java JCA有什么好处？

What are the benefits of JCA?

提问by Dan

Our application often connects to a different kind of back-ends over web services, MQ, JDBC, proprietary (direct over socket) and other kinds of transport. We already have a number of implementations that let us connect from our application to these back-ends and while all of these implementations implement the common java interface, they do not share anything else.

我们的应用程序通常通过 Web 服务、MQ、JDBC、专有（直接通过套接字）和其他类型的传输连接到不同类型的后端。我们已经有许多实现可以让我们从我们的应用程序连接到这些后端，虽然所有这些实现都实现了通用的 java 接口，但它们不共享任何其他东西。

We have realized that there are signification portions of code that are common for all of these particular connector implementations and we have decided to streamline the development of future connectors through one universal connector. This connector will be capable of formatting messages to a format expected by back-end and sending them using the available transport mechanism. For example, fixed-length message format over MQ or over a socket.

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

One of the dilemmas we are facing is the most appropriate technology for this kind of connector. So far, our connectors were basic java classes that implement the common java interface. Since we generally host our applications in some Java EE application server, it seems that Java Connector Architecture would be the most appropriate technology for this piece of software. However, implementing JCA compliant connector seems to be relatively complex. What are the palpable benefits of going with the standard – JCA and do benefits justify the additional effort?

我们面临的困境之一是最适合这种连接器的技术。到目前为止，我们的连接器是实现通用 java 接口的基本 java 类。由于我们通常将应用程序托管在某个 Java EE 应用程序服务器中，因此 Java 连接器架构似乎是最适合该软件的技术。但是，实现符合 JCA 的连接器似乎相对复杂。遵循标准 - JCA 的明显好处是什么？这些好处是否证明了额外的努力是合理的？

采纳答案by bousch

Indeed JCA seemsthe most appropriate technology for you. Already excellent arguments have been made, namely the portability, standardised interface, the connection pooling and transaction support. And don't forget security.

事实上，JCA似乎是最适合您的技术。已经提出了极好的论点，即可移植性、标准化接口、连接池和事务支持。并且不要忘记安全。

With WebSphere Process server the adapters could be exposed as a SCA service which can have a lot of benefits if that's important for you.

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

Also some development tools have extensive support for developing and testing JCA connectors.

此外，一些开发工具为开发和测试 JCA 连接器提供了广泛的支持。

Another benefit is (experienced) Java EE Administrators and Java EE developers (should) know the standard so administration and development should be easy to streamline.

另一个好处是（有经验的）Java EE 管理员和 Java EE 开发人员（应该）知道标准，因此管理和开发应该很容易简化。

But in the end you should have to find reasons to implement JCA based on the scope of your project, the future plans you have for your project or maybe within the policy of your company.

但最终，您必须根据您的项目范围、您对项目的未来计划或可能在您公司的政策范围内找到实施 JCA 的理由。

回答by H Marcelo Morales

Short answer: I see no benefit on selecting JCA over other technologies, I see it as a drawback since you need Java EE container.

简短回答：与其他技术相比，我认为选择 JCA 没有任何好处，我认为这是一个缺点，因为您需要 Java EE 容器。

Long answer:

长答案：

I've been skeptic about these Java EE standards for some time now. I don't see a compelling technicalreason to use a full featured Java EE server anymore, since there are better open source implementations for everyfeature offered. I've been bitten several times by implementation incompatibilities when moving to/from "enterprisey solutions".

一段时间以来，我一直对这些 Java EE 标准持怀疑态度。我认为不再有令人信服的技术理由来使用全功能的 Java EE 服务器，因为提供的每个功能都有更好的开源实现。在移入/移出“企业解决方案”时，我曾多次被实现不兼容所困扰。

The idea for JCA is surfacing here right now and I am pushing to try apache camelor spring integrationinstead. I am all for open source implementations that you can use everywhere. And there is a lot going on. Check this list of components. Granted, maybe is smaller than whats already developed with JCA, but every bit is open sourced and it's all on one location. Also, I believe the documentation is simpler and more complete. The urge for integration calls for a powerful SPI with plenty of open source, real live examples, developed in the same fashion, and that can be found on the same place.

JCA 的想法现在在这里浮出水面，我正在推动尝试apache camel或spring 集成。我完全支持你可以在任何地方使用的开源实现。有很多事情正在发生。检查此组件列表。诚然，它可能比 JCA 已经开发的要小，但每一点都是开源的，而且都集中在一个位置。另外，我相信文档更简单、更完整。集成的冲动需要强大的 SPI，其中包含大量开源、真实的示例，以相同的方式开发，并且可以在同一个地方找到。

I am hating the negativity, but I don't like full featured application servers. For instance, I would go for tomcat and terracota any dayover other "enterprisey" products, just as I would go with camel before JCA, until the need for JCA gets proven. I don't like the idea of the Java Committee to tell how I should develop my own applications because I don't trust them. I believe it is in my best interest when the piece of software can work just as easily on Java SE/RCP as in a Java EE environments or in a pure Servlet container.

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

回答by Kimble

I've just developed an inbound resource adapter for a gps device communicating over an proprietary protocol. It wasn't that much hassle, though I've got the impression that developing an outbound one might require more work. The worst thing with the JCA is the lack of documentation. All books and articles seems to have the same dumb example.

我刚刚为通过专有协议进行通信的 gps 设备开发了一个入站资源适配器。这并没有那么麻烦，尽管我的印象是开发出站可能需要更多的工作。JCA 最糟糕的事情是缺乏文档。所有书籍和文章似乎都有相同的愚蠢例子。

The thing I'm most pleased with is the portability. Once you've written the adapter you can plug the rar (resource adapter archive) into any application server to provide deployed applications the ability to communicate with eis supported by your ra. Or you can bundle the rar into the war/ear.

我最满意的是便携性。一旦您编写了适配器，您就可以将 rar（资源适配器存档）插入任何应用程序服务器，以便为已部署的应用程序提供与您的 ra 支持的 eis 进行通信的能力。或者您可以将 rar 捆绑到 war/ear 中。

回答by David Plumpton

The benefits are primarily for vendors who wish to sell connectors to proprietary back end systems for use with any app server, for customers who want to be able to drop in a connector without worrying about whether it only works on WebLogic not Websphere, etc. Indeed this is the goal of Java EE in general.

这些好处主要适用于希望将连接器销售到专有后端系统以与任何应用程序服务器一起使用的供应商，也适用于希望能够插入连接器而不用担心它是否仅适用于 WebLogic 而不是 Websphere 等的客户。确实如此。这是 Java EE 的总体目标。

Note that JBoss has decided to put several things into JCA, for example JDBC connections go via JCA.

请注意，JBoss 已决定将一些内容放入 JCA，例如 JDBC 连接通过 JCA。

Your future client code will have a standardised interface, some pooling and transaction support etc. but it's important to keep sight of the bigger picture; namely that the benefits are not targeted at you and your one project specifically, but at a software eco-system consisting of many app servers, many back end systems, many connectors and so on.

您未来的客户端代码将具有标准化接口、一些池化和事务支持等。但重要的是要着眼于大局；即好处不是专门针对您和您的一个项目，而是针对由许多应用程序服务器、许多后端系统、许多连接器等组成的软件生态系统。

回答by John Ellinwood

Sounds like a good use for a JBIcontainer with binding components. Discussionof JCA vs JBI.

听起来很适合带有绑定组件的JBI容器。 JCA 与 JBI 的讨论。