The architecture chapter describes the overall architecture of Eclipse Ditto and in detail which sub-components fulfill which responsibilities.
Top level component view
This overview shows the Ditto services (components), the externally provided and consumed API endpoints, the external dependencies (MongoDB and nginx) and the relations of the services to each other.
The components have the following tasks:
- Policies: persistence + enforcement (authorization) of Policies
- Things: persistence + enforcement (authorization) of Things and Features
- Things-Search: tracking changes to
Things,Features,Policiesand updating an optimized search index + executes queries on this search index - Gateway: provides HTTP and WebSocket API
- Connectivity:
- persistence of Connections
- sends Ditto Protocol messages to external message brokers and receives messages from them
All services run in the same Pekko cluster and can reach each other via TCP without the need for an additional message broker in between.
Components
Ditto consists of multiple “microservices” as shown in the above component view.
A “microservice” in Ditto is defined as:
- has its own data store which only this microservice may access and write to
- has an API in form of signals (commands, command responses, events)
- can be accessed by other services only via the defined signals
Communication
All microservices can communicate asynchronously in a Ditto cluster. Communication is done via Pekko remoting which means that each service acts as server, providing a TCP endpoint, as well as client sending data to other services.
All messages which are sent between Ditto microservices must in a way be serializable and deserializable.
All Ditto signals can be serialized from Java objects to JSON representation and deserialized back
from JSON to Java objects.