RE: TAG document: SOAP HTTP GET binding available

Modelling a GET interface in WSDL is fine, but we may need to deal with it 
in SOAP as well.  Why? I think it depends on where you think SOAP 
processing is to happen. 

First question:  are there SOAP nodes at both ends, only at the requesting 
end, or neither?  Specifically, where do you expect the SOAP processing 
model to apply.  Let's take the response to the GET first.  If it's a SOAP 
envelope, is there mustUnderstand checking, etc.  If that's what you want, 
you need a SOAP binding and a message exchange pattern to specify at the 
SOAP level what the processing and message flow rules are.

Now, consider the request.  You might want to do a get from a node which 
is not a SOAP processor.  In this case, the only SOAP message is the 
response.   However, it's perfectly coherent to say that you want the GET 
itself to be a SOAP message, perhaps so that you can relay it past an 
intermediary, and perhaps through a second hop that need not be HTTP (this 
will be a moderately common scenario in corporate environemnts, IMO).   In 
this case, you need to make sure that the HTTP GET actually represents a 
request at the SOAP level as well.   The proposal that I've made for a 
REST:GET soap body element provides this.

So, we need to decide which cases we want to support, and design 
accordingly.  In many cases, a SOAP binding will be required.  A WSDL HTTP 
convention is complementary, but does not necessarily solve the whole 
problem.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Saturday, 11 May 2002 21:00:06 UTC