The Future of SOAP

The Future of SOAP

It should be clear at this point that SOAP is a work in progress. On the one hand, current implementations are inconsistent in their support of the SOAP 1.1 specification. On the other hand, the current spec leaves much to be desired, as well. This section covers some of the most critical features either missing in the 1.1 spec or poorly supported by the cur-rent implementations.

SOAP with Attachments

At its core, SOAP consists of self-defining serialization rules that allow for the marshal-ing and unmarshaling of objects into a simple text stream. SOAP’s focus on objects is quite understandable—after all, it is the Simple Object Access Protocol. However, for SOAP to be a truly useful wire protocol, it must be able to handle large binary objects that don’t lend themselves to marshaling.

The SOAP Messages with Attachments specification (found at http://www.w3.org/TR/ SOAP-attachments) uses the MIME Multipart/Related mechanism for handling attach-ments. This mechanism is the established protocol for handling e-mail attachments and is therefore well accepted in the technical community. When the technical community turned to the discussion of SOAP attachments using MIME, however, it had a problem: How to handle such attachments without burdening the SOAP specification with addi-tional elements? The answer was to construct the SOAP message package as a Multipart/Related media type. In other words, a “SOAP message with attachments” package is actually a MIME Multipart/Related message, where the SOAP Envelope is one of the parts, instead of the MIME message being included in the SOAP Envelope.

Here is how to construct the SOAP message package:

     Put the SOAP message in the root body part of the Multipart/Related structure. The type parameter of the Multipart/Related media header will be the same as the Content-Type header of the SOAP message, (that is, text/xml).

     To reference a MIME part, it must have either a Content-ID MIME header or a Content-Location MIME header.

     To support HTTP, the Content-Type: Multipart/Related MIME header must appear as a HTTP header, and there should be no other MIME headers that appear as HTTP headers.

Let’s take a look at an example of an HTTP POST request that contains a SOAP message package:

LISTING 15.7  Post.txt—Sample HTTP POST Request

POST /myPath.asp HTTP/1.1 Host: www.myServer.com

Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; Âstart=”<myFile.xml@myClient.com>”

Content-Length:  1234567

SOAPAction: http://schemas.myServer.com/myMethod Content-Description: This is the optional message description.

—MIME_boundary

Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <myFile.xml@myClient.com>

<?xml version=’1.0’ ?> <SOAP-ENV:Envelope

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”> <SOAP-ENV:Body>

<msg:myMsg id=”myMsgId” xmlns:myMsg=”http://schemas.myServer.com/myMethod”>

<myJPEG href=”cid:myFile.jpeg@myClient.com”/> </msg:myMsg>

</SOAP-ENV:Body> </SOAP-ENV:Envelope>

—MIME_boundary Content-Type: image/jpeg

Content-Transfer-Encoding: binary Content-ID: <myFile.jpeg@myClient.com>

Raw  JPEG  image...

—MIME_boundary—

Note that there is a reference to the JPEG image file myFile.jpeg in the SOAP Body element.

SOAP Security

As discussed in Chapter 14, there are four basic requirements for secure message trans-mission: confidentiality, authorization, data integrity, and nonrepudiation. Sending SOAP messages over SSL-secured connections such as HTTPS provides for confidentiality and data integrity, but additional measures are required to ensure authorization and nonrepu-diation, as well. The extension to SOAP that outlines a system for adding these security requirements is the Digital Signature (DS) specification, which is currently a W3C Note that can be found at http://www.w3.org/TR/SOAP-dsig. The DS Note proposes a standard way to use the XML Digital Signature [XML- Signature] syntax to sign SOAP messages by defining the <SOAP-SEC:Signature> header entry. DS uses digital signatures to solve the problems of confidentiality, autho-rization, and so on. This header entry is provided in the following namespace:

http://schemas.xmlsoap.org/soap/security/2000-12

Next, the DS Note provides for the SOAP-SEC:id global attribute, which enables the <ds:Reference> element that is used to refer to the signed part of the SOAP Envelope. For example, Listing 15.8 below shows a SOAP message with a signature header entry:

LISTING 15.8  Ds.xml—SOAP Message with Signature Header Entry

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>

<SOAP-ENV:Header> <SOAP-SEC:Signature

xmlns:SOAP-SEC=”http://schemas.xmlsoap.org/soap/security/2000-12” SOAP-ENV:actor=”some-URI”

SOAP-ENV:mustUnderstand=”1”>

<ds:Signature xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”> <ds:SignedInfo>

...Encryption algorithm information goes here <ds:Reference URI=”#Body”>

...Encrypted digest goes here </ds:Reference>

</ds:SignedInfo> <ds:SignatureValue>HiuKjIHKJH=...</ds:SignatureValue>

</ds:Signature> </SOAP-SEC:Signature>

</SOAP-ENV:Header> <SOAP-ENV:Body

xmlns:SOAP-SEC=”http://schemas.xmlsoap.org/soap/security/2000-12” SOAP-SEC:id=”Body”>

...Unencrypted SOAP message content goes here </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Note, first, that the <ds:Signature> element is part of the <SOAP-SEC:Signature> header entry, and the URI attribute of the <ds:Reference> element refers to the <SOAP-ENV:Body> element.

SOAP Transactions

For a set of messages to be considered a successful transaction, it must pass the ACID test. ACID is an acronym for the following:

   Atomicity. The set of messages in a transaction either all take place or none take place. If one fails, every system involved must be returned to the state it was in before the messages were sent (in other words, rolled back).

   Consistency. Transactions always operate on a consistent view of the data and always leave the data in a consistent state when a transaction is complete. Instances of data are considered to be consistent when they conform to the rules that apply to them (for example, if money is being transferred from a checking account to a sav-ings account, the money can never be in both accounts at the same time).

   Isolation. Transactions are not able to interfere with each other. If a system sup-ports multiple threads of execution, each transaction is unaware of others going on at the same time.

   Durability. Once a transaction is committed, its effects persist even if one or more of the involved systems fail subsequent to the transaction. If there is a system failure in the middle of a transaction, all involved systems roll back to their original state.

Database-management systems typically use a two-phase commit model to achieve the ACID requirements. However, the environment that SOAP messages move in lacks much of the infrastructure that databases rely on to execute transactions efficiently. SOAP mes-sages may be asynchronous, potentially leaving a system in a locked or indeterminate state for an extended period of time. SOAP messages may also involve intermediaries, making two-phase commits impractical. In addition, SOAP messages are designed to move among different platforms with no tightly coupled framework supporting them.

   More explicit error messages with strong recommendations on how to handle them.

   The inclusion of the final W3C XML Schema release.

   Improvements in the use of namespaces, which will better resolve ambiguities resulting from elements in different namespaces that share the same names.

   Improved envelope stability, which will improve interoperability among different implementations.

So, the good news is, SOAP is reasonably complete, and there won’t be that much new in the next version. The bad news? There is a new protocol under development that may supersede SOAP altogether: the XML Protocol.

The XML Protocol

The new XML Protocol (XP) is a working draft that is still squarely on the drawing board (at both the W3C as well as the IETF; find it at http://www.w3.org/2000/xp). XP seeks to approach the same issues SOAP was designed to address, by starting with an “abstract model” that separates business workflow from SOAP’s correlation of messages. Although it is generally understood that XP may supersede SOAP, it still remains to be seen whether there will be enough of a difference between the two to warrant such a move. There is also the possibility that the work going into XP will simply become a future version of SOAP.

The XP Working Group wants to include the following features in the specification:

   An envelope that allows for extensibility, evolvability, and a variety of different types of intermediaries (gateways, proxies, and so on)

   Operating system–neutral conventions for handling RPCs

   A serialization mechanism based on XML Schema data types

   An HTTP transport mechanism (which will remain optional, because XP messages can go over a variety of transport mechanisms)

If the preceding features look familiar, it’s no surprise; after all, SOAP currently offers all these features, at least to some extent. That’s one of the reasons why the technical community realizes that XP may not need to be distinct from SOAP at all. However, only time will tell.