The BPMN 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 blogpost 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
Invocations
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:
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:
Transactional process engines such as the Camunda process engine will typically associate a database transaction (Process Engine Tx in the illustration above) with this thread.
Implementing a synchronous service invocation in Camunda BPM is very straight forward:
- Model a Process containing a Service Task
- 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 (labeled Tx1 and Tx2 in the illustration below):
- in the first transaction (Tx1), the request message is sent. If the request is acknowledged, the process engine interrupts execution and commits the transaction.
- 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:
- Model a Process containing a Service Task
- Attach a “SignallableActivityBehavior”-Implementation to the service task.
- In the execute() method, send a message to the actual Business Logic
- 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.
This blogpost including images & illustrations is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.