CORBA family

CORBA, the Common Object Request Broker Architecture, is an OMG standard for distributed object computing first ratified in 1991 and currently at version 3.3 (2012). A CORBA program describes its remote interfaces in OMG IDL — the same IDL DDS also uses — and the runtime takes care of marshalling, transport, lifecycle and security.

Three concepts matter for newcomers. First, the ORB (Object Request Broker) is the runtime; it dispatches method calls between processes. Second, the IOR (Interoperable Object Reference) is the address of a remote object — like a URL but typed. Third, the POA (Portable Object Adapter) is how a server registers objects with the ORB and exposes them.

CORBA's wire protocol is GIOP (General Inter-ORB Protocol). When GIOP runs over TCP it is called IIOP — Internet Inter-ORB Protocol. Different transports (HTTPS, shared memory, named pipes) are possible but IIOP is what 99% of deployments use.

CORBA is the OMG's first big middleware standard and is *still* the de facto distributed-object substrate in three industries: financial services trading systems, aerospace flight software, and telecommunications signalling. Bloomberg, Deutsche Börse, Boeing, Airbus, Ericsson and dozens of national stock exchanges still run CORBA in production.

The reason CORBA persists is not lack of alternatives — it is the cost of migration. A CORBA-shaped codebase has interfaces in IDL, dependencies on the POA lifecycle, deep coupling to GIOP transactional semantics, and often a CCM (CORBA Component Model) container running thousands of components. You cannot port that to gRPC or REST in a quarter.

ZeroDDS implements the full 3.3 stack so a CORBA-shaped application can run unchanged, in pure Rust, against a memory-safe ORB. Then — and only then — you can begin to migrate IDL by IDL toward DDS topics, while the rest of the system keeps working. CORBA support is therefore a migration enabler for our target industries, not a backwards-compatibility chore.

On the technical side, the ZeroDDS CORBA family is the only pure-Rust CORBA implementation. Existing Java (JacORB), C++ (TAO, MICO, omniORB) and Python (omniORBpy) options each carry their own toolchain costs. ZeroDDS removes that cost: one workspace, one cargo build, one signed binary.

Verified interoperable — live, both directions

The CORBA wire is not a paper claim. A cross-ORB harness exercises ZeroDDS against JacORB, omniORB and TAO in both directions — ZeroDDS client to foreign server and foreign client to ZeroDDS server — covering Echo, Bench, CosNaming (including federated sub-contexts) and SSLIOP over TLS.

The hard protocols are proven live, not just on paper. The CSIv2 GSSUP security handshake: a ZeroDDS client authenticates against JacORB's real target interceptor — valid credentials pass, wrong ones get NO_PERMISSION. Bidirectional GIOP (§15.8): ZeroDDS opens a connection to a JacORB server, and the server calls back to a ZeroDDS object over that same connection. Valuetypes (§15.3.4): self-describing object graphs with value-sharing, inheritance-state flattening, and chunked/truncatable encoding travel as live operation parameters. Asynchronous Method Invocation (callback and polling) drives a foreign server asynchronously.

Where a wire format is interoperability-critical — the valuetype value_tag and chunk layout, the CSIv2 GSSUP token, the OTS otid_t and PropagationContext, the Bidirectional listen-point service context — it is checked against the foreign ORB's own encoder. That discipline already caught and fixed a real GSSUP encoding bug before it could break a single integration.

A typical CORBA project with ZeroDDS starts with an IDL file describing your interfaces. Run zerodds-idlc --rust --corba -o gen/rust your.idl (or --cpp / --csharp / --java) to emit interface traits, client stubs and server skeletons. Add corba-poa and corba-iiop to your Cargo.toml, instantiate an ORB, register your servant with the root POA. The generated stubs marshal real GIOP requests over IIOP — a ZeroDDS client and a JacORB, omniORB or TAO server interoperate out of the box, no shims.

For migrations the typical path is staged. Step one: keep your existing IDL, regenerate stubs with zerodds-idlc --<lang> --corba, swap your old ORB for the ZeroDDS ORB — a Cargo-managed binary on a wire-compatible IIOP, no client changes needed. Step two: introduce DDS topics for new functionality, run them alongside CORBA. Step three: deprecate CORBA interfaces one IDL at a time, replacing each with a DDS topic, using the corba-dds-bridge daemon during the cross-over.

Operational details: ORB configuration is read from corba.toml (we provide a CycloneDDS-compatible XML loader as well). TLS via rustls is the default for production; legacy SSL3/TLS1.0 are explicitly not supported (security policy choice — see dds-security for our reasoning). CSIv2 identity assertion is wired through the same SAML / GSSUP plumbing.

Performance: ZeroDDS' CORBA roundtrip is fastest-class. A 32-byte loopback roundtrip runs at ~17.8 µs p50 — on par with omniORB (the fastest established C++ ORB) and about 2× faster than TAO, 3.5× faster than JacORB, measured side-by-side against all three established C++/Java ORBs. Generated stubs cost under 1 µs over hand-marshalled code, and every IDL feature (struct, sequence, valuetype, any) roundtrips at roughly the same ~17 µs. TLS adds about 1.5 µs on an established SSLIOP connection.