ServiceRegistry
To be Reviewed By: 30 Oct 2020
Authors: Udo Kohlmeyer & Patrick Johnson
Status: Draft | Discussion | Active | Dropped | Superseded
Superseded by: N/A
Related: N/A
Problem
Whilst working on GEODE-8466 - Introduction of ClassLoaderService Abstraction, detailed in 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 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 it.
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 more argument to the constructors and methods requires exponentially growing number of tests to ensure all cases are covered.
What would be nice is DI (d-eye) framework (like Spring or Guice) that could be used to inject service instances into the classes as required. What 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.
Anti-Goals
The investigation of DI frameworks or the inclusion of DI frameworks into Geode is outside of this RFC.
Solution
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 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.
Changes and Additions to Public Interfaces
N/A
Performance Impact
N/A
Backwards Compatibility and Upgrade Path
There will be no backward compatibility issues and no upgrade path additions are required.
Prior Art
Alternatives to this approach are:
- Introduction of DI framework
- Passing in Service instances into constructors and methods, possibly touching 100's of classes
By not taking this approach, the approach of passing service instances around via constructors and methods, increasing the classes touched and increasing the testing footprint that is required.