| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Naming Convention Survey/Query |
« View previous topic :: View next topic » |
| Author |
Message
|
| Michael Dag |
 Posted: Mon May 26, 2008 3:48 am Post subject: Naming Convention Survey/Query |
 |
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I am looking for samples of naming conventions
I personally use FromApplication.ToApplication.MessageName_MessageType a lot and covers a lot of ground...
Implementation samples of this convention are:
APPA.APPB.CUSTOMER_INFO_REQ
APPB.APPA.CUSTOMER_INFO_RSP
APPC.APPA.CUSTOMER_INFO_ANS
I am planning some experiments with MQDocument to see if more information can be extracted or deducted from plain Queue definitions,
like go through a 2 step process
whereby using a mask like above tells me which applications could be
detected from the data:
- APPA
- APPB
- APPC
and wheter they are used as fromApp or ToApp or both...
which messageNames exists:
- CUSTOMER_INFO
and what messageType exists:
- REQ
- RSP
- ANS
Etc...
these lists of 'found values' can then be 'confirmed' or flagged as
invalid (for example ANS instead of RSP) and deleted from the 'found' lists...
Then when the second step in the process is run, it can detect which objects do not conform to this convention.
In order to test my logic and procedures / theory I would like to know what naming conventions you use.
Another usage could be a report showing:
APPA has 1 interface(s) to APPB comprising of:
messageName1 type Request (if applicable)
APPB has 1 interface(s) to APPA comprising of:
messageName1 type Response (if applicable)
APPC has 1 interface(s) to APPA comprising of:
messageName1 type Unknown (if applicable)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Mon May 26, 2008 8:28 am Post subject: Re: Naming Convention Survey/Query |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
| Michael Dag wrote: |
| I am looking for samples of naming conventions |
That's like asking "what's your favorite color". 
Many companies have MQ naming standards but they do vary.
- Some MQAdmin have gone with long cryptic queue names and then create shorter alias queue names that applications use. (Security is set to not allow access to QL.)
- I've seen an MQ naming standard where all local queues begin with the QMgr name. I prefer to not do this. I have migrated queues from one QMgr to another and then it becomes very weird.
- Personally, I've always gone with the z/OS dataset style naming standard:
i.e. The first 3 qualifiers are predetermined.
ddd.eee.aaa.s01.so2.etc..
where
ddd is the Division Name
eee is the Department Name
aaa is the Application Number or Code (or Project Name)
s01 is an application defined suffix
s02 is an application defined suffix (optional)
The application can any number of queue suffixes up to the max queue name length.
Don't forget (in your new product) that an MQ naming standard includes channels, process and namelist.
i.e. For channels:
- FromQMgrName.TO.ToQMgrName
- FromQMgrName.2.ToQMgrName
- FromQMgrName.ToQMgrName
Some MQAdmins like to append "CH01" or "C01" to channel names.
For Process Definitions and Namelists, I use the above noted Queue naming standard for processes and namelists.
I'm not a big fan of appending characters to MQ objects to state the type.
i.e. Some people like ".LQ" or ".QL" for local queue or ".P" for a process.
If you have a local queue that ends with ".QL" then you decide to migrate the queue to another QMgr Name, it is really confusing to recreate the queue as a remote queue but have a suffix of ".QL".
Remember, a GOOD MQ naming standard should reduce the MQAdmin's workload and protect an application from ever having to change a property file or IniFile (or worst, hard-coded queue name) because the MQAdmin moved/migrated some queues.
That's my 2 cents.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon May 26, 2008 6:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
A good naming standard for queues is AppName.MajorFunction.MinorFunction
Having everything in upper case is very common, but it doesn't have to be like that. I guess it just saves having to use the shift key and worry about case when typing the names.
AppName is usually 3-8 characters and identifies the serving or receiving application or major business function which "owns" the queue. The MajorFunction is usually a component of the application, eg. CUSTOMER BILLING. The MinorFunction is a particular purpose for the queue. eg. updates, enquiries and may have further sub functions.
eg. MYAPP.CUSTBILLING.ENQUIRY.REQUEST
MYAPP.CUSTBILLING.ENQUIRY.REPLY
MYAPP.CUSTBILLING.NEWCUSTOMERS
MYAPP.CUSTBILLING.UPDATE.DETAILS
MYAPP.CUSTBILLING.UPDATE.BILL
Don't include any identification of the "sending" app in the name, as this will allow the queue to be reused by other apps. Think SOA - ESB !
There are other common naming standards for queue managers, client channels, distributed queuing channels, cluster channels, clusters, name lists, processes, etc.
_________________
Glenn |
|
| Back to top |
|
|
| jsware |
| Posted: Mon May 26, 2008 11:34 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I use the following standard (I call it the laid standard) - queue jokes about "getting laid" 
[LC.]LA[.LG][.IO[.RC][.RA[.RG]]].ID where:
[] denotes an optional part which means it reduces to LA.ID as the simplest form.
LC = Local Corporation/Company Name
LA = Local Application Name
LG = Local Application Group (for grouping queues within application)
IO = INB/OUT for inbound/outbound indicator
RC = Remote Corporation/Company Name
RA = Remote Application Name
RG = Remote Application Group
ID = Identifier of message.
You only need the optional parts to avoid queue name conflicts. The IO part is also used so its clear(er) whether a part is a local part or a remote part (remote parts always appear after an "INB" or "OUT" part.
We use full stops between parts and underscores between words that are within a part (e.g. MY_APP.MY_MESSAGE).
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue May 27, 2008 2:48 pm Post subject: Re: Naming Convention Survey/Query |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| RogerLacroix wrote: |
That's like asking "what's your favorite color".
|
True, just trying to find out the most favorite colors.
| RogerLacroix wrote: |
Don't forget (in your new product) that an MQ naming standard includes channels, process and namelist.
|
No new product planned, just an extension of MQDocument and yes other objects will be applicable as well.
| RogerLacroix wrote: |
Remember, a GOOD MQ naming standard should reduce the MQAdmin's workload and protect an application from ever having to change a property file or IniFile (or worst, hard-coded queue name) because the MQAdmin moved/migrated some queues.
|
This is no quest for the best naming convention, just trying to get a rough idea (outside my own box...) of what others are using and looking for patterns for a parser.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 27, 2008 6:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Try: area.meaningful_name.src.tgt
And src may well be XXX
examples would be
CUST.GET_CUST_ACCT.XXX.BUS (QL)
CUST.GET_CUST_ACCT.WEB.BUS (alias with high def prio)
CUST.ACCT_AGGREG.BUS.BUS (you get the picture...)
CUST.PUBLICATIONS.BUS.SVC (etc...)
Enjoy 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
