Marine runs multi-module WebAssembly applications with interface-types and shared-nothing linking scheme
Go to file
2022-12-06 16:52:49 +03:00
.cargo ci: Add marine e2e (#230) 2022-11-21 13:17:18 +02:00
.github Move non-relevant code from Marine repo into FluenceJS (#235) 2022-12-06 09:50:07 +03:00
core chore(master): release (#245) 2022-12-06 16:52:49 +03:00
crates chore(master): release (#245) 2022-12-06 16:52:49 +03:00
docs Add developer notes about PR reviewing (#157) 2022-04-26 16:20:02 +03:00
examples chore(build): fix clippy warnings (#213) 2022-09-19 19:13:38 +03:00
images update stack png (#109) 2021-09-04 13:39:39 +03:00
marine chore(master): release (#245) 2022-12-06 16:52:49 +03:00
marine-js Move non-relevant code from Marine repo into FluenceJS (#235) 2022-12-06 09:50:07 +03:00
tools chore(master): release (#245) 2022-12-06 16:52:49 +03:00
.gitignore chore(deps): update all non-major rust dependencies (#211) 2022-11-28 18:37:07 +03:00
.rustfmt.toml add rustfmt config 2020-06-03 23:08:26 +03:00
Cargo.lock chore(master): release (#245) 2022-12-06 16:52:49 +03:00
Cargo.toml Update marine-js public interface. Replace any with generic JSON types. Doing se\desalinization work insine marine-js (#207) 2022-09-09 17:28:30 +03:00
CHANGELOG.md Rename to marine: part 2 (#84) 2021-05-11 15:44:11 +03:00
LICENSE add license and readme 2020-05-02 12:44:49 +03:00
README.md update links (#225) 2022-10-26 13:09:13 +03:00
rust-toolchain.toml chore(CI): add rust-toolchain file, use better CI actions for rust (#214) 2022-09-16 16:10:02 +03:00

Marine

marine version on crates.io

Marine is a modern general purpose Wasm runtime based on the component model capable of running multi-module Wasm applications, aka services, with interface-types and a shared-nothing linking scheme. This execution model is well suited for a variety of scenarios and especially applicable to implementations following the entity component system (ECS) pattern or plugin-based architectures.

Fluence peers, such as Fluence Rust node, include Marine to execute the hosted Wasm services composed with Aqua.

Motivational example

To illustrate the capabilities of Marine, let's have a look at a multi-module Wasm service as implemented in this example.

cd into the examples/motivational-example directory and have a look at the shrek/src/main.rs file:

// examples/motivational-example/shrek/src/main.rs
use marine_rs_sdk::marine;

fn main() {}

#[marine]
pub fn greeting(name: &str) -> Vec<String> {
    let donkey_greeting = donkey::greeting(name);         // 1
    let shrek_greeting = format!("Shrek: hi, {}", name);  // 2
    
    vec![shrek_greeting, donkey_greeting]                 
}

mod donkey {                                               // 3
    use super::*;

    #[marine]
    #[link(wasm_import_module = "donkey")]                 // 4
    extern "C" {
        pub fn greeting(name: &str) -> String;
    }
}

In this Marine (Wasm) module (and namespace) shrek, we declare a function greeting that creates a donkey_greeting (1) from the donkey module's (3)greeting function, which itself is dependent on importing the donkey Wasm module with Rust's FFI link (4) from examples/motivational-example/donkey/src/main.rs (see below).

// examples/motivational-example/donkey/src/main.rs
use marine_rs_sdk::marine;

fn main() {}

#[marine]
pub fn greeting(name: &str) -> String {
    format!("Donkey: hi, {}", name)
}

In summary, our example is comprised of two independent Wasm modules, shrek and donkey, and illustrates how to link one module into another one, i.e., use the donkey module in the shrek module. Please note that the shrek module is called a facade module following the facade pattern and there can only be one facade module per service.

Make sure you have the Marine tools installed and compile the donkey and shrek, respectively, which we can do with the build.sh script:

$> ./build.sh

which creates two independent Wasm modules that are placed in the artifact directory:

$> ls artifacts
donkey.wasm    shrek.wasm

Now that we have our modules, we can explore them with the Marine REPL. Note that we use the Config.toml file to help out the REPL by providing the module location and names. Once we got the REPL up and running, we can interact with both modules and, as expected, the shrek module is successfully able to access the donkey module's exposed functions.

$> marine mrepl Config.toml
...
1> interfaces
Loaded modules interface:

shrek:
  fn greeting(name: string) -> []string
donkey:
  fn greeting(name: string) -> string

2> call donkey greeting "no link module"
result: String("Donkey: hi, no link module")
 elapsed time: 42.985µs

3> call donkey greeting "facade with link module"
result: String("Donkey: hi, facade with link module")
 elapsed time: 39.25µs

4> q

Looks like everything is in order and the modules are ready for deployment to the network and composition with Aqua.

Repository structure

  • REPL - REPL intended to test Marine Wasm modules
  • CLI - CLI intended to build and extract some info from Marine Wasm modules
  • fluence-app-service - Fluence Application Service layer provides basic API for service running
  • fluence-faas - Fluence FaaS layer provides host closures, IT<->JSON conversion, logger, config handling and other
  • runtime - runtime layer provides basic functionality for loading, unloading and calling modules
  • marine-js - web runtime layer aim to run Marine in browser
  • examples - several Marine examples used mostly for tests
  • it-generator - generator of IT
  • it-interfaces - handy structure for interface types handling
  • it-json-serde - crate for conversion between IT and JSON
  • min-it-version - keeps minimal supported versions of IT and SDK by runtime
  • module-info-parser - parser of module manifest and sdk version
  • module-interface - parser of module IT
  • utils - some utility functions and consts

References