Proposal by CA Technologies, IBM, SAP, Vnomic TOSCA Metamodel Changes for Requirements and Capabilities with Primer Example Discussion Proposal by CA Technologies, IBM, SAP, Vnomic

SugarCRM Service Model 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)

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

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

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

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

Metamodel – Type System

Metamodel – Template System

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

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 CapabilityDefinition refers to a CapabilityType CapabilityDefinition specifies a name (“named slot”) via which the counterpart can later be navigated CapabilityDefinition specifies 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

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

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"> <!-- to model more generic cases --> <RequirementDefinition name="storage" requirementType="ex:StorageAllocation"/> <CapabilityDefinitions> <CapabilityDefinition name="mySqlEndpoint" capabilityType="ex:MySQLServerServerEndpoint"/> </CapabilityDefinitions> <NodeType id="ApacheWebServerType"> <CapabilityDefinition name="webapps" capabilityType="ex:WebappContainer"/> </NodeTypes>

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

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> <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"> <Capability id="uid-SugarCRMDatabaseContent_MySQLServerEndpoint" name="mySqlEndpoint“/> <RelationshipTemplate id="SugarCRMDatabaseConnection" relationshipType="ex:MySQLDatabaseConnection"> <SourceElement ref="uid-SugarCRMApplication_MySQLClientEndpoint"/> <TargetElement ref="uid-SugarCRMDatabaseContent_MySQLServerEndpoint"/>

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

Containment NodeType: WebApp NodeType: WebServer ReqDef CapDef 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

hostedOn Relationship Apache Web Server SugarCRM App hostedOn R C Req Constraints: version: >= 2 The hostedOn RelationshipType 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

SugarCRM EndPoints 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)

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