Dave Linthicum's Podcast Channel« Programming coming back to Integration - Not Good! | Main | Responses to my 'No Programming for Integration Movement' »
May 24, 2006Thoughts on Orchestration
Orchestration must provide dynamic, flexible, and adaptable mechanisms to meet the changing needs of the domain. This is accomplished through the separation of process logic and the abstract services employed. The loosely coupled nature of orchestration is key, since there are no requirements for all services to be up-and-running at the same time in order for orchestrations to run. This is also essential for long running transactions. Also, as services change over time, there is typically no need to alter the orchestration layer to accommodate the changes. At least, not if they are architected properly.
Orchestration has the following properties:
• A single instance of orchestration typically spans many instances of services and even organizations.
• Most orchestrations leverage public standards such as BPEL.
• Orchestrations may be public--available to everyone, private--available just to the owner, or shared--for supply chain integration scenarios.
• Orchestrations are usually driven from a single party; they are not always collaborative in nature.
• Orchestrations themselves may become services that are available for other services or orchestrations (as mentioned above).
• Orchestration is independent of the source and target systems. Changes can be made to the orchestration without having to force changes to the source or target systems. In other words, this architecture is loosely coupled.
• Orchestrations are always decomposable down to base processes within the source or target systems.
Posted by davel at 09:13 AM in
| 
Digg This | 
Add to del.icio.us
