W3C

SOAP Optimized Serialization Use Cases and Requirements

W3C Working Draft 8 June 2004

This version:
http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/
Latest version:
http://www.w3.org/TR/soap12-os-ucr/
Previous version:
http://www.w3.org/TR/2003/WD-soap12-os-ucr-20031112/
Editors:
Tony Graham, Sun Microsystems
Anish Karmarkar, Oracle Corp.
Mark Jones, AT&T

Abstract

This document records the use cases and specifies the requirements for optimizing the processing and serialization of SOAP messages.

Status of this Document

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/.

The use cases and requirements described in this document serve to motivate and constrain the scope of the XML Protocol Working Group's (WG) work on a SOAP Message Transmission Optimization Mechanism. This publication is the result of the work started in February 2003 by the WG. The WG does not expect there will be any changes to the use cases and requirements in the future, although the WG may consider comments on them. Send comments on this document to xmlp-comments@w3.org mailing list (public archive). The XML Protocol Working Group is part of the Web Services Activity.

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].

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

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.

Table of Contents

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

Appendices

A Acknowledgments (Non-Normative)
B Change Log (Non-Normative)


1 Introduction

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:

2 Terminology

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.

3 Use Cases

UC2: Resource “Bundled” with Message

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.

UC6: Message Containing “Redundant” Pieces of Binary Data

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.

UC9: Undesirable Message Bloat

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.

UC10: Undesirable Processing Overhead

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.

UC11: Focused Intermediaries

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.

4 Requirements

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.

4.2 Processing Environment Requirements

R9

The specification must describe its points of extensibility.

R15

The interface created by the specification should be conveniently describable by languages such as WSDL.

R32

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.

R18

The specification must support transmission of messages to down-level receivers that do not understand the specification.

R27

The specification should, to the extent possible, minimize the overhead involved in securing SOAP messages including content subject to optimized transmission.

R29

A message, however serialized, must be representable as a single SOAP message infoset.

R33

It must be possible to select more than one portion of the message for optimization.

R22

Means must be provided in the infoset for optionally indicating the media type of binary element content.

R36

It must be possible to encrypt the message or its portion(s), including non-XML data (e.g., binary data and XML fragments).

R37

It must be possible to sign the message or its portion(s), including non-XML data (e.g., binary data and XML fragments).

4.3 Infoset Serialization Requirements

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.

R1

The spec must define at least one infoset serialization using Multipart MIME, and possibly additional serializations.

R2

The serialization must be able to carry arbitrary data, including non-XML data (e.g., binary data and XML fragments).

R3

The serialization should support efficient implementation of parsing the physical representation to separate and identify its constituent parts.

R4

The serialization should use a reasonably space-efficient representation.

R35

The serialization should be designed to facilitate cooperation between inbound and outbound bindings at a SOAP intermediary, resulting in efficient relay of SOAP messages.

R5

The serialization should efficiently support the addition and deletion of parts by intermediaries.

R13

The serialization must provide support for arbitrarily large parts.

R21

The serialization should conveniently provide for the existence and extension of metadata relating to the serialization, for example, the version number of the serialization.

R31

The serialization should conveniently provide for the existence and extension of metadata related to the serialization of individual parts.

R30

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.

R6

Within the serialization, each part must be named by an absolute URI.

R7

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.

R12

The serialization part carrying the start of the primary envelope document element must be easily locatable/identifiable.

5 References

WS Activity
Web Services Activity. (See http://www.w3.org/2002/ws/Activity.html.)
XMLP WG
XML Protocol Working Group. (See http://www.w3.org/2000/xp/Group/.)
XMLP Charter
XML Protocol Working Group Charter. (See http://www.w3.org/2004/02/XML-Protocol-Charter.)
XMLP Archive
XML Protocol Discussion Archive. (See http://lists.w3.org/Archives/Public/xml-dist-app/.)
SOAP Part 1
W3C Recommendation "SOAP 1.2 Part 1: Messaging Framework", Martin Gudgin, Mark Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003. (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)
SOAP Part 2
W3C Recommendation "SOAP 1.2 Part 2: Adjuncts", Martin Gudgin, Mark Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003. (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.)
Attachment Feature
W3C Working Draft "SOAP 1.2 Attachment Feature", Henrik Frystyk Nielsen, Hervé Ruellan, 14 August 2002. (See http://www.w3.org/TR/2002/WD-soap12-af-20020814/.)
SwA
W3C Note "SOAP Messages with Attachments", John J. Barton, Satish Thatte, and Henrik Frystyk Nielsen, 11 December 2000. (See http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211.)
PASWA
"Proposed Infoset Addendum to SOAP Messages with Attachments", Adam Bosworth, Don Box, Martin Gudgin, Mark Jones, Franz-Josef Fritz, Amy Lewis, Jean-Jacques Moreau, Mark Nottingham, David Orchard, Hervé Ruellan, Jeffrey Schlimmer, Volker Wiechers, Version 0.61 Draft, 1 April 2003. (See http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.)
UC Summary
"Attachments Use Cases Summary", David Fallside, 17 September 2003. (See http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0051.html.)

A Acknowledgments (Non-Normative)

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): David Fallside (IBM), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), John Ibbotson (IBM), Anish Karmarkar (Oracle), Suresh Kodichath (IONA Technologies), Yves Lafon (W3C), Michael Mahan (Nokia), 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), Herve Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), 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 (Electricite De France)), Olivier Boudeville (EDF (Electricite De France)), Carine Bournez (W3C), 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), Mike Greenberg (IONA Technologies), 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), Mario Jeckle (DaimlerChrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (Systinet), 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), Andreas Riegg (DaimlerChrysler Research and Technology), 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), Seumas Soltysik (IONA Technologies), 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.

The people who have contributed to discussions on xml-dist-app@w3.org [XMLP Archive] are also gratefully acknowledged.

B Change Log (Non-Normative)

WhoWhenWhat
TG20040222Removed R26 since it applies to UC12, and UC12 is out of scope.
TG20031029Changed 'Preamble' to 'Introduction'. Added references to SOAP 1.2.
ASK20031023Removed MAJ's ednote. Added UC6
ASK20031016Added UC12, changed UC9&UC10 to reflect plurality of binary objects, removed three ED notes, added current&previous members of WG
ASK20031007Added requirements derived from UC-4
TG20030925Changed to XML markup. Added use cases. Moved 'Considerations' section to inside 'Requirements' section.
MAJ20030825Changed title, updated status for WD, added preamble to doc and section 3.2