What about a combined BusinessDelegate+ServiceLocator?


EJB design: What about a combined BusinessDelegate+ServiceLocator?

  1. Hi all,
    I've been reading the two J2EE patterns posted on the Sun site ...
    and http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html

    So, my question is, what's wrong in combining the above two patterns into one - a Singleton class which has all the Business methods built in?

    For instance, let's say I have a session facade which is a single point of entry into the EJB world. Now I build a BusinessDelegate which has a one to one mapping of the methods on the session facade. In addition to this, it also has the ServiceLocator functionality which will enable it to cache the EJBHome for the bean.

    Is there any drawback to this design? Is there any reason why you would want BusinessDelegates in the form of JavaBeans (and instantiated by the servlet clients) and a separate ServiceLocator (singleton which caches EJBHomes)?

    Thanks in advance.
  2. As the given URLs describe. The business delegate uses the ServiceLocator pattern. The above urls also describe how your session facade may also use ServiceLocator.

    Now chances are you won't have a single business delegate. I like to do a business delegate for each ejb facade in my application. Typically I'll find that each ejb facade wraps a set of high-level use-cases. For example, I'll have a facade for user administration that encapsulates my user administration use-cases. Another facade by be for a totally different set of use-cases ('like' functionality).

    Now while you could combine the above patterns into a single class, the clear separation of the two makes it easier for you to re-use the pattern elsewhere in your application while keeping the code/design simple and understandable. Plus, you probably wont want your delegate to be a singleton.

    Now if you know that you will only need one delegate and one facade then you may be able to get away with it.. but I would recommend making the separation in case you decide that you want to add additional delegates and facades - which may very well happen in the lifetime of your application.
  3. Thanks for your reply.

    >> I like to do a business delegate for each ejb facade in my application. <snip>

    Yes. This is what we are facing. We have one ejb facade & we are planning a single business delegate for that facade.

    >> Plus, you probably wont want your delegate to be a singleton.

    And this is what my query is about! What are the drawbacks if we choose to have a delegate as a singleton? Are there performance implications? Is it just the "separation of responsibilities" that is a cause of concern?

    Singleton's are known to be bottle-necks in terms of performance. But in Java, if we are using static methods in the business delegates, then we wouldn't have any issue would we? (Since it will be called by multiple threads anyway ...).

    Thanks in advace.
  4. OK... I was more concerned with separating the ServiceLocator and BusinessDelegate patterns. But as for implementing your BusinessDelegate as a Singleton with static methods as its public interface, I'm not sure if I can give a very strong argument against it.

    Basically.. the thing that you would have to most look out for is multi-threading issues. You would need to look at how many of your static methods would need to be synchronized, and would these synchronized methods make your Singleton look more like a Synchronized class. And depending on what you're doing, your static methods may also require some values to be declared final. So it probably just depends on your delegate, and what all is going on inside the class itself.

    But I think you have a good question.. maybe someone else has tried this and can comment.

  5. Thanks for your reply.

    Yes, if I needed to synchronize the static methods, there will definitely be performance issues. In this case, the BusinessDelegate is basically a passthru to the session bean facade. Except that it does a service (session bean) lookup via ServiceLocator(which caches the home stub).

    Any other ideas?