I need to integrate 2 applications. There is an external system and it sends events to the target system. MQ Series is used as an interface between two systems. There will be a significant flow of events between 2 systems (thousands per hour). Should I use Queue Managers, remote queue and channel in this case, like this:
Source system Message Producer -> Source Q Manager1 (remote queue) --- channel --- Target Q Manager 2 (target local queue) <-- listener ---- > DB
Or there can be a more simple design, when source system just connects remotely to the target queue and put messages in it, e.g.:
Source system Message Producer --> Target Q Manager 2 (target local queue) <-- listener ---- > DB
Depends on the security of the environment.
We had implemented 2 approaches previously.
1. "A" sends messages to "B" and vice versa. Both are in different networks.
So we had "C" in between. So "A" sent messages to "C"'s remote queue, then "C" puts it in "B"'s remote queue and my Java app reads it from "B".
Then I put message in "B"'s remote queue, "B" puts in in "C"'s remote queue and other party reads the message from "C".
(Here A, B and C are QMGRs)
2. Both parties are in same network.
So I put message in "X"'s local queue and other party reads message from that local queue only.
(Here X is a QMGR)
Interestingly in the 2nd option we had less traffic and in the 1st we had around 20,00,000 messages flowing per hour.
Personally I have never measured the difference in performance between the 2 setups, but I feel that there will not be much difference considering the fact that IBM Websphere MQ is one of the best in the market.
So I feel it is better to have a simple setup(just 1 QMGR, 1 local QUEUE) if both PRODUCER and CONSUMER are in same network.
If PRODUCER and CONSUMER are in different network, then you go for the more complex setup considering the security.
That's my roommate. He's kinda weird, but he always pays his half of the rent. And he gave me this tiny ad:
create, convert, edit or print DOC and DOCX in Java