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

Naming Policies

As mentioned earlier in this lesson, 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 it to offer true independence, common policies are required 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 and use that data would still be directory-dependent. The lack of policy is a problem not only for multiple naming and directory systems, but also 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 that two applications need to associated data with a user in an enterprise. If each application chooses its own policy of how to name and represent a user in the directory, then the directory will contain two representations of the same user. Furthermore, users of each application will have to learn each representation and how to name it.

Types of Policies

There are two categories of policies: The LDAP defines attribute syntaxes (RFC 2252) and user-related schema (RFC 2256). Many other proposals for specifying other domain-specific schema are available, such as for mail and security. In addition, efforts are underway to standardize the schema across different directory systems (see RFC 2307). Further, 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, naming policies have been 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). Less agreement exists 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. It is used primarily to name machines and domains on the Internet and Intranet so naming policies for other entities are less relevant.

In terms of a composite naming policy, the HTTP and FTP URLs have set the de facto standard. Namely, the first component of the URL names the host/domain using the DNS. After the first component, there is 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 (J2EETM). It defines a logical namespace that application components (such as Enterprise JavaBeans, servlets, and JavaServer 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 the java URL scheme. 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 using 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 the future expansion of the policy, specifically for naming resources that are tied not 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 that is 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 wrappers around primitive data types) that the component needs, as defined in the component's deployment descriptor. No policy is 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