incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: [Agila] Agila & BPEL
Date Tue, 07 Dec 2004 03:39:36 GMT
I didn't see any response to this from the Agila developers. Did
I just miss it? It seems to me that to get Agila & BPEL married
some significant work is necessary .. and obviously that's not
possible without the committment of the Agila developers!


----- Original Message ----- 
From: "Matthieu Riou" <>
To: <>
Sent: Monday, November 15, 2004 6:52 PM
Subject: [Agila] Agila & BPEL

> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message