Publish/Subscribe architecture is useful in scenarios where P2P might not be suitable, reasons are obvious :
Exception Scenario :
While subscribing, we may get following warning :
- Problems with large numbers of senders & receivers.
- Problems when senders & receivers change frequently; (Becomes unmanageable)
- MQ based subscription messages registered using a special queue SYSTEM.BROKER.CONTROL.QUEUE.
- Do not need to define a queue to handle subscription requests.
- Publication messages handled within the flow.
- Publication node receives publication messages and distributes to the subscribers matching the topic within the publication message.
Subscriber Flow
MQINPUT ->> COMPUTE ->> MQOUTPUT (SYSTEM.BROKER.CONTROL.QUEUE)
Code for Compute Node :
CALL CopyEntireMessage();
SET OutputRoot.MQRFH2.psc.Command = 'RegSub'; --RegSub is a keyword
SET OutputRoot.MQRFH2.psc.Topic = 'SPORTS'; --TopicName
SET OutputRoot.MQRFH2.psc.QName = 'DATA'; -- QueueName
SET OutputRoot.MQRFH2.psc.QMgrName = 'QM'; -- QueueManagerName
Declare PTR REFERENCE to OutputRoot.MQRFH2;
Detach PTR;
Publisher Flow
MQINPUT ->> COMPUTE ->> PUBLICATION NODE
Code for Compute Node :
CALL CopyEntireMessage();
SET OutputRoot.MQRFH2.psc.Command = 'Publish'; -- Publish is a keyword
SET OutputRoot.MQRFH2.psc.Topic = 'SPORTS'; --TopicName
Declare PTR REFERENCE to OutputRoot.MQRFH2;
Detach PTR;
attach PTR TO OutputRoot.MQMD AS NEXTSIBLING ;
RETURN TRUE;
OR
OR
Exception Scenario :
While subscribing, we may get following warning :
And no subscription happens. I solved this issue by having the logged user name less then 12 chars, we can also see : http://www.mqseries.net/phpBB2/viewtopic.php?t=1056&highlight=2035+sid
