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
book?"

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
succession!

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!

Mark

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


Mime
View raw message