 | Level: Intermediate Brett McLaughlin (brett@newInstance.com), Author and Editor, O'Reilly Media Inc.
01 Oct 2002 One of the most complex issues in application planning is the necessary separation between business and implementation tiers. To accomplish this separation, Brett McLaughlin builds on the Business Interface pattern with a class to handle the abstraction of Web tier from business logic. The Business Delegate pattern can help you avoid the coupling that can make your applications hard to maintain and upgrade.
If you've been following this series from the beginning, you'll know that one of our recurring concerns is the separation of application and presentation logic from business logic. In the first tip, for example, we focused on the difficulties of remote object design, specifically when it comes to separating a bean's implementation from its interface. We resolved that difficulty with the Business Interface pattern, which we'll be working with again in this article. The last tip addressed the conflicting needs to protect entity beans from direct exposure to the application layer, while simultaneously enabling user access to the data contained within those beans. In both cases, the core problem was resolved by carefully abstracting the business logic implementation from the code that used that logic. As this tip will show, that kind of abstraction is one of the foundations of good application design, particularly EJB-based application design. Here, we'll once again work with both the Business Interface pattern and session beans to keep your Web tier loosely coupled with your Enterprise JavaBeans components. If you haven't read the previous tips in this series, you may want to read them before you go on. In particular, you will need to be familiar with our previous implementation of the Business Interface pattern to follow the examples here. The Business Interface pattern
Our previous implementation of the Business Interface pattern allowed us to provide a business-specific interface for interacting with session beans. Listing 1 shows that interface, which we'll use again in this tip:
Listing 1. A business-specific 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...
}
|
Note that the Library interface doesn't contain any EJB semantics. Rather, all the implementation and EJB details are handled within the session beans that implement the interface. Now, let's look at how the Web tier of an enterprise application might access the Library interface and the session beans that back it:
Listing 2. Access the Library interface
LibraryHome libraryHome =
(LibraryHome)EJBHomeFactory.getInstance().
lookup("java:comp/env/ejb/LibraryHome",
LibraryHome.class);
ILibrary library = libraryHome.create();
|
Listing 2 uses another class that will be familiar to you if you've been following this series from the beginning. The EJBHomeFactory class further separates business and application logic by looking up the
home interface for the Library bean. An implementation of the Library interface can then be obtained from the home interface. The above code isn't bad -- it's certainly an improvement over loading the JNDI initial context, getting the home interface manually, and then dealing directly with an entity bean. But it does contain one fundamental weakness: the Web tier is still tied to EJB components, and in particular the Library session bean (rather than just the business interface). What will happen to your application code when you need to phase out entity beans and start using Java Data Objects, or incorporate a new version of the EJB specification? What will happen when, inevitably, you decide you like the architecture of a cleanly separated system better? While it's easier in the short run to write tightly coupled code (that is, code that introduces implementation semantics into your business layer), doing so almost inevitably decreases the lifespan of your application. And that's where the Business Delegate pattern comes in.
Get a go-between: The Business Delegate pattern
First off, the Business Delegate pattern is different from the Business Interface pattern. Whereas the Business Interface pattern defines the business logic available for use, the Business Delegate provides access to that logic without causing a dependency on its implementation technology (in this case EJB components). Specifically, a business delegate is a helper class that handles the details of connecting to an EJB container, obtaining any required resources, and releasing those resources as needed. Listing 3 uses the Library interface from Listing 1 as its starting point, but note the introduction of the new LibraryDelegate class and methods.
Listing 3. The LibraryDelegate class and methods
package com.ibm.library;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.naming.NamingException;
public class LibraryDelegate implements ILibrary {
private ILibrary library;
public LibraryDelegate() {
init();
}
public void init() {
// Look up and obtain our session bean
try {
LibraryHome libraryHome =
(LibraryHome)EJBHomeFactory.getInstance().lookup(
"java:comp/env/ejb/LibraryHome", LibraryHome.class);
library = libraryHome.create();
} catch (NamingException e) {
throw new RuntimeException(e);
} catch (CreateException e) {
throw new RuntimeException(e);
} catch (RemoteException e) {
throw new RuntimeException(e);
}
}
public List getBooks() throws ApplicationException {
try {
return library.getBooks();
} catch (RemoteException e) {
throw new ApplicationException(e);
}
}
public List getBooks(String category) throws ApplicationException {
try {
return library.getBooks(category);
} catch (RemoteException e) {
throw new ApplicationException(e);
}
}
public Book getBook(String isbn)
throws NoSuchBookException, ApplicationException {
try {
return library.getBook(isbn);
} catch (RemoteException e) {
throw new ApplicationException(e);
}
}
public boolean checkout(Book book) throws ApplicationException {
try {
return library.checkout(book);
} catch (RemoteException e) {
throw new ApplicationException(e);
}
}
public boolean checkout(List books) throws ApplicationException {
try {
return library.checkout(books);
} catch (RemoteException e) {
throw new ApplicationException(e);
}
}
// And so on...
public void destroy() {
// In this case, do nothing
}
}
|
In the LibraryDelegate class, each method responds to an operation request by passing it on to the session bean. The init() method handles initialization and resource gathering; the destroy() method handles resource release. For all its simplicity, LibraryDelegate still has quite an impact on the way the overall application works. Note the differences between Listing 2 and the code fragment below:
ILibrary library = new LibraryDelegate();
|
By introducing the LibraryDelegate, you've removed all technology dependencies from the application's Web tier. Not only does this result in cleaner, more sound application code, but it positions your application to more smoothly incorporate change over its lifespan. For example, if you ever needed to migrate from
using EJB technology to pure JDBC classes, you would simply rewrite your business delegate with the new JDBC classes. Your
Web tier would never know the difference or need to be recompiled. In the next installment, we'll expand on our use of the Business Delegate pattern, making it even more generic. The result will be better code and less dependency on EJB technology.
Resources
About the author | 
| | Brett McLaughlin has been working in computers since the Logo days (remember the little triangle?). He currently specializes in building application infrastructure using Java and Java-related technologies. He has spent the last several years implementing these infrastructures at Nextel Communications and Allegiance Telecom, Inc. Brett is one of the co-founders of the Java Apache project, Turbine, which builds a reusable component architecture for Web application development using Java servlets. He is also a contributor of the EJBoss project, an open source EJB application server, and Cocoon, an open source XML Web-publishing engine. Contact Brett at brett@oreilly.com. |
Rate this page
| |
