Skip to main content

If you don't have an IBM ID and password, register here.

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

EJB best practices: The Business Delegate pattern

Abstract business, presentation, and application logic in EJB designs

Brett McLaughlin, Author and Editor, O'Reilly Media Inc.
Photo of Brett McLaughlin
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.

Summary:  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.

View more content in this series

Date:  01 Oct 2002
Level:  Intermediate

Comments:  

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

Photo of Brett McLaughlin

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.

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in

If you don't have an IBM ID and password, register here.


Forgot your IBM ID?


Forgot your password?
Change your password


By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

(Must be between 3 – 31 characters.)


By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Java technology
ArticleID=10716
ArticleTitle=EJB best practices: The Business Delegate pattern
publish-date=10012002
author1-email=brett@newInstance.com
author1-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.

For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).