MaaS Dynamic Catalogue (MDC)

At a Glance

• Category: Cloud & Marketplace Solutions
• Primary environment: Cloud MaaS Marketplace
• Documentation focus: Design reference
• Maturity: TRL 4 (first release, M18)
• Related architecture docs: Reference Architecture Guide, Environments

Purpose

The MaaS Dynamic Catalogue (MDC) provides a means for representing the body of knowledge of the MaaS system by utilizing ontologies. It enables adequate description of the assets, services, offerings, capabilities of the MaaS Providers, which makes it possible for MaaS Consumers to search and request desired manufacturing services. The solution consists of the following main implementation components, each fulfilling a dedicated function within the system:

Primary Actors

The D5.2 usage viewpoint defines roles, permissions, constraints, a role-task matrix, and a use case diagram for this solution.

• MaaS Provider: Describe Assets, Describe Services, Provide Services, Provide Offer, Update Service Description, Publish services; constraint: Cannot manage other users (create, edit or delete)
• MaaS Consumer: Search Services, Discover Services, Request Services, Get Service Recommendations, Select Services, Accept/Decline Offer; constraint: Cannot manage other users (create, edit or delete)
• Administrator: Manage User Accounts, Manage Service Directory, Approve User Registration, Validate Services, Approve Services; constraint: Cannot provide manufacturing services

Use-case diagram extracted from MaaSAI deliverable D5.2.

Functional Components

MDC combines security, API gateway, ontology, knowledge-base, recommendation, and monitoring modules to support service publication, discovery, and recommendation workflows. The functional view shows how provider and consumer interactions move through these catalogue components to expose both search results and operational dashboards.

Functional components diagram extracted from MaaSAI deliverable D5.2.

Design Baseline

• Frontend: The MDC UI is used by the MaaS Providers and MaaS Consumers to describe/publish and search/request manufacturing services respectively. The Administrator is also able to view alerts and performance metrics via dedicated dashboards.

• Backend: This refers to the core components and services of the MDC. This includes the following sub-components: ontology module, knowledge base, recommendation module and update module.

• Data storage: Database backend for storing static and dynamic data. Required for storing and archiving updates regarding events, provider logs, transactional data etc.

Architecture diagram extracted from MaaSAI deliverable D5.2.

Technology Stack

MDC is implemented as a Python backend service with a clearly separated semantic processing layer.

Category	Technology
Backend	Python, Django, Django REST Framework (REST APIs and serializer-based validation)
Data serialisation	JSON (API input/output), YAML (human-readable provider capability data, read via PyYAML)
Semantics	RDF/Turtle for ontological representation, RDFLib for RDF graph generation, SPARQL for retrieval
Semantic store	Apache Jena Fuseki as remote SPARQL endpoint
Data	PostgreSQL for persistent storage
Licence	no separate public licence; follows MaaSAI project-level licensing guidelines

Integrations & External Dependencies

MDC has no user interface of its own: the Cloud MaaS Marketplace (CMM) acts as its UI and entry point for provider service publication and consumer search requests, although this integration is not yet active (the current release works with a mock UI and a REST client). Required dependencies include the Python/Django runtime, RDFLib, Apache Jena Fuseki, PostgreSQL, PyYAML, and Docker/Docker Compose for deployment.

APIs & Interfaces

MDC exposes a REST API intended for consumption by CMM:

• GET /api/health — health and availability of the MDC backend service
• GET /api/catalog/filters — vocabulary values for service requests (part families, processes, materials, batch/dimension ranges, certifications)
• POST /api/provider-publication — publication and validation of provider capabilities (partially implemented)
• POST /api/search — consumer search returning a list of matching providers (partially implemented)

Functional Flow

MDC exposes no user interface of its own (the Marketplace acts as its UI); the sequence diagrams below illustrate its two core flows:

Provider publication validation sequence — MaaSAI deliverable D6.1.

Semantic representation and retrieval sequence — MaaSAI deliverable D6.1.

Deployment & Configuration

The current release runs as a Django backend service in the test/laboratory environment of Tampere University, executed via a Python virtual environment and the Django development server; Docker, CI/CD pipelines and a reverse proxy are planned for production deployment.

Requirement	Minimum	Recommended
CPU	2 cores	4–8 cores
RAM	6 GB	8–16 GB
Storage	2 GB free	—

The higher recommended values are mainly for Fuseki. Configuration parameters cover the provider seed YAML file, the provider ID assigned via the Marketplace, the semantic backend selection (local RDFLib/YAML or remote Fuseki), Django module settings, and the Fuseki URL endpoint.