J2EE Design Pattern : Business Tier Patterns : Service Locator Design Pattern

• Service Locator Design Pattern?
• Example for Service Locator

Service Locator encapsulates the complexity of business service lookup and creation. It locates business service factories.

Problem

J2EE applications clients need to locate and access business-tier components and services.

For that it must first look up specific object and then obtain the connection or session from the factory.

When you implement a lookup mechanism in your clients, you can deal with several problems related to complexity, duplication of code, performance degradation, and vendor dependency.

Context

You want to transparently locate business components and services in a uniform manner.

Solution

A Service Locator is used to implement and encapsulate service and component lookup. A Service Locator hides the implementation details of the lookup mechanism and encapsulates related dependencies.

Application clients can reuse the Service Locator to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.

A Service Locator reduces the client’s dependency on the underlying lookup infrastructure, and optimizes resource-intensive lookup and creation operations.

Service Locator Class Diagram

Participants and Responsibilities

Client

Client represents a client of the Service Locator that needs to locate and access a component or service in the business or integration tier. For example, a Business Delegate performs the role of a client of the Service Locator when it locates and accesses its Session Façade. Similarly, a Data Access Object fulfills the Client role when it uses a ServiceLocator to obtain a JDBC DataSource instance.

ServiceLocator

The ServiceLocator encapsulates the API lookup (naming) services, vendor dependencies, lookup complexities, and business object creation, and provides a simple interface to clients. This reduces the client’s complexity and increases reuse.

Cache

Cache represents an optional ServiceLocator to hold onto references that have been previously looked up. The sole purpose of using the Cache is to optimize the ServiceLocator by reducing redundant lookups.

InitialContext

The InitialContext object is the starting point in the lookup and creation process. Service providers provide the context object, which varies depending on the type of Target looked up by the ServiceLocator. A ServiceLocator that provides services for different types of Target components (such as enterprise beans, JMS components, and so on) uses corresponding types of context objects, each obtained from a different provider. For example, the context provider for an EJB application server might be different from the context provider for a JMS service.

Target

Target represents the service or component, in the business or integration tiers, that the Client is looking up using the ServiceLocator. For example, when a Client looks up an EJB component, the Target is fulfilled by an EJB Home object. Other components that fill the role of the Target (depending on what is being looked up) are: a JDBC DataSource instance, JMS ConnectionFactory object, such as a TopicConnectionFactory (for publish/subscribe messaging model), or a QueueConnectionFactory (for point-to-point messaging model).

RegistryService

RegistryService represents the registry implementation that holds the references to the services or components that are registered as service providers for Clients. The RegistryService is a “publish and lookup service”, such as the JNDI registry, UDDI registry, and eBXML RegRep.