EJB design: SOAP VS IIOP
SOAP was developed and drafted by IBM and Microsoft and is supported by Sun Microsystems. http://www.develop.com/soap/
SOAP is an HTTP-XML based protocol that allows applications to communicate easily over the Internet, by using XML documents called SOAP messages. In general SOAP can be used to make a RPC, which is a request made to another machine to run a task.
I would like to get technical opinions from you guys that why one should use SOAP over RPC, JRMP or IIOP.
- SOAP VS IIOP by Gianni Scenini on March 19 2001 19:58 EST
- SOAP VS IIOP by Nick Minutello on March 19 2001 20:18 EST
Frankly speaking, I think SOAP is completely useless in distributed systems.
It is slow, very slow.
I do believe in BINARY system to system communication instead, not a messaging protocol over XML over HTTP.
System to system communication must be compact
(SOAP is not) , fast (SOAP is damn low),
locally optimized (Using SOAP, there is no difference. CORBA/IIOP is 15 time faster locally than SOAP)
SOAP has no standardized transaction and security. ?!?!
You guys have learned nothing from the past, huh ?
There is no messaging semantics, which means the Client and the Server have to agree with the semantic.
Do not get me wrong. I have never talked to the original designers of SOAP.
I do not know what their goals were in designing the SOAP protocol.
If they wanted to create a SIMPLE RPC over http ,
that's ok, perfect!
SOAP is simple, it does not need additional system infrastructures. It uses XML to describe messages, and so on.
Maybe PEOPLE are making the mistake to "over-use" it for everything, trying to replace it with IIOP or other system communication protocols.
See the below URL for SOAP vs IIOP performance comparison
if you are interested
Guess I agree with almost everything you (and others) said, I just don't understand why we should use SOAP for interoperability (other than MS pushing it)?
I'm using CORBA for quite some time now, and it is perfect with DCOM, EJB,... okay, advanced features such as security context, transaction context etc. do not work perfectly all the time, but well, SOAP doesn't even provide these things!
The difference is just: SOAP is slower (much slower), even if IIOP is used over http (using Inprise Visibroker "Gatekeeper"), the reason is XML I think (we again have the "overuse").
Those who know me also know I'm always trying to be unbiased as long as technologies are concerned, but for nearly all (!) uses of SOAP today are so ridiculous I cannot imagine they were thought out by developers!
Especially the MS-paradigm to use SOAP everywhere in distributed systems... we will have a whole new category of speed complaints, where there are "coarse grained objects" now there probably will be a single interface with 21845 lines ;-)
Okay, enough for today, just my 2 cents
I couldn't agree more Bernhard. Still no body justifies it yet.
SOAP vs IIOP happens to be a bit of a pet argument for me (you will see no puns about soap-boxes here)
First things first:
SOAP - the first letter stands for SIMPLE. Simple RPC/messaging is what it is good for. IIOP on the other hand, is good for complex RPC.
Secondly (splitting hairs here):
SOAP is not limited to HTTP - it just so happens that it is one of the popular transports for XML RPC. (well, since HTTP is stateless - it is not strictly RPC is it - its messaging - splitting hairs again)
Well.... it is simple. It is human readable (so what, in my opinion) and it is a very lightweight protocol used for RPC. The reason why it is so light is that it propagates no security context and no transactional context. The other reason why SOAP is attractive is that, if used over HTTP, it can pass freely through firewalls. ALSO, given that Microsoft are pouring effort into SOAP as the interprocess communication medium of choice - SOAP is attractive for Java developers as the possible Holy Grail of Windows / non-windows inter-operability.
Why not SOAP?
Well, pretty much the arguments boil down to the fact that is simple. IIOP supports transactional context and security context.
More than that, IIOP is a binary format for the data. Because SOAP is XML, parsing/marshalling is quite expensive on the CPU. As well as this, because it is an ASCII format, it is also inefficient on the network when transporting large chunks of data (its much fatter). You can run some in-line compression to reduce the network traffic but this hits the CPU again.
I wouldnt use SOAP except for simple external interfaces to my system. I would think very carefully about using it internal to my system. However, for heavy-duty inter-process interaction, I would use either CORBA IIOP or RMI IIOP.
JRMP is an elegant all-java solution. Maybe, because of its distributed garbage collection, it doesnt scale as well as IIOP (DCOM suffers from the same problem) - but I am sure that there will be people that disagree with that. The "pinging" that goes on to implement the distributed garbage collection can result in significant network trafiic when you have millions of objects on your network.
The obvious drawback (well, for some developers) is that it is a java-only solution. Not much help in legacy integration.
The other problem is that (I havent found this out myself) it does not support distributed transactions. This is a show-stopper when transactional integrity is required.
The beauty is its simplicity and for the internals of a Java application (unless you fit into one of the above cases) I would use JRMP...
Now RPC Vs Messaging?
That is another story...
SOAP is a light weight protocol,the major objective of designing such a protocol is for accessing some simple services available on the web which do not require any amount of transaction,security,persistency etc..services which are taken care by IIOP,RPC which are considered as Heavy weight protocols,so the very idea of comparing SOAP VS IIOP is wrong,both of this protocol suites are designed to cater for different purpose.
VenkatRahul can you back up your claim with any simple multi tier web architecture scenario. Why one should invoke a method call through http/xml(design issues.) Isn't it usually a thin client layer responsibility to delegate the RPC calls to back end processes (app servers etc.) Second I totally agree with you that SOAP is lightweight but what about mapping the coming XML method calls to corresponding object method calls. Isn't is redundant to write a SOAP server for this purpose, especially since we already have some well tested methodologies like IIOP, JRMP. Does it really worth it?
SOAP is an excellent protocol , ease of usablity, well defined, uses XML but then as someone pointed out is it goona be fast. the answer is no, simplly because its not a binary protocol.
I think the best use of SOAP is in interoperability, integrating heterogenous web/distributed environments. thats where it has its advantages compared to conventional RPC mechanisms like RPC, DCOM, RMI, IIOP.
but then we are movin in a direction where our distributed applications will be sitting as newly defined web services/interfaces accessible to other systems written in and on a different platform. thats where SAOP will chip in,at the same time one has to keep in mind the security aspect which SOAP clearly misses.