The SOAP Protocol
- SOAP
- Doing Business with SkatesTown
- Inventory Check Web Service
- A Closer Look at SOAP
- The SOAP Messaging Framework
- SOAP Intermediaries
- The SOAP Body
- The SOAP Processing Model
- Versioning in SOAP
- Processing Headers and Bodies
- Faults: Error Handling in SOAP
- Objects in XML: The SOAP Data Model
- The SOAP RPC Conventions
- XML, Straight Up: Document-Style SOAP
- When to Use Which Style
- The Transport Binding Framework
- Using SOAP to Send Binary Data
- Small-Scale SOAP, Big-Time SOAP
- Summary
- Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Web services Architecture group at the W3C has defined a Web service as follows (italics added):
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
Although our definition (see Chapter 1, "Web Services Overview and Service-Oriented Architectures") may be a bit broader, it's clear that SOAP is at the core of any survey of Web service technology. So just what is SOAP, and why is it often considered the harbinger of a new world of interoperable systems?
The trouble with SOAP is that it's so simple and so flexible that it can be used in many different ways to fit the needs of different Web service scenarios. This is both a blessing and a curse. It's a blessing because chances are, SOAP can fit your needs. It's a curse because you may not know how to make it do what you require. When you're through with this chapter, you'll know not only how to use SOAP straight out of the box but also how to extend SOAP to support your diverse and changing needs. You'll have also followed the development of a meaningful e-commerce Web service for our favorite company, SkatesTown. Last but not least, you'll be ready to handle the rest of the book and climb higher toward the top of the Web services interoperability stack.
The chapter will cover the following topics:
-
The evolution of XML protocols and the history and motivation behind SOAP's creation
-
The SOAP messaging framework: versioning, the extensibility framework, header-based vertical extensibility, intermediary-based horizontal extensibility, error handling, and bindings to multiple transport protocols
-
The various mechanisms for packaging information in SOAP messages, including SOAP's own data encoding rules and heuristics for putting just about any kind of data in SOAP messages
-
The use of SOAP within multiple distributed system architectures such as RPC- and messaging-based systems in all their flavors
-
A quick introduction to building and consuming Web services using the Java-based Apache Axis Web services engine
So, why SOAP? As this chapter will show, SOAP is simple, flexible, and highly extensible. Since it's XML based, SOAP is programming-language, platform, and hardware neutral. What better choice for the XML protocol that's the foundation of Web services? To prove this point, let's start the chapter by looking at some of the earlier work that inspired SOAP.
SOAP
Microsoft started thinking about XML-based distributed computing in 1997. The goal was to enable applications to communicate via Remote Procedure Calls (RPCs) using a simple network of standard data types on top of XML/HTTP. DevelopMentor (a long-standing Microsoft ally) and Userland (a company that saw the Web as a great publishing platform) joined the discussions. The name SOAP was coined in early 1998.
Things moved forward, but as the group tried to involve wider circles within Microsoft, politics stepped in and the process stalled. The DCOM camp at the company disliked the idea of SOAP and believed that Microsoft should use its dominant position in the market to push the DCOM wire protocol via some form of HTTP tunneling instead of pursuing XML. Some XML-focused folks at Microsoft believed that the SOAP idea was good but had come too early. Perhaps they were looking for some of the advanced facilities that could be provided by XML Schema and Namespaces. Frustrated by the deadlock, Userland went public with a version of the spec published as XML-RPC in the summer of 1998.
In 1999, as Microsoft was working on its version of XML Schema (XML Data) and adding support for namespaces in its XML products, the idea of SOAP gained momentum. It was still an XML-based RPC mechanism, however, which is why it met with resistance from the BizTalk (http://www.biztalk.org) team; the BizTalk model was based more on messaging than RPCs. SOAP 0.9 appeared for public review on September 13, 1999. It was submitted to the IETF as an Internet public draft. With few changes, in December 1999, SOAP 1.0 came to life.
Right before the XTech conference in March 2000, the W3C announced that it was looking into starting an activity in the area of XML protocols. At the conference, there was an exciting breakout session in which a number of industry visionaries argued the finer points of what XML protocols should do and where they were going—but this conversation didn't result in one solid vision of the future.
On May 8, 2000 SOAP 1.1 was submitted as a note to the W3C with IBM as a co-author. IBM's support was an unexpected and refreshing change. In addition, the SOAP 1.1 spec was much more modular and extensible, eliminating some concerns that backing SOAP implied backing a Microsoft proprietary technology. This, and the fact that IBM immediately released a Java SOAP implementation that was subsequently donated to the Apache XML Project (http://xml.apache.org) for open source development, convinced even the greatest skeptics that SOAP was something to pay attention to. Sun voiced support for SOAP and started work on integrating Web services into the J2EE platform. Not long after, many vendors and open source projects began working on Web service implementations.
In September 2000, the XML Protocol working group at the W3C was formed to design the XML protocol that was to become the core of XML-based distributed computing in the years to come. The group started with SOAP 1.1 as a foundation and produced the first working draft. After many months of changes, improvements, and difficult decisions about what to include, SOAP 1.2 became a W3C recommendation almost two years after that first draft, in June 2003.
What Is SOAP, Really?
Despite the hype that surrounds it, SOAP is of great importance because it's the industry's best effort to date to standardize on the infrastructure technology for cross-platform XML distributed computing. Above all, SOAP is relatively simple. Historically, simplicity is a key feature of most successful architectures that have achieved mass adoption.
At its heart, SOAP is a specification for a simple yet flexible second-generation XML protocol. Because SOAP is focused on the common aspects of all distributed computing scenarios, it provides the following (covered in greater detail later):
-
A mechanism for defining the unit of communication—In SOAP, all information is packaged in a clearly identifiable SOAP message. This is done via a SOAP envelope that encloses all other information. A message can have a body in which potentially arbitrary XML can be used. It can also have any number of headers that encapsulate information outside the body of the message.
-
A processing model—This defines a well-known set of rules for dealing with SOAP messages in software. SOAP's processing model is simple; but it's the key to using the protocol successfully, especially when extensions are in play.
-
A mechanism for error handling—Using SOAP faults, you can identify the source and cause of an error and it allows for error diagnostic information to be exchanged between participants of an interaction.
-
An extensibility model—This uses SOAP headers to implement arbitrary extensions on top of SOAP. Headers contain pieces of extensibility data which travel along with a message and may be targeted at particular nodes along the message path.
-
A flexible mechanism for data representation—This mechanism allows for the exchange of data already serialized in some format (text, XML, and so on) as well as a convention for representing abstract data structures such as programming language datatypes in an XML format.
-
A convention for representing Remote Procedure Calls (RPCs) and responses as SOAP messages—RPCs are a common type of distributed computing interaction, and they map well to procedural programming language constructs.
-
A protocol binding framework—The framework defines an architecture for building bindings to send and receive SOAP messages over arbitrary underlying transports. This framework is used to supply a binding that moves SOAP messages across HTTP connections, because HTTP is a ubiquitous communication protocol on the Internet.
Before we dive deeper into the SOAP protocol and its specification, let's look at how our example company, SkatesTown, is planning to use SOAP and Web services.