Previous | Next | Trail Map | Beyond the Basics | Miscellaneous

Naming Policies

The JNDI is defined independent of any specific naming and directory service implementation. This allows a variety of naming and directory systems to be accessed in a common way. However, for true independence, there needs to be common policies that specify how the naming and directory should be used. Without these policies, you might be able to use the same API to access the data, but how you find that data and how you use that data would still be directory dependent. The lack of policy is a problem not just for multiple naming and directory systems; it is also a problem for single naming/directory systems such as the LDAP. Without general agreement on how the data in the directory is to be organized and used, a single system can easily deteriorate into an unmanageable mess.

For example, suppose two applications need to associated data with a user in an enterprise. If the two applications each chooses their own policy of how to name and represent a user in the directory, there will be two representations of the same user in the directory. Furthermore, users of each application must learn each representation and how to name them.

Types of Policies

There are two categories of policies: The LDAP has defined attribute syntaxes (RFC 2252) and user-related schema (RFC 2256). There are many other proposals for specifying other domain-specific schema, such as for mail and security. There are also efforts to standardize the schema across different directory systems (see RFC 2307). In addition, several proprietary schemas have emerged in the LDAP space from vendors such as Netscape and Microsoft. Some applications that are based on servers from those vendors have dependencies on the proprietary schemas.

In the naming policy area, there have been naming policies defined in the X.500. Most LDAP systems follow a common naming convention at the higher levels of the naming tree (for example, how to name countries, organizations and departments). There is less agreement on lower levels. However, some servers, such as the Active Directory from Microsoft, have defined their own naming policies.

The DNS has defined naming policies at the higher levels of the naming tree. The DNS has been used primarily to name machines and domains on the Internet and Intranet. Therefore, naming policies for other entities are less relevant.

In terms of composite naming policy, the HTTP and FTP URLs have set the defacto standard. Namely, the first component of the URL names the host/domain using the DNS, which then leads to a proprietary namespace underneath.

The Java 2 Platform Enterprise Edition Naming Policies

The JNDI does not define any naming policy on its own. However, one important platform that does define a limited set of naming policies for using the JNDI is the Java 2 Platform, Enterprise Edition (J2EE). It defines a logical namespace that application components (such as Enterprise JavaBeans, servlets, and Java Server Pages (JSP)) can use to name resources, components, and other data. The namespace is provided to a component by its container, the entity that executes the component. Typically, a component has a deployment descriptor that contains, among other data, information about the logical names and types of resources and components that the component needs or references. An administrator, using information from the deployment descriptor, maps the logical namespace to bindings in the namespace of the actual environment into which the component is being deployed. The container uses this mapping to present the logical namespace to the component. See the J2EE specification for details.

The enterprise namespace is rooted in a URL context for URL scheme java. For example, you might use a name such as java:comp/env/jdbc/Salary from the initial context to name the Salary database. Details about URL contexts are discussed in the URLs (in the Beyond the Basics trail) lesson. By making use of a URL context, the policy avoids any conflicts with names in the initial context configured by the Context.INITIAL_CONTEXT_FACTORY(in the API reference documentation)environment property.

At the root context of the namespace is a binding with the name comp, which is bound to a subtree reserved for component-related bindings. The name comp is short for "component." There are no other bindings at the root context. However, the root context is reserved for future expansion of the policy, for naming resources that are not tied to the component itself, but to other types of entities such as users or departments. For example, future policies might allow you to name users and organizations/departments, by using names such as java:user/alice and java:org/engineering.

In the comp context, there are two bindings: env and UserTransaction. The name env is bound to a subtree reserved for the component's environment-related bindings as defined by its deployment descriptor. env is short for "environment." The J2EE recommends (but does not require) the following structure for the env namespace:

The env context might also contain bindings for other types of configuration data (such as strings and primitive data types) that the component needs, as defined in the component's deployment descriptor. There is no policy recommended or required for these bindings; they can be placed at the root of the env context or be partitioned by subtrees based on their logical relationships or types. For example, you might have bindings for a string and a numeric parameter that are named using java:comp/env/CompanyName and java:comp/env/PrimeRate, respectively.

The name UserTransaction is bound to a javax.transaction.UserTransaction object. The component that looks up this object from the namespace (by using the name java:comp/UserTransaction) can use it to start, commit, or abort transactions.

Previous | Next | Trail Map | Beyond the Basics | Miscellaneous