Session EJB acting as delegate

Discussions

EJB design: Session EJB acting as delegate

  1. Session EJB acting as delegate (3 messages)

    Hello,

    We are using struts framework where for every screen we have a form bean, which calls action class, which inturn calls session ejb(stateless). The business logic is in session ejb which use DAO to interact with database.
    Now the problem is, that in current scenerio, we will end-up having 100+ screens and thus 100+ session ejb, which may create performance problem later. Pls suggest.

    Also, can we modify the current framework to look like something.....that we build few session ejbs(categorized based on modules), which will have methods for their related screens, which will inturn invoke a normal java class (with business logic) and this java class will call DAO to interact with database. Pls note that every call to ejb will require TRANSACTION.
    Pls suggest the pros and cons of this approach or is there a better way to deal with such scenerio?

    Regards,
    Jaiom Rana

    Threaded Messages (3)

  2. session facade[ Go to top ]

    I think you should have a Business deligate and a Session Facade. For more information plz visit sun website for design patterns.
  3. Session EJB acting as delegate[ Go to top ]

    There is an easy solution to your first question: unify your logic into fewer session beans. Based on your description, it sounds like your situation is this:

    SessionBean1: methodForScreen1
    SessionBean2: methodForScreen2
    etc.

    You can instead combine methods in single session beans:

    ComboSessionBean
    ----------------
    methodForScreen1
    methodForScreen2
    methodForScreen3
    etc.

    Now I don't recommend you put *all* of you methods in a single session bean. What you should do is organize your methods into logical groups, such as for related screens.

    As for putting your logic into Plain Old Java Objects (POJOs), the answer is yes as well. In fact, this is the classic command pattern. Define a common interface for all your business logic POJOs:

    public interface Command {
      public Object execute();
    }

    Your session bean can take the command as a parameter in its method:

    public class CommandBean implements SessionBean {
      public Object executeCommand(Command command) {
        return commmand.execute();
      }
    }

    You can then create subclasses of the command class with your screen-specific logic.

    public class Screen1Command {
      public void init(...) {
        // Take any parameters you need to perform the lookup or update
        // Store them in instance variables.
      }

      public Object execute() {
        // Perform the lookup or update
        // return the results
      }
    }

    In your client:

    Screen1Command cmd = new Screen1Command();
    cmd.init(...)
    CommandBeanRemote commandBean = // Lookup command session bean
    Object results = commandBean.executeCommand(cmd);

    The Pros:

    1. Only one session bean to write.
    2. Properly written command POJOs can be tested and used outside EJB container.

    The Cons:

    1. You loose the ability to declaritively configure transactions and security, since you only have one EJB method.
    2. You have to be extra careful to make sure you have the same version of the POJO commands in both the client and the EJB server.
  4. Session EJB acting as delegate[ Go to top ]

    I suggest using facade Session bean along with Command pattern. You should also look into grouping your business logic or the DAO into related groups/categories. it's not a good idea to have a 1-to-1 mapping between Structs action and EJB because.

    1. Maintenance headaches
    2. Your App server has to run many EJBs

    Struts action class can delegate to the appropriate Business Object via command pattern. In this setup, your business can be Session Bean or POJO (Plain ... Java object).