tosca name used by (roles)modeling conceptdistinguishing traitsnotes node typetype developers...

6
TOSCA Name Used by (Roles) Modeling concept Distinguishing traits Notes Node Type Type Developers Experts that fully understand, package an constrain, properties, scripts, requirements, capabilites Class (or schema) An element for reuse Defines the structure of observable Properties, Requirements and Capabilities Defines Interfaces; added for Simple Profile Node Template Template Developers Compose Service Templates (Topology templates) from existing Types where possible Wants to use types, set configurable properties, scripts, requirements Override types where necessary Factory (with configuration) A qualified constructor (family) Used to set, constrain or override Properties, Requirements (dependencies), or Relationships (templates) TODO: Could be used to describe cardinality. TODO: Orchestrated NOTE: Override at the Template-level reduced introduced for Simple Profile to address the Can be defined by itself and instantiated Unconnected or Connected (with Relationship Templates) Orchestrators start processing Node Templates when processing a service template to derive graph. Currently the same Node Template cannot be reused. More than a constructor. A constructor and how it should be used. Behavior is defined by the fact it resides in the node_templates section The tree is automatically defined by inspection of the node templates

Upload: noel-wilson

Post on 04-Jan-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,

TOSCA Name

Used by (Roles) Modeling concept Distinguishing traits Notes

Node Type Type Developers• Experts that fully

understand, package an constrain, properties, scripts, requirements, capabilites

Class (or schema)• An element for reuse• Defines the structure of

observable Properties, Requirements and Capabilities

• Defines Interfaces; added for Simple Profile

Node Template

Template Developers• Compose Service

Templates (Topology templates) from existing Types where possible

• Wants to use types, set configurable properties, scripts, requirements

• Override types where necessary

Factory (with configuration)• A qualified constructor

(family)• Used to set, constrain or

override Properties, Requirements (dependencies), or Relationships (templates)

• TODO: Could be used to describe cardinality.

• TODO: Orchestrated

NOTE: Override at the Template-level reduced introduced for Simple Profile to address the goal of reduced (Node) Type proliferation.

• Can be defined by itself and instantiated

• Unconnected or Connected (with Relationship Templates)

• Orchestrators start processing Node Templates when processing a service template to derive graph.

• Currently the same Node Template cannot be reused.

• More than a constructor. A constructor and how it should be used.

• Behavior is defined by the fact it resides in the node_templates section

• The tree is automatically defined by inspection of the node templates

Node Instance

Orchestrators, Admins• and (by proxy)

through plans or scripts?

• Instantiation of a Node Template

• Derives its attributes from the bound resource plus the properties that are passed into the factory (identity plus value)

Relationship Type

Type Developers Class (or schema)

Relationship Template

Template Developers Factory (with configuration)• with property values• with dependency injections

(Requirements/Relationships).

• A qualified constructor (family)

• Cannot be instantiated by itself.

• Orchestrators do not process outside of reference by a Node Template

• Different lifecycle than Nodes (Templates)

• Requires (one or more) source or target Nodes (Templates or abstract Types) to be instantiated.

• Note: intent is to allow Relationship Templates be reused.

• Need to add source / target• Just a constructor (how it should be used)

Relationship Instance

Orchestrators, Admins

Page 2: TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,

TODOs for Simple Profile

• Need a list of things that user is allowed (not allowed to do)

• What are the constructs we need to simplify creating templates for the Consumer role?

Page 3: TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,

Topology Template (cont.)

3

<TopologyTemplate id="ID" name="NCName"> ( <NodeTemplate id="ID" name="string" nodeType="QName" minInstances="int"? maxInstances="int|string"?>+ <PropertyDefaults>? XMLDocument </PropertyDefaults> <PropertyConstraints>? <PropertyConstraint property="string" constraintType="anyURI">+ constraint? </PropertyConstraint> </PropertyConstraints> <Policies/>? <EnvironmentConstraints>? <EnvironmentConstraint constraintType="anyURI">+ constraint type specific content? </EnvironmentConstraint> </EnvironmentConstraints> <DeploymentArtifacts/>? </NodeTemplate> | <RelationshipTemplate/> | <GroupTemplate/> )+ </TopologyTemplate>

Node Template

…type for…

Relationship Template

…type for…

GroupTemplate

Page 4: TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,

Topology Template (cont.)

4

<TopologyTemplate id="ID" name="NCName"> ( <NodeTemplate/> | <RelationshipTemplate id="ID" name="string" relationshipType="QName">+ <SourceNodeElement id="IDREF"/> ( <TargetNodeElement id="IDREF"/> | <TargetNodeTemplateReference name="QName"/> ) <PropertyDefaults/>? <RelationshipConstraints>? <RelationshipConstraint constraintType="anyURI">+ constraint? </RelationshipConstraint> </RelationshipConstraints> </RelationshipTemplate> | <GroupTemplate/> )+ </TopologyTemplate>

Node Template

…type for…

Relationship Template

…type for…

GroupTemplate

Page 5: TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,

Vendor „BestStorageVendor“ Sells its Devices with Corresponding Node Template

• BestStorageVendor defines Node Template to specify its BestStorageDevice based on former Node Type

• Vendor sets Properties that are known from the outset– TotalStorageAmount is known– IPAddress is set during installation/deployment

• Implementation of interface is referenced from Node Template

<NodeTemplate name="BestStorageDevice" nodeType="SuperStorage"> <PropertyDefaults> <TotalStorageAmount>1000TB</TotalStorageAmount> </PropertyDefaults>

<DeploymentArtifacts> <DeploymentArtifact name="InterfaceImplementation" type="WARref">

... </DeploymentArtifact> </DeploymentArtifacts>

</NodeTemplate>

Page 6: TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,

From TOSCA v1.0 spec.• Node Templates and Relationship Templates that together define the topology model of a service as a

(not necessarily connected) directed graph. • A Node Template specifies the occurrence of a Node Type as a component of a service. A Node Type

defines the properties of such a component (via Node Type Properties) and the operations (via Interfaces) available to manipulate the component. – Node Types are defined separately for reuse purposes and a Node Template references a Node Type and adds

usage constraints, such as how many times the component can occur.• A Relationship Template specifies the occurrence of a relationship between nodes in a Topology

Template. Each Relationship Template refers to a Relationship Type that defines the semantics and any properties of the relationship. Relationship Types are defined separately for reuse purposes. The Relationship Template indicates the elements it connects and the direction of the relationship by defining one source and one target element

• Requirements and Capabilities of Node Templates in a Topology Template can optionally be connected via Relationship Templates to indicate that a specific requirement of one node is fulfilled by a specific capability provided by another node.– Requirements can be matched in two ways as briefly indicated above: – (1) requirements of a Node Template can be matched by capabilities of another Node Template in the same

Service Template by connecting the respective requirement-capability-pairs via Relationship Templates; – (2) requirements of a Node Template can be matched by the general hosting environment (or the TOSCA

container), for example by allocating needed resources for a Node Template during instantiation.