A Basic Introduction On Service Locator Pattern

Introduction

In the world of distributed applications and service oriented architecture, the need of transparently locating the business components and services in a uniform manner is the need of the hour. Most of the Enterprise applications require a way to look up the service objects that provide access to distributed components.

Background

The Pattern evolved to address:

1. Centralization and reusability of the implementation of lookup mechanisms for .NET application clients.
2. Encapsulation of vendor dependencies for registry implementations, and hiding the dependency and complexity from the clients.
3. Avoiding performance overhead related to initial context creation and service lookups.
4. Re-establishing a connection to a previously accessed object instance, using its Handle object.

Service Locator Pattern

Service Locator is a provider-driven abstract factory design pattern, which is be used to create instances of component servers. It supports configurable as well as run-time dependency injection.

Component services in future can be physically distributed across different servers and machines.

A service component can be used across applications. This service will be used remotely through some remote interface, either synchronous or asynchronous (e.g.. web service, messaging system, RPC, or socket.).

These core components are intended to be used, without change, by application that is out of the control of the writers of the component. 'Without change' means that the using application doesn't change the source code of the components, although they may alter the component's behaviour by extending it in ways allowed by the component writers.

Service Locator Pattern addresses the following design considerations:

1. To access the business-tier components from presentation-tier components and clients, such as devices, web services, and rich clients.
2. To minimize coupling between clients and the business services, thus hiding the underlying implementation details of the service, such as lookup and access.
3. To avoid unnecessary invocation of remote services.
4. To translate network exceptions into application or user exceptions.
5. To hide the details of service creation, reconfiguration, and invocation retries from the clients.

Service Locator Pattern - Implementation Sequence

Abstract

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

This pattern reduces the client complexity that results from the client's dependency on and need to perform lookup and creation processes, which are resource-intensive. To eliminate these problems, this pattern provides a mechanism to abstract all dependencies and network details into the Service Locator.

The Service Locator abstracts the API lookup (naming) services, lookup complexities, and business object creation, and provides a simple interface to clients. This reduces the client's complexity. In addition, the same client or other clients can reuse the Service Locator.

References

• Service Locator Enterprise Library Application Block 1.0
• Core J2EE Patterns - Service Locator

Conclusion

I will try to give more detailed explanation on this design pattern in the upcoming articles.

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)