我正在编写一个 JCA 资源适配器。我也在尝试完全理解 JCA 规范的连接管理部分。作为一个思想实验，假设此适配器的唯一客户端是位于不同机器上的 Swing Java Application Client。还假设资源适配器也将通过网络与其“企业信息系统”(EIS) 进行通信。
据我了解 JCA 规范，.rar 文件被部署到应用程序服务器。应用程序服务器创建 .rar 文件的 ManagedConnectionFactory 接口(interface)的实现。然后它要求它生成一个连接工厂，这是部署到 JNDI 供用户用来获取到资源的连接的不透明对象。 (对于 JDBC，连接工厂是 javax.sql.DataSource。)
要求连接工厂保留对应用程序服务器提供的 ConnectionManager 的引用，而后者又需要是可序列化的。这是有道理的——为了将连接工厂存储在 JNDI 中，它必须是可序列化的，并且为了保持对 ConnectionManager 的引用，ConnectionManager 也必须是可序列化的。很好，这个小对象图被安装在应用程序客户端的 JNDI 树中。
这是我开始感到反胃的地方。 ConnectionManager——应用服务器提供的应该处理连接管理、共享、池等的部分——此时是否完全出现在客户端上？它的工作之一是创建 ManagedConnection 实例，并且 ManagedConnection 不需要是可序列化的，并且它提供的用户连接句柄也不需要是可序列化的。这对我来说意味着整个连接池机制被批发到应用程序客户端并填充到它的 JNDI 树中。
这是否意味着来自客户端的 JCA 交互绕过了应用服务器的服务器端组件？ JCA API 中的网络边界在哪里？
最佳答案
Does this all mean that JCA interactions from the client side bypass the server-side componentry of the application server? Where are the network boundaries in the JCA API?
据我所知，是的。将有一个本地 JNDI，本地 JNDI 将返回本地连接。如果 JNDI 中其他类型的对象为真，则相同，例如配置值 (env-entry)。当然，如果您查找 EJB，工厂会返回远程 bean 的代理，但据我所知，JNDI 仍然是本地的。
客户端嵌入自己的池。这意味着，正如您所指出的，在客户端中获得的连接将逃脱服务器端机制。
当我们开始使用分布式事务时，情况会变得更糟。客户端可以获取 UserTransaction 以在客户端启动和停止分布式事务(尽管并非所有应用程序服务器都支持此功能)。事务上下文将在调用远程 EJB 期间传播。然后，分布式事务可以跨越客户端连接和服务器端连接。
根据J2EE哲学，应用客户端一般不应该使用事务，直接获取连接；它应该只与远程 EJB 通信。
对于更复杂的场景，规范并不是很清楚，而且周围的信息也不多。例如，规范不要求应用程序服务器向客户端公开 UserTransaction。
我在这里写的内容至少适用于 Glassfish，但我不会依赖在所有应用程序服务器上一致地实现此类功能。
关于java - Java 连接器体系结构 (JCA) 中的网络边界在哪里？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2237389/