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

[Joshua Allen <joshuaa@microsoft.com>]

If I am interpreting your message correctly, you are saying something
like "why on earth would anyone want to program directly against
distributed objects over a WAN?"

The answer is generally that they wouldn't.  For example, nobody
manipulates the properties and methods of a Circle object from a remote
handheld.  And if you *did* expose a rich object model like that,
chances are you would not trust the people on the other side of the WAN
to mess with it anyway.  SOAP is just a message format, and doesn't
bother with things like maintaining object references and so on.  I
think of it as the way that the request gets shipped in to a service
that might be built atop COM+, EJB, CORBA (or anything else).



-----Original Message-----
From: Manoj Dhooria [mailto:manojd@geometricsoftware.com] 
Sent: Monday, August 20, 2001 5:53 AM
To: Joshua Allen; Brendan Macmillan; xml-dev
Subject: RE: CORBA vs. XML (was: Re: XML.COM: How I Learned to Love
daBomb)

SOAP-based CORBA/COM bridge over WAN (or were you talking only about LAN
-
in which case, my apologies for this message) - very interesting, but
did
you wonder about performance & coupling issues for an application built
over
it:

a) Programmers want to access objects at the lowest granularity that
makes
sense to application. If I have a circle object, I want access
granularity
to be so low to let me query the radius or center individually. I don't
know
how the caching techniques of generic systems like COM are going to help
you. You nearly always will want domain specific caching - means you
want to
control the granularity of the data moving over the IP network, as well
as
triggers to refresh/fill-in the specific cache elements.

b) Client "forgets" to release an object interface at server! As an
application programmer, I want complete control over the client/server
coupling. I am not aware of a way to do it in COM. And common sense
tells me
I am unlikely to find it in CORBA & EJB too - or am I wrong?

May be SOAP helps you make these object models interoperate over LAN.
But
forget about any substantial services that use them over WAN.

Manoj Dhooria
Geometric Software, Bombay

-----Original Message-----
From: Joshua Allen [mailto:joshuaa@microsoft.com]
Sent: Sunday, August 19, 2001 10:05 AM
To: Brendan Macmillan; xml-dev
Subject: RE: CORBA vs. XML (was: Re: XML.COM: How I Learned to Love
daBomb)


>Has anyone published a point-by-point comparison between CORBA and
>SOAP/XML-RPC?

You could probably consider SOAP and CORBA as complimentary.  SOAP to
IIOP might be a better comparison.  The three "big" object server models
out there have been CORBA, EJB, and COM+ -- these three use IIOP, RMI,
and DCOM respectively as the primary method to pass information to and
from objects.  Now that SOAP is on the scene; CORBA, EJB and COM+ don't
go away, they just have another way to pass information to and from
objects.  In fact, before SOAP, there were many ways to get these three
different worlds to interoperate -- the difference with SOAP is that the
interop layer is based on XML, supposedly easier to implement than
something like an RMI/DCOM bridge, and so on.  For example, if I have
some objects written in CORBA that provide some service, I no longer
have to convince all of my customers to install an IIOP communication
layer.  With SOAP, the layer that calls my CORBA object could be as
simple as a UNIX bash script that pipes some text through netcat.  So I
think of SOAP as being a universal IIOP/RMI/DCOM substitute that mere
mortals can type by hand.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>