ServiceRegistry

To be Reviewed By: 30 Oct 2020

Authors: Udo Kohlmeyer & Patrick Johnson

Status: Draft  Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

...

Whilst working on GEODE-8466 - Introduction of ClassLoaderService Abstraction, detailed in the Introduction of ClassLoaderService into Geode RFC, it quickly became apparent that it would be close to impossible to replace all previous static usages with an instance usage. As this This approach requires the ClassLoaderService instance to be passed in either as a method arg or as a constructor argument. In most cases, the effort to replace a single static method call with an instance method invocation would be 5-10x more work and would require the modification of many, directly or indirectly, related classes. In most cases, the replacement of the single static method invocation is more work than the apparent effort to pass it itin.

In addition, the adding of extra arguments to constructor and method arguments, makes for an approach that is not only cumbersome but also unsustainable, as the addition or of more argument to the constructors and methods requires exponentially growing the number of tests to ensure all cases are covered.

What would be nice is a DI (d-eye) framework (like Spring or Guice) that could be used to inject service instances into the classes as required. What this would mean is an extensive overhaul of the current design and service interfaces that would be too costly and take too long to introduce. A simple a mechanism to lookup registered service instances would be most ideal, as this would reduce the number of changes to code, whilst removing static feature invocations and replacing them with single instance executable service calls.

...

A simple approach to register, lookup, and unregistering of Service instances is required. The simplest approach is to follow the Server-side service discovery pattern. Where a there is a single registry and all services register themselves with the registry for simple lookup and usage. Unlike the described pattern, the ServiceRegistry is limited to in-JVM services only and no services outside of the JVM are currently supported.

This approach allows for the introduction of new services into Geode without having to explicitly wire them into all constructors and method invocations. Potentially breaking public API's APIs and backward compatibility.

...

In the above class diagram, the ServiceRegistryInstance is a singleton only because it is simpler than adding an instance into the system and then having to wire it into all locations. This singleton ServiceRegistryInstance is only there until a real DI frame can be used and injection of services can be done in a safer and better than manner than looking up services through the singleton.

...