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.