Re: One-way messaging in SOAP 1.2

Hmmm, Marc raises an interesting question/issue.

We probably do need to be a bit more clear on the
subtle distinction between a transport-mep and an mep
(which is the application view of an mep). When
we say that one-way mep is required, do we mean
mep or transport-mep? It would seem to me that we mean
mep in this case, no? a one-way tmep may not
always be possible/practical, but a one-way mep
is readily modeled over a two way transport-mep such as
we have described for HTTP.

A one way mep can be easily layered over a single-request-response
transport-mep such as has been defined for the HTTP binding.
In fact, any number of meps could be layered above
this transport-mep quite nicely, IMO.

Of course, it would seem to me that the FSM description of
the HTTP binding would need to be reflective of use of the
one-way mep as well, at least to indicate that a 202 would
be expected as the result, etc.

NB, separate issue for editors: there seems to be an error here
and elsewhere in the part2 spec, the single-request-response
tmep URI shouldn't belong to the domain www.example.com, but rather
to the w3c.org domain, no? Isn't the HTTP binding intended to be
normative?

Cheers,

Chris



Jacek Kopecky wrote:

>  Marc,
>  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.
>  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.
>  I don't like the idea that some transports may not support 
> one-way, I can't imagine such a transport really.
>  Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> 
> 
> 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.
>  > 
>  > 
> 
>

Received on Wednesday, 16 January 2002 09:49:13 UTC