Building a Neutral Integration Bridge with Zenoh and ISA

Overview

A teammate with deep domain knowledge developed the original integration concept. My role was to turn that concept into something participating technical organizations could see and evaluate. I designed and implemented a proof of concept around a neutral transport layer, a source-independent normalization boundary, and a canonical downstream representation. The public case is intentionally generalized: it names Eclipse Zenoh and ISA, but omits source-system names, downstream platform names, internal endpoints, configuration, and operational details.

Initial Ask

Demonstrate that heterogeneous source data could move through a neutral transport and be translated into a canonical representation without making the core bridge dependent on one source system.

Problem

Without a clear normalization and transport boundary, every new source risks becoming another point-to-point integration. That couples downstream logic to vendor-specific records and makes validation, reuse, and replacement harder. The proof of concept needed to show that source-specific data could be normalized before the core bridge and then translated consistently downstream.

Desired Outcome

Produce a repeatable integration proof that separates source-specific adapters, neutral transport, canonical translation, and downstream consumption strongly enough that each layer can change without forcing a redesign of the others.

Constraints

• The original concept was developed collaboratively; this case distinguishes that concept ownership from my implementation and architecture contribution.
• Only Eclipse Zenoh and ISA are named publicly. Other source, platform, and downstream system names are intentionally generalized or omitted.
• Internal endpoints, topic names, configuration, credentials, licensed runtime artifacts, deployment environments, and operational details are not published.
• The current evidence supports a working proof of concept and local integration path, not a production deployment or user-adoption claim.

Approach

I treated the integration as a set of explicit boundaries. Source-specific adapters normalize their inputs before the core bridge. Zenoh provides the neutral transport layer. The Java bridge consumes normalized records, maps them into ISA constructs, and emits follow-on publications and diagnostics. I packaged the pieces as a repeatable node/runtime configuration with proof scripts and validation tooling so demonstrations did not depend on an undocumented one-off setup.

Key Decisions

Solution

A Java-based integration proof of concept that accepts normalized records over Eclipse Zenoh, translates them into ISA constructs, publishes follow-on integration outputs, and includes repeatable runtime packaging, validation scripts, proof scripts, and diagnostics.

Personal Contribution

A teammate developed the original integration concept and brought strong domain understanding of the problem. I converted that concept into the working proof of concept: designing the normalization boundary, implementing the Java bridge and canonical mappings, connecting Zenoh transport to ISA SDK constructs, implementing lifecycle/publication behavior, and building the repeatable packaging and validation path used to demonstrate the capability.

Technical Implementation

The implementation is Java-based and integrates Eclipse Zenoh with the ISA SDK/runtime. Source adapters normalize input before the bridge. The bridge consumes the normalized contract, creates the required ISA-side constructs, and emits diagnostic or enriched publications used to prove the path. Container/runtime orchestration, initialization, validation scripts, and proof tooling make the local integration repeatable. Specific source systems, downstream systems, endpoints, topics, object names, and configuration values are intentionally omitted.

Tech Stack

• Java 21
• Eclipse Zenoh
• ISA SDK / runtime
• Containerized runtime tooling
• Validation and diagnostic scripts

Result & Impact

The proof of concept demonstrated that a normalized record could traverse the neutral transport, be consumed by the Java bridge, and be translated into canonical ISA-side constructs in a repeatable local integration package. It also demonstrated lifecycle and publication behavior beyond a single static message. The work remains a technical proof rather than a production-deployment or adoption claim; additional transport and downstream integration work is still in progress.

Learnings

• The most important integration boundary is often the normalized contract between source-specific adapters and the reusable core, not the transport API itself.
• Canonical models reduce coupling only when source-specific assumptions are prevented from leaking into the bridge.
• Proof scripts, diagnostics, and repeatable packaging are part of integration engineering because they make architecture claims observable and falsifiable.
• Implementation credit should be explicit when the engineering work turns a collaboratively developed concept into a demonstrable system.

Next Steps

• Continue the remaining transport and downstream integration work without expanding the public case beyond what has been proven.
• Create a fully synthetic architecture diagram showing source adapters, normalized transport, the Java bridge, canonical translation, and a generic downstream consumer.
• Review any future code excerpts or test output before publication rather than linking the current implementation repository directly.