31 Using the JMS Transport
This chapter provides an overview of the JMS transport and describes how to use and configure it in your Service Bus services. It also describes features and concepts related to interoperability between Service Bus and WebLogic JMS and between Service Bus and WebSphere MQ.
This chapter includes the following sections:
31.1 Introduction to the JMS Transport
The JMS transport lets you send and receive messages from JMS queues and topics of a JMS service.
You enqueue messages when you configure a business service to use the JMS transport, and you read (or poll) messages when you configure a proxy service to use the JMS transport. The JMS queues or topics can reside in a local WebLogic Server or on a remote server.
JMS is a standard API for accessing enterprise messaging systems. For an overview and features of WebLogic JMS, see Overview of JMS and WebLogic Server in Administering JMS Resources for Oracle WebLogic Server.
31.1.1 JMS Content Type for Services
To support interoperability with heterogeneous endpoints, Service Bus allows you to control the content type used, the JMS type used, and the encoding used when configuring message flows. The JMS type can be byte or text for non-Java-type messages. For more information, see Content Types, JMS Type, and Encoding.
31.1.3 Asynchronous Request-Response Messaging
Messaging can be one-way, synchronous request-response, or asynchronous request-response. However, messaging over JMS is only one-way or is asynchronous request-response. Asynchronous request-response messaging using JMS is an alternative to messaging using HTTP or HTTP(S).
Using asynchronous request-response messaging has the following advantages:
-
The request thread does not get blocked while waiting for the response. This removes a thread management issue that can occur when numerous blocking request-response invocations are made. However, HTTP and HTTP(S) support a nonblocking mode of operation.
-
The messaging is more reliable than HTTP because it can be:
-
Persisted on disk
-
Queued when the service is not available
-
Re-delivered if the server has an error or fails when the message is being processed
-
Transactional
-
For IBM WebSphere MQ, asynchronous request-response messages may be the best approach for interacting with some mainframes. The asynchronous service must echo the correlation ID or the message ID depending on the JMS request-response pattern that you use. The format of either ID used by Service Bus is compatible with IBM WebSphere MQ and with target services that use MQ native interfaces. For more information, see Message ID and Correlation ID Patterns for JMS Request/Response.
Asynchronous request-response messages are handled by the outbound and inbound transports. That is, the message flow, except for the $outbound
and $inbound
transport specific data, does not distinguish between JMS request-response and HTTP request-response.
Service Bus supports bridging between synchronous and asynchronous request and response. For example, a proxy service can be invoked using HTTP, and the proxy service routes to a JMS request-response business service. This is called synchronous-to-asynchronous service switching.
31.1.4 Sending and Receiving Java Objects in Messages
You can directly send Java Objects using the JMS transport. To enable Java Object support in the request or response, create a proxy or business service of type Messaging Service, and select Java on the Messaging page for the request or response, depending on whether you are sending or receiving the Java Objects through Service Bus.
Dequeuing a Java object message from the JMS destination involves de-serializing the Java object. For this to work, you must package the Java classes for the Java objects that are to be dequeued into a JAR file and import the JAR into your Service Bus project. Then, in the JMS transport-specific configuration page for a service, select the JAR in the Client Jar field. The Client Jar field is available in JMS proxy services when you select Java as the message type for the request, and in business services when you select Java as the message type for the response.
Java Objects in Service Bus are stored in the pipeline object repository and referenced in the SOAP body by a <java-content ref="jcid" />
element and attribute, where jcid is the key to the object in the object repository. If a Java Object is null, the object is represented in the pipeline as ref="jcid:null"
.
Only one Java Object is allowed in each message. For Java-type message types, Service Bus does not support large messages (content streaming) or testing Java-type services in the Test Console.
31.1.5 Required JMS Resources
In addition to configuring JMS file stores in the Oracle Fusion Middleware Configuration Wizard, proxy services and business services that use JMS require configuration of the following resources:
-
JMS connection factories. You must configure XA or non-XA JMS connection factories for all business services and proxy services implemented using JMS.
-
JMS queues/topics. Service Bus automatically configures JMS queues for proxy services that are implemented using JMS. You must configure JMS queues/topics for all business services using JMS and for any proxy services that are implemented using non- JMS.
If you want to concentrate all Service Bus JMS resources in a single JMS module, use the Oracle WebLogic Server Administration Console to create a new JMS module containing the destination to be used for the proxy services' endpoint. For more information about configuring JMS resources, see "Methods for Configuring JMS Resources" in the Administering JMS Resources for Oracle WebLogic Server.
31.1.6 Large Payload Rejection with JMS Transport
Payloads over the default of 10MB are rejected for inbound messages under the JMS transport in a Reference Configuration domain.
If the threshold is exceeded in a Reference Configuration domain, the transport
dequeues and redirects the message to the preconfigured dead letter queue
ha_jms_dead_letter_queue
.
The rejection limit is controlled by the -Dsoa.payload.threshold.kb
parameter. The default is 10MB.
The JMS messages in the dead letter queue contain the proxy name and the URL as a key value pair in the JMS header. You can use this information to submit the rejected messages to the respective proxy again by applying the filter criteria if needed. To remove the rejected messages from the dead letter queue, a cleanup script, soaJMSCleanup.py
, is available in $ORACLE_HOME/soa/common/tools/refconfig
.
31.1.7 Platform Interoperability
The following sections provide information and links for interoperability with different JMS platforms.
31.1.7.1 Interoperability with WebLogic JMS
For information about WebLogic Server JMS, see the following topics:
-
"Managing Your Applications" in Developing JMS Applications for Oracle WebLogic Server
-
Configure JMS Servers in the Oracle WebLogic Server Administration Console Online Help.
Note:
Service Bus supports the MQ Extended Transactional Client, which is vital for remote transactional support configuration.
31.1.7.2 Interoperability with WebSphere MQ
Service Bus connects to WebSphere MQ through the WebSphere MQ JMS interface, so Service Bus is a WebSphere MQ JMS client. WebSphere MQ can interface with Service Bus in the following ways:
-
Service Bus acts as the front-end of WebSphere MQ to accept service requests from other applications and converts them to WebSphere MQ requests.
-
WebSphere MQ sends messages to other applications through Service Bus.
For more information, see Using the WebSphere MQ JMS Interface.
31.2 Using SOAP Over JMS Transport
You can use JMS for SOAP transport instead of HTTP, because SOAP is transport-agnostic.
Service Bus supports SOAP messages with JMS request-response, and supports interoperability with WebLogic Server SOAP-based clients and services. JMS is also an approach for reliable messaging.
31.2.1 Interoperating with WebLogic Server
When you configure JMS resources in WebLogic Server, you use the following SOAP-JMS URI format in WebLogic Server:
jms://host:port/contextURI/serviceName?URI=destJndiName
When you configure the service in Service Bus, the URI must have the following format:
jms://host:port/connection_factory/jndi_destination
Both formats use the same jndi_destination
. The jndi_destination
must be the JNDI name of an existing QueueConnectionFactory in the target WebLogic Server. For more information, see "WebLogic Server Messaging" in Understanding Oracle WebLogic Server. This document provides an overview of JMS and links to more information.
Note:
While WebLogic Server allows forward slashes in JNDI names, such as "myqueues/myqueue", JNDI names with forward slashes interfere with the URI format required by Service Bus, and you cannot use those names. To work around this issue, define a JMS foreign server and reference that foreign server in the URI. For more information, see Configure Foreign Servers in the Oracle WebLogic Server Administration Console Online Help.
When you invoke WebLogic Server services from Service Bus, you must set the URI as a JMS property with the value as /contextURI/serviceName
in the pipeline on the outbound variable ($outbound
) before a request is sent to the business service. Use the Transport Headers action to set this property. For information about setting $outbound
, see Inbound and Outbound Variables.
When a WebLogic Server web services client invokes a Service Bus proxy service, the URI property is ignored. However, it can be passed through to an invoked service using the pass through options of the Transport Headers action. For more information, see Adding Transport Header Actions in the Console.
Service Bus can only invoke Oracle WebLogic request-response services running on version 9.2 or later. However, it can also invoke one-way JMS services.
31.2.2 Configuring the Response Queues for Cross-Domain JMS Calls
When you configure the response queue for cross-domain JMS calls, make sure that there is a separate response queue corresponding to each requesting Managed Server.
For example, two Service Bus clustered domains (domain A and domain B) are communicating with a WebLogic Server domain that has two Managed Servers. Domain A has three Managed Servers and domain B has four Managed Servers. You need to configure seven distinct queues to serve as response queues (3 + 4 = 7) on the WebLogic Server domain for sending responses back to domain A and domain B. These seven queues could be distributed queues (with members on both the Managed Servers of the WebLogic Server domain).
Note:
When the JMS requests come from multiple proxy services hosted by different remote domains, you must configure the back-end domain hosting the JMS business service with the separate sets of response queues corresponding to each requesting domain.
31.3 Naming Guidelines for Domains, Servers, and URIs
If you are working with more than one domain, make sure that your configuration conforms to these requirements.
-
WebLogic Server instances and domain names are unique.
-
WebLogic JMS server names are unique across domains.
-
If a JMS file store is being used for persistent messages, the JMS file store name must be unique across domains.
31.3.1 JMS Server Names
Note the following rules for JMS Server names:
-
You cannot have duplicate JMS server names within the same domain. If you do, when messages are sent to a destination at a particular JMS server,Service Bus cannot determine the server to which the message should be sent.
-
If you use Store and Forward (SAF), duplicate JMS Server names in different domains do not pose a problem.
-
In the case of cross-domain communication, duplicate JMS server names can be a problem when you use the
ReplyTo
function. TheReplyTo
message sent from a given domain is returned to the JMS server on the same domain that received the message instead of being returned to the domain that sent the original message.
For more information on how to configure and manage WebLogic JMS:
-
"Managing Your Applications" in Developing JMS Applications for Oracle WebLogic Server
-
Configure JMS Servers in the Oracle WebLogic Server Administration Console Online Help.
31.3.2 JNDI Names and Service Bus
While Oracle WebLogic Server allows forward slashes in JNDI names, such as "myqueues/myqueue", JNDI names with forward slashes interfere with the endpoint URI format required by Service Bus, and you cannot use those names. To work around this issue, define a JMS foreign server and reference that foreign server in the endpoint URI. For more information, see Configure Foreign Servers in the Oracle WebLogic Server Administration Console Online Help.
31.4 JMS Client ID in Proxy Services
The JMS client ID in a proxy service is the jms-client-id
descriptor value, which is used to generate subscriber names and the client ID value for the topic's subscribers.
When you configure a JMS proxy service with a topic destination, you can specify the JMS client ID to use when generating subscriber names and the subscriber client ID. This makes it easier to identify the subscriber and its corresponding proxy service when monitoring and managing the service and topic at runtime. Note that this is only effective for durable subscriptions.
31.4.1 About the Client ID and Subscriber Name
A subscription for a topic destination can be identified by the client ID and subscriber name. These values are generated for different TopicMessagesDistribution
configurations using the following descriptors.
-
jms-client-id
: The value configured for the JMS Client ID property on a JMS proxy service targeted to a topic destination. -
ejb-name
: The name of the MDB generated by Service Bus for the proxy service. This is a unique ID value. -
DomainName
: The name of the Service Bus domain. -
ServerName
: The name of the runtime Service Bus server. -
UniqueKey
: The unique key generated by WebLogic Server when thegenerate-unique-client-id
descriptor is set to true. Thegenerate-unique-client-id
descriptor is always set to true for MDBs deployed by JMS proxy services.
The following table shows how the subscriber client ID and name are generated for different distribution modes.
Topic Messages Distribution | Subscriber Client ID | Subscriber Name |
---|---|---|
One Copy Per Application |
jms-client-id |
ejb-name |
One Copy Per Server |
{jms-client-id}_{DomainName}_{ServerName} |
ejb-name |
Compatibility |
{jms-client-id}_{DomainName}_{ServerName}_{UniqueKey} |
Same as client ID |
Additional descriptors affect the subscriber client ID. The distributed-destination-connection
descriptor is always set to local, and the generate-unique-client-id
descriptor is always set the true. For more information, see "Topic Subscription Identifiers" in Programming Message-Driven Beans for Oracle WebLogic Server.
31.4.2 Recommended Usage
It is not recommended to use the Topic Messages Distribution
mode of Compatibility
. Instead, use either One Copy Per Application
or One Copy Per Server
for better scalability (depending on your requirements). Compatibility mode is provided primarily for backward compatibility, and is typically used for durable subscriptions where cleanup activity might be done on topic subscribers related to a specific proxy service.
31.5 JMS Transport Error Handling
Configure JMS-transport business services to handle application and communications errors as described in this section.
31.5.1 Application Errors
You can specify whether or not to retry business service endpoint URIs when application errors occur. For more information, see "Managing and Monitoring Endpoint URIs for Business Services" in Administering Oracle Service Bus.
An application error occurs when for a JMS business service configured with request/response, the System.getProperty("com.bea.wli.sb.transports.jms.ErrorPropertyName", "SERVER_ERROR")
property is true
in the response message. In this scenario, the JMS transport provider calls the error method with the TRANSPORT_ERROR_APPLICATION
error code.
31.5.2 Communication Errors
You can configure business service URIs to be taken offline when such communication errors occur. When you configure the operational settings for the business service, you can enable the business service endpoint URIs to be taken offline after the specified retry interval. For more information, see "Managing and Monitoring Endpoint URIs for Business Services" in Administering Oracle Service Bus.
Connection errors occur when any JMS exceptions or naming exceptions occur during any of the following activities:
-
Looking up a JMS connection factory.
-
Creating a JMS connection from a JMS connection factory.
-
Creating a JMS session using a connection object.
-
Looking up of a JMS destination.
-
Creating a sender from the session object.
-
Sending a JMS message using the sender and destination object.
31.5.3 Pipeline Exceptions with Java Objects
After an exception occurs in a JMS proxy service, such as while routing a Java Object message to a business service or to a Java Callout, the message payload must be properly formed so that the proxy service can access the exception instance and return it to the calling client. Make sure the payload conforms to the following format:
<soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <ctx:java-content ref="key1" xmlns:ctx="http://www.bea.com/wli/sb/context" /> </soap:Body>
where key1 is the key to the Java Object in the object repository. If the payload is not in this format, the pipeline passes a null payload to the inbound JMS transport.
Using an Error Handler
You can catch pipeline errors involving Java Objects using an error handler. The $fault
variable in the error handler contains the reference to the exception instance ("java-exception" element).
In situations where the $fault
variable does not contain a reference to the exception instance, you can use a Java Callout within the error handler that uses the available $fault
information to generate an exception instance in the previously described $body payload format. You must use a Reply with Failure action so that the $body is made available as the payload to the inbound JMS transport.
31.6 WSDL-Defined SOAP Fault Messages
When consuming a WSDL file that explicitly defines a fault, the WebLogic clientgen tool generates a subclass of java.lang.Exception
for the XML fault type.
When the WebLogic Server JAX-RPC stack inspects a SOAP response message and determines that the response message contains a SOAP fault, it tries to map the fault to a clientgen-generated exception Java class.
For example, if a WSDL file contains the definitions shown in the following listing, the clientgen tool generates a Java class com.bea.test.TheFaultType
that extends java.lang.Exception
. A JAX-RPC client can catch com.bea.test.TheFaultType
when invoking the related method of the service stub.
Example - Sample WSDL Definitions
<definitions ... xmlns:s0="http://www.oracle.com/test/"> ... <types> <xsd:schema targetNamespace="http://www.oracle.com/test/"> ... <xsd:complexType name="theFaultType"> <xsd:sequence> <xsd:element name="ID" type="xsd:int" /> <xsd:element name="message" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:element name="theFault" type="theFaultType" /> </xsd:schema> </types> ... <message name="theFaultMessage"> <part element="s0:theFaultPart" name="theFault" /> </message> ... <binding ...> <operation ...> <soap:operation soapAction="..." style="document" /> <input ...> ... </input> <output ...> ... </output> <fault ...> <soap:fault name="theFaultPart" use="literal" /> </fault> </operation> </binding> ... </definitions>
The SOAP message must contain a fault of the correct format so the JAX-RPC stack throws the correct exception. See Adding a Fault in a SOAP Message if the Fault is Constructed from inside a Service Bus Pipeline for details.
31.6.1 Adding a Fault in a SOAP Message if the Fault is Constructed from inside a Service Bus Pipeline
The SOAP message must contain a fault of the correct format so the JAX-RPC stack throws the correct exception.
If the fault is constructed from inside a Service Bus pipeline, you must do the following:
For information about configuring reply actions, see Adding Reply Actions in the Console.
The clientgen tool is used to generate the client-side artifacts, such as the JAX-RPC stubs, needed to invoke a web service. See "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.
31.7 Message ID and Correlation ID Patterns for JMS Request/Response
This section describes the Message ID and Correlation ID patterns supported in Service Bus for JMS request-response. It also describes how Service Bus uses these patterns to interoperate with Java API for Remote Procedure Call (JAX-RPC) web services. Examples are also provided.
31.7.1 Overview of JMS Request-Response and Design Patterns
Messaging provides high-speed, asynchronous, program-to-program communication with guaranteed delivery and is often implemented as a layer of software called Message Oriented Middleware (MOM). In enterprise computing, messaging makes communication between processes reliable, even when the processes and the connection between them are not so reliable. Processes may need to communicate for the following reasons:
-
One process has data that needs to be transmitted to another process.
-
One process needs to remotely invoke a procedure in another process.
Asynchronous request-response messaging is the best approach to interacting with some mainframes if you are using IBM WebSphere MQ.
In cluster domains and request-response scenarios, JMS Transport deploys the MDBs to individual managed servers of the cluster. But in dynamic cluster domains, because a dynamic server cannot be individually targeted for any application, JMS Transport can only deploy the MDBs to a configured managed server for a request-response scenario. For more information about this limitation of dynamic clusters, see Limitations and Considerations When Using Dynamic Clusters in the Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server guide.
31.7.1.1 Patterns for Messaging
Messaging patterns describe the format of messages that flow between parts of a system built with a MOM. There are several types of messages as described below:
-
A Command Message enables procedure call semantics to be executed in a messaging system.
-
A Document Message enables a messaging system to transport information, such as the information that should be returned to a sender as a result of a command message.
-
An Event Message uses messaging to perform event notification.
-
A Reply Message handles the semantics of remote procedure call results, that require the ability to handle both successful and unsuccessful outcomes.
-
A Reply Specifier enables a program making a request to identify the channel through which a reply should be sent.
-
A Correlation Identifier enables a requesting program to associate a specific response with its request. When the data to be conveyed spans several messages, a Sequence Identifier enables the receiver to accurately reconstruct the original data.
-
Message Expiration enables a sender to set a deadline by which the message should either be delivered or ignored.
-
Message Throttle enables a receiver to control the rate at which it receives messages.
In the case of Service Bus, each reply message should contain a unique identifier called the correlation ID, which correlates the request message and its reply.
When the caller creates a request message, it assigns a unique identifier to the request that is different from those for all other currently outstanding requests (for example, requests that do not yet have replies). When the receiver processes the request, it saves the identifier and adds the request's identifier to the reply. When the caller processes the reply, it uses the request identifier to correlate the request with the reply. This is called a correlation identifier because of the way the caller uses the identifier to correlate each reply with the request.
A correlation ID is usually put in the header of a message. The ID is not a part of the command or data the caller is trying to communicate to the receiver. The receiver saves the ID from the request and adds it to the reply for the caller's benefit. Since the message body is the content being transmitted between the two systems and the ID is not a part of that, the ID is added to the header. In the request message, the ID can be stored as a correlation ID property or simply a message ID property. When used as a correlation ID, this can cause confusion about which message is the request and which is the reply. If a request has a message ID but no correlation ID, then a reply has a correlation ID that is the same as the request's message ID. The correlation ID format used internally by Service Bus is compatible with WebSphere MQ and works with target services that are using MQ native interfaces.
The outbound transport handles asynchronous request-response messages. That is, the pipeline, except for the $outbound
transport specific data, does not distinguish between JMS request-response and HTTP request-response.
When you define a JMS request-response business or proxy service, you must first choose a design pattern. To do this, select the Is Response Required option for a JMS proxy service or a Response Queues option for a JMS business service, then select one of the following correlation patterns on the JMS Transport Configuration page:
-
JMS Correlation ID (this is the default pattern)
-
JMS Message ID
Note:
JMS request-response messaging does not have reliable responses because the mapping of the correlationID to the proxy service is stored in memory. If there is a failure or system restart between sending the request and receiving the response, the response is discarded.
To work around that situation, instead of using JMS request-response, use two one-way JMS proxy services: one for delivering the message and a second for delivering the response.
The following sections discuss these patterns. To compare the two patterns, see Comparison of Message ID and Correlation ID Patterns.
31.7.2 JMS Message ID Pattern
When you create a business service using the JMS Message ID pattern, you can configure the responses to go to a single URI, or, for failover support, you can configure a response queue for each request URI on each Managed Server in the Service Bus cluster. These queues must be collocated with the request queues for the service. The proxy service uses this information to set the JMSReplyTo
property when invoking the business service so the response is processed by the Managed Server that issued the request.
When you define a proxy service using the JMS Message ID pattern, you do not need to define the Response URI
because the proxy service replies to the queue specified in the JMSReplyTo
property. However, you can enter the JNDI name of the JMS connection factory for the response message. The JMSReplyTo
property is accessible through the transport metadata, as described in Access to the JMSReplyTo Property.
Note:
By default, the connection factory of the request message is used. This is useful when you use a non-XA connection factory for JMS responses, but have an XA connection factory for the request.
For the deployment descriptors to be set appropriately for XA-capable resources, you must set the XA attribute on the referenced connection factory before creating a proxy service.
The invoked service must copy the message ID from the request (the value of the JMS header field JMSMessageID
) to the correlation ID of the response (setting the JMS header field JMSCorrelationID
). In addition, the invoked service must reply to the queue specified in the JMSReplyTo
header field. If you choose the JMS Message ID Pattern, the response arrives at the appropriate managed node.
Note:
The JMS Message ID correlation pattern is not supported when a proxy service invokes another proxy service.
31.7.2.1 Access to the JMSReplyTo Property
For JMS proxy services, the JMSReplyTo
property in the incoming message is stored as a Java object in a JMS transport metadata element, also named JMSReplyTo
. The value of the metadata element in the outbound request can be passed to the business service, supporting dynamic "reply to" destinations. In the pipeline, you can pass this value to a Java callout action for transformation. If a JMS proxy service invokes a JMS business service directly, with no pipeline, the JMS transport metadata is passed automatically to the business service. If the proxy service does invoke a pipeline, you need to configure the pipeline to copy the header from the inbound message and to set it in the outbound request header.
Note that in the first case, where the JMS business service is invoked directly with no pipeline, the consumer listening on this queue reads the JMSReplyTo
header and also sends the message to the destination in the header. This means that two messages are written to the queue. To avoid this, use a pipeline between the services.
For request-response proxy services, the JMSReplyTo
metadata element is only set when the correlation pattern is Message ID. When the pattern is Correlation ID, the proxy service determines the JMSReplyTo
value from the transport configuration, so it is not set in the metadata element.
Note:
The JMSReplyTo
metadata element does not appear in the Test Console because the element contains a java-content
representation of a Java object.
31.7.2.2 JMS Message ID Pattern in a Cluster
A JMS proxy service using this pattern can be used in a cluster without further configuration. A JMS business service is available in a cluster. However, when a Managed Server is added to the cluster, all the business services become invalid. To correct this, ensure that the number of response queues equals the number of Managed Servers that specify the JMS Message ID correlation pattern in the Service Bus cluster.
31.7.3 JMS Correlation ID Pattern
When you design a business service in Java, make sure that you set the value of JMS Correlation ID on the response to the value of JMS Correlation ID on the request before sending the JMS response to a queue. You can obtain the JMS Correlation ID when you receive a message using the following method:
String getJMSCorrelationID()
The above method returns correlation ID values as Strings that provide specific message IDs or application-specific values.
To set the JMS Correlation ID when you send a message:
void setJMSCorrelationID(String correlationID)
31.7.4 Comparison of Message ID and Correlation ID Patterns
The JMS request-response patterns differ in the following ways:
-
The method by which the response is correlated with the request
-
The choice of the response queue
The differences between these two patterns are summarized in Table 31-1.
Table 31-1 Differences Between Message ID and Correlation ID Patterns
JMS Pattern Name | Response Queue | CorrelationID |
---|---|---|
Correlation ID Pattern |
All responses go to the same fixed queue(s). |
The server copies the request Correlation ID to the response Correlation ID. |
Message ID Pattern |
The responses dynamically go to the queue indicated by the |
The server copies the request Message ID to the response Correlation ID. |
When the Correlation ID pattern is used, the service that is invoked replies to the queue that corresponds to the request URI. The response always arrives on the same queue and the client has no control over the queue to which the response arrives. For example, if 10 clients send a message to request URI "A", they all get the response to the queue that corresponds with request URI "A". Therefore, clients must filter the messages in the response queue to select the ones that pertain to them. Filtering criteria are configured in the request message Correlation ID property, and the server is configured to echo this to the response Correlation ID property.
In the case of Message ID pattern, the client's JMSReplyTo
property tells the server where the response should be sent. This queue is specific to the client's server, so responses to different clients will go to different queues. The server sets the JMS Correlation ID of the response to the JMS Message ID of the request.
Correlation by MessageID is commonly used by many IBM MQ applications as well as JMS applications and is the standard method to correlate request and response.
If you have multiple Oracle WebLogic client domains invoking a target Oracle WebLogic domain using JMS request-response with the Message ID pattern, you can set up both the request and response queues as SAF queues. However, this is not possible with the Correlation ID pattern that uses a single queue for all the responses for a given request URI.
The Correlation ID pattern has two major advantages:
-
The response queue configuration is simple and it need not change every time a new Managed Server is added to the cluster.
-
Correlation ID can also be used in cases where a proxy service in the domain needs to invoke another proxy service in the same domain.
31.7.5 Interoperating with JAX-RPC Over JMS
The Service Bus development environment lets you create JAX-RPC web services that use the JMS transport, in addition to HTTP-HTTPS. These JMS transport JAX-RPC web services use a JMS queue as the mechanism for retrieving and returning values associated with operations. You can use the JMS Message ID pattern to invoke a JMS transport JAX-RPC web service.
You can also invoke a JMS request-response proxy service from a JAX-RPC static stub, which the Oracle WebLogic clientgen Ant task generates.
31.7.5.1 Invoking a JAX-RPC Web Service Using the JMS Message ID Pattern
To invoke a JMS transport JAX-RPC web service using the JMS Message ID pattern, complete the following steps:
-
Create a JMS Request-Response business service that uses the JMS Message ID pattern to invoke the JMS transport JAX-RPC web service. For more information, see the online help provided with Service Bus.
This business service uses JMS transport. The JMS queue JNDI name portion of the endpoint URI must be the same as the queue attribute specified in the
@WLJmsTransport
annotation of the JMS transport JAX-RPC web service. For example:jms://localhost:7001/AJMSConnectionFactoryJNDIName/JmsTransportServiceRequestQueue
The JNDI name of the JMS queue (or queues) assigned to the Destination field must be associated with a JMS server targeted at the WebLogic Server name that is displayed in the Target field.
Note:
While WebLogic Server allows forward slashes in JNDI names, such as "myqueues/myqueue", JNDI names with forward slashes interfere with the URI format required by Service Bus, and you cannot use those names. To work around this issue, define a JMS foreign server and reference that foreign server in the URI. For more information, see Configure Foreign Servers in the Oracle WebLogic Server Administration Console Online Help.
-
Create a proxy service that contains a Routing (or Service Callout) action to the JMS Request/Response business service that you created in step 1.
The Request Actions area of the Routing action must contain a
Set Transport Headers
action for the outbound request. When you configure the Transport Headers action, you must add two JMS headers for the outbound request action. For detailed instructions about how to configure a Transport Headers action, see Adding Transport Header Actions in the Console.In brief:
-
Configure a Transport Headers Action by selecting Other in the Add Header field and entering a URI in the field provided.
-
Select Set Header to <Expression> and create the expression by entering a concatenation of the values specified for the
contextPath
andserviceUri
attributes (in the@WLJmsTransport
annotation of the JMS transport JAX-RPC web service), preceded by a forward-slash. For example, you have the following@WLJmsTransport
annotation:@WLJmsTransport( contextPath="transports", serviceUri="JmsTransportService", portName="JmsTransportPort", queue="JmsTransportServiceRequestQueue" )
You would enter the following expression in the XQuery Text input area when you configure the Transport Headers:
/transports/JmsTransportService
-
To specify the second JMS Header, select Other in the Add Header field again, and enter
_wls_mimehdrContent_Type
in the associated field. -
Select Set Header to <Expression> and enter
text/xml; charset=UTF-8
in the XQuery Text input area.
-
31.7.5.2 Invoking a JMS Request-Response Proxy Service from a JAX-RPC Client
For a scenario in which a JAX-RPC WebLogic Server client invokes a proxy service, set the _wls_mimehdrContent_Type JMS
header for the proxy service's inbound response and specify the header when you issue the response to the incoming JMS Message ID Pattern request.
For example, for the scenario in which you have a JAX-RPC client calling a proxy service, which subsequently calls a WebLogic Server web service, the route node configuration is as follows:
For the Request Pipeline
-
Set the transport header for web service context URI (for example:
interop/AllocJmsDocLit
). -
Set the transport header for
_wls_mimehdrContent_Type
withtext/xml; charset=UTF-8
. -
Select Outbound request from the Set Transport headers menu items.
-
Enable
Pass all Headers
through pipeline.
For the Response Pipeline
-
Add an empty transport header and select Inbound response from the Set Transport headers menu.
-
Enable
Pass all Headers
through pipeline.Note:
For instructions on configuring a Transport Headers action, see Adding Transport Header Actions in the Console.
31.7.6 JMS Message ID Pattern Examples
The following examples describe the different methods by which the JMS Message ID pattern can be used.
31.7.6.1 MQ Service Using a JMS Message ID to Correlate the Request-Response Message
In Figure 31-1, the server that hosts the MQ service in the request-response communication echoes the request message ID to the response correlation ID, and sends the response to the replyTo
queue. The response travels back and is correlated using the JMS MessageID. The Service Bus replyTo
destination is set, one per Service Bus node in a cluster, when the business service is configured. A JMS or MQ native client can also invoke a JMS request-reply proxy service using the JMS Message ID pattern. The client needs to set the replyTo
property to the queue where it expects the response.
The key to supporting this use case is that JMS Message ID is expected to correlate the request-response message. You also need to create as many MQ series outbound response queues as there are cluster servers.
Note:
The request and response are under different transactions. For any issues in the request or response, the transaction is rolled back.
Figure 31-1 MQ Service Using a JMS Message ID for Correlation
![Description of Figure 31-1 follows Description of Figure 31-1 follows](img/usecase1.gif)
Description of "Figure 31-1 MQ Service Using a JMS Message ID for Correlation"
31.7.6.2 JAX-RPC Client with a Proxy Service
Figure 31-2 represents a JAX-RPC client sending a message to a Service Bus proxy service, that is, the JAX-RPC inbound case. The JAX-RPC stack employs a temporary queue to receive the response. The JMS transport honors this temporary queue during runtime.
Figure 31-2 JAX-RPC Client with Service Bus Proxy Service
![Description of Figure 31-2 follows Description of Figure 31-2 follows](img/usecase2.gif)
Description of "Figure 31-2 JAX-RPC Client with Service Bus Proxy Service"
31.7.6.3 Service Bus as a Client of a WebLogic Server JAX-RPC Service
Figure 31-3 represents the JAX-RPC outbound case or the interoperability of a WebLogic Server JAX-RPC request/response service with a Service Bus proxy service.
Figure 31-3 Service Bus as a Client of a WebLogic Server JAX-RPC Service
![Description of Figure 31-3 follows Description of Figure 31-3 follows](img/usecase3.gif)
Description of "Figure 31-3 Service Bus as a Client of a WebLogic Server JAX-RPC Service"
Note:
When a proxy service in one WebLogic Server domain needs to send a message to a proxy service in a second domain, the message must first be routed to a pass-through business service in domain 1. JMS Store and Forward between domain 1 and domain 2 forwards the inbound request message to the proxy service in domain 2. When you use JMS request/response, you can choose to forward the inbound response message from domain 2 to domain 1 using JMS Store and Forward as well. In the latter case, exported inbound request and imported inbound response queues must be configured in domain 2 for the proxy service in domain 2. Pay close attention to the JMS Store and Forward configuration.
31.8 JMS Transport Configuration Reference
You can select JMS as the transport protocol for proxy and business services of any service type. This section describes the properties you can configure for the JMS transport for business and proxy services.
For information about error handling for business services, see JMS Transport Error Handling.
When you configure a proxy service, you can use a Transport Header action to set the header values in messages. For more information, see JMS Transport Headers.
31.8.1 JMS Transport Endpoint URIs
Enter the endpoint URI for the JMS transport in the following format:
jms://host:port[,host:port]*/connection_factory/jndi_destination
where
-
host
is the name of the system that hosts the service. -
port
is the port number at which the connection is made. -
[,host:port]*
indicates that you can configure multiple hosts with corresponding ports. -
connection_factory
is the name of the JNDI Connection Factory. For more information on how to define a connection factory queue, see Configure resources for JMS system modules in the Oracle WebLogic Server Administration Console Online Help. -
jndi_destination
is the name of the JNDI destination.
To target a JMS destination to multiple servers, use the following format for the URI:
jms://host1:port,host2:port/connection_factory/jndi_destination
where connection_factory
is the name of the connection factory queue. For more information on how to define a connection factory queue, see Configure resources for JMS system modules in the Oracle WebLogic Server Administration Console Online Help.
Note:
While WebLogic Server allows forward slashes in JNDI names, such as "myqueues/myqueue", JNDI names with forward slashes interfere with the URI format required by Service Bus, and you cannot use those names. To work around this issue, define a JMS foreign server and reference that foreign server in the URI. For more information, see Configure foreign servers in the Oracle WebLogic Server Administration Console Online Help.
31.8.2 Configuring Proxy Services to Use the JMS Transport
The following table describes the properties you use to configure a JMS-based proxy service. For more information, see Creating and Configuring Proxy Services.
Table 31-2 JMS Transport Properties for Proxy Services
Property | Description |
---|---|
Destination Type |
Select one of the following:
|
Is Response Required |
Select this option to specify that a response is expected after an outbound message is sent. This option is available only when the Destination Type is Queue. |
Response Pattern |
Select one of the following to specify the design pattern for the response:
This option is available only when the Is Response Required check box is selected. |
Response Message Type |
Select one of the following types for the response messages:
This option is disabled if you select a Message Type of Java for the response. It is available only when the Is Response Required check box is selected. |
Client Jar |
Select the client JAR to be used for dequeueing messages that contain Java Objects. Selecting the client JAR ensures it is on the classpath. This option is available when the service is a Messaging Service with a request type of Java. For more information, see Sending and Receiving Java Objects in Messages. |
Dispatch Policy |
Select the instance of WebLogic Server Work Manager that you want to use for the dispatch policy for this endpoint. The default Work Manager is used if no other Work Manager exists. For information about Work Managers, see:
|
Request Encoding |
Enter the character set for encoding requests. The default is |
Response Encoding |
Enter the character set for encoding responses. The default is This option is available only when the Is Response Required check box is selected. |
Client Response Timeout |
Enter the number of seconds to wait for a server response before dropping the connection. This only applies if the client is another proxy service in the same domain. This option is available only when the Is Response Required check box is selected. |
Response URI |
Enter a response URI in one of the formats described below. This option is available only when JMSCorrelationID is selected for the Response Pattern. jms://host:port/connection_factory/jndi_destination To target multiple servers, use the following format: jms://host1:port,host2:port/connection_factory/jndi_destination You can also omit the host and port in the response URI. For example: jms:///connection_factory/jndi_destination When you omit host and port, the connection factory/destination lookup occurs on the local server. This is useful, for example, if the request URI goes to a foreign connection factory/destination, but you want the response sent to the local server. Note: While WebLogic Server allows forward slashes in JNDI names, such as "myqueues/myqueue", JNDI names with forward slashes interfere with the URI format required by Service Bus, and you cannot use those names. To work around this issue, define a JMS foreign server and reference that foreign server in the URI. For more information, see Configure Foreign Servers in Oracle WebLogic Server Administration Console Online Help. |
Response Connection Factory |
Enter a response connection factory URI. This option is available only when JMSMessageID is selected for the Response Pattern. If a connection factory is not specified, the connection factory for the request is used for the response. |
JMS Service Account |
Select a service account to use for the JMS resource managed by the JMS server. A service account is an alias resource for a user ID and password, used for both the request and response. The same service account is used for both JMS and JNDI purposes. For more information, see Working with Service Accounts. |
Use SSL |
Select this check box only if the requests are made over a TLS/SSL connection. TLS/SSL (Secure Sockets Layer) provides secure connections by allowing two applications connecting over a network to authenticate the other's identity and by encrypting the data exchanged between the applications. Authentication allows a server, and optionally a client, to verify the identity of the application on the other end of a network connection. Additionally, if the administrator has restricted access to individual JMS destinations (queues or topics) by setting access control on the JNDI entry for the destination, the service must authenticate when looking up the entry in the JNDI tree. Note: The JMS transport does not support two-way SSL. |
Message Selector |
Enter a message selector expression. Only messages with properties matching the expression are processed. |
Client ID |
For topics only, enter the client ID to use for the subscriber. If no value is entered, a client ID is automatically generated. Assigning a custom ID helps you identify this component when monitoring the service. Note that this is only effective for durable subscribers. The JMS Client ID is one of several MDB descriptors that are used to generate subscriber names and the ClientID value for the topic's subscribers. Defining a JMS client ID makes it easier to identify and view subscribers for a specific topic by looking at the subscriber name or client ID. For more information, see JMS Client ID in Proxy Services. |
Durable Subscription |
Select this check box if the subscription is durable or leave it empty if the subscription is not durable. If a subscription is durable, it receives all messages published on a topic, even if the subscription was inactive at the time the messages were published. This option is available only if Topic is selected for the Destination Type. |
Retry Non XA Connection |
Select this check box to retry non-XA connections using the given retry count and interval specified below. If this check box is not selected, Service Bus only retries XA connections and the retry count and interval only apply only to XA connections. This check box only applies to JMS proxy services that have a non-XA connection factory in the service URI. |
Retry Count |
Enter the number of delivery retries a message can have before it is moved to the error destination. This field only applies to WebLogic Server JMS destinations. |
Retry Interval |
Enter the amount of time, in milliseconds, before rolled back or recovered messages are redelivered. This field only applies to WebLogic Server JMS destinations. |
Error Destination |
Enter the name of the target destination for messages that have reached their redelivery limit. This field only applies to WebLogic Server JMS destinations. |
Expiration Policy |
Select a policy that defines how to process an expired message encountered on a destination. You can specify to either discard or redirect the message. Redirecting a message moves it to the error destination specified above. This field only applies to WebLogic Server JMS destinations. |
Is XA Required |
Select this check box if your connection factory is XA. This option takes into account when the remote connection factory is unavailable. If your connection factory is available and this option is enabled, make sure that the connection factory is defined as transactional. |
Transaction Timeout |
Enter the amount of time in seconds for the JMS proxy service to wait for a transaction to be processed. This option only applies to services using an XA connection factory. The default is 600 seconds. |
No MDB on Response Queue |
Select this option if you do not want to generate a default message-driven bean (MDB) on the inbound response queue. Use this option to improve performance. When this option is selected, a proxy to proxy routing format is not supported. |
JNDI Timeout |
The JNDI connection timeout (in seconds) used while looking up the destination or connection factory in the JNDI tree. |
Topic Messages Distribution |
Select one of the following properties to determine how message-driven beans handle incoming JMS messages and high-availability and failover:
This option is available when you select Topic for the Destination Type. Note: When using compatibility mode in a cluster, you might receive duplicate messages. To prevent this, use one of the other options. The "One Copy" options override the Subscription Sharing Policy and Client ID Policy configured on the JMS Connection Factory. |
Target |
Select the target server that will handle incoming JMS messages. If you select one of the "One Copy" options for Topic Messages Distribution, this field displays the name of the cluster. This option is available only in a Service Bus cluster when you select Compatibility for the Topic Messages Distribution option. If you do not set a target, the JMS proxy service instance reading messages off the Topic on each Managed Server in the cluster gets a copy of the message. |
31.8.3 JMS Transport Headers
The various headers related to the JMS transport are listed in Table 31-3. All the headers except the Unit of Order header are common to both outbound requests and inbound response.
Table 31-3 JMS Transport Headers
Header | Description |
---|---|
JMSCorrelation ID |
An identifier used to link one message with another. For example to link a request message with a response message. |
JMSDeliveryMode |
The delivery mode specified when the message was sent. |
JMSExpiration |
The expiration time of the message, which is an absolute value that indicates the specific date and time the message should expire. You can use an XQuery expression to calculate the precise expiration date and time for each message. |
JMSMessageID |
A value that uniquely identifies the message sent by a provider. |
JMSPriority |
The processing priority of the message. When a message is sent, this field is ignored. After the send operation is complete, the field holds the value that is specified by the method sending the message. |
JMSType |
The message type identifier that is specified by a client when a message is sent. |
JMSXAppID |
This is one of the JMS defined properties that specifies the identity of the application that sends the message. This is set by the JMS provider |
JMSXGroupID |
This one of the properties defined by JMS that specifies the group id of the message group to which the message belongs. This is set by the client |
JMSXGroupSeq |
This one of the properties defined by JMS that specifies the sequence of the message inside the message group. |
JMS_IBM_Format |
The nature of the application data. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_Exception |
Request exception reports. This also specifies how much of the application data from the message must be retained in the report message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_Expiration |
Request expiration reports. This also specifies how much of the application data from the message must be retained in the report message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_COA |
Request a confirm on arrival reports. This also specifies how much of the application data from the message must be retained in the report message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_COD |
Request a confirm on delivery reports. This also specifies how much of the application data from the message must be retained in the report message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_PAN |
Request a positive action notification reports. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_NAN |
Request a positive action notification reports. For more information, see For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_Pass_Msg_ID |
Request that the message identifier of any report or reply message is the same as that of the original message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_Pass_Correl_ID |
Request that the correlation identifier of any report or reply message is the same as that of the original message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Report_Discard_Msg |
Request that the message is discarded if it cannot be delivered to its intended destination. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_MsgType |
The type of a message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Feedback |
An indicator of the nature of a report message. For more information, refer to the IBM WebSphere documentation. |
JMS_IBM_Last_Msg_In_Group |
An indicator of whether the message is the last message in a message group. For more information, refer to the IBM WebSphere documentation. |
JMS_BEA_UnitOfOrder |
This header is valid for the request and response. |
31.8.3.1 Configuring Transport Headers
You can configure the transport headers for both inbound and outbound requests in the pipeline. Use a Transport Header action to set the header values in messages. For information about adding transport header actions, see Adding Transport Header Actions in the Console. For information about the transport headers related to the JMS transport, see JMS Transport Headers.
Note:
For information about the limitations for JMS transport headers, see How the Runtime Uses the Transport Settings in the Test Console. Also see Table 12-8.
31.8.4 Configuring Business Services to Use the JMS Transport
When you register a JMS business service, you must manually edit the URI from the WSDL file when adding it to the service definition. The URI format is as follows:
jms://host:port/connection_factory/jndi_destination
Note:
To configure a JMS request-response application with response correlation by JMS ID for a business service, you must:
-
Create uniform distributed queues and local queues targeted to one chosen JMS server.
-
Disable the default targeting for the UDQ that deploys the UDQ on the cluster and creates the member queues on all JMS.
The following table describes the properties you use to configure a JMS-based business service. For more information, see Creating and Configuring Business Services
Table 31-4 JMS Transport Properties for Business Services
Property | Description |
---|---|
Destination Type |
Select one of the following JMS destination types:
|
Message Type |
Select one of the following message types:
This option is disabled if you select a message type of Java for the response. |
Response Queues |
Select one of the following options to specify how to handle responses:
This option is available only when the Destination Type is Queue. |
Response Pattern |
Select one of the following to specify the design pattern for the response:
This option is available only when you select a response option in the Response Queue field. For more information, see Message ID and Correlation ID Patterns for JMS Request/Response. |
Dispatch Policy |
Select the instance of WebLogic Server Work Manager that you want to use for the dispatch policy for this endpoint. The default Work Manager is used if no other Work Manager exists. For example, if the business service has a JMS transport protocol, the business service endpoint is an MDB (message-driven bean) JAR file that you can associate with the specific dispatch policy. For information about Work Managers, see:
|
Request Encoding |
Enter the character set for encoding requests. The default is UTF-8. |
Response Encoding |
Enter the character set for encoding responses. The default is UTF-8. This option is available only when one of the response options is selected in the Response Queues field. |
Response Timeout |
Enter the amount of time, in seconds, to wait for the response before dropping the connection. The default, zero (0), means the response never times out. This option is available only when one of the response options is selected in the Response Queues field. |
Client Jar |
Select the client JAR to be used for dequeueing messages that contain Java Objects. Selecting the client JAR ensures it is on the classpath. This option is available when the service is a Messaging Service with a response type of Java. For more information, see Sending and Receiving Java Objects in Messages. |
Response URI |
Enter a response URI in one of the formats described below. This option is available when you select the One for all Request URIs response option and the JMSCorrelationID response pattern. jms://host:port/connection_factory/jndi_destination To target multiple servers, use the following format: jms://host1:port,host2:port/connection_factory/jndi_destination You can also omit the host and port in the response URI. For example: jms:///connection_factory/jndi_destination When you omit host and port, the connection factory/destination lookup occurs on the local server. This is useful, for example, if the request URI goes to a foreign connection factory/destination, but you want the response sent to the local server. Note: While WebLogic Server allows forward slashes in JNDI names, such as "myqueues/myqueue", JNDI names with forward slashes interfere with the URI format required by Service Bus, and you cannot use those names. To work around this issue, define a JMS foreign server and reference that foreign server in the URI. For more information, see Configure Foreign Servers in Oracle WebLogic Server Administration Console Online Help. |
Request Responses |
Enter a Response URI for each request URI entered on the generic Transport page. Use the formatting and guidelines described for the Response URI field, above. For each URI, you can select an optional service account for JMS/JNDI credentials that the service uses for both the request and response queues. This option is available when you select the One per Request URI response option for the JMSCorrelationID pattern to provide response failover. |
Target - Responses |
Enter the name of the Target server that is to receive responses, and enter a Response URI, as described in the Response URI field. This option is available when you select the One for all Request URIs response option for the JMSMessageID pattern. |
Request Connections |
Enter a JMS Connection Factory name for each request URI, identified sequentially by number in the Seq. No field. If you do not enter a name, the JMS transport uses the connection factory from the request URI. You can select an optional service account for JMS/JNDI credentials that the service uses for both the request and response queues. This option is available when you select the One per Request URI response option for the JMSMessageID pattern to provide response failover. |
Target - Destinations |
Enter the destination queue on each target server that receives responses for each request URI on each target. Each Target server in the list (determined by the servers in the current domain, such as Managed Servers in a cluster) lists the request URIs by Seq.No, which correspond to those in the Request Connections field. This option is available when you select the One per Request URI response option for the JMSMessageID pattern to provide response failover. Use this field in conjunction with Request Connections. Note: Because the Service Bus development environment supports only a one-server environment, only one Target is listed. To configure this field in a multi-server environment, deploy this service to the runtime environment and complete the service configuration in the Oracle Service Bus Console. |
JMS Service Account |
Enter a service account to use for the JMS resource managed by the JMS server. A service account is an alias resource for a user ID and password, used for both the request and response. The same service account is used for both JMS and JNDI purposes. This option is available when you use the None or One for all Request URIs option in the Response Queues field. This field is mutually exclusive with the Pass Caller's Subject option. Use one or the other for JMS/JNDI authentication. For more information, see Working with Service Accounts. |
Use SSL |
Select this check box only if the requests are made over a TLS/SSL connection. TLS/SSL (Secure Sockets Layer) provides secure connections by allowing two applications connecting over a network to authenticate the other's identity and by encrypting the data exchanged between the applications. Authentication allows a server, and optionally a client, to verify the identity of the application on the other end of a network connection. Additionally, if the administrator has restricted access to individual JMS destinations (queues or topics) by setting access control on the JNDI entry for the destination, the service must authenticate when looking up the entry in the JNDI tree. Authenticate using a Service Account or the Pass Caller's Subject option. Note: The JMS transport does not support two-way SSL |
Expiration |
The time interval in milliseconds after which the message expires. Default value is 0, which means that the message never expires. |
Enable Message Persistence |
Select this check box for guaranteed message delivery. Clear this check box to improve throughput if an occasional lost message is tolerable. The JMS message delivery mode lets you balance reliability with throughput. |
Unit of Order |
Enter a message unit-of-order, which enables message producers to group messages into a single unit with respect to the processing order. This single unit-of-order requires that all messages in that unit be processed sequentially in the order they were created. For more information about using unit-of-order, see "Using Message Unit-of-Order" in Developing JMS Applications for Oracle WebLogic Server. |
Pass Caller's Subject |
Select this check box to have Service Bus pass the authenticated subject when sending a message. When you enable this field and the business service targets JMS resources in a different domain, enable global trust on both domains. See "Configuring Security for a WebLogic Domain" in Administering Security for Oracle WebLogic Server. This field is mutually exclusive with the Service Account option. Use one or the other for JMS/JNDI authentication. |
JNDI Timeout |
Enter the period (in seconds) to use when looking up the destination or connection factory in the JNDI tree before the JNDI connection times out. The default, zero (0), means the connection never times out. |