Distributed Architecture Reconstruction of Polyglot and Multi-Repository Microservice Projects
This paper presents a novel framework for distributed static architecture reconstruction that overcomes existing limitations by utilizing modular, technology-specific extractors to unify data and generate accurate documentation for polyglot, multi-repository microservice projects.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you have a massive, bustling city made up of hundreds of tiny, independent neighborhoods. Each neighborhood (a microservice) is built by a different team, using different materials (programming languages), and following its own unique style. Some are made of brick (Java), some of wood (Python), and some of glass (Go).
The problem? No one has a complete map of the city. The original blueprints are either lost, outdated, or written in a language only the original builders understand. Because these neighborhoods change so fast and are built separately, trying to draw one giant map of the whole city all at once is a nightmare. If you try to look at the whole city at once, you get stuck in traffic, and if one neighborhood changes, you have to redraw the entire map.
This paper introduces a new tool called ModARO to solve this problem. Here is how it works, using simple analogies:
1. The "Specialized Scouts" (Extractors)
Instead of hiring one giant, super-intelligent robot to understand every type of building material in the city, the authors created a team of specialized scouts called Extractors.
- How they work: Each scout is an expert in just one thing. One scout only knows how to read "Java" blueprints. Another only knows "Docker" containers. Another only knows "YAML" configuration files.
- The Magic: You don't need to teach the Java scout how to read Python. You just send the Java scout to the Java neighborhood. They look around, find the important details, and write them down on a standardized notepad.
- No Memory: These scouts are "amnesiacs." They don't remember what they saw in the last neighborhood. They only look at the specific building in front of them right now. This keeps them fast and prevents them from getting confused.
2. The "Universal Notepad" (The Model)
When a scout finishes their work, they don't just keep the notes to themselves. They write the findings onto a Universal Notepad (a JSON model).
- This notepad has a specific format that everyone agrees on.
- If the Java scout finds a "door" (an API endpoint), they write it down. If the Python scout finds a "window" (a database connection), they write that down too.
- Because everyone uses the same notepad format, the information from the Java neighborhood and the Python neighborhood can eventually be combined.
3. The "Orchestrator" (The Algorithm)
There is a conductor (the Reconstruction Algorithm) who manages the scouts.
- The conductor says, "Okay, let's look at this building."
- The Java scout checks it and adds notes.
- The conductor sees new notes were added and says, "Oh, now that we know there's a Java file here, let's call the Docker scout to see if there's a container too."
- This happens in a loop until no new information is found. The conductor ensures that if two scouts try to write contradictory things on the same line, the system stops and raises a flag (an error) so humans can fix it, rather than letting the map get messy.
4. The "Distributed Map" (Multi-Repo Reconstruction)
This is the paper's biggest innovation. In the old days, to draw a map, you had to gather every single blueprint from every single neighborhood into one giant room and look at them all together. This is slow and breaks the "independent" spirit of the city.
The new approach is Distributed:
- Independent Work: Each neighborhood draws its own mini-map while they are building or updating their own houses. They don't need to wait for the other neighborhoods to finish.
- The Assembly: Later, these mini-maps are brought together and snapped like LEGO bricks.
- The "Ghost" Connections: Sometimes a neighborhood says, "We send mail to a place called 'Test-Service'." They don't know the exact address or ID of that place yet because it's in a different neighborhood. The system allows them to write, "Send mail to anyone named 'Test-Service'." Once all the mini-maps are snapped together, the system automatically connects the dots, matching the "Test-Service" sender to the "Test-Service" receiver.
Why is this better?
- No "One Size Fits All": You don't need a complex, fragile system that tries to understand every programming language at once. You just add a new scout (extractor) whenever a new language appears.
- Speed: Because each neighborhood works on its own map, you can update the map for one service without stopping the whole city.
- Flexibility: You can use existing tools. If you already have a tool that analyzes Java code, you just wrap it in a "scout" suit, and it can join the team.
In short, this paper builds a system where small, specialized teams can independently document their own parts of a complex system, and then automatically stitch those pieces together into a complete, accurate picture of the whole architecture, without needing to know everything about the other parts while they work.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.