Bonita v2 Series: Part One

This is the first in a Bonita trilogy targeting the open source workflow community to share the new features included in the Bonita v2 series. Most of those new features have been discussed with users, customers, and contributors. In some cases, these features have been rewritten to fit real projects needs.

I remember 4 years ago when the first Bonita release was uploaded on the ObjectWeb forge. That was a great moment; in fact it was the achievement of some years of research based on the cooperative applications started at INRIA by the ECOO team.

In that first release a great number of new concepts were put together targeting simplicity of use, and flexibility within the definition and execution phases of a cooperative workflow process. All this on top of a J2EE application server using new technologies such as CMP 2.0, JMS, web services, ...

In 2003 the Bonita Workflow team decided to join Bull R&D. Working together with the JOnAS application server team, we improved Bonita to support business processes in addition to cooperative ones. Today, business workflow processes comprise at least 80% of the processes used in an organization.

This move positions Bonita as the only open source workflow engine known to support both cooperative and business processes. In fact, what has been accomplished in the last few years provides support for business processes (basically those ones following the model-instance paradigm), and retains the flexible approach introduced in cooperative workflow processes. For example, the ability to dynamically modify a workflow instance during execution.

Merging these radically different approaches into the same workflow engine has not been an easy task but I am pleased to announce that the Bonita v2 series achieves this goal in terms of performance, robustness, and added value features.

The Trilogy

This article is the first in a Bonita trilogy targeting the open source workflow community to share the new features included in the Bonita v2 series. Most of those new features have been discussed with users, customers, and contributors. In some cases, these features have been rewritten to fit real projects needs.

In parallel with the Bonita v2 development, we have been working together with other open source projects to provide Bonita users with new functionality. In a cooperative example, Bonita v2 recently integrated with the eXo Platform project ( allowing Bonita users to benefit from the use of the eXo portal and content management solutions.

This first article focuses on some of the new features included in Bonita v2 such XPDL support, performance enhancements, and workflow patterns review. Also introduced in this article are some of the concepts that are described in detail in the next two articles of the Bonita trilogy.

In the second article, Jordi Anguela details the new Bonita v2 iteration mechanism replacing the previous Bonita v1 iteration implementation.

The third article features Brice Revenant describing how Bonita integrates with the eXo Platform ECM project. This article provides insight into new possibilities eXo integration offers in terms of content management support.

XPDL, an overview

Now, following this introduction to the context of this open source project, let's focus on the first part of the Bonita trilogy, and start with an explanation of XPDL!

Most people are probably familiar with XPDL, but we'll start with a few words of introduction for those new to XPDL.

XPDL is an acronym for XML Process Definition Language. XML is a script language defined by WfMC (The Workflow Management Coalition) targeting workflow interoperability between different workflow vendors.

Interoperability is a common nightmare for companies using workflow solutions. Imagine a typical case where a company decides to convert an existing workflow solution to a new vendor. In this context, one of the most important issues is the way in which the existing workflow processes are migrated into the new workflow solution.

In most cases, the workflow definition language used to define the company's internal/external processes is proprietary and too specific to the vendor workflow meta-model. In those instances, the only way to move the customer to the new workflow solution is to re-define customer processes using the new vendor definition language.

Re-definition is one of the interoperability deficiencies XPDL attempts to solve. So, what is within XPDL? Looking into the XPDL syntax reveals most of the traditional workflow concepts needed to control processes, activities, transitions, or workflow relevant data. The key purpose of the XPDL specification is to define some of the rules shared by the workflow vendors simplifying the interoperability between different workflow engines.

Specifically, through XPDL two different workflow engines from two different XPDL vendors should be able to exchange, import, and execute a workflow process using the same XPDL workflow definition.

Below, is a picture from the WfMC site ( WfMC is the workflow organization in charge of XPDL definition. This picture illustrates how the same workflow definition file may be leveraged by different vendors (each using different tools and different workflow engines):

As is known, the world is not "perfect" where all workflow vendors agree to focus on the workflow features included in the XPDL specification. There is always a need for extended features or extended properties simplifying workflow definition/execution and differentiating your workflow solution from others. To facilitate those features the WfMC includes the concept of "extended attributes" within the XPDL syntax. This feature enables definition of an extended attribute within each one of the XPDL related entities: activity, process, transitions (basically additional information needed in your workflow solution).

Leveraging XPDL in Bonita v2

A major enhancement included in Bonita v2 is support for the XPDL workflow definition language. This strategic move takes Bonita to a higher level of workflow solutions focused on workflow interoperability. This feature also reinforces the Bonita project commitment in terms of integration with other information systems. This commitment started within the previous Bonita version with Hooks, Mappers, and Performer Assignment entities, the support of both ingoing and outgoing web services calls, and users' repository externalization.

XPDL support in Bonita also resolves the lack of a XML representation of the workflow process definition. In Bonita v1, the workflow process definition was stored in a relational database so the workflow user responsible for the workflow definition was forced to deal with the Bonita APIs to define and retrieve data from a workflow model. This mechanism is still in place in Bonita v2. This is helpful by allowing external applications to retrieve data from a workflow model using the Bonita API.

The manner in which Bonita v2 adds support for XPDL is intuitive. Rather than completely change the Bonita engine to natively support XPDL, we have developed a new XPDL module located between the end user and the Bonita API. This module is a Stateless session bean with the ability to parse XPDL files and access the Bonita API to store data within the relational database.

As explained, an initial goal of Bonita has been achieved. All the information is still stored in the database using the Bonita APIs. Also, the workflow execution process is persisted as well, ensuring workflow execution and recovery capability over extended execution periods. All other features such as support for cooperative processes and dynamic modification of workflow instances at execution time are also present in Bonita V2.

Writing a Workflow Process in Bonita

Here is a practical example of XPDL support using a real world workflow example: the Approval Workflow process.

This example is fairly simple to understand and use, and at the same time, introduces some of the workflow entities included in Bonita. This is also a good alternative to the "Hello World" samples which I detest.

In this Approval Workflow process, the user requests access to applications within the organization. This request is evaluated by the information system administrator which could validate (accept), or reject the request. After validation, the user is automatically notified of the decision through email.

There may not be a need for the Approval Workflow process within your organization but one could extrapolate this sample to any process providing some kind of service to users, citizens, employees...

We start by listing the workflow entities involved in this process definition. Afterwards, we proceed to the workflow model definition using the Bonita API, and lastly, perform the same operation using the Bonita v2 XPDL module.

In this manner, familiarization with the Bonita workflow entities is achieved, as well as learning the concepts and processes involved in setting up a workflow process in Bonita.

Describing the workflow scenario

The first step is to identify the workflow entities involved in the Approval Workflow process. The following is a list of entities as well as a brief description:


  • Nodes: we have divided our Approval Workflow process into three task/activities/nodes. The first node is a manual activity corresponding to the approval action performed by the system administrator. The other two nodes are automatic activities sending an acceptance or rejection email depending on the approval decision. Four nodes are specified in our example.
  • Hooks: depending on the approval decision, there is a need for two workflow actions responsible for sending an email to the user. Those actions are enabled in Bonita with the concept of Hooks. In our example, two hooks are enabled.
  • Properties: during the Approval workflow execution, Bonita handles a large amount of information containing user related data: user name, phone number, mail address, as well as synchronization data; i.e. the system administrator decision. This data is mapped in Bonita with the concept of Properties. In this example, six properties are defined.
  • Edges: edges, commonly known as transitions, define how activities are connected. In this example there are two edges or transitions.
  • Conditions: conditions are directly related to transitions/edges. Conditions are evaluated during workflow execution to determine whether or not to continue execution based on the edge/transition in which they were set. The example contains two conditions.
  • Role: roles are related to activities access in a process. In this sample we are going to define a role for the manual activity (one role).
  • Role Mapper: a mapper specifies person(s) corresponding to a specific role defined in the workflow process model. In this example a mapper is used to automatically fill-in those users matching the Administrator role defined in the process. In the example, one role mapper is defined.

The following picture represents a global overview of the entities described above in the Approval workflow process.

In this example we have considered that the request action performed by the user is part of the workflow instance operation rather than include it as the first activity of the process. This avoids the need for the user or an application build in addition to Bonita performing two different operations to create a new request.

Also note that the "End" synchronization point is included in the picture. This end point is not explicitly defined in Bonita.

As stated previously, we'll start by using the traditional way to define this workflow process in Bonita. This means we'll be using the Bonita API.

Using the Bonita API

For this first example, familiarity with the Bonita v1 series is assumed. In fact, this manner of definition for the Approval Workflow process is the same as that used with the Bonita v1 series.

If this is your first exposure to Bonita, now is a good opportunity to reference the Bonita APIs before going any further with the new features. Please download the latest Bonita API version from the ObjectWeb forge (, and follow the installation instructions ( Then, under the BONITA_INSTALL/src/bonitaStandAloneClient directory, open the README.txt file to obtain more information about this example.

Start your favorite Java IDE and open the file called located under the src/client/Java_client directory. This file contains the java code required to define and deploy the Approval Workflow sample into the Bonita engine.


To compile and execute this java file, change to the previous directory and execute the task "ant deploy_approval_java".

That was pretty easy, wasn't it? You will be happy to know that after executing this java file, Bonita automatically creates a new workflow process in the specified database as well as creating relationships with all the entities referenced in this sample. Notice that the Approval Workflow process was created through the "initModel" method call which means that it could be instantiated N times by users (the equivalent method for cooperative processes is 'initProject').

There is one more step which is the implementation of the "", "" and "" resources. The first two classes are the actions/hooks responsible for sending an email to the user containing the final decision for a particular request. Those actions are java classes implementing a defined interface. The source code of those files is found under the /src/resources/hero/hook directory (still under the bonitaStandAloneClient directory). After the "ant deploy_approval_java" task execution those files have been compiled and moved to a particular directory in the Bonita server.

When scanning the java code in those files, notice that the only operation performed is to issue a "System.out.println" message rather than send an email. (This was done to avoid having to configure email). For an email service example, under the /src/resources/hero/hook directory there is an example of a Hook sending an email using the J2EE javamail service.

In addition to the Hooks/actions, there is another java class named located under the src/resources/hero/mapper directory. This java file is the role mapper associated with the Administrator role in the Approval Workflow process. As soon as a workflow instance is created, the workflow engine executes this file to determine the users involved with this role for this particular workflow instance. In this example the logic is set explicitly so the user "admin" is always responsible for approving or rejecting a particular request.

Hooks and mappers, as well as other advanced entities that have not been used in this example are explained in detail in the Bonita reference manual (

Using the new XPDL module!

It is now time to delve into the XPDL support in Bonita v2. We sense your eagerness to start working with the new XPDL module.

As stated in a previous chapter, Bonita v2 includes a new module responsible for parsing XPDL syntax. This module is also in charge of calling the Bonita definition API which automatically stores the workflow process definition in the workflow database.

The following paragraphs proceed in the same way as before (API example), with the only difference that the Approval Workflow definition is stored in a XPDL file. Later, we will see in detail what mechanism is offered by Bonita v2 to import this XPDL file.

First, let's focus on XPDL code corresponding to the previous (API) Approval Workflow example. As in the previous chapter this sample file is found under the BONITA_HOME/src/bonitaStandAloneClient/src/client/XPDL_client directory. This time the file is called Approval_workflow.xpdl. . As seen in the following XPDL code, the file looks like a classical XML file and complies with the XPDL schema defined by the WfMC organization.

Notice that the workflow entities defined in the previous sample (API), are in bold font. These entities map to an XPDL standard entity:

Examining in more detail the XPDL code you see the extended attributes added by Bonita to define advanced entities such Hooks, activity properties, or role mappers. The following is an example of the extended attributes for the "Rejection" activity regarding the MailReject hook.


 <ExtendedAttribute Name="hook" Value="hero.hook.MailReject"> <HookEventName>beforeTerminate</HookEventName> </ExtendedAttribute>

Notice below there is an extended attribute for the "decision" property and its relationship with the "Approval" activity. This extended attribute is required because Bonita supports workflow relevant data at both process and activity levels. In XPDL, workflow data is mapped with the DataField entity which is defined only at workflow process level.


 <Activities> <Activity Id="Approval" Name="Approval"> <Implementation> <No /> </Implementation> <Performer>Administrator <StartMode> <Manual /> </StartMode> <ExtendedAttributes> <ExtendedAttribute Name="property" Value="decision"> <Propagated>No</Propagated> </ExtendedAttribute> </ExtendedAttributes> </Activity>

Finally, the extended attribute defined for the Administrator role:


 <ExtendedAttributes> <ExtendedAttribute Name="Mapper" Value="Custom" /> <ExtendedAttribute Name="MapperClassName" Value="hero.mapper.AdministratorMapper" /> <ExtendedAttribute Name="NewParticipant" Value="true" /> </ExtendedAttributes>

The "Mapper" attribute specifies the type of the mapper (custom in this case). The "MapperClassName" attribute contains the Java class associated to this mapper and "NewParticipant" identifies the "Administrator" role as a new logical role defined for the Approval Workflow (this means there is no direct mapping between our user repository, i.e. LDAP and this role).

For more information regarding extended attributes in Bonita and the Bonita XPDL module, refer to document:

At this point questions may have arisen about the XPDL source code written for the Approval workflow sample.

Well, if told that a standard text editor was used it would be a lie. Not because of the complexity of defining an example like this, but because it is easier to use a graphical editor. There are a number of XPDL editors, some available under open source. Some graph editors are available in the ObjectWeb community. In this case the ProEd XPDL editor is used. ProEd is a Bull product directly coupled with the Bonita workflow engine. Using ProEd, there is direct access to the Bonita advanced features such hooks, mappers, and properties.

Below is a display of a screen with an overview of the Approval Workflow Process using an XPDL graphical editor (ProEd in this example):

With the process definition phase completed, let's proceed with the last step of this sample; the deployment operation or, in other words, importing the XPDL file into the Bonita workflow engine.

This operation is as simple as using the "ant deploy_approval_xpdl" task under the BONITA_HOME/src/bonitaStandAloneClient directory in the API method.

This task automatically calls the import XPDL task as well as the tasks responsible for compiling and deploying the advanced resources: hooks and mapper.

This task also removes/un-deploys the ApprovalWorkflow model if it was already created in the database.

In the second/next article of the Bonita trilogy, a simple web application is introduced allowing a graphic creation of an instance of this process as well as dealing with manual activities. At the end of the current article, there is an explanation of how a java client could create a number of workflow instances using the Bonita API.

Bonita v2 and workflow patterns review

Workflow patterns are about common use cases defining a workflow process. There are a great number of studies about workflow patterns, but one of the best known is the study done by Wil Van der Aalts (

With the release of Bonita v2 we have decided to perform the evaluation of patterns using the Van der Aalts study ( The evaluation reviews each of the 20 workflow patterns and the results of this evaluation are published online at Also, we have included in the Bonita v2 distribution a java sample for each pattern to illustrate the Bonita pattern support.

Bonita v2 and iterations

Iterations are one of the major improvements in Bonita v2. Iteration support provided in previous Bonita versions was very limited so it was decided to completely rewrite the iteration infrastructure in Bonita v2. During this rewrite phase, we analyzed the common problems using iterations, cycles, or loops in a workflow graph. We analyzed not only from a theoretical point of view, but also from a practical point of view. It is true we have been dealing with typical problems in this domain such as arbitrary cycles or structured cycles, but we have also focused on the real applications needs in terms of workflow iterations.

As a result of this analysis, we have released a new iterations architecture giving Bonita v2 much more flexibility than the previous version in terms of multiple exit points and multiple iterations support.

New iterations features are described in detail in the second part of the Bonita trilogy.

Bonita v2 and performance

In a workflow project like Bonita where a great amount of data is stored in a relational database, performance is a key measurement of success for the applications running within. In addition to new features included in Bonita v2 we have also focused on a variety of performance enhancements targeting the Bonita workflow engine as well as the Bonita APIs.

The best way to present performance is to get inside Bonita and produce tests results using a concrete test scenario. For a quick performance test, use the Approval Workflow process as a sample use case.

The following lines briefly describe the injector used to stress the Approval process as well as the final results of those tests for a particular configuration.

The test process consists of scenarios (seen in the rectangle below). Those scenarios may be launched in parallel and/or sequentially depending on the targeted test.

Each scenario is a sequence of workflow statements (identified by a blue square with a St within as shown below).

A workflow statement is an action which may be triggered by an end user in the frame of a real life application scenario. In this case the workflow statements are "instantiateProcess", "getTodoList", "getInstancesListNames", "startActivity", and "terminateActivity", operations within the Bonita API.

After completion of a workflow statement, the test driver waits for a configurable think-time before launching the next workflow statement.

After launching an instance of the scenario, the test driver waits for a configurable launching delay before launching the next instance. This avoids overloading the system at the test start.

Once all planned scenarios are launched, measurement can begin. Below is a global picture illustrating this behavior:

Different tests could be performed based on the previous scenario: Pick, Aging, or Stress test, each targeting a different purpose. This example targets the results for a concrete Stress test process. The Stress test basically consists of launching tests corresponding to a heavy load scenario where the injector maintains this load for one hour.

The performance scenario is the following:


  • workflow process name: Approval Workflow sample
  • mode: Stress
  • total real test time: 60 mn
  • batch number (simultaneous users): 50
  • measure delay: 3 mn (measurements start after 3 minutes)
  • launching-delay: 200 ms
  • think-time: from 0 ms to 10000ms
  • without JMS notification

These measurements were produced on June 4, 2006, using the following configuration:


  • Bonita-v2.0
  • JVM: Sun
  • Bull Server Express 5800/120Lh with:
    • 8 GB memory.
    • 2 processors "Intel Xeon" running at 3 GHz
  • Linux 2.6.9-22 from Red Hat Enterprise Linux AS release 4 (Nahant upgrade 2)
  • Oracle version 10.1.0

For each test, report the following parameters/measurements:


  • Number of simultaneously launched scenarios

This corresponds to the number of simultaneously active users.

  • Think time
  • Minimum and average responses time for a workflow statement
  • Number of workflow statements per second
  • Analyzing the test results in the above table, we see that the first test case has 50 simultaneous users executing for one hour with zero think time between executions of workflow statements. The results show the workflow server is performing 27 workflow statements per second. Remember that a workflow statement is a unit operation performed through the Bonita APIs (i.e. startActivity, getTodoList...).

    In the other measurements, the think time is increased from 0 to 10000 ms using 1000 ms increments. In those cases, the number of statements per second is decreasing but the response time for a particular workflow statement is, as expected, better than in the previous case.

    The following graphs show the statements per second executed by the workflow engine as well as the average response time for a particular think time value:

    Switching again to the table results, observe that a for the execution scenario without think time the number of complete workflow executions is 13588. That is the number of Approval workflow instances created in one hour by a constant charge of 50 users. As our injector is performing 7 different workflow statements per instance that is a total of 13588 x 7 = 95116 workflow statements executed during the tests.

    Bonita v2 and workflow queries

    If familiar with using workflow solutions, improved and efficient queries are one of the most important features that a workflow solution must provide. Query response time determines the usability level of a workflow solution as the number of executing workflow instances increases.

    In most cases, those queries relate to more than one SQL query to a database. Usually, a workflow query is composed of a global SQL query followed by one or more other SQL queries depending of the amount of data returned to the client.

    Performances issues for workflow queries may be caused for two different reasons: a poor response time for the global query or a long response time due to the number of subsequent queries to retrieve all the workflow data.

    To avoid those problems, or at least minimize the impact when there are thousands of running workflow instances, Bonita has first optimized some of the global queries. The way Bonita performs those queries is through the EJBQL syntax, so the first improvement was the optimization of those queries. Basically, for optimization tuning we traced the SQL queries generated by EJBQL. This also relates to database tuning. For example, column indexation has a big impact in the response time spent by each SQL query.

    The second issue relates to the amount of data returned by a workflow query and multiple SQL queries. In Bonita, this issue is addressed by means of the J2EE pagination pattern. This pattern limits the number of results returned to the user by setting the "number of rows" as an input parameter. This means a user (or the end application), determines the maximum number of results expected for a given workflow query from the total number of queries. Basically, the total number of results for a particular workflow query is returned, and then those results are paginated in packages based on a defined number of elements per package.

    The Approval Workflow sample below illustrates a pagination pattern. In this example we proceed by creating instances of this process and executing workflow queries retrieving workflow data related to those running instances for a particular user.


    As in previous examples, the file described above is located under the BONITA_HOME/src/bonitaStandAloneClient sample. In this case, the file is located within the Java_client directory.

    In this example the ProjectSession API is used to create 30 different instances of the Approval Workflow sample rather than defining a workflow model as in the previous XPDL sample. This is the last operation performed through ProjectSession API before switching to the Bonita execution API. The Bonita execution API is the UserSession API. This UserSession API is the common entry point for users/applications for executing and terminating activities as well as retrieving useful data about user activities, todo lists, or lists of available workflow models...

    The above source code illustrates the new pagination API when calling methods related to workflow queries. After creation of 30 workflow instances for the Approval Workflow process, the sample source code creates an instance of the UserSession API for the authenticated user. Through UserSession API, the user is able to interact, along with other workflow queries, with the personal todo list of activities.

    In the above code sample, the getTodoListAllInstances query is called for this purpose. The goal is to return to the user/application the 30 activities corresponding to the 30 Approval Workflow instances.

    If familiar with the Bonita API, the getTodoListAllInstances method was available in the Bonita v1 series. This code sample illustrates how to use the paginated version of this method versus getting the full data in one call.

    For each get method available in the UserSession and AdminSession APIs there is a paginated version of the existing method. For instance, there is the getToDoListAllInstances method and the getToDoListAllInstancesAsPK method. The "AsPK" identifies a method which retrieves a collection of primaryKeys corresponding to the 30 activities available in the user todo list. Then, by means of the getToDoListAllInstancesByPK method, the user or the end client application retrieves a defined number of elements from the previous collection. Note, this method also has a parameter defining the value of the "offset" between two different calls.

    To run this sample, go to the BONITA_HOME/src/bonitaStandAloneClient directory and type "ant instantiate_approval." This command compiles and executes the above sample code. Don't forget to first deploy the Approval workflow sample (see the previous chapter) before running this sample.

    The following trace should appear on your command line:


     instantiate_approval: [java] 30 instances of the Approval Workflow process where created and assigned to the default user [java] Activities todo list will be retrieved using the pagination API [java] Activities from 0 to 10 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3202 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3203 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3204 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3205 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3206 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3207 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3208 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3209 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3210 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3211 [java] Activities from 10 to 20 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3212 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3213 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3214 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3215 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3216 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3217 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3218 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3219 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3220 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3221 [java] Activities from 20 to 30 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3222 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3223 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3224 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3225 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3226 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3227 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3228 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3229 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3230 [java] Activity Name = Approval, from Instance Name= Approval_workflow_instance3231


    This first article of the "Bonita trilogy" introduced some of the new features released in the Bonita v2 series from a practical point of view. If you have already used the Bonita v1 before reading this article you probably appreciate the new features and improvements such as XPDL support, API pagination, or workflow pattern evaluation. If reading this article is your first introduction to Bonita, we hope that you will begin using the Bonita v2 series instead of any other open source workflow solution in your next project.

    Perhaps because you are reading this article, you may be interested in a workflow solution which integrates easily with your project. At the same time you were probably looking for advanced workflow features, workflow standards support, scalability, and good performance. The Bonita v2 series was developed to address these issues and target production applications in a J2EE environment (meaning other platform vendors and languages could also make benefit of the workflow features through the Bonita web services APIs).

    With this first article I wanted to address Bonita concepts in a way that makes them easy to understand and at the same time useful for the reader. In the later two articles, we detail new features such as Bonita workflow iterations, and Bonita integration with the eXo platform.

    Stay tuned!





    • Roger Perey working at Bull R&D in Phoenix (USA) for the multiple revisions and feedbacks
    • Helene Joanin from Bull R&D Grenoble (France) for the tests measurements.
    • Marc Blachon working at Bull R&D Grenoble (France) for the key developments on the XPDL module
    • The JOnAS Team for their help and dedication.

    About the Author

    Miguel Valdés Faura currently is the Workflow Project Manager for Bull SAS. Prior to joining Bull, Miguel worked in Spain on different European projects based on J2EE platform and Open Source application servers. Miguel joined INRIA, the French Research Institute in Computer Sciences, on February 2001 and co-founded the Bonita Workflow System. Presently, Miguel is also member of the College of Architects of ObjectWeb Consortium. Miguel has significant experience with large enterprise applications leveraging workflow systems and the J2EE platform. He is a regular speaker at international conferences including: JavaOne, Internet Global Congress, Open Source World Conference, javaHispano Conference, ObjectWebCon, COSGov or JavaBin. Miguel may be reached at

Dig Deeper on Java web services and SOA

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.