I am new to soap technology and while reading an article on it , i am confused that Is there some SOAP Engine required to execute my remote business methods?
What I understand is that there is client who send some request to some remote business method , that business method executed (Confused where it is executed...need some SOAP engine or anything extra) and then response sent to client.
So if anybody can clarify me this point.If some sought of engine is required could you tell me regarding it.
Secondly , what's use of SOAP Technology when i can call method using CORBA Client.
That is a conspiracy by the vested interests who want you to wash your hands off CORBA etc and use their technology asap:)
U need SOAP engine to execute SOAP requests on the server side ... You can get one from http://xml.apache.org/soap
The advantage of SOAP is u can talk to SOAP server over HTTP, HTTPS protocols. It uses XML for its communication between client and the server. Read the documentation thats available with the SOAP installation from Apache SOAP.
The advanatages are:
The communication between Client and the server uses XML.
XML being the plain text, the overhead of data transfer over network is very less compared to binary data.
Since it uses HTTP protocol, the FireWall restrictions are not there.
If u use CORBA, the communication is through the serialaized stubs/skeletons, which is binary and more over head on the network, and too much of computation at botht the server and clinet (marshalling/demarshalling etc).
CORBA uses a different port , aso firewall problems ...
Conclusion in two lines is: SOAP and CORBA have their own application areas. None is better over other. To understand in more detail, read further.
SOAP is about communicating with server side components via request/response messages (I repeat messages and not method invocations). These request/response messages are nothing but XML messages packaged into SOAP envelopes. So finally SOAP envelopes are passed to and fro to enable this request/response based communication. This mechanism has both pros and cons.
Pros: Communication takes place through XML, thus no dependencies on platform/language. This makes SOAP an extremely good candidate to act as glue for carrying out communications between component based applications. So if architectural problem is to identify a solution for making two disparate services talk to each other, putting SOAP wrappers around these disparate services and making them communicate and collaborate (probably), can be a solution here.
Cons: SOAP uses XML as communication protocol and TCP as transport protocol. XML is plain text. Meaning it is not compressed. It generates a good amount of network traffic if sent across the wire *as is*. However, there are some compression utilities available that can minimize the traffic created by marshalling XML on the wire. Also dont forget overhead involved in parsing XML at either end. Third and biggest challenge SOAP faces is how to propagate transactions and security contexts required for supporting sophisticated protocols such as 2PC and CSIv2. This is a challenge that industry is still trying to address through standards such as XLANG/XAML/XACL/etc. However, they are not out yet. I do understand that SOAP is supposed to be "simple", however with simplicity there is always a certain sophistication at loss. So bottom line is: SOAP is not *the* communication protocol between objects. It should be used judiciously with complete understanding of its pros and cons.
Let us try to understand CORBA/EJB/DCOM/etc. as compared to SOAP. All these technologies provide deployment/communication framework for components alongwith highly sophisticated QoS such as transactions/security/persistence/etc. They enable communication between objects/components/services via invocation. Also they represent method invocation data on wire as binary (which is definitely compact), thus making invocations extremely fast and efficient.
However, using this solution may result into two limitations. One, you may not be able to expose these objects/components/services to the web directly since your firewall would not allow this (This is because ports used by DCOM/IIOP/JRMP are non-standard and so firewalls by default would block traffic to these ports unless you keep the ports open (crazy thing to do!) or you do some tunneling). Second limitation can result from compatible endpoint protocol stack requirement, that these kind of frameworks impose. This turns out to be a limitation when you have to provide services that spans over heterogenous systems.
Hope this helps,
Thanks for response given against my query.
I find all these to be very informative.Rema's way of explaining query change way of thinking about soap....As iam new to this technology this all information is very useful to me.
But i have a doubt on following line:
**SOAP is about communicating with server side components via request/response messages(I repeat messages and not method invocations).**
Infact, Every Component based technologgy do same--sent parameter(messages may be in form of objects), underlying engine exe. method and response is send.
This is what is happening in soap also but in platform independent way( keeping in mind the pros/cons).
So above line is applicable to every component based technology.
(correct me if iam wrong)
i guess soap is an http/https based protocal , its more or less towards communication of data . Whereas as component tech are to deal with communication to data and services.
let me know if this answers ur questions