Re: HTTPSOAP - was SOAPAction Proposal

I agree. What I was trying to say before is much along these lines;
some (but not all) applications will not require parameters on
requests, or will be able to encode simple parameters in URIs and/or
traditional forms. The response can be a SOAP message, which can be
handed off to a SOAP processor, or processed by in-browser XML tools
(perhaps with some javascript).

This is sort-of one-way messaging, in that SOAP encoding/envelope,
etc. is only used one-way.

Cheers,



On Sat, May 05, 2001 at 03:20:56PM -0500, Kurt Cagle wrote:
> 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
> > ------------------------------------------------------------------------
> >
> >
> >
> 

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

Received on Friday, 4 May 2001 20:04:37 UTC