Forrester’s Total Economic Impact™ Study reveals Camunda customers see a 389% ROI


Synchronous vs. Asynchronous Service Invocations – BPMN Service Task (1)

2.0 Specification provides the Service Task activity allowing users to invoke
some application service. In this
Blogpost I want to explain the difference between a synchronous and an
asynchronous service invocation in camunda BPM. 

NOTE: this bogposts covers the topic at an abstract level. If you are looking for concrete, ready-to-use examples, have a look at our quickstart repository: 


Synchronous Service

Let’s start
with synchronous service invocations. A synchronous service invocation follows
the well-known Request
/ Response Pattern

The process
engine performs a synchronous request to a service and waits for a response.
The characteristic property of this invocation pattern consists in the fact
that the process engine thread sending the request is blocked until the
response is obtained:

process engines such as the camunda process engine will typically associate a
database transaction (Process Engine Tx in the illustration above) with this thread.
a synchronous service invocation in camunda BPM is very straight forward:
  1. Model a Process containing a Service Task
  2. Attach a “JavaDelegate”-Implementation to the service task.

Check out this quickstart on synchronous service invocations to learn how to to implement this.

Asynchronous Service Invocations

An asynchronous service invocation usually follows the Request / Acknowledge / Callback Pattern:

The process engine sends the request to the service. But instead of processing the request right away, the the service first puts the request into a Queue. It then acknowledges the receipt of the request to the process engine. The request is then delivered asynchronously to the actual request processor. The request processor executes the business logic. Finally it sends a callback to the process engine which may now continue execution in the process instance. 
In practice, we encounter multiple variations of this pattern. For example, the callback itself may be delivered synchronously or asynchronously. Furthermore, the queuing of the requests may be performed before or behind the service boundary. Here is an illustration of two of such variations: 

Contrary to the synchronous service invocation, the transaction context of the process engine is  not propagated to the service implementation. In fact, an asynchronous service invocation always comes down to at least two transactions (labelled Tx1 and Tx2 in the illustration below):

  1. in the first transaction (Tx1), the request message is sent. If the request is acknowledged, the process engine interrupts execution and commits the transaction.
  2. in the second transaction (Tx2), the callback is sent and processed. This constitutes a new transaction in which the process engine resumes the state of the execution and ends the service task activity.
Implementing an asynchronous service invocation in camunda BPM is a lot more complicated than implementing a synchronous service invocation. You have to:
  1. Model a Process containing a Service Task
  2. Attach a “SignallableActivityBehavior”-Implementation to the service task.
  3. In the execute() method, send a message to the actual Business Logic
  4. Implement a callback message which is correlated to the same process instance from which the request message was sent.
Check out this quickstart on asynchronous service invocations to learn how to to implement this.
Creative Commons License
This blogpost including images & illustrations is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.