Advantages:
* Clearer structure for the JMS client code.
This may or may not be true. Depending on what we need to expose for
JMS, there may not be as clean a separation between the layers as you
might hope.
* Ability to write tests for the broker that are rendered impossible via
the JMS API.
I guess we are using the Python client API for that though. I took a
brief look
at the Python client a while ago and I think it's excellent btw!
Yes, you can't work at the protocol level even with our extended JMS
API. But I would argue if we need to work at the protocol level for
test purposes we can do that in other ways (such as with the python
client).
* You can asynchronously send without having to worry about the send
semantics
in JMS. Specifically it appears that there is a need to block to
detect and throw
an InvalidDestinationException. In general you don't have to worry
about JMS
semantics which is nice.
Is this for the case where you specify a Destination in the send call,
as opposed to passing in the Destination when you create the producer?
For the latter case I have proposed and had agreement in principal to
add another method to the protocol to determine whether a given
routing key is routable by an exchange thereby allowing us to throw an
exception on creation of the producer.
For the former case, we can block by default (which is nasty but
required for strict compliance) or provide an option allowing it to be
done asynchronously since I imagine some users will not want to take
the hit of the block. We should certainly discuss this issue
separately.
* You can declare exchanges queues and bindings directly. Perhaps allowing
things that are not available through JMS.
I think we should extend JMS to allow this; we already support an
admittedly limited form of dynamic declaration and binding.
* You could directly supply headers as a field table.
We support this already in the extended JMS API?
Disadvantages:
* the perception problem of having two APIs from a user's point of view
* maintenance could be a burden
* now is probably not the time to do it.
I think if we were wanting to make any kind of "radical" change it is
better done sooner or later although I do take your point about
stability which is obviously extremely important given we have people
running this in production today.
We definitely need to get as much feedback as possible on whatever API
we use to expose more advanced features since changing APIs later on
always upsets users.
The JMS API does surprisingly suck quite a bit as it's
a lowest common denominator kind of
API (but also for small things like JMSException's linkedException
presumably because it was designed
prior to Java 1.4). One odd thing about the JMS API is a number of setter
methods on Message that should only
be called by a JMS provider (like setJMSDestination). Unfortunately
neither of the two gripes to the JMS API
really call for an AMQP API, just some tweaks to JMS or, as is likely, a
better understanding of the JMS requirements.
Yes, JMS suffers from being a lowest common denominator but it does
have widespread adoption.
I think we agree that we need to expose functionality that goes beyond
JMS. The question is whether we can do this though extension points to
JMS or whether we need a separate API.
RG
