What are the differences between service orchestration and service choreography from an intra-organization point of view.
Another way to look at Service Orchestration vs. Choreography:
- Service Orchestration: Around a Business Domain.
- Service Choreography: Among multiple Business Domains.
Service orchestration: you put together several services by a fixed logic. This logic is described at a single place. You can imagine a team of people with a manager doing micro-management. The manager precisly tells what, when and who should do. The team members do not care of the entire goal of the job, the manager combines the outputs into a single deliverable. A practical example is a BPEL process. BPEL process contains the logic, can invoke several services and combine their responses into a single service response.
Service choreography: the decision logic is distributed, with no centralized point. You can imagine a home, where everybody aims for the common good and works pro-actively without micro-management. Or you can imagine a human body, where different members are interdependent and work for the common goal. A practical example is event driven processing, where an agent is activated by an event and does its job. All the agents make a system together. There is no centralized logic. Choreography possibilities may go farther beyond orchestration as it is more aligned with the real world.
My opinion is that we do not need to distinguish much between these two, as we need to focus on the business logic. Where a single point of logic does the job, we do orchestration. Where a problem cannot be covered by a centralized logic, we are forced to choreography anyway. That is why we often come accross orchestration in IT, whereas choreograhy remains more an academical concept and a subject for research. And very often we do choreography without actualy knowing it, as in the real world.
Services can be distinguished between atomic services and services composed of other services. Such compositions are called "orchestration". Sometimes workflow, sometimes business process. For instance, BPEL is an orchestration language, but calls itself "business process execution language".
There is no requirement that services need to be hierarchically composed. That means, two services may talk to each other. The protocol running between them is called "choreography". It may be two services, but usually, there are more than two services involved. Each service in a choreography may be seen as orchestrator of the partner services. Each service taking part in a choreography may be realized as orchestration/workflow/process.
An orchestration shows the complete behavior of each service whereas the choreography combines the interface behavior descriptions of each service.
A good scientific article distinguishing choreography, interface behavior, provider behavior, and orchestration is the following one: Dijkman, R. & Dumas, M. Service-oriented Design: A Multi-viewpoint Approach International Journal of Cooperative Information Systems, 2004, 13, 337-368
Andrei and others did a good job explaining what is orchestration and what is choreography. For the software architect choosing between these two alternatives, it is also important to compare them with respect to different qualities.
Orchestration pluses over choreography
Choreography pluses over orchestration
Performance: Orchestration incurs a performance overhead due to workflow script interpretation and the additional layer of the orchestration platform itself.
Cost: Choreography does not require additional middleware or language, which have associated learning curves and governance burden.
An orchestration solution might introduce a SPOF if the orchestrator element doesn't employ a mechanism for high availability. Thanks @Deepak por pointing this out in a comment.
Both orchestration and choreography are two philosophies of process formalism at large scale, i.e. collaboration spaces. A collaboration space is a formal representation for an industry, for example health industry, food industry, automotive industry or ... . So you should have some service providers at small scale able to speak some language of communication before you decide to orchestrate them or use choreography to supply some demand meaningful to end-consumer.
Orchestration typically follows what has been famous as middleware in distributed systems. Some good tooling examples within IT industry can be Juju, Zapier IFTTT. You have centralized control, auditory, modification and trouble shooting over services you consume.
Choreography is more decentralized than orchestration in the sense that it accepts more autonomous collaborators. For example bitcoin network is a collection of service providers called nodes which collectively provide a Defi service namely distributed ledger functionality to its service end-consumers. But this does not have any centralized authority in charge, and there is no total-view over whole network. There is just a consensus machanism that if respected candidate service provider joins the network and participate in end-consumer service provision. Anywhere you need to attack trusted third party and its side effects such as corruption, an orchestration would not suffice.
Again any collaboration among actors in any industry can be subjected to orchestration or choreography, so I hope limiting examples only to IT industry is not misleading.
Also I can add, naming suggests analogy between the two and stage performance. In an orchestra, every instrument player is harmonized with other team members if he/she follows the single conductor. On the other hand analogous to stage dancing in choreography there is no conductor, each stage dancer only harmonize himself/herself with his/her partner (better if spoke as peer), with no single point of harmonization leadership. But still both present harmonization to viewers.
An orchestration typically ties together lower level services. It is like a mediator. A choreography helps reduce coupling even further. I have explained this in more detail here.