Re: Internal processes and/or external choreographies (was RE: Events and States ...

Burdett, David wrote:

>Thanks ... but one thing we haven't nailed down yet is the extent to which
>the scope of this group covers definition of languages to define internal
>process definitions (as in WSCI and BPEL4WS) as well as external
>choreographies. I have been focusing on the latter but we need to be clear
>what we are doing about the former.
>
>For example we could have the following as requirements for internal process
>definitions ...
>
>"An internal process definition MUST be capable of defining the sequence and
>rules by which software is executed within a 'Control Domain' " ... Control
>domain has been defined/described/discussed earlier.
>
>"An internal process definition MUST be capable of identifying the
>relationships and dependencies it has on an external choreography
>definition."
>  
>
This one is easy, you derive part of the choreography from the 
implementation. I think the challange is to define a choreography first 
and then build an implementation that "sticks".

This is why it becomes important to discuss implementation. Not because 
you want to pick one particular way to build it. Far from that. Because 
you want to investigate how to ensure that the implementation - and any 
implementation - could claim conformance to the choreography.

If the choreography is a bit too abstract or too loose you won't be able 
to determine if the implementation "sticks". You can run the 
implementation, see if it works. Trial by error is not my favorite approach.

On the other hand, if the choreography is too concrete or too tightly 
coupled you end up marrying the choreography to the implementation, you 
can't have variance in the implementation and that's a big no-no in my 
opinion.

Somewhere inbetween there's a silver line. A choreography that is 
precise enough for you to check conformance of the implementation at 
design-time, in fact derive some template for the implementation from 
the choreography, yet is abstract enough to allow a variety of 
implementation and also implementation approaches.

arkin

>... I am sure there are more, like internal process definitions being Turing
>complete ...
>
>Any thoughts chairs?
>
>David
>
>  
>

Received on Thursday, 10 April 2003 21:47:59 UTC