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 Message 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. It is possible that no message is sent by the message flow (for example, if the sending message just requested a database update). 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.
You can do this, for example, by including a Database or DataInsert node in the first message flow that stores the reply destination information, which can be retrieved by the second message flow.
Alternatively, 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 Message Broker environment if they use one of the supported protocols to communicate with the broker.
You can enhance and extend your existing application function by using the facilities of the broker to include additional partners. For example, an application that handles similar data but in a different format can participate because the original message can be transformed by a message flow in the broker into the expected format, without the need to change the sending or receiving application.
If you identify a message that needs additional application processing, you can create another copy of the message in the message flow, and send it to a new application developed to provide that processing. The original applications are unaware of the new action on the message and continue to work unchanged.
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 Message 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 Message Broker, is described fully in further topics available through the related links listed below.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00450_ |