Application communication models

Applications can use the services of a broker by sending messages to it and receiving messages from it, across one of the supported transport protocols.

The way that they do this depends on the protocol itself, the programming interface that they use, and the communication model that they adopt.

WebSphere Event Broker supports two end-user application communication models:

  1. Point-to-point
  2. Publish/subscribe

A single application can mix the two styles, if appropriate. In a mixed scenario, the message flow that processes the messages for this application contains at least one output node and at least one publication node, in addition to one or more input nodes.

The programming interfaces that you can code in your applications are described in Application programming interfaces.

Point-to-point

Point-to-point applications use a request/reply or client/server model, or broadcast a message to many target applications using distribution lists. Other applications send one-way send-and-forget or datagram traffic. They exchange information with known partners. Each application is aware of the identity of the one or more applications with which it is communicating. You can create and configure message flows to process both send-and-forget and request/reply messages, and deploy them to your brokers.

The text and diagrams below illustrate the send-and-forget and request/reply models. The diagrams assume that the applications are using the WebSphere MQ Enterprise Transport protocol. The model is identical for other protocols, although the resource through which a message is sent or received will not be a WebSphere MQ queue.

In the send-and-forget model, an application sends a message but does not expect a reply. Another application might optionally receive a message as a result of the message sent by the first application. In the diagram, the sender puts a message onto the input queue of a message flow at the broker (1). The output from the message flow is put onto the receiver's queue (2), from where the receiver can get it (3).


The text above this diagram describes its contents.

With request/reply messaging, after the receiver receives a request message it sends a reply back to the sender. The request message is handled as described for send-and-forget messages. There are two possibilities for the reply:

  1. The receiver sends the reply message directly back to the sender, without involving the broker. The message is sent to the ReplyToQ in the message descriptor (MQMD) of the request message, which is passed unchanged by the broker. (If your applications are not using WebSphere MQ, you must use some other technique to determine the reply destination.)

    In the diagram below, the sender puts a message onto the input queue of a message flow at the broker (1). The output from the message flow is put onto the receiver's queue (2), from where the receiver gets it (3). The receiver sends the reply directly to the ReplyToQ of the sender (4), from where the sender can get it (5).


    The text above this diagram describes its contents.
  2. The receiver sends the reply message to a reply message flow in the broker, so that it can be processed before reaching the sender. In this case, the broker must replace the sender's ReplyToQ in the MQMD of the request message with the input queue name of the reply message flow.

    The output of this reply message flow must go to the sender's ReplyToQ. If the name is fixed, there is no problem; if it is not, some means of associating this queue with the reply message is needed.

    For example, the relevant details in the message descriptor can be copied into a folder in the MQRFH2 header, and carried with the message.

    In the diagram below, the sender puts a message onto the input queue of the first message flow at the broker (1). The output from the message flow is put onto the receiver's queue (2), from where the receiver gets it (3). The receiver sends the reply to the input queue of the second message flow at the broker (4). After processing the reply, the broker sends it to the ReplyToQ of the sender (5), from where the sender can get it (6). (In this case, the output node of the second message flow needs to know the ReplyToQ of the sender.)


    The text above this diagram describes its contents.

Existing applications that you have written using the point-to-point model can run unchanged in a WebSphere Event Broker environment if they use one of the supported protocols to communicate with the broker.

Publish/subscribe

The publish/subscribe application communication model involves applications known as publishers and applications known as subscribers. Publishers make messages available by publishing on specific topics. Subscribers receive messages by subscribing to topics. An individual application can be both a publisher and a subscriber.

Messages published by any one publisher can be received by any number of subscribers. Subscribers might also receive messages, on the same or different topics, from any number of publishers.

In the diagram below, the publisher can send Publish or Delete Publication messages to the broker. The broker forwards the Publish message to subscribers that have a matching subscription. The subscriber can send Register Subscriber, Deregister Subscriber, or Request Update messages to the broker. Optional Response messages from the broker are sent to the publisher and subscriber.


The text above this diagram describes its contents.

If you have existing end-user applications that are written to the publish/subscribe model, for example using the MQI or AMI, you can probably integrate these applications into a WebSphere Event Broker broker domain without change.

You can also modify these applications, or write new ones, to take advantage of the sophisticated publish/subscribe processing that is provided, particularly for subscribers.

The publish/subscribe model, and the processing provided by WebSphere Event Broker, is described fully in further topics available through the related links listed below.

Related concepts
Publish/Subscribe
Application programming interfaces
Related tasks
Developing message flows
Developing publish/subscribe applications
Related reference
End-user application support
Built-in nodes
Publish/subscribe