The Future of Application Integration and Integration Servers
Integration servers, at least the core engine of integration servers, are destined to become commodity products because many perform only rudimentary functions. In an effort to differentiate their products, many integration server
Given this reality, when all is said and done, integration servers may
Chapter Ten. Adapters and the J2EE Connector Architecture
There is no question about it: If you're going to do application integration, you're going to need adapters. That's the purpose of this chapter—to explain the notion, architecture, and implementation of adapters.
However, adapters don't stop there. There is a new standard on the rise, the J2EE Connector Architecture, which defines a standard architecture and adapter behavior. This standard gives us the ability to create an adapter once, and then use it
Adapters are powerful; they deal with the ugly details of the underlying application, database, and standards-based ( EDI , XML , etc.) interfaces. Believe me, you don't want to have to code through those interfaces on your own. It is always better to buy than to build.
The liberation of information and application services out of back-end systems is the job of adapters. Adapters sit between the source or target applications and the integration server, and account for the differences in the back-end systems by translating
We need adapters for several reasons:
The simple notion of adapters becomes complicated by
The Purpose of Adapters
In the past, when we sought to connect Application A to Application B, or Applications A and B to an integration server, we had to interact with that application using some
Figure 10.1. Before adapters, developers had to code the connections between the application interfaces and the middleware.
An integration server vendor may have adapters for several different source and target applications (such as SAP R/3, Baan, and PeopleSoft), or for certain types of databases (such as Oracle, Sybase, or DB2), or even for specific brands and types of middleware. Over time, adapters have become more sophisticated. They began as a set of libraries that developers had to manipulate and evolved into binary interfaces that require little—if any—programming. Adapters are also getting
Two types of adapters exist in the context of integration servers: thin adapters and thick adapters. These adapters may have two types of behavior: dynamic and static.
Today's most popular integration servers offer thin adapters. In most cases, they are simply API wrappers, or binders, which map the interface of the source or target system to a common interface supported by the integration server (see Figure 10.2). In other words, they simply perform an API-binding trick, binding one API to another.
Figure 10.2. Thin adapters don't provide sophisticated layers of software between the source or target systems and the integration server, and are really just simple abstractions on top of existing APIs.
Thin adapters have the advantage of being simple to implement. With no additional, "thick" layer of software between source and target applications, there is greater granular control. Thin adapters have a number of disadvantages, however. Because using them accomplishes nothing more than trading one interface for another, thin adapters impact performance without increasing functionality. And a fair amount of programming is still required. To complicate matters, the common APIs that are being mapped are almost always proprietary.
Unlike thin adapters, thick adapters provide a significant amount of software and functionality between the integration server infrastructure and the source or target applications. The thick adapter's layer of abstraction makes managing movement or invoking processes painless (see Figure 10.3). Because the abstraction layer and the manager negotiate the differences between all the applications requiring integration, almost no programming is needed.
Figure 10.3. Thick adapters place a sophisticated abstraction layer on top of the application interfaces.
Thick interfaces accomplish this via the layer of sophisticated software that hides the complexities of the source and target application interfaces from the integration server user.The user sees only a businesslike representation of the process and the metadata information as managed by the abstraction layer and the adapter. In many cases, the user connects many systems through this abstraction layer and the graphical user interface, without ever having to resort to hand-coding.
Repositories are major players in the thick-adapter scenario. As we noted, the repository understands much of the information about the source and target applications and can use that information as a mechanism to interact with the source and target applications on
In addition, several abstraction layers may be created around the types of applications to be integrated. For example, there may be an abstraction for common middleware services (such as distributed objects, message-oriented middleware, and transactional middleware). There may also be an abstraction layer for packaged applications, and another layer to address the integration of relational and nonrelational databases. This structure hides from the end user the complexities of the interfaces that each entity (middleware, packaged applications, and databases) employs.
Another feature of a thick adapter is the ability to think and process information on its own, independent of the integration server. Processing performed by thick adapters may include
With the many advantages and
Static and Dynamic Adapters
As noted earlier, in addition to being thick or thin, adapters are also defined by being either static or dynamic.
Static adapters , the most common adapters in play at this time, must be manually coded with the contents of the source and target systems. They have no mechanism for understanding anything about the schema of connected databases. As a result, they must be configured by hand (i.e., coded) to receive information from the source schema. If the connected database schema changes, static adapters have no mechanism to update their configuration with the new schema.
In contrast to static adapters,
"learn" about the source or target systems connected to them through a discovery process that takes place when they are first connected to the application or data source (see Figure 10.4). This discovery process typically means reading the database schema information from the repository (or perhaps the source code) to determine the structure, content, and application semantics of the connected system. More important, dynamic adapters not only learn about the connected system, they also are able to relearn information if something changes within the connected system over time. A dynamic adapter automatically understands when a customer-number attribute
Figure 10.4. When using dynamic adapters, information such as schema becomes visible to the integration server.