Introduction to JCA: An obscure but important Java EE specification

The JCA (Java EE Connector Architecture) specification is one of the most "obscure" in the Java EE Specification collection, joined when the JavaEE1.3 specification was released, and much earlier than the current important members JPA, CDI, etc. From an application development perspective, the development of a very common web application, only a few pages, using a servlet can be done, with the JDBC API to save information to the database, deployment of this application to the Java EE Application Server, you will use the JCA technology. This very simple application uses only a large number of servlet and JCA two specifications in the Java EE specification set of 30. So, why are so few people aware of such important norms, this article explains some of them.

The JCA is intended to be the Java Enterprise Version Connector architecture, and such a jerky term does not describe its functionality well. In simple terms, the role of this specification is to define how to connect Java EE application servers and external information systems, including but not limited to databases, message middleware, distributed caching systems, ERP/CRM-represented enterprise software systems, tuxedo, and other transactional/messaging middleware. We know that the enterprise in Java EE is the meaning of the enterprise, and the design goal of this set of specifications is defined from the beginning to be designed for enterprise application software. In the context of an enterprise domain, many applications can be run, and if a software is developed and deployed in an application server using Java EE Specification Technology, and it needs to interact with other application systems, JCA can play a powerful role.

JCA generated in the most prosperous Java EE 1.3 version of the era, JCA 1.0 version by JSR16, when the entire technology stack has been relatively complete, a demand has emerged: how to JDBC/JMS and other connection management unified? At the same time, Bea's tuxedo products also face the problem of integration with Java EE. The JCA1.0 version defines connection management and how transactions and security are managed on top of the connection, but only the requirements of outbound (outbound) one-way requests are considered.

Then there is the situation of the warlords, more producers of the JCA specifications generated interest, including a large number of EAI integration software vendors and ERP giants such as SAP and so on, the JCA1.5 specification completed in 2003, this version is complete, joined the inbound (inbound) Message flow, Defines the important content such as Workmanager. Until today, many resource adapter also support only 1.5 specifications.

In version 5 o'clock the Java EE Rename is the main focus in JPA and EJB3,JCA without change. The JCA upgrade to the 1.6,JSR number 322 in the JavaEE6 release, with the exception of functional enhancements, is mainly to add support for annotation, from which XML or annotation can be used to describe the related implementation classes for JCA.

Javaee7,jca was released last year with minor modifications, upgraded to 1.7, but still follows the JSR322 specification number. So the JCA specification in the latest support JAVAEE7 application server that we're now looking at is version 1.7. In the latest Wildfly (formerly Jbossas) application Server, configuration information, such as database connection pooling, JMS connections, receiving message MDB information, are configuration options that the Ironjacamar (JBoss Open source organization JCA implementation) can identify and process.

Let's look at the standard JCA architecture diagram.

Four parts are application servers (application server), application components (application Component), resource adapters (Resource Adapter), and Enterprise information systems (Enterprise information System).

Our general development application is to deploy the war in webserver, which corresponds to application components and application servers, respectively. Enterprise Information System can be operated independently of the application system, such as database, ERP, resource adapter is designed to connect with the enterprise information System design of the connection adapter software, Java EE Application Server and external application system can be connected, and provide resource services to the application components to use.

There may be a doubt here that the general application can be connected through JDBC or JMS interfaces, and why the JCA specification interface should be defined. The answer is simply to unify the API for the access layer and be managed by the container. The resource pool container (which can be called the JCA container) in the application server needs to manage all external information system connections, which are uniformly scheduled for application use. For application developers, it's easy to use these resources to get the available resources through Jndi, to be referenced and invoked, to close after use, to recycle the containers and put them back in the pool of available resources for subsequent use. All such resources are identified and managed by the resource container, and the JCA specification defines such an interface. We see in JCA Javadoc that it is clear that the SPI package is the set of interfaces that the resource adapter implements.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/Java/