Notes on Adding a CORBA Interface to Zope

• A quick scan of Fnorb's "orb" package confirms that Fnorb is built around a select reactor, like Medusa's, with an optional thread pool. The SelectReactor class has a couple of methods, handles() and handle_one_event(), which have a comment: "The following two methods are provided to allow Fnorb events to be handled in other event loops." I would guess that adding the Fnorb reactor to Medusa would be a short project -- a "perfect engineering week", perhaps.
• Creating a CORBA object or objects to represent the ZODB is trickier, because the "normal" CORBA scenario involves two distinct passes:
  • Find the object of interest, e.g., by looking it up in the naming or trader services, or by requesting it from an already held reference.
  • Invoke methods on the held reference ad libidum.

  One could make the Zope URL traversal mechanism look like a CosNaming service, where NamingContext objects are "folderish"; the "leaf" object references which it resolved from a sequence of names (like the path elements in a URL) would have to somehow capture the acquisition path, so that subsequent invocation on the object would preserve the correct context.

  I think the likeliest option would be to encode the acquisition path as the object ID in the object reference, and then to use a "default" servant[1] which extracted the path on invocation and then constructs a ZPublisher.Request using that path and the CORBA.Request's method name and parameters. The IOR for a Folder would look something like:

      Type Id       : IDL:org.zope/Zope/Folder:1.0
      Profile       : IIOP
      Host          : www.zope.org
      Port          : 8099
      Object Key    : /Members/tseaver/ZopeCorbaBridge
  

  This strategy allows us to avoid managing the lifetimes of dozens or even thousands of little proxy objects, and fits relatively cleanly into the existing Zope architecture.

• Return values and inout / out parameters are something of an impedance mismatch here -- most of Zope's internal methods, and virtually all user-defined ones, assume that the client expects an HTML response, The ZopeStudio project will likely fix this assumption for us.

[1] For discussion of default servants and their scalability benefits, see Henning and Vinoski's Advanced CORBA Programming with C++, chapter 11.