Gambaran keseluruhan JNDI, Bahagian 3: JNDI Lanjutan

Saya perlu meneliti banyak hal pada bulan ini, jadi saya akan meninggalkan bulu dan memotong tepat ke titik peluru. Pertama, Java Naming and Directory Interface memainkan peranan penting dalam beberapa teknologi Java. Kami akan melihat peranan ini untuk lebih memahami kedudukan strategik JNDI dalam gambaran keseluruhan Java. Seterusnya, sebagai menyedari keperluan anda untuk menggunakan perkhidmatan JNDI yang berfungsi, saya akan memperkenalkan anda kepada pelaksanaan LDAP mudah alih yang tersedia secara percuma, dan saya akan mengajar anda bagaimana untuk menyambung dan menggunakan penyedia perkhidmatan JNDI. Akhirnya, saya akan membawa anda untuk melihat lebih dekat objek yang mengikat pada entri di JNDI.

TEKS TEKS:

TEXTBOX_HEAD: Gambaran keseluruhan JNDI: Baca keseluruhan siri!

  • Bahagian 1. Pengenalan perkhidmatan penamaan

  • Bahagian 2. Gunakan perkhidmatan direktori JNDI untuk menguruskan aplikasi yang diedarkan dengan lebih baik

  • Bahagian 3. Gunakan JNDI untuk menyimpan objek aplikasi anda yang diedarkan

  • Bahagian 4. Gabungkan apa yang telah anda pelajari dengan aplikasi berkemampuan JNDI

: END_TEXTBOX

Sebelum saya memulakan, sedikit pemikiran semula sudah teratur. Sejak dua bulan kebelakangan ini, saya cuba meyakinkan anda bahawa perkhidmatan penamaan dan direktori adalah setara elektronik dari katalog kad yang terdapat di perpustakaan. Ketika kita memulakan lawatan ke ciri-ciri canggih JNDI, saya ingin anda melupakan analogi ini sepenuhnya - ini sangat menggambarkan kehebatan JNDI.

Mari kita mulakan dengan melihat bagaimana JNDI muncul dalam teknologi Java yang lain.

JNDI di mana sahaja

JNDI berperanan dalam sejumlah teknologi Java. Mari kita pertimbangkan tiga daripadanya: JDBC (pakej Java Database Connectivity), JMS (Java Messaging Service), dan EJB (Enterprise JavaBeans).

JDBC adalah teknologi Java untuk pangkalan data hubungan. JNDI pertama kali muncul dalam Pakej Pilihan JDBC 2.0 (lihat Sumber) bersama dengan DataSourceantara muka. A DataSourcecontoh, seperti namanya, merupakan sumber data - sering daripada pangkalan data tetapi tidak selalu. A DataSourcemenyimpan maklumat contoh mengenai sumber data - seperti namanya, pemandu untuk beban dan menggunakan, dan lokasi - dan membolehkan permohonan untuk mendapatkan sambungan ke sumber data tanpa mengambil kira butiran asas. Spesifikasi JDBC mengesyorkan menggunakan JNDI untuk menyimpan DataSourceobjek.

JMS adalah teknologi Java untuk pemesejan. Spesifikasi JMS menerangkan objek yang ditadbir - objek yang mengandungi maklumat konfigurasi JMS dan digunakan oleh klien JMS untuk mencari barisan dan topik pesanan tertentu. Seperti halnya JDBC, spesifikasi mengesyorkan mencari objek yang dikendalikan JMS melalui JNDI.

Akhirnya, pertimbangkan Enterprise JavaBeans. Semua kacang syarikat menerbitkan antara muka rumah - lokasi tunggal di mana pelanggan mencari kacang perusahaan tertentu - melalui JNDI.

Apa yang JNDI bawa ke meja yang menyebabkannya dipandang tinggi?

Pertama, JNDI mempromosikan konsep sumber maklumat yang dikendalikan secara terpusat - syarat utama untuk aplikasi perusahaan. Sumber maklumat yang diuruskan secara pusat lebih senang ditadbir daripada kumpulan sumber maklumat yang diedarkan. Lebih mudah bagi pelanggan untuk mencari maklumat yang diperlukan sekiranya mereka hanya perlu mencari di satu tempat.

Kedua, seperti yang akan Anda lihat, kemampuan JNDI untuk menyimpan objek Java secara langsung memungkinkannya menyatukan hampir secara telus ke dalam aplikasi Java.

Titik penyedia

Untuk menggunakan JNDI, anda memerlukan perkhidmatan penamaan dan direktori dan penyedia perkhidmatan JNDI. Sun membekalkan beberapa penyedia perkhidmatan penamaan dan direktori biasa (penamaan COS, NIS, pendaftaran RMI, LDAP, dan banyak lagi). Saya telah menetap di LDAP.

LDAP (Protokol Akses Direktori Ringan) mempunyai dua kelebihan untuk dilaksanakan secara meluas (baik dalam bentuk komersial dan bebas) dan cukup mudah digunakan. Ciri-cirinya juga disokong oleh penyedia perkhidmatan LDAP Sun dan JNDI.

Oleh kerana memperoleh dan mengkonfigurasi pelayan LDAP sebenarnya bukan masalah Java, saya hanya akan membawa anda menuju ke arah yang betul dan memberi anda rujukan kepada sumber Internet.

Terdapat banyak pelaksanaan LDAP. Banyak produk komersial seperti Netscape Directory Server dan Secure Way Directory IBM. Beberapa dikemas sebagai sebahagian daripada tawaran yang lebih besar (Microsoft Active Directory adalah sebahagian daripada Windows 2000). Sekiranya anda mempunyai akses ke pelaksanaan seperti itu, anda boleh melewatkan sebahagian besar bahagian ini. Jika tidak, saya akan menerangkan OpenLDAP - pelaksanaan LDAP yang tersedia secara bebas berdasarkan pelaksanaan rujukan University of Michigan - serta pemasangan dan konfigurasinya.

OpenLDAP boleh didapati dari OpenLDAP Foundation (lihat Sumber). Lesennya didasarkan pada "lesen artistik" Perl, yang bermaksud bahawa OpenLDAP adalah perisian percuma (atau sumber terbuka). Binari prakemas tersedia untuk pelbagai jenis Linux (Debian, Red Hat) dan juga BSD Unix. Kerja sedang dijalankan di port ke Windows NT.

Sekiranya anda merancang untuk memasang OpenLDAP, anda harus membaca Panduan Pentadbir SLAPD dan SLURPD (slapd adalah nama pelayan LDAP yang dapat dilaksanakan dan slurpd adalah nama pelayan replikasi LDAP; lihat Sumber untuk lokasi).

I have one final suggestion to make your entire experience more pleasing: no matter which LDAP implementation you use, turn schema checking off. An LDAP schema, like a database schema, defines constraints on the stored information. In normal use, schema checking helps ensure that entries (think of address book entries) conform to the correct format. However, since you'll probably be playing rather than building something of lasting significance, schema checking will just get in the way. Take my word for it.

Connecting to a JNDI context

In previous articles, I tried to avoid explaining in detail how to interact with a JNDI service provider such as the LDAP service provider. I mentioned that you need an initial context to do JNDI operations, but I didn't spend much time telling you how to get one. Let me fill in the gaps. (For more on initial contexts, see the first two articles in this series.)

Before you can do anything with JNDI, you need an initial context. All operations are performed relative to the context or one of its subcontexts.

Obtaining an initial context requires three steps:

  1. First, select a service provider. If you're going to use OpenLDAP or some other LDAP implementation, Sun supplies a reference LDAP service provider (see Resources). Add the name of the service provider to the set of environment properties (stored in a Hashtable instance):

     Hashtable hashtableEnvironment = new Hashtable(); hashtableEnvironment.put( Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory" ); 
  2. Add any extra information the service provider requires. For LDAP, that includes the URL that identifies the service, the root context, and the name and password to connect with:

     // the service: ldap://localhost:389/ // the root context: dc=etcee,dc=com hashtableEnvironment.put( Context.PROVIDER_URL, "ldap://localhost:389/dc=etcee,dc=com" ); hashtableEnvironment.put( Context.SECURITY_PRINCIPAL, "name" ); hashtableEnvironment.put( Context.SECURITY_CREDENTIALS, "password" ); 
  3. Finally, get the initial context. If you just intend to perform naming operations, you'll only need a Context instance. If you intend to perform a directory operation as well, you'll need a DirContext instance instead. Not all providers supply both:

     Context context = new InitialContext(hashtableEnvironment); 

    Or:

     DirContext dircontext = new InitialDirContext(hashtableEnvironment); 

That's all there is to it. Now let's look at how applications store objects to and retrieve objects from JNDI.

Work with objects

The ability to store Java objects is useful: object storage provides persistence and allows objects to be shared between applications or between different executions of the same application.

From the standpoint of the code involved, object storage is surprisingly easy:

 context.bind("name", object) 

The bind() operation binds a name to a Java object. The syntax of the command is reminiscent of RMI, but the semantics are not as clearly defined. It's permissible for the bind() operation to store either a snapshot of the object or a reference to a "live" object, for example.

Be aware that the bind() operation throws a NamingException if an exception occurs during the execution of the operation.

Now let's take a look at the bind() operation's complement -- lookup():

 Object object = context.lookup("name") 

The lookup() operation retrieves the object bound to the specified name. Once again, the syntax is reminiscent of RMI, but the method's semantics are not as clearly defined.

Just as with bind(), the lookup() operation throws a NamingException if an exception occurs during the execution of the operation.

Object storage

What does it mean to store an object in a JNDI naming and directory service? We've already mentioned that the exact semantics of the bind() and lookup() operations aren't tightly defined; it's up to the JNDI service provider to define their semantics.

According to the JNDI specification, service providers are encouraged (but not required) to support object storage in one of the following formats:

  • Serialized data
  • Reference
  • Attributes in a directory context

If all JNDI service providers support these standard mechanisms, Java programmers are free to develop generic solutions that work even when the underlying service provider layer changes.

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.

As serialized data

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.

As a reference

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.

As attributes

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.

Conclusion

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.

Bulan depan kita akan melihat aplikasi berasaskan JNDI. Sementara itu, anda harus berusaha agar JNDI dapat dijalankan dan dijalankan pada pelayan LDAP.

Ketahui lebih lanjut mengenai topik ini

  • Pakej Pilihan JDBC 2.0

    //java.sun.com/products/jdbc/articles/package2.html

  • Pergi ke OpenLDAP Foundation untuk memuat turun OpenLDAP

    //www.openldap.org/

  • Untuk memuat turun Panduan Pentadbir SLAPD dan SLURPD , pergi ke

    //www.umich.edu/~dirsvcs/ldap/doc/guides/

  • Maklumat JNDI, penyedia perkhidmatan dan sebagainya

    //java.sun.com/products/jndi/

Kisah ini, "Gambaran keseluruhan JNDI, Bahagian 3: JNDI Lanjutan" pada asalnya diterbitkan oleh JavaWorld.