Restructuring Proposal for TOSCA Files 1

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

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

Splitting Service Template File ? * ? ? ? * ? ? 4 ? * ? ? ? * ? ? ? * ? ? * ? * ? * ? 1 st Proposal as of Oct 4th

Refactored File ? * ? ? ? * ? ? 5 NEW Proposal as of Oct 11th ? * ? ? ? * ? ? ? ? ? ? ? ? ? * ? ? ? * ? ? ? ? ? ? ? ?

Refactored File (ALTERNATIVE) ? * ? ? ? * ? ? 6 NEW Proposal as of Oct 11th ? * ? ( ? ? | | | | | | | | )+ ? * ? ( ? ? | | | | | | | | )+ Removed “container” elements (e.g. NodeTypes). Instead, choice of elements which allows definition of desired elements in an arbitrary order. Removed “container” elements (e.g. NodeTypes). Instead, choice of elements which allows definition of desired elements in an arbitrary order.

The Definitions File A TOSCA Definitions file (root element ) is used as a top-level container for holding all kinds of element definitions according to the TOSCA specification – ServiceTemplate definitions – NodeType definitions – RelationshipType definition – … etc. The approach allows for defining all elements required for a Cloud application in one single file, or it allows for splitting definitions into separate files – In case of separate files, definitions from one file can be imported into other files via the statement Recommended best practices – Split all kinds of type definitions (Node Types etc.) into a separate file for re-use and separation of concerns – Define the ServiceTemplate in a separate file – Use one file per ServiceTemplate 7

Example * <RelationshipTemplate id="hostedOn" type="my:HostedOn"> * <RelationshipTemplate id="hostedOn" type="my:HostedOn">

Slightly Modified CSAR For consistency, a new subdirectory of the CSAR is assumed that holds all TOSCA Definitions required for the packaged Cloud Application – Definitions can include ServiceTemplate definitions – Definitions can also include type definitions (Node Types, Relationship Types, etc.) and implementations 9 /TOSCA-Metadata /TOSCA-Definitions /Types /Plans /... /VirtualImages /JARs

End of presentation 10