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:15:25 GMT
Sorry to send twice. Our mail server is being flaky and appeared to drop 
the first one.

--Rafael

Rafael Schloming wrote:
> 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 which interfaces
> you're allowed to cast it to.
> 
>>>> 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 
> the destination abstraction can be used for most of what we need here.
> 
>> 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 with
> createQueue(...) and friends.
> 
> --Rafael
> 
> 
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> 

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


Mime
View raw message