Method for generating a constraint pattern

WO2026201713A1PCT designated stage Publication Date: 2026-10-01INSTITUT MINES TELECOM TELECOM BRETAGNE +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/EP2026/057567
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2025-03-27
Filing Date
2026-03-18
Publication Date
2026-10-01

Smart Images

  • Figure EP2026057567_01102026_PF_FP_ABST
    Figure EP2026057567_01102026_PF_FP_ABST
Patent Text Reader

Abstract

The invention relates to a computer-implemented method for generating, based on a user requirement, a constraint pattern for identifying computing execution environments useful for said user requirement, the user requirement being expressed: a) at least partially as a consumption of one or more services (2) described in a service catalogue (1), the service catalogue enabling the services in said catalogue to be chosen, b) and by way of a set of non-functional constraints defined by the user, the method comprising the following steps: a) organizing the user requirement in the form of relationships between properties of: i) services, ii) resources (4), iii) and execution environments, b) based on the relationships described in step a), inducing the execution environments useful for fulfilling the requirement, bringing together the induced execution environments so as to automatically generate the constraint pattern.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Description

[0002] Title: Method for generating a constraint pattern

[0003] technical field

[0004] The present invention relates to a method for deploying services across multiple heterogeneous execution environments, particularly in the field of "multicloud" information systems.

[0005] Previous technique

[0006] In the past, software solutions were developed to enable the deployment of services in multicloud environments. However, these solutions are dependent on cloud providers, who dictate resource allocation regardless of user needs.

[0007] Therefore, there is a need for a solution that enables the deployment of services on heterogeneous execution environments, independently of any suppliers or operators linked to the execution environments.

[0008] Summary of the invention

[0009] The invention aims to meet all or part of this need and relates to a computer-implemented method for generating, from a user need, a constraint pattern enabling the identification of computer execution environments useful for said user need.

[0010] The user need having been expressed:

[0011] a) at least partially as the consumption of one or more services described in a service catalogue, the service catalogue allowing the composition of services from said catalogue,

[0012] b) and by means of a set of non-functional constraints defined by the user,

[0013] the process comprising the steps of:

[0014] a) organize the user need in the form of relationships between properties of:

[0015] i) services, ii) resources,

[0016] iii) and execution environments,

[0017] so that:

[0018] Each execution environment holds one or more resources, each execution environment hosts one or more services, and the resources needed must be accessible in at least one execution environment.

[0019] The resources must be required by at least one service instance; each service instance runs in an execution environment; each service instance requires one or more resources accessible within the execution environment in which it runs.

[0020] at least one service being a composite service formed from component services,

[0021] b) the properties of the composite service being derived from the properties of the component services according to propagation rules described in the service catalogue, b) from the relationships described in step a), derive the execution environments useful for fulfilling the requirement,

[0022] gather the induced execution environments to automatically generate the constraint pattern.

[0023] By "constraint pattern", we mean the set of execution environments that satisfy the user's needs.

[0024] Preferably, the process generates a constraint pattern from a user need, enabling the identification of necessary and sufficient computer execution environments for said user need.

[0025] Preferably, the necessary and sufficient resources are accessible in at least one execution environment.

[0026] By "generate by computer," we mean that the process is implemented using any computer means that allows the generation of files, for example, a computer or a processor.

[0027] Advantageously, the method according to the invention makes it possible to meet the user need by composing complex composite services from a set of composite or atomic services that can be characterized independently of resources and execution environments, by functional properties.

[0028] The complete set of properties of services—that is, their functional, non-functional structural, and non-functional non-structural properties—defines a set of constraints that must be respected. It is then possible to determine the resources and execution environments that meet these constraints in order to implement services that fulfill user needs.

[0029] The method according to the invention thus makes it possible to discover resource placements based on user needs rather than on execution environment providers or operators. Indeed, the choice of service placement depends solely on compliance with constraints derived from constraint patterns, which themselves depend only on user needs. Adherence to the constraints of the constraint pattern consequently ensures service portability across heterogeneous execution environments.

[0030] Resources

[0031] Resources are components, including hardware and software, that are useful for fulfilling a user's need. Resources are characterized by two states:

[0032] present, active and accessible

[0033] or absent, inactive, and inaccessible.

[0034] Resources that are useful when needed are resources that are present, active, and accessible.

[0035] Absent, inactive, and inaccessible resources are not useful for fulfilling the user's need.

[0036] A present, active, and accessible resource is exposed by at least one service instance that requires it. A present, active, and accessible resource is accessible within the execution environment in which the service instance exposing it runs.

[0037] A resource that is present, active, and accessible can be exposed by multiple instances of the same service in the same execution environment in which the service instances run. Alternatively, a resource that is present, active, and accessible can be exposed by multiple instances of the same service running in different execution environments.

[0038] A resource that is present, active, and accessible can be exposed by instances of different services running in the same execution environment.

[0039] A resource that is present, active, and accessible can be exposed by different service instances running in different execution environments.

[0040] In the remainder of the description, the term "resource" will implicitly refer to a "present, active and accessible resource".

[0041] A resource is accessible in a runtime environment that holds it or in which a service instance exposing it is running. A resource is not accessible in a runtime environment that does not hold it and in which no service instance exposing it is running.

[0042] A resource is shared if it is exposed by multiple instances of the same service or of different services. For example, a shared resource can be exposed by multiple instances of the same service running in different execution environments.

[0043] At least one resource can be shared between multiple services.

[0044] Resources can be of different kinds.

[0045] Resources can be hardware components, for example CPU processors, GPUs, memory disks..., this list is not exhaustive.

[0046] Independently or in combination with the foregoing and in a preferred embodiment of the invention having application to information systems, the resources may be software or virtual elements, such as IP addresses or MAC addresses, routing tables, network routes, storage systems, partition tables, partitions, file systems, configuration files, this list not being exhaustive.

[0047] At least one resource may be dependent on one or more other resources.

[0048] A resource dependent on one or more other resources can only be active, accessible, and / or present if all the resources on which it depends are active, accessible, and / or present. A resource can be additionally characterized by one or more non-functional properties, for example its location which can be geographical, spatial, or other.

[0049] The properties of a resource can include one or more parameters indicating one or more constraints on its instantiation in execution environments.

[0050] A resource cannot have functional properties.

[0051] At least one resource may have one or more non-functional properties.

[0052] At least one resource, in particular all resources, can be exposed in at least one execution environment by at least one service.

[0053] Services

[0054] A service is a mechanism that provides access to one or more resources, including hardware or software; a service exposes one or more resources. A service runs in an execution environment that gives it access to the resources necessary for its operation.

[0055] One or more services may be composite services.

[0056] A "composite service" is defined as a service made up of one or more component services. Composition relationships, preferably all composition relationships, that link composite services and component services are expressed in the service catalog.

[0057] A "component service" can be an atomic service or a composite service, itself formed from one or more other component services. A component service may be required to form several distinct composite services.

[0058] By "atomic service" we mean a service that consists only of itself.

[0059] An instance of a service runs in a single execution environment. Multiple instances of the same service can run in the same execution environment. Alternatively, multiple instances of the same service can run in different execution environments. At least one instance of a component service can run in a different execution environment than the one in which the instance of the composite service it comprises runs.

[0060] This feature allows service properties to be propagated between different execution environments. This, in turn, enables resource sharing between execution environments. This sharing allows constraints to be propagated between different execution environments without knowledge of those environments.

[0061] A component service may not expose the same resources as the composite service it comprises. In a preferred embodiment of the invention applied to information systems, an example of shared resources to which services are attached are the subnet identifiers of the execution environments of cloud service providers.

[0062] By "service attached to a resource", we mean that the resource is exposed to the service through another service.

[0063] If the resource is made available to the service by the execution environment in which it runs, we say that the service requires the resource.

[0064] Preferably, services are tied to the shared resources they consume.

[0065] A service can expose one or more resources, that is, make them accessible, either directly or via its component services.

[0066] A concrete service is one that directly exposes at least one resource. An abstract service exposes its resources through its component services. Therefore, an abstract service is necessarily a composite service.

[0067] At least one service can expose one or more resources in one or more execution environments different from the one in which it runs.

[0068] Each service can have a set of properties that characterize it. These properties can be:

[0069] functional,

[0070] non-functional structural,

[0071] Non-functional, non-structural properties describe how services operate. They can describe what the service performs in terms of operations. Thus, they can also describe the performance characteristics of these operations. An example of a functional property is specifying the protocol used to communicate with the service.

[0072] A structural non-functional property is defined as identifying resources shared between execution environments that are accessible to the service. In a preferred implementation within the information system, the subnetwork to which the service is attached is an example of a structural non-functional property.

[0073] A non-functional, non-structural property is defined by identifying one or more resources, distinct from those identified in structural properties, that are required by the service. In a preferred implementation within the information system, an example of a non-functional, non-structural property is to specify the execution environment where the service is hosted.

[0074] A service property can have a fixed value that is always known, regardless of the circumstances. Alternatively, a service property can have a value that is only defined during the deployment or instantiation of the service. This property is then identified by a specific identifier that characterizes it. This identifier can be associated with the value that this property takes at the time of deployment or instantiation of the service.

[0075] The properties of composite services can be calculated from the properties of their component services according to propagation rules described in the catalog of generic services and constraints. The concrete value of a property in one service can be propagated to a property in another service according to property value propagation rules.

[0076] Preferably, the functional, non-functional structural and / or non-functional non-structural properties of a composite service propagate to each of its component services.

[0077] Alternatively, the structural non-functional properties and / or non-structural non-functional properties of a composite service may not propagate to at least one of its component services. In particular, the structural non-functional properties and / or non-structural non-functional properties of a composite service may not propagate to a component service that is not attached to the same subnet as the composite service or that is not hosted in the same execution environment as the composite service.

[0078] Functional, non-functional structural and / or non-functional non-structural properties can define a set of constraints to be respected.

[0079] Service catalog

[0080] A service catalog defines a set of services with their composition relationships, as well as the resources required for and produced by the execution of these services.

[0081] Generic constraints can be defined in the service catalog. These generic constraints can be applied when services from the service catalog are executed, regardless of the user's needs.

[0082] Generic constraints can be defined in part by operational constraints of execution environment providers.

[0083] In one implementation of the service catalog, services are composed of interoperable services by definition. Execution environments that use only elements from this service catalog are, by construction, interoperable with each other. "Interoperable" means the ability for services running in different execution environments to produce the expected results together.

[0084] Execution environments

[0085] An execution environment can be a computing environment that exerts constraints on service providers.

[0086] This IT environment can be further characterized by non-technical characteristics, for example the country of establishment.

[0087] In the preferred embodiment of an information system, an execution environment can be a data structure which may include computing means, storage means or communication means, including network, this list not being exhaustive.

[0088] Execution environments allow services to run by providing access to resources. An execution environment can be characterized by one or more non-functional properties. An execution environment cannot have any functional properties.

[0089] A runtime environment can be delivered by an IT service provider.

[0090] Execution environments can be, for example, cloud computing environments or data centers operated under the same operational constraints. A cloud execution environment encompasses the entire hosting environment of the cloud provider. This may include hardware resources, software resources, and network hosting domains.

[0091] At least some of the environments, including all execution environments, may be composed of one or more other execution environments.

[0092] A runtime environment can define non-functional constraints on resources according to dependency rules for the resources.

[0093] A runtime environment can define functional constraints on services according to the composition rules for services.

[0094] At least one execution environment can be characterized by one or more non-functional properties.

[0095] User needs

[0096] A "user need" is a functional need expressed by a user. The set of non-functional constraints defined by the user includes, for example, constraints on the price of the service, or constraints on the location of services for reasons of security, sovereignty, privacy protection, customer requirements, etc., this list being non-exhaustive.

[0097] In one particular embodiment, part of the user requirement is organized in the form of composition relationships between composite services and component services, forming a hierarchy of services.

[0098] step b) comprising the sub-steps consisting of:

[0099] i) traverse the service hierarchy using a recursive traversal process to identify services running in atomic execution environments, ii) create a hierarchy of execution environments supporting this atomic execution environment,

[0100] iii) instantiate, according to the propagation rules described in the catalog of services and generic constraints, a set of properties of the resources, services, and execution environments of this service hierarchy,

[0101] (iv) merge execution environments having identical structural non-functional properties using a merging process.

[0102] Recursive traversal method

[0103] The recursive traversal process can take the following inputs:

[0104] o the service catalogue,

[0105] o the user need, including a tree of execution environments desired by the user as identified in the set of non-functional constraints and the execution environments on which these depend.

[0106] The recursive traversal process starts with the user's need.

[0107] It only traverses the execution environments of the tree.

[0108] For each service 5 hosted on an environment, the process includes the following steps:

[0109] o search the service catalogue for the services required by 5

[0110] o Iterate over the services required by 5. For each required service:

[0111] ■ Retrieve all the functional properties of 5 as defined in the service catalog

[0112] ■ Retrieve all the functional properties of 5 as defined in the user requirement

[0113] ■ Reference all non-functional properties of 5 using the identifier of the execution environment that hosts it

[0114] ■ Call the Error! Referencing Source function, providing the following input parameters: service 5, its retrieved functional and non-functional properties, and the identifier of the execution environment in which 5 is hosted. This function initiates a recursive traversal of the service tree defined in the input catalog, identifying the resources exposed by each of these services.

[0115] Iterate service function

[0116] This function takes three parameters as input:

[0117] • e: the identifier of an execution environment

[0118] • 5: the identifier of the service hosted on e

[0119] • sp: the set of functional and non-functional properties 5

[0120] The function includes the following steps:

[0121] 1. Retrieve definition 5 from the service catalog

[0122] 2. Designate s as a running service

[0123] 3. Add 5 to the execution environment as one of the services managed by that environment

[0124] 4. Search for the services required by service 5.

[0125] 5. If required services exist, iterate over those services. For each required service:

[0126] o The iterate service function builds the functional properties of rs via the propagation rules defined in the service catalog.

[0127] o The `iterate service` function calls itself, with the service type of `rs` and its functional properties constructed in the previous step as parameters:

[0128] ■ If the required service is defined as co-located in the service catalog, it is therefore attached to the same execution environment as the current service.

[0129] ■ if the required service is not defined as co-located:

[0130] ■ Search the service catalogue for the type of environment in which the required service rs runs, ■ Search the execution environment tree for the single execution environment of that type,

[0131] ■ This environment constitutes the environment in which the `iterate service` function is invoked recursively. Calling a function

[0132] Function exposes resources

[0133] 6. The function expose_resources, given as input parameters the service identifier s, its functional and non-functional properties sp, the functional and non-functional properties of its parent service psp, and the identifier of the execution environment in which 5 is hosted e. This function will expose the resources related to service 5.

[0134] Function exposes resources

[0135] The function takes four input parameters:

[0136] • e: the identifier of an execution environment

[0137] • 5: the identifier of the service hosted on e

[0138] • sp: the set of functional and non-functional properties 5

[0139] • psp: the set of functional and non-functional properties of the parent service of 5

[0140] The function includes the following steps:

[0141] 1. Retrieve the properties of the resources exposed by 5 in the service catalog.

[0142] 2. For each exposed resource, instantiate it using its properties retrieved from the execution environment of the current service. This instantiation is done according to the type of environment, the type of resources, and in application of the rules defined in the resource parameters.

[0143] o If, in its definition, an exposed resource has a `known as` property and has been successfully instantiated in the execution environment:

[0144] ■ The exposed resource property concatenated with the content of the known as property takes the value of the reference of the created resource (ref id).

[0145] The exposed resource name properties concatenated with the content of the known as property are subsequently passed to the parent services of the current service

[0146] The recursive traversal process results in a pattern of constraints on the services and resources required to satisfy the user's need. However, constraints on execution environments are not yet taken into account at this stage before the merging process.

[0147] Melting process

[0148] The fusion process in step b) can take the following inputs:

[0149] o The constraint pattern generated following the recursive traversal

[0150] o A set of rules for merging execution environments

[0151] a service catalogue,

[0152] o a user need (including a tree of concrete execution environments and the execution environments on which they depend. Ex: a VM (concrete environment) depends on an L2D which in turn depends on an L3D).

[0153] A merge rule allows you to:

[0154] • identify execution environments that are of the same type and that implement one or more identical resources, and,

[0155] • Group the services and resources implemented in these execution environments to create a single resulting execution environment, thereby consolidating all constraints related to the requirement across these execution environments. An example of a merge rule might be that when a resource belongs to several different but identical execution environments, these execution environments should be merged if their non-functional properties allow it.

[0156] The merger process includes the following steps:

[0157] 1. Traverse all instantiated resources in the constraint pattern generated by the recursive traversal process,

[0158] 2. For each resource:

[0159] a. Identify the pairs of execution environments to be merged. These environments are those of the same type, implementing the same resource, and having non-functional properties that make them eligible for merging. b. Add these pairs to a list L of environments to be merged in a data structure that guarantees the uniqueness of the pairs.

[0160] 3. Traverse the list L. For each pair of execution environments in L:

[0161] a. Designate the first element of this pair as the target environment, and the second element as the source environment. b. Transfer the services and resources from the source environment to the target environment according to the appropriate merge rules. c. Replace the occurrences of the source environment in L with those of the target environment.

[0162] The merging process outputs a constraint pattern that takes into account constraints on execution environments.

[0163] Method for identifying at least one set of execution environments

[0164] The invention also relates, according to another aspect, to a method for identifying at least one set of execution environments conforming to a constraint pattern of a computer system fulfilling a user need, the method comprising the steps of:

[0165] i) generate the constraint pattern from the user requirement using the method described above,

[0166] ii) identify at least one set of execution environments conforming to the constraint pattern.

[0167] Method for generating a deployment pattern

[0168] The invention also relates to a method for generating a deployment pattern from a set of execution environments conforming to the constraint pattern identified by the method for identifying at least one set of execution environments as described above, the method comprising the steps of:

[0169] i) select a set of execution environments from the identified sets, ii) generate the deployment pattern from the selected set of execution environments.

[0170] By "deployment pattern" we mean a method for deploying one or more resources and / or one or more services in one or more given execution environments.

[0171] Method for deploying resources

[0172] The invention, in a final aspect, relates to a method for deploying resources in execution environments from a deployment pattern generated by means of the method for generating a deployment pattern as described above.

[0173] Brief description of the drawings

[0174] The invention will be better understood upon reading the detailed description that follows, the non-limiting examples of its implementation, and upon examination of the attached drawing on which:

[0175] [Fig 1] represents a user need,

[0176] [Fig 2] is a schematic and partial representation of an example of a service catalogue,

[0177] [Fig 3] is a detail of figure 2,

[0178] [Fig 4] is another detail of figure 2,

[0179] [Fig 5] is another detail of figure 2,

[0180] [Fig 6] is another detail of figure 2,

[0181] [Fig 7] is a schematic and partial representation of an example of relationships between services, their resources and their execution environments.

[0182] Detailed description

[0183] Figure 1 illustrates an example of a user need within the meaning of the invention. The user expresses the need for a highly available WordPress application A. The user describes this need for A in a purely functional way by identifying the services necessary for the implementation of A. In a first embodiment, the user may indicate, for example, that the implementation of application A requires the implementation of two service instances: two highly available servers, a MySQL data server B and a web server C.

[0184] Each of these servers requires two load balancers E and D and three associated servers: servers F, G and H for the MySQL server B and K, J and I for the Web server C.

[0185] This user need is characterized by a set of functional constraints specific to the placement of the required services. Indeed, each service required by the user must be hosted in a specific execution environment whose provider and location are specified. In the example described in Figure 1,

[0186] The EE_6 service is provided by the cloud service provider AWS and is located in France.

[0187] The EE_7 service is provided by the cloud service provider AZURE and is located in Germany.

[0188] The EE_8 service is provided by the cloud service provider AZURE and is located in Germany.

[0189] The EE_2 service is provided by the cloud service provider AZURE and located in Germany, in the domain "L2D 001",

[0190] The EE_7 service is provided by the cloud service provider AWS and located in France, in the domain "L2D 001",

[0191] The EE_5 service is provided by the cloud service provider AZURE and is located in Germany.

[0192] The EE_4 service is provided by the cloud service provider AZURE and is located in France.

[0193] and the EE_3 service is provided by the "cloud" service provider AWS and located in France.

[0194] In a second embodiment, however, the user may not know what the implementation of application A requires. They can then describe the required composition based on a service catalog, as shown in Figures 2 to 6.

[0195] Thus, if the user does not have the necessary information, the method according to the invention can determine it automatically. The service catalogue 1 of figure 2 describes twenty-two services 2, each represented by a rectangle.

[0196] The arrows in Figure 2 connecting the rectangles illustrate the composition relationships between services and create a compositional structure. For example, the MySQL server proxy service is a composite service, made up of two component services: the MySQL server service, which is an atomic service, and the Layer 3 connectivity service, which is itself a composite service.

[0197] The Layer 3 connectivity service is required by several composite services: the MySQL server proxy service, the RoutedRproxy service, and the Web server proxy service.

[0198] Among the twenty-two services in the catalogue in Figure 2, seven services are concrete services 3 that expose resources 4 directly, such as the L2Bridging service which directly exposes the subnet resource.

[0199] Fifteen of the services 2 are abstract services 5 that expose resources via component services, for example the L3Routing service exposes resources of type L3Address, subnet, and L3SimpleRoute through its component services.

[0200] Each service 2 has functional, non-functional structural and non-functional non-structural properties.

[0201] For the high-availability MySQL Server service, the `protocol` property, which specifies which protocol to use to communicate with the service, is an example of a functional property. The `subnet-id` property, which defines the subnet to which the service is attached, is an example of a structural, non-functional property.

[0202] For the Layer 2 Connectivity Service, the ref-id property is an example of a property with a concrete value 6 and the subnet id property is an example of a property whose value is only defined at service instantiation 7.

[0203] The L2Bridging service is an example of service 8 which is not hosted in the same environment as its composite service, the layer 2 connectivity service, and for which there is therefore no propagation of structural non-functional properties and non-structural non-functional properties, but there is propagation of the functional property protocol. Figure 3 schematically and partially represents an example of relationships between service properties, their resources and their execution environments, as defined in step a) of the process.

[0204] A runtime environment hosts a service and possesses a resource. The runtime environment is characterized by a non-functional property.

[0205] The service exposes and requires the resource.

[0206] The resource may be dependent on resources of different types (network, road, volume, storage, ...).

[0207] The invention is not limited to the examples previously described.

Claims

Demands 1. A computer-implemented process for generating, from a user need, a constraint pattern that identifies useful computer execution environments for said user need. The user need having been expressed: (a) at least partially as consumption of one or more services (2) described in a service catalogue (1), the service catalogue allowing the composition of services from said catalogue, b) and by means of a set of non-functional constraints defined by the user, the process comprising the steps of: a) organize the user need in the form of relationships between properties of: i) services, ii) resources (4), iii) and execution environments, so that: Each execution environment holds one or more resources, each execution environment hosts one or more services, and the resources needed must be accessible in at least one execution environment. The resources must be required by at least one service instance; each service instance runs in an execution environment; each service instance requires one or more resources accessible within the execution environment in which it runs. at least one service being a composite service formed from component services, The properties of the composite service are derived from the properties of the component services according to propagation rules described in the service catalog. b) from the relationships described in step a), induce the execution environments useful for fulfilling the need, assemble the induced execution environments to automatically generate the constraint pattern.

2. Method according to the preceding claim, at least one resource (4) having one or more non-functional properties.

3. A method according to any one of the preceding claims, wherein at least one execution environment is characterized by one or more non-functional properties.

4. A method according to any one of the preceding claims, at least one resource (4), in particular all resources, being exposed in at least one execution environment by at least one service.

5. A method according to any one of the preceding claims, at least one resource (4) being dependent on one or more other resources.

6. A method according to any one of the preceding claims, at least one service (2) exposing one or more resources in one or more execution environments different from the one in which it runs.

7. A method according to any one of the preceding claims, at least one resource (4) being shared between several services.

8. Method according to the preceding claim, the services (1) being attached to the shared resources (4) which they consume.

9. A method according to any one of the preceding claims, wherein at least a part of the environments, in particular all execution environments, are composed of one or more other execution environments.

10. A method according to any one of the preceding claims, whereby at least one instance of a component service runs in a different execution environment from that in which the instance of the composite service (2) that it composes runs.

11. A method according to any one of the preceding claims, wherein a portion of the user requirement is organized in the form of composition relationships between composite services (2) and component services, forming a hierarchy of services, step b) comprising the substeps of: i) traverse the service hierarchy using a recursive traversal process to identify services running in atomic execution environments, ii) create a hierarchy of execution environments supporting this atomic execution environment, iii) instantiate, according to the propagation rules described in the service catalogue (1) and generic constraints, a set of properties of the resources, services and execution environments of this service hierarchy, (iv) merge execution environments having identical structural non-functional properties using a merging process.

12. A method according to any one of the preceding claims, wherein the execution environments are cloud computing environments; (“Cloud”) or data centers operated under the same operating constraints.

13. A method for identifying at least one set of execution environments conforming to a constraint pattern of a computer system fulfilling a user need, the method comprising the steps of: i) generate the constraint pattern from the user requirement by means of the method according to any one of the preceding claims, ii) identify at least one set of execution environments conforming to the constraint pattern.

14. A method for generating a deployment pattern from a set of execution environments conforming to the constraint pattern identified by the method for identifying at least one set of execution environments according to the preceding claim. i) select a set of execution environments from the identified sets, ii) generate the deployment pattern from the selected set of execution environments.

15. Method for deploying resources in execution environments from a deployment pattern generated by means of the method for generating a deployment pattern according to the preceding claim.