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

>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.

In order to do a "message-poll", one has to do the polling with
something - in this case it is an HTTP request. This means that the SOAP
message is taking part in a MEP that contains an HTTP request with no
SOAP and an HTTP response with SOAP. As Chris has pointed out, the state
machine is similar in many ways to the req-res MEP, the only difference
is really that the request doesn't contain any SOAP.

If no SOAP is involved at all then, as you say, we have nothing to say
about it.

><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.

Absolutely the latter.

>Now you've confused me... I thought that the RPC conventions 
>make use of
>message exchange patterns provided by the messaging framework...

IMO, the messaging framework is just a framework--it doesn't define any
MEPs or bindings. In part 2 of the SOAP 1.2 spec, we define some useful
instances of bindings and MEPs but they are not part of the core
messaging framework described in part 1. I was referring to part 1.
 
>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.

Yes, the request side of an HTTP GET request/response is an example of a
non-SOAP message. Likewise, I can imagine (although I don't think we are
actually considering this) that it is potentially possible to have a
SOAP HTTP request followed by a non-SOAP HTTP response (a GIF if you
like).

>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.

Right.

Henrik

Received on Thursday, 30 May 2002 20:32:57 UTC