ZCOSNamingClient Design Document

ZCOSNaming is a Zope product which allows embedding CORBA object references within a ZODB. It relies on the Fnorb Python ORB, which must be installed such that Zope's Python can find it (under Shared/Fnorb, most likely).

Background

CORBA at 30,000 Feet

Architecture

The product surfaces these classes to Zope:

NamingServiceRoot

a "connection" object, which holds the data required to construct the initial, "root" NamingContext for a given COSNaming service in persistent storage.

NamingContext

a folderish proxy for the COSNaming class of the same name; caches its CORBA object reference in a volatile member.

ObjectReference

a non-folderish proxy for a given CORBA object; caches its CORBA object reference in a volatile member.

CORBAMethod

holds method name and parameter names/types for a given method (a la SQLMethods?).

Use Cases

• Add a NamingServiceRoot to the ZODB
• Browse the NamingContext hierarchy
• Request an ObjectReference from a NamingContext
• Invoke a generic CORBA method on an ObjectReference
• Add a CORBAMethod to an ObjectReference
• Populate an ObjectReference with CORBAMethods
• Invoke a CORBAMethod on an ObjectReference
• Save an ObjectReference

Issues

• Should the ZODB actually hold (by default, at least) any of the non-root objects?
• If it does, should they store their paths (or could we synthesize them from the containment path?)
• Perhaps the act of "saving" an object reference should be manual, e.g., copy the "transient" object, and paste it into a "persistent" location: the pasted copy would then store its NSR and path.
• How does Requestor signal the method name and parameters to an ObjectReference when making a "generic" request?

1. Manager supplies connection information in one of several forms:
   • IOR string (e.g., as dumped by the NS on startup, or pulled from an environment variable)
   • A URL pointing to a file containing the IOR (UOL in Fnorb's terms) -- NSR will attempt to fetch the IOR, perhaps recursively. May throw
   • Hostname and port number -- NSR will attempt to synthesize an IOR from them. May throw
2. NSR stores the IOR string, but does not construct the object reference.

1a. Invalid URL

the supplied URL (or one of the recursively looked-up URL's) may be invalid.

1b. Invalid hostname

the hostname may be syntactically invalid.

1c. Invalid IOR

the supplied IOR, or the one fetched via URL, may be syntacically invalid.

If no exception is raised, the NSR will possess a well-formed IOR string.

1. BrowsingUser "selects" a NamingContext in the management interface (expanding it in the tree view, or clicking on it in either the tree view or its parent's contents view).
2. NamingContext fetches contained contexts/objects through its object reference, creating a "transient" NamingContext or ObjectReference for each.
3. NamingContext then displays the fetched objects in its "Contents" view.

1a. Start from non-connected NSR

before fetching contents, realize the root NC's object reference from the IOR string.

1b. Start from non-connected, saved NC

before fetching contents, realize the NC's object reference using the saved NSR and path.

1. Requestor provides a "path-like" string representing a retrieval path for a given object to a NamingContext (e.g., foo/bar/baz).
2. NamingContext breaks the string up into a sequence of CosNaming::NameComponents (structs defined by CosNaming.idl) and passes the sequence (a CosNaming::Name) to its proxy's resolve() method.
3. NamingContext returns the resolved object reference to Requestor.

2a. Bad syntax in path string

2b. Start from non-connected, saved NC

before resolving name, realize the NC's object reference using the saved NSR and path.

3a. Unknown name

proxy NC may throw if name cannot be resolved.

1. Requestor makes a normal Zope invocation on an ObjectReference, with method name and parameters stuffed into the REQUEST object (how? what about inout?)
2. ObjectReference somehow picks the method name and the right parameters from the REQUEST and forms a DII request from them. It then invokes the method on its proxy.
3. ObjectReference captures any result value and out/inout parameters from the DII response, and stuffs them into the Zope RESPONSE.

1. Manager supplies method name and a list of parameters (including types).
2. ObjectReference constructs the appropriate ObjectReference and stores it.

1. Manager supplies a reference to a COS Interface Repository.
2. ObjectReference retrieves its method signatures from the IR and constructs CORBAMethod for each one.

1. Requestor makes a normal Zope invocation on a CORBAMethod, with parameter values stuffed into the REQUEST object.
2. CORBAMethod invokes its method on its owner, using the parameter values extracted from the REQUEST.
3. CORBAMethod captures any result value and out/inout parameters from the DII response, and stuffs them into the Zope RESPONSE.

1. Manager selects a "transient" ObjectReference from a NamingContext's contents view and clicks the "Copy" button.
2. Manager then pastes the ObjectReference into a normal folder (pasting not allowed in the "transient" tree under an NSR).
3. The pasted OR stores a reference to its NSR and the path relative to the NSR's root context. It also copies the proxy into a "transient" member.