qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <ai...@apache.org>
Subject Re: AMQP 1.0
Date Thu, 19 Mar 2009 15:53:20 GMT
On Thu, Mar 19, 2009 at 2:05 PM, Rajith Attapattu <rajith77@gmail.com> wrote:

> Based on my experience with end users I found that people are very
> keen on sticking to the JMS API's as much as possible.
> Most of them were moving from an existing JMS provider to Qpid.
> If they have to use anything vendor specific their strong preference
> was to use configuration files, jvm arguments, flags etc...
> Using non JMS API's is something they want to avoid as much as possible.
> So from an end users pov, when switching a provider I would like to do
> as less work as possible and having portable code is a big plus point
> IMO.
> Even for an existing Qpid user, when switching from an 0-8/0-9 to 0-10
> to 1.0 this approach IMO provides a more pain free strategy.

I totally understand this desire for portability, and I can see why
users would benefit from sticking to JMS APIs wherever possible. My
point is that writing portable JMS requires not just passing the right
parameters to the right methods, but expecting the correct semantics
from those parameters.

It doesn't help my app's portability if it turns out that I also need
to put a magic string into a properties file for it to work as I
expect. That's something that's likely to be found in QA.

IMO, it's much better for me to have to cast to something that
specifically identifies the depedency and, hopefully, has a comment
about why that's there. That's something that the compiler picks up
when I swap out on JMS provider for another.

- Aidan

Apache Qpid - World Domination through Advanced Message Queueing

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message