weeve Modules
Edge applications are composed of modules
As described in the Edge Applications section, edge applications consist of modules, which are categorized into three different types; Input, Processing and Output. Modules consist of 2 aspects;
- 1.A module is a docker container with a standard communication interface
- 2.A module is the atomic building block of an edge application and has metadata such that the platform can orchestrate it
Figure 1 below presents an abstract representation of a Module. The module, upon instantiation, is running within an edge application (a containerized module). The module, as a dockerized process, can be further broken down into 3 main components;
- 1.A web server, listening to incoming traffic from previous modules on a standardized path
- 2.The module logic, written by the module developer
- 3.The logic for forwarding the transformed data to a further module, or an external endpoint
In order to run the module, the weeve platform uses a configuration file to tie together the static assets.
Module configuration details
The configuration file holds basic metadata for that module, as well as configuration parameters for running the module. Additionally, the configuration file points to externally stored assets. Most importantly, the configuration file holds the URI for the container image, which is held in a container registry. Additionally, user interface affordances are held in the configuration file, including the icon URI.
Most importantly, the standard prescribes the communications interface between modules, as briefly described in the Edge Applications section.
Secondly, the standard prescribes the configuration of the modules such that they can be instantiated in the context of an edge application.
Thirdly, the standard describes implementation details for metadata, icons, and best practices for a project layout.
With the minimal standard met, the developer is free to implement the module logic as they deem fit.
Detailed tutorials for creating a module, including boilerplate code, are found in the guides section.
The latest specifications can be provided upon request.
The benefit of the standard interface is that modules can be used for many different solutions. In order to share modules, the module catalogue is published to browse for modules. The technical implementation of sharing modules depends on the module registry. These concepts are described in the next section.
Last modified 1yr ago