You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Davanum Srinivas <da...@gmail.com> on 2004/10/05 17:14:08 UTC
BPEL Anyone? (Fwd: Apache Agila : BPM engine)
Anyone interested in signing up for helping with a BPEL implementation?
-- dims
---------- Forwarded message ----------
From: Geir Magnusson Jr. <ge...@apache.org>
Date: Mon, 4 Oct 2004 11:05:08 -0400
Subject: Re: Apache Agila : BPM engine
To: general@incubator.apache.org
On Oct 1, 2004, at 9:45 AM, Julian wrote:
> Geir,
>
> I have been evaluating BPM for some time now, and was
> just about to implement one when this happened. I am
> now very curious and excited to see how Gluecode's
> engine was constructed. There is little documentation
> on Gluecode's site so I would greatly appreciate any
> answers you can give to the following:
Yes - Gluecode is the entity donating the software, and it will be here
at the ASF. Note that this isn't Gluecode's commercial product, but the
core engine the product is based on.
>
> 1) Does the engine run standalone or in a servlet
> container?
It was designed with this question in mind :)
The core engine is simple J2SE, depending on a set of services to
provide functionality. You can choose to implement those services in
whatever technology you choose. Agila will come with 'in-memory'
services - non-persistent - as well as JDBC-based services as well. it
also comes w/ a servlet UI that it 'hangs' in, for users to upload
processes, start instances, view instances, and interact w/
notifications and tasks. But that servlet based UI is there to help
humans interact w/ the engine. The engine has no servlet dependencies.
> 2) What process definition languages are supported
> (i.e. XPDL, BPEL-WS, etc.)?
None of the above :) We looked at several, and decided the best way
for us was to do our own. The reason is that our current customer-base
is very 'human task' focused, rather than webservice orchestration
focused. However, BPEL is on our product roadmap, and thus we have an
interest as Agila community participants to get it into Agila somehow,
if the rest of the community agrees.
> 3) Is there a graphical process designer?
We have one in our commercial product, and will not be giving that to
the ASF. However, that means that there's plenty of room in the
project for one :) I'm totally +1 for seeing one created here in the
project.
> 4) Is there a webapp that can be prototyped? If so,
> can it manage "process driven wizards" (i.e. affect
> the page flow based on decisions made by the engine)?
I don't think I fully understand what you mean, but right now, you can
create a workflow which does web-based UI to allow the engine to
solicit input from humans and act on that input.
So, while I never thought of it that way, yes - you could produce a
workflow that just produces tasks for a user to do.
The current UI is generic - the user logs in and gets to see the list
of tasks waiting for the user. However, a servlet could easily use the
engine's taskservice to drive a sequence of pages based on those tasks.
The task model goes something like this :
1) for a 'node' of activity in the workflow, the engine calls a 'begin'
method. This method gets to analyze the instance data, and maybe do
something, like assign a task to the user, fling a request via WS or
soemthing else to another machine, etc. Then it indicates to the
engine to wait for the 'outside' to trigger advancement. When the user
decides to do a task, the framework solicits from the activity that
assigned the task a 'Renderer' that produces the UI for doing the task.
Our product uses JSR168 portlets, but this is an implementation
extention, and you could choose whatever you wanted. Once the user
completes the form (for example), the activity is then asked to
validate the data, indicating if the input is enough, or the UI needs
to be rendered again for correction. If ok, the data is sent into the
engine via a 'continue' message for that instance, and the engine calls
the 'end' method for the activity, in which it can process the data
that was input. We do this present/gather/passByMsg thing to ensure
that we aren't modifying the instance state in the UI transaction, but
rather inside the engine.
> 5) Does the code support any of Wil van der Aalst's
> patterns
> (http://tmitwww.tm.tue.nl/research/patterns/)? If so
> how many?
I've gone through them a little, but not in detail. There is a
fork/join, for example.
>
> Again, please feel free to answer any of my questions.
> I apologize for not being patient, but I find this
> terribly exciting!!
I'm sorry about the delay in answering. I was offline this weekend at
a wedding, forgetting about code for 2 days :)
geir
>
> -Julian
>
> --- Geir Magnusson Jr <ge...@4quarters.com> wrote:
>
>>
>> On Sep 30, 2004, at 7:12 AM, Endre Stølsvik wrote:
>>
>>> On Wed, 29 Sep 2004, Geir Magnusson Jr. wrote:
>>>
>>> | All,
>>> |
>>> | The Jakarta PMC has voted to accept in Jakarta
>> the contribution of a
>>> | BPM engine from Gluecode, my employer, and I am
>> starting the basic
>>> work
>>> | of getting it into [and out of] incubation.
>>>
>>> BPM.. Rite.
>>>
>>> DJ-lingo: "Beats Per Minute"
>>> Some journal: "British Postgraduate Musicology"
>>> BSD: "BSD Ports Manipulator"
>>>
>>> Here we got it, I guess: "Business Process
>> Management" ?
>>>
>>> Sounds cool! What is it?
>>
>> BPM is the [IMO] overused, general term for a whole
>> host of
>> technologies and systems to automate business
>> processes. In this case,
>> it's a small execution engine and simple services
>> that process
>> 'workflows'.
>>
>> A workflow, or business process, is a set of
>> activities and tasks that
>> are connected to complete a larger task. For
>> example, processing a
>> loan application may take may people many steps, and
>> a workflow system
>> allows that step sequence to be constructed and
>> executed.
>>
>> it will be easier to explain when I get the code in
>> there. I'm offline
>> this weekend, but we're working on moving the code
>> to teh Apache
>> license, doing the paperwork, and will be bringing
>> the code here ASAP.
>>
>> geir
>>
>>>
>>> Endre
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail:
>> general-help@incubator.apache.org
>>>
>>>
>> --
>> Geir Magnusson Jr
>> +1-203-665-6437
>> geir@gluecode.com
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail:
>> general-help@incubator.apache.org
>>
>>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: BPEL Anyone? (Fwd: Apache Agila : BPM engine)
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
from my experience adapting generic BPM system to BPEL is difficult or
*very* difficult YMMV.
i think lightweight BPEL only engine that is natively working with XML
messages and supports WSA is the "sweet spot" (having ability to plugin
WS-Sec* and WS-*Tran* layers would be plus).
thanks,
alek
Davanum Srinivas wrote:
>Anyone interested in signing up for helping with a BPEL implementation?
>
>-- dims
>
>---------- Forwarded message ----------
>From: Geir Magnusson Jr. <ge...@apache.org>
>Date: Mon, 4 Oct 2004 11:05:08 -0400
>Subject: Re: Apache Agila : BPM engine
>To: general@incubator.apache.org
>
>
>
>On Oct 1, 2004, at 9:45 AM, Julian wrote:
>
>
>
>>Geir,
>>
>>I have been evaluating BPM for some time now, and was
>>just about to implement one when this happened. I am
>>now very curious and excited to see how Gluecode's
>>engine was constructed. There is little documentation
>>on Gluecode's site so I would greatly appreciate any
>>answers you can give to the following:
>>
>>
>
>Yes - Gluecode is the entity donating the software, and it will be here
>at the ASF. Note that this isn't Gluecode's commercial product, but the
>core engine the product is based on.
>
>
>
>>1) Does the engine run standalone or in a servlet
>>container?
>>
>>
>
>It was designed with this question in mind :)
>
>The core engine is simple J2SE, depending on a set of services to
>provide functionality. You can choose to implement those services in
>whatever technology you choose. Agila will come with 'in-memory'
>services - non-persistent - as well as JDBC-based services as well. it
>also comes w/ a servlet UI that it 'hangs' in, for users to upload
>processes, start instances, view instances, and interact w/
>notifications and tasks. But that servlet based UI is there to help
>humans interact w/ the engine. The engine has no servlet dependencies.
>
>
>
>>2) What process definition languages are supported
>>(i.e. XPDL, BPEL-WS, etc.)?
>>
>>
>
>None of the above :) We looked at several, and decided the best way
>for us was to do our own. The reason is that our current customer-base
>is very 'human task' focused, rather than webservice orchestration
>focused. However, BPEL is on our product roadmap, and thus we have an
>interest as Agila community participants to get it into Agila somehow,
>if the rest of the community agrees.
>
>
>
>>3) Is there a graphical process designer?
>>
>>
>
>We have one in our commercial product, and will not be giving that to
>the ASF. However, that means that there's plenty of room in the
>project for one :) I'm totally +1 for seeing one created here in the
>project.
>
>
>
>>4) Is there a webapp that can be prototyped? If so,
>>can it manage "process driven wizards" (i.e. affect
>>the page flow based on decisions made by the engine)?
>>
>>
>
>I don't think I fully understand what you mean, but right now, you can
>create a workflow which does web-based UI to allow the engine to
>solicit input from humans and act on that input.
>
>So, while I never thought of it that way, yes - you could produce a
>workflow that just produces tasks for a user to do.
>
>The current UI is generic - the user logs in and gets to see the list
>of tasks waiting for the user. However, a servlet could easily use the
>engine's taskservice to drive a sequence of pages based on those tasks.
>
>The task model goes something like this :
>
>1) for a 'node' of activity in the workflow, the engine calls a 'begin'
>method. This method gets to analyze the instance data, and maybe do
>something, like assign a task to the user, fling a request via WS or
>soemthing else to another machine, etc. Then it indicates to the
>engine to wait for the 'outside' to trigger advancement. When the user
>decides to do a task, the framework solicits from the activity that
>assigned the task a 'Renderer' that produces the UI for doing the task.
>Our product uses JSR168 portlets, but this is an implementation
>extention, and you could choose whatever you wanted. Once the user
>completes the form (for example), the activity is then asked to
>validate the data, indicating if the input is enough, or the UI needs
>to be rendered again for correction. If ok, the data is sent into the
>engine via a 'continue' message for that instance, and the engine calls
>the 'end' method for the activity, in which it can process the data
>that was input. We do this present/gather/passByMsg thing to ensure
>that we aren't modifying the instance state in the UI transaction, but
>rather inside the engine.
>
>
>
>
>>5) Does the code support any of Wil van der Aalst's
>>patterns
>>(http://tmitwww.tm.tue.nl/research/patterns/)? If so
>>how many?
>>
>>
>
>I've gone through them a little, but not in detail. There is a
>fork/join, for example.
>
>
>>Again, please feel free to answer any of my questions.
>> I apologize for not being patient, but I find this
>>terribly exciting!!
>>
>>
>
>I'm sorry about the delay in answering. I was offline this weekend at
>a wedding, forgetting about code for 2 days :)
>
>geir
>
>
>
>>-Julian
>>
>>--- Geir Magnusson Jr <ge...@4quarters.com> wrote:
>>
>>
>>
>>>On Sep 30, 2004, at 7:12 AM, Endre Stølsvik wrote:
>>>
>>>
>>>
>>>>On Wed, 29 Sep 2004, Geir Magnusson Jr. wrote:
>>>>
>>>>| All,
>>>>|
>>>>| The Jakarta PMC has voted to accept in Jakarta
>>>>
>>>>
>>>the contribution of a
>>>
>>>
>>>>| BPM engine from Gluecode, my employer, and I am
>>>>
>>>>
>>>starting the basic
>>>
>>>
>>>>work
>>>>| of getting it into [and out of] incubation.
>>>>
>>>>BPM.. Rite.
>>>>
>>>>DJ-lingo: "Beats Per Minute"
>>>>Some journal: "British Postgraduate Musicology"
>>>>BSD: "BSD Ports Manipulator"
>>>>
>>>>Here we got it, I guess: "Business Process
>>>>
>>>>
>>>Management" ?
>>>
>>>
>>>>Sounds cool! What is it?
>>>>
>>>>
>>>BPM is the [IMO] overused, general term for a whole
>>>host of
>>>technologies and systems to automate business
>>>processes. In this case,
>>>it's a small execution engine and simple services
>>>that process
>>>'workflows'.
>>>
>>>A workflow, or business process, is a set of
>>>activities and tasks that
>>>are connected to complete a larger task. For
>>>example, processing a
>>>loan application may take may people many steps, and
>>>a workflow system
>>>allows that step sequence to be constructed and
>>>executed.
>>>
>>>it will be easier to explain when I get the code in
>>>there. I'm offline
>>>this weekend, but we're working on moving the code
>>>to teh Apache
>>>license, doing the paperwork, and will be bringing
>>>the code here ASAP.
>>>
>>>geir
>>>
>>>
>>>
>>>>Endre
>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>
>>
>>>>To unsubscribe, e-mail:
>>>>
>>>>
>>>general-unsubscribe@incubator.apache.org
>>>
>>>
>>>>For additional commands, e-mail:
>>>>
>>>>
>>>general-help@incubator.apache.org
>>>
>>>
>>>>
>>>>
>>>--
>>>Geir Magnusson Jr
>>>+1-203-665-6437
>>>geir@gluecode.com
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>
>>>To unsubscribe, e-mail:
>>>general-unsubscribe@incubator.apache.org
>>>For additional commands, e-mail:
>>>general-help@incubator.apache.org
>>>
>>>
>>>
>>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>>
>--
>Geir Magnusson Jr +1-203-665-6437
>geirm@apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: BPEL Anyone? (Fwd: Apache Agila : BPM engine)
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
from my experience adapting generic BPM system to BPEL is difficult or
*very* difficult YMMV.
i think lightweight BPEL only engine that is natively working with XML
messages and supports WSA is the "sweet spot" (having ability to plugin
WS-Sec* and WS-*Tran* layers would be plus).
thanks,
alek
Davanum Srinivas wrote:
>Anyone interested in signing up for helping with a BPEL implementation?
>
>-- dims
>
>---------- Forwarded message ----------
>From: Geir Magnusson Jr. <ge...@apache.org>
>Date: Mon, 4 Oct 2004 11:05:08 -0400
>Subject: Re: Apache Agila : BPM engine
>To: general@incubator.apache.org
>
>
>
>On Oct 1, 2004, at 9:45 AM, Julian wrote:
>
>
>
>>Geir,
>>
>>I have been evaluating BPM for some time now, and was
>>just about to implement one when this happened. I am
>>now very curious and excited to see how Gluecode's
>>engine was constructed. There is little documentation
>>on Gluecode's site so I would greatly appreciate any
>>answers you can give to the following:
>>
>>
>
>Yes - Gluecode is the entity donating the software, and it will be here
>at the ASF. Note that this isn't Gluecode's commercial product, but the
>core engine the product is based on.
>
>
>
>>1) Does the engine run standalone or in a servlet
>>container?
>>
>>
>
>It was designed with this question in mind :)
>
>The core engine is simple J2SE, depending on a set of services to
>provide functionality. You can choose to implement those services in
>whatever technology you choose. Agila will come with 'in-memory'
>services - non-persistent - as well as JDBC-based services as well. it
>also comes w/ a servlet UI that it 'hangs' in, for users to upload
>processes, start instances, view instances, and interact w/
>notifications and tasks. But that servlet based UI is there to help
>humans interact w/ the engine. The engine has no servlet dependencies.
>
>
>
>>2) What process definition languages are supported
>>(i.e. XPDL, BPEL-WS, etc.)?
>>
>>
>
>None of the above :) We looked at several, and decided the best way
>for us was to do our own. The reason is that our current customer-base
>is very 'human task' focused, rather than webservice orchestration
>focused. However, BPEL is on our product roadmap, and thus we have an
>interest as Agila community participants to get it into Agila somehow,
>if the rest of the community agrees.
>
>
>
>>3) Is there a graphical process designer?
>>
>>
>
>We have one in our commercial product, and will not be giving that to
>the ASF. However, that means that there's plenty of room in the
>project for one :) I'm totally +1 for seeing one created here in the
>project.
>
>
>
>>4) Is there a webapp that can be prototyped? If so,
>>can it manage "process driven wizards" (i.e. affect
>>the page flow based on decisions made by the engine)?
>>
>>
>
>I don't think I fully understand what you mean, but right now, you can
>create a workflow which does web-based UI to allow the engine to
>solicit input from humans and act on that input.
>
>So, while I never thought of it that way, yes - you could produce a
>workflow that just produces tasks for a user to do.
>
>The current UI is generic - the user logs in and gets to see the list
>of tasks waiting for the user. However, a servlet could easily use the
>engine's taskservice to drive a sequence of pages based on those tasks.
>
>The task model goes something like this :
>
>1) for a 'node' of activity in the workflow, the engine calls a 'begin'
>method. This method gets to analyze the instance data, and maybe do
>something, like assign a task to the user, fling a request via WS or
>soemthing else to another machine, etc. Then it indicates to the
>engine to wait for the 'outside' to trigger advancement. When the user
>decides to do a task, the framework solicits from the activity that
>assigned the task a 'Renderer' that produces the UI for doing the task.
>Our product uses JSR168 portlets, but this is an implementation
>extention, and you could choose whatever you wanted. Once the user
>completes the form (for example), the activity is then asked to
>validate the data, indicating if the input is enough, or the UI needs
>to be rendered again for correction. If ok, the data is sent into the
>engine via a 'continue' message for that instance, and the engine calls
>the 'end' method for the activity, in which it can process the data
>that was input. We do this present/gather/passByMsg thing to ensure
>that we aren't modifying the instance state in the UI transaction, but
>rather inside the engine.
>
>
>
>
>>5) Does the code support any of Wil van der Aalst's
>>patterns
>>(http://tmitwww.tm.tue.nl/research/patterns/)? If so
>>how many?
>>
>>
>
>I've gone through them a little, but not in detail. There is a
>fork/join, for example.
>
>
>>Again, please feel free to answer any of my questions.
>> I apologize for not being patient, but I find this
>>terribly exciting!!
>>
>>
>
>I'm sorry about the delay in answering. I was offline this weekend at
>a wedding, forgetting about code for 2 days :)
>
>geir
>
>
>
>>-Julian
>>
>>--- Geir Magnusson Jr <ge...@4quarters.com> wrote:
>>
>>
>>
>>>On Sep 30, 2004, at 7:12 AM, Endre Stølsvik wrote:
>>>
>>>
>>>
>>>>On Wed, 29 Sep 2004, Geir Magnusson Jr. wrote:
>>>>
>>>>| All,
>>>>|
>>>>| The Jakarta PMC has voted to accept in Jakarta
>>>>
>>>>
>>>the contribution of a
>>>
>>>
>>>>| BPM engine from Gluecode, my employer, and I am
>>>>
>>>>
>>>starting the basic
>>>
>>>
>>>>work
>>>>| of getting it into [and out of] incubation.
>>>>
>>>>BPM.. Rite.
>>>>
>>>>DJ-lingo: "Beats Per Minute"
>>>>Some journal: "British Postgraduate Musicology"
>>>>BSD: "BSD Ports Manipulator"
>>>>
>>>>Here we got it, I guess: "Business Process
>>>>
>>>>
>>>Management" ?
>>>
>>>
>>>>Sounds cool! What is it?
>>>>
>>>>
>>>BPM is the [IMO] overused, general term for a whole
>>>host of
>>>technologies and systems to automate business
>>>processes. In this case,
>>>it's a small execution engine and simple services
>>>that process
>>>'workflows'.
>>>
>>>A workflow, or business process, is a set of
>>>activities and tasks that
>>>are connected to complete a larger task. For
>>>example, processing a
>>>loan application may take may people many steps, and
>>>a workflow system
>>>allows that step sequence to be constructed and
>>>executed.
>>>
>>>it will be easier to explain when I get the code in
>>>there. I'm offline
>>>this weekend, but we're working on moving the code
>>>to teh Apache
>>>license, doing the paperwork, and will be bringing
>>>the code here ASAP.
>>>
>>>geir
>>>
>>>
>>>
>>>>Endre
>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>
>>
>>>>To unsubscribe, e-mail:
>>>>
>>>>
>>>general-unsubscribe@incubator.apache.org
>>>
>>>
>>>>For additional commands, e-mail:
>>>>
>>>>
>>>general-help@incubator.apache.org
>>>
>>>
>>>>
>>>>
>>>--
>>>Geir Magnusson Jr
>>>+1-203-665-6437
>>>geir@gluecode.com
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>
>>>To unsubscribe, e-mail:
>>>general-unsubscribe@incubator.apache.org
>>>For additional commands, e-mail:
>>>general-help@incubator.apache.org
>>>
>>>
>>>
>>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>>
>--
>Geir Magnusson Jr +1-203-665-6437
>geirm@apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay