Hi,
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
