HTTPSOAP - was SOAPAction Proposal

I am something of a lurker on this group, but this discussion has hit
something of a raw nerve for me.

The XML Protocol discussion frequently tends to use as a base assumption the
notion that all meaningful transactions will be passed via SOAP messages. I
would agree that in ten years (maybe) when all the browsers and current PDAs
out there have migrated to an XML baseis that this is a reasonable
assumption.  Until then, however, the vast majority of devices out there
currently do not communicate via XML messages, but rather by the same 10+
year old Post/Get HTTP protocol.

This wouldn't be such a gripe, except that by segmenting the two, you get
some really bizarre juxtapositions:

* Almost all form information is sent via a POST mechanism, which would lend
itself perfectly to a SOAP container. Yet so far I've seen very little
effort to look at mapping such posts into a standard SOAP protocol.
* In order to utilize SOAP from a browser, you have to instantiate some form
of HTTP socket and send the information this way, which necessarily means
tying XML to some form of scripting language. However, browsers (whether of
the HTML type or of the smaller handheld types) will still be the vehicle
that makes use of the largest number of web services for years to come.
* Because of the second contention, SOAP places a burden on such devices to
also support scripting capability.

To me, it would seem to make sense to develop at the very least an interrim
bridge SOAP protocol that can be invoked via a URL mechanism.  Such a
service might be relatively limited in some respects -- it might lack
authentication support for instance, and hence only work for "public"
services, but its a start. Otherwise, I think that what's going to happen is
that SOAP will develop as a high tier service for business consumption that
never permeates to the level of the individual; as one of the big "selling
points" of such web services is that it will enable the development of
solutions that benefit these same individuals, I have to wonder if there
isn't some disconnect here.

Okay, enough for my rant. Engaging cloaking shields.

-- Kurt Cagle

----- Original Message -----
From: <Noah_Mendelsohn@lotus.com>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: <marting@develop.com>; <xml-dist-app@w3.org>
Sent: Friday, May 04, 2001 10:33 AM
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 18:25:58 UTC