W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: One-way messaging in SOAP 1.2

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Tue, 29 Jan 2002 13:49:17 +0100
Message-ID: <3C569A4D.DD8763A3@crf.canon.fr>
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
CC: "Williams Stuart" <skw@hplb.hpl.hp.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, "Christopher Ferris <chris.ferris" <chris.ferris@sun.com>, "marc.hadley" <marc.hadley@sun.com>, xml-dist-app <xml-dist-app@w3.org>, Jean-Jacques Moreau <moreau@crf.canon.fr>
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 07:52:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT