Re: CORBA vs. XML (was: Re: XML.COM: How I Learned to Love daBomb)

[David Brownell <david-b@pacbell.net>]

> > Obviously, using XML makes it human readable; but I think the biggest
> > difference is that the latter two are merely method invocation (and that's
> > *easy*); while CORBA implements "remote objects", and the horror
> > of issues like
> > maintaining state, remote memory management etc and so on.
> >
> > Have I got that right?
> 
> No, Corba does just do method invocation.

Wrong; that's one mechanism within the architecture.  Normally
implemented using IIOP, but potentially also using some sort
of SOAP profile.  Brendan had it right, except that managing
state is an application's responsibility (though one can argue
about shared responsibilities during object activation).

The most fundamental part of CORBA is the object model,
as visible through IDL.  That's what'd need to be captured in
such a SOAP profile.  The CORBA-to-COM interop issues
can briefly be summarized as:  OMG-IDL is not the same
as MSFT-IDL (or DCE-IDL).  There are some issues with
object lifecycle that don't show up in IDL, too.


>     The ORB itself can do other
> complex stuff like implementing persistent objects and so on, but then
> it's more of an object database with an ORB interface :-)

But the ORB is fundamental to the Common ORB Architecture
("CORBA").  Admittedly the 1.0 requirements to activate
persistent objects was troublesome, since for some reason nobody
was keen on standardizing activation as a clean layer on top of
a transient object infrastructure.  (That's how it's implemented in
all cases.)  I understand that's fixed at last by stuff like "POA",
though of course it doesn't really show up at the protocol level
(that is, IIOP).

- Dave