[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Java LDAP api's



--On Freitag, 8. November 2002 10:55 -0700 Bryan Field-Elliot <bryan_lists@netmeme.org> wrote:

There are standard Java API's for LDAP (even covering LDAPv3) from Sun,
in the javax.naming.directory and javax.naming.ldap packages. By
contrast, posted on the OpenLDAP site, is the JLDAP class library
donated by Novell. What's not clear from the OpenLDAP site is, why one
would choose JLDAP over the standard Java API's, or whether they should
be combined etc. I guess I'm looking for a brief positioning statement
from this on JLDAP (e.g. why it exists?)

There has been a discussion on this subject on the ldap@umich.edu Mailing List in August 2000. As I couldn't find an archive, I attached one post from the thread.

Norbert
--- Begin Message --- 
Vincent Ryan wrote:
> 
> As Rob has acknowleged: he's biased, so let me provide some
> balance from the JNDI perspective and correct a few errors.
> Also, I've copied the JNDI-INTEREST mailing-list; many of
> whom are interested in the comparison of these 2 APIs.
> 
> 1. The power of JNDI lies in the abstraction that it provides.
>    A naming or directory application is coded in terms of the
>    services that it requires rather than any particular
>    implementation of those services. A good example of this
>    is the way JNDI allows an RMI application to work portably
>    across a JRMP or IIOP environment - independent of the
>    underlying transport. This has general appeal. You don't
>    have to be writing EJBs or designing J2EE-specific
>    applications to apply such a design principle.

  That is a good description of the strength of JNDI. The Directory SDK for Java, on the other hand, just does one thing - LDAP - but does it very well, and it does it explicitly for LDAP, allowing the programmer to access also the LDAP-specific services. Neither is right or wrong, there is a need for both.

 
> 2. JNDI is object-oriented by design and is well integrated
>    with the Java platform. In my view, application developers
>    interested in a low-level API that maps directly to the LDAP
>    wire-protocol are best served by the LDAP C-API. I see
>    no advantage in having a Java API that closely mirrors a
>    low-level wire-protocol - it's the worst of both worlds.
>    Developers wishing to benefit from object-oriented design
>    are better served by a high-level Java API. JNDI provides
>    explicit support for Java objects and is highly extensible
>    by means of its factory framework.

  The Directory SDK is also object-oriented by design, 100% Java, and well integrated with the Java platform (unless you mean shipping with the JDK).

  The choice of level of abstraction is orthogonal to the choice of programming language. Someone who needs to LDAP-enable an application or otherwise provide access to LDAP should be able to choose whatever language is appropriate for the environment. At http://www.mozilla.org/directory you'll find Java, C, and Perl LDAP SDKs. There is also a Smalltalk LDAP SDK (based on the Java LDAP SDK) and a VisualBasic interface (using the C LDAP SDK).


> 3. JNDI is supported on a range of vendor platforms, not just
>    the Java 2 Standard Edition (J2SE) and Enterprise Edition
>    (J2EE) from Sun. Customers have ported and deployed it in a
>    wide-ranging array of platforms for accessing LDAP directories,
>    including smart cards and PersonalJava. Even before J2EE was
>    conceived, leading enterprise vendors such as ATG and
>    BEA/Weblogic were supporting and incorporating JNDI as part
>    of their products. These vendors supported access to LDAP
>    directories via JNDI. I'm in agreement with the original
>    poster: JNDI is the more strategic choice, it was 2 years ago,
>    and most certainly is now.

  The Directory SDK for Java is supported on J2SE and J2EE, as well as the most widely used Java platform in the world: Communicator. It has been shipping with Navigator/Communicator since 1997.

 
> > - The Directory SDK for Java is way more powerful than JNDI. It lets you do
> >   asynchronous operations, it has strong explicit support for schema management,
> >   it has a ton of features you'd have to implement yourself with JNDI (connection
> >   pool, intelligent transparent failover, LDIF processing, and much more).
 
> JNDI has async operations (by means of Java threads),

  The Directory SDK supports asynchronous operations without client-defined threads and thread management. Explicit asynchronous operations allow you to do things like opening requests to several servers at once and have them share a single result queue, with no client thread programming. Obviously not needed by all applications, but useful for very high performing environments where data is distributed across servers.


> has explicit support for schema management, has

  JNDI surfaces schema elements as attributes, not as first class schema objects. That's fine, but you don't get the compile time checking that strong typing provides.


> connection-sharing (between contexts)

  Connection sharing is not the same as connection pooling. Connection pooling is a familiar concept to database programmers. It typically takes much longer to create a connection than to do a search (or authenticate). To address this, serious server-side programmers usually end up writing a pooling mechanism that pre-connects a number of objects and reuses them for incoming client requests (if such a mechanism is not already provided by the environment, e.g. an app server). The Directory SDK for Java provides a ready-to-use connection pool.


> and has DSML (XML)
> processing rather than LDIF processing.

  The Directory SDK for Java has both. I don't know of any LDAP servers that can import DSML; you really need LDIF if you will be doing bulk import or export.

 
> I'm not clear exactly what "intelligent transparent failover"
> means.

  Directories are very often mission critical nowadays. Every new client connection to a secure Web site may involve an LDAP authentication, for example, and companies are not happy if the LDAP server or the machine it is running on goes down, or even needs to be taken down for upgrade, causing client connections to fail. One solution is to replicate the LDAP server so that binds can be done at any of a number of servers.

  With the Directory SDK for Java, you just have to specify more than one server instead of a single server when doing "connect()" and you get transparent failover. If the first server is not available, the next one is used, etc. If the server later on goes down, the next LDAP operation request causes the SDK to reestablish the connection with a server that is accessible - transparently. The SDK remembers which servers were problematic and doesn't attempt to connect to them again unless all other servers have been exhausted. The "intelligent" part is that you can request that multiple servers be tried sequentially with an optional timeout for waiting on each one (rather than the 45 second or 120 second network timeout), or in parallel so that a connection is always established to the server that is quickest to respond.

  The list of "extras" in the Directory SDK for Java compared to JNDI goes on and on - support for language subtypes (e.g. give me all the French-version attributes for this user, not the English-version ones), you can find the number of search results received without enumerating through them all, optional timeout on connecting (so the client doesn't have to wait 45 or 120 seconds to find out that the server is inaccessible), optional search result cache, ...  Most of these things could be written by a programmer for use with JNDI (but why write them for every application?), while some can't (because JNDI doesn't expose the hooks, even though the information is available through the LDAP protocol). This is a valid design decision - keeping JNDI fairly small. The Directory SDK went the other way - adding features commonly required by adopters.


> > - If you are planning to use an SDK just for LDAP (not for NIS or one of the
> >   other JNDI services), you may find the API of the Directory SDK more intuitive.
> >   It certainly maps better to the protocol, so it is easier to leverage reading
> >   material on LDAP (i.e. to understand what the corresponding objects and methods
> >   in the SDK are).
> >
> > - If your application will be accessing NIS or some other JNDI service in addition
> >   to LDAP, and you don't have high performance requirements or don't plan on doing
> >   anything fancy, JNDI is the obvious choice.
> >
> > - If you are writing EJBs and are not planning to do anything fancy with LDAP
> >   (e.g. just simple synchronous authentication, search, and update), you are better
> >   off with JNDI since it is a required part of the J2EE spec and will be present
> >   regardless.
> >
> > - If you plan to do what it takes to squeeze the last ounce of performance from
> >   your LDAP interface, you will probably need to use the Directory SDK.
> 
> Rob didn't provide any performance numbers so I ran a quick test
> using J2SE v1.3 on Solaris 8. The Search example program provided
> in the LDAP SDK ran 30% slower than an equivalent search program
> coded using JNDI and our LDAP service provider. Both programs
> are attached.

  The time to run a program that does a single search is dominated by the VM startup and program launch, the output to the screen, and the conversion from UTF8 to local character set. Last year a very large software company did extensive benchmarking and found:

"1. The search performance of Netscape's SP seems to be much better:
      search 1K objects:
        Sun: 24.000 seconds
        Netscape: 17.281 seconds
        IBM: 25.203 seconds
"

  That was using the JNDI Service Provider that comes with the Directory SDK, so the times for the SDK without the thin Service Provider layer should be a little better.

  But raw performance may vary from release to release and will depend on the particular application and environment. My point about "squeezing the last ounce of performance from your LDAP interface" was about the additional options you have with the Directory SDK for Java to get it to do just what you want and perform optimally for a particular environment. For example, if you need to consolidate search results from multiple servers (as mentioned above), you can do so much more efficiently and safely by leveraging the support for asynchronous operations in the LDAP protocol and in the Directory SDK than by trying to coordinate and manage multiple synchronous searches with many threads.


> > - The Directory SDK for Java comes with a JNDI Service Provider, so you can use it
> >   even if you decide to go with the JNDI API. Note, though, that you should not
> >   combine the two interfaces. You have to decide which one you will be using in a
> >   particular application.
> >
> > - The Directory SDK for Java is a Mozilla open source project, so it is very quick
> >   to get bugs fixed or new features added.


Rob

---
You are currently subscribed to ldap@umich.edu as: [ldap-list@mail500.uni-tuebingen.de]
To unsubscribe send email to ldap-request@umich.edu with the word UNSUBSCRIBE as the SUBJECT of the message.

--- End Message ---