Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Book Excerpt and Interview: jBPM Developer Guide

Book Excerpt and Interview: jBPM Developer Guide


A new book by Mauricio "Salaboy" Salatino, the jBPM Developer Guide, provides a complete jBPM programming guide for Java developers with numerous real-life examples.

The book is a very detailed introduction in the jBPM for java developers. Mauricio starts with an introduction to business processes, business process managements and graph-oriented programming and then shows how these concepts are implemented by jBPM. The book presents a lot of details of the internal jBPM implementations and provides many practical suggestions for developers on how to better utilize jBPM in their projects. Despite the fact that the book covers the older version jBPM3, not the most current version jBPM4, many of the discussions are very relevant even for this newer release.

The book is a useful starting point for those who want to understand not only a formal jBPM syntax, but also the architectural and implementation underpinning of jBPM. There is also a review of the book by lead jBPM developer Joram Barrez available.

Packt Publishing provided InfoQ readers with an excerpt describing basic constructs of the jPDL language. The excerpt is a part of chapter 4: jPDL Language.

InfoQ spoke with Mauricio "Salaboy" Salatino to learn the motivations behind the book and learn from his experience in jBPM usage.

InfoQ: When discussing main stages of business process management, you are not explicitly referring to Business Activity Monitoring and Process Simulation. Do you consider those things important ingredients of BPM?

MS: Yes, they are very important concepts and consequences of all the BPM implementations. I do not include anything about this in the book because the book was focused on the first steps that a developer needs to know when he is switching his/her mind to the BPM paradigm. My book tries to explains all the concepts needed by a developer to use any BPM framework out there. All the post analysis of the information that we get when we run our processes are in fact closely related with Business Analysis and Data Mining concepts.

InfoQ: Describing history of BPM you are writing that introduction of SOA added a significant amount of confusion to BPM. How would you define relationships between SOA and BPM?

MS: We can see that commonly BPM frameworks are considered the glue that orchestrate all the Services inside a Service Oriented Architecture. I recognize that this perspective is well suited for technical discussions. But if we talk about BPM as a discipline, SOA and BPM are not related at all. We must choose our words wisely, in order to not confuse terminology across business contexts. This is one of the cornerstones of my book: to clarify that the BPM discipline can be applied everywhere, using different frameworks or just using pen and paper.

InfoQ: In your book you are defining BPEL as “an integration language that allows us to communicate with heterogeneous systems, which all talk (communicate) using Web Services Standards.” Does this mean that you do not consider BPEL as a process definition language similar to jPDL? Also, the BPEL/SCA binding eases use of non Web Services components with BPEL. Is it your opinion that BPEL is still purely for Web Services?

MS: I consider BPEL as an orchestration language. It is originally conceived as a system orchestrator language. BPEL is a pure technical language, the semantic used to construct the BPEL language doesn't match with the semantic needed to define Business Processes situations. In these business situations we need to express how people work everyday in a company; it doesn't matter how it will be implemented, which programing language we choose or if we decide to use Web Services or not.

InfoQ: When describing differences between GOP and OO in your book you talk about development process, three-tiered architecture, etc. What is the main difference in your mind?

MS: Once again, probably there are no big differences if you compare both paradigms technically. But if you try to represent how people work using flow charts you will notice that flows will describe the sequence of activities more accurately. I also mention in my book that when we use the OO paradigm it is not easy to represent graphically at all times where our application is. Using GOP you can see how the activities are being executed in real time. This is very important when you need to notify Managers about all the work that is being done by the company.

InfoQ: In your book you describe several approaches to the implementation of decision handlers, including decision handler, expression, etc. Do you have a recommendation for developers where to use which?

MS: In complex scenarios I always recommend using the implementation of a decision handler. This lets us delegate the responsibility of propagating the execution of the process using more complex tools like JBoss Drools (an inference engine). Externalizing these responsibilities will make your processes easy to maintain and highly focused.

InfoQ: In your book you wrote “Remember that jBPM is a framework, and not a BPM engine. The way it works very different from that concept”, but give only one example – persistence (which actually works exactly the same as in a BPM engine). Can you elaborate on how jBPM differs from a BPM engine?

MS: jBPM, as all of the BPM frameworks out there, (OSWorkflow, Drools Flow, etc) are stateless frameworks. We don't need to have a big machine with a heavy server running inside them. Each application that wants to use business processes will execute in their own memory the fragments of processes that they have in charge. For long running processes, the only requirement is a database where all the intermediate statuses will be maintained. Commonly, users that are new to this kind of framework think that they will install a Centralized Business Process Engine on a dedicated machine, but with jBPM it's the opposite. We just need a Database to handle long running processes.

InfoQ: Despite the fact that jBPM provides rudimentary support for user forms definition, you do not discuss it in your book. You do not suggest using it?

MS: I always suggest defining and using your own created screens. This will improve the users interactions and your development process. This is basically because your UI developers team don't need to learn a new technology, they can work with things that they already know, and use the jBPM APIs to populate all the information needed by the UI layer.

InfoQ: You do not discuss the jBPM administration console anywhere in the book. Do you consider it useful?

MS: I consider it useful just for developers that want to test their defined processes. I do not recommend that console for Business Demos or Production environments at all. As I've mentioned in the previous question, I consider it a good choice to create your own administration tools and develop customized UI's for your end users.

InfoQ: In the human tasks you do not discuss swimlanes for user assignment. Any specific reason why?

MS: Not really, I had to cut down some topics, as the book would have ended up with more that one thousand pages. Swimlane is an important concept, but with the appearance of standards as BPMN2, explaining the Swimlane concept adopted in the jBPM 3 version would have confused people to adopt the new standard. I've tried to only discuss topics that can be applied for newer versions of the framework. That's one of the main reasons why I talked about how to create your own BPM framework in the initial chapters.

InfoQ: You describe 2 approaches to handle information in jBPM – objects and primitive variables. Can you provide some kind of decision framework on when each one is more applicable

MS: The idea to explain the two approaches to handle the information is to give the user the flexibility to decide for each particular situation that they want to solve. In my personal experience, I saw that people always choose to use Objects when they already have a previously define data model that is persisted using JPA or Hibernate Entities. All the flow control variables (commonly boolean flags) are stored as plain primitive types. As a high level rule I always say:
Flow control variables ? Primitive type variables
Domain Specific Information (Documents, Persons, Invoice) ? Object type variables

InfoQ: You describe in your book differences between Super state and Process state. Can you provide a decision approach on when to use which?

MS: It's very easy, the “Process State” node lets you creates very high level processes. These definitions can be divided into more detailed and low level processes and then can be linked together. “Super State” nodes will let you groups yor activities inside the same process definition to order them into logical groups or phases. With Super States you can ask which phase of the process you are waiting for.

Rate this Article