JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Java CAPS JMS Binding Component User's Guide     Java CAPS Documentation
search filter icon
search icon

Document Information

Using the JMS Binding Component

JMS Binding Component Overview

JMS Binding Component Features

JMS Binding Component Scenarios

Outbound Scenario

Inbound Scenario

XA Scenario

Outbound InOut Exchange Scenario

Inbound InOut Exchange Scenario

On Demand Receive Scenario

Creating JMS-Based Concrete WSDL Documents

To Create a JMS-Based Concrete WSDL Document from the New WSDL Document Wizard

To Create a JMS-Based Concrete WSDL Document from the New File Wizard

Request Connection Configuration

Request Consumer Configuration

Request Publisher Configuration

Response Destination Configuration

Response Consumer Configuration

Response Publisher Configuration

Advanced Configuration

Connecting to the JMS Server

Specifying the Protocol, Server, and Port

Connecting to the JMS Server Using JNDI

Using the lookup Approach

Using the JNDI Approach

Configuring Redelivery Handling

Configuring Redelivery Handling from the Wizard

Configuring Redelivery Handling by Editing the WSDL Document

Using the Normalized Message Properties

Inbound Normalized Message Properties

Connection URL Property (org.glassfish.openesb.jms.inbound.connectionurl)

User Name Property (org.glassfish.openesb.jms.inbound.username)

Message Selector Property (org.glassfish.openesb.jms.inbound.messageselector)

Destination Property (org.glassfish.openesb.jms.inbound.destination)

Destination Type Property (org.glassfish.openesb.jms.inbound.destinationtype)

Forward As Attachment Property (org.glassfish.openesb.jms.inbound.forwardasattachment)

Outbound Normalized Message Properties

Connection URL Property (org.glassfish.openesb.jms.outbound.connectionurl)

User Name Property (org.glassfish.openesb.jms.outbound.username)

Password Property (org.glassfish.openesb.jms.outbound.password)

Destination Property (org.glassfish.openesb.jms.outbound.destination)

Destination Type Property (org.glassfish.openesb.jms.outbound.destinationtype)

XA Transaction Property (org.glassfish.openesb.jms.outbound.xatransaction)

Delivery Mode Property (org.glassfish.openesb.jms.outbound.deliverymode)

Timeout Property (org.glassfish.openesb.jms.outbound.timeOut)

Client ID (org.glassfish.openesb.jms.outbound.clientid)

Message Selector Property (org.glassfish.openesb.jms.outbound.messageselector)

Subscription Durability Property (org.glassfish.openesb.jms.outbound.subscriptiondurability)

Subscription Name Property (org.glassfish.openesb.jms.outbound.subscriptionname)

Forward As Attachment Property (org.glassfish.openesb.jms.outbound.forwardasattachment)

General Normalized Message Properties

Time To Live Property (org.glassfish.openesb.jms.timetolive)

Priority Property (org.glassfish.openesb.jms.priority)

Message ID Property (org.glassfish.openesb.jms.messagetype)

Message Type Property (org.glassfish.openesb.jms.messagetype)

Correlation ID Property (org.glassfish.openesb.jms.correlationid)

Reply To Destination Property (org.glassfish.openesb.jms.replytodestination)

Reply To Destination Type Property (org.glassfish.openesb.jms.replytodestinationtype)

User Properties Property (org.glassfish.openesb.jms.userproperties)

JMS WSDL Extensibility Elements

JMS Connectivity Elements

JMS address Element

JMS jmsjcaOptions Element

JMS Binding Elements

JMS binding Element

JMS operation Element

JMS message Element

JMS properties and property Elements

JMS mapmessage and mappart Elements

JMS Binding Component Clustering

JMS High Availability

JMS Load Balancing

JMS Performance

Publishing and Subscribing to Multiple WebSphere Queues

JMS Binding Component Clustering

Mission-critical enterprise systems need to be fast, reliable, and scalable. In a world of JMS systems that require near-zero downtime, the messaging architecture must support the clustering of JMS resources such as queues and topics, while accounting for the load-balancing of distributed JMS message traffic.

The JBI Runtime Environment supports clusters of JMS Binding Components and JMS brokers. The clustering of JMS binding components requires deploying one instance of a JMS binding component to each JBI runtime in a clustered JBI Runtime Environment. The availability and method of configuring a cluster of JMS brokers depends on the JMS provider. The Enterprise Edition of Java System Message Queue supports clustering of JMS brokers.


Note - Clustering is supported for queues only. Clustering is not supported for topics.


Clustering and the JMS Binding Component is described in the following categories:

JMS High Availability

High availability (or failover) clusters are designed to improve availability of services by removing any single points of failure. Nodes in the cluster also provide failover and redundancy capabilities. If one node in a cluster fails, then another node ensures that there is no loss of availability of the service. A logical front-end is responsible for configuring two or more nodes to act as redundant services.

To achieve high availability of JMS services, the JMS Binding Component is available in every instance of JBI runtime. Each instance of JBI runtime is also associated with one application server running in a clustered environment. The deployment of a service assembly is replicated to each JMS Binding Component instance. As a result, multiple consumers or producers are created on connections established by the JMS Binding Component instances to the same JMS broker. The JMS broker can be a standalone broker or a broker in a high-performance cluster of brokers.

Because JMS Binding Component instances are replicated, a crash to one instance does not result in a loss of service. The JMS message acknowledgement protocol guarantees at least once delivery of messages (no loss of messages). In conjunction with XA, exactly once semantics can be achieved. A crash to the JMS Binding Component during message delivery results in the JMS broker detecting a connection loss (lacking of message acknowledgement) and redelivering the message to the next available JMS Binding Component receiving from the same queue. With XA, a crash that leaves behind any in-doubt transactions can be recovered when the JMS Binding Component performs XA recovery in coordination with the JBI runtime and the transaction manager. Therefore, the combination of JMS acknowledgement protocol and XA protocol can support failover and recovery.

JMS Load Balancing

Load balancing clusters are designed to distribute the workload across multiple nodes in the cluster. The clusters accomplish this by having one logical front-end to the cluster that distributes any requests for work to any node in the cluster. The main purpose of this type of cluster is to provide improved performance, although they often include some high-availability features.

JMS supports load balancing by allowing multiple receivers on a queue. Replication of deployed service assemblies results in multiple JMS Binding Component instances receiving from the same queue. Messages are delivered in a point-to-point fashion, with only one receiver getting one message at a time. The JMS broker balances the load by delivering messages from the queue to any available receivers on that queue. The algorithm used for load balancing depends on the JMS provider.


Note - Load balancing is only valid if queues are used, not topics.


JMS Performance

High-performance clusters are a special type of load balancing cluster. A logical front-end to the cluster partitions the work into tiny chunks and distribute each chunk to nodes in the cluster. When the work is done, the logical front-end reassembles the result and then returns the completed result to the client of the cluster.

Replication of a JMS Binding Component results in multiple receivers on a queue in a clustered or nonclustered broker setup. Load is distributed across the JBI instances as a result of having multiple receivers on one or more queues.

To achieve even higher performance, the JMS brokers should be clustered. Broker clusters enable a message server to scale its operations with the volume of message traffic by distributing client connections among multiple brokers. For Java System Message Queue, in a clustered broker environment, each broker within a cluster is directly connected to all the others. Each client (JMS Binding Component consumer or producer) has a single home broker with which it communicates directly, sending and receiving messages as if that broker were the only one on the server.

Behind the scenes, the home broker works with the other brokers in the cluster to share the load of providing delivery services for all connected clients. One broker within the cluster can be designated as the master broker. The master broker maintains a configuration change record in which changes to the cluster’s persistent entities (destinations and durable subscriptions) are recorded. This record is used to propagate such change information to brokers that were offline at the time the changes occurred.

For detailed information about clustering for Java System Message Queue, see the Java System Message Queue documentation.

The following diagram illustrates how a cluster of JBI/JMS Binding Components and a cluster of Java System Message Queue brokers appears.

image:Diagram shows a cluster of JBI / JMS Binding Components and Java System Message Queue brokers. The context describes the diagram.