you can use jca technology with jboss, weblogic and websphere it can help with old legacy software
and it is tied to the container
here is the wizard directions http://docs.oracle.com/cd/E19509-01/820-6204/jbidevjmsjca_id/index.html
Thanks for the links. I understand that JCA is useful for integrating with legacy systems and whatnot, and that it can be used with different containers.
But my question was specifically about JCA binding with JMS endpoint in Switchyard.
There is also a pure JMS binding in Switchyard. So, if one needs to use asynchronous messaging and the requirement is JMS then what to prefer for the implementation: JMS binding or JCA+JMS binding?
I will try to answer your question the best I can....Which is better plain jms or jca?
It really is a matter what your requirements are....
For example suppose you were a software company that wanted to develop custom
Than you would consider jca-weblogic, websphere, jboss because it works
Here is my two cents.....
Frankly, I love jbpm or bpmn(I love architectural patterns -workflow ) and it seems to me switchyard is following closely what spring activiti so yes jca ra because it makes life easier for my messages
I want something heavy weight to control my messages, a container active mq etc
I believe a system should be able to help you perform system diagnostics.etc , checking to see how bad my code is...or where can I improve...cars, water heaters, have that capacity. I need all the help
I can get....Plain jms just
does not seem to offer anything even close that...I hate flying blind...
jca is the way to go
By the way, I really don't think their is right answer to your question it is really a matter of opinion
and your requirements.
anyway....... thank you for allowing to voice my opinion....It is strictly a matter of taste. .
If you don't have any specific reason to use JCA binding, then 1st option for you is camel-jms (I would not call it "plain JMS" though, as it's using camel-jms and depends on spring-jms underneath). Internally JCA inbound is using JCA inflow manner unlike camel-jms is just using ConnectionFactory. For outbound JCA also uses ConnectionFactory and no significant difference functionally. Note that JCA is not only for JMS and the Endpoint/Processor is pluggable, so you can implement your own.
Thanks William and Tomo. You provided useful insights.
I will have to look deeper into JCA (to check those extra stuff it provides on top) but for now it seems camel-JMS is good enough for us for the existing requirements.
One advantage of JCA should be pooling and transaction support out of the box per the JCA spec, as well as security, which I dont know how easy would be with the JMS component. But maybe I'm wrong and igarashitm might correct me.
Jorge and Tomo have already hinted at this, but just to be clear : the JCA gateway is integrated with JBoss AS / EAP / Wildfly for message inflow, which means it's managed by the underlying container. If you are looking at tight integration and configuration for inflow via JBoss AS configuration, then it's a good option for that. The camel-jms component will have more flexibility in terms of Camel-specific options, but everything will be configured through Camel (including thread pools and whatnot).
There's no correct answer here. If you don't care about any extra options that camel-jms provides, I would go with JCA. If you want those options or just feel more comfortable configuring messaging through Camel config, go with camel-jms.
Connection pooling and XA transaction is served by resource adapter itself, and you can receive that benefits if you just use the XA ConnectionFactory exposed by the resource adapter. And there is a authentication facility on plain JMS ConnectionFactory, which is available via camel-jms property.
TBH, I would go with JCA too, just because I don't like spring-jms. Sometimes it's hard to debug into spring world if I hit a problem (especially transaction related problem). But as I wrote some code for JCA binding, I think my opinion here is not fair