Home
The project proposed here can be separated into two areas. On one side the Crest data model, which is for the moment taken from an operational conditions database deployed by CMS experiment. On the other side the software libraries that can deal with the underlying data model. On this second area, considering the importance of the caching layer and the fact that the use case for our system is “READ often” and “WRITE rarely”, we have decided to pursue the development of the components for the management of the conditions data in the form of a server component deployable in standard web frameworks. This implies that a third component needs also to be developed: some thin client layer, allowing to talk with the intermediate server component. Another project is devoted to the client libraries for Crest. The preliminary prototype is described in this document is based on these architecture principles.
The relational model is illustrated below:
The Crest architecture consists in a multi-tier model service, exposing a REST api to manage conditions data files that are stored in a relational DB (further storage technologies can be implemented). The Crest server provides the full set of management functions to interact with the backend (where conditions data and metadata are stored) and exposes them via a pure REST API. Disentangling the details of how to manage the resources from the client allows a big simplification of the client layer, and gives more flexibility to move to different backend implementations.
In the picture below we show the Crest server architecture and a possible deployment model, reusing the caching components which have been deployed until today in ATLAS and CMS experiments.
The Crest API (i.e. the low level REST API allowing to interact with the backend system via the server) has been defined with the help of CMS experience. The API is described using swagger OpenApi specifications so that we can profit of existing tools to generate part of the low level software libraries for the client and the server side. The JSON files describing the API are included in the project under the repository swagger_schemas. They contain on one side the specification for the methods (the URLs) and their parameters, and on the other a description of the request and response Body.