Oracle Message Broker Adminstration Guide
Release 2.0.1.0

Part Number A65435-01

Library

Product

Contents

Index

Go to previous page Go to next page

8
Oracle Message Broker Propagation

This chapter describes the Oracle Message Broker propagation manager. The Oracle Message Broker uses a propagation manager to transfer messages between JMS destinations, either within a single Oracle Message Broker, or on different Oracle Message Brokers running in a distributed environment. The propagation manager supports propagation between Oracle Message Brokers using either the IIOP protocol or the HTTP protocol.

This chapter covers the following:

Overview of Oracle Message Broker Propagation

In order to transfer messages from one JMS destination to another JMS destination, an entry for a propagation job needs to be created in the Oracle Message Broker administrative LDAP Directory. A propagation job defines a propagation source, a propagation target, and a propagation transport protocol. The Oracle Message Broker that dequeues messages from the source destination is the sending broker, while the Oracle Message Broker that enqueues messages into the target destination is the receiving broker. The sending broker and receiving broker for a propagation job can be the same broker if the source destination and the target destination of the propagation job are managed by the same Oracle Message Broker.

When a propagation job is activated, the sending broker works with the receiving broker to move messages from the source destination to the target destination. If both the source destination and the target destination are persistent, messages are guaranteed to be delivered from the source to the target reliably (in order, with no loss, and no duplicates). If either the source or the target of a propagation job is non-persistent, the sending broker and receiving broker make every effort to deliver messages reliably. However, non-persistent messages may be lost in the case of failures of either the sending or the receiving broker, or any of the underlying messaging systems.


Note:

The propagation feature is only available when running the Oracle Message Broker in Remote Mode. 


This section covers the following:

Types of Propagation

Oracle Message Broker message propagation can be used for the following purposes:

To perform one of these types of propagation, the Oracle Message Broker administrator configures a propagation job. The characteristics of the source and the target destinations determines the type of propagation that is performed, either: message distribution, message server conversion, or domain conversion.

Message Distribution

Using message distribution propagation, the Oracle Message Broker uses its propagation feature to transfer messages between destinations. To use this type of propagation, the administrator configures a propagation job and specifies the source queue (or topic) and the target queue (or topic).

For example, Figure 8-1 shows message distribution for Volatile Queue Q1 on site A, to Volatile Queue Q2 on site B.

Figure 8-1 Sample Message Distribution with Propagation


Message Server Conversion

Using message server conversion, the Oracle Message Broker transfers messages between different supported message servers. The Oracle Message Broker supports message servers using the available Oracle Message Broker drivers (for more information see Chapter 7, "Message Servers and Drivers").

The propagation manager supports message server conversion between the following drivers: Oracle Advanced Queuing (AQ) Driver, IBM MQSeries Driver, Oracle Volatile Driver, Oracle Multicast Driver, and the TIBCO/Rendezvous Driver.

Figure 8-2 shows message server conversion from AQ Queue Q1 on Site A to MQ Series Queue Q2 on Site B.

Figure 8-2 Sample Propagation Message Server Conversion


Domain Conversion

The domain conversion feature uses the Oracle Message Broker to transfer messages between supported JMS messaging domains. Domain conversion allows the Oracle Message Broker to send messages from a JMS queue to a JMS topic, or from a JMS topic to a JMS queue (in either direction).

For example, Figure 8-3 shows message propagation from AQ topic T1 to AQ queue Q1.

Figure 8-3 Sample Propagation Domain Conversion


Propagation with Message Selectors

Some applications in a distributed environment require messages to be distributed among messaging systems based on message properties. Oracle Message Broker propagation supports this feature by allowing the administrator to associate a message selector with a propagation job. Using this feature, only the messages that satisfy the message selector are propagated from the source to the target.


Note:

Message selectors can be specified only for a propagation job whose source is a topic. Message selectors are not supported when the propagation source is a queue. 


A message selector for a propagation job must be defined as a valid JMS message selector (for more information on the valid message selector format, see "Message Selector Format"). Refer to "Propagation Job Configuration" for more information on specifying propagation job message selectors.

Figure 8-4 shows an example of this type of propagation, where the messages in the queue, q_color on broker-1, are distributed to many destinations on other Oracle Message Brokers (queue q_red on broker-2, queue q_green on broker-3 and queue q_red_blue on broker-4). Messages are selected for distribution based on message properties using selectors. For example, the colors red, blue, and green, stored in a JMS properties could be selected for propagation to the specified color queues on the target Oracle Message Brokers.

By accessing the queue q_red, an application on broker-2 receives all and only the "red" messages that were propagated from the queue q-color on broker 1.

To distribute messages as shown in Figure 8-4, the source q_color must be a topic, and three propagation jobs need to have the color message selectors defined, as shown in the figure.

Figure 8-4 One-to-many Propagation using Message Selectors


Propagation Transport Protocols

The Oracle Message Broker propagation manager allows propagation between queues and topics using two transport protocols:

IIOP Propagation

Using IIOP propagation, messages are propagated between the sending broker and the receiving broker using the CORBA IIOP protocol. This is the default transport protocol.

Local Propagation

When the propagation manager finds a single broker is used as both the sending broker and the receiving broker, the propagation manager uses local procedure calls rather than IIOP.

HTTP Propagation

The Oracle Message Broker HTTP propagation manager supports two types of HTTP propagation:

This section describes the two HTTP propagation types.

Direct HTTP Propagation

Oracle Message Broker can be configured to use Oracle Message Broker's built-in HTTP listeners. If a sending broker can directly access the HTTP built-in listeners on a receiving broker and create HTTP connections, direct HTTP propagation can be setup between the sending broker and the receiving broker (see Figure 8-5). Compared with servlet based propagation, direct HTTP propagation is easier to setup and usually has better performance characteristics.

Figure 8-5 HTTP Direct Propagation


Servlet Based Propagation

A built-in HTTP listener running in the receiving broker behind a firewall may not be directly accessible to a sending broker outside the firewall. Some organizations require, for security reasons, that all HTTP traffic pass through centralized web servers. In this case, an Oracle Message Broker HTTP propagation servlet needs to be deployed on the web server to forward messages from the web server to the receiving broker (See Figure 8-6). Using servlet based propagation, Oracle Message Broker propagation jobs that send messages to the receiving broker are configured as though the messages are sent to the servlet. The HTTP propagation servlet then transfers the messages to the receiving broker.

An HTTP propagation servlet communicates with one and only one Oracle Message Broker built-in HTTP listener of a receiving broker. If there are more than one receiving brokers behind the same firewall, multiple propagation servlets must be configured (each using a different virtual path).

The configuration parameters of the HTTP propagation servlet include a host name, the HTTP listener port number, SSL level, and wallet information for the associated receiving broker (for more information, see "HTTP Propagation Servlet Configuration".)

Figure 8-6 HTTP Propagation Using a Servlet


Administration and Configuration

Propagation configuration tasks differ depending on whether the administrator is configuring the sending broker or the receiving broker (a broker may be both a sending broker and a receiving broker). To set up and configure the Oracle Message Broker for propagation and to create propagation jobs, the Oracle Message Broker administrator needs to perform one or more of the following tasks:

Sending Broker Configuration

Configuring and setting up a sending broker for propagation includes the following tasks:

Configuring the Message Broker Entry (for the Sender)

To configure the msg_broker entry for propagation on the sending broker, use the Oracle Message Broker administrative utilities. Table 4-8 shows the msg_broker entry attributes, including the sending broker related attributes:

Setting Propagation Send Threads

By default, the propagation_send_threads attribute is set to one (1). The administrator can change the default value to tune the Oracle Message Broker to handle propagation more efficiently, based on the available resources and on the desired number of concurrent active propagation jobs.

Setting Propagation HTTP Handlers (for HTTP Propagation only)

When an Oracle Message Broker participates in HTTP propagation as a sending broker, the administrator needs to configure the propagation_http_handlers attribute (see Table 4-8). This specifies the number of HTTP propagation handler threads that are used to process acknowledgments and flow control requests from receiving brokers.

Do not use the administration utilities to modify the propagation_http_handlers attribute when the Oracle Message Broker is active (this is a msg_broker entry attribute). If attempted, the updated value is added to the directory, but the existing, old value is used until the Oracle Message Broker is restarted.

Configuring Persistent Message Servers and Drivers

If a broker is expected to process propagation jobs that use persistent destinations as source, the associated persistent message server needs to be configured to support propagation. The message servers that support persistent messages are:

Using persistent queues or topics with propagation, the administrator needs to perform the following actions to setup the message server and the driver:

  1. Create Propagation Logging Queue For Sending

  2. Configure Message Server Logging Queue Attribute

  3. Configure Driver Propagation Send Sessions Attribute


    Note:

    The administrator only needs to perform the steps in this section for propagation jobs with a destination using the Oracle AQ Driver or the IBM MQSeries Driver. 


Create Propagation Logging Queue For Sending

The propagation manager uses the propagation logging queue to log the state of propagation jobs. The propagation manager uses logging information for propagation job recovery in case of failure. This propagation configuration step requires the following actions:

    1. For MQSeries or Oracle AQ, create the sending log queue entry. The sending log queue entry is created like any other queue using the Oracle Message Broker administration utilities. For AQ queues, this step should also create the native AQ queue.

    1. For MQSeries, use the native MQSeries administration tools to create the native queue.

The sending log queue and the receiving log queue can be the same. Using separate queues for the logging queues should provide better performance.

For propagation with an AQ source, the associated sending log queue must be configured using the following specification for the aq_adt attribute.

Configure Message Server Logging Queue Attribute

After creating the required sending log queue, set the prop_send_log_queue in the message server entry to the DN of the sending log queue.


Note:

You only need to set both of the prop_send_log_queue and the prop_recv_log_queue attributes only if the server is used for both the sending and receiving. 


Configure Driver Propagation Send Sessions Attribute

For the driver associated with the propagation source destination, set the driver's propagation_send_sessions attribute to the desired number of sessions on the driver. This value determines the degree of concurrency for the propagation sending process. When setting this value, note the following restriction:

propagation_recv_sessions + propagation_send_sessions < max_private_sessions

Configuring Remote Directories (for IIOP Propagation Only)

A Remote Directories entry represents a foreign, or remote, LDAP Server. A remote directory entry provides information about how to access a remote LDAP Server to resolve a propagation target DN in the propagation job entry.

A remote directories entry only needs to be specified when an Oracle Message Broker is involved in IIOP propagation as a sender. See Table 4-19 for a description of the Remote Directories entry attributes.

Configuring Remote HTTP Listeners (for HTTP Propagation Only)

A Remote HTTP Listener entry represents a foreign, or remote, Oracle Message Broker built-in HTTP listener, or a propagation servlet.

A Remote HTTP Listener entry only needs to be specified when an Oracle Message Broker is involved in HTTP propagation as a sender. See Table 4-20 for a description of the remote HTTP listener entry attributes.


Note:

The attributes remote_wallet_location and remote_wallet_password specify a "local" wallet information on the sending site 


Receiving Broker Configuration

Configuring and setting up a receiving broker for propagation includes the following tasks:

Configuring the Message Broker Entry (for the Receiver)

To configure the msg_broker entry for propagation on the receiving broker, use the Oracle Message Broker administrative utilities. Table 4-8 shows the msg_broker entry attributes, including the receiving broker related attributes:

Setting Propagation Receive Threads

By default, the propagation_recv_threads attribute is set to one (1). The administrator can change the default value to tune the Oracle Message Broker to handle propagation more efficiently, based on the available resources and on the desired number of concurrent active propagation jobs.

Setting Propagation HTTP Handlers (for HTTP Propagation only)

When an Oracle Message Broker participates in HTTP propagation as a receiving broker, the administrator needs to configure the propagation_http_handlers attribute (see Table 4-8). This specifies the number of HTTP propagation handler threads that are used to process propagation requests from sending brokers.

Do not use the administration utilities to modify the propagation_http_handlers attribute when the Oracle Message Broker is active (this is a msg_broker entry attribute). If attempted, the updated value is added to the directory, but the existing, old value is used until the Oracle Message Broker is restarted.

Configuring Persistent Message Servers and Drivers

If a broker is expected to process propagation jobs that use persistent destinations as targets, the associated persistent message server needs to be configured to support propagation. The message servers that support persistent messages are:

Using persistent queues or topics with propagation, the administrator needs to perform the following actions to setup the message server, and the driver:

  1. Create Propagation Logging Queue for Receiving

  2. Configure Message Server Logging Queue Attribute

  3. Configure Driver Propagation Receive Sessions Attribute


    Note:

    The administrator only needs to perform the steps in this section for propagation jobs with a destination using the Oracle AQ Driver, or the IBM MQSeries Driver. 


Create Propagation Logging Queue for Receiving

The propagation manager uses the propagation logging queue to log the state of propagation jobs. The propagation manager uses logging information for propagation job recovery in case of failure. This propagation configuration step requires the following actions:

    1. For MQSeries or Oracle AQ, create the receiving log queue entry. The receiving log queue entry is created like any other queue using the Oracle Message Broker administration utilities. For AQ queues, this step should also create the native AQ queue.

    1. For an MQSeries queue, use the native MQSeries administration tools to create the queue manager.

The sending log queue and the receiving log queue can be the same. Using separate queues for the logging queues should provide better performance.

For propagation with an AQ target, the associated receiving log queue must be configured using the following specification for the aq_adt attribute.

Configure Message Server Logging Queue Attribute

After creating the required receiving log queue, set the prop_receive_log_queue in the message server entry to the DN of the receiving log queue.


Note:

You only need to set both of the prop_send_log_queue and the prop_recv_log_queue attributes only if the server is used for both the sending and receiving. 


Configure Driver Propagation Receive Sessions Attribute

For the driver associated with the propagation target destination, set the driver's propagation_recv_sessions attribute to the desired number of sessions on the driver. This value determines the degree of concurrency for the propagation receiving process. When setting this value, keep the following restriction in mind:

propagation_recv_sessions + propagation_send_sessions < max_private_sessions + 4

Configuring the HTTP Listener (for HTTP Propagation Only)

For a receiving broker participating in HTTP propagation, HTTP listeners must be configured by creating prop_http entries. A receiving broker can have multiple HTTP listeners listening on different ports. After creating a prop_http entry, set its attributes. Refer to Table 4-15 for details on the attributes.


Note:

The HTTP Listener entry only needs to be created and configured on the receiving broker. 


Propagation Job Configuration

The propagation job entry specifies configuration information for the propagation job, such as the source, the target, and the transport protocol. The propagation job entry must be created in the same OMB Instance as its source. This section provides further information on the propagation job attributes shown in Table 4-21.


Note:

A propagation job entry is only defined on the sending side. 


This section describes the following propagation job attributes:

Propagation Source

The propagation source holds the DN of a queue or topic from which messages are propagated.

Note the following limitations when defining a propagation source:

  1. A queue can be the source destination of at most one propagation job, otherwise unrecoverable propagation failures may occur. It is the administrator's responsibility to define only one propagation job per queue as the propagation source.

    If a topic is specified as the source for a propagation job, the topic can be used as the source for other propagation jobs.

  2. Applications should not receive messages from propagation source queues. Receiving messages from the propagation source queue may result in unrecoverable propagation failures. Applications can receive messages from propagation source topics.

Propagation Target

The propagation target holds the DN of a queue or topic to which messages are propagated. This DN is a location on an Oracle Message Broker LDAP Directory. It is not necessarily the local LDAP Directory that stores the propagation source. The target location is determined by the combination of the remote_dn attribute and the propagation_target attribute (see "Remote DN").

When the propagation target is an AQ queue or an AQ topic, the administrator must make sure the types of all messages in the source destination are compatible with the target destination. Otherwise, propagation processing may fail. For example, consider a propagation job that uses a volatile queue as the propagation source, and an AQ queue that is configured with the aq_adt attribute type text for the propagation target. If the source queue contains a message of JMS object type, then the propagation job fails when the object type message is propagated to the target, since the types of messages that the AQ queue specified aq_adt attribute set to text is limited to text messages (see Table 8-1 for limitations on propagation using AQ destinations as the source and AQ destinations as the target).

See "Propagation Limitations" for information on how to avoid creating looped propagation jobs.

When the propagation source and target both use the AQ Driver, they must use compatible types. To configure AQ destination types, set the aq_adt attribute for the topic or the queue. Table 8-1 lists compatible types for AQ propagation.

Table 8-1  Propagation Using the AQ Driver
Source ADT  Supported Destination ADT 

all 

all, raw 

bytes 

all, bytes, raw 

map 

all, map, raw 

object 

all, object, raw 

queriable 

all, queriable, raw 

raw 

all, raw 

stream 

all, stream, raw 

text 

all, text, raw 

Remote DN

The remote DN attribute determines the transport protocol for the propagation job and allows the propagation manager to find the receiving broker and resolves the target destination name. The remote DN attribute value is set to null, a remote directory entry DN, or a remote HTTP entry DN.

The remote_dn attribute should contain one of the values shown in Table 8-2.

Table 8-2  Remote DN Values
Value  Description 

null 

The value of the remote_dn attribute is set to null if the propagation target DN shared the LDAP Server as the propagation source DN.

If the sending broker and the receiving broker use different OMB instances, then IIOP protocol is used for propagating messages from the source to the target.

If the sending broker and the receiving broker are the same broker, then local procedure calls are used to propagate messages from the source to the target. 

Remote Directory entry DN 

When the remote_dn attribute is set to the DN of a Remote Directory entry, the information in the remote directory entry associated with the DN is used to access a remote LDAP Server in order to fetch the propagation target destination entry and the receiving broker entry. This implies using IIOP for the propagation job. 

Remote HTTP entry DN 

When the remote_dn attribute is set to the DN of a Remote HTTP entry, the remote HTTP entry specifies information about how to access the remote HTTP handler. This implies using HTTP for the propagation job. 

Propagation Message Selector

The propagation_msg_selector attribute sets the message selector for the propagation job.


Note:

Message selectors can be specified only for propagation jobs whose source destination is a topic. Message selectors are not supported when the propagation source destination is a queue. 


A message selector for a propagation job must be a string that is a valid JMS message selector (for more information on the valid message selector format, see "Message Selector Format".

The propagation manager processes each propagation job independently. Therefore, a message in a source topic can be propagated to multiple target destinations if its properties satisfy more than one message selector for propagation jobs that use the same topic as propagation source. When messages are only intended to propagate from the source topic to a single target destination, it is the administrator's responsibility to specify exclusive message selectors, among all propagation jobs that use the same topic as source.

Propagation Message Selector Notes

  1. Message selectors cannot be updated. To change a message selector, the associated propagation job entry must be deleted and re-created, using the new message selector.

  2. Deleting a propagation job with a topic as a source results in removing remaining messages. Thus, changing a message selector by deleting a propagation job entry could result in lost messages.

  3. When defining message selectors for propagation jobs using AdminUtil, administrators should pay attention to the special characters, such as ", `, and $, so that the selector to be parsed correctly by AdminUtil (quotes must precede some special characters). If the message selectors are defined using the GUI interface provided with ombadmin, this is not an issue.

  4. Since AQ queues that use the aq_adt attribute, and set its value to queriable do not support JMS properties, propagation message selectors should not be specified for propagation jobs with aq_adt set to queriable (for the propagation source).

Activation State

The activation_state attribute specifies whether the propagation job is activated or deactivated. When a propagation job is deactivated, the propagation manager stops sending messages for the propagation job from the sending broker to the receiving broker. See "Activating and Deactivating a Propagation Jobs" for more information.

Propagation Username

The propagation_username attribute is used along with the propagation_password attribute for authentication and authorization at the receiving site.

Propagation Password

The propagation_password attribute is used along with the propagation_username attribute for authentication and authorization at the receiving site.

Propagation Timeout

The propagation manager at the sending site expects an acknowledgment from the receiving site for each propagation request that it sends. This occurs before the sending site commits operations associated with a request. If the acknowledgment does not arrive within the time specified by the propagation timeout attribute, the propagation manager assumes a failure has occurred with the associated propagation job. The propagation manager then stops the propagation job and automatically tries to recover and continue the propagation job after a delay.

When messages in the following format are shown in the Oracle Message Broker log file, this signifies a potential propagation problem:

Deactivating propagation job [job id] because its requests have timed-out.

The propagation problem could be caused by any of the following:

If the message servers, and the Oracle Message Broker, and the network, and all other components are running properly, then the propagation requests may require more time for processing. In this case, the propagation timeout value should be increased.

Create Timestamp

The create_timestamp attribute is reserved for internal use only. This attribute stores the creation time of the propagation job entry.

Valid Status

The valid_status attribute is used internally by the propagation manager as a flag to indicate if a propagation job entry is valid. An invalid propagation job is caused by an unsuccessful create or delete of a propagation job entry. If a propagation entry is invalid the value of this attribute is set to false. The propagation manager does not process propagation jobs with valid_status in the false state.

To avoid accumulating messages for an invalid propagation job, users should remove invalid propagation jobs.

HTTP Propagation Servlet Configuration

The HTTP propagation servlet requires that the Oracle Message Broker be installed on the system where the servlet runs. After the Oracle Message Broker is installed, the propagation servlet file (PropHttpServlet.class) needs be copied from $OMB_HOME/servlets/propagation/PropHttpServlet.class to the location where the servlet is hosted in the web server (on Windows NT systems, %OMB_HOME%\servlets\propagation\PropHttpServlet.class).

When running with JDK 1.2, the propagation HTTP servlet requires the following three jar files in the classpath:

$OMB_HOME/classess/mercury.jar 
$ORACLE_HOME/jlib/jssl-1_2.jar 
$ORACLE_HOME/jlib/javax-ssl-1_2.jar

When running with JDK 1.1.8, the propagation HTTP servlet requires the following three jar files in the classpath:

$OMB_HOME/classess/mercury.jar 
$ORACLE_HOME/jlib/jssl-1_1.jar 
$ORACLE_HOME/jlib/javax-ssl-1_1.jar

Also, $ORACLE_HOME/lib needs to be included in the LD_LIBRARY_PATH environment variable.

JServ Sample Servlet Configuration

Here is an example for Jserv on Solaris, using JDK1.2, with the following environment variables set to the following values:

ORACLE_HOME = /u/oracle/product/oracle/8.1.6 
OMB_HOME = /u/oracle/product/oralce/8.1.6/omb/2.0

In this sample configuration, to enable the servlet, add the following lines in the file jserv.properties:

wrapper.classpath=/u/oracle/product/oracle/8.1.6/omb/2.0/mercury.jar
wrapper.classpath=/u/oracle/product/oracle/8.1.6/jlib/jssl-1_2.jar
wrapper.classpath=/u/oracle/product/oracle/8.1.6/jlib/javax-ssl-1_2.jar
wrapper.env=LD_LIBRARY_PATH=/u/oracle/product/oracle/8.1.6/lib 

The initial parameters for the HTTP propagation servlet specify the Oracle Message Broker built-in HTTP listener of a receiving broker that the servlet sends messages to. Table 8-3 shows the HTTP servlet parameters.

For example, using Jserv, set these parameters as follows:

servlet.PropHttpServlet.initArgs=host=recvhost,port=80,ssl=1,wallet=/wallets/w1 
passwd=welcome

Table 8-3 HTTP Propagation Servlet Parameters
Name  Description  Default 

host 

Host name of the machine that the receiving broker runs on. 

mandatory 

port 

Port number that the receiving HTTP listener listens to. 

80 if ssl=0

443 if ssl>0 

ssl 

SSL level of the receiving HTTP listener uses. 

wallet 

Full path name of wallet file used by the servlet. 

 

passwd 

Password applied to the wallet file used by the servlet. 

 

proxyHost 

Host name of the proxy server for the servlet. 

 

proxyPort 

Port number of the proxy server for the servlet. 

 

You can access the servlet through a browser to check if the HTTP propagation servlet is installed and setup correctly. The servlet tries to connect to the receiving broker to obtain the propagation version number, upon receiving a request from the browser. The receiving broker and its HTTP listener must be running for this test to run successfully.

Propagation Security

The Oracle message Broker supports the SSL protocol to secure propagation connections. Table 8-4 shows the SSL levels that an Oracle Message Broker administrator can specify for propagation.

Table 8-4 SSL Levels Supported for Propagation
SSL Level  Description 

This specifies no authentication and no encryption on both the sending and the receiving sides. This is the default SSL level. 

This level specifies only encryption on both sending and receiving sides. 

This level specifies encryption and receiving side authentication. 

This level specifies authentication and encryption on both the sending and the receiving sides. 

Keep the following points in mind when configuring SSL for propagation:

In summary, if the sending broker uses SSL level 3 and receiving broker uses SSL level 2, the SSL connection is established using SSL level 2. If the sending broker uses SSL level 2 and the receiving broker uses SSL level 3, the SSL connection is established at SSL level 3 (see "Propagation Limitations" for information additional limitations).

IIOP propagation Security

If a receiving broker is SSL enabled, it requires that connections from sending brokers be secured using SSL. See "Oracle Message Broker SSL Options" for information on enabling SSL. On the propagation sending side, users specify SSL information, including the SSL level, wallet location, and wallet password, in the remote directories entry associated with propagation jobs that send messages to the SSL enabled receiving broker (see Table 4-19 for details on the remote directories entry).

To prevent unauthorized propagation, the administrator can protect the receiving broker. When starting a propagation job, the sending broker retrieves information from the receiving broker's directory entry to allow the sending broker to contact the receiving broker. The receiving side protects the LDAP Directory entries using LDAP Directory access control, which allows only authorized users with valid passwords access to the directory entries. At the sending side, a valid username and password must be provided in the remote directories entry for a propagation job to access a protected LDAP Directory (see Table 4-19 for details on the remote directories entry). Correct SSL information, including the SSL level, wallet location and wallet password must be included in the remote directories entry if the LDAP Directory is SSL enabled.

HTTP Propagation Security

The Oracle message Broker supports the SSL protocol to secure HTTPS propagation. This section covers the following:

Enabling SSL on the Receiving Broker

Enable the HTTP Propagation security features using attributes in the prop_http entry under the msg_broker entry on the receiving broker (see Table 4-15 for the list of attributes). To enable SSL for a receiving broker, configure the built-in HTTP listener with a SSL level using a value greater than 0. When the SSL level is set to a value greater than 1, you need to include the proper wallet information (the wallet location and password).

Enabling SSL on the Sending Broker

Enable the HTTP Propagation security features on the sending broker using attributes in the RemoteHTTPListener entry associated with a propagation job (see Table 4-20 for the list of propagation job attributes). In order for a sending broker to process a propagation job whose receiving broker is SSL enabled, the associated remote HTTP listener entry of the propagation job must be set properly. The sending broker and the receiving broker negotiate SSL options, using the attributes specified in the remote HTTP listener entry on the sending side and the built-in HTTP listener SSL settings on the receiving side (see Table 4-15 for the list of prop_http attributes).

Enabling SSL for Servlet Based Propagation

For servlet based HTTP propagation, there are two HTTP connections (or two HTTPS connections, see Figure 8-6). In order to secure the HTTP connection between the sending broker and the HTTP propagation servlet, the web server must be SSL enabled, and the remote HTTP listener entry at the sending side that represents the propagation servlet must be set properly with respect to the web server's SSL configuration. That is, the SSL level in the remote HTTP listener entry must be set properly to correspond with the level in the web server, and the wallet must be valid with common trust points with that of the web server. In order to secure the HTTP connection between the servlet and the receiving broker, the receiving broker must be SSL enabled and the servlet must set its initial parameters (SSL, wallet, passwd) properly with respect to the SSL setting of the receiving broker.

Propagation Control

This section covers the following:

Creating and Deleting Propagation Jobs

Propagation jobs can be created and deleted with the Oracle Message Broker running or shutdown. When a propagation job is created, if the source destination of the job is a topic, the propagation manager creates a durable subscriber on the topic, regardless of whether the Oracle Message Broker is running or whether the propagation job is activated. The durable subscriber does not have corresponding entries in the LDAP directory (as a user-created durable subscriber would). The durable subscriber is deleted when the associated propagation job is deleted.

When deleting a propagation job, first deactivate the propagation job. You are not allowed to delete an activated propagation job.

Before deleting a propagation job, first check the message log to make sure that there are no uncommitted propagation requests for the propagation job (see "Activating and Deactivating a Propagation Jobs" for details). Deleting a propagation job with uncommitted propagation requests may leave messages in the source destination and the target destination, since the propagation manager only removes propagation jobs from the source destination as the last step before the propagation manager's actions are committed.

In order to avoid uncommitted requests, you can activate and deactivate the propagation job. Repeat this process until there are no more log messages indicating that there are uncommitted propagation requests for the propagation job.

It is possible that creating or deleting a propagation job may fail. This could leave the propagation job in invalid state. A propagation job in invalid state may cause unnecessary message accumulation if the job has a topic as its propagation source. Propagation jobs in invalid state should be deleted.

Activating and Deactivating a Propagation Jobs

The Oracle Message Broker administrator activates and deactivates a propagation job by setting the attribute activation_state in the propagation job entry. To activate a propagation job, set the attribute to true. To deactivate a propagation job, set the attribute to false (see Table 4-21 for a list of the propagation job attributes).

Activating a propagation job means the propagation manager can start processing the propagation job, and the sending broker starts sending messages to the receiving broker. Deactivating a propagation job means stopping to process the propagation job, the sending broker stops sending messages to the receiving broker. For a propagation job with a topic as propagation source, deactivating the propagation job stops only sending, not subscribing. Messages published to the topic when the job is deactivated will be sent to the receiving broker once the job is activated again.

When a propagation job is being deactivated, the propagation manager attempts, for up to ten(10) seconds to complete uncommitted propagation requests for the propagation job. If the propagation manager cannot complete the requests, for example if the receiving broker is down, it writes a message to the Oracle Message Broker log file, in the format:

There are [ number ] uncommitted propagation requests for [job id]. 

Followed by a message similar to the following deactivated message:

propagation job [ job id ] has been deactivated. 


Note:

If uncommitted requests exist and a propagation job is deleted, the uncommitted requests will never be completed. This may cause duplicated messages if a user later tries to recreate the same propagation job. 


Error Handling and Recovery

When starting the Oracle Message Broker, administrators should pay a close attention to the Oracle Message Broker message log file. Check to see that propagation manager and any propagation jobs start successfully. For example, check to see if HTTP listeners start successfully for a receiving broker, and if propagation jobs are activated successfully for a sending broker.

When the propagation manager encounters failures, it stops the related propagation job and writes log messages into the Oracle Message Broker log file. A log message in the log file for the sending broker, in the following form indicates that some failures occurred when processing the propagation job:

 propagation job [ job id ] has been stopped.

The propagation manager attempts to restart and recover failed propagation jobs once every two minutes, until it successfully recovers the jobs or the propagation job is deactivated.

Propagation Limitations

This section lists several limitations that apply for propagation, and for configuring propagation.

  1. replyTo Limitation - If a client receives a message that was propagated from a remote queue by a foreign Oracle Message Broker, and the client tries to reply using the replyTo destination found in the message header, the following restriction applies:

    When the replyTo destination is not a local destination for the client, the Oracle Message Broker throws the exception: java.jms.InvalidDestinationException

  2. Looped Propagation Jobs Limitation - looped propagation jobs, where there is a chain of propagation jobs, with a target in the chain pointing back to a source, are not detected by Oracle Message Broker. When and if propagation jobs are setup in a loop, messages will be transferred in an infinite loop. This behavior is also true for a single propagation job where the source and the target are the same destination. It is the Oracle Message Broker Administrator's responsibility to avoid creating looped propagation jobs.

  3. Propagation is not supported for Oracle Message Brokers running in local mode.

  4. Propagation is not supported for Oracle Message Brokers using lightweight configuration.

  5. Propagation logging queues restriction. The propagation logging queues are used internally by the propagation manager. Client applications should never use these queues. Using either the propagation sending log queue or the propagation receiving log queue may result in unrecoverable propagation failures.

  6. If an administrator specifies a mismatch between the security SSL setting for a propagation job on the sending broker and the receiving broker, the mismatch may cause propagation threads to hang when the propagation job is processed. This can occur when the SSL level is set to 1, 2, or 3, on the sending broker and the security SSL level for the associated HTTP listener on the receiving broker is set to 0 (non-SSL).

  7. HTTP propagation does not support HTTP request redirect.


Go to previous page Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index