Hugo Haas

World Wide Web Consortium (W3C) Cambridge Massachusetts U.S.A.

Hugo Haas is the W3C Team contact for the XML Protocol Working Group.

From its early days, Web technologies have been used to provide an interface to distributed services; for example, users have been interacting with CGI scripts via HTML forms for years. In 2000, the Web community showed a growing interest in the use of XML for communicating between distributed components. Developers came up with a fair number of XML-based protocols , and therefore a need for standardization arose. This lead in September 2000 to the creation of the W3C XMLP XML Protocol Working Group. The XMLP Working Group has been chartered to create an XML-based protocol XML-based protocol. Specifically, its task is to design four components:

An envelope for encapsulating XML data to be transferred in an interoperable manner that allows for distributed extensibility and evolvability as well as intermediaries.

A convention for the content of the envelope when used for RPC Remote Procedure Call applications.

A mechanism for serializing data representing non-syntactic data models such as object graphs and directed labeled graphs, based on the datatypes of XML Schema.

A mechanism for using HTTP transport in the context of an XML Protocol. This does not mean that HTTP is the only transport mechanism that can be used for the technologies developed, nor that support for HTTP transport is mandatory. This component merely addresses the fact that HTTP transport is expected to be widely used.

The Working Group has been chartered to evaluate the technical solutions proposed by SOAP/1.1 against the requirements identified. The public mailing list xml-dist-app@w3.org (see ) is used for technical discussions, and the SOAP developer community is regularly asked for input before making decisions. The goal of this document is to give an overview of the current work of the Working Group as of 15 October 2001. At the time of the presentation at XML 2001, an updated report will be given.

The Working Group decided to use the SOAP/1.1 specification as a base for the new specification designed. After having developed a set of requirements for the protocol designed, the Working Group started lodging issues against the SOAP/1.1 specification. A list of issues was generated, including issues resulting from the evaluation of the requirements document and issues reported by the developer community of SOAP/1.1. The Working Group also developed an abstract model (see ) of the protocol designed, in order to have an abstract description of the behavior intended. This document is also used to evaluate the technical solutions offered by SOAP/1.1. After a year of work, the XML Protocol Working Group has published several documents. The specification produced has been named SOAP Version 1.2 SOAP Version 1.2, since the Working Group intends this protocol to be a smooth evolution of SOAP/1.1. The following sections go over each deliverable quickly and explain their status. More details can be found in the SOAP Version 1.2 Working Drafts . SOAP Version 1.2 is a lightweight protocol for exchange of information in a decentralized, distributed environment. The SOAP envelope SOAP envelope is the outermost syntactic construct or structure of a SOAP message. It is an XML document. The envelope is composed of a header and a body, each composed of blocks which are the unit of extensibility of a SOAP message, as shown in below. SOAP processors can use block to exchange information in a decentralized fashion.

A SOAP message is a one-way communication between SOAP nodes, which goes from the sender to the receiver via a set of intermediaries, called SOAP actors SOAP actors. Those intermediaries can process parts (header blocks header blocks) of the message and then forward the message to the next node along the message path. Each header block of the message can be addressed to a particular actor. Blocks can also be marked for mandatory processing in order to enable the deployment of mandatory extensions. The following is an example of a SOAP version 1.2 message: <env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol" env:actor="http://www.w3.org/2001/09/soap-envelope/actor/next"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope> Should the processing of a message fail, a SOAP fault SOAP fault is generated and a message can be returned carrying details about what went wrong: <env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"> <env:Body> <env:Fault> <faultcode>env:VersionMismatch</faultcode> <faultstring>Version Mismatch</faultstring> </env:Fault> </env:Body> </env:Envelope> For a more in-depth introduction to SOAP, readers are invited to refer to the SOAP Version 1.2 Primer (see ). The following significant changes have been made to the SOAP/1.1 specification:

The specification uses the XML Information Set terminology.

Interoperability testing of SOAP/1.1 implementations showed a lack of clarity in certain sections leading to several different interpretations of the SOAP/1.1 specification. Clarifications to the SOAP processing model SOAP processing model were done in SOAP Version 1.2.

A mechanism to better identify faults on mandatory extensions (Misunderstood header block) was introduced.

The use of trailers was disallowed.

In order to guarantee a smooth evolution from SOAP/1.1 processors to SOAP Version 1.2 processors, an upgrade mechanism has been designed to indicate to SOAP/1.1 implementations that they are talking to a SOAP Version 1.2 implementation. A complete list of changes can be found in the change log section of the specification (see ). In order for a SOAP message to go from the sender to a receiver, it uses an underlying protocol underlying protocol. The Working Group needs to ensure that SOAP can be used on a variety of underlying protocols in order to fit in the current architecture. The use of SOAP over an underlying protocol is called a binding. The Working Group is working on developing a binding for the HTTP/1.1 protocol . In order to ensure common behavior across different transport bindings, the Working Group is working on developing a binding framework binding framework . SOAP messages being fundamentally one-way communications, the Working Group is also working on describing request-response message exchange pattern . As a result, the HTTP binding HTTP binding is being reworked. The SOAPAction HTTP header is now optional, a broader set of HTTP response codes is being proposed to better reflect the processing of messages, the media type used for SOAP messages is under discussion, etc. In order to allow applications to serialize the data to be communicated, SOAP defines an encoding based on the datatypes of XML Schema. SOAP Version 1.2 uses the datatypes defined in the XML Schema Part 2: Datatypes Recommendation . It is also a requirement is to be able to serializing data representing non-syntactic data models. An encoding task force has been started to define the SOAP data model and make sure that SOAP Version 1.2 meets this requirement. Most of today's use of XML-based protocols is for RPC scenarios. It is important for SOAP to enable RPC RPC communications. SOAP Version 1.2 Part 2: Adjuncts includes a convention for RPC . SOAP Version 1.2 introduces an rpc:result element in order to clarify cases where the return value is void. SOAP Version 1.2 also introduces a set of RPC -specific faults. As of today, more than 140 issues were identified and half of them have been addressed. Two versions of the SOAP Version 1.2 specification SOAP Version 1.2 specification were published as W3C Working Drafts. The specification has been split into two documents. SOAP Version 1.2 Part 1: Messaging Framework which describes the SOAP envelope and the SOAP transport binding framework, and SOAP Version 1.2 Part 2: Adjuncts , which describes the SOAP encoding rules the SOAP RPC convention and a concrete HTTP binding specification.

In addition to the SOAP Version 1.2 specification, the XML Protocol Working Group has produced several other documents. The challenge of crafting a protocol specification is to create a description of behavior that is not tied to any particular approach to implementation. There is a need to abstract away from some of the messy implementation details of buffer management, data representation and specific APIs. However, in order to describe the behavior of a protocol one has to establish a set of (useful) concepts that can be used in that description. The XML Protocol Abstract Model XML Protocol Abstract Model establishes such a set of concepts. It is being used to make sure that SOAP Version 1.2 behaves as it is supposed to. The XML Protocol Abstract Model is currently published as a W3C Working Draft. The goal of this document is to provide an easily readable tutorial on the features of SOAP Version 1.2. In particular, it describes the features through various usage scenarios, and is intended to complement the normative texts contained the specifications. A first editors' copy of the document has been made available. Interoperability is of crucial importance. This is why the Working Group is working on collecting a set of tests with the help of the SOAP community. The goals of this test suite are twofold. First, the test collection helps making sure that the specification is clear and that conformance requirements can clearly be identified. Second, it allows developers to test their implementations. The test collection test collection is currently under active development.

Matrix XML Protocol Comparisons , Eric Prud'hommeaux, 15 March 2001. Available at http://www.w3.org/2000/03/29-XML-protocol-matrix Charter XML Protocol Working Group Charter , David Fallside, Yves Lafon, Henrik Frystyk Nielsen, 13 September 2001. Available at http://www.w3.org/2000/09/XML-Protocol-Charter SOAP11 Simple Object Access Protocol (SOAP) 1.1 , W3C Note, Don Box et al., 8 May 2000. Available at http://www.w3.org/TR/2000/NOTE-SOAP-20000508 Issues XML Protocol WG Issues List . Available at http://www.w3.org/2000/xp/Group/xmlp-issues Infoset XML Information Set , W3C Proposed Recommendation. John Cowan, Richard Tobin, 10 August 2001. Available at http://www.w3.org/TR/2001/PR-xml-infoset-20010810/ Framework SOAP Underlying Protocol Binding Framework , Editors' draft, 31 August 2001. Available at http://www.w3.org/2000/xp/Group/1/08/31/ Binding Default HTTP binding , Editors' draft, 11 October 2001. Available at http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11_Framework_HTTP_Binding SRRMEP Transport Message Exchange Pattern: Single-Request-Response , Editors' draft, 11 October 2001. Available at http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11-SRR-Transport_MEP Schema2 XML Schema Part 2: Datatypes , W3C Recommendation, Paul V. Biron, Ashok Malhotra, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ SOAP12 1 SOAP Version 1.2 Part 1: Messaging Framework , W3C Working Draft, Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 2 October 2001. Available at http://www.w3.org/TR/2001/WD-soap12-part1-20011002/ SOAP12 2 SOAP Version 1.2 Part 2: Adjuncts , W3C Working Draft, Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 2 October 2001. Available at http://www.w3.org/TR/2001/WD-soap12-part2-20011002/ XMLP AM XML Protocol Abstract Model , W3C Working Draft, Stuart Williams, Mark Jones, 9 July 2001. Available at http://www.w3.org/TR/2001/WD-xmlp-am-20010709/ Primer SOAP Version 1.2 Part 0: Primer , Editors' copy, Nilo Mitra, 26 September 2001. Available at http://www.w3.org/2000/xp/Group/1/09/25/soap12-primer.html Tests SOAP Version 1.2 Test Collection , Editors' copy, Hugo Haas, Oisin Hurley. Available at http://www.w3.org/2000/xp/Group/1/09/ts