As we know that Web Services are actually application components each of which normally performs one discrete functionality of the overall application. So, we definitely need some way of combining these individual components to make the entire application work. There are two popular ways of combining Web Services, which are:-
- Orchestration - we have a central controller in this case and it can be executed
- Choreography - we don't have any controller here and it can't be executed directly
In this case we have a central controller process which controls and co-ordinates all the Web Services involved in the application. This central process can be a Web Service a well. The point to note in this case is that all other Web Services don't really know that they are participating in a higher-level business process. How the participating Web Services will be called, what will be the control flow, what all transformation will take place, ... these all things are known only to the central controller process. The other Web Services simply honor the requests whenever called. The below diagram makes it quite easier to understand the overall process.
Since Orchestration provides a controlled environment hence alternative scenarios can be used in case a fault occurs in the normal flow. For example, suppose we need to call a Web Service which may result into fault and in such a case we may need to either call another Web Service OR to simply use a default value. IN case of Orchestration it's very easy to achieve - maybe by just having a switch activity to transfer the control either to the alternative Web Service OR to compute the required Default Value.
Choreography
Here we don't have any central controller process and hence all the participating Web Services know when to call, whom to interact, when to execute operations, etc. We can visualize choreography just like a collaborative effort of many participating Web Services and since we don't have any controller hence all the Web Services need to know the actual business process and things involved in it like message exchanges, time of call, etc. Find below a diagram depicting a typical Choreography process.
Orchestration vs Choregraphy
Easy to fugure out, right? Orchestration has a central controller process and all other participating Web Services don't know about the actual business process. They are called only by the controller process and they don't know anything about other Web Services involved in the application. Whereas Choreography doesn't have any controller process/service and all the participating Web Services know the actual business process and they are well aware of which all Web Services they need to interact with, when to execute the operations, etc.
So, we can say that Orchestration is a controlled and co-ordinated way of utilizing the services of all the participating Web Services whereas Choreography is just a collaborative effort of utilizing the services of the participating Web Services.
Falut handling is easier in Orchestration as the execution is controlled which is not the case with Choreography. Web Services can be easily and transparently replaced in case of Orchestration as the involved Web Services don't know the actual business process whereas it'll be difficult in case of Choreography.
Thus, we see that Orchestration is having quite a few advantages over Choreography and hence Orchestrtaion is normally preferred for business process implementations, but Choreography may certainly have its own usage in some selected scenarios.
