We have been coding Java/MQ frameworks for about 3 years now, and our handywork has gone through quite an evolution. In a high volume environment with a lot of synchronous messaging, we ran into some problems with the methods on the queue manager object being synchronized causing contention between PUTters and GETters. This caused us to go to more of a pooling concept where we have specific objects for PUTting and some for GETting. Then, for load balancing and failover, we had to create 2 pools each client connected to 2 queue managers. This has been a long and fairly painful process scraping quite a bit of metal, but we have a fairly sophisticated framework. I feel like in this day and age, this sophistication might be available out of the box in JMS or IBM's CCF (JCA), but we haven't dug into it that much.
Comments? ---------------------- Forwarded by Mark Nofziger/OH/BANCONE on 05/17/2002 09:16 AM --------------------------- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/17/2002 08:45:54 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Java or JMS -which way to go? For our VB apps that run on Windows, our VB wrapper does the trick quite nicely. We created a separate one for VB and a separate one for COBOL. But yes, that VB one is rather limited as we have way more JAVA apps on a variety of platforms. As far as the environment that this wrapper would be running in, it would almost always be a Client, be it on a desktop pc or server, as we are moving towards a Client Concentrator model and limiting the number of MQServers we have to maintain. I keep reading 2 reoccurring negative comments about JMS. One, that performance suffers over straight JAVA. Does anyone have numbers or docs to explain this? And two, that it does not provide full MQSeries functionality. Does anyone have a list of what JMS does not support? Any showstoppers or just some of the weirder, less often used things? We have quite a few existing apps that utilize the IIH header to enter our mainframe quoting system. Does JMS support the IIH header? If not, that would be our showstopper. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Jitkhoon Low [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 4:43 AM To: [EMAIL PROTECTED] Subject: Re: Java or JMS -which way to go? Hi If u wan to do a wrapper......forget about using VB. A wrapper should be as portable as possible. Using VB restrictive urself to Window platform only. So ur decision is either to do with Java MQ client wrapper or JMS client wrapper. From experience, i find that JMS client is easy to deploy if u have the necessary application server setup already. U need a few jar files from MA88 patch and ur application program, and those are stuff enough for u to hook up to the messaging network. very light weight but at a cost of not having the full features offered by MQSeries. If u use Java MQ client wrapper, there is a need to do more during the deployment, u need to setup the client environment etc. U get to have the features of MQSeries. Of course, if all ur applcations are intended to run on the same machine as the MQSeries Server, u wont have much hassle. For a truely distributed applicaation network...JMS would be a good choice in my opinion. So why not develop two flavour of the wrapper, JMS and Java, its really not very difficult. Let the user of the wrapper chose which one is more important to them. ease of deployment vs featue. There is no definite right or wrong, just appropriateness. Regards Low Jit Khoon Software Engineer Lido AeroNet Pte Ltd 80 Raffles Place #47-01 UOB Plaza1 Singapore 048624 Tel: 3790144 Fax:3790150 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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 This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. 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
