3.3 Architecture Variants
Embedded Engine
The deployment can be simplified by embedding the engine into one of the endpoints. In this case, the communications between the engine and its embedding endpoint can be short-circuited (they are not required to go through HTTP and URLs). For example, if the engine is run from the source application and if the source also handles the diagnostics, the diagram becomes:
In this simplified architecture the source is not a service provider any more, it has become an application that consumes services exposed by another application.
If bi-directional synchronization is needed between the two applications, we can still use the same simplified architecture. To synchronize in the other direction, the diagram becomes:
The simplified architecture for bi-directional synchronization is then:
Satellite Engine
The following architecture variant is also possible:
This last diagram shows an architecture suitable for disconnected clients: Application A runs on a laptop with a local data store. It uses the SData synchroniation protocol to catch up with the server (Provider B) when a connection is available. As the engine is stateless and the algorithm fully distributed, each laptop can run its own synchronization engine.
Other Deployment Scenarios
The “simplification exercise” above shows that SData synchronization can accommodate both a “suite” scenario where a central engine coordinates synchronization passes between services and a “disconnected laptop” scenario where each laptop runs its own sync engine.
But the architecture allows a lot more variants because all the interactions go through URLs and the location of the components does not matter much (all that is required is that the engine can access the other component’s URLs). Flexibility is particularly important on the error reporting side, and nothing prevents the engine from sending the diagnoses to more than one diag endpoint. In the context of an application suite, this is usually not required because the suite has a central event management facilty, but when the applications do not belong to a suite, SData allows the system to be configured to report errors in one of the applications, or in the other, or in both, or sometimes in one sometimes in the other (depending on the direction for example). This decision should be dictated by product considerations and the SData architecture should be able to accommodate the various needs of our product integration scenarios.