You are not logged in Log in Join
You are here: Home » Members » Tres Seaver's Zope.org Site » COSNaming Browser » Requirements and Architecture

Log in
Name

Password

 

Requirements and Architecture

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?
Use Case: Add a NamingServiceRoot to the ZODB
  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.
Alternatives
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.
Postcondition

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

Use Case: Browse the NamingContext hierarchy
  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.
Alternatives
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.
Use Case: Request an ObjectReference from a NamingContext
  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.
Alternatives

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.
Use Case: Invoke a generic CORBA method on an ObjectReference
  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.
Use Case: Add a CORBAMethod to an ObjectReference
  1. Manager supplies method name and a list of parameters (including types).
  2. ObjectReference constructs the appropriate ObjectReference and stores it.
Use Case: Populate an ObjectReference with CORBAMethods
  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.
Use Case: Invoke a CORBAMethod on an ObjectReference
  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.
Use Case: Save an ObjectReference
  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.