Hmm... just make sure that your local (same JVM) client code lookup the local interface (or uses @EJB) and the remote ones lookup the remote interface!
Do you really have the webtier as a separate layer? Most cases this is not good for performance. Move the web tier into the same layer as the ejb tier to minimize networks overhead.
Thanks Anders. It seems like JBoss will take care of this. i.e if the EJB call is made from the same JVM it does a local call.
In regards to webtier as a seperate layer, yes that is right. Even if we move the webtier into the same layer as the ejb tier we will have to do the remote call to some extent as the traffic is more.
i.e say I have 3 servers (with web/app in the same server using 8080 for web & 7001 port for app) we need these 3 servers to be clustered as it can load balance it when the traffic is more. So it will act as back to back servers. In other words a web request from Server 1 can go app tier in the server 2 and this will be a remote. Hope it make sense.
I still don't think that you should cluster on the EJB level when using a web tier. Do the loadbalancing in front of the web tier and make ALL calls from the web tier to the EJB tier local. You should always make a local call for performance and if the local EJB layer fails then the Web tier will (probably) fails as it is in the same JVM and the loadbalancer will then do a failover to another JBoss instanceve
But of course you may have some reason for not doing it as I do not know your use case