CORBA's new Interoperable Naming Service (INS) introduces three features that combine to help manage your computing environment and integrate it better with the Internet and your corporate intranet as well. These features:
- Define URL-like representations for the CORBA object reference, allowing your ORB to access publicly available CORBA-based services or an object that you know the name of at an available remote site that runs a CORBA 2.4 or later ORB (the CORBA equivalent of the Web's familiar format, www.omg.org).
- Let you configure your client ORB from any vendor in a standard way so as to initialize to the root-naming context you want so that, for example, all the ORBs in your company or department can see the same naming hierarchy. In fact, these extensions to runtime configurability go beyond the Naming Service, as we'll see shortly.
- Define a standard syntax for the compound name of a CORBA object so you and the CORBA 2.4 clients you exchange e-mail with will write and read the same name in the same form, and your computers will know what to do with it.
The INS was adopted by OMG in March 1999 and finished its first maintenance revision in June 2000. For the past few years, OMG has not given newly adopted specifications a release number, or issued them as a formal document, until they've been through their first maintenance revision. This makes it clear to implementers that these new specifications, although adopted, may undergo more change than specifications a year or more old, enough to be implemented as products. (Unfortunately, it also leads to some confusion about what's an adopted OMG specification and what's not.) INS finished its first maintenance revision which was released as part of CORBA 2.4, issued by the OMG in October 2000. This release included CORBA Messaging and updated the Object Transaction Service and CORBA Core. CORBA 2.4 is an interim release; original plans called for INS and Messaging to release as part of CORBA 3.0, now anticipated in early 2001.
CORBA Object URLs: corbaloc
One thing that's great about the World Wide Web is how you can guess the Web address of a place from its company name, type it in the address window of your Web browser, and (most of the time!) get to its Web page right away. Here's a good example - OMG. You begin by guessing that our domain name is our initials, OMG, and you know we're a not-for-profit organization so our extension should be .org. You put these together and guess (correctly) that our URL is www.omg.org.
To make this work for CORBA, almost all we need to do is put a CORBA server on a well-known port of a machine with a domain name and address. What else do we need? Web servers hold a lot of different pages and serve them up one at a time, identifying them by a page or file name ("gettingstarted/overview.htm" or whatever) following the domain name and separated from it by a slash. Analogously, CORBA servers serve a lot of different objects, so we need to put an object key or object name at the end of our object URL. The object key or object name identifies the service or exact object we want a reference for.
Corbaloc is the keyword for the CORBA URL format that translates to the object reference of an object instance, typically providing a service, at a location. Here's an example:
Taking advantage of defaults (we'll get complicated later), this URL starts with the identifying string corbaloc::, followed by a domain name (here, MyGiganticEnterprise.com) or an IP address, a forward slash, and an object key, which in this case is NameService.
The Object Key
The object key is the part of the IOR that the ORB uses to identify the exact instance that is the target of an invocation. Until now - that is, in ORB-generated object references - CORBA had standardized neither the form nor the content of any object key: ORB-generated object keys are only useful to, and used by, the ORB that generated them, so there was no reason to standardize their format or content. The interoperable naming specification defines URL-like object references with object keys that humans can read.
The object key doesn't have to be a single word; it can be any string that the server responds to. Everything that follows the first slash after the domain name or IP address is the object key. For example, in:
the object key is dev/sandbox/NotificationService.
There's no official equivalent of a "home page" or index.htm for corbaloc invocations. NameService, the default object key for corbaname invocations, is as close as the specification comes. If you're setting up a corbaloc server, we suggest you use NameService as your object key (or one of your object keys, since nothing prevents a server from responding to a number of keys). And when you browse the Web for CORBA servers using a CORBA 2.4 client browser, we suggest you start with NameService as the key to the object type you search for first, at least if it's close to what you're looking for...
corbaloc, Full Form, iiop Protocol
Let's take a look at the full form of the corbaloc URL, specifying every field instead of using defaults:
corbaloc:iiop:[email protected] Enterprise.com:2809/pub/NameService
Following the URL key string corbaloc: with its single colon comes the protocol specifier. iiop: is the default protocol; you can either spell it out followed by a colon or just put the second colon as we did in the previous section. There will be URL formats for many protocols, but right now there are only two: iiop, as we've seen, and rir for Resolve Initial References. Details about the rir form are given below.
Addressing information goes between the colon that ends the protocol specifier and the slash that starts the object key. The address format is protocol specific, of course, since each protocol defines the information set that it needs to find a target. For iiop, which runs over TCP/IP, the address field includes an optional IIOP version identifier followed by @, the host specifier as either a domain name or an IP address, and (optionally) a port number preceded by a colon. The default port, registered at the IANA (Internet Association Naming Authority), is 2809.
corbaloc, rir Protocol
In addition to iiop, the specification defines an rir protocol. (rir refers to resolve_initial_references.) The rir protocol gives you access to your ORB's configured initial services through a URL. For example, passing:
to string_to_object returns the same object reference as passing TradingService to resolve_initial_references. The object key in an invocation of corbaloc:rir can be any of the keys defined for resolve_initial_references; if you leave out the object key, the system inserts NameService.
When we get to corbaname, we'll use the rir capability to find our ORB's default-configured NameService and resolve a name against it in a single call.
Coding and Using Corbaloc
How do you code this into your client, and how does it work? The URL is a string, and every ORB already has a standard interface that turns a string into an object reference - it's string_to _object. The INS expands the capability of this function. When you pass a corbaloc object reference string to string_to_object in a CORBA 2.4 and later ORB, it will resolve the domain name into an address, form it into an invocable object reference, and hand you back a session reference for it. You'll have to narrow the session reference to the interface type it's supposed to be - NameService, TraderService, or whatever your object key corresponded to.
If you're the server programmer and these invocations are coming at you, there are (at least) two ways to respond to them: a normal CORBA name or trader object instance will recognize the incoming request and do the right thing, so you can just run yours on your main host IP address at the registered iioploc port 2809. Or if you don't want to run your server on your gateway machine, you can run a lightweight software agent that listens there and replies to Request or LocateRequest messages with LOCATION_ FORWARD replies. Any standard CORBA client will reissue its request to the location you've forwarded to, allowing you to shift this load away from your gateway host to a more suitable server. Your agent will have to run on a CORBA 2.4 ORB and recognize these newly defined object keys; if you don't use an agent, you'll have to use a CORBA 2.4 ORB.
URLs for Objects by Name:
Corbaname builds on corbaloc to let you resolve a name in a remote name service. Here's a sample corbaname URL:
Up to the pound sign (#), it's a corbaloc URL except that the identifying string is now corbaname. After the #, it's an object name in the newly standardized OMG format that we'll present in our final section.
When you pass this to string_to_object, your ORB resolves the corbaloc part to a NamingContext object instance in the host's Naming Service. Your ORB then invokes resolve on the NamingContext instance to resolve the name part of the URL.
For our example the client ORB would attempt to resolve the name Year2000/Menswear/Outdoors.obj on the NamingContext instance Pub/Catalogs on the CORBA server at MyGiganticEnterprise.com that was listening on port 2809.
If you leave out the starting context, the object key (which is what it is at this spot in the corbaname string) defaults to NameService.
You can use the rir protocol with corbaname. If you leave out the object key, it defaults to NameService. Thus, invoking string_ to_object with:
would find the default-configured Name Service and resolve the object named pub/Catalog/Fall2001/Shirts.obj, all in a single call.
Configuring Initial Services
You can do many things by setting the root-naming context at client start-up. For example, by pointing all users' ORBs to the same root, you can unify the namespace across your enterprise's entire computing structure, allowing your users to exchange object names by e-mail and have them work everywhere. Developers, on the other hand, could initialize to either their own individual root-naming context or a workgroup context, depending on how their work was structured. Some will need one root context for one project and another for a second. Administrators will also need control and flexibility in this setting.
OMG's original specification for client-side initialization half-defined the services list_initial_services and resolve_initial_references, covering how to pull 'em out pretty well, but leaving the stuffing 'em in part to the ORB vendors' discretion. As a result, some ORBs came with their own Naming Services initialized to them and left no way for programmers or users to change this setting, while others didn't initialize to anything unless you set it in an environment file or command-line argument at startup.
The INS RFP required the specification to cover the setting of initial object references for the NameService, and while they were at it, the authors of the specification extended it to cover all initial services. They provided three hierarchical settings:
Once we've covered them, I'll tell how they interact as your ORB starts up.
The specification requires, in about these words, that an ORB be administrably configurable to return an arbitrary object reference for nonlocality-constrained objects - that is, the standard services that reside outside the ORB. (After all, it wouldn't make a lot of sense to let a system administrator redefine the object reference of the RootPOA!)
You can set the object reference for a service at startup by passing to the ORB an argument pair of the form:
-ORBInitRef <Object ID>=<Object URL>
<ObjectID> may be either a string from the list of initial services or a new ObjectID; that is, you may define and initialize a new initial service ID that wasn't there when the ORB was written.
<ObjectURL> can be any of the URL schemes supported by CORBA::ORB::string_ to_object, including the ones we've just discussed. For example,
-ORBInitRef NameService= IOR: 00230021AB08FA123...
configures the NameService using a stringified CORBA IOR, and:
configures the Notification Service using a corbaloc-format object reference.
ORBDefaultInitRef lets you define the default host for your services to be one location or a cascading series of locations represented by a URL-format object reference. You provide all of the URL except the slash (/) character and object key; your ORB appends the slash and the appropriate key string and feeds the resulting string to string_to_object. For example, if you input:
-ORBDefaultInitRef corbaloc::My Ser viceHome.com
at ORB startup, and then called resolve_initial_references ("NotificationService"), your ORB would add a slash and object key to generate the now-complete URL:
and pass it to string_to_object to obtain the session reference for the service, which it would then return to you. As you continued to resolve_initial_references, each new request would generate a URL with the appropriate key string, and your ORB would resolve just as it did the Notification Service in this example.
These three methods are resolved in a strict order, which depends on how your ORB is configured. The default order is:
In some cases you don't want an ORB to use the default setting to divert certain services. The specification suggests, for example, that an ORB that uses a proprietary Implementation Repository may not want it to be diverted to use one from another vendor or one that doesn't work in the way it expects or requires. To prevent this, an ORB is allowed (but not required) to ignore the ORBDefaultInitRef argument when it resolves services that don't have a well-known service name accepted by resolve_initial_references. The ORB is not, however, allowed to ignore any setting specified by ORBInitRef - only ORBDefaultInitRef.
- First, attempt to resolve using -ORBInitRef. If you didn't specify an ORBInitRef for this service at initialization, or if the resolution attempt fails,
- Attempt to resolve using -ORBDefault Init Ref. If you didn't specify an ORBDefaultInitRef, or if the resolution attempt fails,
- Attempt to resolve using the administratively configured settings.
String Form of CORBA Names
The original CORBA name service specified how names were stored inside your program (as a struct) but provided no standard format to print them out. That meant you couldn't print out the compound name of a CORBA object and send it to a friend or co-worker and expect him or her to use the literal string unless you both had the same ORB and used the same code. (The name could be parsed into pieces and each piece entered individually if your friend's GUI allowed it, but this isn't a friendly way to deal with names!) Another reason to fix this deficiency: corbaname requires a standard representation for the string form of a compound name. The revision of the name service fixes this by specifying a string representation for CORBA names, which it refers to as stringified names. (Careful: not the same as a stringified object reference!)
The bottom line is that CORBA object names are UNIX-format directory and file names applied to objects. If you're more used to DOS directory and file names, change the backward slashes to forward slashes - everything else is the same. If you're used to Windows names, change the backward slashes to forward slashes and don't use spaces. There are some other differences but they're subtle and we won't go into them here.
At each level CORBA object names - whether for another naming context or an object - already consist of an identifier or ID (the main part of the name) and a kind (the minor part). In the newly defined standard name string, these two parts are separated by a dot, and the different naming contexts are separated by slashes. (In the original Naming Service these were represented as a struct in your program, and no representational syntax was defined.) Just in case you wanted to put dots and slashes into your object name, OMG defines escape characters.
Two stringified names are equal if every identifier and every kind in one equals the corresponding name and kind in the other. Comparisons are case sensitive. If the two strings are equal, the names are equal.
Converting Among Object Name Formats
A new interface, NamingContextExt, inherits from the NamingContext interface and extends it with operations that convert among the forms of object names: to_string and to_name do just what you expect. resolve_str is a combination of to_name followed by resolve. And to_url combines a corbaloc address/object key combination and a stringified name into a corbaname string.
That's a summary of the Interoperable Naming Service. Although I've left out a few details, the major features are covered. It goes a long way toward integrating CORBA into the Internet and corporate intranet world, where it already plays a significant role, so I'm pleased to see it released with CORBA 2.4. In future columns I'll cover the Messaging Service and the changes to CORBA core that were also part of the CORBA 2.4 release.
The version of the INS current as this column was written may be downloaded from www.omg.org/cgi-bin/
doc?orbos/98-10-11, and www.omg.
org/cgi-bin/doc?ptc/1999-12-02, -12-03, and -12-04.
This article was adapted from material in my latest book, CORBA 3 Fundamentals and Programming, and a forthcoming book, Quick CORBA 3 (Wiley).
Jon Siegel, the Object Management Group's director of technology transfer, also writes
articles and presents
tutorials and seminars about CORBA. His new book, CORBA 3
Programming, has just been published by John Wiley and Sons.
He can be reached at: [email protected]