Nov 10, 2018

No-interface View in EJB

The EJB 3.0 local client view is based on a plain old java interface (POJI) called a local business interface. A local interface defines the business methods that are exposed to the client and that are implemented on the bean class.

Although this separation of interface and implementation is a well-accepted approach to application design, the separation sometimes is unnecessarily cumbersome and adds little value. This is especially true for very fine-grained components with closely coupled clients that are collocated in the same module. Developers have asked for a way to get the same enterprise bean functionality without having to write a separate business interface. The EJB 3.1 specification addresses this by making local business interfaces optional. The result is the no-interface local view.

The no-interface view has the same behavior as the EJB 3.0 local view, for example, it supports features such as pass-by-reference calling semantics and transaction and security propagation. However, a no-interface view does not require a separate interface, that is, all public methods of the bean class are automatically exposed to the caller. By default, any session bean that has an empty implements clause and does not define any other local or remote client views, exposes a no-interface client view.

For example, the following session bean exposes a no-interface view:

@Stateless
public class HelloBean {
public String sayHello() {
return "hello";
}
}


As is the case for a local view, the client of a no-interface view always acquires an EJB reference -- either through injection or JNDI lookup. The only difference is that the Java type of the EJB reference is the bean class type rather than the type of a local interface. This is shown in the following bean client:
 
@EJB private HelloBean helloBean;
 ... 
String msg = helloBean.sayHello();

Note that even though there is no interface, the client cannot use the new() operator to explicitly instantiate the bean class. That's because all bean invocations are made through a special EJB reference, or proxy, provided by the container. This allows the container to provide all the additional bean services such as pooling, container-managed transactions, and concurrency management.