Section 9.3. Introducing the Context
9.3. Introducing the ContextA naming service associates names with objects. An association between a name and an object is called a binding, and a set of such bindings is called a context. A name in a context can be bound to another context that uses the same naming conventions; the bound context is called a subcontext. Using a filesystem as an analogy, a directory (such as /temp) is a context that contains bindings between filenames and objects that the system can use to manipulate the files (often called file handles). If a directory contains a binding for another directory (e.g., /temp/javax), the subdirectory is a subcontext. JNDI represents a context in a naming system using the javax.naming.Context interface. This is the key interface for interacting with naming services. A Context knows about its set of bindings in the naming system, but little else. While you might be tempted to think of a Context as an exotic java.io.File object, you should resist making that analogy, as it will just confuse you. Unlike a File object, which can tell you its absolute and relative names as well as return a reference to its parent, a Context object can tell you only about its bindings. A Context can't go up a level, tell you its absolute pathname or even tell you its own name. When you think of a Context, think of an object that encapsulates its children as data and has methods that perform operations on that data, not on the Context itself. 9.3.1. Using the InitialContext ClassThe javax.naming.InitialContext class implements the Context interface and serves as our entry point to a naming system. To use JNDI to access objects in a naming system, you must first create an InitialContext object. The InitialContext constructors take a set of properties in the form of a java.util.Hashtable or one of its subclasses, such as a Properties object. Here is how we created an InitialContext in the Lookup example: // Create a Properties object and set default properties Properties props = new Properties( ); props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory"); props.put(Context.PROVIDER_URL, "file:///"); ... // Create the initial context from the properties we just created Context initialContext = new InitialContext(props); The most fundamental property key is java.naming.factory.initial, which corresponds to the Context.INITIAL_CONTEXT_FACTORY constant. The value for this property specifies the name of a factory class in a JNDI service provider. It is the job of this factory class to create an InitialContext that is appropriate for its service and then hand the object back to us. We have to give the factory class all the information it needs to create an InitialContext in the form of other property values. For example, the factory class learns the protocol, server name, and path to use from the java.naming.provider.url property (Context.PROVIDER_URL). The filesystem factory class (com.sun.jndi.fscontext.RefFSContextFactory) requires a minimal set of properties; it needs only to have its context factory and provider URL specified. Other JNDI providers can be more demanding. For example, the factory class in Sun's LDAP service provider requires the URL of the LDAP server and directory entry you want to access, a username and password, and an authentication type. Here are some properties (shown in the file format used by the Properties class) you might use to create an InitialContext with the LDAP factory class: java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory java.naming.provider.url=ldap://192.168.1.20/o=Planetary,c=US java.naming.security.authentication=simple java.naming.security.principal=cn=kris java.naming.security.credentials=secret These properties create an InitialContext for an organization called Planetary in the global X.500 namespace. The standard JNDI properties can be specified in several ways. Our Lookup example set them explicitly in the source, using some hardwired default values and (optionally) reading alternate values from the command line. Since these are Java properties, they can also be specified using -D arguments to the Java runtime, for example: % java -Djava.naming.factory.initial=org.my.jndi.factory -Djava.naming.provider.url=file:/// MyJNDIClientJNDI can also read its properties from a jndi.properties file located in your CLASSPATH. If we put the following into a jndi.properties file in the root of one of the directories on our CLASSPATH: java.naming.factory.initial=org.my.jndi.factory java.naming.provider.url=file:/// it will have the same effect as the Java runtime arguments just shown. Note that some JNDI services, such as nonpublic LDAP servers, require authentication in order to access them. In these cases, you would use the Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS properties to indicate the username and password for the account you are using to access the underlying service. The corresponding property names for entering these in your jndi.properties file are java.naming.security.principal and java.naming.security.credentials, respectively. 9.3.2. Other Naming SystemsSince many companies support JNDI, there are many naming system service providers . You can find a reasonably comprehensive list of public JNDI providers from the JNDI page on the Sun web site (currently at http://java.sun.com/products/jndi/serviceproviders.html). You should contact the vendor of your enterprise naming system or directory for more details regarding its specialized providers. Table 9-1 lists the factory classes for some common JNDI providers. The first three are provided out-of-the-box with Sun's JDK 1.3, 1.4, and 1.5 implementations. JDK 1.4 and 1.5 also include the DNS provider by default. The others can be downloaded from the URL just specified.
|
EAN: 2147483647
Pages: 269