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 18:08:56 GMT
Robert Godfrey wrote:
> [.. 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.

An interface if restricted to only permit features not accessible 
through vanilla JMS would certainly help, but I still think casting as 
part of the API unacceptably blurs the boundaries of the API. There is 
no way to tell what types you're allowed to cast and to which interfaces 
you're allowed to cast.

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

Yes, I was considering that a feature. It doesn't matter whether you 
have an 0-8, 0-9, 0-10, or 1-0 JMS message underneath, you still have 
access to the same broker extension. I would probably add an assertion 
based on the destination, broker vendor/version, etc to verify that the 
broker and recipient will understand what is being sent.

>> 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 wasn't suggesting using headers for controlling client local behavior. 
I think actually we should take appropriate advantage of the destination 
abstraction for that.

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

It's not casts I dislike. It's casting as part of an API that I dislike 
since it makes the API unnecessarily blurry. It's also quite trivial to 
avoid assuming you don't have a pathological hatred of static methods. ;)

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

Yes, I think most extensions are actually likely to be more Qpid 
specific than AMQP specific as well.

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

I wasn't suggesting using magic headers for this sort of thing. I think 
we can do most of what we need to through the destination abstraction.

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

I think the destination abstraction is a reasonably useful way to do 
this for most things. It gives us one mechanism that is mostly used via 
configuration but can also be used through code as well via 
createQueue(...) and friends.


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

View raw message