On 12/08/2015 00:56, David Heffelfinger wrote:
> I'm working on a project where we are using IBM MQ Series as our Message Oriented Middleware, to allow JNDI lookups to
> find queues, topics and connection factories defined in IBM MQ, developers need to create a .bindings file, as described
> in http://stackoverflow.com/questions/967051/understanding-mq-series-bindings-files.
>
> This bindings file is very cumbersome to create, and the procedure is very error prone. If there could be a way to map
> JNDI names to the Message Oriented Middleware product specific names it would really make things easier for application
> developers.
>
> I'm not opposed to using JNDI, it just would be nice to be able to map the product specific names to the JNDI names
> defined in the application server, ideally through an annotation right on the MDB or messaage listener.
Can you explain what you have in mind in a bit more detail?
>
> Please let me know what you guys think.
Back when we discussed JMS 2.0, and more recently, we have considered various proposals to define a standard way to
create connection factory, queue and topic objects which
a. keeps applications as portable as possible whilst
b. avoiding the need to use JNDI
However each time we didn't reach consensus on what we should do and no conclusion was reached. That doesn't mean that
the need still isn't there, just that it is not easy!
I think part of the problem is that different people had different use cases in mind. There are at least three cases:
1. API for use by a simple Java SE client to create a connection factory, queue or topic object.
2. API to for use by a Java EE application (servlet, EJB etc) to create a connection factory, queue or topic. In this
case the connection factory object is likely to be implemented by a resource adapter. (And how would such a API relate
to the existing SPI to instantiate resource adapter ManagedConnectionFactory, Queue and Topic objects?) JMS_SPEC-172
(mentioned in the subject line) relates to this use case.
3. SPI used by a resource adapter (or other Java EE wrapper) to create a given vendors' Java SE connection factory,
queue or topic object which it will then wrap to add Java EE behaviour.
In all three, the API/SPI should be capable of supporting multiple JMS providers (and in case (2), multiple resource
adapters) in the same application. So there was a bootstrapping problem to decide what object to start from. (Obviously
we did have ideas on how to solve it)
We also ran into difficulties with queues and topics objects. Essentially, the act of creating a Queue or Topic object
in the application is not the same as creating the underlying queue or topic in the underlying JMS server, and it wasn't
clear whether we should be trying to provide APIs for both.
Despite all this, it's worth trying again, perhaps picking one specific use case and tacking it alone.
Nigel