insightful as always
"Miller, Dennis"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: MQSeries Subject: Re: Transaction Names
List
<[EMAIL PROTECTED]
N.AC.AT>
06/23/2004 02:10
PM
Please respond to
MQSeries List
Hmmm...I do believe in the notion that a queue is a (very) special case
of a database. However, in this respect I think they are (very)
different. Relational tables typically have a formal structure that
constrains their content to the purposes for which they were designed.
MQ queues (setting aside the MD), have are unstructured, which means
their content is comparatively freeform and unrestricted.
Theoretically, any queue can contain anything, which begs a tough
question about naming queues after what they contain. Take an XMITQ, for
example. No one names an XMITQ after what it contains. The closest I can
come would be something like: "xxxxx.MESSAGES.BOUND.FOR.QMGRx". Or a
bridge queue: "xxxxx.TRANSACTION.REQUESTS". Or the DLQ:
"xxxxx.MESSAGES.WITH.NO.PLACE.TO.GO". Or an INITQ:
"xxxxx.TRIGGER.MESSAGES".
Certainly we can (and usually do) assert some discipline over what kind
of messages go to which queues. But the urge to name them accordingly is
a mindset that can paint you into a corner. Suppose we have
yourapp.ORDER.AMENDMENTS and then we want to serve functionality for
order creation from the same queue? In your case (RE:
YOURAPP.TRANSACTION_NAME) is it not possible for more than one
transaction to be served from the same queue? Or what if we need to
scale-up and have multiple queues for order amendments? (The subtle
point is that, strictly speaking, "yourapp.ORDER.AMENDMENTS.2" is a
deviation from the what-it-contains standard, as there is no such thing
as an "order.amendments.2").
I offer a third alterntive. Rather than naming queues after what they
DO or what they CONTAIN, how about mimicing the style used by MQ
developers and naming queues after what they ARE?
For example: QMGRx.HISPEED.XMITQ
CICSx.BRIDGEQ
QMGRx.DEAD.LETTERQ
QMGRx.BATCH.INITQ
myapp.ERROR.COLLECTIONQ
myapp.INBOUND.TRANSFERQ
myapp.COMMON.SUBSCRIPTIONQ
myapp.SILname.REQUESTQ
myapp.username.DYNAM.REPLYQ
Instead of: myapp.ORDER.AMENDMENTS
use: myapp.programname.REQUESTQ
Now, before getting too excited, it's important to understand one more
thing. You gave us the paradigm
MYAPP.TRANSACTION_NAME -> YOURAPP.TRANSACTION_NAME which is mapped by
qremotes/qaliases. The above suggestion pertains only to the QLOCAL
definition which is exclusive to the "->YOURAPP" side. I absolutely do
not suggest the same convention for the "->MYAPP" side which corresponds
to the QREMOTE/QALIASes. Over there, we need a different kind of queue
identity convention that is independent of the physical implementation.
There, it makes perfect sense to name queues according to content, or
more correctly, message structure. I like to think of message
structures as defined by "contract". For example, there would be a
contract for order amendments (that may involve one or more message
formats) and another for order creation. I would go so far as to
suggest that each contract be assigned a different QALIAS/QREMOTE name
even if they are originally intended for the same queue.
Regards,
Dennis
-----Original Message-----
From: John Scott [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 23, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Transaction Names
Thanks for that little "sound byte" - I like "queues do not do
anything". I agree with you.
My reasoning is that, like database tables and class names, they're
typically named after what they contain, not what they do.
You would have an "ORDER_AMENDMENT" table which is used by the
"update_order" program to update orders in the database.
Likewise, the update_order program would have an instance of the
"OrderAmendment" class passed to the "updateOrder" method of an instance
of the "Order" class to update the order.
Regards
John Scott
IBM Certified Specialist - MQSeries
Argos Ltd
-----Original Message-----
From: Randy J Clark [mailto:[EMAIL PROTECTED]
Sent: 22 June 2004 18:10
To: [EMAIL PROTECTED]
Subject: Re: Transaction Names
Our queues are named after what it is - we describe the contents of the
queue... because a queue does not "do" anything.
John Scott
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
.CO.UK> cc:
Sent by: MQSeries Subject: Transaction
Names
List
<[EMAIL PROTECTED]
N.AC.AT>
06/22/2004 01:29
AM
Please respond to
MQSeries List
I have already posted this question on mqseries.net, but I wondered if I
would get some more responses on the list server...
I am not looking for ideas on general MQSeries naming standards, I
already have those and there are enough examples in the archives to keep
anybody happy.
Our queue naming standard is basically APP_NAME.TRANSACTION_NAME.
Where APP_NAME is the name of the application that is allowed access to
the queue. We use alias/remote queue definitions to wire up
MYAPP.TRANSACTION_NAME -> YOURAPP.TRANSACTION_NAME
I am now looking in detail at the TRANSACTION_NAME. When I look at the
queues we have I see a mixture of TRANSACTION_NAME styles - some of them
are named after what the message content is (i.e. ORDER_AMENDMENT) and
others are named after what the applications (typically the receiving
application) does with the data (i.e. UPDATE_ORDER).
Thus we would have a queue called:
MYAPP.ORDER_AMENDMENT
or
MYAPP.UPDATE_ORDER
I wanted to canvas whether people preferred the "what it is" over "what
it does" or vica-versa.
Which style do you use and why?
Regards
John Scott
IBM Certified Specialist - MQSeries
Argos Ltd.
**************************************************************
Click here to visit the Argos home page http://www.argos.co.uk
The information contained in this message or any of its attachments may
be privileged and/or confidential, and is intended exclusively for the
addressee. Unauthorised disclosure, copying or distribution of the
contents is strictly prohibited.
The views expressed may not be official policy, but the personal views
of the originator.
If you have received this message in error, please advise the sender by
using the reply facility in your e-mail software.
All messages sent and received by Argos Ltd are monitored for viruses,
high-risk file extensions, and inappropriate content.
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
**************************************************************
Click here to visit the Argos home page http://www.argos.co.uk
The information contained in this message or any of its attachments may
be privileged and/or confidential, and is intended exclusively for the
addressee. Unauthorised disclosure, copying or distribution of the
contents is strictly prohibited.
The views expressed may not be official policy, but the personal views
of the originator.
If you have received this message in error, please advise the sender by
using the reply facility in your e-mail software.
All messages sent and received by Argos Ltd are monitored for viruses,
high-risk file extensions, and inappropriate content.
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
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
