Object Key Generation

Two central tasks of an object adapter are the creation of object references, and later the demultiplexing of a request and delivering it to the right servant. In order to perform the latter, the object adapter must take care in composing object references so that they contain all information necessary to find the one and only responsible servant.

First of all, the object reference must contain one or more profiles with information on how to contact the server; for the IIOP profile, this would be an Internet host name and TCP/IP port number. However, since an object adapter does not know about profiles or transports, this information must be provided by the ORB. In MICO, the ORB keeps an ior_template containing all available profiles but no object key.

**Figure 5.5:** Components of an object reference with a POA-generated Object Key
$\includegraphics{pics/poa-object-key.eps}$

To identify the object adapter, a globally unique identifier (GUID) is used. In a transient POA, this GUID is generated of the server's host name, the process' pid and a numerical timestamp. Host name and pid are included in this GUID because the object adapters' location mechanism is also used to disambiguate between local and remote objects; with only the timestamp, a local POA might also be held responsible for remote objects, if their POA were created at the same moment in time. The composition of the GUID is unique among the current object adapters in MICO, the BOA for example always prefixes its object keys with the three letters ``BOA.''

In a persistent POA, a user-provided identifier, the ``implementation name,'' is used as GUID instead. The following section deals with persistent objects in detail.

A potential object reference with an IIOP profile and a POA-provided object key is shown in figure 5.5.

The object key is defined as sequence of octets with no internal structure. Special care must therefore be taken that the object key can be decomposed unambiguously: the three parts are concatenated, separated by slashes ``/.'' Since a user is free to use slashes in the name of a POA instance or in a user-selected Object Id, these must be ``escaped'' by the POA in constructing the object key.

The location testing required as part of the MICO object adapter interface can be implemented efficiently. For this test, the object key does not even need decomposition, the Root POA just compares the object key's prefix with the two known GUIDs, one representing all transient POA instances, the other all persistent POA instances within the server.

The mechanism of using slashes as separators was a late addition. Previously, a null octet was used. Since neither GUID nor the POA name can contain null characters, this greatly simplified decomposition of an object key at the cost of their legibility.

This became a concern after the OMG unveiled the preliminary specification of the Interoperable Naming Service (INS) in October 1998, which finally addresses a client's bootstrapping problem of receiving initial references in a portable manner, introducing new, simplified, formats for Interoperable Object References as already mentioned in section 3.2. Its idea of having URI-style object references mandates short, legible object keys that can be easily written down, entered by hand, or exchanged over the phone. Using the new notation, the object reference for the object key shown in figure 5.5 could look like

provided that the server implementing the object was running on ``host'', port 1234.

To achieve even shorter object keys, the POA uses a special case of encoding the object key if the (user-selected, in the case of a persistent object) GUID, the POA Name and the Object Id are identical, and ``collapses'' the three identifiers into one. If, therefore, a persistent object with the Object Id ``NameService'' is activated in the POA ``NameService,'' a direct child of the Root POA in the server identified by the GUID ``NameService,'' the complete object key would be NameService, too.

References to transient objects don't look nearly as elegant, as the GUID for transient objects is already large on its own, but then, the new style of object references is most likely to be used for persistent services, such as the Naming Service^5.3 itself.

The contents of an object key in general are unspecified, subject to the ORB vendor. Having a specification impose requirements about the object key - according to the INS, the Naming Service must have an object key of NameService - leads to the interesting situation that it will be impossible to write a portable implementation of the Naming Service, as each ORB will introduce different mechanisms to achieve this object key. While this implementation happens to rely on consent with the programmer alone, who must choose the POA name and the Object Id accordingly, Vishal Kachroo, a member of the TAO team, once mentioned on the MICO mailing list that his implementation of the INS would involve a proprietary additional POA method that explicitly sets an object key, bypassing the usual object key decomposing and dispatching mechanism.^5.4

Consequently, TAO's Interoperable Naming Service will not compile with MICO, and while MICO's implementation will compile with TAO, it will not yield desired results and won't answer requests at the expected location.