With the rising emphasis on application integration comes a corresponding increase in confusion over what various integration terms really mean. "Adapter" is one such term. The meaning of the word differs depending on the context and the application architecture. In some cases, a simple servlet is called an adapter, while in other instances an entire application could be an adapter (e.g., EDI gateway). Regardless of its size and context, however, an adapter's primary objective is to facilitate integration of the application for which it has been designed.

To understand how and when to use an adapter, a developer must first understand the concept of an integration-ready application.

Integration-Ready Applications

An integration-ready application has two basic requirements:

1. It must isolate and expose its different points of integration. A point of integration could be a specific database table, a specific business function or a stored procedure. In general, the easier the access to points of integration, the better the application's integration capability.

   There are several ways to provide access to application functions and data. Typically, an application-specific API is designed to help developers of other business applications get access to shared application functions and data. However, application-specific APIs are not ideal as access mechanisms, since the API will most likely be different for most applications. (Adapters can incorporate and encapsulate these APIs, providing a more standardized method of integration than the API alone would provide.) In addition, platform-neutral standards such as XML, SOAP (Simple Object Access Protocol) and J2EE (the Java 2 platform, Enterprise Edition) are ideal building blocks for developers to design integration-ready applications.

2. The integration logic must be isolated from the application's business logic, interface and database layers. In a three-tiered application architecture, the user interface, business logic and database layers each encapsulate specific application functionality.

   One reason for this separation is to ensure easy change management of each layer. Changes to the user interface are driven by user requirements, which are generally less stable and require more frequent modification than do business requirements. Similarly, separating integration logic and encapsulating it as a different layer gives developers the flexibility to manage integration requirements without substantially affecting the business application.