Merging of TOSCA Cloud Topology Templates - IAAS

More documents

Recommendations

Info

4 Assumptions and Requirements for Matching and Merging Assumption 2 and 3 also imply that 1:1 correspondences are considered exclusively. This arises from the fact that (1) the correspondences in Fig. 4.2 cannot be calculated if the Node Types of the Node Templates have different ids and (2) without approaches to syntactic or semantic similarity, which are explicitly excluded from this work, no correspondences between the separate entities of database and OS on the left-hand side and the aggregated entity on the right-hand side of Fig. 4.2 can be established. Assumption 5: TOSCA elements have the same modeling granularity In assumption 4 it was stated that only 1:1 correspondences are considered when matching. Additionally this thesis assumes that all Node, Relationship and Group Templates have the same modeling granularity and aggregated elements such as in Fig. 4.2 do not occur in the Topology Templates respectively are not considered. Assumption 6: A limited set of Node and Relationship Types is sufficient for this thesis It is assumed that a limited set of Node and Relationship Types is sufficient to develop the matching and merging concepts and that it is easily possible to transfer the findings to additional types. Furthermore, only for the specified set below a prototypical implementation provided for. The types are organized as a tree. Fig. 4.3 shows the Node Types that are relevant for this work, as indicated by the green color. Node Types Application Database Application Server Operating System Java Application SQL JEE Linux MySQL Tomcat Debian Linux Fig. 4.3: Relevant Node Type tree Fig. 4.4 illustrates the three Relationship Types that are discussed in this work. The HostedOn Relationship Type of a Relationship Template has the semantics of the source Node Template being installed or deployed on the target Node Template. 28
4 Assumptions and Requirements for Matching and Merging Fig. 4.4: Relevant Relationship Type tree The assumption is that each Node Template can only be source for one HostedOn Relationship Template whereas each Node Template can be the target of many HostedOn relationships. The Communication Relationship Type indicates that a corresponding Relationship Template forms a communication link between two Node Templates. Every Node Template can be source and target of an arbitrary number of Communication-typed Relationship Templates. It is even possible that several communication links exist between two particular Node Templates. The Dependency Relationship Type provides a Relationship Template with the semantics of a dependency relation. The source Node Template of such a Relationship Template depends on another Node Template depicted by the target of the Relationship Template. Assumption 7: Only XML schema types are considered Although the TOSCA specification allows for any type system in the Type section of a Service Template to declare the properties of the Node and Relationship Types, this thesis only considers XML schema types. Assumption 8: Relationship Templates target Node Templates inside a Group Template but not the Group Template itself. Assumption 9: Topology Templates have valid semantics All Topology Templates that have to be matched and merged have valid semantics, e.g. no IT component instance is hosted on two or more other IT component instances. Valid in this context means that Topology Templates are modeled in a way that reflects reality. Although it is possible to define a Node Template as the source of a Relationship Template with HostedOn semantics to more than one other Node Template, in a real IT environment this makes no sense. 29
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 26 and 27: 2 Fundamentals Additional Relations
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 44 and 45: 4 Assumptions and Requirements for
Page 46 and 47: 5 Concept for Matching of Topology
Page 92 and 93:
5 Concept for Matching of Topology
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?