axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: BPEL Anyone? (Fwd: Apache Agila : BPM engine)
Date Tue, 05 Oct 2004 23:24:26 GMT
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. <geirm@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 <geir@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


Mime
View raw message