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.2 JMS Transport Security

The JMS transport supports one-way SSL, but not two-way SSL.

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 Platform Interoperability

The following sections provide information and links for interoperability with different JMS platforms.

31.1.6.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.6.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.1.6.3 Interoperability with Tibco EMS

When using Tibco Enterprise Messaging Service (EMS) as a messaging provider, you must modify setDomainEnv.cmd/sh so EXT_PRE_CLASSPATH references the Tibco EMS client JAR files.

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 the following 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. The ReplyTo 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 the generate-unique-client-id descriptor is set to true. The generate-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 follows:

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:

Replace the node for the $body variable with the following sample SOAP:

Example - Sample SOAP

<soap-env:Body> 
      <soap-env:Fault> 
         <faultcode
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">soap:Server</faultcode>
         <faultstring>Some literal string</faultstring>
         <detail>
            <test:theFault>
               <test:ID>Any user defined code</test:Id>
               <test:message>A specific literal message</test:message>
            </test:theFault>
         </detail>
      </soap-env:Fault>
</soap-env:Body>

where:

soap-env is the system prefix for the namespace http://schemas.xmlsoap.org/soap/envelope/
test is the prefix for the namespace http://www.oracle.com/test/

If the prefix test is not already known to Service Bus, you must declare it.

Configure a reply action with failure.

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 and 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 `JMSReplyTo` property.	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:
1. Configure a Transport Headers Action by selecting Other in the Add Header field and entering a URI in the field provided.
2. Select Set Header to <Expression> and create the expression by entering a concatenation of the values specified for the contextPath and serviceUri 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
```
3. To specify the second JMS Header, select Other in the Add Header field again, and enter _wls_mimehdrContent_Type in the associated field.
4. 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 with text/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.

Figure 31-1 MQ Service Using a JMS Message ID for Correlation

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 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 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:

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: Queue (for a point-to-point destination) Topic (for a publish/subscribe destination)
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: JMSMessageID: For JAX-RPC services running on WebLogic Server. JMSCorrelationID: For all other services. When you select this option, you must also enter a Response URI. 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: Bytes (for a stream of uninterpreted bytes) Text (for text 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: Using Work Managers with Service Bus "Using Work Managers to Optimize Scheduled Work" in Administering Server Environments for Oracle WebLogic Server
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 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: One Copy Per Application: Select this option to provide high availability and scalability when the JMS proxy service is deployed to a cluster. This ensures that an inbound JMS message is processed on only one of the available servers in a cluster. This is the default value. One Copy Per Server: Select this option if you want inbound JMS messages published to a topic to be received by the proxy service on every member of the cluster. Compatibility: Select this option if you want inbound JMS messages to be processed on a specific Managed Server or all Managed Servers in a cluster. If you select this property, select a Target server. 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: Queue (for a point-to-point destination) Topic (for a publish/subscribe destination)
Message Type	Select one of the following message types: Bytes (for a stream of uninterpreted bytes) Text (for text messages) 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: None: No response is expected. Select this option for one-way operations. One for all Request URIs: Lets you enter a single URI to handle the response, as well as set other response configuration details such as encoding and timeout, and optionally select a JMS Service Account for passing JMS/JNDI credentials. One per Request URI: This option provides response failover, letting you enter a response URI or destination for each request URI. You can optionally select a service account for JMS/JNDI credentials on each request/response pairing. 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: Select JMSCorrelationID for all services other than JAX-RPC services running on WebLogic Server. Select JMSMessageID for JAX-RPC services running on WebLogic Server. 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: Using Work Managers with Service Bus "Using Work Managers to Optimize Scheduled Work" in Administering Server Environments for Oracle WebLogic Server
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.