J2EE patterns were workarounds - but are still needed in Java EE 5 (Part 1: Business Delegate)

The purpose of the Business Delegate in the legacy EJB 2.X world :-), was the decoupling the presentation from the EJB-APIs. Business Delegate is a simple Java-Interface without any javax.ejb.* references in the signature. A simple class realizes the interface and talks with the remote interface and uses the home interface for the creation of the session facade.
A factory was often use to be able to replace different implementations easily.

We could argue, that Business Delegate is no more needed in the EJB 3 world. Reason: the Session Facade is already represented by an almost clean (we have still the Annotation @Remote and @Local) interface. Also "RemoteExceptions" are no more checked, and are wrapped in an unchecked exception.

The interesting question here is: who actually catches all the unchecked exceptions? These exceptions are still technology-polluted (javax.persistence.EntityExistsException, EntityNotFoundException,NonUniqueResultException, NoResultException, OptimisticLockException) - the client code (presentation) also need to deal with them.
The main difference between EJB 2.0 and EJB 3.0 is the fact, that now the exceptions are unchecked. The developer do not have to catch them, but they have to be in the classpath (otherwise ClassNotFoundException will occur). So we need still decoupling between the business, and the presentation. This task is perfectly suited for a Business Delegate. In this case his responsibility is the transformation of exceptions.

Business Delegate is also a perfect place for decoration (something like lean aspects). With dynamic proxy you could decorate the Business Delegate and provide e.g. some logging functionality (only few lines of code - no additional frameworks needed, works since JDK 1.3).

The concept of Business Delegate is still useful in the Java EE 5 world. Only the name could change (it is very common to invent a new name for the same technology or concept in our world).


Note that it also raises the point that remote services (Session Beans) should never throw technology-bound exceptions such as JPA ones.

One should implement his own hierarchy of exceptions and translate them accordingly, you wouldn't want to have to deploy the JPA and other JEE jars on the clients just to have the exception classes (ewww).

This is also why exception chaining is a very dangerous thing - at least, don't chain exceptions that are not in the JDK.

While chaining e.g. "java.lang.IllegalArgumentException" is fine, chaining "javax.persistence.EntityNotFoundException" would cause havoc on the client.

Posted by Pascal Bleser on October 25, 2006 at 03:00 PM CEST #

Can't you put the @Remote or @Local on the implementation class instead of on your interface?

Posted by Stefan Tilkov on October 25, 2006 at 07:28 PM CEST #

No. :-) But this is not the problem. The real problem are the exceptions.



Posted by Adam Bien on October 25, 2006 at 09:35 PM CEST #


absolutely. I hope I stated it clearly enough in this entry. If not please check out my entry about exceptions: http://www.adam-bien.com/roller/page/abien?entry=unchecked_exceptions_are_o_k

Posted by Adam Bien on October 25, 2006 at 09:39 PM CEST #

For exception handling purpose and to take care of all the unchecked exceptions-i am using Business Delegate in a JEE5 based application. Do i need to use Service locator or my session beans can be injected via DI into my Business delegate?

Posted by Ashu sharma on February 02, 2011 at 03:21 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments