Locating Objects

One of the fundamental tasks that a CORBA programmer faces is discovering how to get a reference to a server object. The CORBA specifications permit a great deal of freedom to the implementer in this area.

As you saw in the example in the previous section, the Oracle8i solution is to publish non-transient objects in a Oracle8i database instance, using a CORBA CosNaming service. JServer provides a URL-based JNDI interface to CosNaming, to make it easy for clients written in Java to locate and activate published objects.

The Name Space

The name space in the database looks just like a typical file system. You can examine and manipulate objects in the publishing name space using the session shell tool. (See "sess_sh" for information about the session shell.) There is a root directory, indicated by a forward slash ('/'). The root directory is built to contain three other directories: bin, etc, and test. The /test directory is the place where most objects are published for the example programs in this guide. You can also create new directories under root to hold objects for separate projects, however you must have access as database user SYS to create new directories under the root.

There is no effective limit to the depth that you can nest directories.

Note: The initial values in the publishing name space are set up when the JServer product for Oracle8i is installed.

The /etc contains objects that are used by the ORB. Do not delete objects in the /etc directory. They are owned by SYS, so you would have to be connected in the session shell as SYS to delete them. The objects is /etc are:

deployejb    execute    loadjava    login    transactionFactory 

The entries in the name space are actually represented by objects that are instances of the classes oracle.aurora.AuroraServices.PublishingContext and oracle.aurora.AuroraServices.PublishedObject. A publishing context represents a class that can contain other objects (a directory), and the PublishedObject class is used for the leafs of the tree, that is the object names themselves. These classes are documented in the JavaDoc that you can find on the product CD.

Published names for objects are stored in a database table. Each published object also has a set of associated permissions, maintained in a separate table in the system tablespace. Each class or resource file can have a combination (union) of the following permissions:

read

The holder of read permission can list the class, or the attributes of the class, such as its name, its helper class, and its owner.

write

For a context, the holder of write permission for a context can bind new object names into a context. For an object (a leaf node of the tree), write permission allows the holder to republish the object under a different name.

execute

Execute permission is required to resolve and activate an object represented by a context or published object name.

These permissions are set when the objects are loaded into the database. You can use the session shell tool to view and change object permissions. See "sess_sh" for information about this tool.

Publishing means registering the object name in the database name service. The steps involved are:

• inserting the name in the session namespace

• associating the name with the implementation class that was loaded

• providing the name of a helper class for the object

• assigning permissions to the published name that determine who can modify, access, and execute the object

Looking Up an Object

The JNDI lookup() method is the normal way that a client looks up an object whose name is published in the name space. When you invoke the lookup() method, you normally pass it a String parameter that specifies a URL containing

• the service name

• the path name of the published object to look up

Service Name

The service name specifies a service handled by an IIOP presentation, and represents a database instance. This Oracle8i release provides two services: session IIOP and standard IIOP. The format of the service URL is explained in "URL Syntax". Briefly, the service name specifies

• a service

• the name of the host that handles the service presentation

• the port number of the listener for the target database instance on that host

• the system identifier (SID) for the database instance on the host

A typical example of a service name is sess_iiop://localhost:2481:ORCL, where sess_iiop is the service, localhost defaults to the host of the local database, 2481 is the default listener port for IIOP connections, and ORCL is the SID.

For more information about the service name, see "URL Syntax".

Object name

The object name specifies the complete path name of the published object that you want to look up. For example: /test/myServer.

See "The JNDI InitialContext Class" for further information about the lookup() method.

---