SEC. 9.1 CORBA 517 The CORBA Naming Service
Like any other distributed system, CORBA offers a naming service that allows clients to look up object references using a character-based name. Formally, a name in CORBA is a sequence of name components, each taking the form of a( id, kind)-pair, where id and kind are both strings. Normally, id is used to name an object by means of a character string such as‘‘ steen’’ or‘‘ elke.’’ The kind attribute is a simple indication of the named object, similar to using extensions in file names. For example, the object named‘‘ steen’’ could have kind‘‘ dir’’ telling that it is a directory object.
There is no way to represent the equivalent of a path name as a single string. In other words, CORBA does not define a separator between name components. Instead, names are to be passed explicitly as a sequence of name components. The representation of a sequence is language dependent, but remains opaque to a client that calls the naming service.
There are no restrictions with respect to the structure of a naming graph. Each node in a naming graph is treated as an object. A naming context is an object that stores a table mapping name components to object references. A naming context is thus the same as what we called a directory node in Chap. 4. Note that an object reference in a naming context may refer to another naming context.
A naming graph does not have a root context. However, each ORB is required to provide an initial naming context, which effectively operates as the root in a naming graph. Names are always resolved with respect to a given naming context. In other words, if a client wants to resolve a name, it is necessary that it does so by invoking the resolve method on a specific naming context. If name resolution succeeds, it always returns either a reference to a naming context or a reference to a named object. In this sense, name resolution proceeds exactly as explained in Chap. 4; for that reason we shall not repeat it here.
9.1.5 Synchronization
The two most important services that facilitate synchronization in CORBA are its concurrency control service and its transaction service. The two services collaborate to implement distributed and nested transactions using two-phase locking.
The model underlying transactions in CORBA is as follows. A transaction is initiated by a client and consists of a series of invocations on objects. When such an object is invoked for the first time, it automatically becomes part of the transaction. As a consequence, the object’ s server is notified that it is now participating in a transaction. This information is implicitly passed to the server when invoking the object.
There are essentially two types of objects that can be part of a transaction. A recoverable object is an object that is executed by an object server capable of