Java 连接器架构 (JCA) 中的网络边界在哪里？
我正在编写一个 JCA 资源适配器。我也在尝试完全理解 JCA 规范的连接管理部分。作为一个思想实验，假设该适配器的唯一客户端是位于不同机器上的 Swing Java 应用程序客户端。还假设资源适配器也将通过网络与其“企业信息系统”(EIS) 通信。
据我了解 JCA 规范，.rar 文件被部署到应用程序服务器。应用程序服务器创建 .rar 文件的 ManagedConnectionFactory 接口的实现。然后，它要求它生成一个连接工厂，这是部署到 JNDI 供用户用来获取资源连接的不透明对象。 （对于 JDBC，连接工厂是 javax.sql.DataSource。）
要求连接工厂保留对应用程序服务器提供的 ConnectionManager 的引用，而该引用又要求是可序列化的。这是有道理的——为了将连接工厂存储在 JNDI 中，它必须是可序列化的，并且为了让它保留对 ConnectionManager 的引用，ConnectionManager 也必须是可序列化的。很好，这个小对象图被安装在应用程序客户端的 JNDI 树中。
这就是我开始感到恶心的地方。 ConnectionManager（由应用程序服务器提供的用于处理连接管理、共享、池化等的部分）此时是否完全出现在客户端上？它的工作之一是创建 ManagedConnection 实例，并且 ManagedConnection 不需要是可序列化的，并且它提供的用户连接句柄也不需要是可序列化的。这对我来说意味着整个连接池机制被批量运送到应用程序客户端并填充到其 JNDI 树中。
这是否意味着来自客户端的 JCA 交互绕过了应用程序服务器的服务器端组件？ JCA API 中的网络边界在哪里？
I am writing a JCA resource adapter. I'm also, as I go, trying to fully understand the connection management portion of the JCA specification. As a thought experiment, pretend that the only client of this adapter will be a Swing Java Application Client located on a different machine. Also assume that the resource adapter will communicate with its "enterprise information system" (EIS) over the network as well.
As I understand the JCA specification, the .rar file is deployed to the application server. The application server creates the .rar file's implementation of the ManagedConnectionFactory interface. It then asks it to produce a connection factory, which is the opaque object that is deployed to JNDI for the user to use to obtain a connection to the resource. (In the case of JDBC, the connection factory is a javax.sql.DataSource.)
It is a requirement that the connection factory retain a reference to the application-server-supplied ConnectionManager, which, in turn, is required to be Serializable. This makes sense--in order for the connection factory to be stored in JNDI, it must be serializable, and in order for it to keep a reference to the ConnectionManager, the ConnectionManager must also be serializable. So fine, this little object graph gets installed in the application client's JNDI tree.
This is where I start to get queasy. Is the ConnectionManager--the piece supplied by the application server that is supposed to handle connection management, sharing, pooling, etc.--wholly present on the client at this point? One of its jobs is to create ManagedConnection instances, and a ManagedConnection is not required to be Serializable, and the user connection handles it vends are also not required to be Serializable. That suggests to me that the whole connection pooling machinery is shipped wholesale to the application client and stuffed into its JNDI tree.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我所知，是的。将有一个本地 JNDI，本地 JNDI 将返回本地连接。如果 JNDI 中的其他类型的对象为 true，则相同，例如配置值 (
env-entry)。当然，如果您查找 EJB，工厂会返回远程 bean 的代理，但据我所知，JNDI 仍然是本地的。客户端嵌入自己的池。正如您所指出的，这意味着在客户端中获得的连接将逃逸服务器端机器。
当我们开始使用分布式事务时，情况会变得更糟。客户端可以获取 UserTransaction 来启动和停止客户端的分布式事务（但并非所有 app.server 都支持此操作）。事务上下文将在调用远程 EJB 期间传播。分布式事务可以跨越客户端连接和服务器端连接。
根据J2EE理念，应用程序客户端通常不应该使用事务并直接获取连接；它应该只与远程 EJB 通信。
对于更复杂的场景，规范并不清楚，并且没有太多信息。例如，规范并未强制应用程序服务器向客户端公开 UserTransaction。
我在这里写的内容至少适用于 Glassfish，但我不会依赖在所有应用程序服务器上一致地实现此类功能。
AFAIK, yes. There will be a local JNDI and the local JNDI will return local connections. Same if true for other kind of object in the JNDI, such a configuration value (
env-entry). Of course, if you look up an EJB, the factory returns a proxy to the remote bean, but the JNDI is still local to my knowledge.The client embeds its own pool. This means, as you pointed out, that connections obtained in the client will escape the server-side machinery.
It gets even worse when we start to play with distributed transactions. A client may obtain a
UserTransactionto start and stop distributed transactions on the client-side (not all app. server supports this, though). The transaction context will be propagate during calls to remote EJB. A distributed transaction may then span client-side connections and server-side connections.According to the J2EE philosophy, an application client should normally not use transactions and obtain connection directly; it should solely communicate with remote EJB.
The specs are not really clear about more complicated scenario and there isn't that many information around. The spec do for instance not mandate the application server to expose the
UserTransactionto the client.What I wrote here applies to Glassfish at least, but I would not rely on a consistent implementation of such features across all application servers.