The ServiceRegistry is used to allow a given application access to application services.

Services are typically registered or requested using an alias name, but older applications may still register and request using interfaces, which is also still supported. Applications that use aliases don't normally need to manually register services as these are created lazily upon first request, but will still need to manually register services that can't be created using a zero-arg constructor.

The ServiceRegistry is initialized as follows:

1. The application invokes module:ct-core/ServiceRegistry.initializeServices which causes all delayed readiness services to be created.
2. Once module:ct-core/ServiceRegistry.initializeServices has finished (once one of the call-backs fire), the application should then register any services that can't be created lazily using zero-arg constructors.
3. The application can now start doing it's proper work.

Because blades aren't allowed to depend directly on classes in other blades, interface definitions are instead created for particular pieces of functionality, and blades can choose to register themselves as being providers of that functionality. The ServiceRegistry and the module:ct-core/event/EventHub are both useful in this regard:

• Many-To-One dependencies are resolved by having a single service instance available via the ServiceRegistry.
• Many-To-Many dependencies are resolved by having zero or more classes register with the module:ct-core/event/EventHub.

The ServiceRegistry is a static class and does not need to be constructed.