In order to cross this bridge between the consumer and the implementation without direct tight coupling, imagine a layer between them called the service registry. The service registry is a layer provided by the module system to record and register implementations of a given interface as services. Think of it as a kind of phone book or yellow pages, but for services. Any module that implements a service needs to register itself in the service registry. Once that's done, the service registry has all the information about the different service implementations of the interface that are available. The following diagram illustrates this interaction:

Now when the consumer needs an implementation, it uses the services API to talk to the service registry and get instances of the available implementations. The following diagram illustrates this interaction:

What the consumer module gets is an Iterable of instances of all available implementations. There doesn't have to be multiple instances, of course. There could be just one implementation! Either way, the Service API hands over the available instances to the consumer when accessed.

As you can see, we have broken the coupling between the provider and the consumer. Every module in this figure reads just one module in common--the module containing the interface. The interface is the only common entity that all these different modules share, since that's the means of the interaction between them. Since the other modules are completely unaware of each other, you could pretty much remove one implementation module and drop in another. As long as it does the right things--that is, implements the right interface and registers with the service registry--it is available for the consumer to use.

Now that you've understood the concept of services at a high level, let's get into the specifics. How do the modules register their implementations? How does the consumer module access the instances from the registry? Let's look at the implementation details.