Skip to main content

Crate zerodds_webdds_bridge

Crate zerodds_webdds_bridge 

Source
Expand description

zerodds-webdds-bridge — the DDS-WEB 1.0 gateway daemon zerodds-webdds-bridged.

Crate zerodds-webdds-bridge. Safety classification: STANDARD.

Spec: OMG Web-Enabled DDS 1.0, formal/2014-12-01. §7-§8.3 (the WebDDS object model + REST PSM) are implemented as a library in zerodds-web; §8.4 (the SIMPLE-WSDL-SOAP PSM) as a library in zerodds-soap. Neither crate implements a DdsBackend, an HTTP server, or a body codec — zerodds-web’s own crate doc says so in as many words (“HTTP-Server-Implementation + XML-Body-Serialization sind Caller-Layer”). This crate is that caller layer, and the one process that serves both PSMs — REST under /dds/rest1, SOAP under /soap/<binding>, WSDL under /wsdl/<binding> — because they are two platform mappings of the same object model (Spec §1.5), not two unrelated protocols.

§Modules

Modules§

contained_entities
Parses the contained-entity lists Spec §7.4.3.1/§7.4.3.2 (participantObjectRepresentation), §7.4.4.7/§7.4.4.8 (publisherObjectRepresentation) and §7.4.4.11/§7.4.4.12 (subscriberObjectRepresentation) allow: a DomainParticipant’s <publishers>/<subscribers>, a Publisher’s <data_writers>, a Subscriber’s <data_readers> — each a DDS-XTYPES XML sequence (<publishers><element>...</element>...</publishers>, XmlElement::sequence_elements), each element the same entity-shaped representation (<name>, optionally <qos>/ <qos_profile>) every other WebDDS entity uses.
daemon
zerodds-webdds-bridged daemon implementation.
dynamic_rpc
A zerodds_dcps::dds_type::DdsType for a DDS-RPC request/reply payload whose structure is only known at run time (synthesized from an IDL interface operation’s parameters, DDS-RPC 1.0 §7.5.1.1.4/§7.5.1.1.5) — the same problem zerodds_dcps::serialized_type::SerializedSample solves for a topic sample, and the same reason it gives for why its own DdsType::decode is a stub: “serialized samples require their topic support”, which zerodds_rpc::requester::Requester<TIn, TOut> / zerodds_rpc::replier::Replier<TIn, TOut> have no room for — they call TOut::decode(bytes) as a bare associated function, with no instance to carry a SerializedTypeSupport reference through.
dynxml
DDS-WEB §8.1/§8.2 XML data representation, converted through the type’s own DynamicType descriptor — never an opaque byte guess.
gateway
impl DdsBackend for Gateway — Spec §7.4, backed by zerodds-dcps’s public typed API.
http1
A hand-rolled HTTP/1.1 engine — no framework dependency, the same style as crates/monitor/src/server.rs and the accept loops of crates/coap-bridge/crates/websocket-bridge, extended to what those two don’t need: request/response bodies beyond one read() call, chunked Transfer-Encoding (RFC 7230 §4.1) on the request side, keep-alive (RFC 7230 §6.3), and a Content-Length DoS cap.
metadata
Spec §7.3.1 Root metadata operations that are not DCPS entities: create/update/delete/get_qos_library, create/delete/get_qos_profile, create/delete/get_type. A QosLibrary/QosProfile/registered Type is a named document the daemon stores and serves back — no DCPS round-trip, so it stays out of zerodds_web::DdsBackend (whose doc comment scopes it to §7.4 entity operations).
qos_update
Turns a REST/SOAP PUT body’s inline <qos> container into a live zerodds_dcps::qos value, for crate::gateway::Gateway’s update_* operations — Spec §7.4 update_topic/update_publisher/ update_subscriber/update_data_writer/update_data_reader/ update_participant, all of which “change the QoS” of the underlying DDS entity (the exact wording §7.4.4.4/§7.4.5.2/§7.4.6.2 use).
rest_service
REST-PSM request dispatch — Spec §8.3: HTTP method + URI (zerodds_web::rest::parse_route) to a crate::gateway::Gateway or crate::metadata::MetadataStore call, and the XML response (zerodds_web::status::http_status_for + Tab 6 element names) back.
rpc_dispatch
Dispatches a SOAP operation of a config-named IDL interface as a DDS-RPC request, and returns the reply — DDS-RPC 1.0 §7.5.1.1 Basic Service Mapping: one request/reply topic pair per interface (§7.4.3), a Call/Return union multiplexing every operation onto it (§7.5.1.1.6/§7.5.1.1.7), each operation’s reply case itself a Result union over dds::RETCODE_OK (carrying the Out struct) and its declared raises exceptions (§7.5.1.1.5). Reuses zerodds_lang_rules::adapter::interface for the operation model — the same one crate::wsdl_bridge builds the WSDL from (“WSDL and runtime from the same model”) — and that crate’s own operation_hash/exception_hash/in_struct_name/out_struct_name for the exact names/discriminators DDS-RPC 1.0 §7.5.1.1.2/§7.5.1.1.6 rule 5a fixes: the same functions emit::interface_rust’s generated Rust binding calls for the identical purpose, so a Requester built here and a Replier zerodds-idlc generate --lang rust wrote for the same interface compute the same topic name, the same discriminator per operation, and the same member layout — verified end to end in tests/soap_rpc_e2e.rs against exactly such a generated Replier (zerodds-rpc-rust-e2e’s own Calculator binding).
soap_service
SOAP-PSM request dispatch — Spec §8.4 (SIMPLE-WSDL-SOAP), sibling of crate::rest_service over the same crate::gateway::Gateway.
types_registry
Type resolution: turns a config-named IDL file, or a type a peer’s DcpsRuntime TypeLookup discovers, into a zerodds_dcps::serialized_type::SerializedTypeSupport plus the reflective zerodds_types::dynamic::DynamicType view the XML body converter (crate::dynxml) walks.
wsdl_bridge
The IDL-interface -> WSDL bridge plan §3 asks for: turns a config-named IDL interface into the Operation list zerodds_soap::wsdl::WsdlGenerator needs, reusing zerodds_lang_rules::adapter::interface (services, all_operations_flattened, in_struct_name, out_struct_name) rather than re-deriving DDS-RPC 1.0 §7.4.3’s operation model a third time.
xmlfields
A small flat-field reader for request bodies whose shape is a WebDDS object representation (Spec §8.3.4 Tab 6) — <topic>, <data_writer>, <waitset>, … — rather than a sample (which crate::dynxml converts through the type’s own descriptor). These bodies carry a handful of named scalar fields (and, for a waitset, one repeated list), so a full recursive DynamicType-driven decode is not needed — the field names are the ones Spec §8.3.4/§7.4 fix, not a user type’s.