Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've heard the term pop all around. I've read various articles regarding the subject and heard two main definitions to the term "Service Location":

  1. A glorified Registry - Bad practice, global variables, general evil.
  2. A type of Dependency Injection Container - Can help with managing dependencies, making modular and extensible applications, generally helpful.

But I can't differentiate between the two. What does a Service Location really means? Can you give a simple example of a Service Locator? Is it good or evil?

share|improve this question
Plus I noticed that this question does not appear anywhere on the Stack Exchange network. Posting it would do great for SEO. –  Madara Uchiha Mar 31 '13 at 8:46
Did you already use the intertubes? ralphschindler.com/2012/10/10/di-dic-service-locator-redux –  Ocramius Mar 31 '13 at 8:49

2 Answers 2

Those two things are essentially the same. A service locator is just any centralized system which lets you find a service to process some request. Using the service locator design pattern, you can use this to get an service implementation(which is really an interface at the code level) from the service locator.

More generally, this system is often used in distributed computing to find a node in the network which can service some other node's request.

For example, some client might want to perform some calculations on some data. Lets say there are multiple ways to do this calculation, each implemented as a service, but the client doesn't care which is actually used. The client could just ask for any service from the service locator, without having to worry which specific type is returned.

In both cases, the benefits and drawbacks are largely the same. The service locator lets you modularize your program better and lets you worry less about specific service implementations. On the other hand, you get this centralized point of failure that may be a weak link in your system. Like everything else, it's a tradeoff so there is no simple "good vs bad" answer.

share|improve this answer

There are two key problems with a service locator/registry:

  1. Finding the registry. Often the only way is to have your code be explicitly told the location of the registry, though in some cases (DI containers, discovery protocols such as Jini) the discovery of the registry isn't so hard, or is even provided as a given.
  2. Ensuring that the information in the registry is correct/relevant. This is actually the hardest part of all. Even without the problem of malicious attacks, ensuring that any enduring collection of services is actually curated correctly is a horribly labor-intensive problem. (You can usually automatically detect when the information isn't right — with enough effort — but can't actually determine how to fix the situation without manual intervention.)

OTOH, it's entirely practical to replicate a distributed registry as long as the rate of change of the mappings it contains is not too fast. What do you think DNS is, if not a replicated registry? (Well, with extra stuff too.) This does suggest that using DNS to handle the hard parts of registry management might be a smart move, rather than replicating all that stuff again at a higher level of network stack…

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.