Proposal for using WebAssembly Interface Types (WIT) to specify core uProtocol types and interfaces

[PLeVasseur]

Overview

WebAssembly Interface Types (WIT) seem to offer a nice level of expressiveness in how to specify types and interfaces for communication between WebAssembly components.

A big benefit they bring to Eclipse uProtocol as we've down-scoped some language implementations is the ability to offer a fairly out-of-the-box working experience for implementers that would like to use other languages.

Another benefit is that there are some initial talks going round that WIT could offer a nice bridge into the AUTOSAR world.

Scope

I'd like to use this as a tracking issue to break the work down and potentially spin off more issues depending on work sizing.

Scope of Eclipse uProtocol

Summarizing, the scope will be the uP-L1 UTransport interface and then the types used within that interface:

• uP-L1 / UTransport
• UMessage
• UAttributes (and its contents)
• UStatus

Scope w/r/t WebAssembly

From what I'm led to understand, host / runtime support does not exist yet for some useful async primitives in WASI preview 3, but guest support does, so I propose:

• WIT definitions supplied for the above
• a feature branch for up-rust which can build using those, not 100% fully integrated but showing the Rust code will compile
  • integrating and using in up-rust should be another issue
• a parallel path underneath up-core-api for the WIT definitions like so:

root/
  up-core-api/
    uprotocol/ <- existing
    wit/
      uprotocol/
        v1/
          umessage.wit
          ... and others ...

Diagram of our vision

Long story short: the ability to write a transport implementation in a single language and benefit from using it from other languages, e.g. C++, Java, Python. This can reduce the maintenance required to update and evolve uProtocol.

Welcome feedback!

classDiagram
    class my-cpp-uservice {
        +up-transport-zenoh transport
    }
    my-cpp-uservice *-- up-transport-zenoh
    my-cpp-uservice *-- up-core-api-cpp
    class my-rust-uservice {
        +up-transport-zenoh transport
    }
    my-rust-uservice *-- up-transport-zenoh
    my-rust-uservice *-- up-core-api-rust
    class up-transport-zenoh {
        +UStatus new()
        +UStatus register-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus unregister-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus send(message: UMessage)
        +UStatus receive(source: UUri, sink: UUri)
    }
    up-transport-zenoh *-- up-rust
    note for up-transport-zenoh "Contains concrete implementation of UTransport.<br>Exposed as a WebAssembly Component<br>to allow for usage in transports written in<br> various languages, e.g. Rust, C++, Python"
    class up-rust {
        +UStatus
        +UUri
        +UMessage
        +UListener
        +UStatus register-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus unregister-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus send(message: UMessage)
        +UStatus receive(source: UUri, sink: UUri)
    }
    up-rust *-- up-core-api-rust
    class up-core-api-rust {
        +UStatus
        +UUri
        +UMessage
        +UListener
        +UStatus register-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus unregister-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus send(message: UMessage)
        +UStatus receive(source: UUri, sink: UUri)
    }
    up-core-api-rust *-- up-core-api-wit
    note for up-core-api-rust "Contains WIT bindings to Rust for<br>core (e.g. UUri) and UTransport.<br>No implementation done here.<br>Note: may be able to be merged<br>into up-rust, but broken out here<br>for illustration"
    class up-core-api-cpp {
        +UStatus
        +UUri
        +UMessage
        +UListener
        +UStatus register-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus unregister-listener(source: UUri, sink: UUri, listener: UListener)
        +UStatus send(message: UMessage)
        +UStatus receive(source: UUri, sink: UUri)
    }
    up-core-api-cpp *-- up-core-api-wit
    note for up-core-api-cpp "Contains WIT bindings to C++ for<br>core (e.g. UUri) and UTransport.<br>No implementation done here."
    note for up-core-api-cpp "<b>Question</b>: Do we still need a up-cpp<br>to build up the common functionality<br>or should we expose that via up-rust<br>as a component as well?"
    class up-core-api-wit {
        
    }
    note for up-core-api-wit "Contains WIT definitions for uProtocol.<br>Likely inside of up-spec repo."

Early proof of concept work

• up-core-api-wit - core data types and uP-L1 UTransport interface
• utransport-mock-with-wit - a stubbed implementation showing it’s possible to implement the UTransport trait

Todos

• [ ] Check into how mature WASI p3 is for other languages of interest -- C++, Python, Java
• [ ] Is the WIT in-memory representation a stable ABI across devices?
• [ ] Is it more correct / in-line with WASI p3 to use async or return a future in the UTransport interface?
• [ ] How should we represent the UListener which we register with? a resource or interface?
• [x] For those protocols which don't work out of the box within a WASM sandbox (e.g. Eclipse Zenoh) can we somehow have an escape hatch for the transport implementation? (see below under A WebAssembly Component using native code for UTransports)

A WebAssembly Component using native code for UTransports, exposing WIT bindings

Amusingly ChatGPT when using its Project feature does not appear to allow sharing of chats...?

So since that's that case, here's a huge image for it:

Seems possible, would need to be explored

Contributions

Contributions very welcome! I'm new to WebAssembly so happy to have others contribute whether writing the spec / WIT or reviewing.

If you'd like to suggest something here on this issue that's welcome, as is filing issues / PRs against the two repos above.

[PLeVasseur]

Discussed with @evshary in the #uprotocol-zenoh channel and found that Eclipse Zenoh doesn't work out of the box within a WASM sandbox.

Gave rise to documenting a new todo above:

• [ ] For those protocols which don't work out of the box within a WASM sandbox (e.g. Eclipse Zenoh) can we somehow have an escape hatch for the transport implementation?