Figure 7-1 contains the following components:

• A client application, which connects to an application running on WebLogic Server, but which also needs to connect to an EIS

• An external system (in this case, an EIS or Enterprise Information System)

• An application component (an EJB) that the client application uses to submit outbound requests to the EIS through the resource adapter

• A message endpoint application (a message-driven bean and possibly other Java EE components) used for the receipt of inbound messages from the EIS through the resource adapter

• The WebLogic Server Work Manager and an associated thread (or threads) to which the resource adapter submits Work instances to process inbound messages and possibly process other actions.

• An external Transaction Manager, to which the WebLogic Server Transaction Manager is subordinate for transactional inflow of messages from the EIS

• The WebLogic Server Connector container in which the resource adapter is deployed. The container manages the following:

  • A deployed resource adapter that provides bi-directional (inbound and outbound) communication to and from the EIS.

  • An active Work instance.

  • Multiple managed connections (MC1, ..., MCn), which are objects representing the outbound physical connections from the resource adapter to the EIS.

  • Connection handles (C-handle) returned to the application component from the connection factory of the resource adapter and used by the application component for communicating with the EIS.

  • One of perhaps many activation specifications. There is an activation specification (ActivationSpec) that corresponds to each specific message listener type, MLT-j. For information about requirements for an ActivationSpec class, see Chapter 13, Message Inflow in JSR 322: Java EE Connector Architecture 1.6.

  • One of the connection pools maintained by the container for the management of managed connections for a given ManagedConnectionFactory (in this case, MCF-2. A Connector container could include multiple connection pools, each corresponding to a different type of connections to a single EIS or even different EISes).

  • A MessageEndpointFactory created by the EJB container and used by the resource adapter to create proxies to MessageEndpoint instances (MDB instances from the MDB pool).

• An external message source, which could be an EIS or Message Provider

A resource adapter may handle an inbound message in a variety of ways. For example, it may:

• Handle the message locally, that is, within the ResourceAdapter bean, without involving other components.

• Pass the message off to another application component. For example, it may look up an EJB and invoke a method on it.

• Send the message to a message endpoint. Typically, a message endpoint is a message-driven bean (MDB). For more information, see Message Inflow to Message Endpoints (Message-Driven Beans).

Inbound messages may return a result to the EIS that is sending the message. A message requiring an immediate response is referred to as synchronous (the sending system waits for a response). This is also referred to as request-response messaging. A message that does not expect a response as part of the same exchange with the resource adapter is referred to as asynchronous or event notification-based communication. A resource adapter can support asynchronous or synchronous communications for all three destinations listed above.

Depending upon the transactional capabilities of the resource adapter and the EIS, inbound messages can be either part of a transaction (XA) or not (non-transactional). If the messages are XA, the controlling transaction may be coordinated by an external Transaction Manager (transaction inflow) or by the application server's Transaction Manager. See Transactional Inflow.

In most cases, inbound messages in a resource adapter are dispatched through a Work instance in a separate thread. The resource adapter wraps the work to be done in a Work instance and submits it to the application server's Work Manager for execution and management. A resource adapter can submit a Work instance using the doWork(), startWork(), or scheduleWork() methods depending upon the scheduling requirements of the work.

The resource adapter can expose connection configuration information to the deployer by various means; for example, as properties on the ResourceAdapter bean or properties on the ActivationSpec object. An alternative is to use the same communication channel for inbound as well as outbound traffic. Thus you can also set configuration information on the outbound connection pool.

A resource adapter can be deployed independently (as a standalone RAR) or as part of an enterprise application (EAR). An MDB can also be deployed independently (as a standalone JAR) or as part of an enterprise application (EAR). In either case, an MDB whose messages are derived from a resource adapter must be bound to the resource adapter. The following sections describe binding the MDB and resource adapter and subsequent messaging operations.

1. A message arrives from the EIS to the resource adapter.
2. The resource adapter examines the message and determines its type by looking it up in an internal table. The resource adapter determines the message type corresponds to a particular pair (MessageEndpointFactory, ActivationSpec).
3. The resource adapter determines the message should be dispatched to an MDB.
4. Using the MessageEndpointFactory for that type of message endpoint (one to be dispatched to an MDB), the resource adapter creates an MDB instance by invoking createEndpoint() on the factory.
5. The resource adapter then invokes the message listener method on the MDB instance, passing any required information (such as the body of the incoming message) to the MDB.
6. If the message listener does not return a value, the message dispatching process is complete.
7. If the message listener returns a value, the resource adapter determines how to handle that value. This may or may not result in further communication with the EIS, depending upon the contract with the EIS.

A resource adapter is configured with a mapping of message types and activation specifications. The activation specification is a JavaBean that implements javax.resource.spi.ActivationSpec. The resource adapter has an ActivationSpec class for each supported message type. The mapping of message types and activation specifications is configured in the ra.xml deployment descriptor, as described in Configuring Inbound Connections. For more information about ActivationSpecs, see Chapter 13, Message Inflow, in JSR 322: Java EE Connector Architecture 1.6.

As described in section 13.4.2.3 of JSR 322: Java EE Connector Architecture 1.6, a resource adapter may provide the Java class name and the interface type of an optional set of JavaBean classes representing administered objects that are specific to a messaging style or message provider. You configure administered objects in the admin-objects elements of the ra.xml and weblogic-ra.xml deployment descriptor files. As with outbound connections and other WebLogic resource adapter configuration elements, you can define administered objects at three configuration scope levels:

• Global - Specify parameters that apply to all administered objects in the resource adapter using the default-properties element. See weblogic-ra.xml Schema in Table A-15

• Group - Specify parameters that apply to all administered objects belonging to a particular administered object group specified in the ra.xml deployment descriptor using the admin-object-group element. The properties specified in a group override any parameters specified at the global level. See admin-object-group.

  The admin-object-interface element (a subelement of the admin-object-group element) serves as a required unique element (a key) to each admin-object-group. There must be a one-to-one relationship between the admin-object-interface element in weblogic-ra.xml and the admin-object-interface element in ra.xml.

• Instance - Under each admin object group, you can specify administered object instances using the admin-object-instance element of the weblogic-ra.xml deployment descriptor. These correspond to the individual administered objects for the resource adapter. You can use the admin-object-properties subelement to specify properties at the instance level too; properties specified at the instance level override those provided at the group and global levels. See admin-object-instance.

When the resource adapter receives requests from application components running in the same server instance as the resource adapter that need to be delivered to an MDB as part of the same transaction as the resource adapter request, the transaction ID must be obtained from the transaction on the current thread and placed in a TransactionContext (or ExecutionContext).

In this case, WebLogic Server does not use the Interposed Transaction Manager but simply passes the transaction on to the Work Thread used for message delivery to the MDB.

1. Select the resource adapter in the Summary of Deployments > Control page.
2. Select Configuration > Workload.
3. Enter a new value in Maximum Number of Concurrent Long Running Requests, if desired, and click Save.

   If you save a new value, the Save Deployment Plan Assistant is displayed, which prompts you to select or enter the path of a deployment plan file. For more information about working with deployment plans, see Understanding WebLogic Server Deployment in Deploying Applications to Oracle WebLogic Server.

1. Select the resource adapter in the Summary of Deployments > Control page.
2. Select Monitoring > Workload.

   The following information about long-running Work instance requests is available from the Long Running Work Managers table:

   Table 7-1 Description of Columns in the Long Running Work Managers Table

   Column Name	Description
   Active Requests	The number of currently active long-running Work instance requests.
   Completed Requests	The number of completed long-running Work instance requests.
   Max Concurrent Requests Allowed	The maximum number of concurrent Work instance requests allowed.