JacORB provides an implementation of the standard CORBA name service (specified as a CORBAService) which allows to bind names to object references and to lookup object references using these names. The JacORB name service comprises two components: the name server program, and a set of interfaces and classes used to access the service.
The JacORB name server is a process that needs to be started before the name service can be accessed by programs. Starting the name server is done by typing on the command line either simply
ns <filename>
to run a shell script or
ns.bat <filename>
for a DOS batch file. You can also start the Java interpreter explixitly by typing
java jacorb.Naming.NameServer <filename>
In the example
ns ~/public_html/NS_Ref
we direct the name server process to write location information and logging
information to the file ~/public_html/NS_Ref. Clients of
the name service use this file to locate the server process. These clients
do not, however, access the file through a local or shared file system. Rather,
the file is read as a WWW resource by using a URL pointing to it. This implies
that the name server log file is
accessible through a URL in the first place, i.e. that you know of a web server in your
domain which can answer HTTP request to read the file.
The advantage of this approach is that clients do not need to rely on a hard-coded well known port and that the name server is immediately available world-wide if the URL uses HTTP. If you want to restrict name server visibility to your domain (assuming that the log file is on a shared file system accessible throughout your domain) or you do not have access to a web server, you can use file URLs rather than HTTP URLs, i.e. the URL pointing to your name server log file would look like
file:/home/brose/public_html/NS_Ref
rather than
http://www.inf.fu-berlin.de/~brose/NS_Ref
In order to restrict access to the name server even further, you can use an access control interceptor (cf. Interceptors).
Please note that the overhead of using HTTP is only incurred once -- when the clients first locate the name server. Subsequent requests will use standard CORBA operation invocations which means they will be IIOP requests (over TCP).
Configuring a naming context (i.e. a name server) as the ORB's default or root context is done by simply writing the URL that points to this server's boostrap file to the file jacorb/Orb/Config.java. You need to type make configure in the JacORB directory for this change to take effect. After the default context has thus been configured, all requests through the API given in the class jacorb.Naming.NameServer will go to that server -- provided it's running.
Name servers are used to locate objects using a human-readable reference (their name) rather than a machine or network address. If objects providing a certain service are looked up using the service name, their clients are decoupled from the actual locations of the objects that provide this service. The binding from name to service can be changed without the clients needing to know.
The JacORB name service can be accessed using the standard CORBA defined interface, but there are also a number of proprietarty extensions to the name service which make it easier to use. We will go through a few examples and first use this simplified API.
A very simple way of locating objects is by just calling locate on the default naming context as in
server s = serverHelper.narrow( NameServer.locate("server"));
The locate-operation is a static method of jacorb.Naming.NameServer which contacts the default name server, so we don't need to obtain a reference to a particular naming context.
The interface to the root context in jacorb.Naming.NameServer also allows to bind and unbind service names using registerService() and unregisterService() and names of other naming contexts using registerContext() and unregisterContext().
The server holding the object that provides the "server" service, which was looked up in the example above, can create and register register the object like this:
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
org.omg.CORBA.BOA boa = orb.BOA_init();
org.omg.CORBA.Object server =
boa.create(new serverImpl(),"IDL:jacorb/demo/example1/server:1.0");
boa.obj_is_ready( server );
jacorb.Naming.NameServer.registerService(server, "server");
The two calls boa.obj_is_ready(server) and jacorb.Naming.NameServer.registerService(server, "server") can even be condensed into one: boa.named_obj_is_ready(server, "server"). This shortcut is intended for service objects only, not for contexts.
In the previous section we used a proprietary interface to the name service for convenience. If you want to make the name service replacable, i.e. you want to take care that another vendor's name service can be used with your programs without rewriting them, you might prefer to use the standardized interface to the name service specified in [3].
In a simple cases like the one of the previous example, this would look like this:
// get a reference to the naming service
ORB orb = ORB.init();
org.omg.CORBA.Object o = orb.resolve_initial_references("NameService")
NamingContext nc = NamingContextHelper.narrow( o );
// look up an object
NameComponent[] components = new NameComponent[1];
components[0] = new NameComponent("server","service");
server s = serverHelper.narrow( nc.resolve(components) );
Before an object can be looked up, you need a reference to the ORB's name
service. The standard way of obtaining this reference is to call orb.resolve_initial_references("NameService"). In calls using the standard
name service interface, object names are represented as arrays of NameComponents rather than as strings in order to allow for structured names.
Therefore, you have to construct such an array and specify that the name's
name is "server" and that it is of kind "service" (rather than
"context"). Now, we can look up the object by calling resolve() on
the naming context, supplying the array as an argument.
[ examples ]
[ to be continued ]