On Tue, Mar 26, 2013 at 8:10 AM, Robbie Gemmell <[email protected]>wrote:
> On 25 March 2013 18:53, Rafael Schloming <[email protected]> wrote: > > > I haven't been following this discussion all that closely, but I did > notice > > two things I wanted to comment on: > > > > (1) The fact that the JMS client maps all topics into the singular > > amq.topic exchange is kind of weird and very different from the way the > > other messaging clients behave. > > > > Using addresses via the messaging API in any other language would result > in > > each separate topic being mapped to a distinct exchange. I think there > is a > > good case that we should change this for the JMS client going forward, > and > > not just for consistency. It is a much more natural mapping between JMS > and > > AMQP 0-x in general and using separate exchanges for each topic makes > for a > > much more manageable broker. > > > > > I agree it would make things clearer in many regards, but I do wonder about > the support and compatibility issues with making such a transition at this > point for the long-established components like the 0-x clients. I'd be > tempted to suggest restricting any such major behavioural changes to shiny > new 1.0 clients. > Tying it to switching over to the 1.0 client makes sense if there are going to be other significant behavioural changes, but is that actually the case? Ideally shouldn't a JMS app work pretty much the same whether it is speaking to the broker via 0-x or 1.0? I'm just thinking out loud here and it's been a while since I've worked in the JMS world so apologies if I'm not making much sense, but should we be preparing our users for behavioural changes, e.g. log a warning if they do createTopic("foo") instead of createTopic("amq.topic/foo"). Do you have in mind the full set of behavioural changes you would expect between the existing JMS client and the 1.0 JMS client? > > > > (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. > > > > --Rafael > > > > > JMS (and the Address syntax for the Messaging API, according to the docs > I've seen) defines Queue and Topic destinations, so whatever it actually > ends up being on the broker should probably be describable in those terms > of objects as used by the JMS client. It is specifically that I am > referring to when I say such things, and not whether the thing on the other > end actually is a queue/topic or an elephant. > > We are also speaking more about the 0-x client here than anything else here > which should be noted I think. Our current 0-x clients 'Address' syntax > implementation means that any 'Address' destination loaded from JNDI cant > be identified as either a Queue or Topic (without casting and using > Qpid-specific implementation methods) or anything else because they always > implement both of those interfaces, even when the user has specified which > they wanted up front. Its situations like that I am most keen to avoid in > future both for our own good and our users. If we want to allow for > 'unstated' types of destinations as well then so be it (this is what the > 1.0 JMS client does I think, gives all three options) but whenever someone > actually specifies it is a queue, it should be only a Queue object. > I agree it's bizarre to implement both, and I agree we should conceptually separate between the local JMS object and what's at the remote end. > > This stuff could be in need of some consideration when the AMQP BINDMAP TC > is looking at JMS mapping. > +1 I just want to be sure that our JMS client allows access to the full AMQP world. Obviously when speaking to a JMS broker over AMQP we need to be sure that everything behaves as expected and the TCK passes, but I do expect people will want to use our JMS client to use AMQP to talk to things that aren't necessarily full fledged JMS brokers. > > (Aside: > > I'm sure someone will point out Destination is a parent on both of those > interfaces and is used as the parameter type on the JMS 1.1 methods. Is > anyone aware of any providers implementing Destination without using Queue > or Topic? Given is has no methods on it I'd be interested if anyone is > using it in that fashion. > > Its possibly worth noting that even the shiny JMS 2.0 annotation > configuration explicitly defines that you are only permitted to set the > interfaceType to the strings javax.jms.Queue or Java.jms.Topic. > > Further aside: if the schedule is still correct, JMS 2.0 starts its final > ballot today: > > http://java.net/projects/jms-spec/pages/Home > http://jcp.org/en/jsr/detail?id=343 > ) > This is an interesting aside. I'm afraid I haven't looked at JMS 2.0 yet. Does it define anything that would be a problem for a pure non-queue/non-topic Destination? --Rafael
