|
home /
infca /
MQ Pub/Sub
(navigation links)
|
The road to innovation isn't paved at all (Sun)
|
MQ Pub/Sub
Publish/Subscribe is a term used to define an application model in which the provider of some information is decoupled from the consumers of that information.
Publish
Concepts
Publishers and subscribers are applications that send and receive messages (publications)
using the publish/subscribe method of messaging.
Publishers and subscribers are decoupled from one another
so that publishers do not know the destination of the information that they send,
and subscribers do not know the source of the information that they receive.
The provider of the information is called a publisher.
Publishers supply information about a subject without needing to know
anything about the applications that are interested in the information.
The consumer of the information is called a subscriber.
The subscriber decides what information it is interested in, and then waits to receive that information.
Subscribers can receive information from many different publishers,
and the information they receive can also be sent to other subscribers.
WebSphere MQ V7 queue managers use a Pub/Sub Engine instead of a broker
to control the interactions between publishers and subscribers.
The Pub/Sub Engine receives messages from publishers, and subscription requests from subscribers.
The Pub/Sub Engine's job is to route the published data to the target subscribers.
mq v7.5 publib + "Publishers and subscribers"
Publisher applications (mq v6) communicate with the broker using command messages in the RF Header format
(or the equivalent functions in the Application Messaging Interface).
Publishers can register with the broker before they start publishing information,
they can register implicitly with their first publication, or they can choose not to register.
When they have finished publishing information, they can deregister with the broker.
They can also delete retained publications.
url
Publish/subscribe has been changed significantly for WebSphere® MQ Version 7.0
In previous versions, publish/subscribe messaging was controlled using a command message interface.
This interface is deprecated in Version 7.0 publish/subscribe.
Instead, publish/subscribe messaging is now controlled using new function in the WebSphere MQ API
and as a result, publish/subscribe messaging is much more consistent with point-to-point messaging.
This new way of doing publish/subscribe messaging is documented in the main body of this section of the information center.
Applications written using previous versions of WebSphere MQ publish/subscribe that make use of the command message interface
are encouraged to move to the new WebSphere MQ publish/subscribe API.
However, the command message interface continues to be supported on all platforms (including z/OS®).
If you are already a user of publish/subscribe
you can continue to use your current configuration after installing WebSphere MQ Version 7.0
without making extensive changes to your applications or configuration.
Similarly, JMS applications do not have to be modified,
although if you do not chose to use the new Version 7.0 publish/subscribe
you will not benefit from the simplified administration that is now available when using WebSphere MQ as the provider.
Since the command message interface method of doing publish/subscribe is still supported in Version 7.0 using the PSMODE function,
this interface continues to be documented in the WebSphere MQ Version 7.0 library.
More detail in those links
- what is new in MQ V7: Publish/Subscribe added to the MQ API -
url
-
webcast replay: Installation and Migration of WebSphere MQ V7 including Publish/Subscribe Configuration -
url
Nomenclatura
- topic - point-to-point queue
Register to Publish
An application that needs to publish a message about a specific topic can do so by opening that topic and putting a message to it.
There is very little difference between an application that opens a queue then puts a message to it,
and one that opens a topic to put a message to it, so the application code should look very familiar to you.
If you wish to use publish/subscribe with WebSphere MQ V7 you do not require any topic objects to be defined.
You can in fact go right ahead and use a topic string directly in your application.
You do this by placing your topic string in the ObjectString field.
TMM42
The publisher can send a Register Publisher command message to the broker's control queue SYSTEM.BROKER.CONTROL.QUEUE
to indicate that a publisher will be, or is capable of, publishing data on one or more specified topics.
Subscribe
Subscribe
An application that wants to register an interest in information about a certain topic needs to ‘subscribe’ to that topic.
This can be done using the MQ API verb MQSUB.
MQSUB can be thought of rather like MQOPEN.
It details the resource you wish to use, and it is the point where security checks are done.
TMM42
Subscriber applications need to register their interest in receiving publications with a broker.
Send the Register Subscriber command message to the SYSTEM.BROKER.CONTROL.QUEUE to register as a subscriber.
Managing the Broker (mq v6)
Control commands
- dspmqbrk (display broker status)
- strmqbrk (start broker function)
- endmqbrk (end broker function)
- dltmqbrk (delete broker)
- clrmqbrk (clear broker's memory of a neighboring target broker)
- migmqbrk (migrate broker to WebSphere Business Integration Brokers)
url
strmqbrk
The strmqbrk command is used to start a broker.
The first time this command is run on a queue manager, all the relevant MQSeries objects are automatically created.
strmqbrk -m MYQMGRNAME
strmqbrk -p MYPARENTQMGRNAME -m MYQMGRNAME
You can use the -p option to specify the name of the parent queue manager in a broker network,
once you specified such value it is retained by the broker upon restart.
dspmqbrk
The dspmqbrk command is used to check the status of the broker.
Possible states are: starting, running, stopping, quiescing, not active and ended abnormally.
dspmqbrk -m MYQMGRNAME
endmqbrk
The endmqbrk command is used to stop a broker.
There are two options: -c requests a controlled shutdown (default), -i requests an immediate shutdown.
endmqbrk -i -m MYQMGRNAME
Distributed publish/subscribe
Concept -
how does it work
Adding a broker to a network
Before you can add a broker to the network,
channels in both directions must exist
between the queue manager that hosts the new broker
and the queue manager that hosts the parent.
Brokers use explicit addressing when sending messages
to queues that reside on another queue manager.
When the queue is opened by the broker,
both the queue and queue manager names are specified.
To facilitate multi-broker operation,
this queue manager name must resolve to the appropriate transmission queue.
The simplest method of achieving this
is for the transmission queue
to have the same name as the remote queue manager name.
To add a broker to the network,
start the broker with the strmqbrk command
specifying the name of the parent broker if appropriate.
When the broker has been started with a parent named
you cannot change the name of its parent,
even when the broker is restarted.
You cannot change the parent of a broker
as part of normal operational procedures without disrupting service.
Sequence of commands for adding and deleting brokers
This example shows the sequence of commands
for adding and deleting brokers in a network.
Queue manager A is to host the parent broker
and queue manager B is to host the child broker.
Channels are defined between the two queue managers.
Broker A is the parent broker, so this must be created first.
Broker B is then created as a child broker of broker A.
The sequence of commands to achieve this is as follows:
START CHANNEL (B.to.A)
START CHANNEL (A.to.B)
strmqbrk -m A
strmqbrk -m B -p A
When both brokers are deleted,
broker B must be deleted first,
and broker A must be available for this to happen.
Only when broker B has been deleted can broker A be deleted.
The sequence of commands to achieve this is as follows.
endmqbrk -m B
STOP CHANNEL (A.to.B)
START CHANNEL (A.to.B)
dltmqbrk -m B
endmqbrk -m A
STOP CHANNEL (B.to.A)
START CHANNEL (B.to.A)
dltmqbrk -m A
Running the application
Sample application
To run the application on a single queue manager, first start the queue manager and then enter the following command:
runmqsc QMgrName < amqsresa.tst
This creates the appropriate queues on the queue manager.
Then start the broker :
dspmqbrk
strmqbrk
The results service program is started by entering the following:
amqsres QMgrName
You can now start one or more match simulators by entering the following command:
amqsgam Team1 Team2 QMgrName
Monitoring pub/sub
Using DISPLAY TPSTATUS TYPE(SUB) you can see the details of the current publishers on this topic string.
One of the attributes returned is the Active Connection ID (ACTCONN) which links to DISPLAY CONN which shows you the details about that specific application.
The Subscription ID (SUBID) links to DISPLAY SBSTATUS where we will see a single subscription with that ID since the perspective of that display is the subscription.
DISPLAY SBSTATUS which shows the run-time status of a subscription.
DISPLAY SUB is slightly different – it shows the more static attributes of the subscription,
whether it was created using a DEFINE SUB command or an MQSUB call in an application.
dis tpstatus
dis sbstatus
TMM42
pub/sub troubleshooting
url
Miscelaneous items
Futur del Pub/Sub
- cluster MQ - els PR es suscriuen a canvis de configuracio
- Message Broker - els Broker es suscriuen a desplegaments
- MQTT - els clients es subscriuen, els aparells publiquen
- bon exemple en aquest RedBook - companyia de transport -
MQSeries Publish/Subscribe Applications
- twit boat position : good app
mirrorq
Queues and topics are interchangable in MQ v7.
You can have the app put the message to a Topic
that has two subscriber queues for the receivers,
without changing the apps.
Duplicació de missatges
- define a topic called Q1T, with a topic string of Q1
- define a sub to topic object Q1T, with a destination of Q1
- define a Q Alias called Q1Alias, target type topic with a target of Q1T
- a put to Q1Alias will now produce a message to the Q1 local queue
- define another sub to topic object Q1T, this time with a destination of Q2
- a put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
url
Define a TOPIC that acts as the destination of the sending app and two subscriptions to the "real" destination queues.
Another seq:
App A is putting to a local q called Q1.
App B is pulling from Q1.
You have MQ 7 and want to duplicate the messages but do not want to change the sending or receiving app code.
- define a topic called Q1T, with a topic string of Q1
- define a sub to topic object Q1T, with a destination of Q1
- define a Q Alias called Q1Alias, target type topic with a target of Q1T
- a put to Q1Alias will now produce a message to the Q1 local queue
- define another sub to topic object Q1T, this time with a destination of Q2
- a put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
The only change in the original setup is that App A puts to Q1Alias instead of Q1.
App A and App B don't know they are using Pub Sub.
The subscriptions are created by the MQ Admin using admin commands.
url
Dubtes de pub/sub
- amb quin criteri escollir de fer servir cues managed o unmanaged ?
