System Architectural Overview
=============================================================================

|entt| is an event driven service that uses |encd| as the mean for communication between |en| |tms| applications and the service. |tms| applications will send a **publish event** to |encd| when they want add containers to the |entt|, and they will register a **Web-Hook** to receive notifications about new container status results.

|en| |tms| applications will not communicate directly with the service. Instead, they will communicate with |encd|, which will track the information about the containers published, as well as the results history. This design will allow us to use additional tools on the data to generate reports and implement BI.

The following diagram shows the architecture of the system:

..  image:: /_static/system-architecture.png

|en| |tms| applications will use |enim| to authenticate and retrieve an access token that will allow them to communicate with |encd|. |en| |tms| applications will be issued a client id and secret to perform this authentication process. They will use the **Client Credentials** workflow as described in the |auth|_ topic.

Once the application has authenticated with |enim|, they can use the access token to publish containers to |encd|. The |encd| service will notify |entm| of the event.

|entm| will generate a **trace job** and store information about that job for later use. It will also publish the current job to |entr|, which will trace the container for the first time.

|entr| will trace the container and retrieve the current status. That information will be sent to |entm|, which will generate a **results event** for |encd|.

|encd| will then notify the |tms| of the trace result through the registered **Web-Hook**.

From this point on, |entm| will schedule new traces of containers based on the results received. This means that |en| |tms| applications only need to publish the containers once. After that, |entm| will take care of scheduling the next trace.

..  note::
    A container might be published multiple times by a |tms| application. This unnecessary process will not cause an error, and |entm| will handle that scenario. This, however, allows users to force tracing at that time for most providers.