¶ DPP Solution Components
This page will go into more technical details on the architecture requirements for a DPP Solution and its components.
The DPP Solution as a whole can be provided by multiple independent providers, allowing some level of interconnection between operators.
There are concerns about interoperability, although this mainly applies to the DPP Service itself.
The main software components considered are:
- Matching Service: an online service that redirects users to the appropriate endpoint/webservice, depending on the input used
- DPP Service: a service that provides DPP data, user interface, and allows manipulation of the DPP
The expected behavior from a regular user using a set of standard devices and features to first access a DPP would look like this:
A similar interaction would occur for M2M, but instead of returning HTML content, the matching service would return a normalized JSON reply containing the content or redirection information.
In any case, when interacting with a dynamic DPP, the DPP Service associated with the product reference is ultimately responsible for handling access control and update operations on the DPP.
Both services can have a tight integration, but for operational reasons, it is recommended to have a clear separation between them.
¶ Matching Service
The matching service could potentially serve as an entrypoint for multiple DPP Service frontends.
It is the central point that handles requests from both end-users and M2M operations.
By its nature, this service can operate in a completely stateless fashion.
In addition, it should not perform any write operation on the data source used to redirect users to the appropriate DPP Service.
As such, it is very easily scalable using standard procedures:
- high-availability load balancers in front
- replication of the matching service behind the load balancers
- access to the database
- a high-availability shared database
- multiple read-only databases, one per instance, with asynchronous replication
The read-only database replicated asynchronously may potentially incur a small time window during which a product reference would not be matched, but that time window can be controlled.
In addition, in the context of manufacturing products, the delay between actually producing a product with a given unique identifier/serial number, and reaching the end-user, is likely to be way higher than the database replication timing.
This service is also very easy to deploy in multiple areas if needed.
Since this is a high-availability, but low operation service, it can also be mutualized between multiple providers, having a single entry point that leverages all the high-availability setup to handle the initial user influx.
For more details on how this service operates and how it can be mutualized, check the matching service.
¶ The DPP Service
The actual DPP Service offers two fundamental components that must consistently be accessible to end users:
- a frontend
- displays public details about a product
- offers an interface for authenticated users to access non-public information
- presents an interface for authenticated users to interact/update the DPP in some capacity
- a backend
- governs user access
- provides details from a DPP ledger
Multiple methods can be employed to implement such a service, but a popular approach is to develop a single-page web application that is hosted by the backend and serves as the frontend for users.
In a streamlined infrastructure, the frontend may originate from the backend.
In a more intricate infrastructure, separating the frontend content from the backend aids in managing the load.
This can also offer some level of controlled feedback to the user in case one of the subsequent components is unavailable or functioning below par.
In any case, the backend operate as a regular webservice and communicates with a ledger containing all DPP data.
This ledger could be a simple database, or a more intricate service.
The current proposal from KeeeX is to combine a file-based approach to provide authenticated "checkpoints" in the life of a product, with a database mirror for performances.
A realistic approach would likely involve different ledgers for distinct use cases/product types.
Alternative options include employing a blockchain to store the DPPs, although these approaches introduce numerous limitations and their benefits are not apparent at this juncture.
The following diagram illustrates a completely decoupled architecture.
As all individual components are stateless (the ledger is the only source of trust), scaling can be achieved appropriately according to operational needs.
The frontend service is relatively lightweight as it always returns static files that do not depend on any ledger details, making them easy to replicate and scale.
On the other hand, backend services perform more intensive operations and must interact with other services, making them dependent on a reliable connection.
The critical component of the system is the ledger itself (database, hybrid solution, SmartContracts…), which requires high-availability services for operation.
Depending on the underlying technologies used, scaling could present challenges; therefore, the choice of technology depends on the anticipated load.
For a small-scale system, a simple approach might involve having a single instance for each service and combining the frontend and backend services into a unified service.
Such an approach remains compatible with basic scalability, but it simplifies the architecture by not having to handle multiple types of services; instead sharing all available resources for both serving the static webapp files and handling operations on the DPP.
¶ Proposal from KeeeX
KeeeX offers the three components of the architecture:
- The matching service
- The Frontend (web application)
- The backend (web service)
The ledger used as a source of truth can be either a regular database (with additional trust information), separate authenticated files using KeeeX technology, Smart Contracts, or a combination of these solutions, depending on the requirements.
As is standard, these services can be deployed on bare-metal solutions, or as container images.
¶ Software distribution
KeeeX offers their services primarily through three major channels:
- SaaS: For some needs, KeeeX can offer a SaaS solution, where the service is hosted by KeeeX and customers have access to a ready-to-use solution.
This approach allows for white-label solutions. - NodeJs applications: Most services are implemented as NodeJs applications that can be deployed on any platform that supports NodeJs. The services are provided as packages with their private dependencies bundled, while others are obtained from NpmJs[1].
- Docker images: When applicable, our services are also available as Docker images and can be deployed on any Docker-compatible platform.
Each image runs one service to facilitate higher-level orchestration and scalability ease.
The images are supplied on a private KeeeX registry accessible to our customers.
For the package and container image distribution, most services rely on external services and configuration for handling database and storage-related tasks.
The services themselves are stateless.