A resource adapter is defined in the J2EE Connector Architecture specification as a system-level software driver that a Java application uses to connect to an EIS. The resource adapter plugs into an application server and provides connectivity between the EIS, the J2EE application server, and the enterprise application.
The Java Connector Architecture (JCA) specification allows resource adapters that support access to non-J2EE systems to be plugged into any J2EE environment. Resource adapter components implementing the JCA API are called connectors.
The JCA specification describes standard ways to extend J2EE services with connectors to other non-J2EE application systems, such as mainframe systems and ERP systems. The JCA architecture enables an EIS vendor to provide a standard resource adapter for a J2EE application to connect to the EIS. A resource adapter is used by a Java application to connect to an EIS. For example, Web enablement of business applications, such as IBM's Customer Information Control System (CICS), would imply that the J2EE-based presentation layer would connect to a CICS application using a CICS connector. With this approach, protocol details of connecting to a CICS system are transparent to the Web application and are handled by the CICS connector implementation.
JCA defines a standard set of system-level contracts between a J2EE server and a resource adapter. In particular, these standard contracts include a security contract and enable secure access to non-J2EE EISs. The security contract helps to reduce security threats to the information system and protects valuable information resources managed by such a system. Given that most of these EIS systems have facilities to accept some form of authentication data representing an identity connecting to the system, the JCA security contract deals with the authentication aspects of the EIS. Essentially, it is about a J2EE application signing on to an EIS system. This means that the J2EE application accesses a connection to the EIS system by providing authentication information. As discussed in Section 3.9.4 on page 87 and Section 3.10.3 on page 96, two organizational roles are involved in addressing this issue: the Application Component Provider and the Deployer. Specifically, the Application Component Provider can use either of two choices related to EIS sign-on: the declarative approach or the programmatic approach.
The declarative approach allows the Deployer to set up the resource principal and EIS sign-on information. For example, the Deployer sets the user ID and passwordor another set of credentialsnecessary to establish a connection to an EIS instance.
With the programmatic approach, the Application Component Provider can choose to perform sign-on to an EIS from the component code by providing explicit security information. For example, the user ID and passwordor another set of credentialsnecessary to establish a connection to an EIS instance are coded into the application code.
The Application Component Provider uses a deployment descriptor element, such as res-auth for EJB components, to indicate the requirement for one of the two approaches. If the res-auth element is set to Container, the application server sets up and manages EIS sign-on. If the res-auth element is set to Application, the component code performs a programmatic sign-on to the EIS.
Further details of the security aspects of a JCA-based connection to an EIS from a J2EE application are discussed in Section 3.9.4 on page 87 and Section 3.10.3 on page 96.