W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

RE: SOAPAction Proposal

From: Corda, Ugo <Ugo.Corda@usa.xerox.com>
Date: Fri, 04 May 2001 14:35:13 -0700
To: "'Noah_Mendelsohn@lotus.com'" <Noah_Mendelsohn@lotus.com>
Cc: Mark Nottingham <mnot@mnot.net>, xml-dist-app@w3.org
Message-id: <0670B83B1F99D2118DAF00805F6505C90448555F@USAESMS1>
I found it interesting to see at how a popular SOAP implementation handles
all this stuff. I took a look at the Apache SOAP implementation and the IBM
WSDL toolkit (which uses Apache SOAP, the open-source derivation from the
original IBM SOAP4J implementation).

When I create a WSDL service description out of a Java class using the
serviceWizard tool from the WSDL toolkit, the tool creates a URN used to
identify the service. That same URN is assigned both to the SOAPAction
attribute in the WSDL SOAP binding and to the input and output parameter
namespaces of the same SOAP binding.

Using another tool from the WSDL toolkit, I can then create a client SOAP
proxy out of the WSDL service description. This proxy generates SOAP
messages which use the same URN mentioned before to identify both the
SOAPAction value and the SOAP body entry's namespace (the one used to
qualify the operation's name). The proxy code, by the way, uses a variable
named "targetObjectURI" to refer to the URN that will end up to be the SOAP
body entry's namespace.

Finally, the WSDL toolkit also generates a so called Deployment Descriptor,
which is an XML file that describes how a service is implemented on the
server under Apache SOAP, whether as a script module or as a Java class, and
contains a pointer to the implementation code. Once again, this Deployment
Descriptor contains an ID parameter whose value is the same URN mentioned

The SOAP/HTTP message issued by the client proxy always contains a header
URL which targets a servlet called "rpcrouter" (the Apache SOAP entry point
for any SOAP RPC call) regardless of the particular method/service invoked.
When the rpcrouter servlet receives the message, it looks inside the SOAP
message, extracts the body namespace URN, and then uses that URN to identify
a particular Deployment Descriptor (which it will use to dispatch the SOAP
call to the code implementing the service, Java class or script). From what
I was able to see, the SOAPAction value plays no role whatsoever in this
dispatching process on the server.

To summarize, the IBM/Apache SOAP implementation uses the following:

- HTTP URL: it targets the rpcrouter servlet (not a specific service or
- SOAPAction: it uses a URN whose meaning seems to be the "target object";
it does not seem to be used by the SOAP implementation
- SOAP body entry's namespace: it's used to identify the "target object" for
the SOAP call (i.e. the Apache Deployment Descriptor , which in turn is used
to locate the implementation code for the requested service).

All this seems reasonable to me (i.e. our XML Protocol spec should allow for
this type of implementation approach), except for the use of the Body entry
namespace to identify the "target object". This looks to me like a hack,
introduced because of the fact that SOAP 1.1 does not clearly provide a mean
of identifying a "target object", and at the same time does not clearly
specify, in my opinion, the allowable interpretations of the namespace used
to qualify the operation name in the body.

Ugo Corda
Xerox Research & Technology

-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: May 04, 2001 8:34 AM
To: Mark Nottingham
Cc: marting@develop.com; xml-dist-app@w3.org
Subject: Re: SOAPAction Proposal

Mark Nottingham writes:

>> One of the comments that has come up re: SOAPAction 
>> and SOAP services in general is that making multiple 
>> methods/services available on the same URI (e.g., 
>> depositMoney, withdrawMoney on http://www.bank.com/service) 
>> is fundamentally at odds with the Web architecture, 
>> because all services/resources available on the Web
>> (including Web Services) should be able to be identified by a
>> (singular) URI.

I am sympathetic in principle to this view, but doesn't it force us to:

a) decouple related methods on a conceptually single resource?  e.g. I 
have a file resource, should I have separate URI's to which to send a 
status check like (getLength) vs. a request like (read) or an operation 
like (delete)?  I think it's reasonable to assume that one wishes to do a 
variety of operations on a given resource.  Yes, in some sense the web 
architecture is that everything, and this in principle every operation 
should (be able to) have its own URI.  I'm less convinced, for the reason 
just stated, that one would necessarily send the request to that URI. 
Indeed, in the SOAP architecture, the namespace qualified name of the 
operation (typically in the body) seems to serve the role of uniquely 
identifying the nature of the service.

b)  Taken to its logical conclusion doesn't this require a separate URI 
for every combination of parameters to the service?  After all, the value 
of my bank account last week is a web resource, the value this week is a 
(smaller) resource, etc.  If we really say that everything has a URI, then 
surely there is a resource for last week's state and for this week's? 

So, I think it is indeed useful to be able to name services (or methods if 
you like)  at a quite fine grain, to give them descriptions, etc.  I am 
less convinced that just because a "method" is nameable with a URI that 
one would necessarily send a SOAP request to that URI to invoke the 
service.   Now, one way to deal with this (which I think would be cool in 
principle) would be to encode the SOAP call after the "?" in a URI.  I'd 
like to explore that as an option sometime, but in practice there are 
length restrictions on URIs, etc. that make this somewhat problematic.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Friday, 4 May 2001 17:35:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC