Java连接器体系结构（JCA）中的网络边界在哪里？

Question

我正在编写JCA资源适配器。 我也是这样，试图完全理解JCA规范的连接管理部分。 作为一个思想实验，假装此适配器的唯一客户端将是位于不同计算机上的Swing Java应用程序客户端。 还假设资源适配器也将通过网络与其“企业信息系统”（EIS）进行通信。

据我了解JCA规范，.rar文件已部署到应用程序服务器。 应用程序服务器创建.rar文件的ManagedConnectionFactory接口实现。 然后它要求它生成一个连接工厂，它是部署到JNDI的不透明对象，供用户用来获取与资源的连接。 （对于JDBC，连接工厂是javax.sql.DataSource。）

连接工厂要求保留对应用程序服务器提供的ConnectionManager的引用，而ConnectionManager又需要Serializable。 这是有道理的 - 为了将连接工厂存储在JNDI中，它必须是可序列化的，并且为了使它保持对ConnectionManager的引用，ConnectionManager也必须是可序列化的。 很好，这个小对象图安装在应用程序客户端的JNDI树中。

这是我开始变得不安的地方。 ConnectionManager - 由应用程序服务器提供的应该处理连接管理，共享，池化等的部分 - 此时完全出现在客户端上吗？ 其中一项工作是创建ManagedConnection实例，而ManagedConnection不需要是Serializable，并且用户连接处理它们也不需要序列化。 这告诉我整个连接池机器批发到应用程序客户端并填充到其JNDI树中。

这是否意味着来自客户端的JCA交互绕过了应用服务器的服务器端组件？ JCA API中的网络边界在哪里？

Answer 1

这是否意味着来自客户端的JCA交互绕过了应用服务器的服务器端组件？ JCA API中的网络边界在哪里？

AFAIK，是的。 将有一个本地JNDI，本地JNDI将返回本地连接。 如果对于JNDI中的其他类型的对象，则为相同，例如配置值（ env-entry ）。 当然，如果查找EJB，工厂会将代理返回给远程bean，但JNDI仍然是我所知的本地代码。

客户端嵌入了自己的池。 这意味着，正如您所指出的那样，在客户端中获得的连接将逃离服务器端机器。

当我们开始使用分布式事务时，它会变得更糟。 客户端可以获取UserTransaction以在客户端启动和停止分布式事务（但并非所有应用程序服务器都支持此操作）。 事务上下文将在调用远程EJB期间传播。 然后，分布式事务可以跨越客户端连接和服务器端连接。

根据J2EE理念，应用程序客户端通常不应使用事务并直接获取连接; 它应该只与远程EJB通信。

关于更复杂的情况，规范并不是很清楚，并且没有太多的信息。 例如，规范不要求应用服务器将UserTransaction暴露给客户端。

我在这里写的内容至少适用于Glassfish，但我不会依赖所有应用程序服务器上这些功能的一致实现。