OMSAC: Bridging the Semantic Gap in Microservices Architecture Modeling

TL;DR

Microservices Architectures (MSAs) are notoriously difficult to document and analyze due to their distributed and polyglot nature. This paper presents an Ontology-driven Conceptual Modelling approach using OMSAC. By centralizing architectural knowledge into an OWL2-based triple store, the authors enable automated, high-precision microservice discovery and "multi-viewpoint" analysis that matches human expert performance.

Problem & Motivation: The Fragmentation of Architectural Knowledge

As organizations shift from monoliths to MSAs, they trade simplicity for extreme modularity. However, this creates a documentation vacuum. Current modeling approaches like UML or Domain-Specific Languages (DSLs) often treat functional requirements, technical stacks, and deployment configurations as isolated silos.

The authors argue that without a formalized, machine-readable semantic layer, it is nearly impossible to:

1. Identify reusable components across different systems.
2. Understand hidden dependencies between services (e.g., shared cache or communication protocols).
3. Automate the analysis of a system's "interchangeability."

Methodology: The OMSAC Framework

The core of the solution is the Ontology of Microservices Architecture Concepts (OMSAC). Unlike flat diagrams, OMSAC provides a hierarchical structure (TBox) that defines what a microservice is, what it implements, how it communicates, and where it is deployed.

The Modeling Workflow:

• Data Extraction: Mining Dockerfiles, source code, and existing documentation to fill the ontology.
• Knowledge Base Creation: Storing the resulting "Assertion Box" (ABox) in a Stardog triple store.
• Intelligent Querying: Using SPARQL to answer "Competency Questions" (CQs) like "Which microservices share the same technical dependencies?"

Figure 1: The high-level hierarchy of OMSAC, linking microservices to functionalities and infrastructure.

Experiments: Automated vs. Expert Discovery

The researchers tested their approach on three real-world open-source MSAs. The goal was to find a replacement for the Basket microservice from eShopOnContainers.

They compared three methods:

1. Manual Expert Analysis: The "Gold Standard" (but slow and unscalable).
2. EdgeSim: A traditional graph-based similarity metric.
3. Stardog ML Similarity Model: An ensemble approach using syntactic, semantic, and structural data.

Key Findings:

The Stardog ML model outperformed simple graph metrics by a wide margin. While EdgeSim only looked at the "edges," the ML model understood the semantics of the labels (e.g., identifying that "Cart" and "Basket" are functionally related).

Figure 2: ML-based similarity vs. Expert scores, showing the gap between automated tools and human intuition closing.

Critical Analysis & Conclusion

Takeaway

The shift from "drawing" architectures to "encoding" them in ontologies is a game-changer. It transforms architectural diagrams from static artifacts into active knowledge bases that can drive CI/CD, reuse, and automated reasoning.

Limitations & Future Work

• Modeling Effort: Creating the initial ABox still requires manual or semi-automated effort in mining Dockerfiles and code.
• Scalability of Experts: The evaluation was limited to 25 microservices because human experts cannot manually analyze much more, although the tool itself is built for larger scales.
• Next Steps: The authors plan to develop a Domain-Specific Language (DSL) to make it easier for architects (who aren't ontology experts) to interact with OMSAC without writing raw SPARQL.

By turning the "black box" of microservices into an "open graph" of semantic relationships, OMSAC paves the way for a more automated and manageable cloud-native future.