- 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