[java] javax.jms.Destination impl

[Rajith Attapattu <ra...@gmail.com>]

Hi folks,

I created a separate thread to ensure it gets the attention it deserves.
The javax.jms.Destination provides a very poweful abstraction and we don't
seem to fully utilize it.
The JMS 1.1 introduced the Destination interface bcos they felt the Topic
and Queue didn't cover all the use cases.
Infact the prefered way is to use Destinations and not Topics or Queues. In
the session interface there is no "createDestination" method.
You can only lookup a destination via JNDI. This allows immense flexibility
where you can create any type of destination hidden behind the interface.

But I see our implementation is centered around Topic and Queues (they are
the first class citizens).
As Godon pointed out in the BindingURL thread, we can use the Destination
abstraction to cover a lot of the AMQP specific features.
I think we should think about a proper strategy for subclassing the
AMQDestination class to provide this extensible functionality.

We can then influence the AMQP WG to make this a standard by submitting
proposals to the JMS SIG.

Regards,

Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/

Re: [java] javax.jms.Destination impl

[Rajith Attapattu <ra...@gmail.com>]

On Jan 18, 2008 11:31 AM, Martin Ritchie <ri...@apache.org> wrote:

> On 18/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> > Hi folks,
> >
> > I created a separate thread to ensure it gets the attention it deserves.
> > The javax.jms.Destination provides a very poweful abstraction and we
> don't
> > seem to fully utilize it.
> > The JMS 1.1 introduced the Destination interface bcos they felt the
> Topic
> > and Queue didn't cover all the use cases.
> > Infact the prefered way is to use Destinations and not Topics or Queues.
> In
> > the session interface there is no "createDestination" method.
> > You can only lookup a destination via JNDI. This allows immense
> flexibility
> > where you can create any type of destination hidden behind the
> interface.
> >
> > But I see our implementation is centered around Topic and Queues (they
> are
> > the first class citizens).
> > As Gordon pointed out in the BindingURL thread, we can use the
> Destination
> > abstraction to cover a lot of the AMQP specific features.
> > I think we should think about a proper strategy for subclassing the
> > AMQDestination class to provide this extensible functionality.
>
> Incase you hadn't noticed work towards this you will find a
> AMQHeadersExchange and an AMQUndefinedDestination. This should allow
> the Java client to be able to use any given Exchange + RoutingKey that
> may be presented via the replyTo.


I did see these to classes when I looked at the code to provide fannout
support.
I think this is a step in the right direction.
However I don't think we are quite there. I still think more work needs to
be done.
When I said we haven't utilized the full power, I based it on the following
comments by Gordon which I will cut-paste here.

"what exchanges to use, multiple bindings to a queue, whether and
when things are declared & whether the 'passive' flag is used when so
doing, whether the 'mandatory' flag is set on published messages,
whether the exclusive flag is set when issuing a subscribe etc. etc."

I believe a lot of these can be hidden behind the Destination abstraction.

I believe to piece of code that we are missing out on is the creation
> of these Destinations something that we can very easily add via JNDI
> or as you say by creating a new sub class of AMQDestination.
>

Yes that is the right approach. But as I said in the comment above, there's
more we can do.

>
> In fact the AMQUndefinedDestination is a new addition to M2.1 and by
> changing createDestination in AMQDestination to create an
> UndefinedDestination we can support any future destinations, of course
> with the caveat that any potential queue already exists on the broker.
> More work will be needed to instruct the client when the appropriate
> time is to create a temporary queue or request a durable queue.
>

When somebody sends me a replyTo, it's done witht the explicit understanding
that the sender has already have this queue in place.
That is the standard practise.

>
> > We can then influence the AMQP WG to make this a standard by submitting
> > proposals to the JMS SIG.
> >
> > Regards,
> >
> > Rajith Attapattu
> > Red Hat
> > blog: http://rajith.2rlabs.com/
> >
>
>
> --
> Martin Ritchie
>



-- 
Regards,

Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/

Re: [java] javax.jms.Destination impl

[Martin Ritchie <ri...@apache.org>]

On 18/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi folks,
>
> I created a separate thread to ensure it gets the attention it deserves.
> The javax.jms.Destination provides a very poweful abstraction and we don't
> seem to fully utilize it.
> The JMS 1.1 introduced the Destination interface bcos they felt the Topic
> and Queue didn't cover all the use cases.
> Infact the prefered way is to use Destinations and not Topics or Queues. In
> the session interface there is no "createDestination" method.
> You can only lookup a destination via JNDI. This allows immense flexibility
> where you can create any type of destination hidden behind the interface.
>
> But I see our implementation is centered around Topic and Queues (they are
> the first class citizens).
> As Gordon pointed out in the BindingURL thread, we can use the Destination
> abstraction to cover a lot of the AMQP specific features.
> I think we should think about a proper strategy for subclassing the
> AMQDestination class to provide this extensible functionality.

Incase you hadn't noticed work towards this you will find a
AMQHeadersExchange and an AMQUndefinedDestination. This should allow
the Java client to be able to use any given Exchange + RoutingKey that
may be presented via the replyTo.

I believe to piece of code that we are missing out on is the creation
of these Destinations something that we can very easily add via JNDI
or as you say by creating a new sub class of AMQDestination.

In fact the AMQUndefinedDestination is a new addition to M2.1 and by
changing createDestination in AMQDestination to create an
UndefinedDestination we can support any future destinations, of course
with the caveat that any potential queue already exists on the broker.
More work will be needed to instruct the client when the appropriate
time is to create a temporary queue or request a durable queue.

> We can then influence the AMQP WG to make this a standard by submitting
> proposals to the JMS SIG.
>
> Regards,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>


-- 
Martin Ritchie