The Current State of the SOAP Standard


The SOAP standard has rattled around for a few years now. When SOAP originally came into being in early 1998, it was called XML-RPC. Several developers worked on it, including Dave Winer and Don Box, in collaboration with a small team at Microsoft that wanted to create a method of sending RPCs via XML. However, SOAP’s structure changed early on with the addition of items such as structs and arrays, and according to “Dave’s History of SOAP,” an article that Dave Winer published on www.xmlrpc.com, the SOAP specification soon looked like it couldn’t even have come from the original XML- RPC specification. This necessitated a name change, and XML-RPC was removed from the specification as a separate adjunct to SOAP. The first version of the specification was released separately by Dave Winer to keep things rolling with the specification and to ensure that Microsoft made it “more than just a press release.” The SOAP 1.0 standard was ready by 1999, and version 1.1 included contributions from other major companies such as IBM, Sun, and Oracle. SOAP 1.1 was to be the final release of the standard, but pressure from developers who wanted to improve some of the features led to work on SOAP 1.2 in late 2001.

The most up-to-date final recommendation is still only SOAP 1.1, although SOAP 1.2 is in a pretty complete state and is due to be released soon. In this chapter, we’ll consider both the “old” standard and the new one, but bear in mind that much of the 1.2 standard has yet to be implemented in .NET Web services.

SOAP 1.1

You can find the SOAP 1.1 specification at http://www.w3.org/TR/SOAP/. SOAP 1.1 is based on the XML specification and has four parts:

  • The envelope for encapsulating data

  • Optional data rules for encoding data types defined within the application

  • A message exchange pattern

  • An optional part for binding SOAP to HTTP

Some aspects of SOAP 1.1 have yet to be implemented, but the specification does outline the general format for the <Envelope>, <Header>, and <Body> elements that make up a SOAP message.

The two main design goals are stated clearly in the standard: simplicity and extensibility. If you’re familiar with the often esoteric terminology of W3C, the standard can make for fairly swift reading. If you’re not, however, lines such as “using SOAP for RPC is orthogonal to the SOAP protocol binding” can make for heavy going. The document is intended more for implementers than developers, but it’s still worth summarizing the main points.

Apart from descriptions of the general structure of a SOAP message and the fundamentals of one-way message exchange, you’ll find that over half the standard is taken up by a discussion of SOAP encoding and how simple types (such as strings and enumerations) and compound types (such as arrays and structs) can be serialized. We’ll touch on the subject of encoding later in the chapter, but it isn’t of much interest to us here because it’s already supported by .NET. Rather than let SOAP handle the encoding, .NET performs the task of serializing data into different data types. We’ll look at this further in Chapter 6. The marshaling of arguments is the one thing that can cause problems for any RPC mechanism, not just SOAP—hence the standard’s preoccupation with it. XML is a perfect format for sending data, but because of its limitations it’s preferable to handle the serialization separately.

SOAP 1.2

The latest version of the SOAP standard, 1.2, is no more than a last-call working draft on the W3C site as of this writing. It’s quite a bit longer than the 1.1 standard, in part because it’s based on the XML Information Set (Infoset), which makes for more precise and formal reading but is also more painfully drawn out. SOAP 1.2 can be found at http://www.w3.org/2000/xp/Group/#soap12.

Note

The XML Infoset is a consistent set of definitions for use in other specifications that need to reference XML documents. It is managed by W3C. The current standard can be found at http://www.w3.org/TR/xml-infoset/.

Even though the 1.2 standard is incomplete as of this writing, its status as a proposed recommendation document indicates that not much should change before final ratification.

SOAP 1.2 introduces some new features into the standard and removes one or two as well. Of particular interest is the fact that SOAP’s most notable features are described more fully in this version of the specification. They include

  • Nodes Nodes are the processing logic needed to send and receive information. Nodes can be broken down into senders and receivers. The initial sender is the SOAP node that started the correspondence, and the ultimate receiver is the intended destination of the message.

  • Roles Roles replace actors from the 1.1 standard. A role or an actor is the intermediary that receives a SOAP header.

  • Features Features are abstract pieces of functionality associated with the passing of SOAP messages. Examples include “reliability” and “security.”

  • Modules A module is a feature expressed as a SOAP header.

  • Message Exchange Patterns These are templates for the exchange of SOAP messages between SOAP nodes. They were present in the SOAP 1.1 standard but take on a greater significance in the newer standard.

The standard hasn’t changed dramatically, but the alterations include corrections to problems in SOAP 1.0 and SOAP 1.1. SOAP 1.2 also addresses the XML Schema specification, which didn’t exist when SOAP first came into being. The standard is also now split into two main sections, one describing the messaging framework and one describing a set of adjuncts to the framework. No fundamental changes have been made to the structure of the SOAP message, though, so in this chapter we’ll mainly talk about SOAP 1.1 because the .NET Framework version 1.1 supports it. We’ll refer to SOAP 1.2 where the changes are likely to make a difference in the future.




Programming Microsoft. NET XML Web Services
Programming MicrosoftВ® .NET XML Web Services (Pro-Developer)
ISBN: 0735619123
EAN: 2147483647
Year: 2005
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net