| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| architectural consideration - using MQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| vradhik |
 Posted: Wed Jan 14, 2009 3:48 pm Post subject: architectural consideration - using MQ |
 |
|
Novice
Joined: 08 Nov 2008
Posts: 10
|
We are going to use MQ interface between aix (web application) and mainframes (IMS, DB2, VAG, application). The communication is going to be both ways and the data is quite huge. Also, the data size is variable, in the sense, it contains detail line items so, sometimes there can be 50 line items and sometimes 10000.
Any pointers on architectural considerartions using MQ in this scenario is highly appreciated. Thanks |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Jan 14, 2009 4:26 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
"quite huge" to you may not be to me. define quite huge.
How big?
How many per minute?
How fast does it have to be?
Request / Reply? Or one way datagrams?
Consumer always up? Or batch job?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 15, 2009 1:39 am Post subject: Re: architectural consideration - using MQ |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vradhik wrote: |
| The communication is going to be both ways |
Put a queue manager at each end and define connectivity
| vradhik wrote: |
| the data is quite huge. |
Size of a mouse? Size of a house? Size of a mountain? Huge because it fills a 2Gb disc on AIX? I make this point because a huge 2Gb AIX file system would rattle round in a lost corner of the average mainframe disc farm.
If single messages are large, you might need to increase queue & channel default size limits. Or consider transmitting the data in smaller chunks.
| vradhik wrote: |
| Also, the data size is variable, in the sense, it contains detail line items so, sometimes there can be 50 line items and sometimes 10000. |
An ideal oppertnity to split this "huge" data into more manageable packets.
| vradhik wrote: |
| Any pointers on architectural considerartions using MQ in this scenario is highly appreciated. Thanks |
From the information you've given it's hard to say. It all sounds fairly straightforward, giving you a number of ways to skin your proverbial cat to obtain your exact requirements.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 15, 2009 2:17 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Make sure all messages have MQMD.Format = MQSTR, make sure applications perform MQGET with MQGMO_CONVERT. This will make sure the cross-platform aspect will be OK.
Try not to send excessive blank data (i.e. don't pad messages to a large fixed length) as this will waste bandwidth. Otherwise follow the usual best practices for MQ. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Fri Jan 16, 2009 10:25 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| No persistence as possible. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
