No-Interface Client View in EJB 3.1

  • 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 for very fine-grained components with closely coupled clients that are collocated in the same module.
    • 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 behaviour as the EJB 3.0 local view. 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:
package com.ibytecode.businesslogic;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;

public class FirstBean {
    public FirstBean() {

    public String sayHello() {
		return "Hello";
  • 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:
public class EJB31ServletClient extends HttpServlet {
	private static final long serialVersionUID = 1L;
	FirstBean bean;

	public EJB31ServletClient() {

	protected void doGet(HttpServletRequest request, 
			HttpServletResponse response) 
			throws ServletException, IOException 
		PrintWriter out = response.getWriter();
  • 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.

Refer this page for complete code.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.