Need to know the Design Pattern for this problem


EJB design: Need to know the Design Pattern for this problem

  1. We have developed 4 Session Beans for one of our application. Each bean is a module by itself with several business methods. Now from the client side we are connecting directly to this beans. We want to streamline this with a workflow Bean. How do I do that. The problem is all this bean have different methods with different signature and how can I write a Session bean to call all this method based on the client request.
    Please reply with some example.

  2. There is something called DynamicProxy introduced in Java 1.3. You might want to check it out! Might help you.

  3. If I understand you correctly, instead of your client making calls to each of your session beans, you want to call another session bean and let that bean orchestrate the sequence of calls to the original session bean. (If this is not right, please clarify your question.)

    Based on the above assumption, I would say that you can divide each of your workflow sequences *functionally*. For instance, if you need to call EJB1 to perform Action1 and then call EJB2 to perform some other Action2, then have a business method on your gatekeeper EJB which first calls EJB1 & then EJB2. Thus for each of your business cases, you can have methods on this gatekeeper EJB.

    This is usually referred to as the Facade pattern. You hide all the various EJB relationships from the client and let the client talk to only one EJB which performs the required actions (as opposed to the client knowing about each EJB and controlling the sequences.)
  4. Your assumption is correct. I even heard about the facade pattern. How does this facade bean know which bean to invoke based on the client request. Let us say our EJB1 have 4 methods with different signature. EJB2 has 5 methods with different signature. How do we manage this. Let us say client want to invoke a method2 in EJB2 how does the facade will recognize this.
    Do you have any examples.

    Thanks for your reply.
  5. Basically, we have to convey our intent to the facade EJB in some way. One way of doing it is to divide these sequence variations *functionally*. What I mean is, determine what the business case is being satisfied when the client needs to call method1 of EJB1 and then method2 of EJB2. Say your business case is to get all Employees satisfying some condition and then update their status to say "ACTIVE" (this may well be nonsensical, but bear with me for this example ;-)).

    EJB1.getAllEmployees(Status inactiveOnly)
    EJB2.setActiveStatus(EmployeeCollection ec)

    So, I could decide that my Facade has a method called

    One disadvantage of this formula is that depending on the number of variations that can happen you could wind up with a lot of methods on the facade. If so, another option is to make you facade smart.

    For instance, you could have the method
    FacadeEJB.setEmployeeStatus(Status fromStatus, Status toStatus);
    Now, the FacadeEJB can evaluate the individual parameters and make a decision based on the input parameters as to which EJB1 & EJB2 methods to call.
    For instance,
    EJB1.getAllEmployees(fromStatus) may have
    if (fromStatus.getStatus() == Status.INACTIVE){
       EmployeeCollection ec = EJB1.getInactiveEmployees();
       if (toStatus.getStatus() == Status.ACTIVE){

    Hope you get the idea.

    Essentially you have moved your business logic from the client to the facade.
  6. Das,

    Fantastic, I think I am on the same track with you. But one thing which bother me is we have to hardcode the events right. Well we have to compromise somewhere. Is there anyway we can route the calls coming from the client to the relevant EJB using a Facade.

    In my scenario we have several jsp client calling different EJBs directly from webtier. I want to have a facade in the EJB Container which will accept all the calls from the client (jsp) and call the relevant EJB and send back the information.

    Thanks for your response, it is really interesting.
  7. I think you should check out the J2EE Blueprints for some commonly used patterns. See

    A commonly used pattern is the Model View Controller. In terms of your app, the JSP is your view, a Servlet (which is called when a user clicks a link on your webpage) is the Controller and the EJBs are like the Model. The flow is usually: servlet collects info from EJBS; servlets pass retrieved data to JSPs. JSPs do the rendering of data into webpages. JSPs should do minimal business logic. Wherever possible move business logic into a bean/plain java class.

    Check out the J2EE patterns. It's informative.
  8. Also see this one:

  9. Yes we do use MVC and it was just an example which I quouted(using JSP as the client). Thanks for all the response.