RE: What is a SOAP Message

At 09:20 PM 2/12/2003 -0800, David Orchard wrote:

>As most people don't believe me when I talk about REST, I'll quote an
>exchange between myself and Roy
>
>DO: Can representations be transferred over protocols other than http, say
>ftp?
>
>RF:Yes. Any shared memory by message passing system is dealing in
>representations,
>though most are constrained to a particular implementation.

With all respect due Roy, shared memory is absolutely not what is
behind the interaction of machines on the Web.  High on the
list of reasons for Web success is the powerful combination of distrust
and tolerance exhibited by clients and servers.  "Shared memory" implies
a deeply common understanding of symbol forms and meanings by the
sharers.  That's why shared memory systems require tight central 
administration.
The Web is not a "hive mind" but a collection of savvy skeptics
with mutual interdependent interests.  That's why the Web can succeed at
spontaneous interaction without central administration and strict version
control.

That said, of course other protocols could adopt a representation/resource
model.  But to go the other direction and claim that every protocol between
machines fits that model makes "representation" useless to us.


>...
>
>RF:  The representation is a moment in time.  A resource is a source
>for some future time.  What you
>mean to say is that ftp constrains the semantics of resources to its
>set of commands that mimic a filesystem.  In practice, however, the
>response to ftp get isn't any more constrained than HTTP GET, since the
>ftp interface of "file" is that of a Unix file "sequence of bytes", and
>thus may be implemented any number of ways on the back-end.  The real
>difference between the two is that an ftp client needs to know how
>to cd around the ftp server's namespace, whereas the path in HTTP is
>always absolute, and that ftp metadata requires additional commands
>rather than being supplied by header fields.

Again I will point out that representation/resource is a conceptual model
that explains part of how the Web differs from, for example, shared file 
systems.
The intent of FTP is, by its design and typical uses, to transfer 
files.  If you
use FTP to PUT and then FTP to GET, you expect the bits to be unchanged.
If they change, you are surprised.  If you use HTTP to POST and HTTP to GET,
you have no such expectations.  No one needs HTTP PUT because it implies
a semantic we can get other ways.  POST/GET are magically precisely
because they do not transfer files.  The possibility of creating an FTP server
that acted like an HTTP server does not change the fact that no one would
find such a beast valuable.



> > -----Original Message-----
> > From: xml-dist-app-request@w3.org
> > [mailto:xml-dist-app-request@w3.org]On
> > Behalf Of John J. Barton
> > Sent: Wednesday, February 12, 2003 4:37 PM
> > To: David Orchard; xml-dist-app@w3.org
> > Subject: RE: What is a SOAP Message
> >
> >
> >
> > At 02:00 PM 2/12/2003 -0800, David Orchard wrote:
> >
> > >Interesting.  I think we might have a disagreement about the scope of
> > >representations.  I assert that in ALL cases of messages
> > using the HTTP
> > >binding, a representation is transferred.  Not just for the WebMethod
> >
> > As I understand "representation" in the web context, the phrase
> > "a representation is transferred" weakens the critical meaning of
> > representation as an instantiation of a resource.
> >
>
>?  The concept of representations/resources/identifiers is more than just
>HTTP.
>A representation is the state of a resource.  And a resources is an
>arbitrary "thing".
>
> > >feature wrt SOAP.  In the case of a "non-RESTful" SOAP
> > usage, such as the
> > >classic getStockQuote inside a POST, there is still a
> > representation being
> > >transferred.  This is exactly similar to an HTML POST of a
> > form, where a
> > >representation of a form is transferred, and then a representation is
> > >returned.  So REST isn't limited to just WebMethod IMO.
> > >
> > >I further assert that whenever URIs are used, representations are
> > >transferred.  HTTP is indeed designed to be extremely
> > friendly to REST
> > >transfers, but representation transfer isn't limited to
> > HTTP.  For example,
> > >ftp transfers lack the ability to add the representation and message
> > >metadata that HTTP supports using HTTP headers.  But it is still a
> > >representation transfer.
> >
> > In my opinion FTP does not and cannot transfer representations.
> > That is why they call it the **FILE** transfer protocol.  It does not
> > transfer representations of resources.  It transfers files.
> > Its intent is
> > quite different from HTTP and this difference is exactly why
> > "representation" was invented.
> >
>
>See above.
>
> >
> > >My point is that there is a distinction between transferring
> > >Representations, and following the REST constraints.  I know
> > that might seem
> > >a little strange.  But the case of the HTML POST is what
> > really cleared
> > >things up for me.  The POST result isn't "on the web"
> > because you can't
> > >"GET" it, but so what?  It's still a web page, and
> > representations are
> > >transferred.  Just because the resource isn't "on the web",
> > doesn't break
> > >the idea that representations are transferred between resources.
> >
> > As I understand them, representations are returned by
> > servers. Web resources
> > cannot transfer or be transferred so I don't know what the phrase
> > "representations are transferred between resources" could mean.
> >
>
>I'm thinking of the notion of 2 servers exchanging messages.  From each
>other's POV, they are sending and receiving representations.  Therefore,
>there must be resources on both sides.  In the case of an HTML FORM, the
>resource is on the web browser side, and the browser sends a representation
>of the form to the web server.  From the web server's perspective, it can
>only see the representation.  A user could easily change the FORM, and thus
>the Resource, but until it is posted, the receiver doesn't know.  That's the
>point that Roy is making about "at a point in time".  And how the resource
>exists for some future time - typically until I shut down my browser.
>
> >
> > >Now I must admit I haven't thought through the notion of
> > representations
> > >over TCP or UDP.  I guess if they don't have URIs, then they
> > wouldn't be
> > >about representations....  I'll have to ponder that.  That
> > might be an
> > >interesting boundary condition.
> >
> > Representations do not have URIs over HTTP either.
> > Representations are
> > not a concept that apply at the socket level so you can't
> > find any boundary
> > there.
>
>Fair enough point, I should have said resource.
>
> >
> > The closest analog for the representation/resource pair that
> > I know is the
> > OOP concept of implementation/interface.  Trying OOP on every single
> > application design is ok, but it won't always be the most appropriate
> > approach.
> >
> > As far as I can see a SOAP message need not represent any resource
> > and it rarely would be one of many alternative representations for a
> > resource.  The connection of SOAP to Web is just the use of similar
> > technology (XML, HTTP, and URIs).  Its just a different thing.
> >
>
>I disagree.  The representation/resource model is sufficiently powerful to
>model all SOAP messages.  And much more.
>
>What I think is happening is that people have too narrow a view of what
>representations, and indeed resources, are.
>
>Hence why I believe that Web services fits in quite nicely into discussions
>about representations, resources, etc.  I actually believe the two
>architectures work very well together, but it takes a bit of a broadening of
>the general understanding of representations to accomplish this.
>
>And before you think that I've suddenly turned to the dark side (or the
>light side depending upon your POV), I still totally believe in SOAP, WSDL,
>Choreography, etc.
>
>It's just that I don't think too many people on the Web services side have
>had the chance/time/etc. to really to fit these architectures together.  And
>to do so in a rigorous fashion, such as going through Roy's thesis and
>coming up with an architectural style that explains "service oriented
>architecture" in terms of properties, constraints, representations,
>resources, etc.  Which I've been doing over the past few weeks, and will
>post soon to ws-arch.
>
>Cheers,
>Dave
>
>
><snip/>

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Thursday, 13 February 2003 12:46:18 UTC