All,
Purchasing, Administering, monitoring, and configuring a queue manager is
far more expensive then using MQClient. If DB update coordination is not
needed, then using MQClient should be considered. Our TCO analysis clearly
shows a substantial benefit in reducing MQServer instances. This is
especially true for applications that have relatively low volume.
Grouping such apps together to share a queue manager through MQClient has a
great many advantages.
Reduction in MQAdministration and administrators.
Reduction in software licences.
Reduction in MQ savvy specialists.
Creation and adherence to firm wide standards (naming, design patterns,
security, ...)
Focused monitoring, paging, alerting, accounting, charge-back...
When creating generalized the MQ Computing environment we've been able
to provide far better Failover and DR services that meet or exceed SLA
requirements.
Yes we use SSL, Yes we use a security exit. Yes we collect statistics
for performance and usage based charge-back. Yes we enforce standards.
Administering SVRCONN channels can be localized by creating unique
listener processes for each application (or sub-application). Naming
standards also help here as well.
Applications are encouraged to utilize "exception" queues for error
handling.... lots more on this. The point is defining a clear
"onboarding" process that includes design reviews if needed.
In line with IBM's Service Integration Bus
just my two cents...
Philip
Scott Meridew
<[EMAIL PROTECTED]> To:
[email protected]
Sent by: MQSeries List cc:
<[EMAIL PROTECTED] Subject: Re: QM or MQ Client
Argument
wien.ac.at>
07/29/2005 09:52 AM
Please respond to
MQSeries List
I completely agree with T.Rob on this one. Clients are free...and you get
what you pay for. I like removing the mystery that is the network from my
concerns...and clients, although flexible and cheap, simply further my
headaches.
Scott Meridew
Director of Professional Services
TxMQ Inc.
Office 716-564-1700 x27
Mobile 416-846-9939
Home Office 905-693-8535
-----Original Message-----
From: Wyatt, T Rob
Date: 29/7/05 8:22 am
To: [email protected]
Subj: Re: QM or MQ Client Argument
Hi Michelle,
We may be a bit conservative in that we prefer full QMgrs with local
bindings here for several reasons as follows:
With local bindings you get trusted authentication at the OS and
authorization with the OAM. With SVRCONN channels you cannot trust the
authentication unless you use SSL and take precautions to secure the
certificate stores on the client hosts. In addition, SVRCONN channels do
not provide authorization unless you use an MCAUSER value or an exit such
as BlockIP2 which will filter out privileged IDs like mqm or blanks. By
default a SVRCONN channel opens up full admin privileges to the whole
world.
With a SVRCONN channel the MCA puts the full MQ API under control of the
remote program which may or may not be well-behaved. With server-to-server
channels the MCA is IBM's code. In the most mild case you can get clients
who do not use FAIL_IF_QUIESCING and prevent a clean shutdown of your QMgr.
In the worst case you can get clients who bring your QMgr to it's knees.
We had a vendor-written client with a reconnect loop that had no sleep.
Everything was fine for a while then one day it hiccupped and get into the
reconnect loop. Tried to reconnect about 1000 times per second. Filled
the listener backlog, prevented all attempts to connect to the QMgr by
other channels (including our administrative tools) failed. Since we were
using inetd, we could not keep the amqcrsta processes down long enough to
restart the QMgr. Nowadays if we let clients connect at all, it is to a
client concentrator QMgr and not our major application QMgrs.
When using clients if you get a 2009 Connection Broken response you do not
know if the connection was broken before or after it reached the agent at
the QMgr. If you did a GET or PUT outside of syncpoint and get a 2009 you
may - or may not - have completed the call on the QMgr. So let's assume
you are doing everything under syncpoint and get a 2009 on the COMMIT. If
you had removed messages from the queue and the COMMIT never made it to the
agent, you will get them back again. Hopefully you coded to recognize them
as dupes. In the case of a PUT, you really do not know if the PUT was
successful. You can get around this with code by placing a message into a
sync queue outside of syncpoint. Then you GET the same message under
syncpoint and do any other GETs or PUTs for your transaction. If you get
a 2009 on the COMMIT you can check the sync queue to see if the token
message is there or not. Of course it may sit under syncpoint for several
minutes before being rolled back when the channel agent times out.
In general, we have found that having a full QMgr is less costly than
making the client robust enough for our application requirements. I
believe this is in fact the basis for IBM charging as much for the
transactional client as a full QMgr. The exceptions in our shop are things
like inquiry transactions or applications which have the capability to
resynch themselves automatically and do not store state in the messages.
Hope that helps,
-- T.Rob (I'm donning my asbestos suit in anticipation of a firestorm
now!)
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
Of Michelle Russell
Sent: Friday, July 29, 2005 2:40 AM
To: [email protected]
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
