qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Greig <robert.j.gr...@gmail.com>
Subject Re: AMQP 1.0
Date Thu, 26 Mar 2009 22:41:35 GMT
2009/3/26 James Mansion <james@mansionfamily.plus.com>:

> I'm surprised about that.  Do you think jdbc provides similar portability?
>  The
> API might be pretty common, but there is no way on earth that makes
> non-trivial
> code portable between Sybase and PostgreSQL, for example - and nor even
> does sticking hibernate on top to generate SQL for you help either, for that
> matter.
> In that particular case the Big Deal will be the concurrency model more than
> anything else, followed by subtleties relating to careful use of
> update-in-place
> and index coverage (from the perspective of starting with Sybase anyway).

I don't think JDBC is really the same - as you say the SQL differences
and differences in locking model and the like are often significant
between database vendors.

Although there are clearly differences between messaging middleware
products, my experience is that many applications only use the basic
JMS API and don't rely on subtle semantics of the underlying broker
implementation.

> I would have thought that differences in the semantics of message ack
> batching,
> fan-out, authentication, subscription etc will be subtle but ultimately
> irreconcilable,
> and the ability to use a familiar JMS API will be a portability benefit in
> theory more
> than in practice.

Differences in areas such as authentication are certainly expected
(and not really covered by the JMS spec) but only affect a tiny part
of the code. Most apps can use the JMS transaction model or message
ack model.

I have ported apps between a few major messaging providers with success.

> Time will tell.  Clearly there is a body that want JMS with an ability to
> get at
> AMQP facilities, and a body that want to write an AMQP application that
> happens to use Java.

As I've argued before in this forum and elsewhere, an "extended JMS"
model can offer a good path for people who want to use JMS and
occasionally exploit a JMS-specific feature.

RG

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


Mime
View raw message