| Author |
Message
|
| pcelari |
 Posted: Mon Jul 25, 2011 10:57 am Post subject: Best practice setting up Toolkit for team access? |
 |
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
Would any experienced WMB admin share some insight in the best practice of managing a group of developers accessing toolkit and broker?
Is it possible to create a centralized toolkit installation for a multiple users to access, each with a different workspace and limited access to broker execution group?
I imagine it's better to avoid giving each developer a separate Toolkit installation, and the support need would grow out of proportion very quickly.
Thanks for sharing your insight!
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jul 25, 2011 11:04 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Norton ghost utility works well. The install is also able to run in silent mode as a script.
The idea of a single toolkit instance for multiple developers sounds sluggish to me. I wouldn't want to attempt it.
If you instruct all your people to use the default paths, its a pretty seamless operation.
It usually takes a day to get a good install fully setup and configured for toolkit and broker runtime, to include the default configuration and the needful Windows domain access from your local sys admins.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 25, 2011 12:07 pm Post subject: Re: Best practice setting up Toolkit for team access? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pcelari wrote: |
| Is it possible to create a centralized toolkit installation for a multiple users to access, each with a different workspace and limited access to broker execution group? |
I think you'll struggle to get the Toolkit itself running anywhere other than locally. If you do manage it, it's going to be slow going starting it up. You can have Toolkit running locally and a network mounted workspace but again you're going to get a lot of latency in there.
Most source code control & build tools have some mechanism for management of changes by multiple developers. IMHO it's far better to have each developer with a workspace gathered round such a repository than what you're suggesting.
Limiting access to broker execution groups has nothing to do with where the individual is running Toolkit, and you set that up in the usual way according to your site's requirements & standards.
| pcelari wrote: |
| I imagine it's better to avoid giving each developer a separate Toolkit installation, and the support need would grow out of proportion very quickly. |
Really? Do all your developers have a centralized install of Word that they use, or do they have a local copy that they run?
Installing Toolkit on multiple machines is no better and no worse than installing anything else on multiple machines. Put the install media image on a centralized location, script a silent install and push that out to the required machines. Your admins may well have such a push mechanism already in place for other software.
We've leveraged some Windows thing to get the best of both worlds; the "My Documents" folders for each user here are local to the machines, but are automagically sync'd with a copy on the network. I've had the trick used on the workspace directories so in the event of hardware failure I don't loose all the wonderful code I've typed and not put back in Subversion yet.
(I also routinely back up a PIP to the network drive as well, but it's not paranoia if they really are after you)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WGerstma |
| Posted: Mon Jul 25, 2011 12:08 pm Post subject: |
|
|
Acolyte
Joined: 18 Jul 2011
Posts: 55
|
If you do not want each developer to set up its own toolkit, you could also create teh basic installation on a Virtual Image and clone this for each developer (Though each image will need a valid Windows License).
You can use a centralised broker instance and provide each developer with one or two Execution groups. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jul 25, 2011 12:52 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| WGerstma wrote: |
| You can use a centralised broker instance and provide each developer with one or two Execution groups. |
It is much easier to sandbox locally rather than on a central box. Central box usually for DEV-INT rather than sandbox.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| WGerstma |
| Posted: Mon Jul 25, 2011 3:09 pm Post subject: |
|
|
Acolyte
Joined: 18 Jul 2011
Posts: 55
|
| lancelotlinc wrote: |
| WGerstma wrote: |
| You can use a centralised broker instance and provide each developer with one or two Execution groups. |
It is much easier to sandbox locally rather than on a central box. Central box usually for DEV-INT rather than sandbox. |
Agreed and prefered. But what about licensing if each developer gets his own MQ/WMB/DB instances? I think this is only managable in large firms with corporate licenses available. Or is there another model for low-cost licensing in development? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 25, 2011 5:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WGerstma wrote: |
| Agreed and prefered. But what about licensing if each developer gets his own MQ/WMB/DB instances? I think this is only managable in large firms with corporate licenses available. Or is there another model for low-cost licensing in development? |
There's the model described by the OP, where each developer has their own execution group on a central broker. The only "issue" with the OP's suggestion is trying to centralize the Toolkit as well.
You can vary this to 1 EG / broker per team / project / resource group if you don't have machine resource for 1 per developer. This cat can be skinned a large number of ways.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 26, 2011 4:35 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| WGerstma wrote: |
| lancelotlinc wrote: |
| WGerstma wrote: |
| You can use a centralised broker instance and provide each developer with one or two Execution groups. |
It is much easier to sandbox locally rather than on a central box. Central box usually for DEV-INT rather than sandbox. |
Agreed and prefered. But what about licensing if each developer gets his own MQ/WMB/DB instances? I think this is only managable in large firms with corporate licenses available. Or is there another model for low-cost licensing in development? |
Toolkit runs without license restrictions. The license fees are for Broker runtime. Toolkits are provided to facilitate the Broker runtimes. In fact, a fully enabled toolkit is available as a trial. So if the goal of this discussion is to save money, please explain how you will save money by making developers miserable sharing toolkit runtimes?
WMB licensing is based on PVU of the system that runs the runtime, not the toolkit.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| pcelari |
| Posted: Tue Jul 26, 2011 4:54 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
Thank you all so much for sharing the insight. It seems I was still in the UNIX and C development world from 15 years ago that all users login into a UNIX server for development. Well, time has changed, and the Toolkit itself is a huge application now - given our good, new, and fat Java! - which makes it infeasible to run multiple instances on a server.
I'll take the advice and give each developer a EG instead.
Many, many thanks.
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 26, 2011 6:03 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| pcelari wrote: |
| I'll take the advice and give each developer a EG instead. |
Heck, give 'em all a Jolt soda too.  
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 26, 2011 4:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| WGerstma wrote: |
| lancelotlinc wrote: |
| WGerstma wrote: |
| You can use a centralised broker instance and provide each developer with one or two Execution groups. |
It is much easier to sandbox locally rather than on a central box. Central box usually for DEV-INT rather than sandbox. |
Agreed and prefered. But what about licensing if each developer gets his own MQ/WMB/DB instances? I think this is only managable in large firms with corporate licenses available. Or is there another model for low-cost licensing in development? |
In the WMB 6.1 Announcement Letter, the following is stated. The topic is ignored in the WMB 7 Announcement Letter.
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP07-0437#Header_34
| Quote: |
12. Unit Testing
A. For distributed platforms
The Program license authorizes multiple developers to install one copy of the Broker Runtime, the Toolkit, WebSphere MQ and DB2 on a single Microsoft Windows machine or a single Linux machine running on Intel per developer, for purposes of "unit testing". "Unit testing" is limited to testing of configurations written or generated by such developer to confirm that such configuration functions as designed. Such authorized "unit testing" DOES NOT include any of the following:
1. Testing message flows on servers separate from the developer's machine. The developer may create local message flows that connect to remote servers hosting non-production applications and services in a unit-test environment;
2. Exchanging messages with any production application or system, or
3. Simulating production workloads for the purpose of testing scalability of any code, application or system in an integration test environment |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
