On Nov 15, 2004, at 5:52 AM, Matthieu Riou wrote:
Based on what little I know of Agila, I think a BPEL implementation will be a welcome evolution!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.
+1
- 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.
I'm currently working with SonicMQ (JMS impl) and SonicESB (an Enterprise Service Bus layered on top of JMS) and in addition to the Message, there is an Envelope that defines the routing of the underlying message within the context of the Service. When you referred to "guess", this is actually the job of the ESB container to know it's outgoing address. I believe Agila's Task model could benefit from some abstraction to adopt a Message and perhaps even an Envelope. Conceptually, this is a simple and powerful model that seems to meet many of our workflow business needs. Personally, I'm trying to understand the layers of separation between ESB and BPEL/Workflow and how all this ties back to JBI/JSR 208 --- that's another thread. ;-)
The engine must also be able to produce such a message in order to send it to the right party. TheI've seen this modeled as an end point; most commonly as a JMS Topic or Queue that serves as an entry point to either a Service or a GUI/Participant.
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).
+1-> 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).
Matthieu, I think you bring up some great topics and ideas wrt adopting Agila to support BPEL. I too am new to Agila, so it will be interesting to watch this thread and some of the feedback from the current authors.
- 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.
-- Tom
--------------------------------------------------------------------- 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]
