This chapter is from the book
This chapter is from the book
This chapter is from the book
Rapid Integration
A few years ago, businesses finding themselves in need of comprehensive integration solutions turned to products and practices developed specifically for that purpose. However, these enterprise application integration (EAI) products proved to be expensive, consumed considerable time and effort, and were subject to high project failure rates. Furthermore, because these various special purpose products are proprietary, many of the projects resulted in additional difficulties whenever a company invested in more than one of them.
Recent experience shows that a better answer is available by using Web services standards. Instead of dealing with the complexity of multiple incompatible applications on multiple computers, programming languages, and application packages by introducing an EAI product, it's possible to add a layer of abstraction that's open, standards-based, and easy to integrate with virtually any new and existing environment.
A new generation of integration products from BEA, IBM, IONA, Microsoft, SAP, SeeBeyond, Systinet, Tibco, WebMethods, and others, enabled by Web services technology, is emerging around the concepts of service-oriented integration.
The combination of Web services and SOA provides a rapid integration solution that more quickly and easily aligns IT investments and corporate strategies by focusing on shared data and reusable services rather than proprietary integration products.
To illustrate the benefits of service-oriented integration, consider the example of three fairly typical financial industry database applications, perhaps supporting retail banking, commercial banking, and mutual fund investment operations. The applications were developed using a classic three-tier architecture, separating presentation logic, business logic, and database logic.
As shown in Figure 1-8, it's possible to reuse a traditional three-tier application as a service-oriented application by creating services at the business logic layer and integrating that application with other applications using the service bus. Another benefit of service orientation is that it's easier to separate the presentation logic from the business logic when the business logic layer is service- enabled. It's easier to connect various types of GUIs and mobile devices to the application when the business logic layer is service-enabled than if a separate tightly coupled presentation logic layer has to be written for each. Instead of running the presentation logic tier as a tightly coupled interface on the same server, the presentation logic can be hosted on a separate device, and communication with the application can be performed using the service bus.
)
Figure
1-8 Designing for service-oriented integration.
Applications can more easily exchange data by using a Web service defined at the business logic layer than by using a different integration technology because Web services represent a common standard across all types of software. XML can be used to independently define the data types and structures. And finally, the development of service-oriented entry points at the business logic tier allows a business process management engine to drive an automatic flow of execution across the multiple services.
Creating a common Web services layer or "overlay" of services into the business logic tiers of applications also allows you to use a common service repository in which to store and retrieve service descriptions. If a new application wishes to use an existing service into one of these applications, it can query the repository to obtain the service description and easily generate SOAP messages to interact with it.