Quick answer, is JMS will probably give you better performance than web services and be easier to implement than JCA (your side anyway if you have to write the connector;-) )
A Common use of JMS might be to receive feed messages from MQ (
http://en.wikipedia.org/wiki/WebSphere_MQ).
Webservices tend to be synchronous (send / receive) , very flexible , easy to just publish an API an let your clients sort out how to talk to you (commonly used on the net), jack of all trades easy to write / implement but be concerned with performance.
JMS tends to be organisation internal, or between trusted organisations, (bulk possibly) asynchronous message passing type systems, you'd be expecting better through put than a web service.
Used for say feeds eg price feeds sent over MQ for reliability. A lot more restrictive in use cases than webservices usually I'm going to send you a lot of data regularly, reliably but I'm not looking for an instant response and puts more restrictions on the technologies used either end of the pipe.
JCA is used where you can't change the other side i.e. they want to talk a given protocol and can't change or won't i.e. legacy C++ server or client engine that wants to speak a given protocol, you need to be very generic with your message processing, you might have to support a socket API and that’s it deal with it. If its a known protocol you might be able to buy a JCA component but if not you have to write one and they tend not to be trivial comparatively.
JCA can make a C++ client think it’s talking to a C++ server while your
Java programmers think they're responding to JMS messages.