RE: [getf] Proposal for Web-friendly representation of RPC's in SOAP

Hi all

On Thu, 30 May 2002, Williams, Stuart wrote:
> > -----Original Message-----
> > From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> > Sent: 30 May 2002 00:10
> > To: noah_mendelsohn@us.ibm.com; xml-dist-app@w3.org
> > Subject: RE: [getf] Proposal for Web-friendly representation
> > of RPC's in
> > SOAP
> >
> > I think there are many good points in this... I have tried to summarize
> > my comments rather than scattering them throughout. If there is some
> > agreement then I think we can quite easily provide updated wording.
> >
> > 1) We should make a sharp distinction between the SOAP HTTP binding and
> > the RPC convention. One can happily live with the SOAP HTTP binding
> > without using RPC. I don't think this is much different from what you
> > write already but I think should be kept as clear as possible.
>
> +1
>
> > 2) When you say that one should use PUT for creating a resource, we
> > should make it clear that this doesn't involve a SOAP message as such.
> > The semantics of PUT is that the entity-body in the request represents
> > the state of the resource to be created. If the operation succeeds and I
> > perform a GET I get the resource that I just PUT. The PUT request
> > doesn't "execute" the SOAP message. The reason I said "as such" is that
> > it is of course perfectly valid to PUT a SOAP message and subsequently
> > do a GET on it.
>
> If this "doesn't involve a SOAP message as such." what has it got to do with
> SOAP?

One possible related scenario: the use of the SOAP Encoding data format as
a stand alone data format, outside of SOAP as-xml-protocol interactions with
some specific service. I'm using it in this way: I have a directory full
of 'software_package_name_soapenc.xml' files on my Web server, also
available in a tar.gz bundle. Each soap-encoded document describes a
software package. Using SOAP Encoding is nice as these XML docs can be
turned into running Java/Perl/Ruby really easily; but I'm not using
SOAP-as-protocol. HTTP PUT, or even WebDAV, is a fine mechanism for
interacting with such documents.

The SOAP spec doesn't call out such uses (in fact we had to strip out the
protocol stuff from the SOAP-Enc'd instance data, so we may be at odds
with the spec). Maybe it should? Seems a cheap way of using pure HTTP (per
the REST lobby's concerns) while also exploiting a major chunk of the SOAP
specification.

I'll send feedback on this work after the next Working Draft is published.

> This seems like regular HTTP, using PUT to write to some storage and GET to
> retrieve it. Don't really understand why we would have to say anything at
> all about this, other than remind folks that the can use HTTP as HTTP. 'The
> PUT request doesn't "execute" the SOAP message.' implies that the SOAP
> message processing model does not apply which IMO further reinforces the
> notion that this usage is plain HTTP with a SOAP message as a content format
> - nothing more.
>
> I'm not arguing against regular HTTP, just that SOAP is something different
> - but then, maybe the title of part 1 doesn't mean anything.

What about SOAP part 2?

The encoding bits of SOAP are something different. SOAP encoding --
basically just defines another Web data format that is
particularly useful in protocol contexts. SOAP Encoding is a *big* and
complex part of SOAP to implement, test; if it can't be used outside of
SOAP protocols (eg. in normal HTTP transactions) we have something of a
re-use problem. SOAP 1.2 would be greatly simplified if Encoding were
relegated to a separate Note (personal view); if it is to stay, it should
imho earn its place by being re-usable as a doc format in pure HTTP apps.

To say that pure-HTTP apps have nothing to do with SOAP ignores the hidden
value of the Encoding / part 2 section of the SOAP 1.2 draft.

[....]
> Well... in that case I think we have stepped outside of the "SOAP 1.2 part 1
> Messaging Framework" and we are doing HTTP with SOAP Messages just another
> content format.
>
> If that's what we want to do... we should say so... but I wouldn't then wish
> to call it a messaging framework.

Implementor feedback preview: this is *exactly* what I'm doing. It is useful.

> I don't think it is our role to describe the behaviour of things that are
> not SOAP nodes.

Please try to describe the meaning of SOAP Encoding documents
independently of processing scenarios. Having a working group try to
imagine all likely processing scenarios for a data format is risky.
Consider XSLT, and the massive re-use of it that we've seen that go way
beyond original goals as a styling mechanism. SOAP Encoding could enjoy a
similarly rosy future if specified in a way that doesn't try to
second-guess the uses that the Web community will find for it.

cheers,

Dan


-- 
mailto:danbri@w3.org
http://www.w3.org/People/DanBri/

Received on Thursday, 30 May 2002 05:51:24 UTC