Business Interface


J2EE patterns: Business Interface

  1. Business Interface (11 messages)

    The EJB spec forces the bean class to provide an implementation for all methods declared in the remote interface. The spec also recommends against the bean class directly implementing the remote interface using the "implements" Java keyword. The EJB compiler will find any inconsistencies between the remote interface and the bean implementation.

    Many of the errors uncovered by the EJB compilation involve methods declared in the remote interface that aren't declared correctly in the bean class. This could be caught in the first compilation step if the bean class were able to implement the remote interface directly. Then the Java compiler could use the standard rules for enforcing the implementation of an interface.

    This problem is solved by creating a Business Interface. Both the remote interface and the bean class implements the Business Interface.

    The Business Interface is defined just like the bean's normal remote interface—only it doesn't extend javax.ejb.EJBObject. The business interface declares all the methods you can call on the business object, but doesn't make any assumptions about the underlying implementation. This leaves you free to build a client that interacts with the business interface rather than the remote interface. You could be working with the remote bean, a serializable "state" object, or something in between. It doesn't matter to the client as long as the interface remains the same.

    Example implementation:>

    // Define a business interface with one method
    public interface BusinessInterface {
       public void doBusinessLogic();

    // Let the remote interface extend the business interface
    public interface EJBRemoteInterface extends EJBObject, BusinessInterface {

    // Let the bean class extend the business interface
    public class EJBBean implements SessionBean, BusinessInterface {

       public void ejbCreate() {

       // Implement the business logic
       public void doBusinessLogic() {


    The Business Interface pattern was originally written by Jeff Gallimore in
    this article.

    Threaded Messages (11)

  2. Business Interface[ Go to top ]

    One step further is to have a implementation bean which implements the BusinessInterface, and then is extended by the actual EJB:

    public class BusinessImplementation implements BusinessInterface {

        public doSomething() {}

    public class EJBBean extends BusinessImplementation implements SessionBean {
        public ejbCreate() {}

    This also splits the EJB container-oriented code (ejbCreate etc) from the business logic.

    By adding a factory for creating the bean (and making BusinessImplementation package local), the client will only use the BusinessInterface and the factory. This makes it transparent to the client whether the bean is local or remote, and thereby adds flexibility to the system:

    public class BusinessFactory {
       public BusinessInterface getBusiness() {

    In some applications parts of the functionality (ie. search pages) does not need support for transactions, security etc, performance more important. By using BusinessInterface and a factory is it still possible to keep a consistent design throughout the hole application, as well as change from local to remote objects without changing the client.

    For development it is also often easier testing a java-bean than an EJB.



  3. Business Interface[ Go to top ]

    There is also a short discussion on this pattern here:

  4. Business Interface[ Go to top ]

    Just FYI, there's an expert group in the JCP working on developing a spec for implementation of a Business rules engine to the j2EE. The idea being that business logic could reside outside of the system of Entity and Session beans, and conditionally call beans to manipulate data based on requests. Wouldn't it be great if someday programming business logic was as simple as developing the algorithm in the format of interrelationships between objects and changes in state, then having that behavior implemented via interpretation of those rules in real time, rather than codifying business algorithms into the system itself?
  5. Business Interface[ Go to top ]

    There is a problem with the approach of having an implementation bean. That makes it impossible to have a generic bean super class for handling issues like a SessionContext.

    public BaseSessionBean implements SessionBean
      private SessionContext context;

      public void ejbPassivate(){}
      public void ejbRemove(){}
      public void setSessionContext(SessionContext ctx)
        context = ctx;

  6. Business Interface[ Go to top ]

    It seems as if the EJB 1.1 spec may cause problems for this pattern. See this discussion thread for a full description of the problem.
  7. Business Interface[ Go to top ]

    In a bean all the business methods defined in a Remote interface have to throw a RemoteException. But when these methods are defined in the bean they, many times, do not throw this exception. So if this creates different signatures how does the EJBOjbect know the correct method to call? Are exceptions not part of the signature?
  8. Business Interface[ Go to top ]

    Exceptions are not part of the signature, ie. you can have a interface containing the method:

    public void someMethod() throws SomeException {

  9. Business Interface[ Go to top ]

    Sorry about the posting above...


    Exceptions are not part of the signature, ie. you can have a interface containing the method:

    public interface SomeInterface{
      public void someMethod() throws SomeException;
    And a implementing class:

    public class SomeClass implements SomeInterface {
      public void someMethod() {
        // do something

    BUT: the implementing class cannot declare more exceptions than the interface.

  10. Business Interface[ Go to top ]

    I'm somewhat new to EJB and I was wondering why/how the following is possible:

    // Let the remote interface extend the business interface
    public interface EJBRemoteInterface extends EJBObject, BusinessInterface {

    I thought you weren't allowed to directly inherit from more that one superclass in java. Can anyone clarify this for me?
  11. Business Interface[ Go to top ]

    interface X extends Y, Z {}

    class A extends B implements Y, Z {}

    These are allowed because multiple inheritence interfaces is legal in Java while multiple inheritence of classes are not.

  12. Business Interface[ Go to top ]

    Good approach for dealing with remote/local objects.
    BUT, how do you guys would deal with the problem to call the EJBRemove (like in myObject.remove() ), as it is not found in the Business Object interface???
    One could say: well, call the remove from the Home Object instead, but would it really work? Even if you have a Object Factory approach (where the Bean extends an Impl class, and the factory is the one aware of which object to create, etc)?