Robert: We're a very small group of old-timer mainframe programmers who would like to assemble a system of open source parts for the mainframe environment (z/OS) to work with old legacy data. Among other parts, the proposed system (which is in its infancy) will require a queuing mechanism. In investigating the availability of non-proprietary queuing protocols, I came across AMQP, and then found my way to QPID. My basic requirement for this piece of the software is to have open source queuing software that I can run on z/OS.
I originally started with the C++ version of QPID, but decided to look at the Java version to see if I could minimize development cycle. That's when my confusion with AMQP and JMS started. I'm very new to JMS as well, and don’t know if it is a wrapper for other underlying, possibly proprietary products, or it is a complete queuing system on its own. One of our main goal is to minimize requirements for proprietary software. Once again, thank you for your help. Kamran Saadatjoo Open Flow Systems, Inc. 404-247-0454 (Cell) -----Original Message----- From: Robert Greig [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 10:40 AM To: [email protected] Subject: Re: General question regarding Java QPID 2008/5/7 Shahbaz Chaudhary <[EMAIL PROTECTED]>: > Hi, I also started testing with the QPid version of the stack (rather > than the Red hat mrg) because Qpid has a non-jms Java api. On trunk (i.e. not yet a released version) there is a non-JMS low level API. > I was hoping to avoid JMS entirely, it sounds like the standard and the > expected practice is actually to use JMS for java based projects rather > than the AMQP specific api? So far, we have found that almost all our users want a JMS API since most people are either migrating from another JMS product or are familiar with JMS due to its ubiquity. Things like Mule or Spring work out of the box with Qpid for example because it is JMS compliant. However, it may be that some people want to interact directly at the protocol level and that was the motivation for having another API. I would be very interested to know your reasons for wanting to avoid JMS and also, if you can share it, what your use case is. This is so that we can make sure we address all your requirements in the next release(s). The people who have worked on the low level API can also perhaps help out here. Thanks, Robert Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008 11:32 AM Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008 11:32 AM
