My rule of the thumb for it: 1. If it is a server MQSeries application and it owns the objects on its local queue manager (i.e. does not share its queues with other applications) you can fire any configuration files or system-dependend staff as registry and use MQSeries as the configuration manager. In this case, using aliases allow re-configuration and even changing topology without affecting the data on the queues.
2. If it is a client application or it shares queues, you will have to provide separate configuration data source with queue names etc.. (Sure, it is always better to have more flexibility than less, but it comes at a price ;-) ). Aliases are still useful as an additional indirection and access control layer. In this situation application owners are usually bound by some MQ administration policy though so they have less freedom of choice. Personally I never used aliases in the development and never had to sorry about that but I guess in production they should be really useful. Hope this will help Pavel ---------------------------------------- Message History ---------------------------------------- From: Stefan Sievert <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 05/30/2002 05:11 PM MST Please respond to MQSeries List <[EMAIL PROTECTED]> DELEGATED - Sent by: MQSeries [EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: alias queues vs hard-coded names Hi Allan, I am most likely not be representative for the general view, but here it is anyway. :-) The first rule I follow (and recommend to anybody who wants to hear it) is to *never* hardcode *any* MQ object names in any program, but to instead read them during startup from a file or a database, or passing them in as command line arguments. This will allow you to use the same program for many different queue names if you wish to. It also isolates your application from infrastructure changes. Additionally, it often makes a lot of sense to use aliases as another level of isolation, or to implement certain security models. As you know, security checks are performed against the name in the MQOPEN call. So, you can define a local queue that nobody has permission to put/get from, but allow access through an alias queue. It depends on the specific requirements of every installation, though. If you do use alias queues as a company standard, your infrastructure team can change physical queue names (and location) without any impact on existing application code. Considering that even a simple name change in an application with a re-compile or the change of a configuration file usually requires re-testing of the application, using alias queues can save a lot of pain (and money). The administrative overhead of creating alias queues has to be weighed against the advantages it will have for the shop. So, "never hardcode, use alias queues where sensible" would be my view. I'm looking forward to hear the philosophies/experiences of others... :-) Hope that helps, Stefan >From: Alan Turnbull <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: alias queues vs hard-coded names >Date: Fri, 31 May 2002 09:24:07 +1000 > >hi > >Just wondering what the general view is of using queue aliases as opposed >to hard coding queue names. > >I guess i am asking, if you are developing a new mq application would you >always use aliases as a matter of course (or the reverse, just hard code >names provided that those names are queue manager independant) > >thanks >alan >Alan Turnbull >Senior Developer >IITS > >Direct: (02) 9701 7333 Fax (02) 9701 7501 > > >[EMAIL PROTECTED] >Visit us on the web at http://www.qbe.com.au > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
