 | Level: Intermediate Brett McLaughlin (brett@oreilly.com), Author and Editor, O'Reilly & Associates
01 Aug 2002 In this new series, you'll learn how best to design and optimize your Enterprise JavaBeans components, how to reduce RMI traffic and JNDI access, and generally get the most out of your enterprise applications. In each tip, Brett McLaughlin, a leading authority on enterprise Java programming, will present a best practice or design pattern. Many tips will build upon what has come before. It's recommended that you work through the tips sequentially, as they will help you build up strategies and design methodologies that will help you in your own enterprise application programming. In this first tip, Brett shows how the Business Interface pattern can improve your remote object design.
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. |
Warning: Don't use this pattern with entity beans!
The Business Interface pattern applies to session beans and message-driven beans only; the pattern doesn't apply to entity beans, which should never be directly exposed to the application layer. In fact, the Business Interface pattern breaks down in EJB 2.0 entity beans, because the classes are declared as abstract and therefore can't be checked.
|
|
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.
Listing 1. The Library business interface
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.
Listing 2. Completing the Library 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.
- Read all of the tips in the EJB best practices series.
- 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 page
| |
