On Oct 20, 2004, at 7:03 AM, Matthieu Riou wrote:
I'm going to have a closer look at Agila to see how Twister can fit here. Is there anything I should look at beside the Subversion repository?
Twister's engine core is somewhat tied to WS-BPEL. Our approach was a bit different, we didn't try to build a meta-model or anything too generic. Our plan was just to extend the engine if other workflow patterns were needed and not included in BPEL and stick with the specs for the rest.
Anyway I'll just check Agila and see how Twister and WS-BPEL could be integrated into it. We could work out a way to stick with your original plan which, I agree, may be better for a generic workflow implementation. If you have any question about Twister, just let me know.
We have a model of 'activities' in the workflow graph that generally can do what they want as part of their action. They are 'two phase' - when execution gets to that node, a start method is called, in which the activity can "do something" - trigger an external action on another system, create a task for a user - and then indicate to the engine if execution should continue to the activities doEnd() method, or just stop and wait for an external message to trigger continuation to the doEnd() method.
To illustrate for a task, where the activity sets a task for a user, waits for the user to do the task, and then with the data from the task (say the user had to fill in a form), process the data and continue.
So for example, the flow for a simple task is :
- engine calls 'doStart()'
- doStart() does whatever and then adds a task for a user.
- doStart() returns 'false', indicating that the engine should not continue execution
- some time later, the user does the task, which results in a message going to the engine w/ the data entered by the user
- the engine gets the message, calls doEnd() to allow the activity to process the data, and continue based on state data and task data
This allows for activities that are asynchronous, which I imagine would be perfect for asynch webservices.
To contrast to an activity that doesn't need input from outside, like adding a notification for a user, or getting data from somewhere synchronously :
- engine calls 'doStart()'
- doStart() does whatever
- doStart() returns 'true', indicating that the engine should continue execution
- the engine immediately calls doEnd()
so in this, an activity can do a synchronous call to the outside, although synchronous external execution can be a performance killer...
Anyway, given this, I thought BPEL execution could be taken care of by one or more activities that do the WS execution. Now, I'm fairly ignorant about BPEL, so I'm interested in what kind of execution model you'd need.
geir
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
