Robert Godfrey wrote:
2009/3/19 Rajith Attapattu <[email protected]>:
On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner <[email protected]> wrote:
On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu <[email protected]> wrote:
On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner <[email protected]> wrote:
On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <[email protected]> wrote:
The Java client uses JMS for this to an extent, but we still need a
way of exposing AMQP specific things in ways that are as version
independent as possible (such as the mandatory flag). I've been
kicking around the idea of something like this:
I am of the opinion that you could get 99% of the AMQP stuff while
still using pure JMS.
I have a few ideas around how to do the immediate flag etc while still
using pure JMS.
One such idea is to pass in a QPID specific property in the message
called "AMQP_IMMEDIATE" and the respective sender method can look for
the presense of this flag and put that in the delivery props. When
See, I'm not sure this is really "pure JMS". It may not use any
non-JMS API, but it does rely on non-JMS semantics.
I can easily see that this improves portability from a "does my code
compile" PoV. I think it may be quite unhelpful from a "does my code
still work" PoV however. Having non-JMS features available as non-JMS
API at least makes their dependence on this more obvious.
I completely agree with Aidan's point here.
Frankly if you are relying on AMQP specific semantics then you should
make this clear in the code.
Personally I would think
if(msg instanceof AMQMessage)
{
((AMQMessage)msg).setImmediate(true);
}
I tend to dislike the casting approach since if you need to make more
than one or two calls it becomes quite cumbersome and people then
inevitably just declare their variables to be of the non JMS type and
then it's unclear which calls are pure JMS and which aren't.
I also think it's a bit of a hack to be required to cast as part of an
API. It's difficult to tell whether you're casting into an approved part
of the API or whether you're casting to some random implementation
specific interface that the object just happens to implement.
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
This is only true if you hardcode your header values rather than using
some API to set them. Using constants will cause a compile time failure,
and using a decorator will cause both compile and link failures.
I think there are different sorts of AMQP specific behavior that we need
to think about here. For example I would make a distinction between AMQP
or Qpid specific broker features, and AMQP or Qpid specific client
features. I think accessing AMQP or Qpid specific broker features
through a well defined set of message headers is probably a reasonable
way to go, and there are a variety of ways to set these headers that
provide differing levels of compile and/or runtime protection to the
application. But really for accessing broker features there is no need
to tie anything to the specific JMS implementation in question, e.g.:
Message msg = ..;
QpidMessage qmsg = new QpidMessage(msg);
qmsg.setFoo(); // equivalent to msg.setStringProperty(QpidHeaders.FOO,
"bar") which is in turn equivalent to
msg.setStringProperty("org.apache.qpid.foo", "bar")
For AMQP or Qpid specific behavior related to the client implementation,
e.g. acking behavior, prefetch behavior, etc, I think this is something
of a different story, and I would probably take these features on a case
by case basis. I suspect it's probably not an either/or situation and
we'll want both configuration for people deploying pre-existing vanilla
JMS apps, as well as API for people writing stuff from scratch or
"porting" to qpid.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
