Introduction↗
Our simulation software was a standalone desktop application used to design and validate industrial operations. Over time, it became a reference product in its field and was well known among our customers.
The software relied on several numerical simulation modules, and the entire product was implemented in C++/MFC.
As part of the company’s digital transformation, new cloud‑based applications emerged and needed to benefit from the same computational capabilities as the desktop product.
Because the original desktop application was not intended to be retired, it became essential to guarantee that both systems, now part of a shared workflow, would produce identical results.
Architecture Overview↗
The initial computation module was already available as C++ code and encapsulated behind a simple object model.
We first defined a clear contract through a pure C++ API. This API had to remain plain C++ and avoid exposing any internal technologies used by the implementation (STL, Qt, MFC, etc.). When the existing implementation is clean enough, the API can be directly copied or derived from it.
Then we developed a C++/CLI wrapper responsible only for translating between the C++ and C# environments. As recommended by Microsoft, this layer remains as passive as possible and contains no business logic.
Finally, we created a simple C# RESTful web service communicating through JSON streams. The service deserializes the input JSON, forwards the resulting data structure to the C++/CLI wrapper, and the wrapper passes everything to the C++ engine.
The following class diagram shows the interaction between the 3 code layers.
The computation is triggered by a call to the web service. The caller provides a well‑formatted JSON input stream and receives the results in the output stream.
Implementation Details↗
As mentioned earlier, the web service implements a RESTful API. It was developed using the C# 4.6 framework, although a more portable version of C# could be used as long as it supports CLI. A pure C++ implementation would also be possible.
The initial C++ engine is built in 64 bits. This imposes a constraint on the C# layer that cannot be configured as ANY CPU and must be also compiled for 64 bits.
The engine is split across several dynamic libraries (DLLs). Due to time constraints and to avoid refactoring the desktop application, we kept the DLLs as they were instead of merging them into a single binary. As a result, all C++ modules must be available in the PATH of the web service host (IIS in our case) so that the entire stack (C#, wrapper, C++) loads correctly.
To support API evolution, the input JSON stream is versioned. The client must specify the version in the stream, and the request is processed only if the engine supports it.
Pros & Cons↗
Pros↗
The RESTful microservice approach completely decouples the client from the service implementation once the JSON contract is agreed upon.
Reusing an existing engine with strong test coverage significantly reduces the risk of discrepancies between the two applications.
JSON handling is greatly simplified thanks to the Newtonsoft.Json library.
Cons↗
Mixing C# and C++ introduces constraints on build configuration and runtime environment.
The CLI wrapper was chosen due to the target engine, but since we have a pure C++ API, the wrapper could also be implemented using .NET Core.
The solution is strongly oriented toward the Microsoft ecosystem, although any type of client can consume the RESTful service.
Additional work would be required on the engine to support non‑Windows platforms.
Conclusion↗
The architecture described in this article has been successfully implemented for multiple computation engines originally present in the desktop application.
This approach allowed the new cloud‑based application to quickly benefit from existing simulation capabilities without requiring any migration or rewrite. More importantly, it ensures strong data integrity between two software components that belong to the same ecosystem.
This approach can be applied to any legacy application and provides a smooth transition toward any digital transformation.