RE: Internal processes and/or external choreographies (was RE: Ev ents and States ...

Assaf:

As long as the orchestration language supports the notion of message
exchange (hopefully they will soon go further an also understand the
notion of message exchange patterns :-), I think that the binding is
possible. At the control flow level, there might be some incompatibility
(e.g. something specified in ws-chor cannot be reproduced exactly in the
orchestration language), which would mean that some ws-chor definition
cannot be implemented in a given orchestration language. However, I
don't think that this should be a requirement imposed on ws-chor. Some
orchestration language are so primitive (e.g. they don't understand what
a MEP is) that it would be a mistake to force ws-chor to adapt to it. It
should be the other way around.

JJ- 
 
 

>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Friday, April 11, 2003 12:37 PM
>>To: Jean-Jacques Dubray
>>Cc: steve@enigmatec.net; 'Cummins, Fred A'; 'Burdett, David';
>>jdart@tibco.com; public-ws-chor@w3.org
>>Subject: Re: Internal processes and/or external choreographies (was
RE: Ev
>>ents and States ...
>>
>>
>>Jean-Jacques Dubray wrote:
>>
>>>Now to respond specifically to Assaf on how hard it is to create an
>>>implementation of an external choreography, I have written in the
past
>>>an algorithm that takes a choreography specification (defined in
ebXML
>>>BPSS) and creates an orchestration definition that can complies with
it.
>>>
>>Exactly.
>>
>>If the choreography language takes into account the notion of a FSM,
it
>>becomes trivial to derive a suitable implementation, conduct run-time
>>checks and ensure conformance. You can do it with simple forms of I/O
>>automata or with more capable models based on mobile process calculi.
>>
>>If the choreography ignores what have already been done and goes off
in
>>another direction, that task becomes significantly harded and in some
>>suggestions I have seen may even be impossible.
>>
>>arkin
>>
>>>At this point, you can add internal activities in between the
activities
>>>that are external touch points. This was very easy to do, and I'd be
>>>happy to open source such algorithm once the ws-chor specification is
>>>stable. However, and ultimately you may never be guaranteed that the
>>>internal unit of work will perform as intended from a timing and
timeout
>>>perspective (your system could be slow or down). This is why one need
a
>>>special component managing the ws-choreography instances to make sure
>>>they comply with the specification (you really don't want to spread
that
>>>code in the service implementations since you would need to change
that
>>>code each time the choreography definition changes or spread the
>>>choreography instance management across all the services that
>>>participate in this choreography).
>>>
>>>Cheers,
>>>
>>>Jean-Jacques
>>>
>>>
>>>

Received on Friday, 11 April 2003 13:01:07 UTC