RE: Finding the Intersection ...

Another way of looking at the various choreography proposals is by
identifying a bunch of different areas/themes (e.g. choreography vs.
orchestration vs. workflow vs. something-else, as it was discussed on this
list a couple of weeks ago), and then finding intersections in each one of
those domains. From what I know of those proposed specs, not all of them
focus on the same areas, and some cover a couple of areas but are stronger
in some and weaker in others.

Ugo

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Friday, September 06, 2002 12:21 PM
To: www-ws-arch@w3.org
Subject: RE: Finding the Intersection ...





> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Friday, September 06, 2002 2:47 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Finding the Intersection ...
> 
>
> Correct me if I'm wrong Mike, but I think what you're saying here is
> that you want to look at the features/capabilities of the
> specifications and find their intersection, not so much the
> architectural principles and/or assumptions made by those specs.
> 
> I can see value to the former interpretation, but not so much with the
> latter, for some of the reasons given at the end of this message;
> 
> http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0386
> 

Hmmm .. I guess I agree that the intersection of divergent "architectural
principles" may end up with the null set.  Perhaps "components, operations,
and relationships" would be a better way to put it than "principles."

For example, I hope we can dig through the WSCI and BPEL/etc specs to find
what they have in common as to what they want to accomplish, how (roughly)
they do it, and relate it to widely understood concepts in computer science
or industry practice (e.g., coordination languages/tuple spaces, just to
pull something out of the air).   If we find a coordination protocol that
has a "distributed object" flavor and another has a coordination protocol
that has a "tuple space" flavor, I for one am not going to say "different
architectural principles, conceptual mismatch, nothing we can do with this."
I'm going to say, "If we abstract away the implementation mechanism, these
are more or less the same conceptual objects that are related to each other
in roughly the same way.  Maybe we can highlight the common architectural
role they play, and draw a box to encapsulate their differences behind a
common architectural abstraction." 

Perhaps Paul Prescod's musings about HTTP's GET/PUT/POST/DELETE and SQL's
SELECT/INSERT/UPDATE/DELETE are a good example of what I'm thinking of.
Someone might say "HERESY -- HTTP is an ad hoc conceptual mess, and SQL is a
(partial!) implementation of the formal Relational Algebra, and it is folly
to pretend that the Web is a DBMS!!!"  I'd say "Interesting how the same
canonical set of primitive operations got distilled out of radically
different disciplines, maybe there's some deeper architectural unity at work
here."

So, I think we probably agree, and "principles" was not the right word [ahem
--  emails do tend to be brain dumps, not well-thought-out analyses].  On
the other hand, I don't want to get too religious about "architectural
principles" that may have more underlying unity than their competing
advocates might realize.  That's pretty much the whole point of my message:
There are very good "marketing" reasons  --broadly defined, and I'm not
using this term as a slur for a change :-) -- for exaggerating the
differentiation among essentially similar products, technologies,
specifications, etc.  Our job is to peel away arbitrary distinctions (be
they business-driven, technology-driven, or ideology-driven) among web
services concepts to find the "essences" inside.

Received on Friday, 6 September 2002 15:31:37 UTC