Registry

To have a fully distributed and continues running Dream system, there is one piece missing: a registry.  Each machine capable of running Dream, especially on a client box, will feature a local registry.  All local services (which either will be local versions of remote services or unique local services only running on the client machine, to do cross-application communication) are registered with the local registry.  The local registry also knows the master group registry and a master backup group registry.  If a service lookup fails with the local registry, it will contact the master group registry, and cache the resulting service locally, which will be valid for a specified time period.  If the master group registry is not available the master backup group registry is contacted, and its backup requested.  In the local registry the master backup registry will become the new master, and the backup's backup will become the local backup registry (just shifting out the master that was not available, so that always a master and a backup are in the local registry).

When a local running application wants to provide its own REST service API, when starting up, it will register its services with the local registry.  Any local application has then access to any other local application as well as any remote application / service in the cloud (registered to the master group registry).

The Registry API looks like the following:

Each registry knows its backup registry, which will be requested by the client on start-up, so that in case of a timeout, the client will switch to the backup, and therefore can just continue working normally.

Each local registry also knows its remote master group registry as well as the master backup group registry.

When a registry has to go down, for maintenance or any other reason, the system is still working properly without a hiccup.

What a registry like that also allows to do is a seamless offline mode.  Each remote service that will not be available when not connected to the network can have a local counterpart, with the same API.  When in online mode, it just acts as proxy-cache, and forwards all non-cacheable or non-cached calls to its remote counterpart.  In off-line mode however it will have its own, sometimes limited, implementation of the service API.  It will try to fulfill the entire request with only the local information available, or information that has been downloaded before a scheduled off-line mode.  Once the service goes back online, it can execute an update/merge process, uploading all new/changed information to its remote counterpart.

Such a registry will also allow families of similar services to be registered: meaning services with the exact same API and fundamental behavior, but different implementations.  A prime candidate for such a service is a generic storage API.  Each type of storage backend can have its own implementation, and calls to the generic storage service can be forwarded to the appropriate specialized version.  What is important is that the API does not change, and each specialization behaves the same way for the given limited API.  A specialization can provide a richer API, however that part of the API will be more tightly coupled to it's usage counterpart, and a config/hot swapping will be prevented.