1. A single instance of orchestration typically spans many instance of service- and information-oriented points of integration, perhaps many integration domains and even organizations.
2. Most orchestrations leverage public standards such as BPEL.
3. Orchestrations may be public, or available to everyone, private, available to just the owner, and shared, for supply chain integration scenarios.
4. Orchestrations are usually driven from a single party, they are not always collaborative in nature.
5. Orchestrations themselves may become services available for other services or orchestrations.
6. Traditional application integration typically means the exchange of information between two or more systems without much visibility into internal processes and services. In contrast, orchestration defines a meta-application, of sorts, that has visibility into many encapsulated application services (web services) as well as application information that may be bound to those services.
7. Orchestration is independent of the source and target systems. Changes can be made to the orchestration without having to force changes the source or target systems. In other words this architecture is loosely coupled.
8. Orchestrations are always decomposable down to base processes within the source or target systems.
9. Traditional application integration is typically a tactical solutions, motivated by the requirement for two or more applications to communicate. Orchestration, in context to a SOA, is strategic, leveraging business rules to determine how systems should interact and better leverage the business value from each system through a common abstract business model.