SOAP protocol

SOAP is a protocol for accessing a Web Service. SOAP is a simple XML-based protocol to let applications exchange information over HTTP. SOAP is designed to be a new protocol for the decentralized, distributed environment, which utilises the power of the Internet and XML to pass typed information between nodes. Originally, SOAP stood for Simple Object Access Protocol, but was later changed simply to SOAP with version 1.2, because it did not directly use Objects. SOAP is a light weight protocol that is platform independent, transport independent and operating system independent.

There are two types of SOAP requests. The first is the Remote Procedure Call (RPC) style request similar to other distributed architectures. This is usually synchronous; the client sends a message and waits to get a response or fault message back from the server. The second type of SOAP request is the document request. In this case, a full XML document is passed to/from the client and server, in side a SOAP message.

RPC

SOAP-RPC is an implementation of a Remote Procedure Call (RPC). In this case, a function on a remote machine is called as if it were a local function. All of the marshalling and unmarshalling of data is handled by SOAP and is performed in XML. RPC-style web services are tightly coupled and interface-driven. The clients invoke the web service by sending parameters and receiving return values. RPC-style web services follow call/response semantics; therefore, they are usually synchronous, which means that the client sends the request and waits for the response until the request is processed completely.


Document

With a document style message the client and/or server passes an XML document as the body of the SOAP message instead of parameters. An example of this is an invoice. The document is marked-up with both XML and a schema, which is common to both the sender and receiver. The sender is the consumer, which makes a function call to the web service with some parameters, and in return the vendor sends back, not data results, but an XML document that contains all of the information that a normal invoice would have, the difference being that it is marked-up with XML, and is machine-readable. Document style messaging has other advantages over a remote procedure call, which is meant to be relatively static, and any changes to the RPC interface would break the contract between the service and the application. Changing the RPC description would cause all of the applications that rely on a specific method signature of SOAP-RPC to break. Good design dictates that the method signature of an RPC message service should never change. With document messaging, the rules are less rigid and many enhancements and changes can be made to the XML schema without breaking the calling application, because what is sent is an XML document rather than a structured return value. Web service applications should be able to use a guaranteed delivery mechanism to improve its reliability, scalability, and performance. Since a document message is usually a self contained XML file, it is better suited for asynchronous processing and can be placed directly into the queue. The reliability of the application is improved because the message queue guarantees the delivery of the message even if the target application is not currently active, performance is improved because the web application simply delivers the document to a queue and is then free to perform other tasks, and scalability is improved because the document is offloaded to one or more instances of an application that handles its processing.

Applications of SOAP

• Business to Business integration : SOAP allows businesses to develop their applications, and then make those applications available to other companies.
• Distributed applications : Programs like databases could be stored on one server and accessed and managed by clients across the Internet.

One thing when we think of going for SOAP on our business server is that there are many other ways to do the same thing that SOAP does. But the most important advantage you would get by going for SOAP is that its not constrained by application language(Java, C#, C++, Perl or any other language) or the platform (Windows, Unix, Mac), and this makes it much more versatile than other solutions.


Lets go little deep into SOAP. As we know SOAP does not use objects. To pass anything besides the basic data types in Java to the web service, you must write your own Serialize and Deserialize functions. These are functions written that convert a class or object into XML and back. So it is true that SOAP does not pass objects, but instead passes representations of the data in the objects, so that it can be used to create new objects. Apache SOAP comes with a built-in serialization class called BeanSerializer. This class can take a Java Bean and automatically serialize and deserialize it.