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)
The enterprise bean implementation is not supposed to implement the bean's
directly, so that clients cannot by mistake bypass the container-generated EjbObject
that wraps the BeanImplementation
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
Create a Java interface containing only the business methods of the bean. Make the RemoteInterface
extend this BusinessInterface
and the BeanImplementation
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
Something you should note about this pattern (mentioned in Richard Monson-Haefel's book):
For EJB 1.1, you should not
Exception 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 Remote
Exception 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 Runtime
Exception, 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 Remote
Exception? If so, then how do the methods declared in the Business Interface (which are NOT declared to throw Remote
Exception) 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?
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 Account
Value class which implements Account (but not Remote
Account), with Account
Bean then extending Account
Value. The Account
Value 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.