> We could add some feature like this to our extended JMS API
> although as you mention I am not sure how acknowledge modes
> and transactions would fit with this. It appears to be
> slightly higher level than JMS?
I'd say it's lower level than JMS as the threading and dispatching is
handled within a JMS provider.
What I meant was that handling messages from different sources should
be unified at a higher level than the messaging middleware transport.
> We have extended the JMS message model. In AMQP, the message
OK, cool. Would this be portable to other AMQP server side implementations?
Yes, it should be. It's certainly not rocket science.
I guess in my ideal provider I'd see:
1. A clean simple JMS implementation.
What do you mean by "clean" and "simple" in this case? Do you mean not
providing any functionality beyond that described by the Sun JMS
specification.
I've seen several mails on the merits of a public AMPQ API on top of which a
JMS API is layered. One benefit of this I've not seen mentioned is that it
localises the mapping between AMPQ and JMS semantics in one place, e.g.
concepts of queues, topics and messages. This could be a real maintenance
benefit as well as making the codebase clearer.
I think that the issue of codebase structure is separate from APIs.
Publishing APIs means supporting and documenting ways of writing
applications using our software. Making our software maintainable is
extremely important but can be done without creating additional APIs
that we encourage people to code against.
RG
