Proposal: Exploring a Modern, API-Compatible OIE Runtime

[david-labs-ca]

TL;DR: I propose exploring a clean-room Python rewrite of the OIE server—not to replace or disrupt OIE, but to provide a modern, modular runtime. Functional compatibility, rather than technical similarity, would be the acceptance criterion. It should reproduce existing API contracts, work with the excellent new OIE Web Client, support established integration workflows, use a resilient modern database, and ship as a configurable Docker image. The software would remain fully open source, with revenue coming only from optional consulting and on-call production support. We should begin with a small proof of concept to evaluate feasibility, compatibility, licensing, and community impact.

Proposal: Exploring a Modern, API-Compatible OIE Runtime

I have been considering this idea for some time, but I wanted to raise it carefully because I do not want to interfere with the current direction of Open Integration Engine or the excellent work underway on the new OIE Web Client.

This is not intended to replace OIE, fragment the community, or redirect effort away from the existing project. It is a proposal for discussion around whether OIE could eventually support a second, modern runtime implementation while preserving the functionality and interoperability that make the platform valuable.

Background

Mirth Connect was originally released as an open-source project in 2006. That means its fundamental architecture carries nearly two decades of technical history.

The current OIE server continues that lineage in Java. This has the enormous advantage of compatibility and maturity, but it also means that modernizing the underlying architecture incrementally may become increasingly difficult.

My proposal is to explore a clean-room reimplementation of the server runtime in Python.

The acceptance criterion would not be technical similarity with the current Java implementation. It would be functional compatibility.

In other words:

The implementation may be completely different internally, but an OIE user, channel, connector, API consumer, or Web Client should continue to experience the expected OIE behaviour.

Why consider a separate runtime?

The intention would be to preserve the established OIE operating model while creating a smaller, modular and cloud-friendly runtime that can be distributed as a self-contained Docker image.

The proposed runtime would aim to provide:

• Compatibility with the existing OIE server API contracts.
• Compatibility with the new OIE Web Client.
• Import and execution of existing channel configurations wherever technically possible.
• Support for established healthcare integration workflows and message formats.
• A modular connector and plugin architecture.
• A modern embedded database suitable for reliable standalone deployments.
• Support for external production databases where scale or operational policy requires them.
• Straightforward deployment through a configurable Docker image.
• Clear migration and compatibility tooling for existing OIE installations.

The first milestone would not be feature innovation. It would be behavioural compatibility.

Only after the essential server contracts and integration workflows were reproduced would it make sense to build additional capabilities.

The OIE Web Client

The new OIE Web Client is exceptional. It demonstrates how much of the administration, monitoring and user experience can be improved without remaining constrained by the current desktop client.

My suggestion would be to fork the Web Client—with the maintainers’ approval and in full compliance with its licence—and build upward from it.

The new runtime would reproduce the server-side API contracts required by the Web Client. This would allow the Web Client to remain the common management interface while the underlying runtime could potentially be either:

1. The existing Java-based OIE server; or
2. The proposed Python-based runtime.

This separation could also help establish the Web Client as a first-class, runtime-independent component of the OIE ecosystem.

Open-source and support model

The proposed runtime would remain fully open source.

Hospitals and healthcare organizations should be free to:

• Download it.
• Deploy it.
• Modify it.
• Build infrastructure around it.
• Scale it.
• Operate it independently.
• Engage any consultant or internal team they choose.

Core functionality, security capabilities and scalability should not be intentionally restricted to create an artificial commercial tier.

The commercial model would instead be based on optional professional services:

• On-call engineering support.
• Architecture and deployment consulting.
• Migration assistance.
• Production incident response.
• Security hardening.
• Performance optimization.
• High-availability and disaster-recovery design.
• Custom connector and plugin development.
• Long-term support agreements.

The software remains open. Expertise, response time and operational accountability are what organizations may choose to pay for.

Important compatibility questions

Before any implementation begins, the community would need to evaluate several difficult areas:

• Which existing REST API contracts must be reproduced exactly?
• What level of compatibility is required for channel XML and configuration exports?
• How should existing Java and JavaScript-based transformers be handled?
• Can existing plugins be supported, or would a new plugin contract be required?
• Which database behaviours are relied upon by the current server and Web Client?
• What constitutes acceptable behavioural compatibility?
• How should conformance and regression testing be structured?
• Should this exist within OIE, as an experimental OIE project, or as an independent project that integrates with OIE?
• How do we prevent duplicated effort and community fragmentation?

These questions should be answered openly before choosing the architecture or writing substantial code.

Suggested first phase

I propose beginning with a small feasibility study rather than committing immediately to a complete rewrite.

The study could:

1. Document the current OIE server API surface used by the Web Client.
2. Identify one representative end-to-end integration workflow.
3. Implement a minimal Python runtime for that workflow.
4. Connect the OIE Web Client to the experimental runtime.
5. Package the runtime and its database as a Docker image.
6. Build compatibility tests that can run against both the Java and Python implementations.
7. Document the incompatible or particularly difficult areas.
8. Present the findings to the community before deciding whether to continue.

A successful proof of concept might include:

• Authentication.
• Channel listing and configuration.
• Channel deployment.
• One inbound connector.
• One transformer pipeline.
• One outbound connector.
• Message persistence.
• Basic logs and statistics.
• Web Client visibility and control.

Relationship with OIE

I want to emphasize that this proposal comes from respect for what the OIE team is building.

OIE is preserving an essential open-source healthcare integration platform after Mirth Connect transitioned to a proprietary model beginning with version 4.6 in March 2025. The existing Java codebase provides the compatibility and continuity that the community needs today.

A clean-room runtime would be a longer-term experiment—not a criticism of that work and not an attempt to pull contributors away from current priorities.

If the maintainers believe that this proposal would create distraction, licensing concerns, brand confusion or unnecessary fragmentation, that feedback should determine how—or whether—the idea proceeds.

The immediate question is therefore not:

“Should we rewrite OIE in Python?”

It is:

“Would an independently implemented, API-compatible runtime strengthen the OIE ecosystem, and is there a responsible way to test that idea without disrupting the work already underway?”

I would appreciate feedback from the maintainers, Web Client developers, integration engineers and organizations currently operating OIE or Mirth Connect in production.

[NicoPiel]

Why Python? If security and stability are the main concern here, along with historical technical debt, then wouldn't a rewrite in, say, Rust be much better? I don't see how Python provides any benefit over Java. If anything, we could consider a clean-room in Java 25, or Kotlin. Rust, Java and Kotlin also provide much more broadly available inter-operability with other languages for scripting, e.g. Lua or JavaScript, are much faster than Python and far safer.

If we were ever to consider a rewrite, I don't think that would be a project for OIE. It would be a separate product, imho.

[david-labs-ca]

Rust was an option, yes. But the learning curve is big as compared to python. And looking at the future, python wins the race. Cross-compatibiity with JS is also a concern. I don't know how Rust will fair against Python.

[NicoPiel]

Yes, but learning curve isn't what should dictate a rewrite. Rust is the superior language for a critical backend such as OIE.
Rust has been the most admired language for years, and that isn't going to change anytime soon.

Regarding cross-compatability, Rust is also superior. Being a low-level language has many advantages when integrating other languages, exemplified by Bun and Dino being Rust implementations of JavaScript and TypeScript.

But I'm not here to advertise Rust. I think a rewrite has merits, but it's not something I think OIE is going to tackle.

[david-labs-ca]

Totally understand. While fascinating, the choice of language matters because people have a hard time understanding Rust and it's core components. My initial pick was Rust. and not python. But if someone wants to extend the functionality say an ASTM connector, developing that as a plugin (still a question on table as to what to do with them) in Rust will be fairly difficult than Python and will probably need special Rust Developers atleast. Again, Rust is also a good candidate.