Dankie Francois. The ideal solution for my client would be to have MQServers at all the remote locations, but unfortunately the client is VERY price sensitive and will not be able to afford it. He does however still want assured one time message delivery and that is where the concern about assured message delivery using clients came from.
Thanks for everyone's comments. Regards Andre van Zyl -----Original Message----- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: 27 May 2003 12:53 To: [EMAIL PROTECTED] Subject: Re: MQ Client Andre, I think one of the concerns in the "server concentrator" setup is that the "window of opportunity for something to go wrong" is bigger when the clients connect to a server that is a long way from it or when the client connections are slow. Yes, you must use syncpoint, and yes, you must use COA or COD or both, but you need to think about what must you do when something goes wrong. For instance, say you receive a COA but no COD and then the connection brake? Is that good enough reason to resend the message or not? Maybe it will be best if the "server" side application know how to handle duplicates, so that if the client does not know what to do, then it can just resend. Also, if the volume is high, then server to server connections is usually faster. Some pros for client connection: Client can connect to more than one QM at a time. Client can automatically use alternate channels when primary is down Client is really cheap Simpler admin Cons Performance suffers No DB XA stuff No local Q's Expose to network outages memory overhead on server for every client connection no clustering no UOW coordination Client is synchronous less control over channels, no keepalive, No batching of high volume messages Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] "van Zyl, Andre" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .SAPPI.COM> cc: Sent by: MQSeries Subject: Re: MQ Client List <[EMAIL PROTECTED] N.AC.AT> 05/27/2003 03:46 PM Please respond to MQSeries List Thanks -----Original Message----- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: 27 May 2003 02:30 To: [EMAIL PROTECTED] Subject: Re: MQ Client >The question / concern I have has to do with assured message delivery when >using MQClients. >We are starting a new project which involves one central MQServer with >several distributed MQClients (all connected via a secure WAN). >We know that with MQServer, message delivery is assured. It is however >expensive to have many queue managers all over the show if the same >objective can be obtained by means of MQClients. >The only issue which now arises is how do I ensure assured message delivery? Andre, The semantics of messaging is exactly the same for a client as for a locally connected application. In other words, in order to do reliable messaging in a local application you must follow a certain set of rules like issuing MQPUTs and MQGETs under transactions etc. These rules are exactly the same for a client. One area which often concerns programmers is the MQCMIT call. What happens if you lose your network half way through an MQCMIT verb and get a MQRC_CONNECTION_BROKEN reason code. Did the transaction commit or didn't it ? Well, this is the same for a local application, you are not guaranteed to get a definitive answer on your transaction commit even for the local application. If you really care, you must do some 'known' action (like put a message to a queue) that you can subsequently check the next time you connect. The principle difference between a client and a local application is that clients (at least the free ones) can not have other resource managers involved in the transaction. So if you want a client application to update a database in the same transaction as an MQPUT call then you should either have a real Queue Manager or use the new Transactional Client product (which costs money). So, on the face of it, you can now do pretty much everything as a client that you can do locally. This does not mean however that regardless of the size of your organisation or the location of your applications that you should just have one server in the middle and everyone else connect as clients. There are many reasons why you might want queues more localised to your applications quite apart from the limiting factor of how many applications is it reasonable to have a single server serve. Hope this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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 ============================== Disclaimer =============================== "This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like". ========================================================================= 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 ============================== Disclaimer =============================== "This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like". ========================================================================= 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
