The Service Locator Pattern

The Service Locator pattern is put in place to provide a location-independent component that can hold onto the various services (classes, components, services, etc.) on behalf of a system and then return those components to a caller, based on some given ID. Most service locators are implemented as a sort of map, which uses textual strings to map a string ID to a component.

Let's walk through an example that utilizes the Service Locator pattern to provide a possible solution to the problem outlined in the last section. In order to avoid possible refactoring problems, I'll provide access to the ServiceLocator implementation through an interface, as defined in Listing 6.

Listing 6. The ServiceLocator interface

package servicelocator;

/**
 * This is the interface definition of the
 * ServiceLocator pattern.
 */
public interface ServiceLocator {
	Object locateService(String serviceName);
}

The one and only method exposed by this interface is locateService, which returns an object given its serviceName. Listing 7 provides a possible implementation for this interface. The class uses a java.util.HashMap object to store and retrieve the services. Notice that there are some additional public methods exposed by this implementation. These methods would be used by a bootstrap process to drop the components into the ServiceLocator object.

Listing 7. The ServiceLocatorImpl class definition

package servicelocator;

import java.util.HashMap;
import java.util.Map;

/**
 * This is the class implementation of the
 * ServiceLocator interface.
 */
public class ServiceLocatorImpl implements
  ServiceLocator {

  private Map services = new HashMap();

  private static ServiceLocator instance =
    new ServiceLocatorImpl();

  public static ServiceLocator getInstance() {
	return instance;
  }

  public Object locateService(String serviceName)
  {
	return services.get(serviceName);
  }

  public void addService(String svcName,
  	Object service) {

	services.put(svcName, service);
  }

  /**
   * Clears out all references to any services
   * presently held by the Service Locator.
   *
   */
  public void cleanup() {
	services.clear();
  }
}

Another observation you might make about this class is that it implements the Singleton pattern. Some might say that singletons are bad (especially in clustered web environments). I tend to agree with this, since I've seen some of the problems that can crop up from singleton implementations. If you insist on using singletons, you need to explicitly design for such challenges. Most IoC implementations avoid these problems by off-loading the creation and destruction of the container onto the calling code, and avoiding the Singleton pattern altogether.

The only thing left is to show how this class is used in an actual application. Listing 8 provides a ServiceLocatorTest client. Think of the main method as the bootstrap process and the performBusinessTask method as a method that will be called at some later point (perhaps within a business delegate implementation).

Listing 8. The ServiceLocatorTest class definition

package servicelocator;

import integrationtier.*;

/**
 * This class retrieves the service locator,
 * places some objects into it, and retrieves the
 * services for use.
 */
public class ServiceLocatorTest {

  public static void main(String[] args) {
	/*
	 * Initialize the service locator.
	 * We'll use the actual implementation to call
	 * methods that would need to ONLY be called
	 * when the service locator is initialized
	 * and only from the object initializing it.
	 */
	ServiceLocatorImpl sl = (ServiceLocatorImpl)
		ServiceLocatorImpl.getInstance();

	// We're going to use the Database DAO
	// implementation.
	DataAccessObject dbDao =
		new DbDataAccessObject();

	// Place the service in the ServiceLocator,
	// specifying the Database DAO as its DataStore
	// device.
	sl.addService("DataStore",
	  new DomainStore(dbDao));

	// Call the necessary business functionality.
	performBusinessTask();
  }

  /*
   * Performs business tasks - Imagine that this
   * functionality is called from or via a Business
   * Delegate.
   */
  private static void performBusinessTask() {
	// Retrieve the Singleton service locator
	// object.
	ServiceLocator sl =
	  ServiceLocatorImpl.getInstance();

	// Locate the service named, "DataStore".
	DomainStore dbStore =
	  (DomainStore)sl.locateService("DataStore");

	// Tell the datastore to load an object named,
	// "Ken".
	Object person = dbStore.load("Ken");
  }
}

The bootstrap has to explicitly connect these pieces together by first creating the DataAccessObject component, and then passing the component to an instance of the DomainStore object. Remember, the DomainStore expects a DataAccessObject as its constructor's input parameter. Finally, the DomainStore object is passed to the ServiceLocator for containment.

Inside of the performBusinessTask method, the ServiceLocator singleton is retrieved and then put to use. The component is retrieved with a call to locateService. Notice the textual string passed to the locator method. Once the DomainStore component is retrieved, the load method is called, passing it a parameter. Note: the parameter could be used in a select statement if the underlying DAO is a database object, or is just used to sequentially look up a record, in the case of a flat file.

Throughout this example, I've mentioned a number of possible issues that can be addressed by switching to an IoC container implementation. But first, before we see an IoC example, let's learn a bit about the actual pattern behind these types of containers.

The IoC Pattern, Defined

The Inversion of Control (or IoC) pattern was designed to solve a multitude of issues, including:

• Component dependency resolution
• Configuration management
• Lifecycle management

Most IoC implementations or frameworks concentrate on component dependency resolution and lifecycle management, leaving configuration management to a third-party component to handle. This is the case with PicoContainer. But I will come back to this issue in the next section.

The IoC pattern is also known as Dependency Injection, which actually better describes what the pattern does. At runtime, the implementation is said to inject a particular implementation when needed by an object. The selection and creation of the dependent object isn't resolved until a component that utilizes the object is requested. At this point, the container looks at what the component might need in order to become fully initialized and assures that these prerequisites are met. In order to help us understand this concept, let's look at a graphical representation of it in Figure 1.

Figure 1. Graphical representation of the Dependency Injection concept

As shown in Figure 1, the client makes a request for Component A. Component A depends on Component B and Component C. Therefore, these two components are constructed prior to constructing Component A, since it will need them in its own initialization before being returned to the client. If you've been following along thus far, the question that should be going through your head at this point is: "How does the container know which components to create before creating Component A?"

The component doesn't go out and fetch the objects it depends on. Instead, it simply declares the types. The container is then responsible for fulfilling the order. It's sought of like going to a restaurant and telling the waiter that you would like to have fish. You didn't tell him what kinds of fish, you simply stated that you want fish. Therefore, the waiter can come back with cod, catfish, or any other variety that fits the bill.

IoC works in the same way. A component such as a DomainStore can specify that it requires a DataAccessObject, and later be passed one when it is needed. If the DomainStore specified that it wished to use a database-aware component, it would be totally controlling the type of object it would be using. However, by allowing the container to choose one for it, it is delegating its control (hence "Inversion of Control").

IoC frameworks can choose to implement the dependency discovery however they choose, although the obvious choice is to use reflection to reverse-engineer the component to discover the types of objects it depends on, and then create instances of those objects based on some registry that is kept by the framework. This will become clearer as we meet the two IoC containers used in this article.

Dependency Injection Types

There are formally three types of dependency injection techniques implemented by IoC containers. The first type is referred to as interface injection (AKA "Type 1 IoC"). This technique relies on interfaces for specifying the injection class. For example, in our case, we could say that the DbDataAccessObject can be injected in place of DataAccessObject. Later, when an object such as the DomainStore requires a DataAccessObject, it can be provided one based on the interfaces registered. However, this technique makes no assumptions about any of its registered classes, as is the case with Constructor or Setter dependencies. Furthermore, it isn't passed the object in its constructor or a setter method. Instead the component, in most cases, must request an instance that implements the required interface.

An example of a container framework that uses interface injection is Avalon (an Apache project that was recently announced closed). Here's an example of how the DomainStore would need to access a DataAccessObject at runtime.

Listing 9. An Avalon example

public class DomainStore implements Serviceable {
	private DataAccessObject dao = null;

	public void service(ServiceManager manager) throws ServiceException {
		dao = (DataAccessObject)manager.lookup("DataAccessObject");
	}
}

In this case, the ServiceManager acts as a ServiceLocator. Notice the textual string passed to the lookup method.

The second technique is known as setter injection (AKA "Type 2 IoC"). With setter injection, the component that depends on other components must implement setter methods to receive the components that it depends upon. In most cases, there needs to be some glue to tie the pieces together. We'll see an example of this technique when we take a look at the HiveMind example.

The last technique, and the one I prefer, is constructor injection (AKA "Type 3 IoC"). In this technique, the container looks at the constructor of the requested component. It then creates any necessary dependent components and ensures that the constructor of the request component is passed the dependent components as needed. In the next section, we'll see this technique used as we take a look at the PicoContainer example.

PicoContainer

Now that you understand what IoC is from a conceptual perspective, let's see how we can make use of it within a specific implementation of the pattern. The container I'm referring to here is the PicoContainer (or "Pico"), a lightweight IoC container that relies on nothing but the Java standard edition API.

Although the PicoContainer supports both setter and constructor injection techniques, its developers prefer the constructor injection technique and suggest that developers follow suit. Another important feature of PicoContainer is that it doesn't require the application to provide a registry or configuration file of any type. In fact, it doesn't even support this on its own. This is done for two reasons: one, to keep the code to a minimum, and two, to keep the dependencies low. If you wish to have a configuration file to provide the glue, you can use the NanoContainer, which sits on top of PicoContainer and provides the registration of objects based on a configuration file.

One other cool feature of Pico is that it can easily be pulled out of the picture and the components tied directly together (although I can't imagine that you'd want to do that once you start to use it).

Listing 10 provides an example of a client that creates an instance of a PicoContainer. Notice that it isn't used as a singleton; we simply keep the instance around and manage it as needed. Once the instance is created, we simply pass it the implementation classes needed by this application. Again, imagine that the main method is the bootstrap process. Observe the fact that we don't need to tell the container anything about the way in which these classes are to be connected. It figures these details out on its own.

Listing 10. A PicoContainerTest client class

package picocontainer;

import org.picocontainer.*;
import org.picocontainer.defaults.*;

import integrationtier.DbDataAccessObject;
import integrationtier.DomainStore;

/**
 * This class creates a default pico container,
 * places some classes into it,
 * and retrieves the services for use.
 */
public class PicoContainerTest {
  private static MutablePicoContainer pico = null;

  public static void main(String[] args) {
	/*
	 * Initialize the service locator.
	 * We'll use the actual implementation to call
	 * methods that would need to ONLY be called
	 * when the service locator is initialized
	 * and only from the object initializing it.
	 */

	pico = new DefaultPicoContainer();

	// Place the service in the Container.
	// Notice that we don't have to create an
	// instance or pass it to the DomainStore. The
	// DomainStore will automatically be passed
	// the DAO implementation.
	//
	// Also notice that we don't use static names
	// here.
	// Instead, we use the class type to identify
	// the classes.
	pico.registerComponentImplementation(
	  DomainStore.class);
	pico.registerComponentImplementation(
	  DbDataAccessObject.class);

	// Call the necessary business functionality.
	performBusinessTask();
  }

  /*
   * Performs business tasks - Imagine that this
   * functionality is called from or via a
   * Business Delegate.
   */
  private static void performBusinessTask() {
	// Locate an instance of the service named,
	// "DataStore".
	DomainStore dbStore =
		(DomainStore)pico.getComponentInstance(
		DomainStore.class);

	// Tell the datastore to load an object named,
	// "Ken".
	Object person = dbStore.load("Ken");

	// Look Mom! No Singletons!
  }
}

We also don't have to specify any textual ID for the registration. It simply uses the class object as the ID, which it maps to the actual class object itself, for later retrieval. The registerComponentImplementation method is actually overloaded to allow the caller to simply pass the class object, pass the class object and an ID; or pass the class object, the ID, and a set of parameters, which are then passed to the object when the object is constructed. The fact is that the PicoContainer has many different methods to register implementations, instances, and adaptors (too many to mention here). Just the same, there are a great number of methods to create instances with, as well. To mention and explain all of the various methods and parameters that can be used when communicating with PicoContainer could fill a book.

Later, in the performBusinessTask method, a DomainStore object is requested and Pico is happy to comply. We didn't need to pass it anything about the constructor. We didn't have to create an instance of the DataAccessObject; it just worked. Also notice that we didn't have to pass it a textual string; instead, we pass it the class object of the type of object we expect back from Pico. Once the DomainStore object is returned, we're ready to call its methods.

The PicoContainer can handle very complicated references, such as when one component depends on another, which depends on the first. It handles these situations by providing proxies. Proxies are used to supply a component with its dependencies. The dependencies are actually proxies that are used in place of the actual dependent object. The dependent object will be created just in time, when it is initially called. The proxy will provide the exact interface as the dependent object; however, any calls made to the proxy will be delegated to the actual object once it is created.

Thus far, we've seen how a single PicoContainer can be used to house all of the various services that can possibly be used by a system. However, what if you want to limit the visible scope of one type of object to one or more other objects? Also, what if you want the ability to have hierarchies of containers and the ability to override objects that exist in containers at lower levels of the hierarchy? Pico offers the ability to create hierarchies of containers, which support all of these functions. See Figure 2 for an example of how a hierarchy could be used to control the scope of objects within a given container hierarchy.

Figure 2. Graphical representation of a container hierarchy