EJB best practices: Improve your remote object design

Return to article

The Business Interface pattern isn't the only way to get around mismatched methods in remote object design. One common solution is to use vendor tools for error checking at deployment time; another is to have your implementation class implement the remote interface.

The vendor solution

While vendor tools can perform effective error checking, you're making several assumptions when you rely on them:

1. The vendor tool will catch your errors (even the sneaky ones).
2. You won't change vendors, and thus lose the ability you've come to rely on.
3. You (the developer) will handle both implementation class generation and development.
4. You don't mind catching errors after you've compiled your hard-written code.

As it turns out, the third and fourth items here are often false. Deployment is generally left up to administrators, not developers, and most of us find it's a real pain to get everything working and jarred up and then find an error. These basic flaws rule out the vendor solution for many developers.

The programmatic solution

Having your implementation class implement the remote interface will give you more control over the results, but the benefits are often outweighed by the work involved. In EJB 2.0, your implementation class will have to implement both the normal EJB interface (javax.ejb.EntityBean, javax.ejb.SessionBean, or javax.ejb.MessageDrivenBean) and your remote interface (for example, com.ibm.ejb.User). Of course, for any of this to work, your remote interface will also have to extend javax.ejb.EJBObject, which means you'll have to contend with all those methods, too. If that's not enough, here are two more big problems that could prove to be your undoing:

1. You'll have to provide dummy implementations of all the non-business-specific methods from javax.ejb.EJBObject in your implementation class.
   
   
2. If you're providing both a remote and local interface, you'll only be able to have your implementation class implement one, leaving the other interface prone to errors.

Return to article