Orchestration and Choreography are often discussed as design options for event driven systems. Some use the term interchangeably while others feel that the two are very distinct. I am in the later group in thinking that the two are very distinct and lead to very different implementations and outcomes.
When thinking about these two patterns I find it helpful to relate their behaviors to the most popular implementations - music and dance.
In orchestral music the conductor is a key component to a successful production. Each person in the orchestra seeks guidance from this central figure. The conductor responds to actions by indicating shifts of behavior and actions from other sections.
In choreography the choreographer’s role is most dominant before the performance and does not take an onstage role during the performance. Dancers perform based on pre-production direction and practice but respond dynamically during the performance based on the actions take by the other dancers.
Relating this to event driven systems
In event driven systems we might consider a Process Manager as a conductor orchestrating the event process flow in production. For Event Choreography systems there is no role beyond the services making up the production performance.
Let’s consider two systems with identical functionality. One build with an orchestrating Process Manager and one based on choreography. Often in software complexity is discovered over time - versioning, additional requirements, changed requirements, system upgrade.
By change I mean change that affects other components or services. Registration for example.
Let’s assume that we have two services. One to handle registrations and the other to handle accounts. Let’s also assume that we have a service that handles sending emails. New requirements mean that we need to send a welcome message when the someone registers and a new account has been opened for them. In Orchestrated systems the Process Manager would be updated to handle the RegistrationCompleted message. The Process Manager would call the email service after creating the account. In choreographed systems the email service would be updated to listen to the RegistrationCompleted message and send the email. The changes are very similar in both cases but where those changes are made are very different. Our 'placement of function' changes radically.
Services oriented architectures allow for service changes. Let’s say we are adding an SMS or messaging service that allows users to receive SMS instead of emails for some more real-time activities like registration.
In orchestrated systems the process manager might be make this decision based on the preferences captured during registration. In choreographed systems both the email and SMS services require updating. The email service now needs to account for user preferences. In the case where a user opts for SMS the email service can ignore the event and 'assume' that there is another service that picks up the required communication. In our case this would be the SMS service.
Service Orchestration handles sequential processes well. Taking action when an event is received and then calling other services to complete the process. Service Choreography does not really support these sequential event/action sequences across multiple services. Each service needs to be independent and events at a level that give enough information that recipients and process without reference to others. I am assuming that services don’t call other services here.
Service Choreography requires more careful design because each component in the systems needs to be aware of the events around it an those events need to be at an appropriate point and level within the overall business process. Events need to contain sufficient information for imagined recipients to take action without collecting their own view of state. Service Orchestration is much simpler to think about. A process manger handles actions based on events, can handle failures, availability, reporting, workflow and a myriad of other responsibilities. Unfortunately over time without constraints it is very easy for the Process Manager to take on many system attributes and capabilities and can grow out of control.
Choosing the right design pattern for event driven systems is hard. Moving from a choreographed to orchestrated is much simpler than orchestrated to choreographed so the decision needs to be made earlier in the development life-cycle.
I have a natural bias to the lower coupling and higher availability provided by choreographed event driven systems and accept the additional design effort in crafting services with sufficient scope to make choreography practical.