Perl workflow engine (BPEL)

[JohnDrago]

Hi,

I want to build a workflow engine in Perl. I am aware of the Workflow
module on CPAN, but I am thinking of something bigger, like ActiveBPEL
( http://www.activebpel.org ).

Business Process Execution Language (BPEL) has a public spec and work
is currently underway to produce the BPEL4WS 2.0 (BPEL for Web
Services) spec.

I have done some research but I have never actually worked with an
enterprise workflow system before. If anyone reading this has worked
on such a system, your feedback would be appreciated.

From what I can gather, a workflow is defined by connecting various

events together with sequences. For instance, connecting tasks
together via objects that denote a "source" and a "target", thus
infering the direction of the flow. Borland published an article here
( http://bdn.borland.com/borcon2004/article/paper/0,1963,32091,00.html
) that goes into some detail about various parts of a workflow.

Most (or all?) current implementations of BPEL-compliant servers are
written in Java. I would like to see one in Perl. I think Perl's
data-manipulation strengths would fit nicely into such a niche. If
anyone has some Golden Nuggets of Wisdom as far as pitfalls that should
be avoided or things to focus on during implementation - I'd love to
hear it.

Thanks!
John Drago

 

[Uri Guttman]

J> events together with sequences. For instance, connecting tasks
J> together via objects that denote a "source" and a "target", thus
J> infering the direction of the flow. Borland published an article here
J> ( http://bdn.borland.com/borcon2004/article/paper/0,1963,32091,00.html
J> ) that goes into some detail about various parts of a workflow.

that is the classical academic version of a workflow. there are many
other ways to envision it. and perl is not typically ever used for such
boring academic things.

J> Most (or all?) current implementations of BPEL-compliant servers are
J> written in Java. I would like to see one in Perl. I think Perl's
J> data-manipulation strengths would fit nicely into such a niche. If
J> anyone has some Golden Nuggets of Wisdom as far as pitfalls that should
J> be avoided or things to focus on during implementation - I'd love to
J> hear it.

why are you willing to do to accomplish this? i have a module i am
working on (potentially with a google summer of code student) that could
be the guts of a workflow system but it won't ever look like anything
java could code up since it will be clean and simple and very perlish.

email me if you are serious and could contribute to this. this means
high level thinking, api issues, coding, tests, documentation,
application examples, etc. these don't come from just wishing for nice
perl modules.

uri

 

[David Combs]

J> events together with sequences. For instance, connecting tasks
J> together via objects that denote a "source" and a "target", thus
J> infering the direction of the flow. Borland published an article here
J> ( http://bdn.borland.com/borcon2004/article/paper/0,1963,32091,00.html
J> ) that goes into some detail about various parts of a workflow.

that is the classical academic version of a workflow. there are many
other ways to envision it. and perl is not typically ever used for such
boring academic things.

J> Most (or all?) current implementations of BPEL-compliant servers are
J> written in Java. I would like to see one in Perl. I think Perl's
J> data-manipulation strengths would fit nicely into such a niche. If
J> anyone has some Golden Nuggets of Wisdom as far as pitfalls that should
J> be avoided or things to focus on during implementation - I'd love to
J> hear it.

why are you willing to do to accomplish this? i have a module i am
working on (potentially with a google summer of code student) that could
be the guts of a workflow system but it won't ever look like anything
java could code up since it will be clean and simple and very perlish.

email me if you are serious and could contribute to this. this means
high level thinking, api issues, coding, tests, documentation,
application examples, etc. these don't come from just wishing for nice
perl modules.

uri

One thought:

Document the hell out of it,

With lots of:

"why you chose this way rather than that and that other one"

With even code for the way you didn't use

with maybe diagrams of one kind or another (eg uml?)

etc, etc

, and turn it into an O'Reilly book!


A "real", non-simple project, from beginning to end.


I'd imagine Google, knowing the educational purpose of the book,
and their "do no evil" ==>> "do good for the world",
would let you.

Thoughts?

David