ServiceLocator Pattern: A History and Does EJB 3 Really Kill It Off?
Soon, ServiceLocator will be replaced by Dependency Injection (also known as Inversion of Control) type annotations in EJB 3. However, as these annotations won’t be available to helper classes like current JNDI lookups are, the ServiceLocator singleton might still be around even after EJB 3’s release, to the dislike of many Singleton haters.
There are some caveats to IoC in EJB3:
- They are not be available to non-ejb programmers or in helper classes
- Those who use Composite Entity patterns in their JEE architecture will not have JNDI look-ups available to them in their Dependent Objects and must aquire all their resources from the EJB itself.
- Those who use Session Facades and Business Delegate patterns for more than EJB lookups will have to continue to rely on JNDI lookups and ServiceLocator.
- The way IoC is implemented in EJB3 leaves a lot to be desired (not just POJOs with XML files like Spring)
- This means that those who prefer (or are mandated) to use light-weight web frameworks and code for small to medium web applications will be stuck with JNDI look-ups and ServiceLocator(s) for some time to come.
Therefore, this article seeks to help people who want an honest comparison between the two methods of operation, about where we got where we are today, and how migrating from JDK 1.4.2 to JDK 1.5 might change their ServiceLocator pattern to reflect Java 5 Generics, since ServiceLocator makes heavy use of Collections API to cache JNDI lookups for services.
Do to formatting issues in Internet Explorer regarding all the code samples I used, it’s best if you just read this article on JavaLobby instead: ServiceLocator Pattern: Does EJB 3 Really Kill It Off?.
