This document records the use cases and specifies the requirements for optimizing the processing and serialization of SOAP messages.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the first working Draft of a document produced by the XML Protocol Working Group, part of the Web Services Activity. This document represents the consensus of the working group at the time of its publication.
The use cases and requirements described in this document serve to motivate and constrain the scope of the Working Group's ongoing work on a SOAP Message Transmission Optimization Mechanism. This publication is the result of the work started in February 2003 by the Working Group; it expects there will be relatively few changes to the use cases and requirements after they have been published although the Working Group will continue to consider comments on them.
Discussion of this document takes place on the public firstname.lastname@example.org mailing list (Archives [XMLP Archive]) per the email communication rules in the XML Protocol Working Group Charter [XMLP Charter].
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress." A current list of patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
3. Use Cases
3.1 Out of Scope Use Cases
4.2 Processing Environment Requirements
4.3 Infoset Serialization Requirements
4.4 Binding Requirements
SOAP Version 1.2 [SOAP Part 1][SOAP Part 2] is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. This document records the use cases and specifies the requirements for optimizing the processing and serialization of SOAP messages.
The use cases illustrate the reasons for optimizing the serialization of SOAP messages.
The requirements distill both the constraints embodied in the use cases and the features necessary for interoperability with existing protocols, bindings, and serialization formats such as SOAP 1.2, WSDL, MIME, etc. Two influential developments shaped these requirements:
The "SOAP Messages with Attachments" [SwA] W3C Note provided a MIME multipart/related packaging scheme that related accompanying "entities" (including binary data) to a SOAP 1.1 message via referencing rules. The SwA approach did not, however, naturally integrate attachments into the SOAP processing model and the XML Infoset representation of a SOAP message.
The PASWA document [PASWA], a "Proposed Infoset Addendum to SOAP Messages with Attachments", offered a more unified approach by suggesting that the accompanying entities be logically considered a part of the SOAP message XML Infoset, while retaining the flexibility for implementations to optimize their behavior.
The terminology and processing reflected in these requirements supercede and are not necessarily consistent with the SOAP 1.2 Abstract Feature specification [Attachment Feature]. For example, the term part does not necessarily indicate attachment data that is logically outside the SOAP envelope infoset. It may also cover data in alternative serializations that is logically contained in the SOAP envelope infoset.
More use cases were submitted to the XMLP WG than were accepted for inclusion in this list. The use cases up to UC11 preserve their numbering from the discussion [UC Summary] prior to their inclusion in this document. Omitting rejected use cases has left gaps in the numbering.
An application wishes to send a URI in a message, and the receiver will dereference the URI. The sender chooses to “bundle” a representation of the resource in the message as well, so that the receiver may choose this representation when it dereferences the URI. This is useful in cases when the resource identified by the URI is inaccessible to the receiver, or the receiver wants to avoid the overhead of dereferencing the resource over the network, etc.
An application wishes to send a SOAP message that contains redundant pieces of binary data. Each such piece of binary data is actually contained in several locations of the SOAP message (for example, the SOAP message could contain an XML document which includes in several locations the PNG logo of the company which authored the document). For design reasons, this data cannot be referenced externally, but must be transported with the message. Doing so by copying each piece of binary data as many times as it is contained in the SOAP message involves an unacceptable message size, due to bandwidth, latency and/or storage requirements.
An application wishes to send a SOAP message that contains one or more large binary pieces of data; e.g., a JPG image, binary executable or other sizeable, non-textual data. For design reasons, this data cannot be referenced externally, but must be transported with the message. Doing so using base64Binary or similar encoding involves an unacceptable message size, due to bandwidth, latency and/or storage requirements.
An application wishes to send a SOAP message that contains one or more large binary pieces of data; e.g., a JPG image, binary executable or other sizeable, non-textual data. For design reasons, this data cannot be referenced externally, but must be transported with the message. Doing so using base64Binary or similar encoding involves unacceptable message generation and/or parsing overhead, due to throughput requirements, device limitations and/or other considerations.
An intermediary wishes to process a large message, but only needs to access a small section of the message. For efficient operation, it needs to be able to construct the relevant parts of the message infoset without actually reading and parsing the rest of the message, whilst still being able to successfully forward the entire message.
The Working Group recognizes that optimizing the serialization of SOAP messages is applicable to the following use cases but decided that it would not develop requirements to satisfy these.
An application may want to interleave the optimized serializations of multiple portions of a message, so that it can be produced and/or consumed incrementally and simultaneously. This could be useful, for example, to applications that produce/consume audio and video streams simultaneously.
The requirements below are coarsely categorized as applying to the SOAP/WSDL processing environment (general issues, abstract features and properties, WSDL compatibility, etc.), as arising primarily at the concrete wire format level (serialization, representation, metadata, etc.), or as constraining the binding.
The requirements are numbered in the order in which they were considered by the XMLP WG. Omitting rejected requirements has left gaps in the numbering.
The grouping and ordering of the requirements in the following sections is for ease of reading and does not indicate any relative priority of any of the requirements.
There are general, high-level considerations in choosing a design for a SOAP Attachment Feature which should be taken as input in addition to the specific requirements listed in the following sections.
If existing packaging schemes (e.g., Multipart-MIME, DIME, ZIP, tar, jar, etc.) meet the requirements, or represent sensible tradeoffs, then the specification should use such existing schemes.
The specification should, where reasonably practical, be designed to facilitate message construction, parsing, debugging, tracing, implementation optimizations and other diagnostic activities.
The specification must describe its points of extensibility.
The interface created by the specification should be conveniently describable by languages such as WSDL.
The specification must be specified using the mechanisms of SOAP 1.2. These may include features, binding specifications, headers, relaying of information through intermediaries, etc. All processing must be specified in terms of the SOAP processing model, as augmented by any new features introduced. Where practical, the optional mechanisms of SOAP 1.2 (such as A Convention for Describing Features and Bindings) should be used in the description of the optimized serialization.
The specification must support transmission of messages to down-level receivers that do not understand the specification.
The specification should, to the extent possible, minimize the overhead involved in securing SOAP messages including content subject to optimized transmission.
A message, however serialized, must be representable as a single SOAP message infoset.
It must be possible to select more than one portion of the message for optimization.
Means must be provided in the infoset for optionally indicating the media type of binary element content.
It must be possible to encrypt the message or its portion(s), including non-XML data (e.g., binary data and XML fragments).
It must be possible to sign the message or its portion(s), including non-XML data (e.g., binary data and XML fragments).
This section lists requirements placed upon the serialization. In them, the phrase "infoset parts" identifies those parts of the Infoset that are targeted for optimization, while "serialization parts" is used to refer to their corresponding serialization artifacts "on the wire." When unqualified "parts" is used, the requirement applies to both senses.
The spec must define at least one infoset serialization using Multipart MIME, and possibly additional serializations.
The serialization must be able to carry arbitrary data, including non-XML data (e.g., binary data and XML fragments).
The serialization should support efficient implementation of parsing the physical representation to separate and identify its constituent parts.
The serialization should use a reasonably space-efficient representation.
The serialization should be designed to facilitate cooperation between inbound and outbound bindings at a SOAP intermediary, resulting in efficient relay of SOAP messages.
The serialization should efficiently support the addition and deletion of parts by intermediaries.
The serialization must provide support for arbitrarily large parts.
The serialization should support streaming of serialization parts, i.e. chunked encoding.
The serialization should conveniently provide for the existence and extension of metadata relating to the serialization, for example, the version number of the serialization.
The serialization should conveniently provide for the existence and extension of metadata related to the serialization of individual parts.
The serialization must provide a facility for specifying length metadata that is appropriate to meet likely buffering requirements of receivers. The use of this facility is optional.
Within the serialization, each part must be named by an absolute URI.
The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc.
The serialization part carrying the start of the primary envelope document element must be easily locatable/identifiable.
The specification will include either an enhancement to the existing SOAP 1.2 HTTP binding or a new (but similar) binding. The new or extended binding will use the serialization to implement the Attachment Feature.
The specification must work with the SOAP 1.2 HTTP binding and shouldn't unnecessarily preclude working with other bindings.
This document is the work of the W3C XML Protocol Working Group [XMLP WG].
Participants in the Working Group are (at the time of writing, and by alphabetical order): Carine Bournez (W3C), David Fallside (IBM), Tony Graham (Sun Microsystems), Mike Greenberg (IONA Technologies), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), John Ibbotson (IBM), Mario Jeckle (DaimlerChrysler Research and Technology), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet), Yves Lafon (W3C), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler Research and Technology), Hervé Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Seumas Soltysik (IONA Technologies), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).
Previous participants were: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (webMethods), Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems), Philippe Bedu (EDF (Électricité De France)), Olivier Boudeville (EDF (Électricité De France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell, Inc.), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (Excelon Corporation), Ron Daniel (Interwoven), Glen Daniels (Macromedia), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett Packard), James Falek (TIBCO Software, Inc.), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Frederick Hirsch (Zolera Systems), Erin Hoffmann (Tradia Inc.), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Limited), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Hewlett Packard, formerly of Compaq), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Limited), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Bob Lojek (Intalio Inc.), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Nilo Mitra (Ericsson), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Highland Mary Mountain (Intel), Don Mullen (TIBCO Software, Inc.), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco Systems), Masahiko Narita (Fujitsu Limited), Mark Needleman (Data Research Associates), Art Nevarez (Novell, Inc.), Eric Newcomer (IONA Technologies), Henrik Nielsen (Microsoft Corporation), Conleth O'Connell (Vignette), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE Corporation), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera Systems), Krishna Sankar (Cisco Systems), George Scott (Tradia Inc.), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Miroslav Simek (Systinet), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Anne Thomas Manes (Sun Microsystems), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (webMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (MartSoft Corp.).
The editors thank the present and past members of the Attachments Requirements Task Force (ARTF) for their contribution to this document: David Fallside, Tony Graham, Martin Gudgin, Marc Hadley, Mark Jones, Anish Karmarkar, Noah Mendelsohn, Mark Nottingham, Hervé Ruellan, and Jeffrey Schlimmer.
|TG||20031029||Changed 'Preamble' to 'Introduction'. Added references to SOAP 1.2.|
|ASK||20031023||Removed MAJ's ednote. Added UC6|
|ASK||20031016||Added UC12, changed UC9&UC10 to reflect plurality of binary objects, removed three ED notes, added current&previous members of WG|
|ASK||20031007||Added requirements derived from UC-4|
|TG||20030925||Changed to XML markup. Added use cases. Moved 'Considerations' section to inside 'Requirements' section.|
|MAJ||20030825||Changed title, updated status for WD, added preamble to doc and section 3.2|