1. Restructuring Proposal for TOSCA Files 1

2. Goals Separation of concerns: only expose what is needed to different roles in the creation of TOSCA templates Allow for more modular definitions of cloud applications Allow easy reuse of objects not coupled with a particular cloud application STE file should be able to be “bare minimum”, easy to define and comprehend by cloud application designers Type definitions should be in a file with a name not indicating “service template” 2

3. Service Template File Today ? * ? ? ? * ? ? 3

4. Splitting Service Template File ? * ? ? ? * ? ? 4 ? * ? ? ? * ? ? ? * ? ? * ? * ? * ?

5. The Definitions File This file is used to define objects that are independent from particular cloud applications – Requirement Types, Capability Types – Node Types, Node Type Implementations –.... These objects are typically defined for particular domains Vendors can define files and corresponding CSARs to deliver their implementations Customers can use them to define, deploy, manage their cloud apps based on them 5

6. The (New) Service Template File This file is used to define topology templates together with the associated plans only – Plans still can be referenced, i.e. defined in a separate file – may be defined for properties that are not exported to the boundary from within the topology Appropriate files are imported The required definitions and service templates are put into a CSAR and can be exchanged for setting up and managing the cloud application 6

7. Slightly Modified CSAR For consistency, a new subdirectory of the CSAR is assumed that holds all s required for the packaged Cloud Application Service-Template subdirectory is optional to allow packaging of service template independent artifacts 7 /TOSCA-Metadata /Definitions /Types /Plans /... /VirtualImages /JARs /Service-Template