qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: AMQP 1.0
Date Thu, 19 Mar 2009 16:51:35 GMT
Robert Godfrey wrote:
> 2009/3/19 Rajith Attapattu <rajith77@gmail.com>:
>> On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner <aidan@apache.org> wrote:
>>> On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu <rajith77@gmail.com>
>>>> On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner <aidan@apache.org> wrote:
>>>>> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <gsim@redhat.com> 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.


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

View raw message