multiple EJBs - same remote interface

Discussions

EJB design: multiple EJBs - same remote interface

  1. multiple EJBs - same remote interface (7 messages)

    Can two different stateless session EJBs implement the same
    remote interface i.e. the exact same class?
  2. One of the basic concept in Interface Based programming is, you keep the interface the same and vary implementation. So it should be possible to provide different versions of the same component by keeping both the Component and Home interface the same and just changing Bean Class(implementation). This essentially boils down to Component Versioning. I don't know if there is a EJB standard for this. Component Versioning could be either container managed or bean managed. These are just my thoughts. All constructive comments welcome.

    Ganesh
  3. multiple EJBs - same remote interface[ Go to top ]

    We implement the Strategy pattern (GoF) for both changing the behaviour of an object at runtime and component versioning. That way you have a single interface, a single EJB and multiple strategies driving the EJB.
  4. Strategy pattern is applicable when only certain portion of the behavior varies. It also introduces a number of trade-offs. E.g. sometimes it is quite difficult to implement Strategy efficiently without breaking encapsulation. Moverover, if Strategy drives close to 100% of object behavior we are talking about facade and delegated responsibility here.
    On the other hand, having one interface and multiple implementation is a quite common approach. It is used widely in OO design and Java implementation. I don't see any reason whe it shouldn't be aplied to EJB development. After all, EJB is just a Java class controlled by the container and following the rules set by that container. Component versioning could be done using deployment descriptors.

    Andrei Filimonov
  5. "Strategy pattern is applicable when only certain portion of the behavior varies."
    Surely not.
     
    "Moverover, if Strategy drives close to 100% of object behavior we are talking about facade and delegated responsibility here."
    The applicability of a Strategy pattern is where "many related classes differ only in their behavior". When we talk about Strategy, we are talking about multiple strategy implementations. No one will implement a single strategy; it's not worth the effort. So, either no strategy can drive close to %100 of object behaviour or you don't have a single interface, multiple implementation situation.

    "On the other hand, having one interface and multiple implementation is a quite common approach. It is used widely in OO design and Java implementation."
    Obviously. The Strategy pattern is implemented as a single interface and multiple implementations.

    "I don't see any reason whe it shouldn't be aplied to EJB development."
    Readability and clarity are two good reasons for me. I would definitely go nuts while reviewing code like this:

     robj = ctx.lookup("ejb/Xone");
     XoneHome home = ...narrow(...,robj);
    ...
     InterfaceX x = home.create(width);

     robj = ctx.lookup("ejb/Xtwo");
     XtwoHome home = ...narrow(...,robj);
    ...
     InterfaceX x = home.create(numberOfLegs);

    "Component versioning could be done using deployment descriptors."
    How? By adding the version to the JNDI name?
  6. Strategy pattern is applicable when only certain portion >of the behavior varies."

    >Surely not.
      
    >"Moverover, if Strategy drives close to 100% of object >behavior we are talking about facade and delegated >responsibility here."
    >The applicability of a Strategy pattern is where "many >related classes differ only in their behavior".

    Well, I hate to say that but that is not GoF definition of Strategy pattern. You quoted "Strategy Pattern and J2EE". But in your previous message you specifically mentioned Strategy pattern (GoF).


    >When we talk about Strategy, we are talking about multiple >strategy implementations. No one will implement a single >strategy; it's not worth the effort. So, either no >strategy can drive close to %100 of object behaviour or >you don't have a single interface, multiple implementation >situation.

    What is your Strategy interface? Is it the same as remote interface? How is it different from delegation then? And who or what configures EJB with the right Strategy implementation?

    If it is different in what way it is different? Does it mean that EJB implementation does some processing and then calls strategy? In this case you have some common behavior for family of related classes. And their behavior is partially different in what is encapsulated by Strategy. By using different Strategy implementation you change this that particular portion of behavior. That what I originally meant.

    >"I don't see any reason whe it shouldn't be aplied to EJB >development."
    >Readability and clarity are two good reasons for me. I >would definitely go nuts while reviewing code like this:

    > robj = ctx.lookup("ejb/Xone");
    > XoneHome home = ...narrow(...,robj);
    >...
    > InterfaceX x = home.create(width);

    > robj = ctx.lookup("ejb/Xtwo");
    > XtwoHome home = ...narrow(...,robj);
    >...
    > InterfaceX x = home.create(numberOfLegs);

    I think what we were dicsussing is to have multiple implementation for the same remote interface. It is better to have the same home interface as well. In this case client has exactly the same view of different implementations. Differentiation is done through JNDI names. Or it may be one JNDI name with implementation that can be switched at the deployment time. Depends on what you are trying to achieve.

    As for you Strateg at what point you decide what Strategy implementation to use? What is the client view in this case.

    Also, it is possible to have one remote interface but different implementations and home interfaces. Theoretically at least. In practice it leads to really cumbersome design.


    >"Component versioning could be done using deployment >descriptors."
    >How? By adding the version to the JNDI name?

    By adding environment entry in the deployment descriptor.

    Andrei Filimonov
  7. I have copied and pasted that applicability statement from the GoF Design Patterns CD!

    You can defer an object's whole behaviour to a strategy instance (this could be done by Bridge instead of Strategy).

    You can defer partial behaviour to subclasses (GoF Template Function), or, you can encapsulate the partial behaviour in strategies and defer the behaviour to a strategy instance.

    The strategy interface can be the equivalent of the remote interface when the whole behaviour is deferred to strategies.

    When partial behaviour is deferred, the strategy inferface is not the equivalent of the remote interface.
  8. You can defer an object's whole behavior to a strategy >instance (this could be done by Bridge instead of >Strategy).


    Yes, you are right. But what would be the reason of doing that? The purpose of Bridge pattern is to decouple abstraction from its implementation. But EJB container already decouples remote interface from the implementation. Doing extra step by using Bridge will only introduce unnecessary design complexity.

    Strategy is a different story though. Structurally, Bridge and Strategy patterns are quite similar. The difference is in applicability. You use Strategy when:
    - object has to be configured by the *right* strategy at runtime
    - only part of the object behavior varies.

    When you delegate the whole object behavior to Strategy you essentially switching to the Bridge pattern. You still can call it Strategy but let's not argue about that:) I think, there is not a right answer written in stone. It depends on what you are trying to achieve.

    1. If it is to provide different implementation of the same remote interface and that implementation is static i.e. defined at the deployment time the best approach is to use multiple EJB implementations. Using Bridge would be unnecessary extra step

    2. If you want to implement different variants of behavior Strategy pattern is the right way to do it. What Strategy implementation to instantiate can be defined in the deployment descriptor. Variants in behavior can also be implemented using template. But in EJB deployment you will still have one remote interface and multiple implementing classes so it is just an extension to p.1.

    3. If you want to change variant of behavior or the whole behavior at runtime depending on some conditions Strategy pattern is the right approach.


    Andrei Filimonov