RE: Roy's ApacheCon presentation

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, November 20, 2002 9:32 AM
> To: Anne Thomas Manes
> Cc: www-ws-arch@w3.org
> Subject: Re: Roy's ApacheCon presentation
> 


> If you don't buy that argument, would you agree that having less
> interfaces means easier integration?  i.e. that it's easier if all the
> insurance companies agree on a standard interface than it would be if
> they didn't? 

I don't see any evidence that this is true.  CORBA, HTTP,  etc. 
deal with the protocols for shipping data around; IDL and WSDL 
deal with interface definitions, XML deals with the data format
and encoding issues.  All these standards are nice, some are 
more widely supported and intrinsically interoperable than others,
but all are ultimately just pipes for getting data from one application to
another. (Yes, I know, that's the "tunneling heresy. So burn me at the
stake!)

> If so, would you also agree that if banking and CRM
> companies could agree to wrap themselves in the same interface, that
> this would further reduce integration costs?  And if yes to that, then
> wouldn't the ultimate interface be one that could wrap all systems?

I'm afraid we have to get into the S-word ("semantics" ... shudder).  
CORBA assumes that someone has mapped the meaning of of the interaction
onto methods and arguments, REST assumes that the meaning of the interaction
is encoded as a "document".  I simply can't get excited that either is the
"ultimate interface."  Both are hard problems for machines.  Both are
O(N**2) if done poorly and O(N) if done extremely cleverly.

I can see practical, mechanical reasons why using URIs as identifiers and
employing the generic HTTP methods is a good a scalable platform for moving
data around.  I don't buy the argument that conceptualizing that data as
methods and arguments is intrinsically less suitable to integration than
conceptualizing that data as "data". AFAIK, the important principles in
designing universally interoperable systems include loose coupling,
appropriate modularity/granularity, and asynchrony.  One can build
tightly-coupled, too-fine-grained, synchronous REST applications, and one
can build loosely-coupled, coarse-grained, asynchronous distributed object
systems.  

Let's focus on the principles that matter, not the red herrings.... and
after a year of debate I'm more and more convinced that the distinction
between encoding semantics as methods and arguments vs encoding semantics as
data is a red herring.   I *do* think that it's probably Best Practice to
use a document-oriented rather than distributed object-oriented conception
of that data, but that has to do with the loose coupling principle not the
generic interface principle.  I do think that it's Best Practice to move the
data around with operations that map easily onto GET/PUT/POST/DELETE (aka
CRUD, or SELECT/INSERT/UPDATE/DELETE ...) but that is a practical matter of
interoperability across the Web, filesystems, and SQL databases.

Received on Wednesday, 20 November 2002 10:25:39 UTC