...
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
...