| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Best practices for WMB development |
« View previous topic :: View next topic » |
| Author |
Message
|
| youssef |
 Posted: Tue Sep 12, 2006 12:41 am Post subject: Best practices for WMB development |
 |
|
Novice
Joined: 09 Sep 2006
Posts: 12
|
We are trying to develop a POC application using the message broker. We have build a integration enviroment where we have three QMs in a cluster.
The intial plan for the development was to to develop indiviual message flows and test and deploy them remotely on the integration env.
This truned not to be so good because
1) only one debug session is allowed,
2) many times we had to restart the broker because some flow stuck,
3) and it is slow relative to local message broker.
The alternative is to use local message broker on each development machine but it seems to be a constly price to mimic that on each development machine. Please advise.
_________________
Regards,
Youssef |
|
| Back to top |
|
 |
| mqmatt |
| Posted: Tue Sep 12, 2006 12:54 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Today, the license agreement only allows one unit test licence per full broker license. However, these terms are currently being reviewed.
Sorry I can't be more specific. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 12, 2006 1:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The license also includes a full install of the entire product stack on any development machines, AS LONG AS THEY DON'T CONNECT to anything.
So you can have each individual developer running a broker for unit testing on their developer machine. They just can't talk to each other.
As far as I know.
All license questions are best and only answered by your IBM Sales representative. You may also be able to get them to provide you with discounted licensing for additional non-production brokers as well.
But your IBM sales rep is the only person who can really answer licensing questions.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 12, 2006 1:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, aside from the debugger single-session problem, you can do a lot to limit the ability of individual developers to impact each other on a common broker by giving them their own execution group.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| msukup |
| Posted: Tue Sep 12, 2006 1:20 pm Post subject: |
|
|
Acolyte
Joined: 11 Feb 2002
Posts: 56
|
in our env (relatively static corporate world), we have one development broker with many developers utilizing it, rather than each on own machine. then maintenance, patches (for broker, db, os, etc) happens only once -- major plus. the philosophy being that you will need to work with each other, and all the flows will eventually need to work on one broker. you might as well get used to it now. besides that, you can better monitor what others are doing, as well as help troubleshoot others flows. Otherwise, you have to do a lot of import/export -- keeping changes in sync starts to become a hassle and becomes as much of a communications headache as sending out a notice that you are bouncing the broker.
in the consulting world, i know that individual broker installations work well, as consultants travel, and can work remotely with full install on laptops.
here is my advice for multi-user env:
1) if you need to bounce broker, announce it, and try not to do it with -i option. this will interrupt others' testing less. if you can, try not to bounce broker if you can do a "mqsireload" or a simple kill -9 of e.g.
2) schedule performance testing, as this tends to be biggest hog of resources, and causes most disruption to others
3) in dev, segregate misbehaving and new flows in their own e.g. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 12, 2006 2:27 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you give each user their own execution group, the only reason you need to bounce broker is for changes to shared-classes and user defined extensions.
Anyone making heavy use of either of those can have their own broker on the same machine.
And keeping things "in sync" between a developer's local broker and a development broker is as easy as having two domain connections in one toolkit.
And if you're doing any development without at least version control, then you deserve all the change management and "sync" headaches you end up with - plus a few production outages due to mistakenly deploying the wrong code.
The problem with a single development broker is that the impact of applying fixes to it becomes signifcant - everyone has to retest all their code and in a corporate environment getting that kind of approval can be ... challenging. You also have to manage an very large set of users on a configuration manager domain or assume that "development can be unsecure".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| msukup |
| Posted: Tue Sep 12, 2006 2:50 pm Post subject: |
|
|
Acolyte
Joined: 11 Feb 2002
Posts: 56
|
applying patches would have to happen in a common broker at some point anyways so that flows can be regression tested against the patch. whether this cooperation happens in development or further on up the food chain, that depends on your organization and your budget.
as for version mgmt -- even with version mgmt, you will still have to communicate to have people check in code, follow up with people, harrass people to finally check it in, and then threaten to take away their allowance and send them to their room if they still ignore you. hence, sync problems -- not a technical challenge, a people challenge. at least with commonly deployed code on a common broker, you can debug others' code without the obstacle of verifying their version of code against deployed version . . . |
|
| 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
|
|
|
|
