| Author |
Message
|
| mvic |
 Posted: Tue Dec 11, 2012 3:30 pm Post subject: Re: MQ design considerations |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| spherenewbie wrote: |
| I am rather new to the MQ world, have been experimenting with the two above-mentioned setups but there is without doubt a lot to be learnt. |
A system built from zero, or a system to integrate with an existing MQ system?
Why MQ, out of interest?
Are your requirements overwhelmingly pointing to MQ as a principled choice because of function, or is it a choice determined by other infrastructure already in place?
I guess I'm coming round to saying, are you "on your own" in your organization, or can you work from known patterns already in place, and with the people who put them in place?
I am also coming round to saying that IBM are probably willing and able to sell you consultancy if you want to buy it.
I hope it goes well. |
|
| Back to top |
|
 |
| brianb |
| Posted: Tue Dec 11, 2012 4:54 pm Post subject: Re: MQ design considerations |
|
|
Voyager
Joined: 12 May 2010
Posts: 85
|
|
| Back to top |
|
|
| spherenewbie |
| Posted: Wed Dec 12, 2012 1:49 am Post subject: |
|
|
Newbie
Joined: 21 Nov 2012
Posts: 7
|
| Quote: |
| A system built from zero, or a system to integrate with an existing MQ system? |
System to integrate with an existing MQ system
| Quote: |
| Why MQ, out of interest? |
The other party/ies use MQ heavily
| Quote: |
| Are your requirements overwhelmingly pointing to MQ as a principled choice because of function, or is it a choice determined by other infrastructure already in place? |
Other infra already in place and due to the functionality we are looking at (guaranteed message delivery, near/real-time)
| Quote: |
| I guess I'm coming round to saying, are you "on your own" in your organization, or can you work from known patterns already in place, and with the people who put them in place? |
So the story goes, the MQ 'guy' we had who put some basic WMQ configs together (Q2Q mainly) is no where to be found, projects on his plate naturally went to the the next in line who may have in his naivety lent a hand running elementary commands ... (that would be me)
So I do have the basic scripts I can refer to, plus online resources I have come across and access to v6 and v7 WMQ's to experiment with.
| Quote: |
| I am also coming round to saying that IBM are probably willing and able to sell you consultancy if you want to buy it. |
Yes I have definitely considered this and the experts here, already pitched to the bosses, let's see how it goes.
| Quote: |
From these 2 you should be able to flesh out a generic viso of a simple installation.
I think we have all at some point in our careers been put in this situation. |
Thank you for the links, going through the docs now. I have the existing configs as reference as well (which are pretty basic). In terms of what I need to do, the requirements are gradually materialising
One QM-QM config
One client-QM config
no SSL
no security exits
leased line connectivity
one QM per client aka other party
no clustering
Sorry for the rather long post. I appreciate all the help and guidance so far! |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 12, 2012 1:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| spherenewbie wrote: |
| Other infra already in place and due to the functionality we are looking at (guaranteed message delivery, near/real-time) |
Make it very, very clear to your management that WMQ does not guarantee delivery because they will focus on that word 'guarantee' like it's gospel. WMQ assures once, and once only, delivery (pub-sub notwithstanding).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 12, 2012 6:09 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| exerk wrote: |
| spherenewbie wrote: |
| Other infra already in place and due to the functionality we are looking at (guaranteed message delivery, near/real-time) |
Make it very, very clear to your management that WMQ does not guarantee delivery because they will focus on that word 'guarantee' like it's gospel. WMQ assures once, and once only, delivery (pub-sub notwithstanding). |
Third WORD. WMQ has always assured delivery, even in the marketing documentation. Nothing is foolproof. WMQ cannot protect against people who use the product without proper knowledge.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 14, 2012 10:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Why assured vs. guaranteed delivery? Not-so-subtle differences.
Consider the role of the post office. If you address a letter to a non-existent address (like a vacant lot), it is impossible for the letter to be delivered. It is possible that the delivery person delivers the letter to the wrong address. Thus, no guarantee. You can request that the post office confirm the delivery (or failure to deliver). At least then you might know one way or the other.
For WMQ, it is possible that a message might not be deliverable. Common reasons include: queue does not exist, queue is full, message is too big for the queue, message has expired, channel errors...
Assured delivery presumes that a message actually existed or exists. Some of the so-called "lost messages" are applications that fail to successfully put a message to a queue in the first place.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 14, 2012 11:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Also guaranteed implies some kind of quality of service. It's assured that a persistent message will be delivered somewhere but you can't guarantee when.
Consider a network failure. It's assured messages will be delivered once communication is restored; but you can't guarantee when that will be.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Drax |
| Posted: Tue Dec 18, 2012 8:22 pm Post subject: |
|
|
Novice
Joined: 16 Apr 2007
Posts: 12
Location: China
|
well.. will share my understanding and what I did ..hope it helps
I had one PRD DC and one DR DC each region, the WMQ is expected to provide the assured message delivery to third party and the datacenter in other regions...
I'm using 'MQ server<> client connections' within the same DC(LAN network) and 'MQ server<> MQ server' communicating with other regions and third party..(WAN and across firewall)
the benefit is MQ client is free.. and WMQ server is charged by PVUs.. no matter how many MQ instances I installed in the server, it will charge the same...(of course you need to consider the numbers yourself)
MQ client is more reliable now and could participate into two-phase commit without additional costs(XA transactional client is free now)..
but I still believe it is not good manner to use MQ client cross the firewall... because you need to prepare a lot in App level to ensure the message delivery.. especially worse remote part is not managed by you or your company.. |
|
| Back to top |
|
|
| spherenewbie |
| Posted: Wed Dec 19, 2012 12:50 am Post subject: |
|
|
Newbie
Joined: 21 Nov 2012
Posts: 7
|
Thanks everyone, you guys have been a tremendous help! I managed to (Monday morning) submit a draft of the requirements, signed off my mgt and surprisingly approved by the client (I was expecting them to ask for changes but they didn't ... perhaps they have no clue either *grin*).
This entire exercise has taught more than I ever knew about MQ and has given me a valuable lesson in organisational politics I often refer to as bs.
Booked an MQ admin course for Feb given that it's part of my job now *sigh*, looking forward to it!
Cheers. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Dec 19, 2012 2:17 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
In general I would not worry about MQ losing persistent messages (but do define a dead letter queue).
Worry instead about your application - make sure it uses syncpoint to protect messages. Make sure it reconnects to the QM after any connection break.
Make sure it does not "poll" the QM too frequently, or try to re-connect in a tight loop (insert a delay between reconnect attempts).
Use MQGET with WAIT, SYNCPOINT and CONVERT as a general rule. Always set the MQMD.Format (usually to MQSTR) as no default is provided.
These are the top tips from me after using MQ for many years. |
|
| Back to top |
|
|
|
|
