6 JMS Provider Management

The Oracle Enterprise Messaging Service (OEMS) provides a robust architecture for integrating business-critical applications. Built on Java 2 Enterprise Edition (J2EE) standards such as the Java Message Service (JMS) and the J2EE ConnectorArchitecture (JCA), OEMS reduces the time, cost, and effort required to build integrated and distributed applications. Through a common interface, JMS, OEMS offers developers a quality of service (QoS) choice for persisting messages.

The RIB is designed to be JMS provider agnostic and will be certified with several, starting with the OEMS JMS Database persistence option; which is the JMS interface to the Oracle Database Streams Advanced Queuing (AQ) feature. Subsequent releases will add certification of the OC4J JMS (for the file and memory-persistence version) that is bundled with the Oracle Application Server, as well as other JMS standard providers.

For more details on OEMS, see the Oracle® Containers for J2EE Services Guide 10g - Using Oracle Enterprise Messaging Service.

The RIB on AQ JMS

The AQ JMS is a database and needs to be installed, configured, and tuned to support the anticipated transaction loads for a retailer's production message volumes.

There are some areas to be considered by the RIB team and the Database Administrators.

It is strongly recommended that the Oracle Database Instance that is configured to be the AQ JMS provider is not shared with any other applications and is not on the same host (physical or logical) with any other applications.
AQ, on the server side, is I/O intensive. Pay close attention to the disk layout.
AQ JMS as used by the RIB will have high transaction rates. Consider this in configuration of the redo logs.

AQ JMS should be run in archive log mode. If the database crashes, it must be recoverable to a point-in-time or messages (business events) will be lost.
The RIB is a client of the AQ database and uses JDBC connections via the aqapi client. The average message size for a given interface affects the network and overall performance behavior.
AQ JMS sizing to avoid out-of-space situations is critical.

Queue Monitor Process Setup

The QMON processes are optional background processes for Oracle Streams Advanced Queuing (AQ) which monitor and maintain all the system and user owned AQ objects. They provide the mechanism for message expiration, retry, and delay, maintain queue statistics, remove processed messages from the queue table and maintain the dequeue IOT.

The number of queue monitor processes is controlled by the dynamic initialization parameter AQ_TM_PROCESSES. There can be a maximum of 10 QMON processes. The parameter AQ_TM_PROCESSES can be set in the PFILE or SPFILE:

aq_tm_processes=4
alter system set aq_tm_processes=4

Starting with Oracle RDBMS release 10.1, Oracle automatically manages the QMON monitor processes depending on the system load. It is no longer required to explicitly set AQ_TM_PROCESSES. However, it is recommended to monitor the workload and make any adjustments. If the QMON processes lag behind, there is a chance of expired messages remaining in the queue and the tablespace eventually running out of space.

If explicitly setting AQ_TM_PROCESSES, our recommended value is between 2 to 8. Do not set the value to the maximum allowed value of 10 in Oracle 10g. This is due to the fact that all explicitly started QMON processes work only with persistent messages. Oracle can automatically start processes to maintain buffered messages. Setting AQ_TM_PROCESSES to a maximum value of 8 still leaves 2 processes for Oracle that can be started to maintain buffered messages.

Optimizing Enqueue/Dequeue Performance

The AQ database performance needs to be tuned as per Oracle database tuning practices.

Tuning the SGA. Use tools such as Statspack, Oracle Enterprise Manager and SQL trace to find out bottlenecks. An inefficiently configured SGA will slow-down enqueue and dequeue transactions.

Tune the Server Resources: Check server CPU, memory, I/O and network utilization. Tools such as nmon, sar, iostat, vmstat, glance can be used to collect system statistics. Use shared memory and semaphore parameters that are recommended for the Oracle database on that type of server.

Tune Physical Schema setup: This will include creating right tablespaces, placements of datafiles, tables, and indexes.

Note:

See also Oracle® Database Administrator's Guide 10g Release 2 (10.2), Oracle® Streams Advance Queuing User's Guide, and Reference 10g Release 2 (10.2)

Sizing Considerations

There some important considerations required by the RIB team and Database Administrators for sizing for the deployment of the RIB on AQ JMS.

The enqueuing/dequeuing rate for the messages per message family affects the requirement for the number of available database segments.

By default, all RIB topics are created in a single tablespace. AQ creates multiple tables for each topic within that tablespace. A topic (message family) that has a high transaction rate can quickly consume available segments. If the tablespace is not sized appropriately, then a single interface can negatively impact all interfaces.

The QMON background process that is responsible for space management will not keep up the transaction rates of some RIB interfaces. In this case, the transaction rate is defined as the rate of enqueuing vs. dequeuing. Messages that are subscribed (consumed) are not removed from the AQ tables immediately. It is the normal case that the enqueue rate will be faster than the dequeue rate. This time lag should be a sizing consideration.
The total tablespace(s) sizing needs to be calculated based on the business requirement for the number of messages that have to be retained per message family if a subscribing application is off-line.

It is very common for a subscribing application to go off-line. This means that messages have to be retained (persisted) on the JMS until the subscriber comes back on-line. The general sizing guideline for any RIB JMS sub-system is for the disk (mount points or database) to be able to handle 24 hours of maximum messages per topic as defined by the site's projected volume requirements. For example -- OrdersFromRMS may be specified to retain 355,000 details (e.g. 1000 1M messages = 1GB). This calculation needs to be performed for each of the 90+ topics in the GA RIB system and based on the customer's estimated volume per interface.

Note:

See the section,"How to Calculate Average Message Size", in this manual.

Support for Multiple JMS Servers Within a Single Deployment

Employing multiple JMS servers allows for the isolation of flows (for example, high volume versus low, custom versus base, and message families) for performance and operational QoS.

Design

To meet the JMS agnostic requirement for the RIB, a unique JMS server ID (jms-server-id) is assigned to each RIB adapter. Accordingly, each RIB adapter can identify the JMS server to which it is associated. As the default, "out-of-the-box" adapters are configured to be on jms-server, "jms1."

For each new jms-server-ID, a new resource adapter must be configured to point the application server to the JMS provider's resource. The adapter communicates with the JMS server and is deployed as part of the application. Where customization is required, the adapter can be configured to point to a different JMS server.

rib-app-builder Validation Checks

The rib-app-builder performs several validation checks, as listed below To prevent the rib-app-builder compilation process from failing, fails the following criteria must be met:

Each jms-server-id is unique where more than one JMS server is configured.
Within a message flow, the jms-server-id is the same for all applications.
A jms-server-id is present in the rib-deployment-env-info.xml and present in at least one of the rib-<app>-adapters.xml files.
A jms-server-id is present in rib-<app>-adapters.xml and present in the rib-deployment-env-info.xml file.
Multiple channels are configured for a give family are on the same JMS server.
Proper hospitals are configureed for all JMS servers. (Where additional JMS servers are configured, the rib-app-builder checks to see if hospital adapters are configured for all JMS servers.)

How to Set Up Multiple JMS Servers

Process Overview

Determine the family to be configured.
Examine the rib-integration-flows.xml to identify all the RIB applications in the full integration flow.
Add a new JMS server by updating rib-deployment-env-info.xml.
In the rib-home, modify the appropriate files for each of the rib-<apps> participating in the integration flow. Point the adapters to the correct JMS server:
1. rib-<app>-adapters.xml
2. rib-<app>-adapter-resources.properties
Compile all applicable rib-<apps>.
Run prepare-jms for the newly created JMS server.
Deploy.

General Recommendations

The default ID for out-of-the-box JMS servers is "jms1". It is recommended that the same nameing convention is followed when additional JMS servers are configured (for example, "jms2").
If multiple JMS servers require configuration, it is recommended that the application (for example, rib-rms) be completely removed (or undeployed) before the new deployment begins.

AQ Recommendation

If multiple AQ JMS servers are configured, each must be on a different database server instance.

Sample Configuration

Following are portions of the Items message flow from rib-integration-flows.xml. The message originates from RMS flows through a TAFR. The TAFT sends the message to two topics, and the message is subscribed by RWMS and SIM. The samples below assume that a new jms-server-id (jms2) is required for the message flow.

rib-integration-flows.xml

  <message-flow id="6">              <node id="rib-rms.Items_pub" app-name="rib-rms"                    adapter-class-def="Items_pub" type="DbToJms">                     <in-db>default</in-db>                     <out-topic>etItemsFromRMS</out-topic>              </node>              <node id="rib-tafr.ItemsToItemsTL_tafr" app-name="rib-tafr"                    adapter-class-def="ItemsToItemsTL_tafr" type="JmsToJms">                     <in-topic>etItemsFromRMS</in-topic>                     <out-topic>etItemsTLFromRIB</out-topic>              </node>              <node id="rib-tafr.ItemsToItemsISO_tafr" app-name="rib-tafr"                    adapter-class-def="ItemsToItemsISO_tafr" type="JmsToJms">                     <in-topic>etItemsFromRMS</in-topic>                     <out-topic>etItemsISO</out-topic>              </node>              <node id="rib-rwms.Items_sub" app-name="rib-rwms"                    adapter-class-def="Items_sub" type="JmsToDb">                     <in-topic>etItemsTLFromRIB</in-topic>                     <out-db>default</out-db>              </node>              <node id="rib-sim.Items_sub" app-name="rib-sim"                    adapter-class-def="Items_sub" type="JmsToDb">                     <in-topic>etItemsISO</in-topic>                     <out-db>default</out-db>              </node>       </message-flow>

Note:

The following are the configuration changes required for the message flow. The example assumes that all applications apply (RMS, TAFT, SIM, and RWMS).

rib-deployment-env-info.xml

A new JMS server with jms-server-id="jms2" is added in rib-deployment-env-info.xml file as follows:

<aq-jms-servers>               <aq-jms-server jms-server-id="jms1">                            <jms-server-home>user@host:/u00/db</jms-server-home>                         <jms-url>jdbc:oracle:thin:@host:port:SID</jms-url>                           <jms-port>1521</jms-port>                         <jms-user>ribaq</jms-user>                        <jms-password>ribaq</jms-password>      </aq-jms-server>                     <aq-jms-server jms-server-id="jms2">                            <jms-server-home>user@host:/u00/db</jms-server-home>                           <jms-url>jdbc:oracle:thin:@host:port:SID</jms-url>                           <jms-port>1521</jms-port>                       <jms-user>aq2</jms-user>              <jms-password>aq2</jms-password>      </aq-jms-server> </aq-jms-servers>

RIB-RMS Application Configuration

To configure the RIB-RMS application, complete the following steps:

rib-rms-adapters.xml changes

Edit $RIB_HOME/application-assembly-home/rib-rms/rib-rms-adapters.xml, where $RIB_HOME is the rib-home directory. For example, /u00/riboas/RIB13.0.2/Rib1302ForAll13xxApps/rib-home/

Point the Items_pub_1 adapter to jms-server-id "jms2" as follows:

<timer-driven id="Items_pub_1" initialState="stopped" timeDelay="10" jms-server-id="jms2">              <timer-task>                    <class name="com.retek.rib.app.getnext.impl.GetNextTimerTaskImpl"/>                    <property name="maxChannelNumber" value="1" />              </timer-task></timer-driven>

Add hospital adapters for jms-server-id "jms2", as follows:

<!-Hospital adapter configuration starts here --><timer-driven id="sub_hosp_2" initialState="stopped" timeDelay="10" jms-server-id="jms2">         <timer-task>                            <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                           <property name="reasonCode" value="SUB"/>                 </timer-task></timer-driven><timer-driven id="pub_hosp_2" initialState="stopped" timeDelay="10"  jms-server-id="jms2">            <timer-task>                                <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                          <property name="reasonCode" value="PUB"/>          </timer-task></timer-driven><timer-driven id="jms_hosp_2" initialState="stopped" timeDelay="10"  jms-server-id="jms2">           <timer-task>                         <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                          <property name="reasonCode" value="JMS"/>          </timer-task></timer-driven>

rib-rms-adapters-resources.properties

Add the following properties to the resource file:

sub_hosp-2.name=SUB Hospital Retry jms2

sub_hosp-2.desc=Inject messages into from the Error Hospital.

pub_hosp-2.name=PUB Hospital Retry jms2

pub_hosp-2.desc=Re-publish messages from to JMS.

jms_hosp-2.name=JMS Hospital Retry jms2

jms_hosp-2.desc=Re-publish messages from to JMS after JMS is brought up again.

RIB-TAFR Application Configuration

To configure the RIB-TAFR application, complete the following steps:

rib-tafr-adapters.xml

Edit $RIB_HOME/application-assembly-home/rib-rms/rib-rms-adapters.xml, where $RIB_HOME is the rib-home directory. For example, /u00/riboas/RIB13.0.2/Rib1302ForAll13xxApps/rib-home/
Point the ItemsToItemsTL_tafr_1 adapter to jms-server-id "jms2", as shown below.

Point the ItemsToItemsISO_tafr_1 adapter to jms-server-id "jms2", as shown below:

<tafrs>       <message-driven id="ItemsToItemsTL_tafr_1" initialState="stopped" tafr-business-impl="com.retek.rib.domain.tafr.bo.impl.ItemsToItemsTLFromRibBOImpl"  jms-server-id="jms2" />       <message-driven id="ItemsToItemsISO_tafr_1" initialState="stopped" tafr-business-impl="com.retek.rib.domain.tafr.bo.impl.ItemsToItemsISOFromRibBOImpl"  jms-server-id="jms2" /></tafrs>

Add hospital adapters for jms-server-id "jms2".

<!-Hospital adapter configuration starts here --><timer-driven id="sub_hosp_0" initialState="stopped" timeDelay="20"  jms-server-id="jms2">         <timer-task>                 <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                 <property name="reasonCode" value="SUB"/>             </timer-task>         </timer-driven><timer-driven id="jms_hosp_0" initialState="stopped" timeDelay="30" jms-server-id="jms2">          <timer-task>                 <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                 <property name="reasonCode" value="JMS"/>             </timer-task></timer-driven>

rib-tafr-adapters-resources.properties

Add the following properties to the resource file:

sub_hosp-2.name=SUB Hospital Retry jms2

sub_hosp-2.desc=Inject messages into from the Error Hospital.

jms_hosp-2.name=JMS Hospital Retry jms2

jms_hosp-2.desc=Re-publish messages from to JMS after JMS is brought up again.

RIB-SIM Application Configuration

To configure the RIB-SIM application, complete the following steps:

rib-sim-adapters.xml

Edit $RIB_HOME/application-assembly-home/rib-rms/rib-rms-adapters.xml, where $RIB_HOME is the rib-home directory. For example, /u00/riboas/RIB13.0.2/Rib1302ForAll13xxApps/rib-home/
```
<subscribers>      <message-driven id="Items_sub_1" initialState="running" jms-server-id="jms2"/></subscribers>
```

Add hospital adapters for jms-server-id "jms2".

<!-Hospital adapter configuration starts here --><timer-driven id="sub_hosp_0" initialState="stopped" timeDelay="20"  jms-server-id="jms2">         <timer-task>                   <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                 <property name="reasonCode" value="SUB"/>           </timer-task></timer-driven><timer-driven id="jms_hosp_0" initialState="stopped" timeDelay="30" jms-server-id="jms2">          <timer-task>                  <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>                  <property name="reasonCode" value="JMS"/>             </timer-task></timer-driven>

rib-sim-adapters-resources.properties

Add the follwoing properties to the resources file:

sub_hosp-2.name=SUB Hospital Retry jms2

sub_hosp-2.desc=Inject messages into from the Error Hospital.

jms_hosp-2.name=JMS Hospital Retry jms2

jms_hosp-2.desc=Re-publish messages from to JMS after JMS is brought up again.

RIB-RWMS Application Configuration

To configure the RIB-SIM application, complete the following steps

rib-rwms-adapters.xml

Edit $RIB_HOME/application-assembly-home/rib-tafr/rib-tafr-adapters.xml

Point the Items_sub_1 adapter to jms-server-id "jms2".

<subscribers>         <message-driven id="Items_sub_1" initialState="running" jms-server-id="jms2"/></subscribers>

Add hospital adapters for jms-server-id "jms2".

<!-Hospital adapter configuration starts here --><timer-driven id="sub_hosp_0" initialState="stopped" timeDelay="20"  jms-server-id="jms2">    <timer-task>            <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>            <property name="reasonCode" value="SUB"/>   </timer-task></timer-driven><timer-driven id="jms_hosp_0" initialState="stopped" timeDelay="30" jms-server-id="jms2">   </timer-task>          <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>          <property name="reasonCode" value="JMS"/>     </timer-task></timer-driven>

rib-rwms-adapters-resources.properties

sub_hosp-2.name=SUB Hospital Retry jms2

sub_hosp-2.desc=Inject messages into from the Error Hospital.

jms_hosp-2.name=JMS Hospital Retry jms2

jms_hosp-2.desc=Re-publish messages from to JMS after JMS is brought up again.

Compile and Deploy

Using the RIB Installer or the RIB App Builder command line tools compile, and deploy the new rib-<app>.ears.

RIB-ADMIN-GUI

After deployment check if the adapters configured point to the correct JMS server.

Surrounding text describes rib_adapter_manager.png.