Introduction to SOAP
What is Soap?
Soap stands for Simple Object Access Protocol. After reading this article I hope to leave you with the million dollar question, "What's with the doofy name?"
Soap, in its current form, is a method for RPC (Remote Procedure Calls) over a network. (Yes, it is also used a way to transfer documents around as XML, but I'll leave that out for now)
Let me explain. Imagine you have this service that would return a stock quote
given a stock symbol. It sends some data to the Nasdaq
web page and scrapes the
returned HTML to give you the result. Now, to allow other developers to use it inside of their
applications, you might make this into a component that uses the Internet to access
the quote information. Works great, except suddenly Nasdaq changed their web page layout. You're going
to have to redo all the logic and send an update to every single developer that used your component!
And they have update all THEIR users. If this happens with any regularity, you're going to
get some really furious developers. And we all know how dangerous developers can be. You don't want to end up with
a printout of a horse's head in your bed, do you?
What this paper is about...
Soap and XML
In order to make SOAP not so simple for you and I, we need to add XML. So instead of a function name and parameters, we now need to have a complicated XML envelope that is designed to confuse you. But don't get scared yet. There's more, and you should see the full picture before you start thinking this is complicated. (It is.)
If you don't know what XML is, stop right here and read my paper on XML at http://www.agnisoft.com/white_papers/xml_delphi.asp.
All Soap packets are formatted as XML. What does this mean? Let's see. Take a look at this function: (Pascal)
Looks great, but the problem is - it's Pascal. How does a Java programmer benefit by giving this seemingly simple definition? Or someone who works on VB? We need something everyone can understand, even VB users. So we give them XML containing the same information (parameters, stock quote values etc You create a SOAP "envelope" - which is basically your function call, wrapped as XML so that any application on any platform can understand it. Let's now see a SOAP call looks like:
How informative! We see here that SOAP is getting more and more simple. Well, that was the fun part. Now I'm going to tell you how to understand this soap call, because, well, because you're reading this and I'm writing this and I can pretty well write what I want to.
The Tags Revealed
The first "tag" you see is the <SOAP-ENV:Envelope ... > tag. This tag is an outer shell to the SOAP packet, giving you various namespace declarations you don't care about, but your average programming language or parser does. The namespaces are defined so that further "prefixes" to tags such as "SOAP-ENV:" or "xsd:" make sense to a parser.
The next tag is <SOAP-ENV:Body> . (We've skipped a tag that is not shown here - the <SOAP-ENV:Header> tag. It's not in this particular Soap envelope, but if you want to read more about it, go to the SOAP specification at http://www.w3.org/TR/SOAP/) The <SOAP-ENV:Body> tag is a placeholder that starts off the actual SOAP call.
Coming next is the <ns1:GetStockQuote ...> tag. The tag name, GetStockQuote, is the function to be called. In Soap lingo, this is called an operation. So GetStockQuote is the operation that needs to be executed. ns1 is a namespace, which points to urn:xmethods-quotes in this case.
A small note about namespaces: A namespace is a way to qualify an XML tag - for instance you cannot have two variables with the same name in one procedure, but it's ok if they're in two different procedures. So the procedure is a "namespace" - all names are unique within it. Similarly, XML tags can be scoped inside namespaces, so that, given a namespace and a tag name, you can uniquely identify and find a tag. We will point a namespace to a URI (Uniform Resource Identifier), in order to make sure that "my NS1 is not the same as yours". In our example above, NS1 is the alias for a namespace which points to urn:xmethods-quotes.
You'll also notice an encodingStyle attribute - this attribute specifies how a soap call is serialized. Within the <GetStockQuote> tag lie the parameters. In our simple case, we only have one parameter. Which is the <symbol> tag. You'll notice that there's this extra little thing next to the tag :
This is approximately how XML defines types. (Note the clever use of the word "approximately" when making a absurdly general statement about a technology that might mutate the minute I put this paper on the web) What this particular statement means is: the type, as defined in the xsi namespace, which you would have noticed is declared in the <SOAP-ENV:Envelope> tag, is xsd:string. Which in turn is a string, as defined in the xsd namespace, again defined earlier. (I'm sure Lawyers love this stuff)
Inside of the <symbol> tag there's the boring little "IBM". This is the value of the parameter symbol to the GetStockQuote function.
Beyond this, like good people, we close our XML tags.
That's about the SOAP packet, which defines a "call" to a SOAP server. The soap server, using the support of complex XML parsers, nuclear missiles and the mir space station, decodes the call and figures that you want to get a stock quote. It then quickly fetches the stock quote and sends you back a packet like so:
This, after removing all the envelopes, the gift-wrap and the embellishments, simply tells you that the price of the IBM stock was 34.5.
Most commercial servers would return a LOT more information than just that, of course, like in what currency, last traded price etc. And would perhaps return a more accurate value of the IBM stock.
So we now know what a soap server expects, and what to send back. Now HOW do we send such information? You could use any transport. The most well discussed case is HTTP. I'm not going to explain what that is, except it's what your web browser uses to communicate with those web sites you go to.
You would make an HTTP request such as:
The only other point of significance here is the SoapAction header. This header indicates the intent of a request, and it is mandatory. Each SOAP server could have multiple functions, and it could decide to use the SoapAction header to figure out which function is being called. Also, firewalls and server multiplexers can filter content using this header.
The soap response from the HTTP server will be as follows:
Why HTTP? For one, network administrators do not have to worry about opening separate ports for SOAP calls...a web server would do the job, and port 80 is usually opened to the world to handle incoming web requests. The other advantage is that web servers are usually extensible using CGI, ISAPI or other native modules. This extensibility allows us to write a module that will handle a SOAP request, while not affecting any other web content.
That's all for now, folks
This, I hope, has been a reasonably understandable description of SOAP. If you're still here, and want to know more, we'll have some more articles on Soap, WSDL and other such four letter words coming up soon.
Has this page been helpful to you? Suggestions? Comments?
Let us know!
Links: (all links open in new windows)
Copyright © 2000-2001 Agni Software Private Limited