GEP 5: New Object Adaptor for ORBit2

[Mark McLoughlin <mark skynet ie>]

Hi Guys,
	I've just added GEP-5 to CVS. In essence the proposal is for a
GObject based Object Adaptor based on a cut down version of the POA.
The big advantage of this is that it makes implementing CORBA Objects
a doddle for anyone who is used to GObject.

	Discussion should take place one gnome-components-list and
orbit-list, and input would be very, very welcome indeed.

	Oh, there's also a prototype implementation on the
gobject-adaptor branch of ORBit2 if anyone is interested.

Cheers,
Mark.


   ORBit2's Object Adaptor doesn't suit GNOME's needs very well. This GEP
   sets out the requirements for a replacement.

                               1. Administrivia

   Document Owner
          Mark McLoughlin

   Posted
          September 05, 2002

   Discussion Period Ends
          October 05, 2002

   Status
          Pending

   Discussion List
          orbit-list@gnome.org, gnome-components-list@gnome.org

   Responsible Persons
          Mark McLoughlin, Michael Meeks, Elliot Lee

                            2. Overview of the POA

2.1 What is the POA?

   An Object Adaptor is the primary way an object implementation accesses
   the services provided by the ORB core. Because CORBA is intended to be
   used  for  a  variety  of  different kind of objects, different Object
   Adaptors  with  interfaces  that  target specific types of objects are
   explicitly allowed for in the CORBA specification.

   An Object Adaptor provides the following services:
     * creating and parsing object references,
     * routing incoming requests to a method invocation,
     * object and implementation activation and deactivation,
     * mapping an object reference to an object implementation and
     * registration of object implementations.

   ORBit2  currently  only  implements  the  POA  interface  which is the
   default   Object   Adaptor   since  the  2.2  revision  of  the  CORBA
   specification.  The intent behind this adaptor is that the services it
   exposes  should  be  broad  enough to be suitable for use with a broad
   range  of object types and straight forward enough so that it could be
   implemented  on top of any ORB core, thus guaranteeing a usable Object
   Adaptor interface on whose portability can be relied upon.

2.2 Large Feature Set

   However,  GNOME's  usage  of  the POA interface has been very limited.
   GNOME has neglected to find a use case for many POA features:
     * POA  hierarchy:  there  can be more than one instance of a POA per
       ORB,  and  these  POAs organised in a familiar tree-like hierarchy
       with a defined POA as the root of this hierarchy, the RootPOA.
     * POA  policies:  the  POA's  behaviour  is  controlled  by a set of
       policies. GNOME currently only uses the default policy values. For
       example  GNOME  has  never found the need for explicitly assigning
       ObjectIds and hence uses the SYSTEM_ID policy.
     * Persistent  object  references:  it  is  possible  with the POA to
       create an object reference that is valid across ORB lifespans.
     * ServantManagers:   ServantManagers  may  be  used  to  dynamically
       activate an object unknown to the ORB when a request is received.
     * AdaptorActivators: similarly to ServantManagers, these can be used
       to activate new child POAs on demand.
     * POAManagers states: a POA can be put into different states so that
       incoming  requests  may be queued or discarded. GNOME applications
       all move the POA into an active state as soon as it is created.

   It  should  be  clear  from  the  above  list that the POA is far more
   complex  than  is necessary for GNOME's needs. The maintenance burden,
   runtime  performance  hit and general lack of understanding of the POA
   are all significant problems for GNOME.

2.3 Object Implementation in C

   Another inconvenience of the POA for the GNOME developer is that the C
   language  mapping  of  the 'Servant' native type is extremely unwieldy
   when  one is used to the object orientated development using the GNOME
   type system, GObject. Indeed, the specification itself leaves a lot to
   be desired and many points need clarification.

   Much  of  the complexity of the Servant mapping seems to come from the
   need  to  support  multiple inheritance. However, multiple inheritance
   has   been  abandoned  by  GNOME  in  favour  of  the  aggregation  of
   interfaces.

   In  libbonobo, much of the complexity of the Servant mapping is hidden
   by  BonoboObject and developers are able to implement CORBA objects in
   a  familiar  fashion  by  deriving from GObject. The implementation of
   this,  however,  is  a kludge to get around the inherent problems with
   the Servant mapping and does pose a significant maintenance burden.

                                  3. Proposal

3.2 GObject Based Servant

   With the new adaptor, it should be possible to implement CORBA Objects
   using  the  GObject  model.  A  new  Servant type, which, derives from
   GObject  should  be  the  base  class for all implementations of CORBA
   objects under this model.

   Note,  that this implicitly means that multiple inheritance should not
   be  supported. This is already the case with BonoboObject and it seems
   that multiple inheritance is not used elsewhere in GNOME.

   In order to avoid possible misunderstanding, it is important to stress
   that  this  requirement is not that all GObjects should be exposed via
   CORBA  - so this requirement is not advocating the manipulation of the
   entire gtk+ widget set out-of-process using CORBA :-)

3.3 Slimline Interface

   The  adaptor's  interface should be much less rich in features and its
   behaviour should be similar to the default behaviour of the POA.

   Only three operations on the adaptor is likely to be needed:
    1. Adaptor destruction,
    2. Creation of an object reference,
    3. Mapping an object reference to an object implementation.

3.4 Ease of Implementation of Interfaces

   It  should  be as straightforward as possible for a GNOME developer to
   implement  a  CORBA  object.  Allowing CORBA objects to be implemented
   using  GObject  certainly  helps  meet  that  requirement, but as much
   additional  effort  as  possible  should  be  put in place to ease the
   development  burden.  For example, it may be judged useful for the IDL
   compiler  to  output  a  skeletal  implementation  of  the  object  if
   requested.

3.5 Comparable Performance

   The  new adaptor should not introduce any performance regressions over
   the  POA.  Indeed  it  is hoped that that the new adaptor will compare
   very favourably with the POA.

3.5 Integration With Bonobo

   It  should  be straightforward to integrate the adaptor with libbonbo.
   It  is  imagined  that  if  BonoboObject  is implemented using the new
   adaptor,  it will become only an implementation of the Bonobo::Unknown
   interface.  For  backward compatibility reasons another name change is
   likely to be needed. Perhaps BonoboUnknown may be appropriate?

3.6 Continued Use of the POA

   The  implementation of the new adaptor, should not impact existing any
   applications  use  of  the  POA.  It  should  be  possible to use both
   adaptors side by side.

3.7 A Decent Name

   The adaptor and servant types would benefit from less sappy names than
   ORBit::GOA and ORBit::GServant. Suggestions are welcome :-)

3.8 Other Requirements Worth Consideration

     * Support  for  Controlling Method Re-entrancy: perhaps a per-method
       flag to indicate that the method should not be allowed to re-enter
       would suffice?
     * Threading  Support:  it  may be good to make this a requirement of
       the  new  adaptor.  One  could  choose  to have the adaptor invoke
       methods  on  either  a  one-thread-per-app, one-thread-per-object,
       one-thread-per-interface or one-thread-per-invocation basis?
     * Persistent  References:  although  these  have  never been used in
       GNOME before, interest has been expressed in them. However, adding
       support for these would add significant complexity to the adaptor.
     * Hooks:  it  may be nice to allow the developer to add hooks to the
       invocation  request processing engine on a per-servant basis. e.g.
       "pre-invoke"   and  "post-invoke"  signals  on  the  servant.  The
       emission  of  these  signals  would  be  on the critical code path
       however, so this may not be wise.
     * Agregation:  using  GObject's GTypeInterface it may be possible to
       provide a form of aggregation in the adaptor. Would this be wise?

                      4. Issues Raised During Discussion

   None as yet.

                           5. Decision and Rationale

   None as yet.

References