GB2522031A - Method and system for automatic creation of service templates for deployment of resources in a data processing infrastructure - Google Patents

Abstract

The invention relates to a method and system for automatic creation of service tem­plates for deployment of services in a data processing infrastructure (100), such as a cloud computing environment, which provides a pool of resources. A service template is inter­preted by a service orchestrator (120), the service orchestra­tor allocates resources from the pool of resources and deploys services based on the resources by interpreting the service template. The method comprises the steps of: receiving existing packages (L1 -L3) of configuration scripts and at least one run list (RL1, RL2) for automatic installation or configuration of resources on existing servers; extracting from the packages (Ll-L3) of configuration scripts deployment information regarding the resources to be installed or configured by the configuration scripts and generate a collection of resource types based on the information in­cluding their associated automation modules; extracting from the packages (Ll-L3) of configuration scripts and at least one run list (RL1, RL2) deployment dependencies be­tween the resources to be installed or configured by the configuration scripts; and using the deployment information and the deployment dependen­cies for creating a service template describing the deployment hierarchy of the resources for deploying a specific service.

Description

DESCRIPTION

Method arid system for automatic creation of service templates for deployment of resources in a data processing infrastructure

Field of the invention

The presenb IriveriLlori relaLes generally Lo Llie field of ajLoraLlc resource deployment. More specifically, the present invention is related to a method and a system for automatic creation of service templates which can be used to deploy services in an existing data processing infrastructure.

Background

Management of services following the paradigm of "infrastructure as code" is widely used. The basic idea of the "infrastructure as code" is to pro- vide a domain specific language in order to describe the underlying infra-structure of a particular IT service. A configuration management product like Opscode Chef, Puppet or CfEngine may be used for realizing "infra- structure as code" which is freguently used in cloud environments compris-ing a plurality of virtual machines. Said configuration management products can be used for instantiating resources, typically software configurations, on existing servers or virtual machines. Configuration management products commonly provide a platform-independent script-framework for deploying re-sources on said servers or virtual machines. A configuration management server comprises a library with multiple packages of configuration scripts and run lists which are used to deploy resources on servers or virtual ma-chines. Each run list may be used to deploy resources on a specific server or virtual machine. Using a configuration management product, a set of re- sources may be automatically deployed on an existing server or virtual ma-chine. Thereby, the configuration of resources gets reproducible.

Mso model-driven service management, in cloud environments also referred to as model-driven cloud management, is gaining more and more attention.

Thro examples for model-driven cloud nanagement tools are TOSCA (Topology and Orchestration Specification for Cloud Applications) and Canonical Juju.

By using model-driven cloud management tools, models for specifying IT ser- vices which use a plurality of resources on a plurality of servers or vir-tual machines can be generated. Said models may use service templates for instantiating the services. Said models provide a holistic approach to make an IT service manageable, specifically to deploy a plurality of resources on different servers or virtual machines, wherein said resources comprise hierarchical sLrucLLjres wiLh dependencies beLweeri said resources.

existing drawback of model-driven service management is that the service terplates have to be created manually by a human service modeler. Espe- cially for managing complex services, the generation of said service tem-plates may take a long time and would require unreasonable ef fort.

Hence, there is a need to provide for a method for automatic creation of service templates based on existing resource configurations.

Surruary of the invention It is an objective of embodiments of the invention to provide for a method, computer-readable medium and system for reducing the effort of generating service terrplates for model-driven service management. The objective is solved by the features of the independent claims. Preferred embodiments are given in the dependent claims. If not explicitly indicated otherwise, em-bodiments of the invention can be freely combined with each other.

According to a first aspect, a method for automatic creation of service templates for deployment of services in a data processing infrastructure is described. The data processing infrastructure provides a pool of resources, a service orchestrator and a service template which is interpreted by said service orchestrator. Resources according to the invention are any kind of middleware, software components, applications or databases provided by a data processing component. A data processing component may be any physical or virtual component adapted to process data, e.g. a computer, a server, or a virtual machine. A service orchestrator is a component adapted to auto- matically arrange, coordinate and manage complex computer systems, middle-ware, and services.

The service orchestrator allocates resources from said pool of resources and deploys services based on said resources by interpreting said service template, wherein said service template contains a description of resources to be deployed, wherein the resources described by said service template are of specific resource types. A resource type defines the structure of a specific resource. For each resource type an automation module, also re-ferred to as implementation artifact, exists which is used by the service orchestrator to automatically create and configure said resources.

The method comprises the steps of: -receiving existing packages of configuration scripts and at least one run list for automatic installation and/or configuration of resources on existing servers; -extracting from said packages of configuration scripts deployment information regarding the resources to be installed and/or con-figured by said configuration scripts and generate a collection of resource types based on said information including their asso-ciated automation modules; -extracting from said packages of configuration scripts and at least one run list deploaent dependencies between the resources to be installed and/or configured by said configuration scripts; -using said deplouent information and said deployment dependen-cies for creating a service template describing the deployment hierarchy of said resources for deploying a specific service.

A run list may be a collection of automation scripts to be executed in a specific order. After a run list has been processed, a specific resource or multiple resources that are based on each other, e.g. a software installa-tion or multiple software components, will have been set up.

The method provides an least partiaiLy automatic generation of a service template modeling the management of a service in a data processing infra-structure, e.g. in a cloud computing environment based on existing packages of configuration scripts provided by a configuration management entity.

Thereby, the effort for modeling services in order to manage said services by the generated model is considerably reduced.

According to further eribodiments, the step of extracting deployment infor- mation comprises analyzing the structure of the configuration script pack-ages which are used to deploy a service and extracting parameters from the configuration script packages describing the type of resource to be imple- mented by each of said configuration script packages. The parameter de-scribing the type of resource to be implemented by a specific package may be an identifier, specifically a unigue identifier specifying the resource type. For example, the identifier may be indicative for the kind of appli- cation or software component to be installed and/or configured by the re-spective configuration script package. In order to provide an environment independent of a specific configuration management product, adapters for specific configuration management products or libraries can be installed into the system to perform a proper napping of e.g. identifiers to resource type names.

According to further embodiments, the resource type comprises an interface section comprising properties (e.g. name, type, valid value range) for de-scribing the resource type and the properties for describing the resource type are correlated with the parameters extracted from the configuration script packages. The interface section of the resource type may define the resource type by means of said properties. The values correlated with said properties are assigned at deployment time, i.e. when instantiating the service based on the service template. In other words, the foundation of the properties of the generated node resource type are parameters defined in the corresponding configuration script package.

According to further ernbodinents, the step of extracting deployment infor-mation comprises extracting information regarding input parameters reguired by each resource and output parameters provided by each resouroe. Each re-source to be Installed and/or configured by a configuration script package may need input parameters before performing the installation/configuration step, respectively, may generate output parameters while performing the Installation/configuration step. Therefore, said input/output parameters may be indicative for the seguence of deployment of the resources and may provide informaLion regarding Lhe dependencies beLweexi Ltie resources. Based on said dependencies, the relationships between resource templates within the service template may be defined.

According to further embodiments, the step of generating a collection of resource types comprises generating a resource type for each received pack-age of configuration scripts or for each package of a selected number of received packages of configuration scripts. Specifically, the at least one received run list may comprise information about the set of resources to be installed and/or configured on a specific computing entity, e.g. a virtual machine. If multiple virtual machines are used to implement a service, there may be nultiple run lists defining the set of resources. Each of said resources may be correlated with a specific configuration script package and for each configuration script package a resource type may be generated.

Thereby, the set of resource types reguired for establishing the service template is defined.

According to further embodiments, the resource type comprises a reference to a package of configuration scripts reguired for implementing a resource.

For example, a resource type correlated with a customer relationship man- agement (OHM) application may comprise a reference to a package of configu-ration scripts which can be used for installing and/or configuring the OHM application. The reference to the package of configuration scripts may be derived by interpreting the at least one run list and determining which resource is generated based on which package of configuration scripts, spe- cifically based on which configuration script of said package of configura-tion scripts. So, by means of the service template a specific service built by a set of interacting resources can be implemented by evaluating said service template arid installing and/or configuring the resources based on the configuration scripts the resource types refer to.

Acoording to further embodiments, the step of extracting dep1onent depend-encies comprises interpreting the at least one run list and determine the sequence of records within the run list. By means of the run list, the se- quence of installation and/or configuration of specific resources on a spe-cific computing entity is scheduled. So, by evaluating said installation and/or configuration sequence it is possible to derive information about the dependencies between the resources. For example, a run list may com-prise the following sequence of records: "MySQL-deploy", "CBM DB-deploy".

Hence, the information may be derived, that the CBM database (DB) is re-lated to the installation and /or configuration of a MySQL-resource.

According to further embodiments, the service template comprises at least one topology of resource templates, wherein the resource templates are gen-erated based on the resource types. Specifically, the resource templates may be generated as instances of the resource types. The topology of re- source templates defines resources interacting with cacti other and the re-lationships between said resources. The dependencies within the topology of resource templates are created based on the extracted deployment dependen-cies. The dependencies are described based on pre-defined relationship types defining the interaction of the resources.

According to further embodiments, the service template comprises at least two topologies of resource templates wherein each topology of resource tem-plate is correlated with a specific received run list. So, a first resource template topology may comprise infornation about the resources and their dependencies installed on a first conputing entity and a second resource template topology may comprise information about the resources and their dependencies installed on a second computing entity. The whole set of to-pologies of resource templates form the topology template indicating the possible dependencies between the topologies of resource templates. For example, a CRM application being deployed by a first computing entity may connect to a BM database hosted by a second computing entity. Thus, the 5PM application may connect to the 5PM database. The relationship between the CRM application and the CRM database may be illustrated by a "connect to"-relationship between the resonrce template representing the CPM appli- cation and the resource template representing the CPM database. Said "con-nect to"-relationship is an example of a dependency between two topologies of resource templates.

According to further eritodiments, the packages of configuration scripts and/or the at least one run list are received from a configuration manage-ment server. The configuration management server may provide information for installation and/or configuration of resources on existing computing entities, specifically existing virtual machines.

According to a further aspect, the invention relates to a computer-readable medium comprising computer-readable program code embodied therewith which, when execmted by a processor, cause the processor to execute a method as previously described.

According to a further aspect, a system for automatic creation of service templates for deploaent of services in a data processing infrastructure is described, wherein said data processing infrastructure provides a pooi of resources, a service orchestrator adapted to interpret a service template, wherein said service orchestrator is configured to allocate resources from said pooi of resources and configured to deploy services based on said re- sources by interpreting said service template, wherein said service tem- plate contains a description of resources to be deployed, wherein the re-sources described by said service template are of specific resource types, wherein for each resource type an automation module exists which is used by the orchestrator to automatically create and configure said resources, said system comprising: an analyzer component configured to: -receive existing packages of configuration scripts and at least one run list for automatic installation and/or con-figuration of resources on existing servers; -extract from said packages of configuration scripts de- ployment information regarding the resources to be in-stalled and/or confIgured by said configurarion scripts a generator component configured to: -generate a collection of resource types based on said in-formation including their associated automarion modules; -extract from said packages of configuration scripts and at least one rur list deployment dependencies between the re- sources to be installed and/or configured by said configu.-ration scripts; -create a service template using said deployment informa- tion arid said deployment dependencies describing the de- ployment hierarchy of said resources for deploying a spe-cific service.

Brief Description of the Drawings

Tn the following, preferred embodiments of the invention will be described in greater detail by way of example, only making reference to the drawings in which: Fig. 1 shows en example schematic diagram of a data processing infrastruc-ture; Fig. 2 shows en example schematic diagram of the service template genera-tion system arid the configuration management entity; Fig. 3 shows an example schematic representation of the structure of a ser-vice template; Fig. 4 shows en example flowchart of a process of generating service tem-plate according to a first embodiment; Fig. 5 shows an example flowchart of a process of generating service tem-plate according to a second errbodlment; Fig. 6 shows an example schematic diagram of a service topology providing an instance of a customer relationship management service; Fig. 7 shows a first step of generating a service template of the service topology of Fig. 6 by means of a schematic diagram; Fig. 8 shows a second step of generating a service ternpiate of the service topology of Fig. 6 by means of a schematic diagram; Fig. 9 shows the step of generating a topology template corresponding to the service topology of Fig. 6 by means of a schematic diagram; and Fig. 10 shows the step of correction/refinement of the topology template corresponding to the service topology of Fig. 6 by means of a sche-matic diagram.

Detailed description

As will be appreciated by one skilled in the art, aspects of the present disclosure may be ea*I)odied as a system, method or computer program product.

Accordingly, aspects of the present disclosure may take the form of an en-tirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Elirthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or irore computer readable medium(s) may be utilized.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a port- able computer diskette, a hard disk, a random access memory (PAM), a read- -10 -only memory (RCM), an erasable programmable read-only memory (EPRCM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-RcM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can con-tain, or store a program for use by or in connection with an instruction execubioti sysLem, apparabcs, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be trans-mitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the pre-sent invention may be written in any combination of one or more prograirming languages, including an object oriented prograiriming language such as Java, Smalltalk, C++ or the like and conventional procedural programming lan- guages, such as the "C" programing language or similar programming lan- guages. The program code may exerute entirely on the user's computer, part-ly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be con- nected to the user's computer through any type of network, including a lo-cal area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Tnternet Service Provider) -11 -kspects of the present disclosure are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systerris) and computer program products according to embodiments of the present disclo-sure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illus- LraLioris and/or block diagrams, can be iiuplemeriLed by compuber program in- structions. These computer program instructions may be provided to a proc-essor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other pro-granmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions nay also be stored in a computer read-able medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The block diagrams in the Figures illustrate the architecture, functional- ity, and operation of possible implementations of systems, methods and com- puter program products according to various embodiments of the present dis-closure. In this regard, each block in the block diagrams may represent a -12 -module, segment, or portion of code, which comprises one or irore executable instructions for implementing the specified logical function(s) It should also be noted that, in some alternative implementations, the functions dis-cussed hereinabove may occur out of the disclosed order. For example, two functions taught in succession may, in fact, be executed substantially con-currently, or the functions may sometimes be executed in the reverse order, depending upon Die fLaicLiorialiLy involved. IL will also be ruLed DiaL each block of the block diagrams, and combinations of blocks in the block dia-grams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or corrbinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It will be further understood that the terms "comprises" and/or "compris- ing," when used in this specification, specify the presence of stated fea-tures, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, arid/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and de-scription, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical applica-tion, and to enable others of ordinary skill in the art to understand the -13 -invention for various erodiments with various modifications as are suited to the particular use contemplated.

Referring to Figure 1, a schematic diagram of a data processing infrastruc- ture 100 is shown. The data processing infrastructure 100 comprises comput-ing entities CE1, CE2, which may be discrete machines or virtual machines.

Said coinpubirig eriLibies CE1, CE2 may liosL a pluraliby of resources, for example software components, applications, databases etc. The computing entities cE1, CE2 may be coupled in order to provide a certain service. For example, the computing entity cF1 may host a software application, e.g. a customer relationship management (CR11) application and the computing entity CE2 may host a database which is used for storing data of the customer re-lationship management (CRM) application. In addition, the data processing infrastructure comprises a configuration management entity CME, for example a configuration management server which provides packages L1-L3 of configu-ration scripts and run lists RL1, RL2. The computing entities CF1, CF2 may be coupled with the configuration management entity cT4E for automatic in-stallation and/or configuration of said resources on the computing entities CE1, 052. In case that the configuration management tool Opscode Chef is chosen for automatic installation and/or configuration of the resources hosted on the computing entities CEl, 052, the configuration management entity cI4E may be the Chef server.

The data processing infrastructure 100 may further comprise a service tem-plate generation system 110. Said service template generation system 110 may be coupled with the configuration management entity QvJE in order to receive information of the configuration management entity CME, specif i-cally information regarding the packages L1-L3 of configuration scripts and the run lists 311, P12. The service template generation system 110 may be adapted to generate a service template based on the received information.

The generated service template may be interpreted by a service orchestrator for deploying resources on the computing entities CE1, CE2. Said ser-vice template contains information regarding the deploment of resources on -14 - the computing entities GEl, CE2. The computing entities may be virtual ma-chines hosted by at least one hypervisor.

Figure 2 shows an excerpt of the data processing infrastructure 100, namely the service template generation system 110 and the configuration management entity G4E in closer detail. The service template generation system 110 comprises an analyzer comporiexiL 111 arid a gexieraLor coiuporienL 112. The asia-lyzer component 111 may be adapted to receive information regarding the packages Ll-L3 of configuration scripts and run lists P11, 312. Further-more, the analyzer component 111 may be adapted to analyze the received information and extract deployment information, i. e. information regarding the resources to be installed and/or configured by the configuration scripts out of the packages L1-L3 of configuration scripts. Furthermore, the analyzer component 111 may be adapted to extract information regarding deployment dependencies between the resources to be installed and/or con-figured by said packages L1-L3 of configuration scripts. Said information derived by analyzing the packages Ll-L3 of configuration scripts and run lists FRILl, P12 may be provided to the generator component 112. The genera- tor component 112 may create a service template based on the provided in-formation. Said service teirplate may describe the deployment hierarchy of said resources for instantiating a specific service.

Figure 3 shows a schematic view of the structure of a service template 300.

The service template 300 comprises a topology template 310, resource types 320 (also called node types) and relationship types 330. The resource types 320 represent single components of the whole service to be deployed. Each resource type 320 comprises an implementation section, in the following also referred to as automation module to be executed by the service orches- trator and an interface section describing the resource type 320. The in-terface section may comprise information regarding the name of the resource type 320, properties and a create-operation for creating an instance of the resource type. The relationship types 330 define relationships between said resource types 320. Typical relationships are "hosted on"-relationship, "depends on"-relationship or "connects to"-relationship. The topology tern- -15 -plate 310 represents the topology of instances of the resource types 320, i.e. the dependencies of the resonrces correlated with said resource types 320 by means of a graph. Each box of the graph represents a resource tem-plate 340 as an instance of a resource type 320 and the interconnections indicate the relationships between said resource templates 340, wherein the relationships are correlated with a certain relationship type 330 (as mdi-caLed by Ltie dashed anuws) . AldiLionally, Llie service LemplaLe 300 may corprise a plan representing the operational aspects of the service to be deployed by the service template.

Figure 4 illustrates a first embodiment of a process 400 of generating a service template by means of an example flowchart. After starting the proc-ess, resource type definitions are generated (step 410) . Specifically, a resource type for each library stored in the configuration management en- tity ONE is generated. In case of using the configuration management prod-uct "Opscode Chef", the configuration management entity cI'JE is the "Chef" server arid the configuration script packages are "Cookbooks". If there are many packages stored in a library of the configuration management entity ElIdE, the user may be able to explicitly select for which packages resource types should be created. The resource type definitions may consist of a name and an identifier as well as properties definitions. Said resource type definitions may be assigned by using information of attributes defined in the package corresponding to the resource type.

Following up, a script operation is being automatically created for each resource type generated in the step before (step 420) . This operation rep-resents a lifecycle operation, which is responsible to create an instance of the corresponding resource type.

After creating instances of the resource types, an implementation artifact is automatically linked to each "create" operation (step 430) . The content of the implementation artifacts are basically references to configuration scripts of said packages provided by the configuration management entity ElIdE. Specifically, the instance of a resource type may be linked by its -16 -implementation artifact to a specific configuration script which implements the "create" operation of a particular resource type. Preferably, the run lists provided by the configuration management entity ONE may be used to determine which configuration script implements the "create" operation of a particular resource type. As an example, there may be a resource or soft-ware component "mysql-server" which is associated with the conmand "mysql: :insLall" in a run lisL. Said command indicabes LhaL a resource "mysql-server" may be installed on the data processing component associated with the run listby using the configuration script "install" of the package "mysql". Tn other words, based on a single entry within a run list, the configuration script adapted to install and/or configure a resource can be determined. Based on the sequence of the entries within a run list, the deployment dependencies between the resources implemented on a specific data processing component, e.g. a virtual machine can be determined because each run list is correlated with a specific data processing component. M-ditionally, deployment dependencies can be also derived by analyzing the inputs arid outputs of the configuration scripts provided by the configura- tion management entity cOlE. For example, a first resource generating a spe-cific output has to be deployed before a second resource which is using said specific output generated by the first resource as an input.

After extracting information regarding the resources required for imple- menting a specific service and information regarding the dependencies be- tween the resources for implementing a certain service, the service tem-plate may be generated based on said information (step 440) . Said service template comprises a topology template. As already describe above in con- nection with Fig. 3, the topology template may consist of resource tem-plates based on the generated and generic resource types as well as "hosted on" relationship templates between particular resource templates. For exam-ple, for each resource that is registered on the configuration management entity OME, a "virtual machine" resource template may be created. On top of each "virtual machine" resource template, an "operating system" resource template may be generated. Afterward, a "hosted on" relationship template may be created for each pair of "virtual machine" and "operating system" -17 -resource template. Then, based on the run lists and the generated resource types, more resource templates arid "hosted on" relationship templates are getting created based on the dependencies found by analyzing the run lists.

Steps 410 to 440 may be performed automatically.

Figure 5 illustrates a second embodiment of a process 500 of generating a service LemplaLe by means of an example flowcharL. The sLeps 510 Lo 530 are identical to the steps 410 to 430 described abcve. So, the above statements regarding steps 410 to 430 also apply to steps 510 to 530 of Fig. 5. Espe- cially when creating models for complex services, the automatically gener- ated service template may contain failures or may not be complete. There-fore, in step 540, a topology template draft or skeleton may be generated (step 540) . As already describe above in connection with Fig. 3, the topol- ogy template skeleton may consist of resource templates based on the gener- ated and generic resource types as well as "hosted on" relationship tem- plates between particular resource templates. For exairple, for each re-source that is registered on the configuration management entity 01, a "virtual machine" resource template nay be created. On top of each "virtual machine" resource template, an "operating system" resource template may be generated. Afterward, a "hosted on" relationship template may be created for each pair of "virtual machine" and "operating system" resource tem-plate. Then, based on the run lists and the generated resource types, more resource templates and "hosted on" relationship templates are getting cre-ated based on the dependencies found by analyzing the run lists. Steps 510 to 540 may be performed automatically. The following steps 550 to 580 may be performed at least partly manually by a human service template modeler.

After automatic generation of a topology template skeleton, said topology template skeleton may be completed and or refined (step 550) . For example, relations between resource templates may be replaced by other relations. In addition, missing additional resource types and/or relationship types may be introduced step (560) . If the topology template skeleton was correctly and completely created by the automatic generation process, steps 550 and 560 can be omitted.

-18 - Tn the next step, a plan may be created which represents operational as-pects of the deployed service (step 570) . The plan provides means to manage the service during its run-time. It may be created automatically. Finally, the service template may be generated based on the topology template arid the plan (step 580) . Finally, the service template is packed into an ar- chive, specifically a cloud service archive. Said archive may be She fousi-dation to instantiate and manage a service modeled by the service template.

Tn the following, an example of creating a service template according to the invention is described. Figure 6 shows a simple service topology pro-viding an instance of a CR4 service. The topology consists off two virtual machines VM1, VM2 that are both managed by a configuration management en-tity OME. As already described in connection with Fig. 1, the configuration management entity CME may be coupled with the virtual machines VM1, 7M2 and may comprise a specific run list Fall, P12 for each virtual machine VM. In addition, the configuration management entity ONE may comprise a plurality of packages which contain configuration scripts for installing and/cr con-figuring resources on the virtual machines \Nl, VM2. For providing a CMVI service, for example, the first virtual machine VMS may run the CR4 Appli-cation and the second virtual machine VM2 may run the CR4 database. The CR4 application of virtual machine VM1 may, for example, require as further resources a PHP resource and an Apache webserver resource run on an operat-ing system OS. The CR4 database provided by the second virtual machine 7M2 may require a MySQL-resource hosted on an operating system OS. For install-ing and configuring said services, the configuration management entity STylE may comprise packages associated to upper-mentioned resources, e.g. a CR4 Application package, a CR4 DB package, a MySQL package, an Apache package and a PHP package. Each package may comprise a set of configuration scripts to which the entries within the run lists may refer. Each run list may re- fer to a specific virtual machine VMI, VM2 and may comprise entries defin- ing which configuration scripts have to be executed on the respective vir- tual machine VMS, 7142. In addition, the sequence of the run lists is in-dicative for the sequence of deployment of the respective resources.

-19 -According to figure 7, the service template generation system 110 may in a first step generate a resource type for each package of the configuration management entity cME associated with a specific service (steps 410, 510 of Fig. 4 and 5) . Furthermore, there may be an automatic generation of generic resource types like a resource type for the operating system "OS", a re- source Lype for Ins Lallixig virLual naclilries "VM", or a generic relaLioxi-ship type "Hosted On". The generated resource type may be a resource type skeleton which is refined and completed in the following steps.

As shown in figure 8, a "create" operation is attached to each generated resource type. Specifically, the create operation is included in an automa- tion module to be executed by a service orchestrator. The "create" opera- tion may comprise a reference to a specific configuration script which gen-erates a resource according to the resource type the "create" operation is included in. For example, the resource type "MySQL" may comprise in its automation module a reference to the package "MySQL" and its configuration files to install and configure a MySQL server. The processes illustrated in figure 8 correspond to the steps 420, 430 of figure 4 and steps 520, 530 of figure 5.

Figure 9 corresponds to step 540 of figure 5 and illustrates a topology template skeleton which may be generated by the service template generation system 110. Based on the generated resource types, resource templates may be generated. Based on the information regarding the dependencies of the resources, relations between the resource templates may be generated. Ac-cording to the example, "Hosted on" relations may be created between the resource terrplates. The shown example comprises two topologies of resource templates wherein each topology of resource template is correlated with a specific run list. Each topology of resource templates may comprise infor-mation regarding the installation and/or configuration of resources on a specific computing entity, e.g. virtual machine. In the present example, the left branch of the topology template skeleton may refer to the first virtual machine v141 running the 5PM application and the right branch of the -20 - topology template skeleton may refer to the second virtual machine VM2 run-ning the CPM database.

Figure 10 corresponds to steps 550 and 560 of figure 5 and illustrates the revision of the topology template. In a first step, relations between the resource templates may be deleted in order to represent the service topol-ogy correobly. For example, Lhe "hosLed on" relaLiorisliip bebweeri Lhe "CBN App" resource template and the "PHP nodule" resource template is not cor-rect and may be deleted. A "hosted on" relationship between the "CRM App" resource template and the "Apache" resource template may be introduced.

Pjrthermore, two additional relationship types, namely a "depends to" and a "connect to" relationship type may be introduced in order to refine the topology template. The "connect to" relationship type is used to express that the tERM App" resource template connects to the "CERN DB" resource tem-plate and the "CERM App" depends on "PEP Module" resource template.