Merging of TOSCA Cloud Topology Templates - IAAS

More documents

Recommendations

Info

2 Fundamentals Syntax of the XML complexType tExtensibleElements 1 2 3 5 7 8 9 Listing 2.2: Syntax of the XML complexType TExtensibleElements The optional Import element provides means to use external Service Templates, XML Schema or WSDL definitions. A Service Template must name all external references that it uses via Import elements. With the optional Types element additional XML definitions can be specified and used throughout the Service Template document, e.g. as attribute in other elements, without the need to define them in separate documents and import them via Import elements. The types are XML Schema elements by default but could also be of any type system. A TopologyTemplate defines the topological structure of an IT service as a directed graph. The vertices are represented by a set of NodeTemplate elements and the directed edges by a set of RelationshipTemplate elements. The edges express the semantics of the relationships between the vertices. The TOSCA specification either demands one TopologyTemplate or a TopologyTemplateReference which references a TopologyTemplate imported via an Import element. A Service Template may only have zero or one TopologyTemplate or TopologyTemplateReference. The explanation of the different properties of a TopologyTemplate is continued below. The optional element NodeTypes contains one or many NodeType elements which describe the type of NodeTemplates, i.e. their properties and behavior. In contrast, the optional element RelationshipTypes contains the types of RelationshipTemplates and their properties. The element Plans contains Plan elements specifying how to manage the IT Service under definition, e.g. how to instantiate und terminate the service. The TOSCA specification allows that a Service Template serves as a document that only describes an IT Service and is composed into another Service Template that can be instantiated into a service instance. A Service Template document that is to be instantiated must contain either a TopologyTemplate or TopologyTemplateReference whereas a document only intended for description purposes must contain at least one element of the elements Node- Types, RelationshipTypes, or Plans. These syntactical specifications ensure that a Service Template document can be designed modularly. 10
2 Fundamentals Node Type As already mentioned above Node Types are an important part of a Service Template. They describe the properties of one or more Node Templates. The following paragraph discusses the properties of a NodeType element which are important in the scope of this thesis. NodeTypeProperties are the observable properties such as configuration and state of a Node- Type element. They are defined in the Types element of a Service Template or in an external XML Schema file. TOSCA offers an inheritance/derivation mechanism via the DerivedFrom element. It contains a reference to another Node Type acting as a basis for derivation. The properties and operations of the base Node Type either form a union with the newly defined properties and operations or are overridden by the new Node Type in case of conflict. The optional InstanceStates element represents the states a NodeType element can occupy once it has been instantiated. Possible states are e.g. started or stopped. The Interface element contains the description of the functions that belong to a certain Node Type. These functions are invoked by operations which are in turn implemented by so called ImplementationArtifacts. The Operation element can either define a Web Service call and its WSDL port type and operation or a REST call with its HTTP methods and headers as well as optional parameters. The third kind of operation that can be defined is the script via the ScriptOperation element and its input and output parameters. The optional ImplementationArtifact element names the concrete artifacts that are needed to implement the abstract operations of the Interface element. The artifacts could be Python scripts or WSDL files that can be provided in place or referenced from an external location. The RequiredContainerCapability element and its attribute capability indicate if there exist particular dependencies to the execution environment of the operation implementation, e.g. the need for environment provided interfaces to manipulate images or EJBs. The optional Policies element is a container for Policy elements describing the kind of policies a Node Type instance supports. These policies apply to management aspects such as billing or monitoring. The last important element of a Node Type is the optional DeploymentArtifacts element. It specifies all the concrete deployment artifacts that are required to instantiate a particular Node Type. These could be EAR files for a Java EE application or a virtual image for installing a Java EE Application Server. Relationship Type Relationship Types specify the type of one or more Relationship Templates which serve as edges between the Node Templates in a Topology Template graph. Similar to the Node Types the Relationship Types define properties and potential states during runtime but no operations are specified. An important attribute of a RelationshipType element is semantics which denotes the expected behavior of the RelationshipType under definition. 11
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 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 74 and 75:
5 Concept for Matching of Topology
Page 76 and 77:
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?