Welcome Guest. | Log In| Register | Membership Benefits
InformationWeek Labs
June 22, 1998

Manage Custom Apps With LDAP

continued...page 2 of 3

Philosophical Differences
There are some major differences in philosophy behind the toolkits, and the table on page 4A compares the major features of the LDAP toolkits. Netscape's Directory SDK is the most comprehensive; it provides all the tools you need to allow your applications to work with any LDAP server, including its own Netscape Directory Server. The toolkit comes in two versions, one for applications developed in C and another for those in Java. I looked at beta 1 for version 3.0; the currently shipping version 1.0 supports LDAP version 2. As part of the company's program to release source code for some of its products, the source code for the Directory SDK is available at www.mozilla.org.

Directory SDK does a good job of supporting the LDAP specification, letting your applications access, manage, and update the information stored in a directory. It supports the widest range of platforms of the toolkits I looked at.

Netscape has added a number of nonstandard extensions to its toolkit. You can use the Secure Sockets Layer to encrypt LDAP sessions. It supports user authentication based on user IDs and passwords (optionally encrypted), X.509 client certificates, and user-defined authentication mechanisms. Netscape enhances performance by caching query results on the client side. The toolkit includes pluggable support for alternate I/O and threading routines.

The Java version additionally includes JavaBeans to simplify directory access from applications developed with tools that support beans, and classes for browsing and updating directory schemas.

Sun's JavaSoft unit introduced the Java Naming and Directory Interface version 1.1 as part of its Java APIs. Like Netscape's Directory SDK, JNDI is a complete package for LDAP-enabling custom applications. The toolkit includes class libraries, example code, service providers for various directory services, and a demo program for browsing and editing namespaces and directories.

But unlike Netscape's toolkit, JNDI provides a common API to use just about any back-end directory service you choose, including LDAP, as long as the host application is written in Java. This has several advantages. Because it's written in pure Java, both the toolkit and host application will run on any hardware with a Java virtual machine. Your application can be designed to either access any directory in the supported list, or you can change the directory server without changing the client application.

JNDI includes a service provider's interface that lets you plug in any directory and naming service from any vendor. You can even introduce a new naming or directory service while the client application is running. The JNDI architecture provides an interface layer between your application and directory services.

The JNDI API implements three Java packages for directory support. The Naming interface, javax.naming, is the core interface that specifies a naming context for operations such as adding a name-to-object binding, looking up the object bound to a name, listing bindings, and maintaining bindings. The Directory Interface, javax.naming.directory, manages directory objects and their attributes, and allows searching for directory information. The Service Provider Interface, javax.naming.spi, lets third-party naming and directory service providers hook into the services supported by the JNDI.

One of the significant features slated for Windows NT 5.0 is the Active Directory built upon the X.500 and LDAP specifications. Concurrently, Microsoft will release its Active Directory Services Interface, a high-level API for creating directory-enabled applications with virtually any Windows development tool, including Visual Basic, Java, C, and C++. (ADSI was formerly called OLE-DS.)

Like Sun's JNDI toolkit, ADSI provides a single interface to any directory server with a compliant service provider, including LDAP.

Because ADSI is built on Microsoft's Component Object Model, and because it's from Microsoft, ADSI is a Windows-only solution. Microsoft touts ADSI's support for Java, but it only works with Windows extensions to Java. The ADSI SDK consists of five APIs: Network Provider Interface to support automatic logon to multiple namespaces; Windows Sockets Registration for service registration; Windows Sockets Resolution for name resolution; RPC OLEDB for querying directory data; and ADSI for directory object manipulation. If you need lower-level access to LDAP or other directory services with an API, you can call those, too.

continued...page 3
return to page 1



Back to Labs

Send Us Your Feedback

Top of the Page