The Java Connector Architecture 1.5 (the wrong but often used abbreviation is "JCA") specifies a standard way to integrate external resources such as legacy systems or messaging providers into J2EE 1.4 compliant application servers and thus become an integral part of the managed application server environment. The interface between the application server and the resource is the Resource Adapter (RA). The big enhancement in JCA 1.5 over its predecessor JCA 1.0 is that JCA 1.5 defines contracts for message inflow which is also often called "JMS Pluggability".
SwiftMQ provides a full-featured JCA 1.5 JMS RA. In conjunction with a J2EE 1.4 application server you are able to:
The RA provides full support for distributed (XA) and local transactions for all of the above combinations of messaging. For XA it provides the possibility to automatically recover indoubt XA transactions after a crash or system failure by the application server via XAResource.recover(). It is also possible to recover those transactions manually via SwiftMQ Explorer/CLI.
To drive MDBs the RA uses Application Server Facilities (ASF, ConnectionConsumer; see chapter 8 of the JMS specification) internally. This guarantees high scalability.
It is required to install the JMS XA/ASF Swiftlet if the JCA 1.5 RA is used with the following deployments:
For example, if you use the RA to send messages without XA (local transactions) because you don't use another resource within your transaction, you don't need the JMS XA/ASF Swiftlet. However, if you use MDBs without XA, thus local transactions, you need the JMS XA/ASF Swiftlet because ASF is used to drive MDBs and ASF is only provided by the JMS XA/ASF Swiftlet.
It is possible to deploy a RA to connect to an external SwiftMQ router which runs outside the JVM of an application server (on the same or different host). You can also deploy the RA intra-VM. Here the SwiftMQ router is started when the RA ist started from the application server and stopped when the RA is stopped so you have only one JVM and start/stop of the SwiftMQ router is managed by the application server. You also don't need socket connection in that case but can use faster intra-VM connections.