RE: SOAPAction Proposal

I would like to make a strong distinction between 3 issues.

1) Serializing: Turning a complex data-object into a 1-dimensional stream
2) Marshalling: Turning a method-invocation, procedure-call or function-call
into a 1-dimensional stream.
3) Delivery: Moving such a stream across time and space from one end-point
to another.

Issue 1 can be solved (in XML) using a specific name-space for a specific
application domain, or using a generic name-space like wddx.

Issue 2 can be solved (in XML) using something like SOAP, which specifies a
name-space for writing method-invocations, replies and events. However, you
still need to serialize parameters of complex datatypes. SOAP *should not*
specify any restrictions on which serialization mechanism is used (other
then "XML-based").

BTW. how do we serialize binary data? Using uucode or base64-code? That way,
we could even use proprietary (non-XML) serialization mechanisms and encode
them using uucode or base64-code.

Issue 3 is completely separate from issue 1 and 2. *How* we deliver
XML-marshalled data, e.g. SOAP-payload, *must not* be known from within such
a payload. The SOAP message must not be aware that it's being sent using
HTTP for example. The payload should not contain knowledge about its
end-point. It's up to the delivery mechanism to insert the payload inside an
envelope and add a delivery mechanism specific header to specify the
end-point and add other routing information.

Of course, the full SOAP specification may contain both the definition of
SOAP-payload, as well as a prescription of how to use SOAP-payload within
HTTP. But all HTTP headers must be separate from the payload. There should
be no information in the headers, other than routing information, that is
not available in the payload. There should be no information in the payload
that is HTTP related (this includes things like a URI).

The URI that identifies the end-point of a SOAP message should only identify
a service, that implements an interface of several different methods. We do
not need a separate URI for every method. At least, not in relation to XMLP
(like SOAP). We could develop a completely different marshalling protocol,
not based on XML, but based on HTTP, that uses a fully qualified URI
including function identification and parameter passing. Why not? But that
would not be XMLP! That would be a different marshalling protocol which is
based on a specific delivery mechanism (HTTP). But the point of XMLP is to
be delivery mechanism independent (even though there is a strong emphasis on
HTTP).

Pascal Rottier

Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottier@nl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascal@pmintl.ch



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



I'm still trying to formulate my opinion, but I do notice that URI
fragment identifiers, path paramenters and queries (as you mention),
as well as things like xpointer seem to make this possible, or at
least worthy of consideration.

It's also interesting because one of our pseudo-requirements was to
make it possible to use XMLP from browsers. To me, one compelling way
to do this is with a normal GET HTTP request to a URI, with an XMLP
response.

Cheers,


On Fri, May 04, 2001 at 11:33:47AM -0400, Noah_Mendelsohn@lotus.com wrote:
> 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
> ------------------------------------------------------------------------
> 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Monday, 7 May 2001 09:05:00 UTC