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，但我不會依賴所有應用程序服務器上這些功能的一致實現。