| The J2EE Connector Architecture, otherwise known as JCA or J2CA, has become a popular means of connecting legacy applications to a Java environment using a standard set of contracts. JCA simplifies integration by providing the container contract between an application server or middleware integration broker to an application adapter, and between the application adapter and an application. A vendor-supplied or third-party application adapter that is JCA-compliant can simply plug into this container. JCA was designed to be implemented in an application server container, but can also be implemented in an ESB container. JCA is to applications what JDBC is to database connectivity. It provides connection management and connection pooling, transaction control, propagation of security context, and a worker thread management and delegation model. A birds-eye view of the JCA architecture, shown in Figure 10-5, reveals the following components: A JCA container, which is intended to house a JCA Resource Adapter (RA). The container manages the contracts for thread pooling, connection pooling, and the propagation of transaction and security context. A Resource Adapter (RA), which is the component that interfaces with the application and implements the application-specific behavior for connection management, security, and transactional resources. This portion of the JCA is allowed to be proprietary on a per-adapter-type basis.
Figure 10-5. An ESB container as a JCA container 
An ESB that supports a JCA container allows applications to be plugged into an ESB using a standard set of off-the-shelf adapters. These adapters can be made available from the application vendors themselves, such as SAP, or from vendors who specialize in providing adapters, such as iWay and DataDirect. 10.2.1 Domain Expertise JCA automates the connectivity task of plugging adapters into middleware infrastructure by providing a standard set of contracts for plugging an application adapter into a managed container environment. This allows deployment and configuration tools to have a uniform approach toward integrating applications. However, it does not preclude the need for expertise on the inner workings of the applications themselves. Consider the JDBC and database analogy. When connecting to a database, JDBC simplifies and standardizes things such as connection pooling, transaction management, and security management. This does not eliminate the need for a database administrator who knows the intimate details of the tables and inner workings of the database. The same is true for JCA adapters. While JCA can automate some of the details of connectivity, application expertise is still required to achieve a successful integration; for example, you still need to know the impact of invoking the interfaces that an application exposes. 10.2.2 ESB to Application Server Connectivity Beyond specialized application adapters, JCA can also be used to generically connect a JMS interface into an application server. JCA allows multiple application servers from different vendors to plug into a common JMS layer. Figure 10-6 shows two ways that an application server can connect into an ESB endpoint using JMS. The application server uses the JMS client API coded directly into an instance of a servlet, portlet, or Stateless Session Bean (SSB). The application server's EJB container may configure a Message-Driven Bean (MDB) to interface with the JMS topic or queue channel directly, without any special coding. Figure 10-6. An application server can interface with messaging using either direct JMS APIs, or through a JCA 1.5 connection 
 | JCA is considered a "slang" acronym for the J2EE Connector Architecture. Chronologically, "Java Cryptography API" came first, and officially owns the acronym of "JCA." However, early adopters of the J2EE Connector Architecture also used the acronym "JCA," and the usage has stuck. This book uses JCA and J2CA interchangeably to refer to the J2EE Connector Architecture. |
|
|
