Chapter 5: Naming Services
The process of binding objects is performed by a name server. Each instance of EAServer can be its own name server, or you can configure a server to use another server as its name server. You can also use an external naming service, such as an LDAP server, in conjunction with EAServer’s naming service.
You set the naming service options for each server using the Naming Service tab on the Server Properties window.
The naming service relies on an “initial” or default name context for each server. You set the initial context when you set up the server’s Naming Service properties.
The server name context syntax follows a specific organization or schema. You can use this schema to represent the hierarchy of objects in the namespace, for example by geographic region, organizational unit, and so on.
If you use EAServer as the name server, and do not use an external naming service, the initial context for your server uses this format:
<Level 1>/<Level 2>/<Level 3>/...
The number of levels depends on the hierarchy you want to represent. For example:
US/sybase/finance US/sybase/marketing US/sybase/sales
If you use an LDAP server as an external naming service, the initial context must follow the syntax and schema of the LDAP server. LDAP servers have predefined schema for common objects such as country, organization, and organizational unit. EAServer uses the following format for an LDAP-compatible initial context:
ou=<organizational unit>, o=<organization>, c=<country>
Using the previous examples, the initial contexts would be:
ou=finance,o=sybase,c=US ou=marketing,o=sybase,c=US ou=sales,o=sybase,c=US
On start-up, the name server binds all object implementations on EAServer to the initial context of the server on which the object is installed. Once the server binds an object, the structure of the resulting name context is:
<initial context> is the initial context property for the server where the component is installed.
<package> is the name of the package being bound, as displayed in EAServer Manager.
<component> is the name of the component being bound, as displayed in EAServer Manager.
If you have multiple EAServer installations, and one of them is designated as the name server, the name server binds the objects on those servers using the initial contexts of their respective servers. If you do not specify an initial context for any of those servers, the name server binds the objects with the initial context of the designated name server.
You can set the server properties to enable password protection for name binding on an EAServer name server. See “Name binding password security”.
To illustrate how an EAServer name server uses the initial context to create name contexts for objects on multiple servers, let’s say you have three EAServer installations:
Server A contains package Pkg1 and components CompX and CompY. You assign the server an initial context of /us/sybase/serverA.
Server B contains package Pkg2 and the component CompZ. You assign the server an initial context of /us/sybase/serverB.
Designate server C to be the name server for servers A and B by specifying the URL for server C (iiop://myhost:9050) in their Naming Services properties.
When you start server A, it connects to server C, using the name server URL you entered in server A’s Naming Service properties. The name server gets the initial context for server A and binds each object installed on server A. The resulting name contexts are based on server A’s initial context, the package name, and the components in the package. For this example, the name server creates the following bindings:
If you are using an external naming service such as LDAP, the name server also updates the existing object references on that server, if any.
When you start server B, the name server creates the following binding:
Figure 5-1 illustrates the name binding process.
Figure 5-1: Name binding process
An application referencing object CompY uses the URL of the name server, followed by the object’s name context. For example:
The name server finds the name context in the namespace, resolves the name context with the object it references, then implements the object.
If you had not assigned an initial context to Server A, the name server, server C, would create name contexts for objects Pkg1/CompX and Pkg1/CompY using the initial context of the name server. In this case, the client application can simply retrieve CompY using this URL:
The naming service inherently provides transient object name storage. The name server is instantiated when you start EAServer, and binds names to all the known object references. The name server provides the bound name and object references to EAServer’s session manager object. Because this information is stored in memory, the name context information is retained only as long as the server is running.
You can add persistent object name storage capabilities to EAServer by using an external directory naming service, such as an LDAP server. The external server retains object name information, and the EAServer name server updates this information whenever it creates new bindings or unbinds existing ones.
To use an external naming service, specify the URL of the external server in the Naming Service properties of the designated EAServer name server. You must also provide a manager DN (distinguished name) and password that has exclusive access to all objects in the LDAP server database for EAServer to be able to update the stored name context information.
|Copyright © 2005. Sybase Inc. All rights reserved.|