Some real-life jBPM action: PoC jBPM Orchestration

A few weeks ago, I did a presentation about jBPM, BI & BAM at a JBoss end-user event, organised by JBoss and Dolmen Computer Applications (the company I work for).

The main act for that event was of course the talk about jBPM and the Process Virtual Machine by Tom “Mr. jBPM” Baeyens himself. I was scheduled to talk after Tom, which made my level of inner nervosity reached values that were previously unknown. So yes, I was quite nervous. After all, one does not get the chance every day to present after and talk with the man that allows me to do my everyday job as a business process implementator. After the presentation, I got several good reactions (including from Tom Baeyens), which made it all worth the while.

Now, something more about the presentation (you can download it here).

The presentation is built around a proof-of-concept (PoC) that we at Dolmen have implemented for one of our customers . For this reason I’m not able to talk about code details here (altough I really would like to), since the code is not completely my own possession. I can, however, talk about and show you some of the ideas that were used to build the PoC. The reason why this presentation was scheduled, was to show some real-life results by using jBPM.

An overview of the PoC can be seen in the following picture:

The functionality of the PoC is as follows:

    • One application constantly generates XML reports. A business proces implemented with jBPM is used to handle these reports: some will be treated automatically and some will need some manual intervention, depending on te properties of the report.

    • Access to the business process is regulated by an EJB 3 stateless session bean service running on a JBoss server. This way, the ‘BPM service’ can easily be scaled by using a JBoss cluster since all services are stateless.
    • The report generator sends the XML reports to a Mule Enterprise Service Bus (ESB). This way, many applications can communicate with each other without having the need to ‘speak’ the language of the destination application. In the PoC, the Mule ESB routes the XML reports (received through basic TCP) to a JMS queue. During the routing, the XML report is transformed into a nice XML using the XSLT technology.
    • On the same JBoss server as the BPM service, a JMS queue is defined. The queue is processed by an EJB 3 Message Driven Bean (MDB). When a new report is received (= taken from the queue), the XML is parsed and based on the content delegated to the correct service.
      Note: the main bottleneck for the application could be found in parsing the XML reports (up to 10 seconds when the report generator generated constantly new messages). Using the StaX-compliant (JSR 173) Woodstox parser, the parsing was lowered to an average 20 ms/report. Quite impressive software, these StaX parsers!
    • Business Activity Monitoring is implemented using the SeeWhy technology. SeeWhy is an application which runs on a JBoss server and allows to define metrics. These metrics can range from a simple count to a average comparison with last week monday on the same hour. Quite impressive piece of software, if you ask me. The defined metrics can then be inspected in real-time through the browser.
      Note: the communication between SeeWhy and jBPM is done using JMS queues on the SeeWhy server. It is sufficient to send XML messages which comply to a given XML schema to this queues. In other words, SeeWhy is completely event-driven. The sending of the events can be done using a custom jBPML ActionHandler. 

    • Business Intelligence is implemented by querying the jBPM database. By default, jBPM logs all its actions to the database, so this information can easily be aggregated into valuable business information. For the PoC, the application is implemented using the JRuby on Rails framework, since time was running short (and using Rails it was done in 2.5 hours …).

The following movie gives a short demo of the PoC. The 2 little guys who are typing on their keyboards are 2 simple Java threads. Reports that are too expensive aren’t handled automatically, but they are placed into a task list of employees. Depending on some properties, the report must be handled by a clerk or a supervisor. The reason why the supervisors appear to work harder in the demo, is because the demo was presented for the supervisors … in reality, we all know who does the most work 😉

If you have any questions about this presentation, do not hesitate and contact me!


EDIT: Tom Baeyens has made a blog post about my presentation (Thanks Tom!!). If you want some explanation about the performance number measurements, be sure to check my comment on his post.


  1. Alejandro Scandroli April 23, 2008

    Hi Joram, excellent presentation! thanks for sharing.

    I’m curious about your “Dolmen Reporting Application”, which tools did you use for those nifty graphics? Is that ruport? because I don’t think they are SeeWhy graphics.

  2. Phil Wilkins April 24, 2008


    The first of the two graphs shown is the SeeWhy Navigator & the second (barchart) I believe is the results of the Ruby work

  3. Joram Barrez April 24, 2008

    Indeed, the first one is the SeeWhy navigator.
    The second one is a flash graph which needs an xml input (I can’t find the name of the library atm since I’m not on my dev machine). The job was quickly done using Rails RXML.

Comments are Disabled