[Agila] Agila & BPEL

[Matthieu Riou <ma...@gmail.com>]

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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Agila] Agila & BPEL

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

On Nov 15, 2004, at 5:52 AM, Matthieu Riou wrote:

> 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.
Based on what little I know of Agila, I think a BPEL implementation 
will be a welcome evolution!
>
> - 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.
+1
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. 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).
I'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.
> 	-> 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).
+1
>
> - 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, 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.
>
> Matthieu.
--
Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Agila] Agila & BPEL

[Sanjiva Weerawarana <sa...@opensource.lk>]

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" <ma...@gmail.com>
To: <ge...@incubator.apache.org>
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org