Author |
Message
|
walterA |
Posted: Tue Sep 22, 2015 5:55 pm Post subject: How to integrate 2 systems via MQ |
|
|
Novice
Joined: 22 Sep 2015 Posts: 20
|
I am pretty new to MQ, so sorry for dumb question.
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:
Option 1.
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.:
Option 2.
Source system Message Producer --> Target Q Manager 2 (target local queue) <-- listener ---- > DB
What approach is better?
Thanks,
WA |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Sep 22, 2015 6:53 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
None / All ...
In fact I would say the one you feel most comfortable with...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Wed Sep 23, 2015 4:57 am Post subject: Re: How to integrate 2 systems via MQ |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
walterA wrote: |
There will be a significant flow of events between 2 systems (thousands per hour). |
I have a couple of systems that run a couple of thousand messages a minute.....
walterA wrote: |
What approach is better? |
The one that best fits your needs. Seriously. You can skin this cat any number of ways.
Consider:
The network link between the Producer and the listener is unreliable and / or slow. Using a queue manager to queue manager channel exploits MQ's resiliency features and removes this problem.
Consider:
The source system is heavily loaded doing whatever it's doing inside a tight SLA. Putting messages directly to the target queue removes the need for a queue manager on that machine, freeing up resources.
There is a laundry list of other considerations for this kind of design question, and only you know them all. There's no single "best practice". Indeed for both of those you could mitigate them in other ways; solid retry / reconnect code inside the app fixes the network problem and any resource issue is fixed with more hardware........... _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Sep 23, 2015 5:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
There is an issue of security. What rules/policies do you need to put in place for connections from the business partner? You can't simply rely on the firewall.
A second queue manager allows you to isolate traffic from the business partner into a single endpoint that can then be tightly secured, and all information about your internal setup hidden. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
Vitor |
Posted: Wed Sep 23, 2015 5:05 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqjeff wrote: |
There is an issue of security. |
Vitor wrote: |
There is a laundry list of other considerations |
Like this one. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
walterA |
Posted: Wed Sep 23, 2015 4:57 pm Post subject: |
|
|
Novice
Joined: 22 Sep 2015 Posts: 20
|
Thank you for your comments.
I am leaning towards the first solution with 2 Q Managers.
so the second Q manager provides:
1) additional security which is needed in my case
2) better availability in case of failures
As far as I understand it will also more effective because if you have a channel between 2 Q manager it will open 1 socket connection for multiple messages.
can someone recommend what I can read on how to design a distributed system like this?
Thanks! |
|
Back to top |
|
 |
|