A-MQ 6 always had a JCA-compliant resource adapter RAR as part of its tested and supported delivery. Although the upstream Artemis has a resource adapter, it is excluded from the AMQ 7 product build because of a perceived lack of customer demand, and a low priority in the QE test program.

This situation is become increasingly burdensome. There is, right now, no supported way to use AMQ 7 with any J(2)EE application server other than EAP 7, and support for EAP 7 only exists because the support is essentially provided inside the application server.

The JCA specification is clear on the responsibilities of the various vendors involved, when it comes to creating a resource adapter:

"An application server vendor extends its system once to support the connector architecture and is then assured of seamless connectivity to multiple EISs. Likewise,an EIS vendor provides one standard resource adapter which has the capability to plug in to any application server that supports the connector architecture."

That is, the user of an application server that supports JCA – which means every reputable product currently available – can reasonably expect J(2)EE-compliant software components it integrates with to provide a resource adapter. Application server vendors do not have a responsibility under the J(2)EE specifications to provide support for any particular JMS product – this is the responsibility of the JMS vendor.

We already have a request open to certify AMQ 7 with WebSphere (ENTMQBR-2207), but this problem goes beyond WebSphere. We can't even provide a supported way for customers to integrate AMQ 7 with EAP 6 and, while I do appreciate that EAP 6 is itself at the end of its regular service life, we do have a lot of important customers who are unable to upgrade an EAP 6/A-MQ 6 installation to EAP 7/AMQ 7 in a single operation. There is interest from customers using WebLogic as well.

To some extent, customers can get around the lack of a resource adapter using work-arounds in the application server (sometimes described as 'foreign JMS' or 'foreign JNDI' capabilities). However, JCA provides the only specification-compliant way to get full and complete integration between a JMS broker and message-driven beans. The application-server's work-arounds are merely fall-backs to accommodate JMS products without full J(2)EE compliance. My experience is that these fall-back strategies have varying success rates; they are particularly weak in areas like transaction recovery.

Not every customer engagement where the question of AMQ 7 integration has been raised has resulted in registration of that interest in JIRA – I think we could be underestimating the demand for a resource adapter. That fact that we had, and supported, one for A-MQ 6 does make this lack look like a regression.