Get down to business

Achieve implementation transparency for your business objects with the Business Object Factory framework

By James Carman, JavaWorld.com, 07/18/03

Many architects strive to reduce coupling between the presentation tier and the business logic tier in multitier applications. The Business Delegate design pattern (in Sun Microsystems' Core Java 2 Platform, Enterprise Edition (J2EE) Patterns Catalog) was created to solve this problem. But, many critics claim it is an unnecessary added layer of abstraction for achieving this simple goal. Most argue that the business delegate's interface mimics the business logic interface so closely that any change to the business logic interface also mandates a change to the business delegate's interface. In most cases, this is true. However, the Business Delegate pattern has other benefits such as remoteness hiding, failure recovery, thread synchronization, and caching. But many applications that use the Business Delegate pattern do not take advantage of these additional benefits. Thus, the pattern's overhead seems to outweigh its merits. For these applications, all that is desired is an abstraction layer that hides the underlying implementation details, such as the familiar lookup and narrow operations required for Enterprise JavaBeans (EJB) implementations. This article takes you through the API, configuration, and implementation of one such framework, the Business Object Factory framework.

Note: You can download this article's source code from Resources.

The API

The Business Object Factory framework's simplest part is the API itself. There is only one major class, but a few other "behind-the-scenes" classes can extend and customize the framework.

The BusinessObjectFactory class

Apart from the business interfaces used in their applications, consumers of business objects' services need only concern themselves with one primary class, BusinessObjectFactory. Let's look at its public interface:

public final class BusinessObjectFactory
{
  public BusinessObjectFactory getInstace();
  public Remote create( Class businessInterface );
}

As you can see, the BusinessObjectFactory class implements the Singleton design pattern (a Gang of Four design pattern). The BusinessObjectFactory's constructor is declared as private, and the class only maintains one static instance. This provides one global point of access to the functionality BusinessObjectFactory provides. We could just as easily make all of the methods static, but that approach is more object-oriented.

The create() method tends to raise a few eyebrows. First, it returns an instance of java.rmi.Remote. Most business object implementation choices, namely Remote Method Invocation (RMI), EJB, and the Java API for XML-based Remote Procedure Calls (JAX-RPC), require a remote interface. For simple JavaBean-based business object implementations, this adds the inconvenience of requiring the client code to catch java.rmi.RemoteException when it will never be thrown. However, this inconvenience helps provide the implementation transparency, as the business objects can be migrated to a different implementation type without altering the client code. The only stipulation is that the remote interface does not change. Another create() method peculiarity is its parameter type, java.lang.Class, which corresponds to the remote interface type requested. This allows the BusinessObjectFactory class to be loosely coupled with the application using it. This does not prevent company XYZ from creating an adapter class to simplify client programming:

Archived Discussions (Read only)

Subject

Forum migration complete By Athen

Forum migration update By Athen

Configuration file Schema By Katari

Singleton By Juan Casares

Interesting, but very tilted towards EJB usage By Eric Pugh

Oops... By James Carman