I am also very interested in this topic. I'm still browsing the docs (JNDI / JBoss /...) to find anything relevant to it, but if anybody has pointers they would be more than welcome.
Typical problem would be: Bean A on server 1, bean B on server 2. You want a client not to have knowledge bean A is on server 1, but query a JNDI server C which provides him with this information.
==> how do you link / synchronize JDNI servers?
As i understand it up to now, there is no support provided for this in JBoss. Some other J2EE implementations offer clustering services that include what we want to do here with JNDI.
Which doesn't mean it's impossible with JBoss, you just have to create it yourself.
I would think of something like:
- running another Naming Service MBean on another host / port. Call this the central server, and this one should be listed in clients jndi.properties and all beans should have this listed in their local component environment for looking up external beans.
- each time you build and deploy a bean on some jboss server, also deploy the new aliases/references to the central server's Naming Service mbean.
How this last update is achieved is still an open question to me. I would hope i can somehow send a xml file to the deploy directory of the central server. If this is not possible, i can deploy a small bean / mbean / ... that would in its initialization code add the new aliases to the central Naming Service mbean. Or this could be done in the new bean initialization, or from the client, but then you would need to allow remote updates of this central Naming Service, which would bring in some security issues.
Again, don't know what is possible / what has been done before. If you have any pointers, let me know.
You can use a central JNDI like this (it is a working example of a message driven bean with using a Queue on a different JBoss server).
dont know if something similar works for SFSB or SLSB or EB.
jboss.xml of your bean:
<configuration-name>Foreign Queue Message Driven Bean</configuration-name>
<container-name>Foreign Queue Message Driven Bean</container-name>
<!-- CMT -->
<!-- BMT -->
at your jboss.jcml
if you're using org.jboss.naming.ExternalContext Mbean it should be possible to built a global JNDI Tree which federates all other local JNDI trees into one global one. By pointing all clients via jndi.properties to this JNDI instance you would use a global JNDI tree.
We're trying to get this flying, but currently obtaining an EJB-Remote interface via a external (mapped into the local tree) provider fails with a NoContext naming exception. Browsing the information globally works like a charm. Might be some obscure rmi problem....
I think your method could work, but let me make sure i get it. Say you have jboss servers A and B and decide to make the JNDI RMI Registry on A the 'central' one.
On A you always map the namespace /servers/B to the ExternalContext of the JNDI RMI Registry B.
Then, when you deploy say a session bean 'interest' on B and map the Remote interface as 'interest/Interest', you also add a NamingAlias on A: 'all/interest/Interest' --> ' /servers/B/interest/Interest'.
This way a client can always query server A '/all/[bean name]' to get a remote RMI object, independantly from the actual location of the object.
I'd like to see this working, will put some time in it (how can you easily at bean deploy time on server B also add a NamingAlias to server A (in its jboss.jcml?!)? does this cross-referencing actually work? ...).
I've also figured in the meanwhile that LDAP might bring an alternative solution. Since an LDAP service is not a bad thing to have entreprise-wide anyways, why not put references in it to the different objects on the jboss servers. Seen the search / aliasing / referencing / distribution capabilities of LDAP, this seems to be a great tool for achieving this. I also know there is a schema for Java RMI objects (and references to them).
I'm still too rookie to judge if any of these solutions could actually work, so more on this after some reading/testing (unless someone with experience can comment on this...).