2008/5/7 Kamran Saadatjoo <[EMAIL PROTECTED]>: > 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.
OK, since z/OS has a good JVM and qpid has no native components (i.e. no C++ or C accessed via JNI) you should be able to get qpid to work. I am not aware of anyone getting qpid running on z/OS yet but if you run into any difficulties or have any questions please do let us know and we will do our best to help. > 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. Ah ok. Let me try to explain this. JMS is a vendor-independent API for messaging in Java. Nearly every messaging product that has a Java client implementation supports JMS. That includes IBM MQ as well as the open source products (e.g. JBoss Messaging). JMS in itself is not a queuing system, it is just an API. Think of it like ODBC - it isn't a database but an API to access a database. I strongly recommend you use the Qpid JMS API. If you use it, you will not be tied to Qpid plus you will be able to find examples all over the web for JMS programs. Obviously I hope that you think Qpid is great and meets all your needs but if you want to switch it should be relatively simple if you stick to JMS. You would have a similar choice if you picked IBM MQ - it has both a "native" API and it supports JMS. The native API has been around for a very long time whereas the JMS API is newer. Most development teams I have worked with that use MQ now pick JMS to avoid being tied too closely to MQ. So one question you may have is "how does AMQP relate to JMS"? AMQP is a wire level protocol, rather than an API. This means that you should be able to have a mixture of AMQP compliant products in your infrastructure and they will interoperate. This is independent of whether they are java or C++ or python. Let me know if you have further questions or if this isn't very clear. Robert
