I tend to agree with bobbee... while it might be nice to have an environment which is ultra-secure and never loses data, it's a cost/benefit decision. If you have a non-critical application with a supporting reconciliation process to make sure all data was received then I would use client since 99% of the time it will just work and it saves money. What we really need to avoid at all costs is an undetected failure.
Stephen Gordon
Application Messaging and Integration Architecture Team
|
Robert Broderick <[EMAIL PROTECTED]> Sent by: MQSeries List <[email protected]> 01/08/2005 10:59 PM
|
|
Hi Wayne,
I told Phill i would get involved in this one further But....
I came from a strick server to server environment. Being involved in the
deistributed side for the last ump-teen years (it seems) of my life I have
been in MANY environments that have used the Client facility (opps did I
just give away my back ground?). It worked fine, issues have been addressed
and suitable procedures were put in place to achieve the business solution.
When you think of it, isn't that what we get paid to do??
the
end
bee-oh-dubble-bee-dubble-egh
>From: Wayne Myers <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[email protected]>
>To: [email protected]
>Subject: Re: QM or MQ Client Argument
>Date: Fri, 29 Jul 2005 17:55:47 -0400
>
>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.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
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
