...
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
...
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 service template is the basic file format that TOSCA defines, and almost all parts of it, including the topology template, are technically optional. Eclipse Winery manages "service templates" which include topology templates, and saves type definitions in other files (using the same format, but without topology templates). 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.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 development process.
Support for Components
Describe how components will be modeled in Winery and how they are expected to behave in a service catalog.
Flexible Service Catalogs
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 editingDescribe what service catalogs are and how they will be implemented in the context of TOSCA and Winery.
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.
...