RE: What is a SOAP Message

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.

...

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.


> -----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/>

Received on Thursday, 13 February 2003 00:22:33 UTC