<<The best way to consider both notions of service and orchestration (and process integration in general) is to think of them as independent layers, where the process layer is the calling application to the services to extract both data and behavior needed to form cohesive orchestrations. This interaction allows the architect and the developer to place certain things into certain domains. The orchestrations that define the way the services are leveraged, and the services that well provide service.
Orchestration is a necessity if you build a SOA, intra- or inter-organization. It's the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration is a godlike control mechanism that's able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, and to define or redefine any business process on-the-fly. For our purposes we can define orchestration as a standards-based mechanism that defines how web services work together, including business logic, sequencing, exception handling, and process decomposition, including service and process reuse. Orchestrations may span a few internal systems, systems between organizations, or both. Moreover, orchestrations are long-running, multi-step transactions, almost always controlled by one business party, and are loosely coupled and asynchronous in nature. Orchestration encapsulates and leverages services, binding them together to form higher level processes and composite services. Indeed, orchestrations themselves should become services, and may be leveraged as services. Here are a few things to consider: A single instance of orchestration typically spans many instances of service- and information-oriented points of integration, perhaps many domains and even organizations. Thus, you typically have one orchestration for many services. Most orchestrations leverage public standards such as BPEL. However, there are a few competing standards, such as process and workflow standards, and technology that can do very much the same job binding services into processes to form solutions. Thus, when considering the process/orchestration solutions, you have many to choose from that provide process-based control, using or not using BPEL. Orchestrations may be public, or available to everyone, private, available to just the owner, and shared, for supply chain integration scenarios. Thus, orchestrations can span businesses, supporting supply chain integration and other B2B activities. Orchestrations are usually driven from a single party; they are not always collaborative in nature. Orchestrations themselves may become services available for other services or orchestrations (as mentioned above). Orchestration defines a meta-application, of sorts, that has visibility into many encapsulated services as well as application information that may be bound to those services. Orchestration is independent of the services they are leveraging. Changes can be made to the orchestration without having to force changes to the services. In other words, this architecture is a loosely coupled, services to orchestrations. Orchestrations may be decomposable down to base processes, and finally services. The hierarchy further provides architectural control to the architect or the developer in support of the business solution they are automating. 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.>> You can read this at: http://weblog.infoworld.com/realworldsoa/archives/2007/11/how_to_consider.html?source=NLC-SOA&cgd=2007-11-20 Gervas
