我们的应用程序经常通过Web服务、MQ、JDBC、专有（直接通过套接字）和其他类型的传输与不同类型的后端连接。我们已经拥有了许多实现，让我们能够从我们的应用程序连接到这些后端，虽然所有这些实现都实现了共同的Java接口，但它们没有共享其他任何东西。
我们意识到，所有这些特定连接器实现都有重要的代码部分是通用的，我们决定通过一个通用连接器来简化未来连接器的开发。该连接器将能够将消息格式化为后端期望的格式，并使用可用的传输机制发送它们。例如，在MQ或套接字上使用固定长度的消息格式。
我们面临的一个问题是这种连接器最合适的技术。到目前为止，我们的连接器是基本的Java类，实现了共同的Java接口。由于我们通常在某个Java EE应用服务器中托管我们的应用程序，因此似乎Java连接器架构是这个软件部分最合适的技术。然而，实现符合JCA标准的连接器似乎相对复杂。选择标准JCA的明显好处是什么？这些好处是否值得额外的努力？
确实，JCA技术似乎是您最合适的选择。我们已经提出了一些优点，例如可移植性、标准化接口、连接池和事务支持。还有安全性方面也不能忽略。
使用WebSphere Process Server，适配器可以作为SCA服务公开，如果这对您很重要，会带来很多好处。
此外，一些开发工具对于开发和测试JCA连接器提供了广泛的支持。
另一个好处是（有经验的）Java EE管理员和Java EE开发人员应该熟知这个标准，因此管理和开发应该容易协调。
但最终，您需要根据项目范围、未来计划或公司政策等原因来决定是否实现基于JCA的解决方案。
现在这里浮现了JCA的想法，我正在推动尝试使用Apache Camel或Spring Integration。我完全支持开源实现，可以在任何地方使用。有很多事情正在进行中。请查看此组件列表。可能比已经使用JCA开发的更小，但每一部分都是开源的，并且都在一个位置上。另外，我认为文档更简单、更完整。集成的迫切需要呼唤一个强大的SPI，具有丰富的开源、真实的示例，以相同的方式开发，并且可以在同一位置找到。
我讨厌消极情绪，但我不喜欢功能齐全的应用服务器。例如，与其他“企业级”产品相比，我会选择tomcat和terracota任何一天，就像在需要证明之前我会选择camel而不是JCA一样。我不喜欢Java委员会告诉我如何开发自己的应用程序的想法，因为我不信任他们。我相信当软件可以在Java SE/RCP、Java EE环境或纯Servlet容器中同样轻松地工作时，这符合我的最佳利益。
这些好处主要是为那些希望销售连接器以用于任何应用服务器的专有后端系统的供应商和希望能够放置连接器而不必担心它只能在WebLogic而非Websphere上运行的客户而设计的。事实上，这是Java EE的总体目标。
请注意，JBoss已决定将几个东西放入JCA中，例如JDBC连接通过JCA进行。
您未来的客户端代码将具有标准化的接口、一些池化和事务支持等，但重要的是要保持对更大的局面的关注；即这些好处并不是针对您和您的一个项目，而是针对由许多应用服务器、许多后端系统、许多连接器等组成的软件生态系统。
