Azure IoT Operations dataflow graphs<\/a> make this concrete.\nBuilt on the Timely dataflow computational model, dataflow graphs execute WASM modules as streaming dataflow operators at the edge: map, filter, branch, accumulate, concatenate, and delay.\nProcessing pipelines are defined in YAML, compiled modules are pushed to a container registry as OCI artifacts, and deployment happens through Azure Resource Manager.<\/p>\n [!IMPORTANT]\nIn this post, dataflow operator<\/em> is the graph role, WASM module<\/em> the deployable artifact, and component<\/em> the WIT composition unit.<\/p><\/blockquote>\n WebAssembly defines a portable binary instruction format for a stack-based virtual machine.\nSource languages (Rust, C, C++, Go, Python, and others) compile to a compact Three enforcement mechanisms make WebAssembly suitable for running untrusted or multi-team dataflow operator code on production infrastructure.<\/p>\n Control-flow integrity validates the type signature of every function call at load time.\nIndirect calls through function tables are type-checked again at runtime, preventing redirection to arbitrary functions.<\/p>\n Memory safety comes from linear memory: a contiguous, bounds-checked byte array that the module reads and writes through indexed instructions. Every access is validated against the memory size, and out-of-bounds reads or writes trigger an immediate trap. The call stack is separate from linear memory and inaccessible to user code, eliminating a common class of vulnerabilities like stack buffer overflows found in native code.<\/p>\n Traps provide an immediate, non-recoverable termination path for any violation: out-of-bounds access, division by zero, integer overflow in conversion, unreachable code, or stack exhaustion. The runtime never allows a faulting module to continue executing.<\/p>\n For edge data processing, these guarantees are decisive. Untrusted or team-contributed dataflow operator code runs on production infrastructure knowing that a misbehaving module cannot corrupt host memory, hijack control flow, or access resources it has not been granted.<\/p>\n Core WebAssembly modules have a critical limitation at their boundaries.\nThe only types a module can import or export are numeric: The Component Model<\/a> solves this by introducing components: self-describing WebAssembly binaries that interact through typed interfaces instead of shared memory.\nEach component owns an isolated linear memory region.\nThere is no shared address space between components; the only ways a component can interact with anything outside itself are by having its exports called or by calling its imports.\nA Canonical ABI handles lifting and lowering between rich types (strings, records, lists, variants) and the numeric values core modules understand, invisible to the component author.<\/p>\n WIT<\/a> (WebAssembly Interface Types) is the IDL that defines those interfaces. An interface<\/em> groups related types and functions. A world<\/em> describes the complete set of imports and exports for a component. If an interface is not listed in a component’s world, the component has no access to it: the sandbox is enforced structurally, not at runtime.<\/p>\n WASI Preview 2<\/a> builds on WIT to provide standardized system APIs (clocks, filesystem, sockets, random). Where WASI Preview 1 exposed a monolithic, POSIX-like API with file descriptors and no component model support, Preview 2 replaces that with fine-grained, composable WIT interfaces and adds async primitives through streams and futures. This solution targets WASI P2 through the Four qualities make this stack valuable for dataflow operators:<\/p>\n The official AIO documentation<\/a> covers monolithic operator development in Rust and Python, where a single module owns SDK integration and business logic together. This post builds on that foundation with a second pattern: composed operators that use WIT interfaces to separate SDK integration from business logic across independently developed and deployed components. Composition is the key enabler for multi-team scenarios, where one team maintains the platform integration layer and another ships domain-specific processing rules as sealed binaries, without sharing source code, build systems, or even programming languages.<\/p>\n The monolithic pattern places all logic in a single crate: data type definitions, SDK integration, and business rules coexist in one module. The filter operator reads threshold parameters at initialization, then checks each incoming temperature measurement against bounds:<\/p>\n The This pattern works well when one team owns everything. The limitation surfaces when business logic is proprietary or developed by a separate team, since every change to the processing rules requires access to the AIO SDK integration code.<\/p>\n The composed pattern splits the dataflow operator into two independently compiled components connected by a WIT contract. The map operator handles AIO SDK integration, while the custom-provider implements business logic behind a clean interface boundary.<\/p>\n The WIT contract defines the composition surface:<\/p>\n Three types define the contract. Two worlds reference the same interface from opposite directions. The The provider operates entirely on When Both dataflow operator patterns target the [!TIP]\nThe Dataflow graphs separate the processing pipeline description from the infrastructure binding.\nA graph definition is a YAML file validated against a JSON schema<\/a>. It declares operations (source, filter, map, sink), their connections, module references with semantic version tags, and runtime configuration parameters.\nThe graph definition uses abstract [!TIP]\nKeep the graph definition environment-agnostic. Bind topics, endpoints, and registry access in the wrapping resource, not in the operator.<\/p><\/blockquote>\n A separate dataflow graph resource, deployed through Azure Resource Manager or a Kubernetes manifest, wraps the graph definition and connects those abstract operations to concrete MQTT topics, Kafka endpoints, or OpenTelemetry collectors.\nThis separation is a critical design principle: the same graph definition deploys across development, staging, and production environments without rebuilding any WASM modules.\nThe runtime pulls the graph definition to learn the pipeline structure, then pulls each referenced WASM module by its artifact tag (e.g., Both graph definitions and compiled WASM modules are stored in a container registry as OCI (Open Container Initiative) artifacts.\nThe ORAS<\/a> CLI handles pushing, using distinct media types so the registry and runtime can distinguish graph YAML from WASM binaries.\nThe azure-edge-extensions-aio-dataflow-graphs<\/a> sample repository provides an end-to-end pipeline with WebAssembly provides the safety guarantees that edge data processing demands: a sandboxed execution environment with control-flow integrity, bounds-checked memory, and immediate trapping on violations.\nThe Component Model extends those guarantees with composability, enabling independently developed components to fuse through type-safe WIT interfaces into single shipping binaries.\nWASI Preview 2 standardizes the system APIs these components use, while the The two-pattern approach proved effective in practice: monolithic dataflow operators keep simple logic self-contained, while the WIT composition boundary lets separate teams contribute dataflow operators independently without exposing SDK internals.\nThe graph definition layer adds deployment flexibility by decoupling pipeline structure from infrastructure binding, enabling the same dataflow operators and graphs to move across environments without rebuilds.<\/p>\n Azure IoT Operations dataflow graphs bring the WebAssembly standards stack to production with two dataflow operator patterns: monolithic for self-contained logic, and composed for cross-team separation of concerns.\nThe combination of memory-safe sandboxing, typed composition through WIT, and environment-agnostic graph definitions delivers a practical foundation for safe, portable edge data processing.<\/p>\n The full implementation is available in the edge-ai project<\/a>, the sample repository<\/a> covers the end-to-end pipeline, and the AIO dataflow graphs documentation<\/a> provides the official reference.<\/p>\n","protected":false},"excerpt":{"rendered":" Safe, composable dataflow operators for Azure IoT Operations, built as WASM modules using the Component Model, WIT interfaces, and WASI Preview 2.<\/p>\n","protected":false},"author":62975,"featured_media":16650,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,18],"tags":[3539,3653,3652,3655,3651,3650,3654],"class_list":["post-16647","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cse","category-iot","tag-azure-iot-operations","tag-component-model","tag-edge-computing","tag-wasi","tag-wasm","tag-webassembly","tag-wit"],"acf":[],"blog_post_summary":" Safe, composable dataflow operators for Azure IoT Operations, built as WASM modules using the Component Model, WIT interfaces, and WASI Preview 2.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts\/16647","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/users\/62975"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/comments?post=16647"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts\/16647\/revisions"}],"predecessor-version":[{"id":16649,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts\/16647\/revisions\/16649"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/media\/16650"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/media?parent=16647"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/categories?post=16647"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/tags?post=16647"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"WebAssembly](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2026\/05\/wasm-tech-stack.svg\")
<\/p>\nThe Journey: Our Approach and Solution<\/h2>\n
Why WASM Fits Dataflow Operators<\/h3>\n
.wasm<\/code> binary that any conforming runtime can execute at near-native speed.\nThe AIO WASM module development guide<\/a> officially supports Rust and Python; all examples in this post use Rust.\nThe format makes minimal assumptions about the host and does not specify any APIs or system calls, only an import mechanism where the embedding environment provides the functions a module needs.<\/p>\nThe Component Model and WIT<\/h3>\n
i32<\/code>, i64<\/code>, f32<\/code>, and f64<\/code>.\nPassing a string requires writing bytes into linear memory, handing the offset and length as two i32<\/code> values, and trusting the caller to read from the correct region.\nRecords, lists, variants, and other compound types demand the same manual memory-offset coordination on both sides.<\/p>\nwasm32-wasip2<\/code> Rust compilation target. A component that never imports wasi-filesystem<\/code> cannot access files, regardless of what the underlying host runtime supports.<\/p>\n\n
wasm-tools compose<\/code> merges both at build time without either side accessing the other’s source code.<\/li>\n<\/ul>\nTwo Dataflow Operator Patterns<\/h3>\n
Pattern 1: Monolithic Dataflow Operators<\/h4>\n
#[filter_operator(init = \"filter_temperature_init\")]\r\nfn filter_temperature(input: DataModel) -> Result<bool, Error> {\r\n let payload = match input {\r\n DataModel::Message(Message {\r\n payload: BufferOrBytes::Buffer(buffer), ..\r\n }) => buffer.read(),\r\n DataModel::Message(Message {\r\n payload: BufferOrBytes::Bytes(bytes), ..\r\n }) => bytes,\r\n _ => panic!(\"Unexpected input type\"),\r\n };\r\n\r\n let measurement: Measurement = serde_json::from_slice(&payload).unwrap();\r\n Ok(matches!(measurement, Measurement::Temperature(t)\r\n if t.value.is_some_and(|v| v < *UPPER_BOUND.get().unwrap()\r\n && v > *LOWER_BOUND.get().unwrap())))\r\n}<\/code><\/pre>\n#[filter_operator]<\/code> procedural macro generates the WASM exports that the AIO runtime expects. The init function reads threshold parameters from the graph definition’s moduleConfigurations<\/code> section. The filter function extracts raw bytes from the DataModel<\/code>, deserializes JSON, and returns true<\/code> to pass the message downstream or false<\/code> to discard it.<\/p>\nPattern 2: Composed Dataflow Operators via WIT<\/h4>\n
package map:custom;\r\n\r\ninterface types {\r\n record module-configuration {\r\n properties: list<tuple<string, string>>,\r\n }\r\n variant error {\r\n invalid-argument(string),\r\n internal(string),\r\n }\r\n record data-model {\r\n payload: list<u8>,\r\n }\r\n}\r\n\r\ninterface custom {\r\n use types.{data-model, error, module-configuration};\r\n process: func(message: data-model) -> result<data-model, error>;\r\n init: func(configuration: module-configuration) -> bool;\r\n}\r\n\r\nworld custom-impl { import custom; }\r\nworld custom-provider { export custom; }<\/code><\/pre>\nmodule-configuration<\/code> carries key-value pairs from the graph definition’s runtime parameters. error<\/code> is a variant with two cases for structured error reporting. data-model<\/code> wraps an opaque list<u8><\/code> payload, keeping the interface decoupled from any particular serialization format.<\/p>\ncustom-impl<\/code> world imports the interface, generating call stubs that the map operator uses to invoke process()<\/code> and init()<\/code>. The custom-provider<\/code> world exports the interface, generating a Guest<\/code> trait that the provider must implement.<\/p>\n![\"WIT](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2026\/05\/wasm-composition.svg\")
<\/p>\npayload: list<u8><\/code> from the WIT contract. It never encounters AIO SDK types like Message<\/code>, BufferOrBytes<\/code>, or HybridLogicalClock<\/code>. This separation means the team can ship the custom-provider as a sealed binary, swap it for a different implementation without modifying the map operator, or write it in any language with Component Model toolchain support.<\/p>\nwasm-tools compose<\/code> fuses the two compiled components, it matches the map’s imports against the provider’s exports, producing a single artifact with all dependencies resolved internally.<\/p>\nFrom Source to Streaming Pipeline<\/h3>\n
Compilation and Composition<\/h4>\n
wasm32-wasip2<\/code> Rust compilation target, which directs the compiler to emit Component Model binaries linked against WASI Preview 2 interfaces.\nMonolithic dataflow operators compile to a single WASM module ready for deployment.\nComposed dataflow operators require an additional step: the wasm-tools<\/a> CLI from the Bytecode Alliance fuses the two independently compiled components into one artifact.\nThe compose<\/code> subcommand inspects each component’s interface metadata, matches the map operator’s import custom<\/code> against the custom-provider’s export custom<\/code>, and produces a single component with all internal dependencies resolved.\nThe result is indistinguishable from a monolithic module at deployment time, but preserves the clean development-time separation between SDK integration and business logic.<\/p>\nwasm-tools compose<\/code> subcommand is deprecated in favor of WAC<\/a> (WebAssembly Composition), which provides the same interface-matching with additional features like dependency graphs and configuration files.<\/p><\/blockquote>\nGraph Definitions and Deployment<\/h4>\n
source<\/code> and sink<\/code> names without specifying concrete endpoints.<\/p>\nfilter:1.0.0<\/code>), initializes modules with their configuration parameters, and begins streaming data through the graph.<\/p>\n![\"Dataflow](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2026\/05\/wasm-pipeline.svg\")
<\/p>\nmake<\/code> targets covering cluster provisioning, ACR setup, role assignments, registry endpoint configuration, module compilation, OCI push, graph deployment, and testing.\nThe WASM module development guide<\/a> and the graph definition documentation<\/a> cover the full lifecycle in detail.<\/p>\nThe Destination: Outcomes and Learnings<\/h2>\n
wasm32-wasip2<\/code> compilation target and wasm-tools<\/code> CLI provide the concrete toolchain.<\/p>\nConclusion<\/h2>\n
Call to Action<\/h2>\n