views:

27

answers:

1

I have a @Stateless @Local Bean successfully deployed in an ear. I can see the new EJB 3.1 standard global JNDI name when I browse the JNDI tree. (java:global/product/product-ejb/ProductManagement)

I want to use this EJB in a different application on the same app server. Do I need to add a remote interface for this EJB?

+2  A: 

Inter-application access to the local client view is not required by the specification but might be optionally supported by your container. If you want your application to be portable, you shouldn't rely on it and use a Remote interface (a decent container should optimize calls inside a same JVM anyway). From the EJB 3.1 specification:

3.2.2 Local Clients

Session beans may have local clients. A local client is a client that is collocated in the same JVM with the session bean that provides the local client view and which may be tightly coupled to the bean. A local client of a session bean may be another enterprise bean or a web component.

Access to an enterprise bean through the local client view requires the collocation in the same JVM of both the local client and the enterprise bean that provides the local client view. The local client view therefore does not provide the location transparency provided by the remote client view.

Access to an enterprise bean through the local client view is only required to be supported for local clients packaged within the same application as the enterprise bean that provides the local client view. Compliant implementations of this specification may optionally support access to the local client view of an enterprise bean from a local client packaged in a different application. The configuration requirements for inter-application access to the local client view are vendor-specific and are outside the scope of this specification. Applications relying on inter-application access to the local client view are non-portable.

...

References

  • EJB 3.1 Specification
    • Section 3.2.2 "Local Clients"
Pascal Thivent
+1 Spot on. Most the vendor's I've compared notes with have automatic optimization of remote calls happening in the same vm. Do be careful though that non-optimizers often do not pass transaction and security information on remote calls in the same vm. The sneaky way to check is to see if you have the same thread on the both sides of the intra-vm remote invoke. If you do not, then bad luck, you hit the full remoting layer and picked up a new thread from the thread pool on the way back into the vm.
David Blevins
@David Thanks David. I really appreciate reading your comments and answers with all these priceless details. Thank you very much for sharing all this.
Pascal Thivent