Re: Finding the Intersection ...

I think that, while it is important to extract the lessons from 
approaches such as REST, and from specs such as WSDL, etc. etc., a 
process of distilling/intersecting/culling ideas from these various 
architectures is not necessarily the best way to go. The reason being 
that you end up being completely driven by what everyone else has done; 
irrespective of whether thats what you want to do in the first place.

I suggest a different approach: decide what we want to do first, and 
then see how well REST/WSDL/etc fits in with what we want. This 
top-down style at least has the merit of being clear what is being 
achieved, and it can also identify holes that are left completely 
vacant by whatever is currently `out there'.

Better still, a combination of the two: guided by the top-down view but 
informed by a bottom-up analysis.

Frank McCabe

On Friday, September 6, 2002, at 12:30  PM, Ugo Corda wrote:

>
> 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:[email protected]]
> Sent: Friday, September 06, 2002 12:21 PM
> To: [email protected]
> Subject: RE: Finding the Intersection ...
>
>
>
>
>
>> -----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.
>