On 26 March 2013 14:26, Rafael Schloming <[email protected]> wrote:
> 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?
>
Ideally it would, definitely. There are already enough slight behavioural
differences between the 0-8/9/9-1 and 0-10 codepaths of the existing client
to cause annoyance though and the 1.0 client(s) being completely separate
and entirely different (for good reasons...) mean I'm not sure that is ever
really going to be exactly the case.
That wasnt really part of my reasoning though, it was more to do with the
fact one client has an entrenched user base that might not expect such
behvioural change between otherwise fairly minorly different releases,
whereas the newer ones (that may or may not yet exist) have yet to build up
many users at all and people picking them up should really be more
accepting of change given it is in fact something entirely new.
I'm not completely against it, as I do agree it would have been a more
obvious way of doing things from the start, just putting the idea out for
discussion as to whether the gains for users of the older protocol client
actually warrants the upheaval given its been that way for say 7? years.
>
> 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").
>
If we decided to change it and it was just a one-time type warning that
might be ok...otherwise people using frameworks doing 'interesting'
repetition of such calls would probably not be happy about their disks
filling with logs.
I'm personally not that against the 'simple' variety as I think its
actually what many users would expect to see coming from some other
providers, and certainly most of the user code I have seen in the past does
it that way, which is probably why I'd be ok with only making this an issue
on the newer client(s). It can be a struggle getting users to make even 15
character changes to their config, so I'd be quite happy not dealing with
the outcry from changing the behaviour of their stuff somewhat noticably;
at the very least it would probably have to be configurable.
>
> 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?
>
>
Not really no, as above I was operating mostly on the basis of it often
being easier to say <new thing> works differently in regards to <x> and
gain acceptance simply because <new thing> is at least actually new and
different.
>
> >
> >
> > > (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.
>
>
I'm fine with making it able to access everything in one way or another,
and we are certainly keen that the brokers are first and foremost AMQP
brokers which simply happen to support JMS [clients] rather than the other
way around, I just want us to be mindfull that there are simpler use cases
that don't need every feature in the book and we ensure they work as well
and in as suitably easy a fashion as people might find with other providers.
>
> >
> > (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
>
The reason I actually asked above about a Destination-only implementation
is that my interpretation of the spec/interfaces has been that this was not
intended usage, and the spec really only deals with Queue and Topic based
destination objects; Destination being added in order allow things like
MessageProducer to work with either Queue or Topic without rewriting
application code for little reason. The Destination interface does talk a
lot to their provider-specific nature and using them via JNDI but thats
about it. I'm not sure if anyone is doing Destination-only, but I freely
admit that since Qpid was really my starting point with messaging and
everything else and I've obviously spent most of my time working on Qpid,
its entirely likely I just wouldnt have picked up on it if there was.
I haven't read the 'actual spec' doc for JMS 2.0 yet, but I did take a look
at a JavaOne presentation (
http://www.slideshare.net/reza_rahman/whats-new-in-java-message-service-2 )
about it and have a poke around the Javadoc a month or so ago. Destinations
seem to be untouched from 1.1, with the exception of one of the new
configuration areas intended for simplifying JEE usage allowing annotation
assisted specification of Destinations (
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSDestinationDefinition.html).
One of the optional attribute elements is the implementation class, but the
main required element is the JMS destination interface name and there it
notes "Permitted values are javax.jms.Queue or javax.jms.Topic." (quoted
this time to avoid further typos :P), though I'm not sure that restricts
you from actually specifying other things.
Since we are on the JMS 2.0 subject,sort of, for anyone interested but not
really wanting to look through the stuff, some key changes are:
- New objects to simplify sending/receiving messages (JMSContext,
JMSProducer, JMSConsumer). Reduces the number of method calls, encapsulates
some of the previous Connection+Session+Producer objects, allows method
chaining for some things, etc.
- API support for asynchronous messaging with callbacks for completion and
errors.
- Multiple consumers are allowed on shared Topic subscriptions, within one
or across multiple JVMs.
- Delivery Delay for scheduling a future delivery.
- Message delivery count is now mandatory
- JCA adapters are now mandatory.
- Additions to simplify JEE usage, such as the annotation assisted config
mentioned above.
