Choreography, Orchestration and Event Driven Orchestration
Event-Driven Business Process Orchestration
Let's consider another popular approach to designing systems for managing and coordinating the execution of business tasks or processes based on events. In general, this is a mix of Choreography and Orchestration. Let's consider them in more detail.
Choreography
Choreography is the development of systems where interaction between components or services occurs without the need for a central controller (organizer, conductor – whatever you prefer). In such systems, each component is responsible for understanding its role and coordinating communication with other components of the system. It is somewhat similar to ballet, where each ballerina has her own role, but the result is a performance, not a solo program with random collisions of participants on stage.
The main aspects of architecture can be identified:
Decentralized governance: the system distributes control among the participating components. Each of them independently decides how to react to the events or messages it receives.
Autonomy: components in a well-functioning system should work autonomously, without relying on external coordination (like ballerinas: they don’t have a prompter or a person running after them shouting: “Where are you going, Sveta!!!”). They are responsible for interpreting incoming messages and triggering appropriate actions based on their internal logic.
Weak connection: This approach promotes loose coupling between components, allowing them to interact without heavily depending on each other's implementations. This aspect increases the flexibility of the system and facilitates maintenance and scalability.
Asynchronous communication: Communication between components in choreographic systems is usually asynchronous. Components exchange messages or events that do not require immediate response, which provides better scalability and fault tolerance.
Controlled events: Components respond to events or changes in the state of the system. Events trigger actions within individual components, and the system's behavior is determined by the collective reactions of these components.
Choreography is typically used where systems need to be scalable, resilient, and adaptable. For example, the abstract architecture of microservices, where each service performs a specific function and interacts with other services through asynchronous messaging. Each service only knows its own small part, and there are no strict limits on the execution of a specific, clearly defined, time-limited, global task.
Orchestration
It is generally believed (though I don’t know by whom) that the evolution of monkeys into humans began with one of them taking a stick in its hands and forcing the others to work.
In our case orchestration – the development of systems where interactions between components or services are coordinated by a central controller or orchestrator—a conductor—that coordinates the execution of various tasks or processes by directing them to the appropriate participants or systems based on predefined rules and conditions. In the context of programming and systems architecture, this means centralized control of the flow of tasks and actions in a system. A real-world example: an orchestra under the direction of a conductor. Thanks to his commands, we hear beautiful music (I wonder if there is a performance of Morgenstern with an orchestra? If so, this principle does not always work), and not cacophony.
The main aspects of architecture can be identified:
Centralized management: the orchestrator or central controller determines the order of execution of tasks and manages their distribution among the system participants.
Hard-coded processes: the order in which tasks are performed is pre-defined and configured within the orchestrated process. This may include the sequence of steps, execution conditions, etc.
State management: The conductor can monitor the state of the process execution and respond to changes, for example by reassigning tasks or making decisions based on the current context.
Resource management: Orchestration can also include resource management such as allocation of computing power, data access, and other aspects required to execute the process.
Orchestration is often used in distributed systems, microservice architecture, and cloud computing to coordinate the execution of complex tasks, such as deployment, container management, and workflow automation.
Event-driven orchestration of business processes
In our case, it's a mix of approaches, since only the Sith take everything to the absolute. But seriously, it's hard to achieve the use of one approach, most often it's a question of emphasis.
It is a design approach used to manage and coordinate the execution of tasks or processes based on asynchronous events. It involves using the principles of event-driven architecture to organize the flow of actions within a system.
The main aspects of architecture can be identified:
Decentralized execution: While a central controller manages the orchestration logic, task execution is usually decentralized. Event consumers operate autonomously, performing their assigned actions in response to events without direct instructions from the controller. Decentralization allows for greater scalability, flexibility, and fault tolerance of the system.
Asynchronous communication: Events are produced and consumed asynchronously, without the need for immediate response. This asynchronous nature allows systems to handle large volumes of events and maintain responsiveness even under varying loads.
Dynamic adaptation: This approach enables dynamic adaptation of workflows based on changing conditions or requirements. Workflows can evolve over time as new events occur or the system state changes, enabling rapid and flexible process management.
For a better understanding, let's also look at the key components:
Event Consumers – components or services in a system that monitor and respond to events. These consumers are responsible for processing events and initiating appropriate actions or workflows. They subscribe to specific types of events and perform tasks based on the event data.
Event Brokers — Message queues, or publish-subscribe systems, facilitate interactions between event producers (components that generate events) and event consumers. They act as intermediaries that route events to the appropriate consumers based on subscription criteria.
Controller (Conductor) – is the central component responsible for coordinating the flow of activities based on the events received. It analyzes incoming events, determines the sequence of tasks or actions to be performed, and delegates execution to the appropriate components or services. The orchestrator can maintain the state of ongoing workflows and manage the overall execution logic.
“Okay, but this is even driven orchestration,” you might object, “what are the benefits of business processes?” Below we will consider the main benefits:
Centralization of the decision-making process: Process orchestration tools like Camunda are designed to help you decide what should happen in a business process and then take action accordingly. This means that decision-making responsibility can be removed from places where it doesn’t belong. It’s also easier to make changes to meet changing technical and/or business requirements.
Using BPMN (Business Process Model and Notation) diagrams in development: processes are described using visual diagrams, this is both documentation and an easy way to make changes to processes, conduct a quick audit of the system, quickly find logical errors in processes, directly use the experience of people who understand business processes, but know nothing about programming or UML diagrams. In addition, BPMN provides an excellent set of ways to handle “bad scenarios”.
Micro example: “Food delivery”:
*For simplicity, the example only implements the success flow.
Key Components:
Service-Conductor (My Delivery) — is a SpringBoot microservice that includes Camunda (Community edition) as a built-in engine BPMN processesCamunda is added as an application library and can be started, stopped, and scaled along with our microservice.
Business Model in BPMN Notation
Model components:
Service tasks are used to call or run business logic. For us, this is checking for product availability, cooking food, finding a delivery person, and the delivery itself.
Intermediate Message Catch Event: a stage of a process at which the corresponding process instance waits for an incoming message before starting a flow.
Start and Stop events: I think an explanation would be unnecessary here.
Parallel gateway allows you to run processes in parallel, we assume that finding a delivery person and preparing food can be done in parallel, and sent for delivery only if both processes are completed.
For simplicity and to reduce the amount of code (written with the left foot today), third-party microservices are presented as event listeners in our application (com.delivery.camunda.listeners). In reality, these will be applications where a cook or a delivery person will react to receiving an order. Process handlers: com.delivery.camunda.delegates. In our case, to simplify things, they simply forward the message.
https://github.com/kain64/deliveryexample/tree/main
In general, this is an interesting thing, Camunda, I will have to… in general, BPMN and Camunda have been written about many times, so no need. So the ending is crumpled. I hope I did not tire those who have mastered it with my reasoning.
