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 anywhere including most integration and application servers. Clearly this provides the application integration technology consumer with many advantages. 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 requests into something the native source or target application can understand, then they translate the response. We need adapters for several reasons:
The simple notion of adapters becomes complicated by numerous vendor varieties, and even the differences between standards. Truth be told, the approaches to adapters outnumber the source or target systems they are looking to connect. Moreover, the use of standards, which is supposed to simplify things, may add more complexity and confusion in the short term. We'll talk more about that below. |