Comparsion of JBPM and Imixs Workflow
If you take a closer look at the Imixs Workflow Project you may ask yourself where the project is different to other Workflow Engines like JBoss JBPM. So I will try to do a short comparison of JBPM and Imixs Workflow. This comparison is not in technical detail but it should give an overview about the goals the two open source projects. First I want to point out that the Imixs Workflow and JBPM are not rivals in the BPM market. Both projects are open source and both try to find solutions for similar but not equal problems in business process management.
In general JBPM and Imixs Workflow follow different goals in the area of
business process management. Where JBPM is more focusing on the
technical aspects of a workflow, the Imixs Workflow try to support the
users needs during a business process. JBPM gives you - as a developer
- the possibility to control the flow (workflow) in a business process.
You can provide the engine with implementations which takes care about
the current state of a process instance and you can implement event
handlers to control the transition from one state to another.
The Imixs Workflow tries to provide the end-user with informations
about the running tasks and the engine take care about typical
functionality of a human based worklfow management system.
So lets begin with the Imixs Modeler. With this technical modeling tool
you describe a business process mostly started by a user. In each
transition (WorklfowActivity) you describe what should happen with the
process instance. Therefore the Imixs Modeler provides a set of
WorklowPlugins which implement typical workflow functions like:
- Email notification (e.g. when a new task was started)
- Process documentation (what happens during a workflow of a process instance)
- Access Control (who should be able access or modify a process instance)
- Creation of Versions of a process instance
- ...and so on..
The Imixs Worklfow Plugins are comparable to JBPM ActionHandlers. But
the goal of the Imixs Workflow project is to provide precise
implementations of these functions.
So for example you can use the Imixs Modeler to configure a email
notification

The org.imixs.workflow.jee.plugins.MailPlugin will then read this
configuration during a process step and will perform sending a SMTP
Mail Message.
Or another example is the workflow History. This allows you to describe
what happens to a process during the editing by the users. This
workflow history can be displayed by an application to document the process flow.

As you can see these are less technical aspects and there is one of the differents to JBPM which is more answering the question how technical modules play together during a workflow transition. The Imixs Workflow is more focusing on human need during a business process.
But one of the most important features of the Imixs Workflow is the
access control of a process instance. You can define in each transition
who can read or modify the process instance (workitem).

These settings will be processed by the
org.imixs.workflow.plugins.AccessPlugin and mapped to the data
management used by the workflow application.
An typical scenario for this feature is a publishing process fully
controlled by the workflow engine. Imagine you have a document which is
edited by a team of web-authors. This document has a read and write
restriction so only the editor-team is able to read or modify the
document. When the document goes through a publishing process a
chief-editor can publish the document to the internet. Now the workflow
engine release the read restriction and restrict the write access to a
chief-editor team. So as a result now this document is readable by
anonymous web users but only editable by the chief-editor. The hole
functionality is completely controlled by the workflow engine and the
model description. There is no need to implement this behavior inside
the application.
So you can see the Imixs Workflow is more focusing what an actor in a
business process can do with a document or what should happen with a
document.
To get all this functionality into your application you need an
implementation of an Imixs Workflow Management System. I am talking
about Workflow Management System and not about Workflow Engine. This is
because the Engine is only responsible for the flow of a workitem and
not for the access and representation from a end-user-view.
As you can see on our project site the Imixs project consists of
different parts and libraries. There is the Imixs API which is a basic
Workflow Framework implemented in Java, the Imixs XML library which is
providing xml client functions for WebServices or Rest Services. And
the Eclipse based modeler to describe the technical model details like
email messages or the versioning of a document.
All parts are highly extensible. Also the Imixs Modeler allows to
implement an application specific plugin and control elements.
But if you want start with the Imixs Workflow "out of the Box" the
Imxis JEE Workflow is the most interesting part of the project. This is
a full featured workflow management system based on the JEE5 spec. This
implementation allows you to control any business process in any kind
of JEE/Java application. You can check out the
"imixs-workflow-jsf-sample" which is a workflow demo application and
also a good starting point to begin an individual workflow app.
There is a tutorial available which explains how all parts of the JEE
Implementation fit together.
http://workflow.imixs.org/roller/imixsworkflow/entry/building_a_imixs_workflow_webapp
As I explained at the beginning I don't want to go in technical details but give an overview what the Imixs Workflow is in different to JBPM. If you have any comments please let me know.
Posted at 06:08PM Dec 08, 2009
Posted by: Ralph
Category: Business
Posted by Document Comparison on August 11, 2010 at 12:29 PM CEST #