On 07/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
On 07/06/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
>
> Providing two distinct APIs seems like a clean way forward with new
> applications but it doesn't seem to offer much in the way of migration
> for existing JMS API users.
So, how do we let a JMS application do something that is more AMQP like? For
example, there is no way in the current JMS implementation to do JMS over a
headers exchange. Some suggestions:
1. Use the management console to set up the headers exchange and bind a
queue to it. The JMS just accesses this queue already set up.
2. Do the same thing, but you specify this in the properties that you pass
to the JNDI context, to get your connection factory from. Not exactly a nice
solution.
Both these approaches are pure JMS compliant. If you changed to a different
JMS product, you'd have to figure out their way of doing it.
When you change JMS provider just now your properties file is usually
useless as each JMS provider has their own proprietary way of
specifying queues/topics and connections
3. Provide an extension API that gives you access to AMQP features, or just
make the lower level AMQ API available publicly.
Once an app starts doing 3, its not plain JMS anymore, so can't change to a
different JMS provider. At least its the application writers choice to move
outside of JMS.
But they could change do a different AMQP provider and with no or tiny
changes in code or configuration as everything is standard. This is
the end goal after all. To make AMQP language independent and vendor
independent.
Rupert
--
Martin Ritchie
