Business Interface

I think this was first described by Richard Monson-Haefel in his EJB book.

I'm not taking credit for this one, I just typed it in here. -- FrankSauer (Oct 20, 1999)

Problem

The enterprise bean implementation is not supposed to implement the bean's RemoteInterface directly, so that clients cannot by mistake bypass the container-generated EjbObject that wraps the BeanImplementation and does implement the RemoteInterface. Yet we would like to have some compile time confirmation that our implementation implements all of the business methods advertised in the RemoteInterface.

Solution

Create a Java interface containing only the business methods of the bean. Make the RemoteInterface extend this BusinessInterface and the BeanImplementation implement it.

Example

Possibly missing forces

This is so obviously the right thing I wonder why the ejb compilers don't enforce it. In fact, I wonder that so much that I almost suspect there's something wrong with the idea. Does anyone know what Sun's reason for not requiring this might be?

Without this, the local and remote parts of the bean are merely co-incidentally coupled. Why didn't the EJB spec authors think that was a bad enough thing to make BusinessInterface compulsory?

---

Something you should note about this pattern (mentioned in Richard Monson-Haefel's book):

For EJB 1.1, you should not declare RemoteException in the throws clause of the implementation of the remote methods. While this was required in EJB 1.0, EJB1.1 deprecated the habit of throwing RemoteException from the implementation of remote methods in favor of throwing EJBException. Fortunately Java does not require implementation methods to declare all of the exceptions thrown by an interface method, so we're ok here. Also, EJBException is derived from RuntimeException, so there is no need to declare it.

This should eliminate any concerns that the BusinessInterface pattern is incompatible with EJB1.1.

---

I'm confused. Isn't it required that the EJB methods be declared in the Remote interface to throw RemoteException? If so, then how do the methods declared in the Business Interface (which are NOT declared to throw RemoteException) become legal EJB methods? I'm surely missing something or operating under some false assumption.

---

Possible Mistake in this Pattern

by Javier Paniza

The primary goal of java interfaces is a plug-in point in a software system. If we make a class that implements a interface, we say that the class can be used in any place when the interface is required. If we build a system based on interfaces (see Code suggestions) the sessions beans (or other software pieces) work with any that implement this interface, including EJB Bean (�Ohh! Error).

It doesn't seem like a "mistake in the pattern" that it allows client code to work with either the generated EJB or a simpler implementation of the Business Interface. If anything, this seems nice because it (conceivably) allows client code not to know that it's using EJBs. This assumes that there's no defense for the statement below starting with "Huh?" If someone can supply a defense, please do so and delete this paragraph! :-)

---

Huh? Using this pattern, nobody should ever try to reference an object with a direct type of the BusinessInterface. Instead of passing around WhateverBusiness interfaces, we should always pass around Whatever interfaces - the remote interface which also extends EJBObject. This is probably a good reason why the business interface name should have a long and uncomfortable-to-type string like "Business" appended to it :-)

---

Why shouldn't they reference objects with a direct type of BusinessInterface? It seems to me that this pattern could be used as insulation against the technology if it wasn't for that rule. -- RobertWatkins Could someone please AnswerMe?

---

Can I use Business Interface to specify the Framework of my business model? --SeshKumar

Unless you provide some explanation of what you mean by "Framework," this will probably not ever get answered.

---

I dont understand why people are bothered about this pattern, this is basically to find the mismatches between methods in the remote interface and the implementation, which is a one time job. This pattern worked well with EJB1.1 but will not work with EJB2.0. Because the local interfaces cannot throw remote exceptions.

Could you say something about WHY this pattern will not work with EJB 2.0 (if that is in fact the case)? It would sure make this page more useful.

---

This pattern relies on the fact that Java supports multiple inheritance for interfaces. The remote interface extends the Business Interface AND EJBObject; the business interface doesn't extend EJBObject. Like this:

 public interface Account // business interface
 {
  public int getBalance() throws RemoteException ;
 }

 public interface RemoteAccount extends Account, EJBObject // remote interface
 {
 }

 public class AccountBean implements RemoteAccount, EntityBean
 {
  public int getBalance()
  {
   // implementation here
  }
  // other method implementations here
 }

There is a variant on this which factors out some of the innards into an AccountValue class which implements Account (but not RemoteAccount), with AccountBean then extending AccountValue. The AccountValue is handy in that it can then be used as a value object for transferring all (or some) of the account's state in one go.

---

CategoryBusiness CategoryInterface