The Web Services Advisor
(Edit your Profile to receive in your inbox.)
Understanding how SOAP works
At the heart of Web services is SOAP (Simple Object Access Protocol), the main communications protocol that enables all the pieces of the architecture to work with one another. In this column, the second part of a series that looks at the protocols underlying Web services, I'll examine the role SOAP plays in Web services, explain how SOAP works, and look at some of the potential pitfalls with the protocol.
How SOAP fits into Web services
First, let's take a look at how SOAP fits into the Web services scheme. We'll start off with a brief refresher about how Web services work. A Web service is a software module hosted by a service provider, that can be run over the Internet. In order for it to be available to others, an XML-based descriptor about the Web service is published to a service registry. Information about the Web service and how to run it is found in the descriptor. When a service requestor (which can be a piece of software) wants to run a Web service, it contacts the service registry. Based on what it finds in the descriptor, the requestor binds to the service provider and runs the Web service.
SOAP is the communications protocol that allows all this to take place. It is used to publish the descriptor into a service registry; to send a service request from a requestor to the registry; to send information from the registry to the requestor; and then to allow the requestor to bind to the service provider and run the Web service. It's safe to say that without SOAP, there could be no Web services.
SOAP is an XML-based protocol - its whole purpose is to send and receive XML information. It was created and championed by Microsoft, and so initially was met with skepticism by those who believed it was the software giant's attempt to hijack a piece of the Internet. But that view has changed, and now it's recognized as a common standard, and its development is guided by the World Wide Web Consortium (W3C), the organization that guides most important Web standards.
Anatomy of a SOAP message
A message sent via SOAP is in XML format, and is made up of three parts - an envelope, a header and a body, as you can see in the nearby figure. The envelope encapsulates the message header and body, and contains a variety of information required for processing the message, including a description of the kind of data to be found inside the envelope, and information about how that data should be processed. It also contains information about the sender and recipient of the message.
SOAP doesn't require that a message contain a header, although as a practical matter, messages will include them when SOAP is used in Web services. Information found in headers can perform a variety of functions, such as providing authentication. The data found in headers is organized into header blocks. There can be one or more blocks in a header.
The body of the message is what actually contains the data. The data might be a request for information - for example, when a service requestor is searching a service registry for a Web service. Or it might be response to a request for information, such as when the registry sends back a service descriptor. The data found in the body is organized into sub-elements. There can be one or more sub-elements in the body.
This all may sound rather abstract, so I'm including an example SOAP message put together by the W3C. The sample message is a request for a travel reservation being sent via SOAP. As you can see, the entire message itself is in XML format, as are all SOAP messages. While you probably won't be able to understand all of what you see, if you take a few minutes to examine it, you'll be able to get a better sense of what each of the elements of a SOAP message do.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:actor="http://www.w3.org/2001/12/soap-envelope/actor/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:actor="http://www.w3.org/2001/12/soap-envelope/actor/next"
env:mustUnderstand="true">
<n:name>John Q. Public</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>
Potential problems with SOAP
The biggest potential pitfall with the protocol is that different SOAP implementations might not work with one another. You rarely will work directly with SOAP itself - instead, you'll work with a SOAP toolkit that creates SOAP messages, or with a Web services toolkit that will create them. Often, these toolkits translate from a language to SOAP - for example, you could use a toolkit to translate COM function calls to SOAP, and a different toolkit to translate JAVA function calls to SOAP. The problem is that each toolkit may implement SOAP differently, and they may not end up working properly with one another.
This will be a particular problem for anyone wanting to develop for both .NET and for Java-based Web services. There may be incompatibilities when dealing with SOAP in those two warring worlds. As just one small example, when it comes to numbers, .NET and Java implementations vary: With .NET you can take numbers out to 29 decimal places, while with Java, you can only go out to 18 decimal places.
If you're developing a Web service, you'll have to work with SOAP, incompatibilities or not. So you'll do well to get started trying various implementations now, so that you're prepared for the workarounds you may be forced to live with.
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at preston@gralla.com.
For More Information
- What do you think about this column? If you'd like to send feedback, you can E-mail the Editor.
- Visit our Best Web Links for Web Services for the best editor-selected resources on the Web.
- Post your technical questions, or help out your peers by answering questions, in our Discussion Forums.
- Ask the Experts! Our Web Services, XML, .NET, Java, EAI, and App Server gurus answer your toughest questions.
