Merging of TOSCA Cloud Topology Templates - IAAS

More documents

Recommendations

Info

5 Concept for Matching of Topology Templates Correspondences to More Than one Node Template Another matching situation to be discussed occurs when a Node Template matches more than one Node Template inside one Topology Template. This must not be confused with 1: n or n:1 mapping characteristics. Those characteristics imply that an entity is mapped to more than one other entity in order to represent the same semantics. Fig. 4.2 in Section 4.1 exemplifies such a situation. In contrast the concept discussed here is the occurrence of several Node Templates the have identical Node Types. Fig. 5.4 shows that the OS Node Template the database is hosted on matches both OS Node Templates of the two Application Servers. Therefore, two Correspondences have been established. Each Node Template at which the comparison started, must store the found Node Template Correspondence additionally to the mapping. We will see in Section 6.1.1 that this is a necessary requirement for the merging algorithm in order to generate a correct result under certain, yet to be discussed, circumstances. If each Node Template has a Correspondence to every other Node Template, which comes into consideration because of the appropriate Node Type, the author calls this a full mapping between the respective Node Templates. Otherwise it is called a partial mapping in this thesis. Fig. 5.4: Correspondences to more than one Node Template Fig. 5.4 also shows Topology Templates containing disconnected graphs, i.e. the graphs with more than one component can be handled by the matching concept. 36
5 Concept for Matching of Topology Templates Consideration of Derived Node Types The different cases discussed above assume that the Node Types must possess an identical id and targetNamespace attribute in order to even take into consideration the matching of two Node Templates. However, the concept of matching can be expanded to Node Types that are not identical but have some kind of relation with each other in a Node Type inheritance tree. Fig. 5.5 shows the relationship between different application server Node Types. In this example a Websphere Application Server (WAS) 6.1 with Web Service Feature Pack is derived from Websphere Application Server 6.1 which itself is derived from a generic Application Server Node Type. The DerivedFrom attribute indicates the respective Node Type that is extended. The relationships between the Node Types in Fig. 5.5 form an “inverted” tree with the arcs pointing in the direction of the root Node Type (Generic) Application Server. Fig. 5.5: Node Type parent relationships A similar case is depicted by Fig. 5.6. Two application server Node Types from different software vendors share the same root Node Type and thus are siblings in the inheritance tree. To match Node Templates using node Types that are not identical but are related with each other as indicated by the inheritance tree, the author of this work proposes an extension of the TOSCAMerge framework discussed above with its generic part and the type-specific plugins. The generic part must recursively resolve the actual properties of the Node Type under evaluation. That means if a Node Type used by a Node Template has a filled De- 37
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 46 and 47: 5 Concept for Matching of Topology
Page 100 and 101:
5 Concept for Matching of Topology
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?