3.2
Object Naming
Object naming systems link references to objects on a system. Typically, this reference is passed to the component that wishes to use the object. For example, CORBA objects are represented by an object name. When an application wishes to use a CORBA object, it looks up the reference and uses the reference to access the object. Objects names are typically relatively static, in that objects are long-lived and their names do not often change. In this section, we examine some object naming services, specifically, the Spring naming service and CORBA object names.
3.2.1 Spring Naming Service
The Spring [120, 137, 149, 166] operating system was an experimental microkernel [171] based operating system designed by Sun to replace its Unix operating system. One of the basic design aspects of Unix is its concept that “everything is a file”. Thus, directories are files, devices are files, and so on. However, this paradigm does not fit every aspect of a Unix system. For example, the capabilities of printers are represented in a printer specific namespace.
To address this limitation, subsystems in Unix have type-specific name services, such as the printer capabilities (/etc/printcap) or environment variables. Furthermore, distributed services of Unix, such as NIS or NFS, must also have a means to refer to objects distributed across a network. These systems use directory services to bind objects to names. The spring system provides a specific name service to support the requirements of the different subsystems of the operating system. This naming service provides users and normal Unix programs uniform naming access to most types of Unix objects.
Spring is an extensible distributed operating system that is inherently multi-threaded. It is struc- tured around the concept of objects that act as “an abstraction that contains state and provides a set
of operations to manipulate that state” [137]. Spring provides the concept of a domain, that is an
address space with a set of threads. In a distributed system with multiple domains, Spring provides an unforgeable nucleus door identifier that identifies the server domain.
The Spring name service allows any object to be bound to any name. These name binding are stored in a context. A context is an object that stores one or more unique name bindings. A simple example of a context is a Unix directory file. Each file in the directory is an object-name binding and the directory file stores these bindings. Objects can be bound to more than one unique name at a time. The Spring name service provides the capability to bind objects to names and to resolve the name for any object. As contexts are themselves objects, they can also be bound to names. This leads to naming graphs. For example, the Unix file system is such a naming graph. An example of such a graph is shown in Figure 3.4. In a naming graph, directory contexts are bound to names (the directory name) and these contexts stored in another directory file (the parent directory).
/home /usr/share /usr /usr/lib /home/tom /home/tom/research /
Figure 3.4: A File System Naming Graph
bound can be associated with access control lists (ACL). ACLs specify the access rights that princi- pals have to objects within the system. One of the major advantages of this paradigm is that names in the Spring system provide the detail to specify security policies for all of the different subsystems that make up the Spring operating system.
3.2.2 CORBA Names
Common Object Request Broker Architecture (CORBA) [28, 81, 140] is a application component system that is specified and standardised by the Object Management Group (OMG) [8]. CORBA defines an API, communication protocol and object management system to enable heterogeneous components to inter-operate on various systems. CORBA objects can be thought of as services that are used by applications. In general, CORBA wraps code to provides a standard interface to that code for distribution across a network.
An important aspect of CORBA is how these objects are named. CORBA objects may be distributed across many different CORBA servers (called object request brokers or ORBs). The provision of means to refer to objects on remote systems allows these objects to be used. In most object orientated systems, objects have references that are used internally to identify them. In CORBA, objects are used remotely, a more systematic approach is required.
CORBA’s naming service, like the Spring system, relies on the concepts of name to object asso- ciations called name bindings. Name bindings in CORBA are defined relative to naming contexts.
3.4 Other Naming Systems 61
As with Spring name contexts, CORBA name contexts contain a set of name bindings in which each name is unique. Many different names can be bound to a single object. However, there is no requirement that every object have a name. Contexts can also be named, allowing the creation of naming graphs. CORBA uses linked contexts to form compound names to refer to an object. A compound name defines the path in the naming graph that leads to an object.
Names in CORBA are made up of a sequence of name components. Name components consist of two attributes: the id attribute and the kind attribute. Both the id attribute and the kind attribute are represented as interface definition language (IDL) strings. Kind attribute provides a textual descrip- tion of the name. For example, a kind attribute could be “c source” or “executable”. Kind attributes are not interpreted by the naming system. Both attributes are arbitrary length ASCII strings. Name components cannot be empty and a name must consist of at least one name component. In contrast id attributes store the reference to the object in question.
As with the Spring system, the CORBA security model uses object names to form the basis of the access control system. Permissions are specified regarding object names.