GCOM, was Re: Communicating with MICO

[Samuel A. Falvo II]

In article <87mb8g$tlr$1 at pineapple.uk.research.att.com>, Duncan Grisby wrote:
>I'm happy to talk about omniORBpy and all things CORBA. From your
>description of GCOM, it sounds just like a CORBA ORB. In what way is
>it a COM implementation?  Do you intend to interoperate with COM /
>DCOM, or just follow some of the design?

The run-time environment is all COM, right down to every object supporting
IUnknown methods.  It's v-table based, just like COM, and exhibits a
registry (the interface to which is highly unstable; software which uses the
registry API in 0.1/0.2 will likely break in 0.3).  The registry currently
serves the purpose of the implementation repository in CORBA; however, it's
accessed via the GCOM library, and not by CORBA objects.

However, I was going to use GIOP to communicate between local servers.  The
Service Control Manager would be responsible for maintaining the local
servers, and would sit on a well-known socket (/com/scm most likely).  I was
going to implement an OMG IDL compiler which produced proxies and stubs
which conformed to the GIOP protocol.  Note that the SCM itself is not an
ORB, in that it doesn't sit on a socket and dispatch GIOP messages (except
those directed to the SCM itself).  All the SCM does is it provides a
rendezvous service between client and server.  Once the client has the
server's socket, the SCM leaves the picture (except to maintain the server's
lifetime).

Requests via IIOP would be accepted through a real ORB component; this ORB
component would act as a router for the SCM.  Any servers the SCM cannot
locate is "broadcast" to all registered ORBs (causing the ORBs to be loaded
as needed), causing service request queries on remote machines.  (This is
all done as part of CoGetClassFactory() ).  Activation of objects from
remote hasn't been addressed yet, but will likely involve manually running
an ORB as a daemon.

However, in an epiphany (<-- is that the right word?), I realized just what
you wrote above: it would be a glorified CORBA ORB.  So I figured, if I
relaxed the requirement that all interfaces be inherited from IUnknown, they
become plain-vanilla C++-type objects.  All that's needed is a stub that can
map a method _name_ to a method's function pointer.

So the "sluggishness" that CORBA has amassed a reputation for is not the
fault of the spec, but of the individual ORB and B/POA APIs.  However, the
APIs do add an unnecessary layer of complication to the development of any
standards-compliant ORB.  And 2.3 just makes things worse.

Right now, I don't have time to develop for GCOM, though if someone needs a
quick bug-fix or whatnot, I can do that.  My research into, and the
development of, GCOM has given me the tools necessary to take advantage of
existing CORBA ORBs.  But make no mistake about it -- the existing C/C++
mappings are absolutely and unnecessarily complicated.

A future direction for GCOM is to merge the two technologies -- first, to
relax the requirement that _all_ GCOM objects inherit from IUnknown (as is
the case with COM), thus allowing greater interoperability with CORBA
objects outside the GCOM realm, and second, to eschew the CORBA API
specifications, and use my own mappings and APIs, which concentrate on ease
of software development, ease of debugging, and a more orthogonal API (e.g.,
stripping away nearly all the redundency that's currently present in the
CORBA mappings).  I will likely retain the use of object->vtbl->method()
notation for C software.  There's no reason to switch, and it's fully binary
compatible with C++, which is an added benefit.

-- 
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA