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 15:05:19 -0800
Message-ID: <01d601c19ee2$46912780$32a2583f@val6000>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>, "'Marc Hadley'" <marc.hadley@sun.com>
Cc: <xml-dist-app@w3.org>

----- Original Message -----
From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
To: "'Marc Hadley'" <marc.hadley@sun.com>
Cc: <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 9:56 AM
Subject: RE: One-way messaging in SOAP 1.2


> Marc et al.,
>
> I would also note the ednote ahead of the table in 8.4.1.1.2 (!)...
>
> <quote>
> Editorial note: JJM/SKW 20011205
> This is a large table and it would be good shrink it somewhat. It does not
> cover all generally possible HTTP status codes and may cover more than it
> should. This is one that we should be able to address provided the
direction
> and style are to peoples taste.
> /quote>
>
> >From my POV as one of the contributors to this part of the spec, the
content
> of that table is at least in part tentative. It provides a framework where
> we can give account of any SOAP'ish significance that may be attributed to
> the receipt of particular HTTP status codes.
>
> 204 No-content is a good example... do we ever expect it to happen and
what
> should it mean if it does? Would we regard as request/response as having
> succeeded or failed in such circumstances? To we regard it as a 'null'
> response (ie... from the MEP POV it was a response, with no value as
opposed
> to no response) and leave the 'application' to decide from it's POV
(without
> having to know about 204 from HTTP or xxx from protocol yyy).
>
> Personally, I think that these are some of the corner cases that this
style
> of documenting the binding forces us to visit - the answers in the boxes
may
> not yet be the right ones.
>
> On Marc's original point I would take the view that the binding we have
> defined in the current WD does not support a one-way message exchange
> pattern. It always does request response as currently defined - or fails.
> However, it is has been written to be 'tolerant' of empty responses, but
you
> are welcome to regard me as dancing on the head of a pin :-)
>
> For me the essential difference is that for a one-way MEP the binding
would
> know a-priori that that MEP was in use and that no-response would be
> forthcoming.   It would likely be denoted differently on the 'wire'. You
> ought to able to tell without having to know the semantics of message
> content being exchanged.
>
> Regards
>
> Stuart
>
> > -----Original Message-----
> > From: Marc Hadley [mailto:marc.hadley@sun.com]
> > Sent: 16 January 2002 14:38
> > To: xml-dist-app@w3.org
> > Cc: xml-dist-app-request@w3.org
> > 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 14:40:11 GMT

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