Re: Micro-workflow engine suggestion

I think it would be very interesting to have a BPEL
implementation.  Currently, the "language" of the
workflow engine is XPDL.

It does, as Shash and Mike metioned, work as a sort of
SuperModel.  The application calls the workflow model
and it in turn calls many other models.  I would
imagine that we could make it into a service.  We
could talk about how the other workflows work.  

One thing that I did have problems with was the fact
that most of the other engines didn't play nicely in a
web environment.  OSWorkflow, in particular, kept
reevaluating nodes in the workflow that had been
passed.  There were some very odd ramifications.  That
is why I wrote Red Workflow.

Let me know what you have in mind and I would be happy
to help out.

Jeff Richley

--- Carlos Cardenas <juan_carlos_cardenas-/[email protected]>
wrote:

> Guys,
> 
> Thanks a lot for the info.  It does make a lot of
> sense to have app-workflow in the current keel.
> 
> However, I believe it may be a good idea to
> formalize
> the concept of a BPM in keel.  It does make a lot of
> sense in a business environment to have this one.
> 
> It seems to me that using a BPEL based
> implementation
> of the BPM would be most useful, so we can
> communicate
> with other parts of the business areas exactly what
> we
> are doing for implementing a BP.  In this case, the
> model would be there to fulfill the tasks/activities
> of the BP controlled in the BPM.
> 
> As you guys say, this is quite unique and I see some
> business value here.
> 
> Thanks also for the explanation on our internal
> workflow engine.  I will be checking out soon the
> source to understand app-workflow better.
> 
> BTW, for implementings the tasks/activities of the
> BP
> I'd like to use scripting that would bind the lower
> level model components.  This kind of makes sense to
> me.  I'd like to use groovy as the scripting
> language.
>  Is keel's current implementation of BSF ready to
> handle groovy?  I'll check out the source.
> 
> Thanks 
> 
> --- Shash Chatterjee <[email protected]> wrote:
> 
> > Mike/Carlos,
> > 
> > > Quick word of history: Keel's workflow expert,
> > Jeff, is sometimes off
> > > the list for a while, but I very much imagine
> > he'll have some
> > > perspective to share on Keel's existing
> workflow.
> > The workflow "service"
> > > went away because workflow in Keel was "driving"
> > the Model objects, and
> > > was not a service called *by* the Models, so it
> > became an application
> > > (app-workflow), rather than a service.
> > > 
> > > Just wanted to toss in those 2c while I was
> > thinking of it...
> > > 
> > > I think BPM-style workflow is a somewhat
> different
> > animal than the
> > > app-workflow, but I'd defer to it's author to
> say
> > how different. Our
> > > current workflow does have a very nice GUI
> editor,
> > though.
> > 
> > This is exactly right.  app-workflow is an
> entirely
> > different flavor of 
> >   workflow than typical BPM engines; app-workflow
> is
> > used mainly to 
> > chain multiple models and then to dispatch to
> other
> > models based on the 
> > output of the preceding one.  I know Jeff started
> > out by basing 
> > app-workflow on OSWorkflow from OpenSymphony, but
> > switched over to his 
> > own engine (RedFlow) at some point.  I think if we
> > started with a 
> > service API, it would be possible to make a
> RedFlow
> > impl. of the 
> > service.  RedFlow doesn't have support for
> > persisting flow states, but 
> > there (I think) are hooks for that to be added in
> > pretty easily.
> > 
> > Shash
> > 
> > 
> > _______________________________________________
> > User mailing list
> > [email protected]
> >
>
http://lists.keelframework.org/listinfo.cgi/user-keelframework.org
> > 
> _______________________________________________
> User mailing list
> [email protected]
>
http://lists.keelframework.org/listinfo.cgi/user-keelframework.org
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail