The X-Files

Simple Object Access Protocol (SOAP) Primer

The Star Trek Universal Translator is not as far off as the twenty-third century after all. Since we made first contact with other species, we immediately realized the need to understand their languages. This was by no means an easy task, but thank God we first made progress in the twenty-first century with the advent of the Simple Object Access Protocol (SOAP), which opened the way for the advances that led to the invention of a tool that will help all species understand each other. The Universal Translator. The only good thing about First Contact was that it was with the Vulcans, who just happened to speak English too. But imagine if First Contact was made with the Klingons, or even my Alyssa and Jessica, my one- and two-year-old nieces. We would be sitting across the table just looking at each other, wondering what all that gibberish was about.

This is why SOAP is so important. SOAP is a messaging protocol based on XML for transmitting data across the internet. The current submission of the SOAP standard to the W3C is supported by the following companies: Ariba, Inc., Commerce One, Inc., Compaq Computer Corporation, DevelopMentor, Inc., Hewlett-Packard Company, IBM, IONA Technologies, Lotus Development Corporation, Microsoft Corporation, SAP AG, and UserLand Software, Inc. I would say that is a pretty impressive list, which also means that we have a support base for the future. It is not going to be a fly-by-night technology!

Currently, there are many languages: Visual Basic, C, C++, Java, CGI, COBOL, C#, and so on. Most likely, all of these languages have some pretty clever code that developers would love to use and show other developers. But we can’t share, because we don’t understand the other language. My Visual Basic component does not know how to process CGI instructions. With SOAP, we have an opportunity to write objects in such a way that they can be accessed from any language from any platform. How, you ask? XML-SOAP is an XML-based proposal (submitted to the W3C), which allows developers to package objects in a plain XML format so that they can be understood by any type of object that can understand XML.

So what is the deal with SOAP, and why did they really create it? Initially, the idea was to create a way for distributed applications to communicate over HTTP through corporate firewalls. This idea has grown, creating a whole new way of writing applications that are platform neutral on both the client and the server. Hence the Microsoft term “Web Service.” Web Services are everywhere.

Finally, there is a platform-neutral way of accessing objects and using them in our applications. For example, DCOM is a great technology, but in order for it to work, the platform is Microsoft, or more exactly a Win32 platform. ASP.NET is great too, but what if my component is running on a non-IIS server? How can I expose methods to other applications? Rewrite? Not anymore. With SOAP, we can package our components so that they can be called by anything from anywhere. Another important point is the client side. It seems nowadays everyone is writing applications that are browser based. Do we really need to rewrite our C++ or VB apps to take advantage of the new components we have written for the Web? No, because we can use SOAP from a fat client too.

When I first heard of SOAP, I thought to myself “Another way to write stuff, now I have more to learn, I need more sleep, there are not enough hours in the day to keep track of all this new technology.” Well, once that thought was complete, I decided to investigate further. It really wasn’t that bad. I can leverage my existing knowledge of XML with this new technology and do some pretty cool stuff.

Let’s look at the basic syntax of a SOAP message:

 < SOAP-ENV:Enve1ope     xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/     SOAP-ENV:encodingStyle=     "http://schemas.xmlsoap.org/soap/encoding/">     <SOAP-ENV:Header>        <t:XDeskTrans          xmlns:t="some-URI"        SOAP-ENV:mustUnderstand="l">l        </t:XDeskTrans>     </SOAP-ENV:Header>     <SOAP-ENV:Body>        <m:GetOpenIncident           xmlns:m="Some-URI">              <IncidentID>1001</IncidentID>        </m:GetOpenIncident >    </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

SOAP Message

A SOAP message consists of a SOAP envelope, a SOAP header, and a SOAP body.

SOAP Envelope

The SOAP envelope is a mandatory element in the SOAP message. This is the top element representing the message and optional attributes, which must be qualified by valid namespaces. In the preceding example, we include a reference to a namespace that will understand this message grammar and a namespace that describes the encoding of this message.

SOAP Header

The header is an optional element in the SOAP message and is always the first child element after the SOAP Envelope element. The SOAP header normally defines how a recipient of the SOAP message should process the message.

SOAP Body

The SOAP body is actually the guts of what we need to execute our method calls and to pass any variables to the server that out method call may need. In our example, we are passing the GetOpenIncident method with the IncidentID attribute containing our variable of “1001”. This will instruct the server we are executing this to return the open incidents for the customer who has the ID of 1001.

Now that we have a brief explanation of what a SOAP message is and what all the good parts are, you are probably wondering what this means to you. Well, not much unless you have a tool that can help you use your existing COM components and start using this new SOAP way of executing methods and moving data. Here is where the SOAP Toolkit from Microsoft comes into play.