- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Thu, 17 Jan 2002 11:12:42 -0500
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- CC: "'Marc Hadley'" <marc.hadley@sun.com>, xml-dist-app@w3.org
Stuart, Maybe angels dancing... but I think that the TMEP while clearly request/response can and should be identified as supporting an MEP of request/response and/or one-way (in fact, as Marc points out, the SOAP spec says that one-way MUST be supported). It seems to me that maybe what is required for the binding specification is to put things into perspective of the MEP, mindful of the TMEP underpinnings. If the SOAP "application" identifies a message as being a "one-way" message, by means of a property that identifies that feature by its defined URI, then we can characterize the FSM in those terms, and be explicit that what is expected is a 202 (or possibly a 200) with an empty entity body in the HTTP response message, etc. Again, the state transitions might be slightly different. You could define either a blocking state transition, that resembled quite closely the state transitions for request/response, but one could also make a case where there wer no need of blocking, and that the 200/empty entity body response could be returned immediately, etc. Conversely, we can stipulate that for a request/response MEP, that a 200 status with an entity body containing a SOAP message (possibly wrapped in some other MIME envelope) was required, etc. Cheers, Chris Williams, Stuart wrote: > 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 Thursday, 17 January 2002 11:14:06 UTC