W3C

SOAP 1.2 Part 3: One-Way MEP

Editors Copy $Date$ 16 May 2007

This version:
http://www.w3.org/2000/xp/Group/6/soap12-part3
Latest version:
http://www.w3.org/2000/xp/Group/6/soap12-part3-20070516.html
Previous versions:
http://www.w3.org/2000/xp/Group/6/soap12-part3-20070330.html ( xml ), http://www.w3.org/2000/xp/Group/6/soap12-part3-20060906.html ( xml ), http://www.w3.org/2000/xp/Group/6/soap12-part3-20060830.html ( xml ), http://www.w3.org/2000/xp/Group/6/soap12-part3-20060809.html ( xml ), http://www.w3.org/2000/xp/Group/6/soap12-part3-20060804.html ( xml ), http://www.w3.org/2000/xp/Group/6/soap12-part3-20060720.html ( xml )
Editor:
David Orchard, BEA Systems

Abstract

SOAP Version 1.2 Part 2 provides a request-response MEP and a response-only MEP. This, the SOAP 1.2 Part 3, provides a one-way MEP.

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. This is the First Public Working Draft of the SOAP 1.2 Part 3: One-Way MEP document. It has been produced jointly by the XML Protocol Working Group which is part of the Web Services Activity. The current intention of the Working Groups is to issue the final version of this specification as a Working Group Note.

Comments on this document are welcome. Please send them to the public mailing-list xmlp-comments@w3.org (archive). It is inappropriate to send discussion email to this address. 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
    1.1 Notational Conventions
2 SOAP One-way Message Exchange Pattern
    2.1 SOAP Feature Name
    2.2 Description
    2.3 Property Description
    2.4 Fault Handling
3 References
    3.1 Normative References
    3.2 Informative References

Appendix

A Change Log (Non-Normative)


1 Introduction

SOAP Version 1.2 Part 2 provides a request-response MEP and a response-only MEP. This, the SOAP 1.2 Part 3, provides a one-way MEP.

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].

With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.

2 SOAP One-way Message Exchange Pattern

This section defines the message exchange pattern (MEP) called "One-way". The description is an abstract presentation of the operation of this MEP. It is NOT intended to describe a real implementation or to suggest how a real implementation should be structured.

2.1 SOAP Feature Name

This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 [SOAP Part 1]SOAP Features):

  • "http://www.w3.org/2006/08/soap/mep/one-way/"

2.2 Description

The SOAP One-way MEP defines properties for the exchange of a SOAP message. In the absence of failure in the underlying protocol, this MEP consists of zero or more SOAP messages. The scope of a one-way MEP instance is limited to transmission of messages from one sending node to zero or more receiving SOAP node(s). The ImmediateSender and ImmediateDestination properties may differ among nodes. The envelope in the InboundMessage property at each successful receiver SHOULD be identical to the envelope in the OutboundMessage at the sender. Implementations MAY choose to support multiple MEPs at the same time.

The sending node MUST attempt to send, in a binding-specific manner, the SOAP Message provided in http://www.w3.org/2003/05/soap/mep/OutboundMessage to the node(s) identified by http://www.w3.org/2003/05/soap/mep/ImmediateDestination. If the sender has a means of detecting successful or unsuccessful transmission, it SHOULD fault in a binding-specific manner in the event that transmission failure is detected.

When a message is successfully received by a SOAP node, that node MUST populate http://www.w3.org/2003/05/soap/mep/InboundMessage with the received message and MUST process the message in http://www.w3.org/2003/05/soap/mep/InboundMessage according to the SOAP Processing Model (see SOAP 1.2 Part 1 [SOAP Part 1]Processing SOAP messages). A receiver MAY (though typically only in exceptional circumstances) treat as erroneous, or lost, a message that has been received intact. Typical reasons for making such decisions might include shortage of buffer space, network interface overruns, etc.. A receiver MAY fault in a binding-specific manner if some particular message is determined to have been unsuccessfully received (note, however, that in many cases where receipt is unsuccessful, information identifying the message or its sender may be unreliable, in which case there may be little if any value in reflecting a message-specific fault.)

2.3 Property Description

The One-way MEP defines a set of properties described below.

Property definitions for One-way MEP
Property NameProperty DescriptionProperty Type
http://www.w3.org/2003/05/soap/mep/InboundMessageAn abstract structure that represents the current inbound message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope. This property is populated if and only if the message is successfully received.Not specified
http://www.w3.org/2003/05/soap/mep/OutboundMessageAn abstract structure that represents the current outbound message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope.Not specified
http://www.w3.org/2003/05/soap/mep/ImmediateDestinationThe identifier of the immediate destination of an outbound message. (NOTE: the URI supplied MAY be the identifier of a single destination SOAP node, or MAY be the identifier of a multicast group, which itself consists of zero or more destination nodes. Whether multicast is supported is binding-dependent. This MEP specification provides no standard means for representing a multicast group, except to require that the group as a whole be designated by a URI.)xs:anyURI
http://www.w3.org/2003/05/soap/mep/ImmediateSenderThe identifier of the immediate sender of an inbound message.xs:anyURI

This MEP MAY be extended by later specifications. Such extensions MAY add additional properties to the ones listed above.

2.4 Fault Handling

Each SOAP node involved in the message exchange makes its own determination of successful completion of the message exchange. Each node MAY independently signal a fault in the case of abnormal operation. Determination of successful operation and disposition of faults are outside the scope of this specification.

3 References

3.1 Normative References

SOAP Part 1
W3C Proposed Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/)
RFC 2119
IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt)
RFC 3986
IETF "RFC 3986: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, January 2005. (See http://www.ietf.org/rfc/rfc3986.txt)

3.2 Informative References

SOAP Part 0
W3C Proposed Recommendation "SOAP Version 1.2 Part 0: Primer", Nilo Mitra, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part0-20030624/)
SOAP Part 2
W3C Proposed Recommendation "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/)
XMLP Comments
XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/)
XMLP Dist-App
XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/)
XMLP Charter
XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter)
RFC 2045
IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1996. (See http://www.ietf.org/rfc/rfc2045.txt)
RFC 2026
IETF "RFC 2026: The Internet Standards Process -- Revision 3", section 4.2.3, S. Bradner, October 1996. (See http://www.ietf.org/rfc/rfc2026.txt)

A Change Log (Non-Normative)

Changes
WhoWhenWhat
DBO20041208Initial Revision
DBO200603302nd Revision
DBO20060530Adding sending and receiver MUSTs
DBO20060720Update date parts, checked into cvs, and moved abnormal operation paragraph to end of 2.2
DBO20060803Added InboundMessage property and text about populating, removed State property, other minor edits. Moved to xmlspec 2.10 dtd and xmlspec.xsl 1.54 (2005/10/13)
DBO20060809Removed failureReason property, explicit support for multicast by saying 0 or more nodes, changing "the receiver" to "a receiver" etc.
DBO20060830Some more clarifications on multicast, added ednote for feedback.
DBO20070330Did Mutiple fixes based on WSDL WG comments. Minutes at http://www.w3.org/2007/03/21-xmlprotocol-minutes.html, WSDL Comments at http://lists.w3.org/Archives/Public/xmlp-comments/2007Feb/0000.html. WG made decisions about 1, 5, 10, 11. Items 2,3 done at editors discretion.
DBO20070425Did 2 fixes, http://www.w3.org/Bugs/Public/show_bug.cgi?id=4404, http://www.w3.org/Bugs/Public/show_bug.cgi?id=4407. Minutes at http://www.w3.org/2007/04/25-xmlprotocol-minutes.html. Also removed Ed note.
DBO20070516Did 2 fixes, first 2 of Noah's comments from 5/4/2007 and moved error handling out of 2.2