Architecture

Current architecture design as discussed starting 16/04/2020

This is the current view of how the service will work, with the back end making calls out to TIS Core to pull in data not duplicated in Revalidation.

The disadvantage with this approach is the tight coupling between the back end and TIS Core which means routing complexity, monitoring and recovery is added to the back end. Managing messages to other services should not be the responsibility of the back end.

The complexity of the back end will be increased each time it needs to talk to another service, e.g. Self Service for Form Rs or future GMC Connect APIs.

Alternative design featuring a bespoke controller

Adding a bespoke controller to the design will allow the orchestration between different services to be abstracted from the back end. The controller would be responsible for splitting requests between the data providers and aggregating the responses before the reply goes back to the client.

The controller could be a micro service or, possibly, a Lambda function.

Alternative design featuring a message broker

Rather than write a bespoke controller the, orchestration could be performed using an off the shelf product. AWS MQ supports Apache Camel and can be used to provide a sophisticated message broker service which supports multiple messaging patterns out of the box.

With our current, envisaged configuration there would be very little custom code required to be written. Most of our requirements would be handled by configurable settings in Camel.

This solution is the most flexible when it comes to adding extra services that need to be consumed.