W3C

SOAP Optimized Serialization Use Cases and Requirements

Editors Draft 22 February 2004

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


Short Table of Contents

1. Introduction
2. Terminology
3. Use Cases
4. Requirements
5. References
A. Acknowledgments (Non-Normative)
B. Change Log (Non-Normative)


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

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.

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.

3.1 Out of Scope Use Cases

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.

UC12: Interleaving

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.

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.

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.

4.1 Considerations

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.

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.

4.4 Binding Requirements

R34

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.

R17

The specification must work with the SOAP 1.2 HTTP binding and shouldn't unnecessarily preclude working with other bindings.

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/2000/09/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): 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.

B. Change Log (Non-Normative)

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