RE: [getf] Proposal for Web-friendly representation of RPC's in SOAP

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 30 May 2002 15:58
> To: Williams, Stuart
> Cc: noah_mendelsohn@us.ibm.com; xml-dist-app@w3.org
> Subject: RE: [getf] Proposal for Web-friendly representation 
> of RPC's in
> SOAP
> 
> >>2) When you say that one should use PUT for creating a resource, we
> >>should make it clear that this doesn't involve a SOAP message as such.
> >>The semantics of PUT is that the entity-body in the request represents
> >>the state of the resource to be created. If the operation succeeds and I
> >>perform a GET I get the resource that I just PUT. The PUT request
> >>doesn't "execute" the SOAP message. The reason I said "as such" is that
> >>it is of course perfectly valid to PUT a SOAP message and 
> subsequently
> >>do a GET on it.
> >
> >If this "doesn't involve a SOAP message as such." what has it 
> >got to do with SOAP?
> 
> This is exactly my point - I tried to call this out explicitly in bullet
> 5)
> 
>   5) In many ways, I think the proposed text conveys the difference
>   between HTTP and RPC rather than SOAP. As such it seems more to be a
>   description of how to use HTTP vs. RPC than a description of how to use
>   SOAP. Maybe having it in a section called "RPC and the Web" or some
>   such?

Ok, good... then I think we are in tune with each other on this.

> The first point is that HTTP PUT has been defined with semantics that
> defines the role of the entity-body in a request and we as SOAP folks
> can't change that.

Absolutely...

> The particular semantics of HTTP PUT doesn't allow
> for execution of the body which means that there is little SOAP
> involved. However, there are other methods that do allow for extra
> semantics and this is where we can add SOAP semantics.
> 
> The second point is that we have to enable SOAP to be used in
> combination with MEPs that contain messages that are not SOAP. That is,
> we have to enable the possibility that one can do a normal HTTP GET
> (non-SOAP) and get back a SOAP message in the HTTP response. For the
> specific SOAP HTTP binding we are not just using SOAP as a media type
> but deploy it in places where HTTP allows us to. This doesn't mean that
> SOAP isn't a protocol or anything like that - just that SOAP and HTTP
> can be used only in certain combinations together.

Hmmm... lost the drift somewhere in the middle. The way i interpret what I
think we are proposing with respect to GET and SOAP is an MEP that we might
call a "message-poll" that uses a binding specific mechanism for a SOAP node
to solicit a (SOAP?) message from another SOAP node (referenced by URI). I'm
not at-all sure where the "non-SOAP" message comes in - but I think that
probably just a difference in the way we (you and I) try to explain
essentially the same thing. It's also plausible that the result of such a
poll is not a SOAP message, but some 'ordinary' HTTP GET response with
something else in it. In those circumstances, I don't think we have anything
to say other than... it means whatever it would mean as an HTTP GET
response.
 
> >> 3) HTTP POST has been explicitly defined to deal with "extraneous"
> >> semantics and can carry parameters such as the ones  defined by a SOAP
> >> message. There are only a few other methods like OPTIONS that enables
> >> this. That is, it is not the case in HTTP that the entity-body always
> >> can be used to carry additional parameters, it is up to the particular
> >> method.
> >
> >Is that:
> >
> >a) not all HTTP methods allow an entity-body in the HTTP 
> >request message, or
> >
> >b) of those HTTP methods that do allow an entity-body in the HTTP
request,
> >not all such methods allow additional parameters to be carried in that
> >entity body.
> >
> >If b) (or a and b) what constitutes 'a parameter' in once sense the whole
> >entity body is a complex parameter to the HTTP method. The narrative of
> >RFC2616 places some very 'fuzzy' restrictions on the sort of information
> >that might be conveyed in particular entity bodies. But it's not clear to
me
> >what is meant by "additional parameters" and what HTTP method based
> >restrictions apply to the particular content of an entity body.
> 
> In HTTP 1.1 it is really only OPTIONS and POST that have been defined in
> a manner that allows for execution of an entity body in the request.

Ok... I was really wanting to understand you specific use "additional
parameters" in:

<quote>
That is, it is not the case in HTTP that the entity-body always
can be used to carry additional parameters, it is up to the particular
method.
</quote>

I was wanting to understand whether you were talking about the availability
of an entity-body on an HTTP request, or if you were talking about
constraints on what such an entity body is allowed to contain/be used for.

> >> 4) As to what HTTP method one is to use, I think we should leave that
to
> >> the HTTP spec as it defines the semantics of its methods. To me, the
> >> absolutely most important part is that it is ok to use SOAP in
> >> combination with HTTP in ways that doesn't require a SOAP message in
the
> >> request AND a SOAP message in the response.
> >
> >Well... in that case I think we have stepped outside of the "SOAP 1.2
part 1
> >Messaging Framework" and we are doing HTTP with SOAP Messages just
another
> >content format.
> >
> >If that's what we want to do... we should say so... but I 
> >wouldn't then wish to call it a messaging framework.
> 
> I think the specific text that Noah proposed is intended for the HTTP
> binding and the RPC convention in part 2. That is, it is not part of the
> messaging framework but a specific instance of a binding and the RPC
> convention.

Now you've confused me... I thought that the RPC conventions make use of
message exchange patterns provided by the messaging framework...
 
> >> 5) In many ways, I think the proposed text conveys the difference
> >> between HTTP and RPC rather than SOAP. As such it seems  more to be a
> >> description of how to use HTTP vs. RPC than a description of how to use
> >> SOAP. Maybe having it in a section called "RPC and the Web" or some
such?
> >>
> >> 6) I agree that we should not provide a mapping of SOAP into URIs as
> >> this is IMO not the point of this exercise. Rather, it is to enable
SOAP
> >> usage in combination with non-SOAP messages.
> >
> >Oh... I thought that the point was to encourage the use of URIs as the
means
> >of identifying resources and to provide a means of making use of HTTP GET
to
> >do things that are known to be 'safe' within HTTP binding for the SOAP
> >Messaging Framework.
> 
> We do that by enabling use of HTTP GET (or any other protocol that
> supports similar semantics). It is specifically targeted the SOAP HTTP
> binding, not the binding framework as such. The point is that HTTP GET
> doesn't really include SOAP so we have to describe how that works.

Ok... I think the problem term is "non-SOAP messages". I took you to be
meaning things that might be gifs, jpegs etc. I now think its plausible that
you are meaing the request side of an HTTP GET. If that is indeed what you
mean then I think we are on the same page, we just speak it differently.

> >I believe that we primarily need to describe the behavior of SOAP nodes
> >interactiong with SOAP nodes. 
> 
> Well, I think the idea is that a SOAP node can interact with other
> things than strict SOAP nodes like for example an HTTP client that sends
> a GET request forcing a SOAP message to be generated in the response.

That's Ok... my point (which is the one that follows) is that in such
circumstances we cannot be describing the behaviour of the HTTP client -
that already been done (elsewhere). It also not clear that the responding
SOAP node can even tell that the client is *not* a SOAP node.

> >I think its also important that we discuss the behaviour of a SOAP node
when
> >interacting with something that is not a SOAP (if indeed it is possible
for
> >a SOAP node to tell the difference). 
> 
> Yes - although I think this is what Chris has been working on - the
> point of Noah's text is IMO more to describe the difference 
> between RPC and HTTP.
> 
> Henrik

Cheers,

Stuart

Received on Thursday, 30 May 2002 12:35:02 UTC