qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Cohen-Sason" <dak...@gmail.com>
Subject Re: SubscriptionManager implemtation for Java Client
Date Fri, 16 May 2008 16:28:10 GMT
Thank you so much for the detailed answer!


On Fri, May 16, 2008 at 11:24 AM, Robert Greig <robert.j.greig@gmail.com>

> 2008/5/15 Daniel Cohen-Sason <dakash@gmail.com>:
> > 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

Daniel Cohen-Sason

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message