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?
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.