J2EE patterns were workarounds - but are still needed in Java EE 5 (Part 1: Business Delegate) 📎
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).