| Author |
Message
|
| objectthinker06 |
 Posted: Thu May 06, 2010 5:46 pm Post subject: MQ Infrastructure Design |
 |
|
Novice
Joined: 15 Aug 2006
Posts: 15
|
I'm looking for some recommendations from your experience whether we should go with Websphere MQ Client v7 or Websphere MQ Server v7 given the following circumstances:
a) We are integrating with our partner MQ system hosted in California data center.
b) The app. hosted on my side (is in the east coast data center) needs approximately seven queues and consumes approx. upto 85,000 messages in a day with peak load of ~8000 (traffic bursts) per sec or a minute. All messages have to be processed and associated workflows satisfied in real time (as they arrive) based on the message data.
c) There would a need in the future for other partners and new apps. to connect to us and we want to plan for scalability from a platform perspective.
Given the above, would establishing a connection through MQ Server to MQ Server is recommended? and my app. will consume messages from MQ hosted locally in the same data center (east coast). Or would you recommend consuming messages directly from our partner systems in the west coast using WMQ Client? Which one offers better performance and what things to watch out for in each scenario?
Thanks! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri May 07, 2010 3:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Especially in view of the fact that you might get more applications I'd suggest that you use server to server.
Looking at the client to server scenario you make the app dependent on a network component and scalability is more difficult to manage... (How many instances do you need when the network slows you down?)...
The server to server setup leaves all the network problems to the channels to deal with and your app can be scaled on a quasi linear basis. It may also be easier for you if you need multiphase commit.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun May 09, 2010 3:28 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| fjb_saper wrote: |
Especially in view of the fact that you might get more applications I'd suggest that you use server to server.
Looking at the client to server scenario you make the app dependent on a network component and scalability is more difficult to manage... (How many instances do you need when the network slows you down?)...
The server to server setup leaves all the network problems to the channels to deal with and your app can be scaled on a quasi linear basis. It may also be easier for you if you need multiphase commit.
Have fun |
Yes, Server to Server is the way to go, for these very reasons. objectthinker06 didn't mention MQ Clustering, but I'd recommend against that, as you only have a point-to-point requirement.
_________________
Glenn |
|
| Back to top |
|
|
| brianb |
| Posted: Tue May 25, 2010 3:07 pm Post subject: |
|
|
Voyager
Joined: 12 May 2010
Posts: 85
|
hmm as he is going to MQv7 which has improved client reconnect does that not make a difference to recommending server ?
Thanks
Brian |
|
| Back to top |
|
|
| mvic |
| Posted: Tue May 25, 2010 3:40 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| brianb wrote: |
| hmm as he is going to MQv7 which has improved client reconnect does that not make a difference to recommending server ? |
As far as reconnectability is concerned, compare the reconnectable function of the client with the reconnectable function of SDR/RCVR channels.
The retry logic in the SDR/RCVR arrangement is much more visible/verbose (qmgr error log messages) and configurable (channel def attributes). This "transparency" is an advantage of SDR/RCVR over client.
The OP's "real time" requirement tends to suggest that large batches of work do not build up for later processing. The advantage of SDR/RCVR over client is less than for a system that does experience large batches of work coming in, to be worked on over a period of time.
And to the OP's "future expansion possibilities" requirement: with a local qmgr these possibilities are much more. This is because you own (or have influence over) local queues, apps, processor and disk capacity. Another plus for a local qmgr. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 26, 2010 2:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| In fact, from a number of perspectives (security included!), there should really be *two* local queue managers. One that connects to business partners and one that is used by local applications. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed May 26, 2010 3:21 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| In fact, from a number of perspectives (security included!), there should really be *two* local queue managers. One that connects to business partners and one that is used by local applications. |
Yes, a "gateway" queue manager that handles external channels and does not have any business logic applications connected is common practice. Sort of like an MQ firewall.
_________________
Glenn |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu May 27, 2010 5:05 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
And if you do use clustering and want higher availability (note I did not say High Availability), then it would be two external gateways and two internal application server QMGRs.
Then you can set the receiver channel's MCAUSER to have an ID with less then administrative authority (so your buddy does not help you manage your QMGR). |
|
| Back to top |
|
|
|
|
