One possible solution is that you cluster the two nodes and deploy one (different) application to each.
In this case the same JNDI context is available on both instances.
But why you have such approach, if you call always an EJB remote it will have network latency and traffic.
If you deploy the applications for both the JBoss cluster do the loadbalancing and failover for you
I think my original post has quite a few mistakes. - I need clients on server B to call interfaces on server A without doing a remote lookup. And the two options I was looking at were -
1. On server A - to configure ejbs to also bind to the naming service on B while getting deployed.
2. On server B - to configure jndi so that the jndi name indirectly points to jnp://serverA:1099/jndi name
Well, the reason we need this approach is that server B is going to be within a firewall and server A is going to be outside of it. The main application will be deployed on server B and only certain specific interfaces that cannot function within the firewall will be deployed on server A. So when the server processing happens on server B and it tries to invoke those specific interfaces, I need it to get processed by A instead of B. But since the application has been originally designed for a single server - all look ups are local and I would like to leave it that way. I don't think clustering would be an option because we do not want server A to do any of the processing like DB access - the only processing it should do would be those specific functions which cannot happen behind a firewall.