Integrate Service-Oriented Architectures
Reliable communication over JMS is important, but it's not the only communication protocol in use today. The global reach of the Web and HTTP, along with the data and platform-independent nature of XML, has given rise to a new paradigm for software development: the service-oriented architecture. This includes, more specifically, XML/SOAP-based web services that are becoming increasingly available over the Internet.
The proliferation of the Web and its related technologies, the adoption of broadband networks by both businesses and individuals, and the ever-decreasing cost of computer hardware, has helped to usher in the age of integration. Corporations partner with other corporations to share data and provide complimentary services; we send and receive email through a corporate server from handheld devices; and we stay connected to the systems and data we rely on even as we travel. The age of integration defines the interconnectivity of computers, and whole networks, which enable these solutions.
It has become increasingly useful to integrate available web services into existing applications, and to generate new applications from existing web services. After all, this is what SOA advocates have been promising all along. Organizations have discovered the benefits of using both internal web services (those developed and deployed within the organization) as well as external ones (those built and deployed by other organizations). Google is, perhaps, the most famous of those offering use of its intellectual property (web search, photo archives, mapping, and so on) through web services to be integrated into other organizations' applications.
Google's web services, along with Google's usage of advanced web technologies such as Ajax, have spawned an entire genre of web-based applications called Web 2.0. Part of the movement of Web 2.0 is the concept of mashups, which are web applications that use content from multiple sources (usually web services) to form a new application or service. The excitement of Web 2.0, the development and usage of web services, and the ever-increasing deployment of mashups, all prove that there is a lot to be gained through web service integration.
Though there are standards for web service development, discovery, and usage (such as SOAP, UDDI, and WSDL), there is still a lot of work to be performed in actually integrating the web service APIs and their content into a unified application. Web service orchestration, or the integration of web services and other components through rules-driven processes, is one way to solve this problem. The ESB supports web services through a SOAP adapter, and the use of Business Process Execution Language (BPEL) for orchestration.
Integrate Legacy Applications
Although the number of systems that support a SOAP interface is increasing, there are many more that don't. You're more than likely to come across other applications, ranging from standard Java, enterprise Java, .NET, and even IBM CICS applications, which you will need to integrate into a newer distributed application. For this reason, you may need to use the data transformation functionality provided by the ESB, a built-in adapter, a custom adapter, or a combination.
The ESB Adapter. An adapter is a relatively simple piece of software that wraps a component's interface, or transforms data, to interface with a different system. You can write this software yourself to, in effect, convert the software's interface into a web service or to be JMS-compliant. If the application uses enterprise Java or .NET, the tools used to build the system will more than likely be able to automate this process. This is assuming you have access to the component's source code or development tools. Even if you don't, you will more than likely be able to use the ESB's built-in adapters for these cases (see Figure 8)
IBM CICS now supports adding enterprise Java and web services interfaces to components built upon it. The adapter software will need to be run somewhere, and be interfaced to the ESB in some way. If the application supports a Java interface, the calling Java component can be developed and deployed as an enterprise Java application and integrated with the ESB's built-in JCA adapter, as in Figure 9.
More often than not, data transformation adapters will be the way to go. In fact, this problem is so common that most ESB vendors provide tools to support various data transformations. Even if the ESB you choose does not support all of the transformations you require, the chances are high that you will be able to find other tools, often open-source, that can automate this process. Figure 10 is an example of how the ESB XML adapter can be used to accept transformed XML.
For other cases where a data transformation or a built-in solution is not possible, you may need to build a more complex, custom adapter. The custom code you write may need to interface with older applications such as COBOL (see Figure 11) or to transform older, proprietary, data formats, to XML.
The adapter pattern is straightforward in most cases, and will solve many of your ESB integration problems. There will be cases, however, where more subtle differences between integrated systems require something other than an adapter. For systems that comply with the ESB interface, yet whose messages do not match the standards for the rest of the system, the ESB message transformation capabilities may be used.
