-
Announcing Sarasvati: an Open Source Workflow/BPM Engine (11 messages)
- Posted by: Paul Lorenz
- Posted on: November 05 2008 07:47 EST
Sarasvati is an open source workflow/business process management engine for Java and Haskell. It is currently in beta, and is already suitable for use in many projects. Features: * Simple, well documented, graph execution based core * Process modularity via load time or run time process composition * Process and token level attributes * Node Actions can be implemented in scripting languages. * Execution history available through tree structure of immutable tokens * Node guards which allow bypassing nodes or discarding tokens for flow control * Domain specific language (GuardLang) for user understandable guards * Java implementation with Hibernate and memory backed engines * Alpha Haskell implementation with HDBC and memory backed engines * LGPL license Why might you want to use Sarasvati? * Load time process composition gives you tremendous flexibility in modularizing your process definitions * You want to provide transparency to your users * The code base is extensible and customizable * You don't want the workflow engine to dictate how users, groups and tasks should be modeled. Why might Sarasvati not yet be useful to you? * It currently has no graphical editor (planned for a future version). * It only runs on Java 1.5 or newer * It does not yet have a turn key solution for users/groups/tasks. The current version of Sarasvati is 1.0.0-beta2 and is available for download. Documentation: * What is workflow? * Core Concepts * User's Guide Sarasvati welcomes users and contributors. Please send comments, questions, etc to the user forum at: http://groups.google.com/group/sarasvati-wf-usersThreaded Messages (11)
- Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine by Nagraj Chakravarty on November 06 2008 11:20 EST
- Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine by Kumar Mettu on November 06 2008 14:17 EST
- Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine by Paul Lorenz on November 06 2008 08:11 EST
- Agree by Joshua Partogi on November 06 2008 17:39 EST
-
Re: Agree by Kumar Mettu on November 06 2008 08:11 EST
- Re: Agree (Designer response) by Ronald van Kuijk on November 18 2008 11:41 EST
-
Re: Agree by Kumar Mettu on November 06 2008 08:11 EST
- Motivation for developing Sarasvati by Paul Lorenz on November 06 2008 19:49 EST
- Re: Motivation for developing Sarasvati ('jBPM' Response) by Ronald van Kuijk on November 18 2008 11:32 EST
- Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine by Kumar Mettu on November 06 2008 14:17 EST
- Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine by Kenneth Mark on November 11 2008 02:20 EST
- Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine by Ronald van Kuijk on November 18 2008 11:45 EST
- Naman by Naman Sah on April 30 2012 04:23 EDT
-
Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine[ Go to top ]
- Posted by: Nagraj Chakravarty
- Posted on: November 06 2008 11:20 EST
- in response to Paul Lorenz
Questions: 1) I wonder what the motivation behind Sarasvati is ? There are several dozens of open source Workflow engines already (http://java-source.net/open-source/workflow-engines) 2) Can it integrate with a Project Management tool ? -
Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine[ Go to top ]
- Posted by: Kumar Mettu
- Posted on: November 06 2008 14:17 EST
- in response to Nagraj Chakravarty
(I am not associated with the project and this is purely my personal opinion) I have worked on developing a commercial workflow engine before (circa 1998) which has 10K+ seat installations. So I have some idea on what a workflow engine is and what it needs to provide to the minimum. I understand with web requirements for a workflow engine has changed. Recently I was looking for a workflow engine to be included as part of the product I am working on. Here are the basic requirements I have: 1. Simple Graph execution engine. 2. Simple way to define Process Definitions (Both UI based and XML based) 3. Easily embeddable in a web application. None of the opensource projects mentioned at http://java-source.net/open-source/workflow-engines fit the requirements. Some of the projects I am not sure is even worth calling a workflow engine. So far Sarasvati looks good to me. I am going to be play with it and see if it is what I want. -
Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine[ Go to top ]
- Posted by: Paul Lorenz
- Posted on: November 06 2008 20:11 EST
- in response to Kumar Mettu
Hi Kumar, I'm interested to hear the results of your evaluation (positive or negative), to help me improve Sarasvati. So if you have the time and are so inclined, let me know what you think on the user forum. I would very much appreciate it. cheers, Paul -
Agree[ Go to top ]
- Posted by: Joshua Partogi
- Posted on: November 06 2008 17:39 EST
- in response to Nagraj Chakravarty
Questions:
Agree. I'm already comfortable with jBPM now. What does sarasvati has that jBPM don't have?
1) I wonder what the motivation behind Sarasvati is ?
There are several dozens of open source Workflow engines already (http://java-source.net/open-source/workflow-engines)
2) Can it integrate with a Project Management tool ? -
Re: Agree[ Go to top ]
- Posted by: Kumar Mettu
- Posted on: November 06 2008 20:11 EST
- in response to Joshua Partogi
I want to use jBPM too but the fact that you need eclipse to be doing process definition tells me its a product developer's can get excited about and never really be implemented successfully in a company. -
Re: Agree (Designer response)[ Go to top ]
- Posted by: Ronald van Kuijk
- Posted on: November 18 2008 11:41 EST
- in response to Kumar Mettu
Hmm... Agreed and Not, mostly not. A standalone version of the GPD will be made and that hides most of the Eclipse tech stuff. Otoh, have you seen other tooling? I know of two free BPMN editors(BPMN focusses on Business People) that a just as technical (one eclipse based, one from Enterprise Architect). The thing is that in most cases you will need two editors or make it a joint effort to get somewhere. My personal experience is that when a semi-tech guy (architect?) and a business guy sit together, you get the best results. Even when using the jBPM designer (Tom Baeyens, jBPM project lead and founder has blogged a lot about this) As a semi-insider (do not work for JBoss), I have some information with which I can easily provenever really be implemented successfully in a company.
is not true. Check the reference page (large dutch bank in there) and the releasenotes of 3.3 which just came out.
-
Motivation for developing Sarasvati[ Go to top ]
- Posted by: Paul Lorenz
- Posted on: November 06 2008 19:49 EST
- in response to Nagraj Chakravarty
Questions:
Hi Nagraj, I had a couple of reasons for developing Sarasvati. To give you some background, I've been maintaining a proprietary workflow engine and writing process definitions for the engine over the last four years. The engine is about 10 years old and is based on hierarchical colored petri nets. On the whole it has done well, but for several reasons we are looking for a replacement. Before I started development, I looked at that site you referenced. Most of the projects there aren't usable for my purposes, either because they are no longer maintained, because they weren't graph based or because their API was too limited. The only engine I did serious research into was jBPM, which is maintained, graph based and quite extensible. I found several issues with the it, some of which may have resulted from misunderstanding on my part or may since have been addressed (someone with a deeper understanding of jBPM may wish to reply). 1. The default split/join mechanism seems clunky and seems to require the outgoing arcs of the split to be matched by the incoming arcs on the join. So if you have a (poorly drawn ascii) graph like A--> B-------> F \-> C--> D --/ \-> E -/ Then it breaks, because when a token arrives at A, it generates child tokens on B, C. The child at C will generate its own child tokens on D and E. F will receive a token from B, and will expect 2 total tokens to arrive, since the parent of the arriving token only has two children. I have two issues with this. First, I realize you can write your own split and join nodes. However, I would expect this behavior to built in. Second, I don't like the need for explicit split and join nodes. In Sarasvati, splits are implicit. When you specify an outgoing arc name, tokens are generated on all arcs which have that name. Any node can be given join node behavior. A join node will wait for tokens to exist on all incoming arcs which share a name. This makes process definitions more concise. 2. The only method jBPM supports for process composition and modularization is via nested processes. This means that the included process definition is run in a separate process, and can have only one input and output. If you want a nested process with (for example) both success and failure outputs, this will have be passed via a token attribute, and can't be expressed via regular graph connections. Sarasvati supports these kind of nested processes, but also supports load-time composition of processes. Here you can link to an external process definition and that external process definition will be pulled into your graph, formed a single 'flat' graph. This means you can have arbitrarily complex linkages to and from the nested process definition. See here for a longer explanation. 3. Finally, I wanted an easy way to track the history of a process execution, so it could be displayed to the user. AFAIK, jBPM has a log for this. I'm not sure how easy or hard it is to use. Sarasvati uses immutable tokens for this. Rather than moving along the execution path, Sarasvati creates new tokens per node and arc traversed. This builds a directed acyclic graph (DAG) of the graph execution history. The DAG makes it easy to show a visualization of process history. I have some code which does this under the visual/java-visual folder in Sarasvati SVN, which people are welcome to look at. It's not release ready yet, but is functional enough to be interesting. Having said all that, I don't want to disparage jBPM at all. I got a lot of inspiration from them and they have a great project that has features that Sarasvati doesn't yet. Regarding integration with a project management tool, I'm going to guess no, but I'm not exactly sure what you are asking. Could you elaborate? cheers, Paul
1) I wonder what the motivation behind Sarasvati is ?
There are several dozens of open source Workflow engines already (http://java-source.net/open-source/workflow-engines)
2) Can it integrate with a Project Management tool ? -
Re: Motivation for developing Sarasvati ('jBPM' Response)[ Go to top ]
- Posted by: Ronald van Kuijk
- Posted on: November 18 2008 11:32 EST
- in response to Paul Lorenz
1. The default split/join mechanism seems clunky and seems to require the outgoing arcs of the split to be matched by the incoming arcs on the join. So if you have a (poorly drawn ascii) graph like
Nice drawing ;-)... But you are right. That is the default and only out of the box jBPM behaviour in jBPM 3
A--> B-------> F
\-> C--> D --/
\-> E -/
Then it breaks, because when a token arrives at A, it generates child tokens on B, C. The child at C will generate its own child tokens on D and E. F will receive a token from B, and will expect 2 total tokens to arrive, since the parent of the arriving token only has two childrenI have two issues with this. First, I realize you can write your own split and join nodes. However, I would expect this behavior to built in.
The reason it was not in there out of the box was the fairly limited amount of requests that came in for this. The core would have made it possible and I even think contributions in this direction would have been acceptedSecond, I don't like the need for explicit split and join nodes. In Sarasvati, splits are implicit. When you specify an outgoing arc name, tokens are generated on all arcs which have that name. Any node can be given join node behavior. A join node will wait for tokens to exist on all incoming arcs which share a name. This makes process definitions more concise.
I think you can argue on this. It has pro's and cons. Many people are used to having explicit forks in UML, BPMN etc... so that is one of the reasons explicit forks/joins are there.2. The only method jBPM supports for process composition and modularization is via nested processes. This means that the included process definition is run in a separate process, and can have only one input and output. If you want a nested process with (for example) both success and failure outputs, this will have be passed via a token attribute, and can't be expressed via regular graph connections.
Correct, from what I know (a lot but not everything), you can only have one outcome from a subprocess. But again, not a lot of requests have come in for this and most people were happy with using a processvariable for this. And... I also think that contributions in this area would have been accepted :-) jBPM 4 will probably support multiple outcomes of subprocess nestingSarasvati supports these kind of nested processes, but also supports load-time composition of processes. Here you can link to an external process definition and that external process definition will be pulled into your graph, formed a single 'flat' graph.
jBPM has the notion of a superstate, but just not with the definition in external files. Without wanting to repeat myself to much, there has not been a lot of requests for this either and contributions in this area would have been welcomed as well ;-)3. Finally, I wanted an easy way to track the history of a process execution, so it could be displayed to the user. AFAIK, jBPM has a log for this. I'm not sure how easy or hard it is to use.
not hard to medium. You have to dig into it a little, but it is just 'nested' data like the processdefinition itself. It is just data in the database accessible via hibernate api's to give the user the freedom he/she wantsHaving said all that, I don't want to disparage jBPM at all.
I (we) know ;-)I got a lot of inspiration from them and they have a great project that has features that Sarasvati doesn't yet.
I know ;-) -
Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine[ Go to top ]
- Posted by: Kenneth Mark
- Posted on: November 11 2008 02:20 EST
- in response to Paul Lorenz
Many talk about Jbpm but I found using it on others application server than Jboss is not easy at all. I'm not quite sure but I think Jbpm is highly coupled with Jboss projects like seam. -
Re: Announcing Sarasvati: an Open Source Workflow/BPM Engine[ Go to top ]
- Posted by: Ronald van Kuijk
- Posted on: November 18 2008 11:45 EST
- in response to Kenneth Mark
Many talk about Jbpm but I found using it on others application server than Jboss is not easy at all.
The core or the webconsole? The latter is true, the former certainly not. I've implemented it even on Weblogic Server 8.1 with JDK 1.4.2 without a problem.I'm not quite sure but I think Jbpm is highly coupled with Jboss projects like seam.
I'm quite sure, no I'm completely sure it is not. Yes many people use them together to leverage two great (shameless plug) frameworks, but it can easily be used without and develop your own ui (even swing based in a fat client!!) -
Naman[ Go to top ]
- Posted by: Naman Sah
- Posted on: April 30 2012 04:23 EDT
- in response to Paul Lorenz
hi i am intrested in learning one of the workFlow engine..can any one help to get the Easiest ..
or if any one can help me to learn Sarasvati.