RE: One-way messaging in SOAP 1.2

Hi Chris,

So my question to you is, by what means would the binding instance at the
receiving end know that this is indeed a one-way inbound message and that
would prompt it to return say an empty 200 OK (or whatever response code we
agree). 

On the HTTP request side there are no distinguishing marks, unless we use a
different HTTP method (say PUT) or denote the distiction in some HTTP header
(maybe even further overload the media type - not serious).

If there are no such distinguishing marks, I think I'll stay dancing on my
pinhead and assert that we only (presently) have request/response and that
the response may be NULL.

I'd also expect an one-way MEP to work in both directions... (seems like an
oxymoron...). BTW I was really amused to hear that gift shops over here had
run out of "The One Ring" :-). That said, the HTTP binding is assymetric on
request/response, so why not on one-way too... keep it consistent.

Regards,

Stuart

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: 17 January 2002 16:13
> To: Williams, Stuart
> Cc: 'Marc Hadley'; xml-dist-app@w3.org
> Subject: Re: One-way messaging in SOAP 1.2
> 
> 
> 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:50:56 UTC