Rafael Schloming wrote:
Jonathan Robie wrote:
In another message, I suggest separating out the configuration API
from the messaging API.
In this message, I wonder whether we should consider using either AMQP
1.0 or Java JMS as the model for the new messaging API, rather than
create a third model that nevertheless needs to bridge both Java JMS
and AMQP. If we separate out configuration, I would think either model
would cover everyday messaging operations quite well.
Making the new API more like Java JMS would have the advantage that is
the best known messaging API. Making it more like the AMQP 1.0 model
would allow more direct support of AMQP concepts. Is there an
advantage to having a third programming model that is not based on
either?
It's probably worth distinguishing between the messaging model and the
programming model. If you look at the messaging model alone then AMQP,
the new APIs, and JMS aren't a million miles apart. The major difference
is that AMQP describes the messaging model in more abstract terms and
from a global perspective. You have "nodes" that store messages, and
"links" that shuttle messages between nodes, and "addresses" that
identify nodes.
With the JMS API the messaging model is understandably described more
from the perspective of a client application. You have destinations,
producers, and consumers. A JMS destination is just a name for something
that you can send messages to or get messages from (in AMQP terms it's
an address). A producer is just an outgoing link, and a consumer is just
an incoming link.
Similarly the new APIs take a somewhat more client centric approach to
terminology, but without some of the slightly confusing choices made in
the JMS API. The new APIs are defined in terms of addresses, senders,
and receivers. Where the term address is pretty much synonymous with the
AMQP usage of the term, and the term sender and receiver can be thought
of as the API for the two ends of a link, as in "a link connects two
nodes, a sender and a receiver."
Now as for the programming model, AMQP is really intentionally agnostic
on that subject since it's just a protocol. For JMS the only really well
supported programming model is for threads in the client library to
dispatch out to message listeners supplied by the application. For
example if the application wants to call into the library to get its
messages, then you really need to go around the API to configure
prefetch appropriately in order for this to work in a safe and practical
(or at least in a performant) way.
As for the new APIs, while the basic concepts are quite analogous to JMS:
MessageProducer.send(...) vs Sender.send()
MessageConsumer.receive(...) vs Receiver.fetch(...)
They provide additional features intended to support a wider variety of
programming models, such as explicit control over blocking vs non
blocking behavior, access to asynchronous send/ack confirmation,
explicit control over prefetch and flow control, etc. Additionally there
are a few choices made for consistency and simplicity, e.g. rather than
having a separate API for queue browsers like JMS does, you simply use a
non destructive receiver.
The upshot is you can sort of look at these as providing a JMS-like API
plus some critically missing bits minus some extra cruft.
One thing I should say before someone accuses me of bashing our JMS
client too much is that most of the critically missing bits of
functionality are actually also available in our JMS client, just not
via the JMS API. They're usually accessible via some system property or
other.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
