SOA: Choreography over Orchestration

The ThoughtWorks tech radar once talked about choosing Choreography over Orchestration. I'll try to explain this using real world examples and touch upon some other points of service orientation along the way.

Transcript

1. 1 Object = data + behaviour service = data + behaviour + autonomy
2. The ThoughtWorks tech radar once talked about choosing Choreography over Orchestration. I'll try to explain this using real world examples and touch upon some other points of service orientation along the way. 2
4. employee joins end of a workflow in the recruitment system first create her record in employee master e.g. peoplesoft also need to create it in corporate directory, email system, time & expense, skills master based on role, office - need to add the new joinee to certain groups different systems may need different parts of employee data 4
5. one approach is to write a EmployeeService or NewEmployeeManager somewhere that has code to create the record in all the downstream systems this is the orchestration approach 5
6. then a new system launches we now to need to change and re-deploy the orchestration 6
7. we are not thinking in terms of events else we would just publish the event on a queue, and the other system would look at the published employee and create a copy for itself with a subset of the info e.g. corporate directory doesn't care if you are a dev or manager but skillsMaster does. email system doesn't care about salary but payroll does. this is how a choreo approach would look like 7
8. so is it just a new name for event driven programming? or pub-sub? in a sense yes, it is sort of a distributed observer but that is not all. we are doing this to achieve decoupling at several levels availalbity clearer boundaries help the cause of autonomy remember: it is possible to get it wrong with events also. what you publish is important an event describes "what happened", not "what should happen" - that is a request/command message,document 8
13. local caching to avoid service level joins finding boundary is major thing 13
16. A service can/should expose a private, commonly in-process interface for admin and reporting UI. Only cross-service business applications need use an out-of-process (even this could be in-process) public interface. 16