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!
Sanjiva. ----- Original Message ----- From: "Matthieu Riou" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
