Re: One-way messaging in SOAP 1.2

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 07:49:03 UTC