The first version of Bonita Workflow Cooperative System is released for JOnAS, in order to take advantage of the latest version of JOnAS application server.

Bonita is a OpenSource workflow execution engine. Its goal is to support the definition and execution of cooperative processes. It is based on a classical graph based workflow model, with an advanced execution model that allows different kinds of execution strategies: from classical, automatic to less constrained, user driven process execution. Moreover, an executing workflow can be changed dynamically to reflect process evolution.

The development of the Bonita Workflow engine is built on EJB (Enterprise Java Beans) technology that is the server-side component architecture for the J2EE (JavaTM 2 Platform, Enterprise Edition). EJB enables rapid and simplified development of distributed, transactional, secure and portable Java applications. We have chosen JOnAS application server (http://jonas.objectweb.org/) in order to deploy Bonita Cooperative Workflow System.

Bonita offers a comprehensive set of graphical tools integrated into a single package in order to perform process conception and definition, the instantiation and control of this process and the interaction with the users and other applications.

- Bonita modeling component

The workflow modeling component in Bonita is the GraphEditor application that allows users to formally represent and visualize Workflow processes. These workflow processes are composed by simple units, named activities, and the connections between these activities, are known as edges. With the GraphEditor tool, users can define and edit activities that compose every processes. We can also set activity attributes (activity type, activity description, activity execution mode, activity deadline, activity role...) and associate actions or/and properties.
To support the new generation workflow concepts, bonita modelling component allows at run time the definition and visualisation of the process by different users. This flexibility involves some coordination and groupware methods in order to ensure the dialog between participants, when necessary.

- Bonita execution component:

The Workflow execution engine in Bonita is based on flexible data management and on flexible workflow execution. Flexible data management allows activities to exchange data in a better way than traditional data flow models. Our data model is closer to the data exchange that occure in real life cooperating activities. Complementary, flexible execution allows activities to be enacted in a more natural way than traditional workflow models.
To allow users to control the process execution, the system offers the WorkList application. The Worklist application provides different information about the projects for each user. This information is organized in three list: project list, to do list and activity list. When the user select one project from its project list, he obtains the executing activity list (executing or anticipating states) and its assigned activities (ready or anticipable).

View the Bonita Workflow System

Some time ago our company had a search for good forkflow system based on J2EE standard. We need workflow to create and customize our software product more productively. I inspected WWW and found about 10 workflows, but some of them were too expensive, some of them were strange and unclear. Seems like although we have wide choice of workflow engines, there are no standard and leader in this area (like Struts for web applications). As a result we put aside this idea for some time. What do you think (or know) about situation with J2EE-based workflows?

Same here. We chose WebLogic Integrator (WLI) but in its 7.0 incarnation, the tool is far from perfect. What did you end up using?

I also wish there were more of a consensus on workflow engines... The field seems really immature.

I have looked into three different workflows:
* cibeles: way to simplistic, doesnt allow custom forks or joins.
* shark: non-standard, and complex ugly code that made my head ache
* jBPM: the one I have looked into most, I like the metaphor of using UML activity diagrams, but overall its to tightly coupled with its presentation, and what the h*ll is image coordinates for some picture doing in an activity?! Perhaps a bit on the heavy side with a couple of too complex "Manager"-classes that are always a pain to test

Also, there seems to be a lack of running these outside of a container, heavy coupling to J2EE stuff like EJB:s and a lot of use of mandatory persistence.

What would really be needed is a workflow engine with a service oriented architecture that can stand on its own or inside a container, low/no coupling or dependencies to other services (jBPMs webforms are a good idea, but should in no way be so coupled to the workflow engine).

Well, those are at least my somewhat incoherent thoughts on the state of workflow engines (its friday..)

Clarification on shark: by non standard I meant that it seemed to have some home-grown server solution, not running inside a J2EE container by any means possible. It does follow all the buzz-word BPM standards, which makes it a bit to complex and heavy for my liking..

Start there and then add more. Last I saw with Jonas, they did nto have clustering, their JMS implementation was a joke, their EJB stuff is old, etc, etc, etc.

What is it with all of these French open source clowns? What ever happened to good closed source software from America and India. All I want is something that works, I like BEA.

Arun

Unlike some other open source J2EE application server, JOnAS has easy to find documentation, so you should have known better:

http://jonas.objectweb.org/current/doc/

Clustering:
http://jonas.objectweb.org/current/doc/howto/Clustering.html

CMP 2.0:
http://jonas.objectweb.org/current/doc/CMP2.html

JMS:
You can use Joram, SwiftMQ or WebSphere MQ
http://jonas.objectweb.org/current/doc/Config.html#Jms

Hey look at the IT news.. redhat and suse joined Objectweb and jonas team. Do u think they are wrong ?
U think you are better than them ?

> Well, those are at least my somewhat incoherent thoughts on the state of workflow engines (its friday..)

We (at my firm) are currently in test mode for a proprietary J2EE-based workflow engine that I architected and help build. The primary design goal was total decoupling between enaction and hosting semantics. Meaning that you can run the engine equally well in a web/J2EE container or just in any JVM.

The engine is configured via XML using UML activity diagrams (after passing over Wfmc, XPDL, statecharts and a bunch of other things). Currently the definition language (and the engine) supports forks, joins, decisions and embeddded subflows.

Messaging (JMS - any provider) is used for integration as well as orchestrating the enaction. The engine also includes configurable web forms that can be hooked in as part of the workflow process, but the engine is, in itself, just a workflow engine. The idea was to create a highly configurable, easily extensible micro-kernel.

It isn't easy to build one of these engines. But it's worth the effort. Can't really say much more than this as the details are confidential. The engine is meant to be used for internal consumption, so probably won't see the light of day on its own.

The idea behind this post was to emphasize the need to actually decouple the workflow engine from EJB or web semantics. Support them, thrive on then, but don't depend on them.

This was a key priority for us. Among other things, it helped unit test the engine using "just any JVM".

Sandeep.

PS: We looked around prior to committing to the proverbial reinvention of the wheel. All in all, we probably examined well over 20 engines.

I should have said UML activity diagram "semantics".

Sandeep.

The idea behind this post was to emphasize the need to actually decouple the workflow engine from EJB or web semantics.

You haven't really done much to explain why this decoupling is so important. I think that for most of us, requiring a J2EE container would be a small price to pay for a functional, robust, workflow engine.

Well, first of all, let me define what I mean by "coupled to J2EE" in this context. It means that the primary form of implementing business logic within the context of the workflow engine takes the form of Session beans, and/or the workflow engine is tied to expressing itself in terms of web-based forms and interfaces.

That is not what "our need" was. We needed to be able to run our processes independent of EJB, Servlets, JSP and the lot, yet be able to leverage these constructs when we wanted to.

So, we see ourselves as getting more out of this decoupling than less.

Sandeep.

Hi Wille,

* jBpm is not tightly coupled to its presentation : @see the components picture. Every component is exposed as a session facade. In the database tables (which are completely decoupled from the client interface), the presentation data is stored together with the process model for performance reasons. In not used, these presentation-data-columns could easily be removed.

* The jBpm implementation is not coupled to an ejb-container : We use the ejb-container for 2 purposes authentication and transaction mgmt. All other other implementation is separated and decoupled from ejb-container. Running jBpm outside an ejb-container is not (yet) supported out-of-the-box but it takes minimal effort to do so. The intention is that also transaction mgmt will be moved to the ejb-independant-implementation to make it even easier to run jBpm outside a container. The main reason for using ejb technology is clusterability.

Regards,
Tom Baeyens
Founder Java Business Process Management
Member of the JSR207 expert group : Process Definition for Java

Ok. Thanks for the info, I just zipped through the codebase a while back, and liked quite a few solutions (such as the general semantics used, which kind of set the benchmark for semantics for me), but disliked others (like the picture coordinates, minor but "eye-poking" to a purist). I saw that the code has changed quite a bit from the last time I looked at it. Will have a look at it again.

"like the picture coordinates, minor but "eye-poking" to a purist"
--> We'll work on it. Thanks for the feedback.

Regards, Tom.

Hi,

About workflow standards, the next Bonita version will use xpdl workflow definition language to allow relationships with other workflow engines. With this functionality, the user can, for example, use his favorite workflow definition client and then import xpdl workflow file in order to use Bonita workflow engine...

Miguel

Here's a list that I collected a few weeks ago:

Open Source Workflow Engines Written in Java

Listed are 15 java open source workflow engines. I'm sure there are others that I have missed, for example I haven't heard of con:cern but I'll add it to my list!

<quote>
I inspected WWW and found about 10 workflows, but some of them were too expensive, some of them were strange and unclear. Seems like although we have wide choice of workflow engines, there are no standard and leader in this area (like Struts for web applications). As a result we put aside this idea for some time. What do you think (or know) about situation with J2EE-based workflows?
</quote>

Have you looked at using a BPEL engine for embedded workflow? There are two such solutions on the market today compliant with the BPEL 1.1 specification - ChoreoServer (OpenStorm, based on .Net) and BPEL orchestration server (Collaxa, based on J2EE). Both are available for download and evaluation.

Doron Sherman
CTO, Collaxa.
www.collaxa.com

I would also recommend anyone to look at the BPEL activity.
This is an abstracted, language and technology agnostic business process specification. Implementation like Collaxa's has some hooks to connect java objects directly in the workflow.

For a free implementation, you can try the BPEL implementation from IBM, it even comes with an Eclipse plugin. Last time I have tried it, it was not fully compliant with the latest release of the spec, but you can have a pretty good grasp at it.
Many and many articles have been written on BPEL.
A recent even go through an example involving UML, eclipse.

Check this out:
http://www-106.ibm.com/developerworks/webservices/library/ws-uml2bpel/

Cheers

Olivier

I am puzzled indeed. Why are there so many workflow definition standards? Which standard I should follow up, and which implementation product of them I should use? Anybody can give me an detailed guide?

In march I tried to create an inventory of specs and open source tools for workflow. Its not complete but it gives a start : http://jbpm.org/article.html

Regards, Tom.

Thanks, really useful stuff!

Hi,

some details about the different languages can be found at:
http://tmitwww.tm.tue.nl/research/patterns/standards.htm
and (especially for XML-based) http://xml.coverpages.org/wf-xml.html

If XPDL from WfMC (Workflow Management Coalition) is your choice, you may have a look ak wfmOpen which is an implementation of a J2EE-based XPDL-engine.
It runs out-of-a-box in JBoss 3.2.x and (very important!) is it documented very well.

URL: http://wfmopen.sourceforge.net

bye,
Andreas

Nikita,

I really share your opinion that there is no standard or leader in the area, although there are specifications plenty. I see 2 main reasons :
1) lack of focus : Most tools and specs are designed towards a certain application domain. As a result, every model has slightly different concepts. (In jBpm we have tried to separate the core state-machine-engine from all other aspects involved.)
2) difference between academic and commercial ideas : The academics are working on this topic already for a long (focus is on mathematical models). Commercial companies seem to have complete different approach. As a result, they cannot benefit from each others work. One research project that successfully made the bridge was Wil van der Aalst's Workflow Patterns.

I believe that your company is not the only one that is not investmenting in this area because of the standards issue. This is regrettable because a solid workflow engine could save many development projects a lot of time. But what to do... create yet another spec ? No not yet. First we should use open source for innovation until one metamodel gets broad acceptance. This metamodel should be a clear definition of something like a state-diagram or activity-diagram, extended with exact runtime execution semantics. Only when such a model becomes mainstream it is time for 'the final' spec.

Let me explain what I mean with "open source for innovation" : Open source projects get much more feedback then commercial companies can pay. On top of that, open source can adapt a lot faster (not comparable) then standardisation committees. Conclusion should be that open source is a furtile environment for innovation.

ps: with 10 workflow systems, I think you have found about 5% :-)

Regards,
Tom Baeyens.

Your concerns are real and correct Nikita,

However, there is a Workflow Engine/System being developed at
the moment that follows the WfMC (Workflow Management Coalition)
defined standards on workflow enactment.

The WfMC is really quiet a good standards body to follow,
and this product follows its WfDL spec which is enough
to form a 'standard' that all Workflow systems should conform
to.

Watch out for NetFLO...

John

Any workflow system providing microsoft office integration?

One good choice for a workflow is jBPM : http://www.jbpm.org

We have integrated in the eXo platform enterprise distribution (OSS too).

Te main idea behind jBPM is the notion of "interactions" that allows to decouple activities (BP units) from Informational System.

Hi guys,
    There is a embedded worklow engine based on CPN (coloured petri nets) that is very flexible , decoupled from a specific technology like ejb or whatever. It has a clear separation between workflow logic and application logic and is licensed under GPL so , take a look and enjoy ;-)

Leonardo

Sorry guys, the url is http://www.bigbross.com/bossa/

Leonardo

Thank you for your useful information, Andreas Kraushaar and Tom Baeyens :)

But up to now, I have not heared anybody talked about the shark engine.

URL: shark.enhydra.org

From last week I have already get a dip into this implementation yet. It used CORBA and it's an independent Server itself(just Workflow server). An GUI designer is also included in the project.

How do you think about this Workflow Engine? And compared with WFMOpen?

THANKS.


PS. I have used OSWorkflow and OFBiz. The former one is smartly designed indeed, but anyway, it's too simple when it comes to a practical project. To the contrary, the OFBiz is so complicated that I can't understand it very well.

As Huang already said: shark uses it's own server and (imho) is not so easy to embed in J2EE-based applications.

I guess we have to distinct between designing processes/workflows and running instances of them in a (hopefully open-source) workflow engine.
It slightly happens that you are running your processes in a certain engine because you have to use (or like to use) a specific description language for your processes (maybe XPDL) or a specific editor (like JaWE from enhydra.org).

If there would be a robust solution for convert your process definitions from one language to another, we would have more flexibility to run those processes in an engine that fits into our applications regardless of the used editor.

In my opinion popular engines like jBPM would enlarge their user community if they support standards like XPDL.
I will watch the progress of JSR-207/JSR-175 for widely-used standards.
Unfortunately I can't recognize any involvement of the WfMC and XPDL...

Maybe I should write something like xpdl2jpdl... :-)

bye,
Andreas

There's not only lots of competing standards and products. There are completely different approaches out there, serving totally different requirements. Maybe our expectations are too high. Using WF techniques can increase efficiency but it will never decrease complexity. You will never enable a non technician to model your business, not with the smartest graphical modelling tool. However, this seems to be the approach of most products available.

I don't like all the activity-diagram-based approaches anyway. IMHO, Petri nets and case handling are much more appropriate for modelling business processes / etc. This is what con:cern does.

Holger Engels

What is IMHO?

LOL

What is IMHO?

In My Humble Opinion

It seems Bossa is GPL, meaning I can't embed it without a license (or making a commercial product GPC, which I cannot do).

It is unclear what Bonita's license structure is. It is not obvious from any of the documentation on the site.

JBPM's appears to be Apache. Hooray.

Hi,
Bonita is in LGPL license. You can find it at BONITA_HOME/legal directory.

Miguel

Another OS workflow in the 'shopping' cart : http://www.openwfe.org

It's not XPDL enabled (for the moment), it's not tied to J2EE (though it's java).

also worth a look : http://www.topicus.nl/topwfm

The correct spelling is "anticipatable", not "anticipable" - correct your source code too!

Where did you see the word 'anticipatable' in my comment or my source code ?
Are you sure you replied to the comment you intended to ?

...