I'll have a meeting with a guy who will defend using JCA for application integration. I'm not a JCA expert, but as far as I know JCA is trying to solve the same problem as WebServices.
The only article I found discussing about this was in a BEA site, and I do not agree with the author. He says that you cannot compare the two, and the main reason it gives is that Websevices are more 'intrusive' as you need to build a stack for the legacy server, and with JCA you just use the existing APIs. If that's the main reason, I think they _are_ competing with each other.
Sun built/is building a whole EAI stack for JCA, and it is also building it for WebServices... is there a reason for this?
Of course I think webservices is a better solution, even if it is more complex, as it's a cross-platform and cross-language solution.
Can anyone help me to clarify this? Will JCA have a future?
On the other side, the BEA article made me think that Microsoft really needs the Enterprise Applications vendors to build SOAP APIs for their products. Perhaps this Microsoft entry into the Enterprise Application market (Great Plains, Navision) is, among other reasons, to force their competition to build the SOAP APIs. If MS products have good SOAP APIs, as they will, the other vendors would have to build them to compete with MS.
6:07:03 PM 
|
