Re: Clarified one-way MEP

Chis,

Thanks for the feedback.  Comments inline.

Christopher B Ferris wrote:

>
> David wrote:
>
>         A mechanism for receiving nodes to be notified of receipt of a
> message.
>
> Clearly, the receiving node needs to have a mechanism to actually
> receive the message, not just be
> notified of its receipt.

Sure, but we don't need to model both.  The important event is the
properties being populated.  I'd tend to call this "notification of
receipt", but that might be my WSN background creeping in.  If "receipt"
seems better, that's fine with me.

How would you model receipt as distinct from population-of-properties? 
Would it be a separate event?

>
> It is also not clear to me why you believe that there need to be
> constraints on the mechanism for
> notification of receipt of a message (exactly once). If the sender
> happens to retransmit the message, then
> clearly the message may be received more than once...

That would be two instances of the MEP:  "In an instance of this MEP, a
single sending SOAP node establishes a message consisting of a set of
properties as defined below and sends it in a binding-specific way."

In answer to a later comment:  There are zero or more receivers in the
general case (multicast).  In the unicast case, there will be only one,
and the mapping from ImmediateDestiation to receivers will be N:1 (or
maybe 1:1 in some cases, but that probably doesn't matter).  Other than
that particular, I don't see a significant difference between the
unicast and multicast cases.

As far as I can see all the other text works fine in either case.  If
not, it might be worth calling out the unicast/multicast distinction
more explicitly.  It's probably worth calling out a bit more explicitly
anyway, as many readers will have unicast in mind and may not make the
somewhat implicit connection to multicast.

> it would be up to higher levels to make any determination
> as to whether it were a duplicate and as to whether that duplicate
> message should be dropped on the floor
> or processed.

Take your pick.  If the upper levels are handling retransmit (as would
be expected WS-RX is in effect), then the binding will potentially be
told to send more than once and receivers may hear the message more than
once.  In this case (which I expect would be a common one), there is no
one-to-one correspondence between application-level MEP instances and
binding-level MEP instances, but this is nothing new (the "async
request-reply" case would be another example).

If the binding is handling retransmit, then the sender sends once, the
binding puts the message on the wire as many times as it needs to, and
(normally) each receiver receives it once.   This would be the norm for,
e.g., TCP-based protocols, such as jabber, where normally a message sent
will be received exactly once.

It's also possible that /both/ levels are doing retransmits (e.g., WS-RX
is providing reliability /across /connections while the binding protocol
is, perhaps redundantly, providing reliability /within /connections). 
This makes no difference.  Higher-level retransmits are still separate
MEP instances, lower-level retransmits are still invisible.

A perhaps more pertinent difference is whether the binding is able to
guarantee that it will either deliver normally or signal an error. 
TCP-like bindings will generally be able to, UDP-like ones, including
many multicast implementations, generally won't.  This is why I leave
the base semantics open and say that "Bindings MAY define more detailed
behavior in the case of abnormal operation."

>
> At least as I read this, the constraint would preclude the use of
> WS-Reliable Messaging (or any of the RM
> protocols, for that matter) because the sending endpoint might indeed
> retransmit messages.
>
> Note that we are talking here about a transport-level MEP, not an
> application-level MEP and I would
> include infrastructure goop at the "application" level in many cases.

I agree.  Again, I think the main disconnect was over whether a
retransmission is a new instance of the MEP.  That was my assumption,
and I believe it makes life much, much easier.

>
> I would think that the description would be more along the lines of:
>
> *2.2 Description*
>
> The SOAP One-way MEP defines properties for the transmission of a SOAP
> message between a sending and a receiving SOAP node.
>
> In an instance of this MEP, a sending SOAP node establishes a message
> consisting of a set of properties as defined below and transmits the
> message in a binding-specific manner.  A binding to this MEP MUST define:
>
>     * A mapping of the message properties onto the transport-specific
>       PDU format.
>     * A mapping of the ImmediateDestination property of the message to
>       one or more receiving SOAP nodes.  This mapping MAY vary from
>       instance to instance of the MEP. [note: I couldn't understand
>       why you think that it might be zero SOAP nodes. Additionally, I
>       don't understand the second sentence unless you meant to say
>       that such a mapping may vary dependent upon the binding chosen.]
>
> In normal operation
>
>     * The received message is well-formed. [note: I could envisage
>       that an intermediary might add to the message things such as a
>       trace route entry as it transits between the sending SOAP node
>       and the ultimate receiver SOAP node. I think that all that we
>       can say is that in normal operation, that the received message
>       is well-formed. We may need to add some form of constraint that
>       a receiving node be capable of determining whether a received
>       message is well-formed.].
>     * Each receiving SOAP node processes received messages according
>       to the SOAP Processing Model (see SOAP 1.2 Part 1 _[SOAP Part
>       1]_ <soap12-part3-1.html#SOAP-PART1>_Processing SOAP messages_
>       <http://www.w3.org/TR/2003/REC-soap12-part1-20030624//#procsoapmsgs>).
>
>
> In abnormal operation, any of the following may happen:
>
>     * A receiving node might receive messages that are ill-formed. In
>       such a case, it MUST generate a fault.
>     * The sending node and/or any of the reciving nodes MAY generate a
>       fault, regardless of whether nodes in the receiving set have
>       been notified of receipt.
>
> Bindings MAY define more detailed behavior in the case of abnormal
> operation.  Bindings MAY choose to support multiple instances of this
> MEP simultaneously.
>
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> xml-dist-app-request@w3.org wrote on 06/16/2006 08:46:04 AM:
>
> > In a spare moment, I put together a revision of the one-way MEP which
> > tries to be more explicit about the questions I mentioned before.  The
> > formatting may be a bit funky, due to the HTML editor I was using.
> >
> > SOAP 1.2 Part 3: One-Way MEP
> > Editors Copy $Date: 2006/03/30 09:53:43 $ 16 June 2006
> > This version:
> > /
> > Editors:
> > David Orchard, BEA Systems
> > David Hull, TIBCO Software Inc
> > © 2006 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability,
> trademark
> > , document use, and software licensing rules apply.
> >
> > 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 document is an editors' copy that has no official standing.
> > This section describes the status of this document at the time of
> > its publication. Other documents may supersede this document. The
> > latest status of this document series is maintained at the W3C.
> > 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/03/soap/mep/one-way/"
> > 2.2 Description
> > The SOAP One-way MEP defines properties for the exchange of a SOAP
> message.
> > In an instance of this MEP, a single sending SOAP node establishes a
> > message consisting of a set of properties as defined below and sends
> > it in a binding-specific way.  A binding MUST define
> > A  mechanism for sending nodes to send a message.
> > A mapping from the ImmediateDestination property of the message to
> > zero or more receiving SOAP nodes.  This mapping MAY vary from
> > instance to instance of the MEP.
> > A mechanism for receiving nodes to be notified of receipt of a message.
> > In normal operation
> > Each receiving node is notified of receipt of the sent message
> exactly once.
> > The properties of each received message are identical to the
> > properties of the sent message.
> > Each receiving node processes the received message according to the
> > SOAP Processing Model (see SOAP 1.2 Part 1 [SOAP Part 1]Processing
> > SOAP messages).
> > In abnormal operation, any of the following may happen:
> > Nodes in the receiving set MAY fail to be notified of message
> > receipt or may be notified more than once.
> > Nodes in the receiving set MAY receive messages not identical to the
> > sent message.
> > Nodes not in the receiving set MAY be notified of message receipt,
> > regardless of whether nodes in the receiving set have been notified
> > of receipt.
> > The sending node and/or any of the reciving nodes MAY receive a
> > fault, regardless of whether nodes in the receiving net have been
> > notified of receipt.
> > Bindings MAY define more detailed behavior in the case of abnormal
> > operation.  Bindings MAY choose to support multiple instances of
> > this MEP simultaneously.
> > 2.3 Property Description
> > The One-way MEP defines the properties described below.
> >
> > Property definitions for One-way MEP
> >
> > Property Name
> >
> > Property Description
> >
> > Property Type
> >
> > http://www.w3.org/2003/05/soap/mep/OutboundMessage
> >
> > An 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/ImmediateDestination
> >
> > The identifier of the immediate destination of an outbound message.
> >
> > xs:anyURI
> >
> > http://www.w3.org/2003/05/soap/mep/ImmediateSender
> >
> > The identifier of the immediate sender of an inbound message.
> >
> > xs:anyURI
> >
> > There may be other properties related to the operation of the
> > message exchange and are processed according to their own feature
> > specifications.
> > 2.4 Fault Handling
> > This MEP makes no claims about the disposition or handling of SOAP
> > faults generated by the sending SOAP node or the receiving SOAP nodes.
> > 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/.)
> > 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/.)
> > 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 2396
> > IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax",
> > T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http:
> > //www.ietf.org/rfc/rfc2396.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/
> > .)
> > 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)
> >
> > Who
> >
> > When
> >
> > What
> >
> > Changes
> >
> > DBO
> >
> > 20041208
> >
> > Initial Revision
> >
> > DBO
> >
> > 20060330
> >
> > 2nd Revision
> >
> > DBO
> >
> > 20060530
> >
> > Adding sending and receiver MUSTs
> >
> > DMH
> >
> > 20060616
> >
> > Clarified semantics.
>