- From: Jacek Kopecky <jacek@systinet.com>
- Date: Wed, 16 Jan 2002 15:46:47 +0100 (CET)
- To: Marc Hadley <marc.hadley@sun.com>
- cc: <xml-dist-app@w3.org>
Marc,
I think that now I see what you mean and it seems to me that
some formal description of the one-way MEP could be useful and
that we would _not_ require all bindings to support one-way
messaging.
On the other hand, I think it would not be wise to not support
one-way in our (as of now) only binding. 8-)
Jacek Kopecky
Senior Architect, Systinet (formerly Idoox)
http://www.systinet.com/
On Wed, 16 Jan 2002, Marc Hadley wrote:
> 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.
> >
> >
> >
> >
> >
> >
>
>
>
>
Received on Wednesday, 16 January 2002 09:46:49 UTC