Service Locator Pattern... again


EJB design: Service Locator Pattern... again

  1. Service Locator Pattern... again (2 messages)

    Hi, I have posted yesterday a question about the SL Pattern.
    François answered me to see a post he wrote some days ago: "Reusable Service Locator Component"
    Here he suggests me to use a SessionBean for my SL. The implementations of SL I have seen so far are a singleton living on web tier. Is this a bad approach?

    How do you keep a reference to a statefull SB? In the web user session?


    Nicolas Dobler
  2. i'd say have a reference to a SFSB in the web context so then you only have one instance per web app but dont forget to remove it when the web context is shut down
  3. Both appraoch are good...[ Go to top ]

    but the idea behind the Session Bean implementation is to make the SL reusable. Indeed, when you add a new EJB in your app, you just have to add an environment entry in the SL Session Bean to make it available to all the component of your app (both web tier and ejb tier). No code change at all!
    In the web.xml, you only need one EJB reference:
    <!-- ### EJB References (java:comp/env/ejb) -->

    On the ejb-jar.xml, you just have to define one ejb-ref per bean:
            <ejb-ref >
    But you declare a reference to every bean in the ServiceLocator section.

    Using the Singleton is not a worse or better appraoch. But you have more work to manage the deployment descriptor. On the other hand, the Singleton might be more performant (no remote call the a SL Session Bean). I did not test.

    You can not cach a reference to a Statefull Session bean, because the Statefull SB maintains a conversational state with the client. Caching it means that client B might end using the same EJB than client A, with both the same conversational state. Imagine that this is the state of a shopping cart...