J2EE:JCA (Java Connector Architecture) [Go]

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 defined in the j2ee1.3 specification as a source adapter that is based on the Java Connector architecture. The JCA connector also provides an important capability to enable the Java EE Application Server to integrate any enterprise Information System (EIS) that uses JCA adapters, greatly simplifying the integration of heterogeneous systems. With JCA, enterprises can deploy enterprise applications to a 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 application host of the application server) to use the connector in a uniform way. In this way, the connector is portable for cross-application servers, and the client program becomes a very lightweight connector.

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

　　 JCA and EIS integrated application

In the era of e-commerce, business applications with Internet capabilities and integration of business processing on the Internet have become the basis for major vendors to gain a competitive advantage. Before the Internet economy, however, many companies have invested heavily in business and management information application systems, such as:

ERP (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.

An old-fashioned database system, such as IBM's IMS.

These systems are commonly 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 transactional program in a transactional application.

Before the connector appeared, some application server vendors provided a variety of customizable adapters for the integrated EIS system. These adapters also provide a custom native interface. But these are complex, difficult to understand, and are constrained by their attempts to support a standard architecture. Some of these specific constraints are as follows:

EIS application programming itself is proprietary, and the diversity of application systems indicates that there is no common interface mechanism for integration with open architectures.

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 are expensive to connect to in an EIS, and custom adapters lack the connection management mechanisms provided by application servers.

Managing security and distributed transactions for many back-end applications is extremely complex and lacks a reliable mechanism. This means there is no standard infrastructure solution available to provide a more neutral security mechanism, and there is no common transaction management support for many EIS resource managers. This situation poses a huge problem for EAI implementations.

With these difficulties in mind, SU publishes JCA to provide a standard architecture for the integration of the Java EE server with heterogeneous EIS resources. The main goal is to simplify the development process by defining a common API and a common set of services in a consistent Java EE environment. JCA provides developers with an easy way to seamlessly integrate EIS with the Java EE System platform components. Figure 1 shows a structure diagram of a component with JCA and an EIS integration application.

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



Sun's idea was that all application server vendors would eventually implement JCA services, and EIS vendors would implement EIS resource adapters that complied with the JCA specification. By supporting JCA, all application servers that adhere to the Java EE are guaranteed to handle numerous and heterogeneous EIS resources. As a result, JCA improves the productivity of the Java EE application developer while providing a scalable integration solution through the Java EE, reducing development costs and protecting existing investments in the EIS system.

　　 The 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 JCA-compliant resource adapter provided by the EIS vendor. This resource adapter is an EIS-specific pluggable Java EE component in an application server that provides an interface for communicating with a primary EIS system. JCA defines the following elements and services:

System-level contracts (contract) and services define a standard interface between the Java EE component, the application server provider, and the EIS system. These contracts and services are implemented by the Java EE Server Provider and are also located in the EIS vendor's resource adapter. The implementation of these contracts and services defines a logical division (not a physical division) between the application server and the resource adapter's system-level roles and responsibilities. This enables the Java EE 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 Universal Client Interface (CCI), which defines a client API that a Java EE component, such as JSP, EJB, can use to connect to or interact with an EIS system. In addition to the Java EE Customer component, it allows unmanaged applications such as Java applets and application customers to integrate with an EIS using a resource adapter that adheres to JCA.

Package and implement interfaces that 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 resources. The resource adapter is clearly seen as the base component of JCA because it serves as a central connector for the Java EE component, Application Server, and 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 is part of the implementation. The Java server vendor provides application servers that support JCA system-level contracts, allowing these resource adapters to be plugged into the application server and providing connectivity to the primary EIS resources. This enables the Java EE application developer to develop integration components using CCI.

The JCA technical specification supports two types of environments, based on the types of client applications that use resource adapters, such as:

The managed environment defines a multi-tiered, web-capable, EE-based application that accesses the EIS. This application can contain one or more application components (such as EJBS, JSP pages, Servlets) that are implemented in their own containers. In the context of JCA, these applications are referred to as managed applications.

The rogue Environment Connector architecture supports access to the EIS in such a way that applets or Java client applications. Typically this is a two-tier architecture in which one application customer directly uses a resource adapter library. Resource adapters provide low-level transactional and security processing for customers. In a JCA context, these applications are called non-managed applications.

　　 resource adapters and their contracts

The resource adapter contains an EIS-specific library (which can be written in Java or with native interface components) 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 primary EIS.

JCA requires that all the JCA-compliant EIS resource adapters and the Java EE Application Server support system-level contracts. JCA also recommends (but does not stipulate) that all resource adapters support CCI just as they do for their client APIs. This provides a Java EE-based solution for application development, integration of multiple EIS, and enables the EIS resource adapter to "have the ability to insert", which can be used in application servers and collaborate with all system-level mechanisms.

In general, a contract in context is a simple statement of responsibility between layers of an application that implements a standard interface between these layers. Resource adapters generally implement two types of contracts according to the JCA technical specification. These two types of contracts are:

Application contract

The application contract defines the CCI API, which can be used to communicate with the primary EIS resource through this api,-Java EE client component, such as an EJB or servlet.

System-level contracts

A system-level contract defines a set of system contracts that allow a resource adapter to be linked to an application server. The JCA Technical specification defines many system-level contracts for the implementation of resource adapters and the Java EE Application Server.

Connection Management

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

Transaction management

This contract extends the transaction processing power of the application server to the base-level EIS resource manager. In the context of JCA, an EIS resource manager manages a shared set of EIS resources to participate in transaction processing. One resource manager can manage XA transactions and local transaction class two transactions.

Security management

This service allows developers to define security between application servers and EIS resources. There are several mechanisms for protecting an 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 EE Server and the EIS resource adapter, actually extends the connection management along the security side. This security contract provides an EIS issuance (sign-on) mechanism such as the following:

Pass 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 security secret credential information from the application server to the resource adapter.

　　 Universal Client Interface (CCI)

CCI provides an easy way to solve the problem of writing a more complex Java interface for basic-level EIS resources. After the CCI, the problem has become an "integration problem" that both Java developers and EIS vendors know. By implementing the Cci,eis vendor in the resource adapter, a Java interface for their EIS product will be available to run on any application server that complies with the Java EE 1.3 specification.

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

CCI provides a feature call for the Java EE Application Server, which generates and manages a connection to an EIS resource and performs operations related to an EIS resource through the components provided by a JCA resource adapter.

The JCA technical specification suggests that CCI should be more functional and become a richer programming model provided by EIS resource adapter vendors, rather than becoming an API for most application developers. The JCA technical specification also recommends that all EIS resource adapters implement CCI as their customer API, while still requiring these resource adapters to provide system contracts related to the Java EE Application Server. It is important to note that a resource adapter can also choose an additional client API that differs from CCI, similar to the vendor-provided customer API that can be used in a JDBC implementation. Using CCI greatly improves developer productivity, reduces system integration costs, makes code portable, applications can be extended, and good maintainability.

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

Table 1 CCI Interfaces and classes

<ccid_nobr> /table>

interface type	name
A connection-related interface that describes a factory class connection and an application class connection.	javax.resource.cci.ConnectionFactory javax.resource.cci.Connection javax.resource.cci.ConnectionSpec Javax.resource.cci.LocalTransaction
interacts with interfaces that enable a component to drive an interaction with an EIS instance.	javax.resource.cci.Interaction javax.resource.cci.InteractionSpec
interfaces related to data performance, using the To describe the data structures involved in interacting with EIS instances.	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 the basic meta-information for a resource adapter to connect to an EIS.	javax.resource.cci.ConnectionMetaData javax.resource.cci.ResourceAdapterMetaData

　　Packaging and implementation of resource adapters

JCA defines the packaging and implementation interfaces, so various resource adapters can easily be plugged into 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.

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. The package and implementation process for a resource module is 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 specialized functionality provided by the JCA contract and resource adapters.

The native library provided by the Java class and the resource adapter provider (if available) is packaged with an implementation descriptor that forms a resource adapter module (RAR file) similar to other Java EE component implementation descriptors. The implementation descriptor of the resource adapter module defines the service contract properties between the resource adapter provider and the implementers who are responsible for the resource adapter.

During implementation, the application implementers install a resource adapter module on an application server, then configure it with the Java EE Application Server and determine the primary EIS environment target.

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

J2EE:JCA (Java Connector Architecture) [Go]