Naming and Directory Services:
A fundamental element in every application is the capability
to find and locate components and services.
A client looking for a component/service
usually knows its name, but not its physical location.
The component name correspond to the actual name,
typically much more difficult to remember and manage.
A well-known naming service is provided on Internet by DNS.
For applications, a naming/directory service is the way
to get a reference to a required service
(e.g. a JDBC data source, a JMS connection factory,
an EJB home interface, etc.)
Naming and Directory Services
A naming service is an application that contains
a set of objects, or references to objects,
with corresponding names
(usually easy to remember).
Such correspondances are called bindings.
A directory service allows for the association
of attributes to a binding.
Some popular directory implementations:
• Lightweight Directory Access Protocol (LDAP)
• Network Directory Service (NDS)
• Network Information Servis Plus (NIS+)
•CORBA Naming Service (COS
•Domain Name Service (DNS)
JNDI (Java Naming Directory Interface) provides Java clients
with the capability to access naming and directory services.
JNDI is subdivided in the following packages:
Service Provider Interface
JNDI configuration could be a quite difficult task.
Whenever we use an EJB server,
JNDI is started automatically
at the same time of the server itself.
Such a service is usually already configured
for the specific server.
Also the client applications using JNDI
must be configured, and this task
is up to the programmer/assempler/deployer.
JNDI Environment Properties
A client (object) uses JNDI to locate remote services;
but JNDI might be a remote service as well.
Thus, how to locate a naming service
without using a naming service?
We can do it using environment properties.
Some standard JNDI properties:
Context and InitialContext
Context (interface) is used to deal with objects
that have been bind to a JNDI name.
javax.naming.Context contains methods to put
objects in the naming service, and to retrieve them.
All the naming services have an access point,
and in JNDI it is named InitialContext.
To obtain an InitialContext, three steps are required:
1. Select the service provider
2. Specify every configuration needed
3. Call the InitialContext constructor,
providing the environment properties.
!!! A unique InitialContext is not thread-safe!
Use of InitialContext
InitialContext must be closed after its usage,
as it happens for any resource, e.g. a JDBC connection.
The best way to do it is to insert the invocation
of the close method inside a finally block.
The method getEnvironment of Context
returns an Hashtable with all the active properties
for the context.
The method lookup(name) returns a reference
to the Object corresponding to name.
This way, also EJB “home factories” are looked up.
Access to the
Environment of an EJB
As an EJB usually must not access files,
how can an EJB access its configuration properties?
A smart way to pass a configuration value to a bean is
through its deployment descriptor, adding an env-entry tag, e.g.
<description>what a beautiful entry!</description>
An EJB accesses environment properties
using an InitialContext object,
and looking up the desired property by its name.