SOAP (Simple Object Access Protocol)
Since the release I have been fascinated with this thing called SOAP, This bubbly new protocol backed by the power of XML is certainly going to make waves in the world of distributed computing. The first thing which comes into our mind is “Why the heck we didn’t think of this before?”
SOAP was originally developed by Microsoft, IBM, DevelopMentor and Userland Software and was then submitted to the Internet Engineering Task Force (IETF), who eventually made it an official recommendation. Though Microsoft camp seem to have played a major role in defining the specification of SOAP.
The motivation of developing this protocol was the widely used inter-application communication protocols like Microsoft’s DCOM protocol or Java’s RMI or OMG’s IIOP protocols which have till recent times fulfilled the needs of giving component services over an interconnected network .The richness of these protocols helped them gain a strong hold over distributed computing over controlled environment. Almost all these protocols need a smart client able to run the proxies of the server components, moreover, these protocols reveal their limitations when it comes to
INTERNET. Internet cannot guarantee what kind of client and server will be operating at either end of the connection — it can only guarantee that they are both communicating via HTTP.
SOAP (Simple Object Access Protocol) is a simple solution for interaction of different applications built in different languages and running on different platforms as it uses HTTP as its transport and XML as its payload for sending and receiving messages. Its is a lightweight and a loosely coupled protocol for exchange of information in a decentralized and a distributed environment.
What’s so light in SOAP?
Soap relies on HTTP as a transport mechanism to send XML based messages, the messages are packed in what is called a SOAP envelop and send to the server to process in a Request/Response fashion. SOAP unlike proprietary protocols like DCOM or RMI does not require strong connection between client and the server and the SOAP messages are sting based messages passed from the Client to Server and vice versa in the form of SOAP envelops.
What makes SOAP loosely coupled?
Most proprietary protocols require the applications of the same breed to be running on both the ends, what if the server is implemented in a different programming language. The ability to access service of a component in a language/location and platform transparent manner reduces the tight coupling between the client and the server. SOAP enables “incompatible” systems to interoperate.
How does SOAP Message look like and How is it different from a method invoked on a Object?
To demonstrate how SOAP messages are different from method invocation on an component Let’s take a look at this ActiveX component, which accepts two integers and returns the total, as a return value would look something like this,
Server ActiveX Component (MyComponent.MathComponent)
Public Function Add (Num1 as integer, Num2 as integer)
Add = Num1 + Num2
End Function
The Client would create an instance of this component and would invoke the method to get the total.
Sub Button1_click()
Dim objAdd as new MyComponent.MathComponent
Dim intResult as integer
intResult = objAdd.Add(10,20)
end sub
This MyComponent.MathComponent would get instantiated and serve the request from the client application.
At a higher level a SOAP request to fulfill this request would look something like this
<Add>
<Num1>100</Num1>
<Num2>400</Num2>
</Add>
In order to ensure that server can c