Merging of TOSCA Cloud Topology Templates - IAAS

More documents

Recommendations

Info

2 Fundamentals However, the TOSCA Plans are only introduced here for the sake of completeness since the merging of plans is not in the scope of this work. TOSCA Example To exemplify the description of an IT service using TOSCA consider the following situation as depicted in Fig. 2.1. The simple Topology Template consists of an application running on an application server. The application is represented by the Application Node Template and the application server by the Application Server Node Template. The “HostedOn”- relationship between the two Node Templates is realized by the HostedOn Relationship Template. Topology Template Types Node Template Application type for Properties Owner Instance Name AccountID Application Node Type startStopInterf Configuration Interf Interfaces HostedOn Relationship Type Relationship Template HostedOn type for Properties Install Dir Application Server Node Template type for Properties Application Server Node Type Hostname IP Address HeapSize startStopInterf Configuration Interf Deployment Interf Interfaces Build Plan configureIP startServer configure Application deploy Application restartServer startApplication Fig. 2.1: Graphical instance example of a TOSCA Service Template 1 The two Node Templates and the Relationship Template are typed und therefore enriched with properties by Node Types respectively a Relationship Type. The Node Types additionally provide interfaces that expose operations to interact with the Node Templates. Fig. 2.1 1 Adopted from [32] 14
2 Fundamentals also shows a buildplan illustrating the sequence of activities that must be performed to start und deploy both server and application and bring them up to a working state. The build plan exploits the operations exposed by the displayed configuration and management interfaces. 2.3.2 Use Cases of TOSCA The authors of the TOSCA specification have proposed several supported use cases [32]. Services as Marketable Entities The first one is the notion of services as marketable entities. According to the authors, a market for hosted IT services will emerge if Service Templates are standardized. Service developers with profound knowledge about a particular service could create Topology Templates consisting of a set of components and their mutual dependencies und thus define the structure of IT services in an interoperable manner. Service Providers could then select predefined Service Templates out of service catalogs and make them available for potential customers. The service providers would adapt the selected Service Template to their concrete infrastructure, mapping the Topology Templates and management plans to make the Template executable. The necessary management plans, i.e. the plans for managing the whole life cycle of a service from creation to termination, will also be provided by service developers. Having access to those plans there is the potential of significantly reducing service hosting costs for a service provider as they can rely on reusable knowledge and apply management best practices. The domain knowledge of the modeler is encapsulated in the management plans hiding the complexity from its user, who can simply invoke it. Portability of Service Templates A second use case is related to the portability of Service Templates. Definitions of IT services become portable when standardizing them with TOSCA. The authors define portability in this context as the ability of one party to understand a Service Template’s structure and behavior that has been created by a second party. The creator can be anyone from a cloud provider, to an enterprise IT department or a service developer. The authors point out that the portability they define only refers to the service definitions, i.e. the topology model and the corresponding plans but not to the individual (physical) components. Their portability is not in the scope of the specification. Service Composition The third use case the authors cite is service composition. That means that the abstractions provided by a Service Template help to compose components and automation products from different suppliers and hosting providers to one service. This is possible because the Service Template does not imply any particular hosting environment. These properties facilitate strategic decisions such as using datacenters at different geographical locations that together form one IT Service. 15
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 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 78 and 79:
5 Concept for Matching of Topology
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

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

Delete template?

Save as template?