Agila BPEL Support

[Tom Bender <to...@goldhill.net>]

(I just saw Geir's posting on Twister, and I think that is an excellent 
starting point!)

A while back Matthieu Riou posted the following message. I thought it 
was very insightful and potentially very useful
if Agila is to support BPEL. I had heard at one time that this was one 
of the items first up for Agila, but the mailing
list has been hauntingly quiet to this end. In addition, I felt 
Matthieu raised some very insightful questions and potential
solutions to address some of the perceived shortcomings of the Agila 
model if it is to support BPEL

Additionally, many of the points Matthieu raised about the codebase 
were many of the same questions I had. Having
worked fairly extensively with Sonic's ESB product, I felt that many of 
his ideas lent themselves well to an ESB model,
which is not a stretch for some workflow engines, but seemed almost 
unattainable with Agila's current model. I feel
their  is  considerable value in a workflow engine that can consume 
BPEL and support a slightly more generic workflow
model --- perhaps sitting somewhere between Agila today and the Werken 
codebase from which it is derived.

Following Matthieu's (matthieu.riou@gmail.com) email, Sanjiva 
Weerawarana (sanjva@opensource.uk) and I had some
off topic discussions to attempt to formalize some of our thoughts and 
attempt a re-post. Well, then came the holidaze and here we
are in January.

Anyway, please have a read and if these ideas ring true, let's see if 
we can gain some momentum around workflow/BPEL.


 >Please have a read and if interested in creating an Apache BPEL 
supported workflow engine
 >
 >In addition, I think it  one day and some of the Enterprise Service 
Bus  ,
 >
 >I just looked into Agila in detail and thought it might be interesting
 >to share my remarks and questions. Of course, most of my comments are
 >related to BPEL compatibility, or what could be changed to ensure that
 >making Agila BPEL-compliant won't be too hairy.
 >
 >- Right now Agila is pretty much task based. A task is assigned to a
 >specific user (as well as notifications) and "renders" itself to the
 >user with a TaskHandler. There's no concept of incoming message (data
 >basically comes from tasks completion) or event.
 >
 >	-> A concept of message should be introduced. The message should
 >represent XML data (not just a Map). The engine must be able to
 >receive messages and "guess" which execution and node the message is
 >targeted at to react accordingly. The engine must also be able to
 >produce such a message in order to send it to the right party. The
 >concept of user is usually associated with a final end user. A concept
 >of participant (as defined by the WfMC) should also be introduced to
 >encompass both the notion of a human user and an automated system (a
 >service).
 >
 >	-> Agila will also need something like incoming events. Which of
 >course will be messages. In BPEL some specific activities can be
 >triggered anytime, outside of the main execution flow of the process.
 >This event can trigger the creation of a new process execution but can
 >also be alarms fired by external systems or an automatic cancellation
 >for example.
 >
 >- The WorkList (or task list) management is handled inside the engine
 >
 >	-> It could be somewhat better to externalize (as in a different
 >module and different jar) tasks management. Let's imagine Agila is
 >fully BPEL compliant but also includes additional semantics to provide
 >tasks creation targeted at a specific end user (which is not handled
 >by BPEL). It would be nice if these additional semantics could also be
 >expressed in BPEL so the Agila's end users won't be too tied to the
 >Agila implementation. A way that I found rather elegant is to provide
 >a separate service for worklist management. Your BPEL process just
 >references Agila's task management service using BPEL constructs
 >(invoke task creation and receive task completion for example). When
 >using Agila's engine, the BPEL process is translated to Agila's EL and
 >then the usage of the task management service can be "hardcoded". If
 >the user wants to migrate to another BPEL engine implementation
 >without being tied to Agila, the BPEL processes do not change much.
 >Actually not at all if our user still uses Agila's task management
 >service (which he will probably do as other commercial implementations
 >usually don't provide this feature embedded).
 >
 >- The only way right now to interact with Agila is to have a task
 >created for you. So there's no way for you to identify a specific
 >execution you're interested in beside its private id (which usually
 >you don't want to use as it has nothing to do with your order
 >management system or your shipping system). A process instance doesn't
 >have any public, business related id.
 >
 >	-> We will need a solution to "push" an instance identity to the
 >engine. The client should be able to give its own id to the process
 >instance it's interacting with (either at creation or when responding
 >synchronously). In BPEL this is called Correlation (roughly each
 >instance possess a collection of maps with key/value pairs, providing
 >an identification for all its partners). But it could be abstracted as
 >a generic way to give a unique identity to an instance providing
 >identity data. A specific implementation would be correlation.
 >
 >- The data held by a process instance is held inside a Map.
 >
 >	-> This will be problematic when we'll need to handle BPEL variables.
 >Data in BPEL is XML. Of course a DOM tree could easily be stuffed in
 >the Map, but what about persistence? We could serialize the stuff
 >(like java serialization or back to XML) but it will certainly raise
 >performance issues. And most users don't like to have persistent data
 >that can't be easily read or updated. I would like to suggest the use
 >of an embedded XML database here, like Xindice for example. The
 >language chosen by BPEL guys to evaluate expressions (conditions,
 >deadlines...) is XPath, which is easy to handle when you have XML
 >structures.
 >
 >Please, correct me if I got something wrong, I may have missed many
 >things while looking at Agila's code. I'll keep on looking and sending
 >issues when if I find more. What do you think?
 >
 >Matthieu.