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:
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 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).
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:
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 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.)
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.
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.
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.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00450_ |