Finding the Intersection ...

[speaking as a member, not from the Chair, and sorry for the length!]

The discussions about REST and the Web Architecture illustrate a challenge
that we are going to have to face up to in defining a reference architecture
for web services:  There are LOTs of divergent opinions out there. Even
those who are trying to define an "authoritative" architecture for the Web
as a whole or the Web Services network (they may or may not be the same
thing) aren't going to agree on everything, no matter how long they discuss
it.

What we can do is find the *intersection* of the architectural principles in
various specs and proposals, and those that are actually succeeding in
practice.  That's not easy to do -- for various reasons of personal
persuasion or corporate marketing, old ideas are often dressed up in new
clothes, or radical ideas camouflaged with familiar ones.  The TAG is
addressing these challenges for the Web itself, and finding some points that
everyone agrees on about URIs, REST, etc. ... and finding lots to disagree
about.  

I think we would be most effective if we think of ourselves not as
"authorities" deciding on what goes into or out of the "official" web
services architecture ... but as *analysts* (or maybe "scholars" ...
"auditors" ... "researchers ???) who are sifting through the various specs
and reports of actual experience to find the principles that are widely
shared and effective, and to draw boundaries around those that are immature
and contentious.  The TAG may believe (I don't know!) that they have the
authority to make definitive statements about the architecture of the
hypertext web, but as a practical matter we do NOT have the authority to
prescribe the architecture of Web Services.  What we have is the charter to
make sense of it, and lead by proposing win-win scenarios rather than
picking winners and losers.

I think what we want to do is:

- Determine what is common to all reasonable and effective notions of web
service choreography

- Describe the major axes of cleavage where different specs are not
consistent.

- Organize all this into a framework that emphasizes what is common, while
identifying the alternative approaches to what is contentious.

- Propose WG's that will hammer out a working consensus of how to provide as
much interoperability as possible within each contentious area.

There may be areas, such as Choreography, where we need to get more
specialized expertise focussed on the architectural problems of sorting out
the areas of agreement and axes of cleavage, I don't know how far we can get
on our own.  But clearly the first step is to start with the objective of
identifying and leveraging what is common across diverse proposals.  We want
to avoid the situation (of which COM and CORBA are the obvious examples)
where similar ideas got organized into "silos" that one had to choose
between rather than alternative branches off a common root.

Received on Friday, 6 September 2002 11:23:47 UTC