Optional Local Business Interfaces

The EJB 3.0 Simplified API made it much simpler to write a Local business interface for an EJB component. But what if you don't even need a separate interface? That's an issue we're planning to address in the EJB 3.1 Specification by making local business interfaces optional.

Let's start by looking at an example of a simple EJB 3.0 stateless session bean exposing a Local view :

   1:  public interface Hello {
   2:    public String hello();
   3:  }
   5:  @Stateless
   6:  public class HelloBean implements Hello {
   7:    public String hello() { return "hello"; }
   8:  }

Here's a client of that bean :

   1:  @EJB Hello helloRef;
   2:  ...
   3:  helloRef.hello();

Pretty straightforward, but in some cases developers find it cumbersome to use a separate interface as the contract for their client. This is especially true for fine-grained components accessed locally from clients within the same module. It's one more file per component to write and keep in sync with the bean class, and one more .class to package into the application.

Here's how a corresponding EJB 3.1 component using a "no-interface view" might look :

   1:  @Stateless
   2:  public class HelloBean {
   3:    public String hello() { return "hello"; }
   4:  }

All public bean class methods are exposed as the client method contract. The client acquires an EJB reference the same way as before. The only difference is that the reference type is a bean class instead of a local business interface :

   1:  @EJB HelloBean helloRef;
   2:  ...
   3:  helloRef.hello();

It's important to note that even though there is no interface, the client still interacts with the bean through an EJB reference object. The client never directly instantiates the bean class using the new() operator or holds a direct reference to a bean instance. This makes the client programming model almost identical between the Local view and the no-interface view. All semantics regarding transaction propagation, exception handling, concurrent access, etc. stay the same.

We think the no-interface view will be one of many nice options for simplifying EJB applications going forward. What do you think? Please post comments here or send them to jsr-318-comments@jcp.org.

This is my favorite feature of EJB 3.1 (well in close competition with timers, and asynchronous beans).

It takes a lot of frustration of EJB away. I can't wait to use it.


Posted by Anders on September 22, 2008 at 03:44 AM EDT #

That's great to hear Anders. Thanks for the feedback. BTW, you can try the no-interface view out right now on top of Glassfish V3 TP2. Details are here : http://blogs.sun.com/MaheshKannan/entry/ejb_3_1_in_glassfish

Posted by Ken Saks on September 22, 2008 at 07:23 AM EDT #

Nice :) What if you want to expose certain methods as local services and other as remote ? I am thinking something like:

public class HelloBean {
public String helloAll() { return "hello all"; }

public String helloLocal() { return "hello"; }


Meaning helloAll are available remotely but helloLocal are only available localy.


Posted by Phillip Kruger on April 07, 2009 at 07:49 AM EDT #

Hi Phillip,

Thanks for the feedback. It's already possible to selectively expose certain bean methods through a local
interface and not through a remote interface (and vice versa). We discussed whether to make that
possible for no-interface view methods, but the Expert Group felt it wasn't worth it given the additional
complexity of new metadata we would need to define. Exposing only a single client view is still the most
common case so it's unlikely to be a significant limitation, but it's an issue we can always address in
the next spec if it turns out otherwise.


Posted by Ken Saks on April 08, 2009 at 01:35 AM EDT #

[Trackback] EJB 3.1 (JSR 318) and Servlet 3.0 (JSR 315) are the two new JSRs in Java EE 6 (JSR 316). The EJB 3.1 specification provides multiple new features such as WAR packaging, Optional Local Business Interfaces, EJB.lite, Portable Global...

Posted by Arun Gupta's Blog on May 19, 2009 at 07:01 AM EDT #

Hi Ken.
I'm Brazilian...
Sorry if my question is simple or stranger but I would like understand the communication between layers web and EJB 3.1 when I write bean class without interface as "non-interface view"..
Is correct to affirm that this way there is less overhead of network by not use the RMI procotol, only the local access in the EJB class? If I'm wrong.. Might you help me?

Posted by Patrícia Pedroso on May 19, 2009 at 03:23 PM EDT #

Hi Patricia,

Yes, the no-interface client view, as well as the Local interface client view, both avoid much of the overhead associated with the Remote client view. The benefit of the Remote client view is that it provides location transparency. That means the deployer has much more flexibility in deciding where to physically deploy the client in relation to the target bean.

In the Local case, for both no-interface and Local interface, there is no network call or argument copying required for the invocation, but the tradeoff is that the client and the target bean must be packaged in the same application. As such, the Local view is a better fit for more tightly coupled, finer-grained, components.

Posted by Ken Saks on May 20, 2009 at 02:33 AM EDT #

[Trackback] EJB 3.1 (JSR 318) and Servlet 3.0 (JSR 315) are the two new JSRs in Java EE 6 (JSR 316). The EJB 3.1 specification provides multiple new features such as WAR packaging, Optional Local Business Interfaces, EJB.lite, Portable Global...

Posted by Arun Gupta's Blog on May 20, 2009 at 02:16 PM EDT #

it is greate.

Posted by jiaqiang on July 01, 2009 at 12:10 AM EDT #

Support of the Lou Zhu, Lou Zhu worked hard
Nothing is impossible for a willing heart
<a href="http://www.uggshelf.com/Products.html">ugg Boots</a>

Posted by hanyujoys on October 14, 2009 at 04:29 PM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Ken Saks is the Spec Lead for Enterprise JavaBeans (EJB) 3.1 and a Senior Staff Engineer in the Java Platform, Enterprise Edition team at SUN.


« March 2015