If you've done much development of EJB components, you're well aware of the difficulties of remote object design. Core to distributing EJB components is the ability to separate a bean's implementation (represented by a Bean class) from its interface (represented by a remote or local interface). The interface is exposed to the client and is generally used in a different JVM from the actual implementation class. What this means is that the two rarely have a code-level reliance on each other; and that, in turn, means that it's possible to have methods in the interface that are not in the implementation, and vice versa. For example, utility methods on the implementation class don't have to exist on the remote interface.

None of this sounds unmanageable so far, but that will change when you realize that sometimes a mismatch in methods is unintentional. Take the all too common case where, upon deploying your beans, you realize you need a new method. You add the method to your bean implementation class, but then forget to add it to the remote interface. Now you've added the necessary functionality, but there's no way for remote users to actually access it. It's at this point that the Business Interface pattern steps in.

Note that the Business Interface pattern isn't the only way to get around mismatched methods in remote object design. Read the sidebar "Alternatives to the Business Interface pattern" to learn about other solutions.

The Business Interface pattern

First, you need to write an interface that defines all of your business methods. This will end up looking a lot like your remote interface, but without the EJB semantics. Listing 1 shows a simple business interface for a Library object.

package com.ibm.library;

import com.ibm.library.exceptions.NoSuchBookException;

import java.util.List;

public interface ILibrary {

     public List getBooks();
     public List getBooks(String category);

     public Book getBook(String isbn)
         throws NoSuchBookException;

     public boolean checkout(Book book);
     public boolean checkout(List books);

     // And so on...
}

The example is obviously pretty simple, but you get the idea. The business interface clearly defines the business usage of the Library object. To make the interface compatible with the EJB specification, you'll have to make just one EJB-specific concession: you'll have to ensure that each method can throw a java.rmi.RemoteException. Listing 2 shows the completed business interface.

package com.ibm.library;

import com.ibm.library.exceptions.NoSuchBookException;

import java.rmi.RemoteException;
import java.util.List;

public interface ILibrary {

     public List getBooks()
         throws RemoteException;
     public List getBooks(String category)
         throws RemoteException;

     public Book getBook(String isbn)
         throws NoSuchBookException,
                RemoteException;

     public boolean checkout(Book book)
         throws RemoteException;
     public boolean checkout(List books)
         throws RemoteException;

     // And so on...
}

With the EJB-compatible business interface in place, the next step is to extend it in your remote interface. Because all of your business methods are defined in the Library interface, you actually don't need to add any new methods to the remote interface. Listing 3 shows what the remote interface would look like if it were built using the Business Interface pattern.

package com.ibm.library;

import javax.ejb.EJBObject;

public interface Library extends ILibrary, EJBObject {
     // All business methods defined in the ILibrary interface
}

That's it. Already seems simpler, doesn't it? The next step is to code your local interface, which I'll leave as an exercise for you (just use the remote interface as your working example). As for the home interface (and local home interface, if necessary) you can code them just as you normally would; no changes to either of them.

Things do differ slightly in your implementation class, however. Normally, you would declare that this class implements the javax.ejb.SessionBean interface, or for message-driven beans, the javax.ejb.MessageDrivenBean interface. Under the Business Interface pattern, however, the implementation classes will also need to implement your new business interface (in this case, the ILibrary interface). Listing 4 shows the header of the implementation class for the Library bean implementation class; I've left out the remainder of the code for the sake of brevity.

package com.ibm.library;

import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
import javax.ejb.SessionBean;
import javax.naming.Context;
import javax.naming.InitialContext;

import com.ibm.library.exceptions.*;

public class LibraryBean implements SessionBean, ILibrary {

     // Implementation of EJB-specific methods

     // Implementation of remote interface methods

     // Utility methods, as needed
}

Again, this turns out to be a minor change to your normal processes. The difference is that, when you go to compile your bean implementation class, the compiler will now complain about any methods you've left out. By using the Business Interface pattern, you've set up a system where your business interface defines your business methods, your remote interface exposes them, and your bean class is responsible for implementing them. At the same time, you've avoided the problems of directly implementing your remote interface, and you no longer have the hassle of maintaining that remote interface on the same machine as your implementation class. You can also use remote and local interfaces (both extending the business interface) with this pattern. Furthermore, you've removed yourself from dependency on vendor-specific tools.

Hopefully, the Business Interface pattern will start to change the way you think about and code your session and message-driven beans. In the next tip, I'll continue looking at EJB design patterns and show you how using value objects in your EJB components can improve the performance of your application. Until then, I'll see you online.

Resources

• The official EJB home page at java.sun.com is a good resource for all things EJB.
  
  
  
  
• The Server Side offers lots of articles and information pertaining to J2EE.
  
  
  
  
• Paul Monday's "Java design patterns 201" tutorial (developerWorks, April 2002) offers an insight to design patterns in enterprise programming.
  
  
  
  
• The jGuru "EJB fundamentals" tutorial (developerWorks, March 2001) provides comprehensive introduction to Enterprise JavaBeans technology with particular attention to the role of EJBcomponents in distributed-computing scenarios, the architecture, the extension APIs, and the fundamentals of working with EJB technologies.
  
  
  
  
• Visit the developerWorks Java technology tutorials page for a listing of other free EJB technology- and J2EE-related tutorials.
  
  
  
  
• You'll find hundreds of articles about every aspect of Java programming in the developerWorks Java technology zone.
  
  

About the author

Brett McLaughlin is one of the leading authorities today on enterprise programming. He has designed, architected, and implemented enterprise solutions at Nextel Communications and Allegiance Telecom, Inc., and helped develop the Lutris Enhydra open source J2EE application server. He has written books on XML, Java, data binding, and enterprise applications, and is the author of over 50 articles on enterprise programming. Additionally, Brett is a committing member of every open source J2EE application server available today: JBoss, Enhydra, and OpenEJB. He is also the co-founder of the JDOM API for Java and XML, the Apache Turbine project, and is involved in numerous other open source projects. He currently writes and edits for O'Reilly & Associates, the world's leading technical publisher.

Rate this article

Comments

Back to top

Table of contents

• The Business Interface pattern
• Resources
• About the author
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Demo: Watch this demo and learn how to configure and use the WebSphere Application Server and the Eclipse IDE with the Web Tool Project Platform.
• Buy: WebSphere Application Server

Dig deeper into Java on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers