Re: Web Services/SOAP and CORBA

Leo Golubovsky <[email protected]>
Newsgroups gmane.comp.windows.devel.soap.general
Message-ID <[email protected]>
Before I give you my short opnion on the article I would like to state that:
1) I LOVE CORBA and have many years of successful CORBA experience.
2) I have spent quite a bit of time lately working with webServices and
CORBA together.

So back to the article.  I think that article is written in a way that
descriminates against webServices and I think this is a wrong way to write
this type of article.  However, that does not mean that a large chunk of
information in this article is wrong.

1) Performance - Yes if you compare request for request you will pay a price
for using webServices and a big price.  The network utilization and CPU
usage for processing and validating (if you do) these XML messages is
tremendous.  I have seen some numbers in our tests that show 1 to 3 and 1 to
5 times CPU penalty and this is just on the server.

But what you must understand is that in most rational cases you will not
translate every CORBA IDL operation into same WSDL request.  WSDL is more
document oriented.  For better discussion of this go look at IONA webSite.
So for some transactions, this extra cost may not be meaningful.

2) The author is correct that if you code for webServices you would most
probably have some package helping you do that.  So you need some library
for WSDL and ORB.  Of course you can do both by hand, but you got to be
crazy to do that today.

3) Complexity of creating webService has mostly gone away.  What I mean by
that is that most packages today generate Stubs and Skeletons just like for
CORBA.  JAX/RPC to the rescue.  In fact even the  generated structure is
similar.  So instruction for creating CORBA or webServices request is almost
identical.  So I don't agree with the Author here
Unfortunately it is true that generated code is stil in its early stages and
unfortunately, I must say that authors could have learned a lot by looking
at the CORBA standard more closely.  It still has limitations that CORBA
solved many years ago: Exception handling, request manipulation, POA
properties and so on.

On the same subject if developer uses generated stubs, then same static type
checking becomes available in webServices

4) Complexity of the interfaces.  I personally find IDL easier to read than
WSDL - but that may be my personal taste.  In any case there will be tools
that will make both of them equally simple to read any time now.

5) Port 80 overload.  Well yes and no I think.  The advantage of course is
that with minor changes to our existing firewalls and web security engines
we can deal with it relatively easily and probably with minimal additional
cost.  And yes we can change the port - but what difference will that make -
that is not the point here.  (Before all CORBA lovers jump on me here - I
know the standards) Corba still has some security issues that are not
trivial in deployment - just look at the most implementations of the naming
service.  However, security is part of CORBA prootocol if one is willing to
take advantage of it, and it is just now becoming a standard for webServices
(we will see who wins the standars war here)

So as a conclusion:
I beleive that CORBA is one of the best specs produced for distributed
computing, but that does not change the fact that webServices are gaining
popularity and CORBA never really become a technology for cross company
integration.

I do not think that webServices can replace CORBA today in some projects,
but on some projects webServices could be a better fit.  But if you are
smart and understand what is going on, you can do a lot of things with
webServices.  Just don't treat it as solve it all technology - it is not.
If you are looking for fast/real time client server architecture in many
cases webServices IS NOT.

Leo Golubovsky
[email protected]




-----Original Message-----
From: Discussion of implementing SOAP applications today
[mailto:[email protected]]On Behalf Of Pablo Roca
Sent: Friday, August 02, 2002 9:19 PM
To: [email protected]
Subject: Re: [SOAP] Web Services/SOAP and CORBA


Hi,

I see this as a SOAP vs. CORBA, XML vs. CORBA, and the world vs. CORBA
thing (like Frederick says). This guy doesn't have an independient
oppinion, and is much in the CORBA side. Well like me in the SOAP side,
so ...

"Web services have interoperability that resembles CORBA around 1994"
... But Webservice are not here since that 7 years he claimed, let pass
7 years ...

"Now there is another party wanting to travel over port 80: the Web
Services’ HTTP transport". Absolutely not true. You can bound SOAP to
any other port, this is not restricted to port 80. As for the
saturation, I don't see too much, as all things all depends in what are
you sending.

"Various people report that SOAP performance is staggeringly bad and
that the wasted memory and network bandwidth is enormous", also not
agree I see SOAP very lighweight, but oppinions are oppinions.

For the rest of the document is more or less (I tend to think less)
accurate. I wouldn't trust vague comments like "various people" and so
.. This must be demonstrated.

Saludos,

Pablo Roca MS - VFP MVP
La Coruña - España



> -----Mensaje original-----
> De: Discussion of implementing SOAP applications today
> [mailto:[email protected]] En nombre de Will Thomson
> Enviado el: viernes, 02 de agosto de 2002 17:02
> Para: [email protected]
> Asunto: [SOAP] Web Services/SOAP and CORBA
>
>
> Hi SOAP gurús,
>
> I need your comments on this article regarding Web Services
> and SOAP versus CORBA.
>
<http://www.xs4all.nl/~irmen/comp/CORBA%20vs%20SOAP.html>

Is it accurate?

Thanks in advance,


Will

You can read messages from the SOAP archive, unsubscribe from SOAP, or
subscribe to other
DevelopMentor lists at http://discuss.develop.com.

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.