我们的应用程序通常通过 Web 服务、MQ、JDBC、专有（直接通过套接字）和其他类型的传输连接到不同类型的后端。我们已经有许多实现，让我们从应用程序连接到这些后端，虽然所有这些实现都实现了通用的java接口，但它们不共享任何其他内容。
我们已经意识到，对于所有这些特定的连接器实现，代码中有一些含义部分是通用的，因此我们决定通过一个通用连接器来简化未来连接器的开发。此连接器将能够将邮件格式化为后端预期的格式，并使用可用的传输机制发送邮件。例如，通过 MQ 或套接字的固定长度消息格式。
我们面临的困境之一是最适合这种连接器的技术。到目前为止，我们的连接器是实现通用java接口的基本java类。由于我们通常将应用程序托管在某些Java EE应用程序服务器中，因此Java Connector Architecture似乎是最适合该软件的技术。但是，实现符合 JCA 标准的连接器似乎相对复杂。采用标准 - JCA有哪些明显的好处，好处是否证明额外的努力是合理的？
事实上，JCA似乎是最适合您的技术。已经提出了很好的论点，即可移植性，标准化接口，连接池和事务支持。不要忘记安全性。
使用 WebSphere Process 服务器，适配器可以公开为 SCA 服务，如果这对您很重要，则可以带来很多好处。
此外，一些开发工具对开发和测试 JCA 连接器提供了广泛的支持。
另一个好处是（有经验的）Java EE管理员和Java EE开发人员（应该）知道标准，因此管理和开发应该易于简化。
但最终，您应该根据项目的范围，您对项目的未来计划或公司的政策，找到实施JCA的理由。
简短的回答：我认为选择JCA优于其他技术没有任何好处，我认为这是一个缺点，因为您需要Java EE容器。
长答案：
一段时间以来，我一直对这些Java EE标准持怀疑态度。我没有看到一个令人信服的技术理由来使用功能齐全的Java EE服务器，因为所提供的每个功能都有更好的开源实现。在移入/移出“企业解决方案”时，我多次因实施不兼容而咬伤。
JCA的想法现在在这里浮出水面，我正在推动尝试apache骆驼或弹簧集成。我完全支持你可以在任何地方使用的开源实现。而且有很多事情正在发生。检查此组件列表。当然，也许比JCA已经开发的东西要小，但每个位都是开源的，而且都在一个地方。另外，我相信文档更简单，更完整。对集成的渴望需要一个强大的SPI，其中包含大量开源，真实的实时示例，以相同的方式开发，并且可以在同一个地方找到。
我讨厌消极情绪，但我不喜欢功能齐全的应用程序服务器。例如，我每天都会选择tomcat和terracota而不是其他“企业”产品，就像我在JCA之前选择骆驼一样，直到JCA的需求得到证明。我不喜欢Java委员会的想法来告诉我应该如何开发自己的应用程序，因为我不信任它们。我相信，当该软件可以在Java SE / RCP上像在Java EE环境或纯Servlet容器中一样容易地工作时，这符合我的最佳利益。
