JMS Transport support for CXF JAX-RS clients

I blogged about the support for JMS by CXF JAX-RS endpoints two years ago.

The main reason behind making the JAX-RS frontend (associated by most users with supporting HTTP-based communications) JMS-aware was to do with getting the most from the 'investment' made into implementing the RESTful services on top of CXF JAX-RS.

If one has the resource code relying on the JAX-RS runtime to make the inbound data delivered to the right method and easily consumable in the form of a given JAXB bean instance, then the possibility is that this code can work equally well when the data comes to this resource handler either via HTTP or JMS or indeed some other transport, example, CXF Local Transport.    

CXF is super-flexible in the way it can support multiple transports, and it does make sense to get JAX-RS based endpoints optionally supporting non-HTTP transports.

And it is exactly for the same reason that CXF JAX-RS proxies (and I have to admit, WebClient :-) - simply because proxies and WebClient are using the same base code) also optionally support JMS transport now, thanks to the contribution from Willem.

So why would one want to use CXF JAX-RS client code with JMS ? As noted above, it is primarily about making the same code, client one in this case, re-usable in different contexts. I could've noted again that REST principles can probably be applied even to RS-232 endpoints if really really needed :-) but I'd rather focus on the re-usability aspect.

For example, consider a newly introduced HTTPSPStateManager implementation for making it easy for users to quickly set up a centralized distributed SSO cache endpoint. You've tested it and seen it working with HTTP. Now the time has come up for you to move to a more sophisticated distributed cache implementation for it to scale really well in the production. But then you realize that by simply getting HTTPSPStateManager proxies and the endpoint addresses use  a JMS scheme you can get an entirely different cache support, still using the same configuration, so you are going to give it a go and see what happens.

Or perhaps you have a Camel JAX-RS endpoint, supported by Camel transport and jaxrs:endpoint or CXFRS bean or endpoint, supporting both HTTP and JMS. It would be cool to get the same Camel CXFRS client to be able to talk to the endpoints using either HTTP or JMS.

I'm hoping users can come up with more interesting cases which will be possible thanks to the optional end-to-end support for JMS in the JAX-RS frontend.

Enjoy!