Copyright ©2003 W3C®(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document records the use cases and specifies the requirements for optimizing the processing and serialization of SOAP messages.
This is an Editor's Draft of the SOAP Optimized Serialization Use Cases and Requirements document. It is a deliverable of the XML Protocol Working Group (WG) [XMLP WG], which is part of the Web Services Activity [xmlp-activity].
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 xml-dist-app@w3.org mailing list (Archives [XMLP Archive]) per the email communication rules in the XML Protocol Working Group Charter [XMLP Charter].
1. Introduction
2. Terminology
3. Use Cases
4. Requirements
5. References
A. Acknowledgments (Non-Normative)
B. Change Log (Non-Normative)
1. Introduction
2. Terminology
3. Use Cases
3.1 Out of Scope Use Cases
4. Requirements
4.1 Considerations
4.2 Processing Environment Requirements
4.3 Infoset Serialization Requirements
4.4 Binding Requirements
5. References
A. Acknowledgments (Non-Normative)
B. Change Log (Non-Normative)
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.
Note:
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.
Note:
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 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): Michael Champion (Software AG), David Chappell (Sonic Software), Glen Daniels (Macromedia, formerly of Allaire), Colleen Evans (Sonic Software), David Fallside (IBM), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Don Mullen (Tibco), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Herv Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Nick Smilonich (Unisys), Lynne Thompson (Unisys), 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 (Planetfred), formerly of Sun Microsystems), Philippe Bedu (EDF (Electricit de France)), Olivier Boudeville (EDF (Electricit de France)), Carine Bournez (W3C), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), 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.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), 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).
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.
The people who have contributed to discussions on xml-dist-app@w3.org [XMLP Archive] are also gratefully acknowledged.
| Who | When | What |
|---|---|---|
| TG | 20040222 | Removed R26 since it applies to UC12, and UC12 is out of scope. |
| 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 |