JCA有什么好处？

我们的应用程序通常通过Web服务,MQ,JDBC,专有(直接通过套接字)和其他传输孩子连接到不同的后端之王.我们已经有许多实现允许我们从应用程序连接到这些后端,虽然所有这些实现都实现了公共java接口,但它们不共享任何其他内容.

我们已经意识到所有这些特定连接器实现都有共同的代码部分代码,我们决定通过一个通用连接器简化未来连接器的开发.此连接器将能够将消息格式化为后端预期的格式,并使用可用的传输机制发送它们.例如:MQ或超过套接字的固定长度消息格式.

我们面临的困境之一是这种连接器最合适的技术.到目前为止,我们的连接器是实现常见Java接口的基本java类.由于我们通常在某些Java EE应用程序服务器中托管我们的应用程序,因此Java Connector Architecture似乎是最适合此软件的技术.但是,实现符合JCA标准的连接器似乎相对复杂.采用标准有什么明显的好处 - JCA并且有益于额外的努力吗？

事实上,JCA 似乎是最合适的技术.已经有了很好的论据,即可移植性,标准化接口,连接池和事务支持.不要忘记安全.

使用WebSphere Process Server,适配器可以作为SCA服务公开,如果这对您很重要,它可以带来很多好处.

此外,一些开发工具对开发和测试JCA连接器有广泛的支持.

另一个好处是(经验丰富的)Java EE管理员和Java EE开发人员(应该)知道标准,因此管理和开发应该易于简化.

但最终,您必须根据项目范围,您对项目的未来计划或公司政策内的政策,找到实施JCA的理由.

简短的回答:我认为选择JCA优于其他技术没有任何好处,我认为这是一个缺点,因为你需要Java EE容器.

答案很长:

一段时间以来,我一直对这些Java EE标准持怀疑态度.我没有看到使用全功能Java EE服务器的令人信服的技术理由,因为对于所提供的每个功能都有更好的开源实现.从"企业解决方案"转移到/从"企业解决方案"移动时,我已经被实施不兼容性多次咬了一口.

JCA的想法现在就出现在这里,我正在努力尝试apache camel或spring integration.我全都是开源实现,你可以在任何地方使用.还有很多事情要发生.检查此组件列表.当然,也许比JCA已经开发的更小,但是每一点都是开源的,而且都在一个地方.此外,我相信文档更简单,更完整.对集成的渴望需要一个功能强大的SPI,它具有大量开源,真实的实例,以相同的方式开发,并且可以在同一个地方找到.

我讨厌消极情绪,但我不喜欢功能齐全的应用服务器.举例来说,我会去Tomcat和陶土任何一天比其他"enterprisey"的产品,就像我会去骆驼JCA之前,直到JCA需要得到证实.我不喜欢Java委员会的想法,告诉我应该如何开发自己的应用程序,因为我不相信它们.我相信,当Java SE/RCP上的软件可以像在Java EE环境或纯Servlet容器中一样轻松工作时,这符合我的最佳利益.