Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Architecture design as discussed starting 16/04/2020 - OUTDATED

...

View file
nameMessageRoutingCurrent.drawio

...

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.

...

Long term design featuring a

...

View file
nameMessageRoutingWithController.drawio

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.

...

message broker

...

View file
nameMessageRoutingWithBroker.drawio

Rather than write a bespoke controller the, orchestration In the long term, integration could be performed using an off the shelf product, such as AWS MQ and Apache Camel.

AWS MQ supports integrates with Apache Camel and can be used to provide a sophisticated message broker service which supports multiple messaging patterns out of the box. Implementing this solution will de-couple micro-services from each other, allowing greater flexibility when it comes to changing existing services or adding extra services that need to be consumed.

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

Single request/response timeline

...

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

View file
nameMessageRoutingTimeline.drawio

This diagram shows the path a request takes through the components of the service in the case of a request for dynamic data from the back end. The diagram illustrates the use of a controller, but the concept is the same where no controller or a broker is used.

The steps are

  1. The client makes a request from the internet

  2. Route 53, or other DNS directs the request to the Revalidation service

  3. The WAF checks the incoming request is acceptable

  4. API Gateway routes the message to the controller

  5. The controller routes messages to the back end and TIS Core via private API Gateway calls

  6. The back end and TIS Core send their responses back to the controller via the gateway

  7. The controller aggregates the response and returns it to the public API Gateway

  8. The public API Gateway sends the response back to the client via the WAF and Route 53.

Current Implementation

This is the current implementation in stage-revalidation as at Fri 24/04/2020:

...

View file
nameCurrentImplementation.drawio

Detailed AWS Architecture

This is the architecture for the Revalidation service as at Friday, 18/05/2020

...

View file
nameDetailedArchitecture20200514 (6) (2).drawio

Updated Architecture - JS - 19/05/2020

...

View file
nameReval Documentation updated (2).drawio

Needs to be made pretty using draw.io - files above

...

An attempt by Phil using the famous artist Babul for inspiration

Draw.io files

View file
nameCurrentImplementation.drawio

SVG File

...

Image AddedImage Added