IBM Reliable Transport Extension for WebSphere sMash

Overview

The IBM Reliable Transport Extension consists of the following components:

Messaging broker

A messaging broker is a long running application that provides the messaging service to applications performing request processing.

Messaging protocol

This component provides a protocol implementation that allows an application to send and receive messages using the Connection API.

Messaging kicker and receiver

These components allow an application to monitor a queue and perform request processing when a message arrives.

Messaging external client

The external client component allows external applications to communicate with applications through the IBM Reliable Transport Extension.

A simple scenario

The following diagram outlines a simple deployment in which one application is sending a message to another:

1. Application code in app1 uses the Connection API to POST a message to queue1 managed by broker1.
2. The long running application, broker1, hosts the messaging broker and a messaging kicker which is monitoring queue1.
3. When a message has arrived the messaging kicker notifies the messaging receiver in app2 and this reads the message from queue1.
4. The messaging receiver fires an event to allow an onMessage() event handler containing application logic to process the message.

An offline processing scenario

A deployment of the Reliable Transport Extension can include multiple messaging brokers. For example consider a scenario in which travelling salesmen take orders using their laptops, which do not have permanent network connections. The following diagram depicts the deployment of WebSphere sMash applications and messaging brokers on a salesman's laptop and on an office server:

1. Each salesman's laptop has a Web browser and two WebSphere sMash applications installed:
   • An instance of a salesman application, which provides a user interface to allow the salesman to record the details of orders taken.
   • A messaging broker instance unique to the individual salesman; which in this case is called broker.smith.
2. A server in the main office has another two WebSphere sMash applications installed:
   • An application called office, which processes orders recorded by the salesmen.
   • A messaging broker instance to serve the office application, which is called broker.office.
3. When the salesman completes an order the salesman application uses the Connection API to POST a message containing the completed order to a queue in the local messaging broker, broker.smith. The salesman application can send orders to its local messaging broker even if the salesman is working offline.
4. The messaging broker stores the orders in its queue until it is able to establish a connection to the messaging broker in the office. It can then forward the orders to the central queue, in broker.office. This is called store-and-forward processing.
5. The office application is using the messaging kicker and receiver components to listen for orders arriving on its queue. When the orders arrive, they are processed in the order that the salesman recorded them.

For more information about multiple broker deployments and store-and-forward processing, see Store-and-forward processing in multiple messaging broker topologies.