| Author |
Message
|
| ruimadaleno |
 Posted: Thu May 07, 2015 8:42 am Post subject: Looking for rules/best practices on broker + MQ marriage |
 |
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi all,
we are building the first applications that use MQ with broker, and we want to establish a set of rules to govern these kind of application development.
I'm looking for best practices on Broker + MQ marriage  so i'd like to get some advice rules, some good docs/presentations to govern this marriage so it doesn't end up in divorce 
my environemnt
Broker 8.0.0.4 (soon 8.0.0.5) running on windows 2008 R2 server.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu May 07, 2015 11:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Nothing specific if you thought about what doing maintenance means... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 07, 2015 11:11 am Post subject: Re: Looking for rules/best practices on broker + MQ marriage |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ruimadaleno wrote: |
| I'm looking for best practices on Broker + MQ marriage |
All the coding rules you'd apply to a well - behaved MQ application (don't use a string as a message id, don't browse the queue looking for a specific message like it's a database table, etc).
Specific gotchas:
- don't put an MQGet node in a loop within a flow
- don't use WMQ with anything other than the supplied nodes (i.e. do not use JMS inside a JCN)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inMo |
| Posted: Thu May 14, 2015 6:19 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Quote: |
| we are building the first applications that use MQ with broker |
Just curious - are you saying:
A) MQ & Broker are new to us
B) We've had MQ and Broker is new to us
C) We've had Broker and MQ is new to us (this might be a trick answer)
D) We are an application team being told we need to work with the MQ/Broker team
E) Something else |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri May 15, 2015 12:36 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi inMo
i think the option that best fits our scenario is option C)
we are using WMB for over two years for integration of heterogeneous Services (WMB is the ESB block in our SOA architecture), mainly with soap nodes (http/soap web services). We are not a pure development team. Apps/message flows are built by third party developers with our requirements althougt we have development knowledge (teorical - ibm certification and pratical - some message flows implementions). We also validate/test/approve and maintain message flows built by third party.
We have applications using MQ but they were completly designed by third party provider (political decisions of management)
Some future projects will require the usage of MQ (getting an high volume of messages flow third party providers and integrating in several information systems).
So, we have the Broker + MQ marriage running already but we need to understand what conditions must be met to get it running for many years
We want to deliver a document on policies/best practices that our third party developers/providers must comply to implement message flows using Broker + MQ. We also want to understand if the applications already running Broker + MQ are well fit to our environment/requirements.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Fri May 15, 2015 4:09 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| Quote: |
| . don't put an MQGet node in a loop within a flow |
We use this to process 100 messages at a time so that we don't
Have to commit for every message. Is there a specific reason why you are advising against it? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 15, 2015 4:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| paustin_ours wrote: |
| Quote: |
| . don't put an MQGet node in a loop within a flow |
We use this to process 100 messages at a time so that we don't
Have to commit for every message. Is there a specific reason why you are advising against it? |
I suspect it depends on what was meant by "loop".
It's always a bad idea to connect the out terminal of one node to the in terminal of a node that precedes that out terminal. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Fri May 15, 2015 5:56 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| we have a route to label node connected to the mqget and we do database inserts reading 100 messages at a time. this is much faster than doing database insert 1 message at a time. Just wanted to mention our use case. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri May 15, 2015 7:14 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What they mean is that MQGET can be repeatedly called by using a ESQL loop inside a compute node (and a propagate statement inside the loop).
Just avoid a wiring loop as the node stack limit will be reached pretty quickly.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| inMo |
| Posted: Fri May 15, 2015 8:25 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Quote: |
| the node stack limit will be reached pretty quickly |
And the stack limit number is? I've never reached it and curious to know what it is and/or what it depends on. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 15, 2015 8:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| inMo wrote: |
| Quote: |
| the node stack limit will be reached pretty quickly |
And the stack limit number is? I've never reached it and curious to know what it is and/or what it depends on. |
... you've never reached it, using a wire between the out terminal of a node, and it's own in terminal, or the in terminal of a node that is upstream/before that node?
It's kind of hard to reach otherwise. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 18, 2015 11:54 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Broker + MQ marriage |
I'm a bit late to this party, but isn't that a bit like a USA + UK marriage?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 18, 2015 11:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kimbert wrote: |
| Quote: |
| Broker + MQ marriage |
I'm a bit late to this party, but isn't that a bit like a USA + UK marriage? |
And those work just fine. Just fine.
(I love you darling. Now put the knife down ....)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Tue May 19, 2015 3:14 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
let me explain our problem:
WMB development is done by third party development teams (outsourcing) , so we must have in place a good set of rules/design guideline to avoid that each development team develops on it's own style and we end up with a headache of several "styles" of implementation.
I'm fully aware that some teams are good in MQ and others just heard about the concept , so there is a lack of knowledge that places risks in development of Broker + MQ .. and these risks must be controlled somehow, like providing the set of rules/guidelines for the WMB + Broker marriage.
Let's look at MQ like a database (just for example).
Now the develoment team says:
Hey i have queue and i what to put and read messages ( hey i have a table and i insert and read records from it)
Hey i need a new queue named xpto to throw some messages (hey i have a database and need to create some tables and throw some records on it)
as we know from our experience, letting the development team shake and sturn the database is not a good practice, there must be some guideline in place to avoid issues ... the same for MQ .. right ? 
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Tue May 19, 2015 5:36 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
The main one would be to allow MQ interactions only through the nodes provided by the broker. No MQ calls inside JCN's!
We had this attempted by a vendor once and we only put a stop to it when they asked us to deploy the MQ jar files to the shared-classes directory.
WMB is not WAS. |
|
| Back to top |
|
|
|
|
