Purpose of Resource Adaptor

[kalyanmiddleware]

Hi All,

Can any one help me in under standing Resource Adaptor in jboss eap.

[mnovak]

I'll describe it for EAP 6 (princips are the same for EAP 7)

EAP 6 contains HornetQ as default JMS provider. It's component which implements JMS specification which does not define how it will fit inside application server. Application server contains number of additional features which JMS provider can use.  Resource adapter is basically set of APIs, workflows and contracts which allows JMS client (it can be any Java EE deployment doing something with messaging like EJB, Servlet, MDB) to use features of application server. For example Transaction Manager so JMS provider can be part of XA transactions or application server can pool JMS connections to JMS provider so they do not have to be created all over again. Client can use security domains which are defined in application server. For all those features some API must be defined and resource adapter is implementing this API.

HornetQ has its resource adapter in EAP 6 server and is configurable in messaging subsystem by pooled-connection-factory "hornetq-ra". Any deployment in EAP should use this connection-factory when doing something with HornetQ. I hope it helped a little bit.

Note that there is also another type of connection factory like RemoteConnectionFactory or InVmConnectionFactory. This is not the same connection factory as pooled-connection-factory as it's not created by HornetQ resource adapter but by HornetQ itself. It does not provide the additional features provided by application server.

If you don't need connection pooling or XA transactions then you might see better performance with RemoteConnectionFactory/InVmConnectionFactory. Otherwise I strongly recommand to used pooled-connection-factory.

[wdfink]

Additional to say, a ResourceAdapter can be a connection to any system.

So you can have a backend system which use a socket and a properitary protocol, you implement a RA for the communication and maybe XA 2phase commit transaction protocol handling.

Now your application can use it and the transaction/connection is handled by the container for you - assuming that your RA implementation is correct