Re: One-way messaging in SOAP 1.2

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


> My issue is not so much whether "the SOAP spec supports one-way
> messages", but whether we are in fact mandating support in every binding
> for a one way MEP that we don't formally define.
>
> I agree that the HTTP binding can be used to support a one-way MEP, I
> just don't think that we define this very well in the current text. E.g.
> section 8.3 states that it supports single request-response, nothing
> more; the detail about HTTP response codes 202 and 204 is in "8.4.1
> Single Request-Response Exchanges".
>
> In general, I don't think the layering is as clear as it might be -
> probably because the only instance we have at the moment is a request
> response MEP over a request response transport.
>
> Regards,
> Marc.
>
> John Ibbotson wrote:
>
> > This issue is an example of how things get blurred at different levels
in a
> > stack, We are considering the contents of a SOAP Envelope, not the
> > transport that moves the message from one point to another. As Jack
> > suggests, a SOAP message can be sent as the contents of an HTTP request,
At
> > the transport layer, a 200 response comes back with empty content. Tha
> > response is simply an artifact of the HTTP protocol design. If I use an
> > asynchronous transport (I know some folks may not view it as a
transport)
> > such as MQSeries, then I simply PUT a message to a queue and it gets
> > delivered. to the destination. There is no request/response visible at
the
> > application layer.
> >
> > I am happy that the SOAP spec supports one-way messages in that there is
no
> > mandatory response at the SOAP layer from the ultimate destination. If
you
> > think some clarification of this is needed then I support that. This
> > clarification must emphasise the SOAP layer and not complicate it by
> > transport artifacts.
> > John
> >
> > XML Technology and Messaging,
> > IBM UK Ltd, Hursley Park,
> > Winchester, SO21 2JN
> >
> > Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
> > Fax: +44 (0)1962 816898
> > Notes Id: John Ibbotson/UK/IBM
> > email: john_ibbotson@uk.ibm.com
> >
> >
> >
> >
> >                     Marc Hadley
> >                     <marc.hadley@sun.       To:     XML dist app
<xml-dist-app@w3c.org>
> >                     com>                    cc:
> >                     Sent by:                Subject:     One-way
messaging in SOAP 1.2
> >                     xml-dist-app-requ
> >                     est@w3.org
> >
> >
> >                     01/16/2002 11:18
> >                     AM
> >
> >
> >
> >
> >
> >
> > 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 13:47:15 UTC