Programming WebLogic J2EE Connectors

 Previous Next Contents Index View as PDF  

Overview of WebLogic J2EE Connectors

The following sections provide an overview of BEA WebLogic J2EE Connectors:

 


J2EE Connector Architecture Terminology

Key terms and concepts that you will encounter throughout the WebLogic J2EE Connector Architecture documentation include the following:

 


Overview of the BEA WebLogic J2EE Connector Architecture Implementation

BEA WebLogic Server continues to build upon the implementation of the Sun Microsystems J2EE Platform Specification, Version 1.3. The J2EE Connector Architecture adds simplified Enterprise Information System (EIS) integration to the J2EE platform. The goal is to leverage the strengths of the J2EE platform—including component models, transaction and security infrastructures—to address the challenges of EIS integration.

The J2EE Connector Architecture provides a Java solution to the problem of connectivity between the multitude of application servers and EISes. By using the Connector Architecture, it is no longer necessary for EIS vendors to customize their product for each application server. By conforming to the J2EE Connector Architecture, BEA WebLogic Server does not require added custom code in order to extend its support connectivity to a new EIS.

The Connector Architecture enables an EIS vendor to provide a standard resource adapter for its EIS. This resource adapter plugs into WebLogic Server and provides the underlying infrastructure for the integration between an EIS and WebLogic Server.

By supporting the Connector Architecture, BEA WebLogic Server is assured of connectivity to multiple EISes. In turn, EIS vendors must provide only one standard Connector Architecture-compliant resource adapter that has the capability to plug into BEA WebLogic Server.

Note: BEA WebLogic Server 7.0 is completely compliant with J2EE 1.3. Also, since J2EE is backward compatible, you can still run J2EE 1.2 on WebLogic Server 7.0.

 


J2EE Connector Architecture Components

The J2EE Connector Architecture is implemented in an application server such as WebLogic Server and an EIS-specific resource adapter. A resource adapter is a system library specific to an EIS and provides connectivity to the EIS. A resource adapter is analogous to a JDBC driver. The interface between a resource adapter and the EIS is specific to the underlying EIS; it can be a native interface.

The J2EE Connector Architecture has three main components:

The following diagram illustrates the J2EE Connector Architecture:

Figure 1-1 J2EE Connector Architecture


 

A resource adapter serves as the "J2EE connector." The WebLogic J2EE Connector Architecture supports resource adapters developed by Enterprise Information Systems (EISes) vendors and third-party application developers that can be deployed in any application server supporting the Sun Microsystems J2EE Platform Specification, Version 1.3. Resource adapters contain the Java, and if necessary, the native components required to interact with the EIS.

System-level Contracts

The J2EE Connector Architecture specification defines a set of system-level contracts between the J2EE-compliant application server (WebLogic Server) and an EIS-specific resource adapter. WebLogic Server, in compliance with this specification, has implemented a set of defined standard contracts for:

Note: For more information on connection management, refer to Connection Management.

Note: For more information on transaction management, refer to Transaction Management.

Note: For more information on security management, refer to Security.

Common Client Interface (CCI)

The Common Client Interface (CCI) defines a standard client API for application components. The CCI enables application components and Enterprise Application Integration (EAI) frameworks to drive interactions across heterogeneous EISes using a common client API.

The target users of the CCI are enterprise tool vendors and EAI vendors. Application components themselves may also write to the API, but the CCI is a low-level API. The specification recommends that the CCI be the basis for richer functionality provided by the tool vendors, rather than being an application-level programming interface used by most application developers.

Further, the CCI defines a remote function-call interface that focuses on executing functions on an EIS and retrieving the results. The CCI is independent of a specific EIS; for example: data types specific to an EIS. However, the CCI is capable of being driven by EIS-specific metadata from a repository.

The CCI enables WebLogic Server applications to create and manage connections to an EIS, execute an interaction, and manage data records as input, output or return values. The CCI is designed to leverage the JavaBeans architecture and Java Collection framework.

The 1.0 version of the J2EE Connector Architecture recommends that a resource adapter support CCI as its client API, while it requires that the resource adapter implement the system contracts. A resource adapter may choose to have a client API different from CCI, such as the client API based on the Java Database Connectivity (JDBC) API.

Note: For more information relating to the Common Client Interface, refer to Client Considerations.

Packaging and Deployment

The J2EE Connector Architecture provides packaging and deployment interfaces, so that various resources adapters can easily plug into compliant J2EE application servers such as WebLogic Server in a modular manner.

Figure 1-2 Packaging and Deployment


 

A resource adapter provider develops a set of Java interfaces and classes as part of its implementation of a resource adapter. These Java classes implement J2EE Connector Architecture-specified contracts and EIS-specific functionality provided by the resource adapter. The development of a resource adapter can also require use of native libraries specific to the underlying EIS.

The Java interfaces and classes are packaged together (with required native libraries, help files, documentation, and other resources) with a deployment descriptor to create a Resource Adapter Module. A deployment descriptor defines the contract between a resource adapter provider and a deployer for the deployment of a resource adapter.

You can deploy resource adapter module as a shared, stand-alone module or packaged as part of an application. During deployment, you install a resource adapter module on an application server such as WebLogic Server and then configure it into the target operational environment. The configuration of a resource adapter is based on the properties defined in the deployment descriptor as part of the resource adapter module.

Note: For more information on packaging and deployment, refer to Packaging and Deploying Resource Adapters.

 


Enhancements in This Release

The following J2EE Connector Architecture enhancements are new to this release of WebLogic Server.

Additional Classloading Support

WebLogic Server now supports the loading of properties or classes that are specified in ClassPath entry of the resource adapter's Manifest.mf file. The following is a description of how you configure properties and classes that are in and used by a resource adapter.

The resource adapter (RAR) archive file and the application component using it (for example, an EJB JAR) are contained in an Enterprise Application (EAR) archive. The RAR requires resources such as Java properties that are stored in a JAR file, and that JAR file is contained within the EAR file (not in the RAR itself).

You specify a reference to the RAR Java classes by adding a ClassPath= entry in the RAR Manifest.mf file. You can also store the EJB Java classes in the same JAR file that is contained within the EAR. This scenario provides a "support" JAR file that contains Java classes for the components in the EAR that require them.

Secure Password Credential Storage

This release provides a standard method for resource adapter deployers to plug in their specified authorization/authentication mechanism through secure password credential storage. This WebLogic Server storage mechanism has replaced the Security Principal Mapping mechanism provided with the weblogic-ra.xml deployment descriptor within the resource adapter archive.

As a result, the weblogic-ra.xml <security-principal-map> element has been deprecated. The Password Converter Tool provided with the previous release of WebLogic Server has also been deprecated.

This new storage mechanism is used to map initiating principals (such as WebLogic Server username and password combinations) to resource principals (EIS user name and password combinations).

Flexible Connection Leak Detection

In the past release, the connection leak detection mechanism was based upon a timer that started when a connection was created and triggered when the connection exceeded its usage duration. WebLogic Server now provides two mechanisms for preventing this scenario:

The <connection-cleanup-frequency> and <connection-duration-time> elements in the weblogic-ra.xml deployment descriptor have been deprecated.

Security Policy Processing of an ra.xml Specification

BEA WebLogic Server J2EE Connector Architecture provides a set of security permissions for execution of a resource adapter in a managed runtime environment. WebLogic Server also grants a resource adapter explicit permissions to access system resources.

 


Black Box Example

A simple code example for a resource adapter is provided with this release. This code example uses a Black Box resource adapter that mimics JDBC calls. An EJB is used to model the data in the Black Box, and a Java client is used to query the Black Box resource adapter and display the output. The example uses the all-Java PointBase DBMS, which is provided in an evaluation version with WebLogic Server. For more information, refer to the WebLogic J2EE Connector Architecture Example Javadoc provided with the product download.

 

Back to Top Previous Next