What is local/remote and no-interface view in EJB?

Question

I am trying to understand what the purpose and why we need the different client views in EJB. Could someone try to explain?

Iamb

Answer 1

Remote client view

When your EJB and its clients will be in a distributed environment - meaning EJBs and clients will reside on separate Java virtual machines. Example : EJBs hosted on a WebSphere Application Server and Servlets that consume EJB APIs hosted on a Tomcat server.

Local client view

Only when it is guaranteed that other enterprise beans or clients will only address the bean within a single JVM. Example, EJBs as well as the Servlets deployed on the same WebSphere server.

No-Interface view

Is almost same as local client view, but there are differences. Your bean class is not required to implement client view interfaces in this case. All public methods of the bean class are automatically exposed to the caller. no-interface view always acquires an EJB reference - just like local or remote views - either through injection or JNDI lookup; but, Java type of the EJB reference is the bean class type rather than the type of a local interface. This is a convenience introduced as part of Java EE6.

Difference between local client view and no-interface view

In case of no-interface view, the client and the target bean must be packaged in the same application (EAR). In case of local view, client can be packaged in a separate application than the enterprise application. So, this gives more flexibility in terms of fine-graining your components.

You may use local client view vs no-interface view depending on your API usage scenario. It is very likely for no-interface view to receive flexible features in future specs.

Reason

Historically or otherwise, a client wishing to use EJB services was supposed to "look up" the bean on the container ( with certain initial contexts ). That was because all invocations are made through a special EJB reference(proxy) provided by the container. This allows the container to provide all the additional bean services such as pooling, container-managed transactions etc. So, a client can not explicitly instantiate an EJB with new operator. The client view is provided via certain interfaces that the client would have access to. The proxy realization at server side is done based on these interfaces. Different client views are defined to suite different deployment scenarios as mentioned above.

Theta

I'm wondering if it is really the case, that a local client view can be used between different enterprise applications. In the EJB 3.2 specification, section 3.2.2, it is stated that invoking beans from different applications through local client views is vendor specific and may not be supported in containers. You had any specific app server in mind? – Mcreynolds

What happen? if we "new" an EJB (this could happen if the client and EJB stay in the same application) – Fernandafernande

If you use new you end up getting a new instance. That's all. That new instance will not have any "support" from container in terms of pooling, setting its context etc. You are running on your own. – Theta

Another thing I just realized in JBoss 7.1.3 is that when I have an EJB that implements an interface that is neither marked as Local nor Remote, I can inject the EJB as its interface type in CDI beans unsing CDI Inject. What Kind of view of the EJB is this? Fun fact is that I cannot CDI Inject any Local or Remote interface types due to a bug in JBoss regarding this. – Bunche

@Mcreynolds Agree with your finding. This definitely is vendor specific. Same thing mentioned in EJB 3.1 spec. – Bligh

@Gandalf: You can inject the EJB probably because it is managed by the CDI container not because it is a EJB. The proper way to combine EJB and CDI containers it to use a CDI provider. – Blowing

@Fernandafernande another issue if you "new" the EJB is if this same EJB have injected attributes, they will all throw null pointer exceptions. And then deal with them with reflection haha... – Mull

"EJB APIs hosted on a Tomcat server."? Tomcat is not a Java EE server. – Lachrymatory

Answer 2

As per Section 3.2.2 of EJB 3.1 Specification:

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.

No-interface view is just a convenience feature that allows a bean to expose a local client view without having to declare a separate interface.

Tea