Rebert. Thank you so much for the detailed answer! dakash
On Fri, May 16, 2008 at 11:24 AM, Robert Greig <[EMAIL PROTECTED]> wrote: > 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 <http://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 > -- Regards, Daniel Cohen-Sason
