I think that I have to agree with Sanjiva, a BPEL engine has to be pretty tightly integrated with the web service layer. Mechanisms like correlation and assignment force you to handle XML messages and data at the lowest levels of implementation.
In short a correlation in BPEL is a unique way to identify an execution and is specific to each partner. For a given execution, you may have 4 correlations, each handling the exchanges with a given partner. For example if you have a process managing an order and its shippment, you will have to handle order specific information that will only interest your billing department and shippment specific information only interesting the shipper. Both have a specific way to identify their interaction, a specific correlation. And correlation is initiated at an activity level. The execution model in Twister is the same as the one you implemented Geir. An activity can either execute and terminate, or execute and wait for a message before termination depending on its type. We only had to create specific activity types. Actually the main difference between Twister's execution model and yours is that Twister's execution doesn't use any "manager" class like your engine, the execution is carried on from activities to activities by activities. The basic use case is the following: 1. Web service layer receives a message. 2. Message is parsed and analyzed to extract the targeted partner, port and operation and eventually a correlation. 3. The Message Controller uses the data extracted from the message to see which current execution it is targeted at or if it has to start a new execution. 4. The message is forwarded to the right activity execution that was waiting for this message. 5. The activity terminate executions and forwards execution to the next activity. 5. Next activity executes and (eventually) forwards execution to next activity and so on... Now I'm cheating a bit here. In Twister we have two main types of activities: basic activity and activity container (coming from BPEL). The container is the one controlling which activity has to execute next in its domain. Once a controller has finish executing its activities, it surrenders execution to it's parent container. And so on... Right now the containers we implemented are Sequence, Pick, Switch and While. The Flow is not finished yet. So we don't have any notion of "link" between two activities, the container implementation is the one deciding. For more about Twister's architecture, there's a document here: http://smartcomps.org/confluence/display/twister/Architecture+Guide I didn't have enough time to finish all yet but there still might be some helpful stuff. Actually a BPEL engine is somewhat different to a workflow engine. The execution core may have similarities but all the "wrapping around" is quite different. So I would say that beside the fact that Twister is a bit more "wrapped" (and therefore also more "heavyweight") the main differences are: 1. Containment execution vs. "link-based" execution 2. Peer-to-peer execution vs. managed execution Geir, what is your opinion on all this? Did you have time to check Twister? Tell me if you need more information or anything else from me. Thanks, Matthieu. On Thu, 21 Oct 2004 02:09:17 +0600, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > +1 for merging in BPEL support using Twister. > > Geir, I'd like to understand the BPEL plans for Agila a bit > more. I'm a co-author of the BPEL spec and have done an impl > of it in IBM (BPWS4J- which was released via alphaworks a while > back). My intuition is that a solid impl of BPEL needs to work > very closely with the Web service layer. AFAIK there hasn't been > that kind of interaction between Agila and the Axis community > yet. Dims and I can easily support/facilitate that! > > Matthieu- how does Twister do its SOAP, WSDL etc. stuff? Do > you support non-SOAP bindings? (BPWS4J used WSIF, for example.) > > Sanjiva. > > > > ----- Original Message ----- > From: "Geir Magnusson Jr" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, October 20, 2004 7:20 PM > Subject: Re: Proposition: Twister WS-BPEL engine and Apache Agila > > > This is great. We're really interested in getting BPEL into Agila. > > I'll take a look. > > > > We originally decided to not go w/ BPEL as the core language, as we > > wanted to support all kinds of activities in a workflow, being able to > > make a workflow that mixes them. So it was planned that we'd get BPEL > > support, and allow you to incorporate BPEL into a regular Agila > > workflow using a namespace or something. Of course, we can decide if > > we want to change that plan here, but I think there are some compelling > > arguments for that kind of approach... > > > > geir > > > > On Oct 20, 2004, at 5:52 AM, Matthieu Riou wrote: > > > > > Hello, > > > > > > I'm the project leader of Twister, an open source WS-BPEL engine. More > > > can be found about Twister here: > > > > > > http://www.smartcomps.org/twister > > > > > > I'm sending this e-mail to suggest a donation of Twister to the Apache > > > Group and a merge with the incubated Apache Agila project. I believe > > > that Twister and the Gluecode engine could be assembled to a better > > > solution, using the strengths of both implementations. This would also > > > be beneficial for the BPM Open Source community and would bring more > > > users and contributors to Agila. > > > > > > Regards, > > > > > > Matthieu Riou > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > Geir Magnusson Jr +1-203-665-6437 > > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
