2008/5/15 Daniel Cohen-Sason <[EMAIL PROTECTED]>: > Is there any document where I can understand the two approaches for QPID > Java implmentation (JMS vs. Java)?
Currently there is not, however this questions has come up a couple of times so I will write a wiki page about it today. It is something of a contentious issue however and there was a long debate about it on the mailing list a while ago. > I really don't know which path to take. where can I have more details about > it? What follows is my own opinion, but your questions show that the concerns I had were valid. > Please correct me if I'm wrong: If I adopt the JMS approach, I'll have > richer api and more stable implemtation? You will certainly get a much more stable implementation - almost certainly better performance too. The current M2.x codebase - including the JMS client - has had over 18 months of real world production usage. The API itself is widely documented on the web and it also should work with third party packages with little effort, e.g. Spring or Mule. The non-JMS Java API is only available on trunk (M3). I *strongly* recommend that you do not use trunk unless you really want to be at the bleeding edge. If you use the just-released M2.1 version you will have the best results. You could take the M2.x branch from svn if you want to keep up to date with bug fixes and tweaks, but that codebase is stable. > So what's the point of QPID team to maintain 2 "packages"? This was exactly the confusion I wanted to avoid. JMS is, whether people like it or not, the standard API for messaging for Java developers. Some people might not like certain aspects of it but basically it is fine for 99% of use cases. There is only so much you can do with a messaging API so any other API is not going to be radically different anyway. Some people wanted to offer a "low level" API that exposed the underlying AMQP protocol. This was because they wanted to expose certain features of the protocol directly (like the ability to wire exchanges and queues). However I do not believe you need to create a separate API to achieve this, since you can do what every other JMS vendor has done and extend JMS with some extra interfaces and methods. It may not be the most elegant approach but it does mean that users do not have to rewrite their applications to take advantage of one feature! An analogy might help: both SQL Server and Sybase use the Tabular Data Stream (TDS) protocol for client/server communication. Neither vendor supports application development using an API that exposes TDS directly - people use ADO.NET or JDBC or whatever. Some people might want to work at the TDS level but they are generally tools vendors or some other specialised case and neither vendor to my knowledge promotes in any way a TDS API. I do not believe that any API that directly mirrors the protocol is useful to end users because it makes life difficult when the protocol changes. Anyone, for example, who had written an application against an API that mirrored the 0-9 protocol would have to change it just to upgrade to 0-10. That is unacceptable for most users - certainly I would be irate if I were a user and there was no upgrade path. Using JMS or some other higher level API provides the ability to have an upgrade path. So in summary, use the JMS API. I'm sorry this confusion exists; we will work to make it clearer. Let me know if any of this is still confusing! RG
