This document describes the goals for development of the Edge Service Enabling Platform in 2023 and how we plan to work towards those goals. Specifically, we focus on the design and implementation of extensions to existing tools, and the technical/architectural decisions which we have made (and those which still need to be made).

Contents:

Motivations

In 2023 we want to start off prototyping an open tool which will help make designing edge services easier. The overall goals of this year's development are as follows:

Improve on existing tooling for edge service designers in a substantial way
Provide an open source implementation
Have something usable in a short (<1year) time frame

Even a relatively small piece of working code can be an anchor for further improvements. We also want to get our ideas "out there" to see what has traction (i.e. what looks useful to other developers and service designers). Hopefully, this can lead to productive partnerships and encourage ongoing development towards implementing the overall vision of the platform.

Focus

We've looked at the landscape of open tools and standards which could be applied to edge services, and have settled, at least for now, on OASIS TOSCA as a potential base technology. TOSCA is already in use in ONAP. It is a relatively mature standard, but still actively under development, and with several implementations. In particular, Eclipse Winery is an open source tool that provides graphical visualization and design tools using TOSCA data structures and formats. XOpera is another tool which provides support for deploying services described by TOSCA CSAR files.

TOSCA is a standard focused firstmost on cloud services. It seems likely that adapting it for use on the edge will require some work. On the other hand, it does provide a firm and extremely flexible foundation for modeling services. For this reason, and because of the availability of open source tooling mentioned above, it seems like a good fit for our project.

Our initial focus will be adding and extending functionality to Eclipse Winery in support of these goals:

Reducing complexity for people designing edge services by supporting flexible and reusable service designs (service catalogs) and abstractions of service subsystems (components)
Supporting developers of edge-oriented software and hardware offerings by making it possible to provide their products to service designers as service components, with the potential to be simply dropped into a service design with minimal configuration

How we plan to do this will be discussed below.

Basic Design

In this section we describe the approach we will be taking to implementing the new functionality in Eclipse Winery. Because this work is based on TOSCA technology and the existing Eclipse Winery implementation, the first section below discusses the fundamentals of TOSCA and Eclipse Winery to provide background for understanding the later sections on our proposed extensions.

TOSCA and Eclipse Winery Fundamentals

The basic elements of a TOSCA design are illustrated in the diagram below, taken from the TOSCA 1.0 specification. A service template contains all the type definitions required by the design plus a topology template. The topology template consists of a set of nodes (or node templates) and relationships (or relationship templates) between those nodes. The topology template represents the structure of the service as it will be deployed. The nodes are abstract functional blocks, representing such things as software applications, libraries, virtual machines (or other "compute" nodes), and so on. Relationships describe dependencies between nodes, which can encompass network connections and APIs, and also such things as which host runs a given piece of software.

Diagram from http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html

Relationships connect a requirement from one node to a capability on another. All of these entities: nodes, requirements, capabilities, and requirements, have types which can define their properties, attributes, and behaviors (i.e. scripts executed when certain events, such as starting the service, occur).

Eclipse Winery supports creating and editing the various type entities used to create service templates through a graphical interface. It also provides a visual topology template editor where the nodes and relationships can be manipulated, as shown below. The rectangles are nodes, and the arrows are relationships between those nodes. On the left, a palette of node types is available to drag and drop into the topology template.

Screen capture of the Eclipse Winery topology template editor

The various pieces of data associated with a node (properties, requirements, capabilities, and so on) can be accessed by enabling them on the toolbar along the top and opening the resulting panels in nodes as shown below.

A screen capture showing properties, requirements, and capabilities editing

When a relationship is clicked, an editing panel will appear on the right allowing modification of the data for the relationship.

The panel for editing relationship data

It is possible to open a separate window or tab showing, and allowing editing of, the type definition (e.g. the node type or relationship type) underlying an element of the topology template by clicking on the type name shown under the name of the element (the type names are highlighted in blue in the above screenshots), or in the type field of the element editing panel, in the case of relationships.

An example of the interface for editing a relationship type (other types present similar user interfaces)

Node Substitution

TOSCA has a concept of node substitution, where a node in a service template can be programatically replaced by a group of nodes and relationships (effectively a different service template, but one which defines substitution mappings, external interfaces for the substitution service template that map to the capabilities and relationships of the node they replace). This closely resembles the idea of components which will be described below. Where possible, we hope to make use of the syntax and concepts already developed as part of node substitution to implement support for components. We may even find that node substitution with only minor extensions can be applied directly to support components. Eclipse Winery does not directly support creating or manipulating substitutions at this time. This is an area for ongoing investigation as part of this year's work.

Eclipse Winery File Structures

The service template in TOSCA is the basic file format, and almost all parts of it are technically optional, including the topology template. Eclipse Winery manages "service templates" which include topology templates, and saves type definitions in other files (using the same format, but without topology templates). Note, also, that internally Eclipse Winery stores all these data structures as flat files, by default in the YAML format specified by TOSCA.

In order to keep the service template file from becoming unmanagably large and complex, it can include groups of types by reference from other files. Every node type and relationship type is managed as a separate file in Eclipse Winery and included in the service template by reference. When a service template is packaged in a CSAR (cloud service archive) file, all the files referenced by the service template are also included in the archive.

Support for Components

One of the major hurdles we have identified for creating edge services, is the increasing number and complexity of technologies which must be integrated to create such a service. To address this complexity, we believe design tools like Eclipse Winery (and the TOSCA standard underlying it) are essential. They make it possible for a user to easily visualize and manipulate the parts of a service and their interdependencies. However, we believe there is room for improvement in these tools. We want to make it possible to encapsulate complex groups of nodes and relationships into a simple to understand package, which we call a component, while preserving the ability to open up the component and access the internal complexity when the need arises (and the expertise is available). We also believe arranging the nodes and relationships of a service into components provides an opportunity to make these groups reusable in other designs, and to document them so they are easier for service designers (and operators) to understand and use in their services.

A "database" component which contains a more detailed representation of the nodes and relationships within it, from https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#_Toc26969430

We also want to support the nesting of components. That is, a component may be made up of not just nodes, but other components, in this way simplifying the logical structure of the component's design, making it easier to build, maintain, and customize, without losing the ability to "dig deeper" into the sub-components and their implementation details when necessary.

Implementation

A component has a topology template, so we will base the management and editing of components on the service template management and topology editor functions that exist in Winery already. We plan to present the components to the user as a new top-level class of entities alongside the existing service templates, node types and so on.

A mockup of the component list UI

Editing a component's topology should be the same as editing a service template, with the exception that other components will appear in the "node" palette so that they can be included as sub-components. Also, an interface will be required for configuring the mapping of "external" interfaces (properties, capabilities, and requirements) to those of nodes or sub-components. We hope to provide a visual way to configure these mappings from within the topology editor, e.g. by dragging elements to an external connection space.

Flexible Service Catalogs

A service catalog is a complete design for a service, made up of all the necessary components to implement that service. Ideally, a service catalog provides flexibility and configurability, in the form of input parameters, scaling behaviors and so on. In this iteration, first we will focus simply on making the it possible to create a service catalog from components and, if time and resources allow, implement features that improve the usability of service catalogs, e.g. improved searching. We also hope to implement visualization improvements that components make possible, allowing the user to change the level of detail from a simple block diagram to a full breakdown of all the nodes and relationships in the design, or levels inbetween.

We are also planning to investigate whether implementing more advanced template mechanisms (e.g. introducing template processing with an engine like Jinja) might allow service designers to create more flexible designs which can be reused in different deployments.

Implementation

Service catalogs are very similar to existing service templates in Eclipse Winery, at least in the initial implementation. The main difference is that they may contain components as well as (or instead of) nodes. There may be further differences introduced in the future, coming from ideas like the template engine mentioned above, so we plan to implement service catalogs as a separate class of entity based on the existing functionality for service templates in Eclipse Winery. On the other hand, future development may consider merging service catalog and components into the service template as more of a type or optional set of features that can be used for service template editing.

Future Development

After the initial pass described above, we hope to continue expanding on the base we will establish this year. A few of the directions we are already considering are described here.

Deploying Services

The initial focus of our work is on improving the tools for design of services. The other half of the process, deploying those services, could be a focus for upcoming work. XOpera has already been mentioned as an orchestration/deployment tool. Even XOpera will probably require some work to integrate our changes, or at the very least testing and verification. We would also like to make our approach as agnostic as possible, supporting multiple tools, possibly through a plugin framework, and even potentially more than one orchestration tool in the same service. Service deployment and management has seen more work in the open source community than service design, so there are many potential tools to choose from.

Our next steps should include selecting one or more orchestration tools to integrate our extensions with, and determining the scope of the development effort required.

Usability Improvements

In our investigation of Eclipse Winery we have encountered several areas where there are potential usability improvements that could be made. Some examples include:

improving search and filtering of node and service template lists
improving the UX for connecting nodes with relationships (e.g. visually identifying which nodes could satisfy a given requirement)
improving the clarity of the connection between input and output parameters of service templates, nodes, and node types

We should evaluate these improvements for inclusion in our next development phase, or even in the current phase if extra resources are available.

Component Connection UX

One area that makes both component and service design complex is understanding the connections between nodes and/or components (the requirements, capabilities, and relationships, in TOSCA terminology). In the mid-to-long term we would like to make setting up these connections easier to understand and possibly automate (or at least automatically suggest) connectivity between components during the service design process. A first step in this direction might be to make it possible to document connection points and refer to that documentation within the tools. It should be possible eventually for Eclipse Winery to perform automatic discovery of compatible interfaces, search for components (or nodes, or node types) that satisfy requirements (or might require a component's capabilities), and offer up selections of components and relationship types when necessary.

Because of the scope of this topic, it will probably need to be broken down into several phases. In the next step of development we should evaluate what parts will fit within the limits of available time and resources, and estimate a timeline for implementing them.

Browser not supported