| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Strategies / Best Practice for .bindings files |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Tue Feb 17, 2015 12:30 pm Post subject: Strategies / Best Practice for .bindings files |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I need to come up with a recommendation on whether an app should use one .bindings for all environments, or a separate .bindings for each. Not being a JMS guy, here is what I am thinking.
All the app's environments in one .bindings file - This requires different names for the objects inside the JNDI so the app can distinguish between QA and PROD while referring to the same .bindings file. This can be a Pro or Con I suppose. The app's config must differ between environments to refer to the correct object name. This can be seen as tedious. Or can be seen as protection from calling the wrong environment. But with all objects for all environments available in one file, mistakes still possible.
However it allows the app to only maintain one .bindings file for its app.
Or a separate .bindings file for each environment?
The same names can used for the objects in the JNDI. As in, the QCF for QA can have the same name as the QCF for PROD. The app's config is identical between QA and PROD, and reacts according to the .bindings file presented. Pros and Cons to this.
The app must maintain a library of .bindings file and the risk is the wrong one is loaded into the runtime, since it always has to be named .bindings.
We can use different object names in the different .bindings files. As in the Integration QCF is named different than the QA QCF.
Now that I typed it all out, I'm thinking separate .bindings files for each environment, with different names for each object (MY_QCF_QA, MY_QCF_PROD, MY_QUEUE_QA, MY_QUEUE_PROD) is a little more work for the app, but the best protection from inadvertently connecting to the wrong environment if they also mess up and pull their authentication credentials from one environment to another. They can load the wrong file, they can load the wrong authentication credentials, but none of the object names they are looking for are there.
What do you do?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Feb 17, 2015 12:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Have you thought about having everything the same but
- qmgr name to use different in prod
Thinking here about using a channel tab for the connection. Using a *qmname value only valid for prod.
- Different signer certs between dev and prod:
- 2 internal CAs one for PROD, one for everything else
- choosing 2 different security providers between prod and other environments
prod is signed by Verisign, other environments by for example Comodo, GoDaddy, Symantec, GlobalSign etc... to name only a few US ones...
And this is if you cannot use an internal CA for your non prod environments...
The likelyhood that you have both a prod CA and are using a prod qmgr in a non prod environment is minimal... unless you create some of the non prod environments by copying a prod environment.... But then the likelyhood of forgetting to change the essentials is the same, regardless of the security features you built in.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 18, 2015 6:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would tend to go with a separate bindings file for each environment, and the application then use the same name for all of the JMS objects within that file.
Then the application code stays the same as it is promoted between environments, and the deployment/release operation makes sure the environment to host the application is configured correctly.
That's generally the point of the bindings file. In application servers is why you use a local JNDI repository, so that when you move a WAR or EAR file to the next environment, the configuration is set at that environment.
It's akin to bar file overrides in Broker, or etc. The bar file doesn't change, just the broker config it's deployed to. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 18, 2015 1:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Thanks guys, food for thought..thinking....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
