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:
/us/sybase/serverA/Pkg1/CompX /us/sybase/serverA/Pkg1/CompY
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:
/us/sybase/serverB/Pkg2/CompZ.
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:
iiop://myhost:9050/us/sybase/serverA/Pkg1/CompY
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:
iiop://myhost:9050/Pkg1/CompY
