通过 JNDI 客户端访问企业资源
在大型java 企业基础设施中，我体验到了一种如何从多个JNDI 服务器访问资源的模式，例如不同的应用程序服务器，每个服务器都服务于一个企业bean 模块。
此模式包括客户端显式指示 JNDI 服务器希望通过 jndi 提供程序 url 属性解析给定资源。
为了实现这一点，客户端为其请求资源的每个不同服务器设置给定的命名上下文。
我想知道一种不同的、也许更强大的方法： 客户端设置一个唯一的初始上下文，可以连接到多个 JNDI 服务器。 类似这样的事情：
env.put (Context.PROVIDER_URL, "serverA:1100,serverB:1100,serverC:1100")
JNDI 实现本身应该发现哪个服务根据一致的命名模式解析给定的资源。
这是一个可行且合理的方法吗？
Inside large java enterprise infrastructures I've experienced a pattern on how to access resources from more than one JNDI server, eg different application servers each one serving a module of enterprise beans.
This pattern consists on the client explicitly instructing JNDI the server it expects to resolve a given resource through jndi provider url property.
To achieve it, the client sets up a given Naming Context for each different server it asks a resource.
I've wondered about a different and maybe more robust approach:
The client sets up an unique Initial Context which may connect to multiple JNDI servers.
Something like that:
env.put (Context.PROVIDER_URL, "serverA:1100,serverB:1100,serverC:1100")
JNDI implementation itself should discover which service resolves a given resource based on a consistent naming schema.
Is this a viable and plausible approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您描述的 URL 模式（“serverA:1100,serverB:1100,serverC:1100”）已被某些应用程序服务器 InitialContext 实现所接受，但用于定义负载平衡以到达集群中的初始上下文！
例如，如果您在 Weblogic Server 中使用此 URL，它将使用循环算法从列表中的服务器检索可用的初始上下文。它不会使用您在查找时描述的逻辑，而仅连接到初始上下文。
一种替代方法是使用外部 JNDI 提供程序，这是一种将外部 JNDI 服务器和组件映射到集中式服务器和组件的技术，然后您可以在链接名称中使用一致的命名模式（谷歌“外部 JNDI 提供程序”来查找一些信息） ）。 Weblogic 也支持此功能，就像其他服务器一样。
服务定位器模式也可以用于在应用程序层中执行此逻辑。
规范没有定义关于provider_url的规则，只是说这个属性的使用是由初始上下文实现定义的。所以它是合理的，但一旦它被用来定义负载平衡就不再直观。另一个问题是 Java EE 规范不保证 EJB 组件的 JNDI 绑定名称的任何内容，因此糟糕的 JNDI 实现一定不允许您定义 JNDI 名称。
我认为最好的解决方案是使用外部 JNDI 映射或服务定位器。
The URL pattern you described ("serverA:1100,serverB:1100,serverC:1100") is already accepted by some application servers InitialContext implementations, but is used to define LOAD BALANCE to reach initial contexts in a cluster!
For example, if you use this URL in Weblogic Server, it will use a round-robin algorithm to retrieve an available initial context from the servers in the list. It will not use the logic that you described at the lookup time, but only to connect to the initial context.
One alternative is to use Foreign JNDI Providers, that is a technique where you map external JNDI servers and components to an centralized one, and then you can use a consistent naming schema in the linking names (google "foreign JNDI provider" to find some information). Weblogic supports this feature too, like other servers maybe do.
The service locator pattern can also be used to do this logic in the application layer.
The specification does not define rules about the provider_url, just says that this property usage is defined by the initial context implementation. So it is plausible, but will not be intuitive once it is already used to define load balancing. Another problem is that Java EE specification does not guarantees anything about JNDI binding names for EJB components, so a poor JNDI implementation must not let you define the JNDI names.
I think the best solution is to use foreign JNDI mapping or service locator.