TOSCA Metamodel Changes for Requirements and Capabilities with Primer Example Discussion

1. TOSCA Metamodel Changes for Requirements and Capabilitieswith Primer Example Discussion Proposal by CA Technologies, IBM, SAP, Vnomic

2. SugarCRM Service Model SugarCRM Service WebServerTier DBServerTier Port 80 HTTP EndPoint Apache Web Server MySQL Required EndPoint Provided EndPoint HTTP Client SugarCRM App SugarCRM DB Typed Connector PHP Module DocumentRoot:/SugarCRM HTTP Content EndPoint Database Server EndPoint propagates client credentials, DB Name, host and port client EndPoint (Web Server)

3. Containment Hierarchy Application Container Tier Tier VM VM OS OS Web Server DB SugarCRM App SugarCRM DB Requires PHP Module

4. hostedOn Relationship Apache Web Server SugarCRM App hostedOn Req Constraints: version: >= 2

5. Requirements and Capabilities Semantics • Strongly typed hostedOn relationship • References are required to represent this semantic concisely • Requires/Provides • One node requires the capabilities provided by another node • web app requires a database • Named slots to differentiate occurrences • 2 required databases such as customer and product • Sets of occurrences (collections) per named slot • multiple server endpoints for high availability • RelationshipType semantics • Express connected Requirements and Capabilities • Express cardinalities • Two ways to resolve requirements • Explicitly modeled using Relationships • Implicitly matched to a Capability provided by the environment • E.g. PaaS implied capabilities versus IaaS explicit capabilities

6. Addressed Issues • Introduction of metamodel changes to express Requirements and Capabilities of TOSCA Node Types • Introduction of navigability between nodes based on Requirement/Capability definition • Explicit definition of (deployment and implementation) artifacts • TOSCA-26,27

7. Metamodel – Type System

8. Metamodel – Template System

9. Requirements and Capabilities • The concept of Requirements and Capabilities allows for annotating NodeTypes with requirements they have and/or capabilities they provide • Requirements can be expressed against the environment, against hosting resources, etc. • Such requirements would be matched by the hosting environment • Proposal: drop “EnvironmentConstraint” element in current TOSCA spec, since this would be replaced by the new Requirement concept in a much cleaner way • OR: Requirements can be expressed against capabilities provided by other nodes • This allows for validation of models and substitution of components based on matching requirement/capabilities

10. Requirements and Capabilities • Introduce RequirementType and CapabilityType elements supporting inheritance and property definitions • NodeTypes can define requirements using RequirementDefinition element • RequirementDefinition refers to a RequirementType • RequirementDefinition specifies a name (“named slot”) via which the fulfilling entity can later be navigated • RequirementDefinition specifies lower and upper bounds for counterpart • NodeTypes can define capabilities using CapabilityDefinition element • CapabilityDefinitionrefers to a CapabilityType • CapabilityDefinitionspecifies a name (“named slot”) via which the counterpart can later be navigated • CapabilityDefinitionspecifies lower and upper bounds for counterpart • RelationshipType defines ValidSource/ValidTarget that can point to either NodeTypes, RequirementTypes or CapabilityTypes • Thus, a Relationship Type can indicate which Req/Cap pairs can be matched

11. References between nodes • There has been a discussion about the need for generic references and navigability between objects … • Need for references or navigability between nodes exists when: • Nodes have a requirement on (capabilities of) other nodes • Nodes reference deployment artifacts • Nodes referencing implementation artifacts for interfaces • Relationships reference members of the relationship • Relationships reference implementation artifacts for interfaces • Define concrete elements in spec covering above use cases, which provide reference mechanism for concrete context • Named requirements/capabilities (“named slots”) • Named artifact references

12. Req/Cap Definition <NodeTypes> <NodeType id="SugarCRMApplicationType"> <RequirementDefinitions> <RequirementDefinition name="database" requirementType="ex:MySQLClientEndpoint"/> <RequirementDefinition name="container" requirementType="ex:WebappContainment"/> </RequirementDefinitions> </NodeType> <NodeType id="SugarCRMDatabaseContentType"> <RequirementDefinitions> <!-- to model more generic cases --> <RequirementDefinition name="storage" requirementType="ex:StorageAllocation"/> </RequirementDefinitions> <CapabilityDefinitions> <CapabilityDefinition name="mySqlEndpoint" capabilityType="ex:MySQLServerServerEndpoint"/> </CapabilityDefinitions> </NodeType> <NodeType id="ApacheWebServerType"> <CapabilityDefinitions> <CapabilityDefinition name="webapps" capabilityType="ex:WebappContainer"/> </CapabilityDefinitions> </NodeType> </NodeTypes>

13. Req/Cap Definition (2) <CapabilityTypes> <CapabilityType id="Container"/> <CapabilityType id="WebappContainer"> <DerivedFromtypeRef="ex:Container"/> <PropertiesDefinition element="exp:WebappContainerProperties"/> </CapabilityType> <CapabilityType id="MySQLServerServerEndpoint"> <DerivedFromtypeRef="tcore:SQLDatabaseServerEndpoint"/> </CapabilityType> <CapabilityType id="StorageProvider"> <PropertiesDefinition element="exp:StorageProviderProperties"/> </CapabilityType> </CapabilityTypes> <RequirementTypes> <RequirementType id="Containee" requiredCapabilityType="ex:Container"/> <RequirementType id="WebappContainment" requiredCapabilityType="ex.WebappContainer"> <DerivedFromtypeRef="ex:Containee"/> </RequirementType> <RequirementType id="MySQLClientEndpoint" requiredCapabilityType="ex:MySQLServerServerEndpoint"/> <RequirementType id="StorageAllocation" requiredCapabilityType="ex:StorageProvider"/> </RequirementTypes>

14. Req/Cap Template <NodeTemplate id="SugarCRMApplication" nodeType="ex:SugarCRMApplicationType"> <Requirements> <Requirement id="uid-SugarCRMApplication_MySQLClientEndpoint" name="database"/> <Requirement id="uid-SugarCRMApplication_WebappContainment" name="container"/> </Requirements> </NodeTemplate> <NodeTemplate id="ApacheWebServer" nodeType="ex:ApacheWebServerType"> <Capabilities> <Capability id="uid-ApacheWebServer_WebappContainer" name="webapps“/> </Capabilities> </NodeTemplate> <RelationshipTemplate id="SugarCRMApp_hostedOn_Apache" relationshipType="ex:HostedOn"> <SourceElement ref="uid-SugarCRMApplication_WebappContainment"/> <TargetElement ref="uid-ApacheWebServer_WebappContainer"/> </RelationshipTemplate> <NodeTemplate id="SugarCRMDatabaseContent" nodeType="ex:SugarCRMDatabaseType"> <Capabilities> <Capability id="uid-SugarCRMDatabaseContent_MySQLServerEndpoint" name="mySqlEndpoint“/> </Capabilities> </NodeTemplate> <RelationshipTemplate id="SugarCRMDatabaseConnection" relationshipType="ex:MySQLDatabaseConnection"> <SourceElement ref="uid-SugarCRMApplication_MySQLClientEndpoint"/> <TargetElement ref="uid-SugarCRMDatabaseContent_MySQLServerEndpoint"/> </RelationshipTemplate>

15. RelationshipType Example <RelationshipTypes> <RelationshipType id="HostedOn"> <!-- endType can point to a NodeType or a Requirement- or CapabilityType --> <ValidSourcetypeRef="ex:Containee"/> <ValidTargettypeRef="ex:Container"/> </RelationshipType> <RelationshipType id="MySQLDatabaseConnection"> <!-- endType can point to a NodeType or a Requirement- or CapabilityType--> <ValidSourcetypeRef="ex:MySQLClientEndpoint"/> <ValidTargettypeRef="ex:MySQLServerEndpoint"/> </RelationshipType> </RelationshipTypes>

16. Containment RelationshipType: hostedOn source: ContainerReq dest: ContainerCap typed references NodeType: WebApp NodeType: WebServer RequirementType: ContainerReq CapabilityType: ContainerCap ReqDef derivation CapDef RequirementType: WebContainer CapabilityType: WebContainer name: container ReqType: WebContainer name: webApps CapType: WebContainer derivation derivation NodeType: SugarCRMWebApp NodeType: ApacheWebServer NodeTypes inherit the Requirements and Capabilities of the super types

17. hostedOn Relationship • The hostedOnRelationshipType is defined once for all possible containment cases, e.g. as core RelationshipType • A RequirementType and CapabilityType pair are defined for each containment case, e.g. WebApp and WebServer • The base class of each containee specifies the RequirementType in a RequirementDefinition • The base class of each container specifies the CapabilityType in a CapabilityDefinition Apache Web Server SugarCRM App hostedOn R C Req Constraints: version: >= 2

18. SugarCRMEndPoints EndPoints are expressed using Requirements and Capabilities SugarCRM Service WebServerTier DBServerTier Apache Web Server MySQL SugarCRM App SugarCRM DB C R C connectsTo RelationShip PHP Module Database Server EndPoint propagates client credentials, DB Name, host and port client EndPoint (Web Server)

19. Artifacts • Introduce ArtifactType and ArtifactTemplate as top-level elements that can be referenced from different contexts • Artifacts derive from generic Entity, so inherit capability to be derivable and define properties • Specific context given thru DeploymentArtifact and ImplementationArtifact elements • Introduces reference to respective ArtifactType and -Template