Try to debug a service oriented at 3:00AM when all you got is a queue name to go on and your critical financial start-of-day application is getting a bad data enima and your application SME has had enough of his/her crappy job and busted the batteries out of their beeper.
I understand that in this age of OVER doing things and making everything nicey nice and looking like we all got degrees from MIT. BUT...what often is best is the KISS method.
I have been in these situations and what people take for granted when naming "BUSINESS OBJECT" sort of eludes the actual person who is harpooned with the process of figuring out what the problem. And also from experience it isn't the MSTER of names that will take the heat for the application / infrasturcture not working.
We do a better job if we design and NAME system that are a little less abstract and a lot more realistic. I know that sometimes this is not possible but......................................................:-)
bee-oh-dubble-bee-dubble-egh
From: "Kelly, Steve" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Questionable MQ infrastructure design Date: Mon, 14 Jul 2003 17:26:01 -0400
Interesting. Agree with channel names but queue names ? In a service-oriented architecture don't you want your queue names to identify the shared service they drive. So, for example, UPDATE.NAME.AND.ADDRESS, CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we really care who the sending application is? Yes, you'll want to know if something goes wrong, but do you need it in the queue name ?
Steve.
-----Original Message----- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: 14 July 2003 12:15 To: [EMAIL PROTECTED] Subject: Re: Questionable MQ infrastructure design
The Queue name I push when we a developing infrastructure is SendingApp.ReceivingApp.AnythingYouWant
Channels are generic-ly Sender.Receiver with variations considered for multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev, SIT, UAT, QA, Prod, DR)
bobbee
>From: [EMAIL PROTECTED] >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Questionable MQ infrastructure design >Date: Sun, 13 Jul 2003 18:01:36 +1000 > >Hi, > >We have a similar name scheme for channels except much shorter.... SRC_DST >and optionallyPROD_SRC_DST, not by application though. > >For queues,we normally use a qualifier on the end of the queue name/type >for >the type of data i.e. > >ie app_type.pgp (PGP encrypted data) >app_type_subtype.xml > >etc > >Same goes for Transmission queues and initiation queues > >app_process.initq >app_process.txq > >I think you can see the pattern.. > > >Sid > > > >-----Original Message----- >From: Armand ten Dam [mailto:[EMAIL PROTECTED] >Sent: Thursday, 10 July 2003 10:58 AM >To: [EMAIL PROTECTED] >Subject: Questionable MQ infrastructure design > > >Hi all, >For an integration project I have been asked to adopt an MQ naming standard >that reflects a very unusual approach in MQ-based integration. I have never >seen this approach before and have serious concerns in adopting any of it. > >Key in the design is the use of separate queue managers for each >application >pair. E.g. if an application interfaces with eight different distributed >applications this would result in eight separate queue managers on a single >system. > >Some examples: >Queue manager: >QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME >Channel: >CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP >Transmission queue: >TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP >... > >Obviously this does not reflect best-practice, seriously impacts >scalability, makes support of the MQ infrastructure difficult etc. > >As it looks like it will be a bit of a political discussion to get this out >of the way, >I am looking to gather as much 'neutral' feedback to back me up. I would >appreciate it if some of you could shed some more light on the implications >of the above approach. > >Any insights much appreciated, >Thanks, >Armand > >_________________________________________________________________ >Hot chart ringtones and polyphonics. Go to >http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referr >al=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp > >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 > >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
_________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
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
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
_________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
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
