The CORBA standard is really a collection of standards and definitions. In addition to the core specifications for the Object Request Broker (ORB) and inter-ORB communication protocols such as IIOP, CORBA also includes specifications for services that distributed objects may require, such as naming services, security measures, etc. Taken as a whole, these specifications, backed up by solid implementations, provide a very powerful environment for the distributed application developer.
This appendix provides a brief overview of some of the key services currently included in the CORBA Services specification. Some of these services are similar in nature to features provided inherently by Java. In these cases, we discuss the contrasts between the Java-native service and the CORBA service.
The Naming Service is arguably the most commonly used service in the CORBA family. We used the Naming Service in our CORBA example in Chapter 3, "Distributing Objects" to look up our CORBA-based Solver object. The Naming Service provides a means for objects to be referenced by name within a given naming context. A naming context is a scoping mechanism for names, similar in philosophy to class packages in Java. Within a particular context, names must be unique, and contexts can be nested to form compound contexts and names. Figure B-1 shows two naming contexts in the form of Venne diagrams: one, whose topmost context is named "BankServices," defines names for objects in a banking application; the other, named "LANResources," defines names for network resources such as printers, compute servers, data servers, etc. The "BankServices" naming context contains a single object named "AuthorizationAgent," and a subcontext named "CorporateAccount." The "LANServices" context contains a "DataServer" context and a "Printer" context, and each of these contains two named objects.
Agents in a distributed system can add named objects to the Naming Service by binding objects to a particular name within a context. Other agents can then look up these objects by resolving their names into object references. The name of an object is made up of a sequence of name components that specify the subcontexts that the object falls within. So, for example, the "Laser1" object in the "LANResources" context would be fully specified with a name made up of the ordered components "LANResources," "Printer," and "Laser1."
All of the interfaces making up the Naming Service are contained in the CosNaming module. The interface to the central Naming Service functions is the NamingContext interface, which provides methods for binding, rebinding, and unbinding objects to names, as well resolving object references from names. Using a Java implementation of the CORBA Naming Service, the "LANResources" context and all of its object "contents" might be built up as follows:
// Get handle on base naming context from the ORB
NamingContext base = ...
// Get references to the objects to be registered in Naming Service
omg.CORBA.Object engDataBaseRef = ...
omg.CORBA.Object finDataBaseRef = ...
omg.CORBA.Object laserPrinterRef = ...
omg.CORBA.Object plotterRef = ...
// Build up subcontexts for LAN resources
NameComponent lan = new NameComponent("LANResources", "");
NameComponent data = new NameComponent("DataServer", "");
NameComponent print = new NameComponent("Printer", "");
// Create context for LAN resources
NameComponent path[] = {lan};
NamingContext lanContext = base.bind_new_context(path);
// Bind all of the data servers to their names within the new context
path = {lan, data, new NameComponent("Engineering", "")};
lanContext.bind(path, engDataBaseRef);
path = {lan, data, new NameComponent("Financial", "")};
lanContext.bind(path, finDataBaseRef);
// Bind the printers to their names
path = {lan, print, new NameComponent("Laser1", "")};
lanContext.bind(path, laserPrinterRef);
path = {lan, print, new NameComponent("Plotter", "")};
lanContext.bind(path, plotterRef);
In this example, a new context is established first for the LAN resource objects. The bind_new_context() method of the NamingContext interface takes an array of NameComponents, which specify the fully qualified name for the new context. In this case, we simply need a single NameComponent to give the new context the name "LANResources."
Next, the object references are bound to their names within this new context. In each case, we create an array of NameComponents specifying the compound name for the object, then bind the object to its name by calling the bind() method on the NamingContext.
Agents that want to use these named objects can look them up by getting a reference to the NamingContext and resolving the object references from their full names:
NamingContext base = ...
NameComponent printerName = {new NameComponent("LANResources", ""),
new NameComponent("Printer", ""),
new NameComponent("Laser1", "")};
omg.CORBA.Object printerRef = base.resolve(printerName);
There are many similarities between the RMI registry facilities, represented by the java.rmi.Naming interface, and the CORBA Naming Services, represented by the NamingContext interface in the CosNaming module. Each provides methods for binding and rebinding objects to names, removing these bindings, and looking up objects by name. They also both provide methods for listing the contents of a registry or NamingContext, respectively.
Where CORBA and RMI differ the most with regards to naming services is hierarchical naming contexts. RMI does not support them at all, while CORBA supports them extensively with the ability to both create hierarchical naming contexts and represent compound object names. In the RMI examples in this book, we got around this limitation of the RMI registry by registering a single factory object with the registry, which was then used to create references to other remote objects. So the client of the remote object would use a single, simple name to look up the remote factory object, and the factory object would be responsible for supporting the "lookup" of other objects within this "context."
In situations where hierarchical naming is critical, such as distributed directory services, this becomes a major deficiency in the RMI package, and a good reason to turn to the more comprehensive services provided by CORBA.
 |  |  |
| A.2. Class Downloads |  | B.2. Event Service |
Copyright © 2001 O'Reilly & Associates. All rights reserved.