Conventi nal wisdom of the 'software stack' approach to building applications may no longer be relevant. Enterprises are pursuing new ways of organizing systems and processes to become service oriented and event-driven. Leveraging existing infrastructural investments is a critical aspect to the success of companies both large and small. Enterprises have to adapt their systems to support frequent technological changes, mergers and acquisitions. Furthermore, in a growing global market, these systems are being called upon to be used by external business partners. Technology is often difficult, costly and complex and without modern approaches can prevent the enterprise from becoming agile.

Enterprise Service Oriented Architectures helps readers solve this challenge in making different applications communicate in a loosely coupled manner. This classic handbook leverages the experiences of thought leaders functioning in multiple industry verticals and provides a wealth of knowledge for creating the agile enterprise.

In this book, you will learn:

• How to balance the delivery of immediate business value while creating long-term strategic capability

• Fundamental principles of a service-oriented architecture (find, bind and execute)

• The four aspects of SOA (Production, Consumption, Management and Provisioning)

• How to recognize critical success factors to implementing enterprise SOAs

• Architectural importance of service registries, interfaces and contracts

• Why improper service decomposition can hurt you later rather than sooner

• How application design and integration practices change as architects seek to implement the 'agile' enterprise

About the Authors

James McGovern is an enterprise architect for The Hartford. He is an industry thought leader and co-author of the bestselling book:A Practical Guide to Enterprise Architecture.

As ish Jain is a Principal Architect with Ping Identity Corporation, a leading provider of solutions for identity federation. Prior to joining Ping Identity, he worked with BEA Systems where his role was to assist BEA customers in designing and implementing their e-business strategies using solutions based on J2EE. He holds several industry certifications from SUN and BEA and is also a board member for the Denver BEA User group.

Mark Little is Director of Standards and SOA Manager for JBoss Inc. Prior to this, he was Chief Architect for Arjuna Technologies Ltd and a Distinguished Engineer at Hewlett-Packard. As well as being an active member of the OMG, JCP, OASIS and W3C, he is an author on many SOA and Web Services standards. He also led the development of the world's first standards-compliant Web Services Transaction product.

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.