- From: Assaf Arkin <arkin@intalio.com>
- Date: Fri, 11 Apr 2003 09:36:59 -0700
- To: Jean-Jacques Dubray <jjd@eigner.com>
- CC: steve@enigmatec.net, "'Cummins, Fred A'" <fred.cummins@eds.com>, "'Burdett, David'" <david.burdett@commerceone.com>, jdart@tibco.com, public-ws-chor@w3.org
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 12:39:22 UTC