This week's book giveaway is in the OCP forum. We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests and have Scott Selikoff and Jeanne Boyarsky on-line! See this thread for details.
CORBA is a Distributed Computing solution that is platform and language independent. The CORBA-Firewall spec, if widely adopted, could make SOAP redundant - is that possible? What benefits does SOAP provide? I tried to think of some - a) SOAP can be implemented on HTTP, JMS, Mail etc os it is a high level protocol. It lend itself easily to Async messaging etc. b) It looks easy to implement and therefore is likely to be free or low cost as opposed to CORBA. c) Based on XML and HTTP (primarily) makes it easy to port and implement. d) It is an alternative to IIOP pushed by vendors like (but not limited to) Microsoft who do not generally love IIOP. BUT 1) Some free implementations of CORBA do exist 2) A lot of work has gone into removing. interoperability problems for CORBA which will have to be done for SOAP. 3) CORBA is much faster as the payload is optimized and binary. 4) CORBA is more than just GIOP/IIOP (ie the CORBA protocol that 'competes' with SOAP). There are specs for Quality of Service, policies for adapters, activation etc(to name just a few), making CORBA a platform for 'complete' application development. Before I sign off - It appears strange that Firewall administrators will only open port 80 and that too for HTTP, but happily allow all sorts of traffic (SOAP for eg.) disguised as HTTP through it. If I were to allow SOAP over HTTP I might as well allow IIOP! Thanks m faruqui
SOAP, is just a payload protocol, the underlying transport may vary like you mentioned,, HTTP, JMS, FTP, (may be GIOP in future?).. The idea that makes SOAP more cooler than CORBA is we dont have to worry about stubs/skels ... We send Message or RPC calls across the wire.. so it easy to keep track of what's going on since they are text messages and anybody can read it when they open a tunnel to sniff it... Yes, of course performance will be a big issue .. since we have an additional parsing/intrepration that needs to be done which is not needed in CORBA since all done in binaries...
Hi Raghu, Cient-side stubs are required in all the implementations of SOAP that I have seen. And one can easily have a small utility that converts a GIOP message into Human readable text. Is it worth all the trouble just to avoid this utility! Thanks m faruqui
m farquai It's not that SOAP is just like GIOP/IIOP except it uses port 80. There's a big difference. As many of the posters have tried to point out SOAP is NOT a wire-level protocol. It doesn't use a specific port or set of ports. SOAP is a way of representing data (similar to GIOP) that you can put over any wire-level protocol or higher protocol. For instance: SOAP over HTTP (common, useful for getting around firewalls as you've mentioned. Also common becuase it's available for MS technologies, which CORBA is not) SOAP over JMS (useful for oneway messaging over a MOM infrastructure with reliable asynchronous delivery -- something CORBA can't do) SOAP over SMTP (useful for messaging over an email infrastructure -- a wonderful backup for the above two for program-to-program communication over existing infrastructures where multiple firewalls are involved on each end and speed isn't crucial). SOAP over FTP (see the posts earlier about how this is useful for offline batch-type processing) Also, GIOP is harder to implement on new technologies and languages (maybe Perl, Python, etc.) than SOAP. SOAP just takes an XML parser to implement == GIOP/IIOP requires you to get very heavily down to the bits and bytes level and to be able to create hundreds of little structures at that level; just think of the pain of doing integer (bigend/little-endian) and float (IEEE) conversions alone! Finally, SOAP is just like CORBA in one other respect -- you do NOT have to have client-side Stubs. It's an option but not a necessity. In fact, most SOAP books and articles talk about using the Call interface, which isn't a Stub at all, but is more like CORBA DII. Kyle [ January 09, 2002: Message edited by: Kyle Brown ]
This is a link to a performance study done on SOAP over RMI vs. normal Java RMI. The finding is that SOAP is slower usually by a factor of 10. I like the idea of using and XML based marshalling for discovery and perhaps negotiation then dropping down closer to TCP for session. http://www.extreme.indiana.edu/soap/sc00/paper/index.html [ January 09, 2002: Message edited by: John Harby ]
Kyle, You said "Finally, SOAP is just like CORBA in one other respect -- you do NOT have to have client-side Stubs. It's an option but not a necessity. In fact, most SOAP books and articles talk about using the Call interface, which isn't a Stub at all, but is more like CORBA DII." What is a Call interface? I saw in one implementation (WASP) that the client code does Order order = (Order)lookup.lookup("http://blah..",Order.class); String s1 = order.addItem("acmebean"); My question - is this a reasonable guess: A) Order class is first instantiated. B) Its state is set by getting state related data from the server serialized in XML. BUT when order.addItem is called the method has to executed on the remote (server) object. (One way to do this could be - Let lookup return a subclass of Order that overrides all methods with methods that call the remote object) Thanks, Am really puzzled! m faruqui
Yes, you were looking at a generated client-side Stub. Most Web Services toolkits will generate stubs for you, just like they will in CORBA. In CORBA you generate a stub from CORBA IDL. In Web Services you generate a Stub (usually) from WSDL. However, the way in which the stub works in most of them is that it uses an underlying Call interface. I strongly suggest you go over to http://xml.apache.org and take a look at the Apache SOAP implementation (which most vendors use under the covers). In particular, take a look at the following URL: http://xml.apache.org/soap/docs/index.html Read the section on "Writing RPC Clients". That shows you how to use the Call class directly, which (As I stated earlier) is equivalent to CORBA DII. Or (even better) go buy Steve Graham's book, referenced here: http://www.amazon.com/exec/obidos/ASIN/0672321815//ref=sr_1_74_1/002-8940133-3189661 Kyle
Hi, I noticed the interoperability and the feasibilty that Soap offers us. For the web services structure, from the some tutorial I have read that it is better for the dynamic E-business and the pervasive computing. What I don't understand is: How can soap as the main communication protocol of web service to improve the pervasive computing? (for smart processor, mobile computing)? or where they improve it? --- As the speed of soap is much slower indeed. Thanks. Roy
SCJP 1.4/SCBCD/SCWCD<br />MCSE<br />IBM professional XML Developer<br />SAP certified Development Consultant (NetWeaver portal and Web JavaApplication)
The reason that SOAP and Web Services will work well with Pervasive devices is that the software is smaller. Yes, more data flows on the wire than in CORBA or RMI, but the software required for Web Services is physically smaller than an entire ORB. Kyle