Re: One-way messaging in SOAP 1.2

One clarfification, I believe that the receiving "SOAP MEP" should be the
receiving "HTTP binding implementation". I think that Henrik's
concern is that if we expected that the receiving HTTP node
were responsible for interpreting the SOAPMessagePattern header,
that clearly would enter into the realm of mucking with HTTP
processing semantics. However, if it is the responsibility of
the layer above the HTTP processing (say a servlet or CGI)
that is effectively the implementation of the HTTP binding,
that is responsible for interpretation of the new header,
and responsible for returning an HTTP 204 No Content response
to the sender. That (IMO) would be perfectly acceptable.

Cheers,

Chris

Jean-Jacques Moreau wrote:

> Henrik,
> 
> I don't think this is quite the kind of change Noah had in mind; it's
> certainly not how I've read his proposal.
> 
> My reading of Noah's proposal is less passionate, and does not require any
> changes to HTTP's semantics (I believe). Here's the scenario for a one-way
> SOAP exqhange using the extra HTTP header proposed by Noah:
> 
>   1. The SOAP sender decides to send a one-way message.
>   2. It crafts the corresponding envelope and selects a One-Way MEP.
>   3. The MEP crafts an HTTP request and adds the "SOAPMessagePattern:
>      OneWay" HTTP header.
>   4. The receiving SOAP MEP receives the HTTP request, reads the value of
>      the "SOAPMessagePattern" header, figures out it is a one-way message,
>      and sends back an empty 200 HTTP response (to comply with HTTP's
>      semantics).
>   5. The SOAP receiver processes the envelope. It DOES NOT return back a
>      SOAP response.
> 
> Jean-Jacques.
> 
> Henrik Frystyk Nielsen wrote:
> 
> 
>>A problem with the proposed solution of introducing a new HTTP header
>>field is that the 202 Accepted status code which is the status code in
>>question is an HTTP response and responses are by definition determined
>>by the server and not by the client.
>>
>>There is no mechanism to change that in HTTP and introducing an HTTP
>>header field with this sort of semantics would be a significant change
>>to HTTP. I don't think we want to go down this route - it is a *very*
>>slippery slope.
>>
>>Henrik
>>
>>
>>>>-----Original Message-----
>>>>From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
>>>>Sent: 17 January 2002 18:55
>>>>To: Christopher Ferris <chris.ferris
>>>>Cc: marc.hadley; skw; xml-dist-app
>>>>Subject: Re: One-way messaging in SOAP 1.2
>>>>
>>>>
>>>>
>>><snip/>
>>>
>>>>Those are options.  Why not do it this way:
>>>>
>>>>* In the binding framework, state that:  "Binding
>>>>
>>>specifications that
>>>
>>>>support more than one MEP MUST specify the means by which the
>>>>recipient of a message can determine the MEP being used.
>>>>
>>>+1
>>>
>>>
>>>
>>>
>>>>* In the HTTP binding state:  "This binding specification
>>>>
>>>provides the
>>>
>>>>following means for distinguishing use of the one way MEP
>>>>from requests
>>>>send using the Request/Response MEP:
>>>>- A SOAPMessagePattern: HTTP header is defined with the
>>>>values 'OneWay' or
>>>>'RequestResponse' (perhaps these should be URI's for extensibility?)
>>>>
>>>Yes... in fact we are naming our MEPs with URI's and this
>>>would be a good
>>>use for such URI names. I feel somewhat reticient about
>>>defining another
>>>HTTP header... but if thats what we have to do... its more
>>>extensible in the
>>>long run than using different HTTP method (say PUT... if
>>>that's viable for
>>>use with SOAP).
>>>
>>>
>>>>- The MEP MAY be implicit in the URI used to deliver the message
>>>>
>>>Not keen on this one as it overloads (conflates?)
>>>identification the next
>>>recipient with of an immediate destination (of a hop) with
>>>denotation of the
>>>MEP in use.
>>>
>>>
>>>>- In situations where more than one MEP is used in conjunction with a
>>>>single destination address, the SOAPMessagePattern HTTP
>>>>
>>>header MUST be
>>>used
>>>
>>>>to identify the MEP.
>>>>We could instead go with your suggestion that HTTP depend on
>>>>
>>>a header in
>>>
>>>>the envelope.  I'm nervous that you don't really want to
>>>>
>>>parse the XML
>>>
>>>>before making the determination.  I'm also a bit nervous
>>>>
>>>about more HTTP
>>>
>>>>headers, but on balance I think we need something outside the
>>>>envelope.
>>>>
>>>If we're going to mark the difference (which I think we should
>>>if a binding
>>>supports multiple MEPs) then yes, I think it needs to be outside the
>>>envelope too.
>>>
>>>
>>>>In any case, I really do think the framework should make it the
>>>>responsibility of the binding to convey the MEP in use (explicitly or
>>>>implictly -- for example, if a binding only supports one MEP,
>>>>then there is no need to send anything with the message).
>>>>
>>>What do you
>>>
>>>>think about this approach?
>>>>
>>>+1
>>>
>>>
>>>>------------------------------------------------------------------
>>>>Noah Mendelsohn                              Voice: 1-617-693-4036
>>>>IBM Corporation                                Fax: 1-617-693-8676
>>>>One Rogers Street
>>>>Cambridge, MA 02142
>>>>------------------------------------------------------------------
>>>>
>>>>
>>>regards
>>>
>>>
>>>Stuart
>>>
>>>
>>>
>

Received on Tuesday, 29 January 2002 08:08:33 UTC