qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: AMQP 1.0
Date Thu, 19 Mar 2009 17:09:26 GMT
[.. snip ..]

> 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.

That is why I advocate an *interface* rather than casting into
implementation classes.

>> 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.

It will cause a compile time failure but not a run time failure.  You
can have the jar in your classpath without it being the JMS client
that you are actually using.

> 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")

I think the JMS Properties should be used as intended - that is as a
way of adding to the end-to-end properties of the message (payload)
being sent.  If the extension is on the broker, and is triggered by
such a property then setting the property is the appropriate
mechanism.  However if the AMQP extension is something that should be
interpreted by the client then I do not believe that we should be
using such an ugly hack.

I understand that you have a pathalogical hatred of casts.  The java
syntax is certainly less than ideal.  However where we are depending
on AMQP specific behaviour it should be called out.

My feeling is that given where we are taking the 1-0 spec there is
likely to be *much* less of this required.

The only examples I can think of off-hand on messages might be audit
trails or signatures...

> 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.

My view is that you should try to avoid to using *any* AMQP or Qpid
specific extensions.  Where they are to be relied upon I (as an
architect or manager of a development team) want those dependencies to
be called out *very* explicitly.  The use of magic headers etc. is the
sort of thing that makes porting between message providers *very* hard
(been there done that).

Hopefully most AMQP/QPID extensions can be isolated in cofiguration
rather than code...


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

View raw message