Discussions

EJB design: Design pattern for calling remote/local EJB dynamically

Bookmark and Share Get thread feed

  1. Design pattern for calling remote/local EJB dynamically (4 messages)

    Hi All,

    In my application I'm planning to make client tier dynamically find whether the EJB to be called is local or remote and accordingly call the local or remote interface.

    To achieve this, the client tier will read the home class string for the ejb to be called from a properties file. Based on the actual location of the EJB relative to the client tier, the home class name passed can be either of remote home type (say AccountHome) or local home type (say AccountLocalHome). The actual bean class will contain a set of business methods which will be exposed through both remote interface (say Account) and local interface (say AccountLocal).

    However, I'm facing the problem in writing an optimised code for calling either remote interface or local interface dynamically.
    It seems that, in the client tier I need to have if/else for each business methods of EJB, based on whether the EJB is local or remote. This will make the code clumsy and duplication of same application specific logic in two places.

    Is anyone aware of any design pattern (or any solution) to make the code more cleaner and modular for this situation ?

    Any idea/pointer will be really appreciated.

    Thanks in advance.

    Regards,
    Sourav
    Reply to this

    Threaded Messages (4)

  2. Use Business delegate + Service Locator.[ Go to top ]

    Sourav,
      In my opinion, you may use a Business Delegate with a Service Locator.

    Here is how it can be implemented:
    1. The Client (or the Actor) always calls the Business Delegate (core java class), the client never calls the EJB directly. The business delegate would encapsulate the logics for delegating the call to the EJBs.
    2. The Business Delegate only delegates the call to the EJB, it does not lookup the EJB's itself. In your case the Business Delegate can decide which EJB is to be invoked is remote / local. The Business Delegate would use a Service Locator (core Java class) to looup the EJB. THe Business Delegate can also initiate transactions if the EJB methods being invoked require the client call to be associated in a XA (Transaction) Context.
    3. The Service locator can be a singleton to encapsulate the JNDI/Initial Context operations.


    Consequences:
    1. Encapsulates the client code in the client and need not pollute it with the EJB invocation decisions, lookups, handling Remote Exception etc.
    2. The Business Delegate encapsulates the EJB invocations/decisions on whether to use remote/local interfaces, hence is reusable at times when differnt client need to delegate calls to EJBs (from within the EJB tier/Client tier/Web tier etc).
    3. The Service Locator being a Singleton can optimize the JNDI service lookups and eliminates the repeated/redundant codes for JNDI lookup.

    Pointer to the patterns:
    http://java.sun.com/blueprints/patterns/BusinessDelegate.html
    http://java.sun.com/blueprints/patterns/ServiceLocator.html

    I hope this answers your question, Good luck.

    Regards,
    Shafique Razzaque,
    Singapore.
    Reply to this Reply to original

  3. Design pattern for calling remote/local EJB dynamically[ Go to top ]

    yes using bisiness delegate with service locator will be the real good option
    Reply to this Reply to original

  4. GOF Strategy[ Go to top ]

    You could have a RemoteCall strategy and a LocalCall strategy and choose one or the other once during the initialization. A Business Delegate will neither hide away the decisions nor eliminate the runtime cost to make them.
    Reply to this Reply to original

  5. Design pattern for calling remote/local EJB dynamically[ Go to top ]

    Hi,

    IMHO it is not be necessary to distinguish between local and remote interface calls: the ejb container should be intelligent enough to detect that a bean is local - and will make a local call, even if there only exists a remote interface to that bean.

    So why do you actually want to have two different interfaces at all?

    GreetinX,

    René
    Reply to this Reply to original