Enterprise Service Oriented Architectures - Concepts, Challenges, Recommendations

3 ORCHESTRATION (p.95-96)

None of us is as smart as all of us. 
Anonymous


Even before the advent of Web services, an increasingly large number of distributed applications were constructed by composing them out of existing applications. Enterprise Application Integration (EAI) techniques grew up from the realization that no one infrastructural technology (e.g., CORBA or DCOM) will ever be adopted by all of the software industry. Furthermore, although sourcing a solution to a problem (large or small) from a single vendor is possible in the short term, in the long term it is often the case that a corporate intranet will be running systems from a variety of vendors, not all of which will be able to interoperate. Large multi-national corporations often evolve through acquisitions of smaller companies who may have different infrastructural investments. We have often heard the statement that "It’s easier to interoperate with a different company than to talk to different divisions within the same company." Therefore it should come as no surprise to learn that large-scale applications are rarely built from scratch; rather they are constructed by composing them out of existing applications.

Providing solutions that enable disparate (heterogeneous) technologies and applications to communicate is extremely important. Without them, a company’s infrastructure would either not be able to grow (leading to islands of isolation) or would be at the mercy of a single vendor. For several years EAI solutions have made it possible to compose an application out of component applications in a uniform manner, irrespective of the languages in which the component applications have been written and the operating systems of the host platforms. Unfortunately, most EAI platforms offer solutions that are not interoperable with one another. Web services offer a potential solution to this important drawback.
The resulting applications can be very complex in structure, containing many temporal and data.ow dependencies between their constituent applications. An additional complication is that the execution of such an application may take a long time to complete and may contain long periods of inactivity (minutes, hours, days, weeks, etc.), often due to the constituent applications requiring user interactions. In a distributed environment, it is inevitable that long running applications will require support for fault-tolerance and dynamic recon.guration: machines may fail, services may be moved or withdrawn and application requirements may change. In such an environment it is essential that the structure of applications can be modi.ed to re.ect these changes. In general, composite applications are increasing in importance as companies combine off-the-shelf and homegrown Web services into new applications. Various mechanisms are being proposed and delivered to market daily to help improve this process. New "fourth generation" language development tools are emerging that are speci.cally designed to stitch together Web services from any source, regardless of the underlying implementation.

A large number of vendors are starting to sell business process management, work.ow and orchestration tools for use in combining Web services into automatic business process execution .ows. In addition, a growing number of businesses .nd themselves creating new applications by combining their own Web services with Web services available from the Internet supplied by the likes of Amazon.com and Google.com. These types of composite applications represent a variety of requirements, from needing a simple way to share persistent data to the ability to manage recovery scenarios that include various types of transactional software. Composite applications therefore represent a signi.cant challenge for Web services standards since they are intended to handle complex, potentially long-running interactions among multiple Web services as well as simple and short-lived interactions.