|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 4
Each of the methods above has advantages and disadvantages. The best method will depend on the requirements of the application under development.
Let's consider each in turn.
The most obvious approach to storing an object in a directory is to store the serialized representation of an object. The
only requirement is that the object's class implement the Serializable interface.
When an object is serialized, its state becomes transformed into a stream of bytes. The service provider takes the stream of bytes and stores it in the directory. When a client looks up the object, the service provider reconstructs it from the stored data.
The following code demonstrates how to bind a LinkedList to an entry in an JNDI service:
// create linked list
LinkedList linkedlist = new LinkedList();
.
.
.
// bind
context.bind("cn=foo", linkedlist);
.
.
.
// lookup
linkedlist = (LinkedList)context.lookup("cn=foo");
It's that easy!
Unfortunately, the other two methods are more complicated. I will describe them briefly but reserve a detailed discussion for a later date.
Sometimes it's not appropriate (or possible) to serialize an object. If the object provides a service on a network, for example, it doesn't make sense to store the state of the object itself. We're interested in the information necessary to find and communicate with the object.
An example is a connection to an external resource (one outside the scope of the Java Virtual Machine) such as a database or file. It clearly doesn't make sense to try to store the database or the file itself in the JNDI service. Instead, we want to store the information necessary to reconstruct the connection.
In this case the programmer should either bind a Reference instance that corresponds to the object or have the object's class implement the Referenceable interface (in which the object generates and provides a Reference instance when requested by the service provider).
The Reference instance contains enough information to recreate the reference. If a reference to a file was stored, the reference contains
enough information to create a File object that points to the correct file.
If you're using a service provider that provides directory functionality instead of only naming functionality, you can also
store an object as a collection of attributes on a DirContext object (a DirContext instance differs from a Context instance in that it may have attributes).
To use this method, you must create objects that implement the DirContext interface and contain the code necessary to write their internal state as an Attributes object. You must also create an object factory to reconstitute the object.
This approach is useful when the object must be accessible by non-Java applications.
If you've read the series, you should understand and appreciate the power and importance of JNDI -- you don't hear much about it, but it's there under the covers.
Next month we'll take a look at a JNDI-based application. In the meantime, you should try to get JNDI up and running on an LDAP server.
Read more about Enterprise Java in JavaWorld's Enterprise Java section.