Merging of TOSCA Cloud Topology Templates - IAAS

More documents

Recommendations

Info

2 Fundamentals Additional RelationshipTypeProperties can be referenced analogous to the NodeTypeProperties of the NodeType element. Topology Template The following paragraph describes the TopologyTemplate element of a Service Template and the nested NodeTemplate, RelationshipTemplate and GroupTemplate elements. From the perspective of graph theory a Topology Template forms a directed graph with Node Templates as vertices and Relationship Templates as edges between these Node Templates specifying the relationships. Group Templates form subgraphs of the Topology Template graph, containing Node Templates, Relationship Templates and possibly other Group Templates. The NodeTemplate element symbolizes any kind of component that is part of the IT service under definition. It has a nodeType attribute referencing a beforehand defined Node Type. The attributes minInstances and maxInstances specify the minimum respective maximum number of instances of the Node Template that must or can be created in parallel. Because of the notion of Node Types and Node Templates the term node rather than vertex will be used in the rest of the thesis to avoid confusion. The optional PropertyDefaults element provides initial values for the Node Type properties of the Node Type. The PropertyDefaults contain an XML instance of the Node Type Properties’ schema definition regarding configuration and state. The inheritance hierarchy of a Node Type via DerivedFrom property is also included, i.e. the XML instance document considers the union or overriding of the properties. The PropertyConstraints element names constraints regarding the Node Type Properties of the Node Type of the Node Template under definition. The property attribute of this element contains an XPath expression pointing to particular XML fragment in the NodeTypeProperties element that is to be constrained. The constraintType attribute contains an URI explaining the semantics of the constraint. The Policies element has the identical meaning as the one nested inside the NodeType element. It specifies management policies such as billing or monitoring but in this case regarding the Node Template. Policies in the corresponding Node Type are overridden if they possess an identical name and type, the union of the Policies is formed otherwise. The EnvironmentConstraints element contains definitions for constraining the runtime environment of the Node Template standing for a concrete IT component. This could be network security settings or the prerequisite of certain resources. Similar to the Policies element, the DeploymentArtifacts element on the NodeTemplate level can also override Deployment Artifacts from the NodeType level in case of identical names or otherwise complement them. The same overriding and complementation semantics hold true for the element ImplementationArtifact (see above). A Relationship Template specifies the relationship between two Node Templates. The attribute relationshipType indicates which of the beforehand defined RelationshipType elements provide detailed properties to the Relationship Template under definition. Forming a directed edge, the elements SourceElement and TargetElement specify the navigation path between two Node Templates. Both elements reference either a Node Template or a Group 12
2 Fundamentals Template. The referenced elements must be defined inside the Service Template document under definition. For references to outside Node Templates or Group Templates a TargetElementReference element can be specified, but there is no syntax element for referencing an outside source of the edge. TargetElement and TargetElementReference must not be specified both at the same time inside a RelationshipTemplate element. The PropertyDefaults element of a Relationship Template serves the same purpose as its equivalent in a Node Template. Initial values for the corresponding Relationship Type properties are given via a XML document instance. PropertyConstraints also refer to the properties of the used Relationship Type properties and specify constrains such as uniqueness of a given property value. The optional RelationshipConstraints element contains Relationship- Constraint elements specifying constraints on the use of the defined relationship. The last element to be introduced is the GroupTemplate element. It forms a subgraph of NodeTemplate, RelationshipTemplate and other nested GroupTemplate elements. The GroupTemplate element has a minInstances and maxInstances attribute defining the minimal and maximal instances when creating the Group Template. A Group Template can also have its own Policies attached. Plans Orchestration Plans specify the operational management behavior of a Service Template. The Plans specify discrete steps called tasks or activities and their order. The steps are executed either by the operations exposed by the Node Templates interfaces or by invoking a Service Template API. The TOSCA specification already names two types of Orchestration Plans: Build plans for the creation of a Service Template instance and Termination plans for the removal of an instance. Modification plans for the managing of instances during lifetime have not yet been developed. This will be done by domain experts and the authors of specific Service Templates. The Plans element of a Service Template contains one or more Plan elements. Each Plan has an attribute planType indicating the type of plan, e.g. build plan or termination plan, by means of an URI (http://docs.oasis-open.org/tosca/ns/2011/12/PlanTypes/BuildPlan and http://docs. oasis-open.org/tosca/ns/2011/12/PlanTypes/TerminationPlan). To specify the modeling language describing the plan under definition the languageUsed attribute is used. It contains an URI indicating the language, e.g. http://www.omg.org/ spec/BPMN/2.0/ for BPMN 2.0. The Precondition element contains a condition that has to be satisfied prior to execution. The condition is expressed by an expression language indicated by the expressionLanguage attribute. The content of the condition usually relates to the instance states of the Node or Relationship Templates. The PlanModel element contains the actual model specified in the beforehand denoted modeling language, the PlanModelReference element provides a reference to the actual model. A Plan element instance must either specify a PlanModel or a PlanModelReference but not both at the same time. 13
Page 1: Institute of Architecture of Applic
Page 5 and 6: Contents Contents 1 Introduction...
Page 7 and 8: List of Figures List of Figures Fig
Page 9 and 10: List of Listings List of Listings L
Page 11 and 12: List of Tables List of Tables Table
Page 13: List of Abbreviations SaaS SAX SESE
Page 16 and 17: 1 Introduction Not in the scope of
Page 18 and 19: 1 Introduction Chapter 6 - Concept
Page 20 and 21: 2 Fundamentals arcs = (, ) and =
Page 22 and 23: 2 Fundamentals bination with a publ
Page 24 and 25: 2 Fundamentals Syntax of the XML co
Page 28 and 29: 2 Fundamentals However, the TOSCA P
Page 30 and 31: 2 Fundamentals 2.4 Frameworks The f
Page 32 and 33: 2 Fundamentals Framework class usin
Page 34 and 35: 2 Fundamentals Code example for a c
Page 36 and 37: 3 Related Work 3 Related Work The f
Page 38 and 39: 3 Related Work tive algorithm with
Page 40 and 41: 4 Assumptions and Requirements for
Page 46 and 47: 5 Concept for Matching of Topology
Page 76 and 77:
5 Concept for Matching of Topology
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
6 Concept for Merging of Topology T
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
7 Architecture & Design of an Exten
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
8 Implementation of the Framework (
Page 148 and 149:
8 Implementation of the Framework F
Page 150 and 151:
8 Implementation of the Framework a
Page 152 and 153:
8 Implementation of the Framework 8
Page 154 and 155:
9 Evaluation of the Algorithms and
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
10 Conclusion and Future Work 10 Co
Page 164 and 165:
Bibliography Bibliography [1] Amazo
Page 166 and 167:
Bibliography [28] S. Melnik, H. Gar
Page 168:
Erklärung Hiermit erkläre ich, da
show all

Merging of TOSCA Cloud Topology Templates - IAAS

Create successful ePaper yourself

Delete template?

Save as template?