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 😉
This blog is a personal blog written and edited by me. It does not reflect the opinion of my past, present, and future employer(s). All content provided on this blog is for informational purposes only. I will not be liable for any errors or omissions in this information and accept no responsibility for any damages or losses arising in connection with the use of this website. Links directing to third-party websites are used for informational purposes only and serve as a resource for the reader. I do not accept responsibility for the content of these sites or liability from use of them.