Phillip,
You posted a very nicely worded response. You have brought up the same concerns
that we have addressed, we're not just doing charge-back just yet. Standards is the
key and maintaining control over the MQSeries architecture is just as important. The
developers and others cannot dictate how MQ is structured, because many don't
understand the ramifications of their demands. Without standards, the MQSeries land
would become a wild west of bollixed systems, similar to what happens on some other
distributed systems.
For running MQClients, we don't have many issues, especially something that is as
grievous as what had been described. I guess good programming talent within the
company may have something to do with it.
We're also onboard with the exception queues, we call them deferred queues.
Take care,
Wayne
======
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
*************************** IMPORTANT NOTE ***************************** The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates ("BBH"). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. ************************************************************************
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.comArchive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
