qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Atwell <mark.atw...@gmail.com>
Subject Re: AMQP 1.0
Date Fri, 27 Mar 2009 07:46:40 GMT
Porting between JMS implementations is, by definition, possible.

Unfortunately there is the very practical problem that most developers
don't really read or understand the spec. - especially the subtleties.
They tend to write to a simple paradigm that seems to make sense and
the implementation that they happen to have in their hands at that
moment *appears* to - and sometimes does - adhere to - see below. The
written-language of the author and the reader have to be on the top of
their game to understand *exactly* what is being conveyed... and
sometimes: why you should care! I still come across the odd paragraph
(not just in the JMS spec.) where I'm thinking "This looks like it's
meant to be important - teasing out some subtlety - but I can't for
the life of me, see what it's trying to say that is different or
important... Or is it just a restatement - possibly to 'pad out' the

And sometimes even the subtleties aren't obviously surfaced! I recall
a few years ago: poring for several minutes over one particular
paragraph (and might have even been a sentence) in the spec. about
routing rules and ordering over different topics/destinations. IIRC
(don't write your code based on what I'm about to write here! :o) the
implementation has the latitude to route traffic on different topics -
even between the same source and destination - separately and
therefore messages can arrive out-of-order w.r.t. each other. In
practice many implementations don't do this, but what do you know? But
the implementation that was being ported to did! And of course, it
(out-of-order delivery) didn't actually happen very often. In this
particular case it was further masked by a 'slow' sender client that
very rarely got its act together and sent two messages in quick enough

The software industry is littered with such examples. For those who
can remember back: How many years did it take C (let alone C++!) to
clarify *all* the standards and subtleties, and the compiler writers
themselves to understand and implement them correctly and the
developers to fix their now-broken (some would perhaps correctly argue
'always-broken') code? It's probably still going on somewhere... This
is why the Java Language and JVM Specs. are so much better than what
we had before - they define rules for almost everything - both the
language and the run-time environment.

And then, just when you think (hope!) I'm going to stop: What about
the reasons for using a particular implementation? Whilst cost is
often a driver, what about those 'extra' features or even
implementation 'profile'? For example: "It's backed by (it stores data
in) Oracle and we're an Oracle shop and therefore can get it to fit
our DR approach!" or "It was designed for low latency / deals with
slow clients over the WAN / Internet." - all within the letter and
even the spirit of the spec. The points about JDBC or even Hibernate
are similar. Whilst one can get functional portability, the supposed
non-functionals are often even more important.

BTW, I'm really not a 'buyer' of the concept of 'non-functionals' -
especially performance - but I'll save that rant for another day...

Regards to All!


On Thu, Mar 26, 2009 at 10:41 PM, Robert Greig <robert.j.greig@gmail.com> wrote:
> 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

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

View raw message