RE: Definition of Choreography

Edwin

I totally agree. There are two problems to be solved here.

David

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Saturday, October 19, 2002 6:30 PM
To: 'Paul Prescod'; 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: Definition of Choreography



+1

External interfaces can/should be kept simple (coarse grained) for
adaptability purposes.

Private implementation always get complex: they start with a story where
business analyst drag and drop a few nodes on a canvas and evolve to
complex implementation by the time the developer has implemented all
data transformation, exception handling, parallel branching, join
patterns, timeout management, transaction/compensation semantic, etc...

Here are a couple of real world examples (the hidden face of BPM tools):

[1] Claim Processing Application: 
http://www.collaxa.com/maps/claim.jpg

[2] Telecom Provisioning App:
http://www.collaxa.com/maps/telecom.jpg

In both cases the interface between the orchestrator and each
participant is simple. The logic that puts all the pieces together,
manages exceptions, handles variability is complex.

This is one reason why way the public interface and the private
implementation should be defined/described using different formalism
although they are intimitely related (similar to Java interface versus
Java class).

Both can be standardized separately.

Edwin

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Paul Prescod
> Sent: Saturday, October 19, 2002 6:07 PM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: Re: Definition of Choreography
> 
> 
> 
> Champion, Mike wrote:
> >...
> > Thoughts anyone?
> 
> Specifying the external interfaces (with or without time-based 
> sequencing) is a completely different problem than scripting a set of 
> web services to accomplish some task. I would personally use 
> a scripting 
> language for the latter but I know that won't get me any venture cap.
> 
> Nevertheless, I think that we should choose two different words for 
> those two different projects and avoid the confusion of 
> pretending they 
> are the same thing. Then the powers that be can decide separately 
> whether each project is worthwhile.
> 
>   Paul Prescod
> 
>

Received on Sunday, 20 October 2002 21:27:27 UTC