大型java企業基礎架構內部我經歷了一個關於如何從多個JNDI服務器訪問資源的模式，例如不同的應用程序服務器，每個服務器服務於一個企業bean模塊。通過JNDI客戶端獲取企業資源
此模式由客戶端明確指示JNDI服務器，它期望通過jndi提供商url屬性來解析給定資源。
爲了實現它，客戶端爲每個不同的服務器設置了一個給定的命名上下文，以請求資源。
我想知道一種不同的，也許更健壯的方法： 客戶端設置一個獨特的初始上下文，它可能連接到多個JNDI服務器。 類似的東西：
env.put (Context.PROVIDER_URL, "serverA:1100,serverB:1100,serverC:1100")
JNDI實現本身應該瞭解哪些服務解決基於一致的命名模式給定的資源。
這是一種可行且合理的方法嗎？
您描述的URL模式（「serverA：1100，serverB：1100，serverC：1100」）已被某些應用程序服務器InitialContext實現接受，但用於定義LOAD BALANCE以達到羣集中的初始上下文！
例如，如果您在Weblogic Server中使用此URL，它將使用循環算法從列表中的服務器檢索可用的初始上下文。它不會使用您在查找時描述的邏輯，而只是連接到初始上下文。
另一種方法是使用外部JNDI提供程序，這是一種將外部JNDI服務器和組件映射到中央服務器和組件的技術，然後您可以在鏈接名稱中使用一致的命名模式（谷歌「外部JNDI提供程序」找到一些信息）。 Weblogic也支持這個功能，就像其他服務器一樣。
服務定位器模式也可用於在應用程序層中執行此邏輯。
規範沒有定義關於provider_url的規則，只是說這個屬性的用法是由初始上下文實現定義的。所以它是有道理的，但一旦它已經用於定義負載平衡，它將不會很直觀。另一個問題是，Java EE規範不能保證任何關於EJB組件的JNDI綁定名稱，所以一個糟糕的JNDI實現不能讓你定義JNDI名稱。
我認爲最好的解決方案是使用外部JNDI映射或服務定位器。