Re: Finding the Intersection ...

Excellent, I agree complete.  Thanks for clarifying.

I understand (all too well 8-) that emails are more ad-hoc, but I also
see the need to be careful with terminology, especially in a field with
so many overloaded terms.  That's ok though, it just means a few more
messages like this one to clarify.  Thanks again.

MB

On Fri, Sep 06, 2002 at 01:21:05PM -0600, Champion, Mike wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Mark Baker [mailto:[email protected]]
> > Sent: Friday, September 06, 2002 2:47 PM
> > To: Champion, Mike
> > Cc: [email protected]
> > 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. 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               [email protected]
http://www.markbaker.ca        http://www.idokorro.com