SOA: Choreography over Orchestration

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.

53a11eae40e7036ed17960e0705855b8?s=128

Sriram Narayan

July 23, 2011
Tweet

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
  3. 3

  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
  9. 9

  10. 10

  11. 11

  12. 12

  13. local caching to avoid service level joins finding boundary is

    major thing 13
  14. 14

  15. 15

  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
  17. 17

  18. 18