On Mon, Mar 25, 2013 at 3:13 PM, Rajith Attapattu <[email protected]>wrote:
> On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <[email protected]> > wrote: > This is not the case since the time we implemented the addressing stuff. > (used to be the case before that). > > The JMS client behaves the same as the messaging API. > Are you sure? It looks to me like AMQSession.createTopic("foo") will result in an address of "amq.topic/foo", and I believe that's what Robbie suggested earlier in this thread. This would seem to very much confuse the notion of "topic" and "subject" as it is presented in the messaging API. > > > (2) Forcing all destinations to be either queues or topics doesn't work > so > > well in the AMQP 1.0 world. Going forward we to be able to specify an > > address that refers to a node that isn't necessarily either a queue or a > > topic (e.g. it could be a specific kind of service node which doesn't > > behave like either). I also think it's a valid use case to be able to > > specify the name of something on the client and not have to know whether > it > > is configured on the broker to be a topic or a queue. > > JMS does provide the Destination interface, and Queues and Topics are > indeed special cases. > > To provide some historical context, not knowing if it's a Topic or > Queue has been a general issue in our code base not just for this > equals issue. > Hence the suggestions from Robbie and me about specifying a type. > Our products were heavily geared towards the hub-and-spoke model and > Queues and Topics are fundamental in this model. > I don't see what the "hub and spoke" model has to do with this at all. Pretty much every broker already supports things that don't really act like queues or topics. --Rafael
