Relational resource adapters and JCA
A resource adapter is a system-level software driver that a Java application uses to connect to an enterprise information system (EIS). A resource adapter plugs into an application server and provides connectivity between the EIS, the application server, and the enterprise application.
WebSphere Application Server supports JCA versions 1.0 and 1.5 including additional, configurable features for JCA 1.5 resource adapters with activation specifications that handle inbound requests.
Data access for container-managed persistence (CMP) beans is indirectly managed by the WebSphere Persistence Manager. The JCA specification supports persistence manager delegation of the data access to the JCA resource adapter without knowing the specific backend store. For the relational database access, the persistence manager uses the relational resource adapter to access the data from the database.
Note: The terms J2C and JCA both refer to J2EE Connector Architecture and they are used interchangeably.
Java EE Connector Architecture and WebSphere relational resource adapters
An application server vendor extends its system once to support the Java Platform, Enteprise Edition Connector Architecture (JCA) and is then assured of seamless connectivity to multiple EISs. Likewise, an EIS vendor provides one standard resource adapter with the capability to plug into any application server that supports the connector architecture.
The product supports any resource adapter that implements version 1.0 or 1.5 of this specification. IBM includes WebSphere MQ and the Service Integration Bus with the Application Server, and IBM supplies resource adapters for many enterprise systems separately from the WebSphere Application Server package, which include but are not limited to, the Customer Information Control System (CICS), Host On-Demand (HOD), Information Management System (IMS), and Systems, Applications, and Products (SAP) R/3 .
The general approach to writing an application that uses a JCA resource adapter is to develop EJB session beans or services with tools such as Rational Application
Developer. The session bean uses the
javax.resource.cci interfaces to communicate with an enterprise information system through the resource adapter.
WebSphere Relational Resource Adapter
WebSphere Application Server provides the WebSphere Relational Resource Adapter implementation. This resource adapter provides data access through JDBC calls to access the database dynamically. The connection management is based on the JCA connection management architecture and provides connection pooling, transaction, and security support. The WebSphere RRA is installed and runs as part of WebSphere Application Server, and needs no further administration.
The RRA supports both the configuration and use of JDBC data sources and Java EE Connection Architecture (JCA) connection factories. The RRA supports the configuration and use of data sources implemented as either JDBC data sources or Java EE Connector Architecture connection factories. Data sources can be used directly by applications, or they can be configured for use by container-managed persistence (CMP) entity beans.
Configuring Java EE Connector connection factories in the administrative console
To access an enterprise information system (EIS), configure connection factories, which instantiate resource adapter classes for establishing and maintaining resource connections.
An application component uses a connection factory to access a connection instance, which the component then uses to connect to the underlying enterprise information system (EIS). Examples of connections include database connections, Java Message Service connections, and SAP R/3 connections.
Click "Resources > Resource Adapters > Resource adapters".
In the "Resource adapters" panel, select the resource adapter that you want to configure.
From the "Additional Properties" heading, click "J2C connection factories".
Specify any properties for the connection factory in the "General Properties" panel.
Select the authentication preference.
Select the aliases for "Component-managed authentication", "Container-managed authentication", or both. Some choices for the mapping-configuration alias do not use a container-managed authentication alias, so you will not be able to select a container-managed alias if one of those mapping-configuration aliases is selected.
If you have defined security domains in the application server, you can click "Browse..." to select an authentication alias for the resource that you are configuring. Security domains allow you to isolate authentication aliases between servers. The tree view is useful in determining the security domain to which an alias belongs, and the tree view can help you determine the servers that will be able to access each authentication alias. The tree view is tailored for each resource, so domains and aliases are hidden when you cannot use them.
Click the name of the J2C connection factory that you created.
From the "Additional Properties" heading, click "Connection pool properties".
Change any values by clicking the property name.
Click "Custom properties" from the "Additional Properties" heading.
Click any property name to change its value. If the "UserName" and "Password" properties are defined, they will be overridden by the component-managed authentication alias that you specified in the previous step.
Restart the application server for the changes to take effect.
JMS and the default messaging provider
Java Enterprise Edition (Java EE) applications (producers and consumers) access the SIBus and the bus members through the JMS API. JMS destinations are associated with SIBus destinations. A SIBus destination implements a JMS destination function. Session Enterprise JavaBeans (EJBs) use a JMS connection factory to connect to the JMS provider. Message Driven Beans (MDBs) use a JMS activation specification to connect to the JMS provider.
Configuring an activation specification for the default messaging provider
Configure a JMS activation specification to enable a message-driven bean to communicate with the default messaging provider.
You create a JMS activation specification if you want to use a message-driven bean to communicate with the default messaging provider through Java EE Connector Architecture (JCA) 1.5. JCA provides Java connectivity between application servers such as WebSphere Application Server, and enterprise information systems. It provides a standardized way of integrating JMS providers with Java EE application servers, and provides a framework for exchanging data with enterprise systems, where data is transferred in the form of messages.
One or more message-driven beans can share a single JMS activation specification.
Because a JMS activation specification is a group of messaging configuration properties not a component, it cannot be manually started and stopped. For this reason, to prevent a message-driven bean from processing messages you must complete the following tasks:
Stop the application that contains the message-driven bean.
Stop the messaging engine.
All the activation specification configuration properties apart from "Name", "JNDI name", "Destination JNDI name", and "Authentication alias" are overridden by appropriately named activation-configuration properties in the deployment descriptor of an associated EJB 2.1 or later message-driven bean. For an EJB 2.0 message-driven bean, the "Destination type", "Subscription durability", "Acknowledge mode" and "Message selector" properties are overridden by the corresponding elements in the deployment descriptor. For either type of bean the "Destination JNDI name" property can be overridden by a value specified in the message-driven bean bindings.
Start the administrative console.
Display the default messaging provider. In the navigation pane, expand "Resources > JMS > JMS providers".
Select the default provider for which you want to configure an activation specification.
Optional: Change the "Scope" check box to the scope level at which the activation specification is to be visible to applications, according to your needs.
In the content pane, under the "Additional properties" heading, click "Activation specifications". This lists any existing JMS activation specifications for the default messaging provider in the content pane.
Display the properties of the JMS activation specification. If you want to display an existing activation specification, click one of the names listed.
Alternatively, if you want to create a new activation specification, click New, then specify the following required properties:
"Name" - Type the name by which the activation specification is known for administrative purposes.
"JNDI name" - Type the JNDI name that is used to bind the activation specification into the JNDI namespace.
"Destination type" - Whether the message-driven bean uses a queue or topic destination.
"Destination JNDI name" - Type the JNDI name that the message-driven bean uses to look up the JMS destination in the JNDI namespace.
Select the type of destination on the "Destination type" property.
"Bus name" - The name of the bus to connect to.
Specify the name of the service integration bus to which connections are made. This must be the name of the bus on which the bus destination identified by the Destination JNDI name property is defined.
You can either select an existing bus or type the name of another bus. If you type the name of a bus that does not exist, you must create and configure that bus before the activation specification can be used.
Specify properties for the JMS activation specification, according to your needs.
Optional: Specify the JMS activation specification connection properties that influence how the default messaging provider chooses the messaging engine to which your message-driven bean application connects. By default, the environment automatically connects applications to an available messaging engine on the bus. However you can specify extra configuration details to influence the connection process; for example to identify special bootstrap servers, or to limit connection to a subgroup of available messaging engines, or to improve availability or performance, or to ensure sequential processing of messages received.
Save your changes to the master configuration.
Installed applications use a data source to obtain connections to a relational database. A data source is analogous to the Java Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) connection factory, which provides connectivity to other types of enterprise information systems (EIS).
A data source is associated with a JDBC provider, which supplies the driver implementation classes that are required for JDBC connectivity with your specific vendor database. Application components transact directly with the data source to obtain connection instances to your database. The connection pool that corresponds to each data source provides connection management.
You can create multiple data sources with different settings, and associate them with the same JDBC provider. For example, you might use multiple data sources to access different databases within the same vendor database application. WebSphere Application Server requires JDBC providers to implement one or both of the following data source interfaces, which are defined by Sun Microsystems. These interfaces enable the application to run in a single-phase or two-phase transaction protocol.
ConnectionPoolDataSource - a data source that supports application participation in local and global transactions,
excepting two-phase commit transactions. When a connection pool data source is involved in a global transaction, transaction
recovery is not provided by the transaction manager. The application is responsible for providing the backup recovery process if
multiple resource managers are involved.
XADataSource - a data source that supports application participation in any single-phase or two-phase transaction
environment. When this data source is involved in a global transaction, the product transaction manager provides transaction
Installed applications use Java Database Connectivity (JDBC) providers to interact with relational databases.
The JDBC provider object supplies the specific JDBC driver implementation class for access to a specific vendor database. To create a pool of connections to that database, you associate a data source with the JDBC provider. Together, the JDBC provider and the data source objects are functionally equivalent to the Java Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) connection factory, which provides connectivity with a non-relational database.
Planning for resource scope use
Resource scope is a powerful concept to prevent duplication of resources across lower-level scopes. For example, if a data source can be used by multiple servers in a node, it makes sense to define that data source once at the node level, rather than create the data source multiple times, possibly introducing errors along the way. Also, if the data source definition needs to change (maybe due to changes to an underlying database), the data source definition can be changed once and is visible to all servers within the node. The savings in time and cost should be self-evident.
Some thought needs to be put toward outlining what resources you will need for all the applications to be deployed and at what scope to define each. You select the scope of a resource when you create it.
The following list describes the scope levels, listed in order of granularity with the most general scope first:
The cell scope is the most general scope and does not override any other scope. We recommend that cell scope resource definitions should be further granularized at a more specific scope level. When you define a resource at a more specific scope, you provide greater isolation for the resource. When you define a resource at a more general scope, you provide less isolation. Greater exposure to cross-application conflicts occur for a resource that you define at a more general scope.
The cell scope value limits the visibility of all servers to the named cell. The resource factories within the cell scope are defined for all servers within this cell and are overridden by any resource factories that are defined within application, server, cluster, and node scopes that are in this cell and have the same Java Naming and Directory Interface (JNDI) name. The resource providers that are required by the resource factories must be installed on every node within the cell before applications can bind or use them.
The cluster scope value limits the visibility to all the servers on the named cluster. The resource factories that are defined within the cluster scope are available for all the members of this cluster to use and override any resource factories that have the same JNDI name that is defined within the cell scope. The resource factories that are defined within the cell scope are available for this cluster to use, in addition to the resource factories that are defined within this cluster scope.
Node scope (default)
The node scope value limits the visibility to all the servers on the named node. This is the default scope for most resource types. The resource factories that are defined within the node scope are available for servers on this node to use and override any resource factories that have the same JNDI name defined within the cell scope. The resource factories that are defined within the cell scope are available for servers on this node to use, in addition to the resource factories that are defined within this node scope.
The server scope value limits the visibility to the named server. This is the most specific scope for defining resources. The resource factories that are defined within the server scope are available for applications that are deployed on this server and override any resource factories that have the same JNDI name defined within the node and cell scopes. The resource factories that are defined within the node and cell scopes are available for this server to use, in addition to the resource factories that are defined within this server scope.
The application scope value limits the visibility to the named application.
Application scope resources cannot be configured from the Integrated
Solutions Console. Use Rational Application Developer Assembly and Deploy
V7.5, or the
wsadmin.sh tool to view or modify the application scope
resource configuration. The resource factories that are defined within the application
scope are available for this application to use only. The application scope
overrides all other scopes.
You can define resources at multiple scopes but the definition at the most specific scope is used.
When selecting a scope, the following rules apply:
The application scope has precedence over all the scopes.
The server scope has precedence over the node, cell, and cluster scopes.
The cluster scope has precedence over the node and cell scopes.
The node scope has precedence over the cell scope.
When viewing resources, you can select the scope to narrow the list to just the resources defined at the scope. Alternatively, you can select to view resources for all scopes. Resources are always created at the currently selected scope. Resources created at a given scope might be visible to lower scope. For example, a data source created at a node level might be visible to servers within the node.