RE: REST wrap-up (was Re: Web Services Architecture Document

+1

-----Original Message-----
From: Thompson, Bryan B. [mailto:BRYAN.B.THOMPSON@saic.com]
Sent: Monday, 9 February 2004 23:22
To: 'Mark Baker '; 'www-ws-arch-request@w3.org '; 'Jim Webber '
Cc: 'www-ws-arch@w3.org '
Subject: RE: REST wrap-up (was Re: Web Services Architecture Document



I am interested to see how this looks in 3-5 years.  Like J2EE?

To date, my experience with using SOAP in distributed systems is that
it was too underconstrained.  There was simply too much architecture
that needed to be specified before it could be useful - and everyone
wanted to do it differently.  E.g., what metadata is sent with a message,
how is the message centric processing (where the message has an id and
is carried along with modifications) interleaved and integrated with
resource centric processing (where the state of the resource is what is
identified and evolves over time).  How do we get uniform addressing for
resources and web services?

What I saw was people trying to re-create the basic architectural
constraints for a distributed application.  Each time differently,
and, frankly, without the depth in practical experience that drove
the internet protocol engineering efforts.  Nothing in my experience
suggested that this was going to translate into a win across SOAP
architectures realized by different groups.

-bryan

-----Original Message-----
From: www-ws-arch-request@w3.org
To: Jim Webber
Cc: www-ws-arch@w3.org
Sent: 2/9/2004 1:22 AM
Subject: Re: REST wrap-up (was Re: Web Services Architecture Document


On Mon, Feb 09, 2004 at 05:07:10AM -0000, Jim Webber wrote:
> I don't necessarily think that Web Services will be used for Internet
> scale systems, at least not at the same Internet scale that the human
> web is at.

Well, I'd like to see the day when its possible for information systems
around the world to be able to be integrated ad-hoc.  Anything less than
that just isn't an Internet scale integration solution, IMO.

> However I do not believe that laying down a foundation that
> consists of messages (which are sent and received) is in any way
> detrimental to building such systems, after all I can build "your
> architecture" using those primatives, no?

Sure.  But consider NFS.  It's built on top of ONC RPC.  But do you see
NFS clients and servers interoperating with other ONC services?  Nope,
you
just see them talking to other NFS clients and servers.

I could be wrong on this point, because my experience on this is fairly
limited.  But my current position, if you're interested, is that a
common messaging layer *is* detrimental from a performance POV.
Consider NFS again.  It would really be a much better protocol if it had
its own messaging layer which was optimized for the needs of distributed
file sharing, rather than one optimized for RPC.

A common messaging layer *does* save you some coding though, but it
seems to come at the cost of performance, and without the improvement in
interop that many might expect.  But I'd be happy to be proven wrong.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca