W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: One-way messaging in SOAP 1.2

From: Edwin Ortega <ortegae@wns.net>
Date: Wed, 16 Jan 2002 13:26:01 -0800
Message-ID: <00e001c19ed4$6bc03ae0$32a2583f@val6000>
To: "Marc Hadley" <marc.hadley@sun.com>, <xml-dist-app@w3.org>

----- Original Message -----
From: "Marc Hadley" <marc.hadley@sun.com>
To: <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 6:32 AM
Subject: Re: One-way messaging in SOAP 1.2


> (RESEND - this didn't seem to make it out the first time)
>
> Jacek Kopecky wrote:
>
>  >  as far as I understand the HTTP binding (I've last read the
>  > SOAP/1.1 version of it though) is that it supports one-way quite
>  > nicely:
>  >  An HTTP request with the SOAP Envelope in it goes there, back
>  > goes either 202 success, but nothing back, or 200 OK with content
>  > length zero. (IIRC the wording meant "in case there is a reply,
>  > send it like this:...")
>  >  If the current wording prohibits one-way, I think we've indeed
>  > got an issue here.
>
>   >
> The current wording doesn't prohibit it, but it doesn't enshrine it
either:
>
> "8.3 Supported Transport Message Exchange Patterns
>
> An instance of a transport binding to HTTP[2] conforming to this
> transport binding specification MUST support the following transport
> message exchange pattern:
>
>       *
> http://www.example.org/2001/12/soap/transport-mep/single-request-response/
> (see 7.1 Single-Request-Response TMEP)"
>
> Note no mention of one-way.
>
>
>  >  I don't think we necessarily have to describe one-way MEP for it
>  > should be clear enough. Or we could have a simple definition
>  > like:
>  >  One-way MEP: best effort to get the message to the other side,
>  > nothing (SOAPish) ever goes back.
>
>   >
> You could say the same about request-response, but instead we describe
> it quite formally. If we are going to say that every binding MUST
> support a one-way MEP then we should at least define it formally IMO.
>
>
>  >  I don't like the idea that some transports may not support
>  > one-way, I can't imagine such a transport really.
>
>   >
> It's not a question of the transport, but of the binding: how does the
> binding use the transport to do one-way. Our HTTP binding doesn't call
> out that it supports a one-way MEP, but does imply it in the description
> of the 202 and 204 status codes.
>
> Regards,
> Marc.
>
>  >
>  >
>  > On Wed, 16 Jan 2002, Marc Hadley wrote:
>  >
>  >  > All,
>  >  >
>  >  > I'd like to raise a new issue:
>  >  >
>  >  > In Part 1, section 5.3 we find:
>  >  >
>  >  > "Every binding specification MUST support the transmission and
>  >  > processing of one-way messages as described in this specification. A
>  >  > binding specification MAY state that it supports additional
> features, in
>  >  > which case the binding specification MUST provide for maintaining
> state,
>  >  > performing processing, and transmitting information in a manner
>  >  > consistent with the specification for those features."
>  >  >
>  >  > This paragraph is potentially confusing, either we mean:
>  >  >
>  >  > (i) All bindings must support a one-way MEP, in which case there
> are two
>  >  > issues:
>  >  >    (a) we currently don't define a one way MEP in the specification
>  >  >    (b) the HTTP binding we do define doesn't support a one-way MEP
>  >  >
>  >  > or (my reading)
>  >  >
>  >  > (ii) All bindings must at a minimum define how to move a message
from
>  >  > one node to another, in which case I would propose that we add a
>  >  > clarification along the lines of "Note, this does not mean that all
>  >  > bindings must support a one way MEP, only that they MUST define
> how to
>  >  > move a message from one SOAP node to another".
>  >  >
>  >  > Comments ?
>  >  >
>  >  > Regards,
>  >  > Marc.
>  >  >
>  >  >
>  >
>  >
>
>
>
> --
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Centre, Sun Microsystems.
>
>
>
>
Received on Wednesday, 16 January 2002 12:41:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT