...
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 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.
...
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, however, 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, howevercoming 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.
...