Summary
The Java Naming and Directory InterfaceTM (JNDI) is an application programming interface (API) that provides generic and uniform access to multiple naming and directory services (NIS, DNS, LDAP, ...). JNDI features a pluggable interface meaning implementations for existing, new and future naming services can easily be plugged in. Such pluggable implementations are called service providers.
In this project two JNDI service providers were developed:
- A service provider for the Jini lookup service (LUS)
- A service provider for the HDNS distributed, fault tolerant naming service
These two providers are an addition to the list of existing service providers for NIS, LDAP, DNS, CORBA, ...
JNDI
JNDI
provides naming
and directory
functionality to applications written using the JavaTM
programming language.
It is defined to be independent of any specific directory service
implementation.
Thus a variety of directories--new, emerging, and already deployed--can
be accessed in a common way.
The JNDI architecture
consists of an API
and a service provider interface (SPI).
Java applications use the JNDI API to access a variety of naming
and directory services. The
SPI
enables a variety of naming and directory services to be plugged in
transparently, thereby allowing the Java application using the JNDI API
to access their services. See the following figure.
Additionally JNDI provides a generic distributed event model and support for federation. Federation is the process of "hooking" together naming systems so that the aggregate system can process composite names--names that span multiple naming systems (eg: ldap://myhost.com/n=jiniServer/jxtaGroup/myJxtaObject).
Many examples of composite names and federation are possible in the computing world, for example, URLs (RFC 1738) and the World Wide Web. One way that the JNDI federation model differs from these models is that it provides a single programmatic interface for accessing federations. Not just one API for one federation, but one API for many different types of federations.
Jini
Jini network technology, which includes JavaSpaces Technology and Jini extensible remote invocation (Jini ERI), is an open architecture that enables developers to create network-centric services -- whether implemented in hardware or software -- that are highly adaptive to change. Jini technology can be used to build adaptive networks that are scalable, evolvable and flexible as typically required in dynamic computing environments.
The key features of Jini are:
-
Code Mobility: Extends the Java programming model to the network; i.e., moves data and executables via a Java object over a network
-
Protocol agnostic: Provides the ultimate in design flexibility
-
Leasing: Enables network self-healing and self-configuration; i.e. improving fault tolerance
-
Resiliency - Networks readily adapt to changes in the computing environment
-
Integration - Allows fast, easy incorporation of legacy, current, and future network components
-
Licensing - Jini network technology is available free of charge with an evergreen license
HDNS is a fault-tolerant, distributed naming service initially developed for the Harness project. HDNS uses JGroups for reliable multicast communication. The service consist of a group of nodes which maintain consistent replicas of the registration data. Read requests can thus be handled entirely by any of the nodes, facilitating load balancing and reducing access latencies. Write requests, in turn, are propagated to the each member of the group, enforcing strong consistency of the replicas. The service can withstand a crash of all but one of the group members. These characteristics make HDNS an adequate choice in situations where read requests are predominant, and high failure resilience is required.
The code available here was developed with the H2O project. H2O is an open-source research project of Distributed Computing Laboratory, Dept. of Math and Computer Science, Emory University. The research is supported in part by U.S. DoE grant DE-FG02-02ER25537 and NSF grant ACI-0220183.