Forward
In this article I introduce straight though processing (STP), its relationship to business process management (BPM), and various associated technical details.
Introduction
Straight through processing (STP) describes the automated and uninterrupted execution of services from beginning to end. The process “start” receives enough information so that each subsequent step can move forward with uninterrupted execution. Human intervention is not required.
Business Process Management Notation (BPMN) helps illustrate STP. And, with both concept and illustration we now have an established metaphor for communicating capability across both technical and non-technical audience.
Architectural Overview: Comparing Service Orchestration Without and With BPM
Without BPM:
Though lacking an illustrated process diagram, this architecture still provides STP.
(1) User makes request to web-app’
(2) Web-app’ forwards user-request to ReST service infrastructure
(3) Service infrastructure, or SOA, then breaks out request into a series of back-office service calls
With BPM:
So let’s make our design a little more interesting by adding BPM to help communicate our concepts and ideas. We’re working towards meaningful representation. And, BPM’s pattern of linking together tasks into composite process resonates – meaning that both developers and analysts (and even management) tend to grasp this message.
Tasks, as building-blocks, can be assembled/re-assembled into composites representing business functions.
Let’s review the new architecture with a focus on the new BPM layer:
(1) Service Layer (SOA) makes a single request to BPM
(2) BPM orchestrates communication with back-office systems
(3) BPM returns results
Reference Implementation
Focusing on Business Services integration with our BPM layer. Java code example demonstrates Camunda BPM integration and omits back-office integration (keeping it simple).
(1) Service Layer (SOA) makes a single request to BPM
(2) BPM prepares a response
(3) BPM returns results
Adding Asynchronous Behavior
The above example works fine no matter the number of tasks within our process. But, I’ve noticed that all our process variables may not be returned, via the above illustrated example, if we configure a task for asynchronous behavior. This is reasonable given the context of model as it launches new threads during the course of execution.
To get all of our process variables back at the end of an asynchronous process we add the request-reply pattern. And, Apache Camel provides both excellent documentation and implementation to suit our needs.
Our ReST API is now launching our Camunda process via the Camel conext and route defined. The camel route uses WildFly’s new built-in Artemis JMS implementation to first start the process and then return results.
Let’s review the new architecture:
(1) Service Layer (SOA) sends request (message), via Camel component, to the queue: JmsBpmStartQueue
(2) Camel picks up the message and starts the BPM process via a managed bean
(3) BPM orchestrates communication with back-office systems
(4) BPM returns results to the JmsBpmStartQueue
(5) Camel forwards message back to top-level Service (JAX-RS)
Reference Implementation showing Apache Camel
(1) Service Layer (SOA) sends request (message), via Camel component, to the queue: JmsBpmStartQueue
(2) Camel picks up the message and starts the BPM process via a managed bean
(3) Bean starts BPM Process
(4) BPM returns results to the JmsBpmStartQueue
(5) Camel forwards message back to top-level Service (JAX-RS)
NOTE: Round-trip takes about 127ms (measured from HttpRequester)