Can a Stateless session bean have both remote and local interfaces so that certain methods I can call locally and others remotely?
I need this because there is a batch process running as part of the Server which need to call some methods locally to avoid network traffic and the online process will call remotely. I can create two seperate Stateless session beans one having remote interface and the other having local interface but some of the methods are shared between batch and online and I want to avoid duplicating if possible.
Yes, it is possible for a bean to have both local and remote interfaces, and quite easy to do-- just create your local and remote interfaces, and the respective home interfaces, and specify them in the deployment descriptor like so:
Hope this helps...if you have any questions, feel free to email me.
Thanks. Is there any coding (regarding the exceptions to throw) or performance issues doing this? The JNDI name for lookup will be the same whether you use local or remote interface for this bean right? It should just differ in the way we get the home instance, in local home, it will be a simple lookup and in remote home, it will be the narrow method way.
Regarding exceptions-- the methods of your local interface won't throw "RemoteException" (it won't be part of their method signature, though they may still be declared to throw other application exceptions). The JNDI names for your local and remote homes will be different-- in weblogic, for example, they are declared in the weblogic-ejb-jar like follows:
The client must be co-located to work with a local EJB, so the lookup of the local home is explicit; it is _not_ transparent to the caller. If you require that type of transparency, (one JNDI lookup, for all callers), you will probably need to use just a remote interface.
Also note the "call by value" nature of the remote call and the "call by reference" nature of local calls. See section 5.4 in the EJB 2.0 specification for details.
From the spec:
"Developers who want to preserve the ability to distribute components at a later date should rely on the efficiency benefits of pass by refer-ence semantics, but not rely on the side-effects."