axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <mturi...@microtest.ru>
Subject RE: BPEL Anyone? (Fwd: Apache Agila : BPM engine)
Date Wed, 06 Oct 2004 08:17:43 GMT
My 2 cents:
You should consider BPELJ to provide seamless integration
with Java-based APIs.
http://dev2dev.bea.com/technologies/bpel/index.jsp


-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu] 
Sent: Wednesday, October 06, 2004 3:24 AM
To: axis-dev@ws.apache.org
Cc: general@ws.apache.org
Subject: Re: BPEL Anyone? (Fwd: Apache Agila : BPM engine)

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