How to implement Enterprise applications using JCA (Java EE Connector architecture)

The JCA (EE Connector architecture, Java Connector architecture) is an important complement to the EE standard set. Because it focuses on the development of connecting Java programs to non-Java programs and package middleware. A connector is a particular source adapter based on the Java Connector schema, which is defined in the j2ee1.3 specification. The JCA connector also provides an important capability to enable the Java EE Application Server to integrate any enterprise Information System (EIS) that uses the JCA adapter, greatly simplifying the integration of heterogeneous systems. With JCA, the enterprise can deploy enterprise applications to the Java EE Server by purchasing an adapter based on the JCA specification so that integration with the Java EE Application Server can be achieved without writing any code. JCA also provides a standard Java solution for application server and EIS connectivity.

JCA defines a standard set of interfaces that allow connectors to seamlessly integrate compatible application servers. At the same time, another set of standard interfaces defined allows the client (or the application host of the application server) to use the connector in a uniform way. In this way, connectors are portable for cross application servers, and client programs become very lightweight connectors.

The goal of JCA is enterprise application integration, which provides a standardized architecture for the Java EE component to "Plug and Play" Access to heterogeneous EIS, including ERP, transaction processing, legacy database systems, and so on.

　　JCA and EIS integration applications
In the age of electronic commerce, business applications with Internet capabilities and integrated business processes on the Internet have become the basis of competitive advantage for major vendors. Before the Internet economy, however, many companies have invested heavily in business and management information applications, such as:

Enterprise Resource Planning (Enterprise Resource Planning,erp) applications such as SAP R/3 and Baan.
Client Relationship Management (Customer relationship MANAGEMENT,CRM) applications such as Siebel and clarify.

database applications, such as DB2 and Sybase.

Large transaction processing applications, such as CICS.
Legacy database systems, such as IBM's IMS.

These systems are generally referred to as Enterprise information systems (EIS, Enterprise information Systems). EIS provides information infrastructure and services for the entire enterprise. This information may be in the form of a set of records in a database, a business object in an ERP, a workflow object for a CRM system, or a transaction program in a transaction processing application.

Prior to the advent of connectors, some application server vendors provided a variety of customizable adapters for integrated EIS systems. These adapters also provide a custom native interface. But these are complex, difficult to understand, and are limited because they are trying to support a standard architecture. Some of these specific limitations are as follows:

The application programming of the EIS itself is proprietary, and the diversity of application systems indicates that there is no universal interface mechanism for integration with open architecture.
Large Web applications require high availability and scalability in terms of customer, connection management, and so on. Traditionally, the number of customers and their activities connected to an EIS is expensive and the custom adapter lacks the connection management mechanism provided by the application server.
Managing security and distributed transactions for many back-end applications is extremely complex and lacks reliable mechanisms. This means that there is now no standard infrastructure solution to provide a more neutral security mechanism and no common transaction management support for numerous EIS resource managers. This situation poses a huge problem for EAI implementations.

In view of the above difficulties, Su has released JCA to provide a standard architecture for the integration of Java server and heterogeneous EIS resources. Its main goal is to simplify the development process by defining a common API and a common set of services in a consistent Java environment. JCA provides developers with an easy way to seamlessly integrate the EIS with the Java EE System platform components. Figure 1 shows a structure diagram of the components and EIS integration applications with JCA.

As you can see from Figure 1, if you need to integrate a Java-based application with an existing EIS, all you have to do is install the appropriate EIS connector (a resource adapter that adheres to the JCA specification, or Resource-adapter) to the application server. Once this adapter is installed, we can develop the Java EE component to use the CCI (Common client Interface, generic client interface) API with the EIS interface. The approach is the same as using JDBC with the relational database interface. That is, it simplifies development by using non-EIS specialized programming, and the configuration is completely independent of the backend EIS.



Sun's idea is that all application server vendors will eventually implement the JCA service, and EIS vendors would implement EIS resource adapters that comply with the JCA specification. By supporting JCA, all application servers that adhere to Java EE are guaranteed to handle numerous and heterogeneous EIS resources. As a result, JCA enhances the productivity of Java EE application developers while providing an extensible integration solution through Java EE, reducing development costs and protecting existing investments in EIS systems.

　　 Java EE Connector Architecture and its elements
JCA is implemented on an application server that adheres to the Java EE 1.3 specification and has a resource adapter that is compliant with JCA provided by the EIS vendor. This resource adapter is an EIS-specific pluggable Java component in the application server that provides an interface for communicating with the base-level EIS system. JCA defines the following elements and services:

System-level contracts (Contract) and services define standard interfaces between the Java EE component, the application server provider, and the EIS system. These contracts and services are implemented by the Java server Provider and are also located in the EIS vendor's resource adapters. The implementation of these contracts and services defines a logical division (not a physical partition) between the application server and the system-level roles and responsibilities of the resource adapters. This enables the Java server and resource adapters to collaborate with each other. Not only that, it also enables a resource adapter that adheres to the JCA specification to be plugged into any Java EE server.
JCA Common Client Interface (CCI), which defines the Java EE component (such as JSP, EJB) that can be used to connect to an EIS system or interact with a client API. In addition to the Java client component, it allows unmanaged applications, such as Java applets and application customers, to integrate with an EIS using a resource adapter that adheres to the JCA.
Package and implement interfaces to allow various EIS resource adapters to be inserted into the Java EE application.

Figure 2 shows the Java EE Connector Architecture and the components that access the EIS resource. The resource adapter is clearly considered the underlying component of JCA because it serves as the central connector for the Java EE component, the application server, and the EIS system.



In the framework of a Java EE application using JCA, the EIS vendor provides a resource adapter that adheres to JCA and CCI as part of the implementation. Java EE server vendors provide application servers that support JCA system-level contracts so that these resource adapters can be plugged into the application server and provide connectivity to the grassroots EIS resources. This enables Java EE application developers to develop integration components using CCI.

The JCA technical specification supports two types of environments, based on the client application type using the resource adapter, which is:

The managed environment defines an application that is multilayered, web capable, based on Java EE, and accesses an EIS. This application can contain one or more application components (such as EJB, JSP Web page, servlet), all of which are implemented in their respective containers. In the context of JCA, these applications are referred to as managed applications.
Non-Managed Environment Connector architectures enable access to EIS in such a way as applets or Java client applications. Typically this is a two-tier architecture where one application client directly uses a resource adapter library. The resource adapter provides customers with low-level transaction and security processing. In a JCA context, these applications are referred to as not managed applications.

　　 resource adapters and their contracts
The resource adapter contains a library-specific repository (which can be written in Java or with a native interface component) and provides connectivity to the EIS. In the Java EE Application Server, the resource adapter runs in the address space of the application server and manages the connection to the grassroots EIS.

JCA requires all compliant EIS resource adapters and Java EE application servers to support system-level contracts. JCA also recommends (but does not stipulate) that all resource adapters support CCI as they do with their client APIs. This provides a Java-based solution for application development and integration of multiple EIS, and enables EIS resource adapters to be "pluggable", available to application servers, and collaborate with all system-level mechanisms.

In general, a contract in a context environment is a simple statement of responsibility between layers of the application that implements a standard interface between these layers. According to the JCA technical specification, the resource adapter generally implements two types of contracts. The two types of contracts are:

Application Contracts
The application contract defines the CCI API, which communicates with the grassroots EIS resources through this api,-Java client component, such as an EJB or servlet.

System-level contracts
System-level contracts define a set of system contracts that allow resource adapters to be linked to the application server. The JCA specification defines many system-level contracts for the implementation of resource adapters and Java EE application servers.

Connection Management

Connection management is represented by the service contract, which enables an application server to provide its own services to generate and manage a connection buffer pool that is connected to a grassroots EIS resource. This provides an extensible connection management facility to support a large number of customers.

Transaction management

This contract extends the transaction processing capabilities of the application server to the grassroots EIS resource manager. In the JCA context, an EIS resource manager manages a shared set of EIS resources to participate in transaction processing. A resource manager can manage XA and local transaction two classes of transactions.

Security management

This service allows developers to define security between the application server and the EIS resource. There are several mechanisms to protect your EIS from unauthorized access and other security threats, including:

1. Use identifiers, authentication, and authorization mechanisms;
2. Secure communication between application servers and EIS resources, using an open network communication security protocol such as Kerberos, which provides end-to-end security for authentication and confidential services;
3. Enabling the EIS-specific security mechanism, the security contract between the Java server and the EIS resource adapter, actually extends the connection management along the security side. This security contract provides an EIS issuing (sign-on) mechanism as follows:

Transfer the connection request from the resource adapter to the Java EE Application Server and open the authentication and authorization service for the server;
In a security context, pass the secure confidential credential information from the application server to the resource adapter.

　　 Generic Customer Interface (CCI)
CCI provides a simple way to solve the problem of writing a more complex Java interface for the base-level EIS resource. After the CCI, the problem has become an "integration problem" known to both Java developers and EIS vendors. By implementing Cci,eis in a resource adapter, vendors can provide a Java interface to their EIS products that will run on any application server that complies with the Java EE 1.3 specification.

CCI defines an EIS-independent client API for the Java EE Application component that defines a remote function invocation interface for running EIS-related queries and EIS transactions, and can be used to obtain results.

CCI provides functional invocation for the Java EE Application Server, which generates and manages a connection to an EIS resource through a component provided by a JCA resource adapter to perform operations related to an EIS resource.

The JCA Technical specification recommends that the CCI should form richer functionality and become a richer programming model provided by EIS resource adapter vendors rather than being used by most application developers. The JCA technical specification also recommends that all EIS resource adapters should implement CCI as their client APIs, while still requiring these resource adapters to provide system contracts related to the Java application Server. It should be noted that a resource adapter can also choose a different add-on client API than CCI, similar to the vendor-supplied client APIs that can be used in JDBC implementations. Using CCI greatly improves developer productivity, reduces system integration costs, makes code portable, applications scalable, and good maintainability.

The CCI is divided into four parts (see table 1). All the specific CCI classes and interfaces can be easily found in Javax.resource.cci packages.

Table 1 CCI Interfaces and classes

Interface type	Name
Connection-related interfaces, describing a factory class Connection is connected to an application class.	Javax.resource.cci.ConnectionFactory javax.resource.cci.Connection Javax.resource.cci.ConnectionSpec javax.resource.cci.LocalTransaction
Interface-related interfaces that enable components Drives an interaction with an EIS instance.	javax.resource.cci.Interaction javax.resource.cci.InteractionSpec
Interfaces related to data performance to describe the data structures involved in interacting with an EIS instance.	Javax.resource.cci.RecordFactory Javax.resource.cci.Record Javax.resource.cci.MappedRecord Javax.resource.cci.IndexedRecord Javax.resource.cci.IndexedRecord Javax.resource.cci.ResultSet Java.sql.ResultSetMetaData
is a metadata-related interface that provides basic meta information for a resource adapter to connect to an EIS.	Javax.resource.cci.ConnectionMetaData javax.resource.cci.ResourceAdapterMetaData

The

package and implementation of resource adapters
JCA defines a packaging and implementation interface, so the various resource adapters can easily insert an application server that adheres to the Java EE specification in a modular and portable manner. This module, called the resource adapter module, is similar to the Java EE Application module and can include Web and EJB components. The

Figure 3 shows a package and implementation process for a resource adapter module that will be used to connect a Java EE application and an EIS resource. Typically this process is similar to implementing an EJB or Web component in a Java EE container. A resource module is packaged and implemented as follows: The

 

EIS resource adapter provider (usually the EIS vendor) develops a set of Java interfaces and utility classes as part of the resource adapter implementation. These Java classes implement the EIS-specific functionality provided by the JCA contract and resource adapters.
The native library provided by the Java class and resource adapter provider, if available, is packaged, along with an implementation descriptor that forms a resource adapter module (RAR file), similar to other Java component implementation descriptors, The implementation descriptor for the resource adapter module defines the service contract attributes between the resource adapter provider and the performer responsible for the resource adapter.
during implementation, the application performer installs a resource adapter module on an application server, configures it with the Java application Server, and identifies the base-level EIS environmental objectives.

An application's resource adapter module packaging and implementation process is similar to other Java EE packaging and implementation processes, especially with web and EJB components. However, the roles and responsibilities involved in packaging and implementing resource adapters are slightly different from the corresponding processes in other Java EE components. An EIS resource adapter packaged by a resource adapter is an EE server component that is contained in a RAR profile. It can prepare one or more resource adapters in one directory and package them into a. rar file.