WO2019223867A1 - Service orchestrator for model-driven workflow generation - Google Patents

Service orchestrator for model-driven workflow generation Download PDF

Info

Publication number
WO2019223867A1
WO2019223867A1 PCT/EP2018/063605 EP2018063605W WO2019223867A1 WO 2019223867 A1 WO2019223867 A1 WO 2019223867A1 EP 2018063605 W EP2018063605 W EP 2018063605W WO 2019223867 A1 WO2019223867 A1 WO 2019223867A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
model
workflow
orchestrator
dependency
Prior art date
Application number
PCT/EP2018/063605
Other languages
French (fr)
Inventor
Janakiraman THIYAGARAJAH
Gianluca PUGGELLI
Peng Lv
Luca De Matteis
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP18727260.4A priority Critical patent/EP3743811A1/en
Priority to PCT/EP2018/063605 priority patent/WO2019223867A1/en
Publication of WO2019223867A1 publication Critical patent/WO2019223867A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration

Definitions

  • the present invention relates to the field of service fulfillment in information and communication technology (ICT). More specifically, the present invention relates to a service orchestrator for model-driven workflow generation, wherein the workflow is generated based on a service model.
  • the service model is compliant with a meta model.
  • the present invention also relates to a method, a computer program product and a system for model-driven service orchestration.
  • Service orchestrators arrange, sequence, and implement tasks based on rules and policies to coordinate creation, modification, or removal of logical and physical resources in a managed environment, e.g. a data center.
  • Service orchestration is an application responsible for assembly of complex, multi-faceted telecom or IT services in repeatable loops. Its primary function is the automation of end-to-end service instance provisioning activities.
  • Network functions are e.g. deployed on a virtual infrastructure, e.g. in data centers.
  • a data center environment has a large number of dynamic infrastructure elements such as physical elements (storage, servers, CPUs), logical elements, or virtual elements, which interact to deliver services such as email, firewall, DNS, intrusion detection, etc.
  • Static mapping of infrastructure and application components i.e. the physical, logical or virtual elements
  • Dynamic virtualized systems and cloud computing environments have created an environment where these mappings can change rapidly at any time.
  • Rapid deployment of a virtualized infrastructure or an automated migration of virtual machines in response to fluctuating demand for application services, for example, may lead to a change in the mapping of the virtual elements to the physical elements.
  • systems and methods are built to update the policies at runtime.
  • the policies applied at mntime are not effectively defined to consider various possible relationship of one component on another.
  • US 20140372533 Al discloses an apparatus, systems, and methods for cloud agnostic multi-tier application modeling and deployment.
  • the method discloses to obtain dependency information for each component in a system, wherein the dependency information for a component comprises information indicating prerequisites for starting the component.
  • Each component in the multiple components is started based on a starting sequence derived, in part, from the dependency information.
  • a graphical user interface (GUI) representing the dependency information is disclosed.
  • This solution however has the following drawbacks: It captures the dependency information only for starting the services and considers primarily location dependencies or VM co-location information. It doesn’t capture various other dependencies required in a fulfillment process.
  • the dependency and configuration information is captured template driven, which is pre-defined. That is, the dependency and configuration information capturing and processing can’t be adapted to a user’s needs automatically.
  • US 20170201569 Al discloses an apparatus, systems and methods for automatic distributed application deployment in heterogeneous environments. It is disclosed how to facilitate distributed orchestration and deployment of a cloud based distributed computing application. The disclosure however does not consider obtaining dependency information that is various enough according to a user’s need. Further, no automatic workflow generation for orchestration is disclosed. Instead, a template- and rule-based approach is suggested. This requires cloud agents to provide context information pre-configured in templates, which is not desired by a user.
  • the present invention aims to improve the conventional service orchestrator.
  • the present invention has the objective to provide a model-driven service orchestrator that uses a service description based on a predefined meta- model that does not require specific scripts or command to generate the required orchestration workflow.
  • the service orchestrator can use a meta-model of a domain in which the service orchestrator is applied, wherein the meta-model specifies service-model syntax and service-model semantics.
  • the service orchestrator is configured to generate an orchestration workflow according to a user defined service model, rather than hardcoding a workflow or a part of it into scripts or templates.
  • a service designer thus can describe a service, its dependencies and how it behaves without the need to specify which particular process is used to obtain such behavior of the service.
  • the service composition and behavior are provided in form of a model that is compliant with the service orchestrator’ s meta- model.
  • orchestration workflows are deduced from the service-model that describe the service using predefined semantics.
  • the service-model can be converted into a dependency graph that can be manipulated to retrieve an operation order of the workflow (which may include parallel tasks).
  • Model is an artificial concept that can be used to express information, knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.
  • a model is a representation of a system using general rules and concepts. This can e.g. be unified modeling language (UML).
  • UML unified modeling language
  • the model as used in the present invention also supports the concepts of model and meta-model according to the Meta Object Facility (MOF).
  • MOF Meta Object Facility
  • Entity A logic representation in a model of an element that is included in the scope of a system.
  • An entity may have properties. It can go through changes during its lifecycle.
  • An entity can e.g. be a service, a resource, or any kind of product (i.e. a contract good).
  • Activation A process that makes a resource or service operationally available with a requested configuration.
  • Resource Controller A logical layer abstracting resources under its control. The purpose of a controller is to present a common interface for the management of resources.
  • Creation Request A request to create a service instance from a service type, including parameters to meet dependencies and its configuration.
  • Service Fulfillment A process responsible for assembling and making services available to subscribers, tenants and 3rd parties.
  • Orchestrator A logical layer abstracting and automating the fulfillment of complex service operations and requests from subscribers, tenants and 3rd parties, in an operator’s network or management domain.
  • Plan A series of steps that represent a workflow with the purpose of fulfilling an orchestration request within the context of existing services and resources at the time of a plan's creation.
  • a plan is a decomposition into steps for the fulfillment of a service request based on a service model and a resource requirement.
  • Policy A policy is a formal statement whose purpose is to govern the management of services and resources during their life-cycle. It controls or modifies how a service or resource operation is fulfilled and how the service is formed. It manages life-cycle events in the scope of a service or resource.
  • Provisioning The action of providing resources for a resource request to support a service.
  • Resource A resource is an element in an enterprise’s infrastructure utilized by a service or a goods procured by the market in the form of product. Services are generally hosted on resources.
  • a service is a realization of a product or something provided in support of a product. It represents the technical or engineering and implementation view of the product. Product offering is sold to customers, and service is implemented to help realize this product. More specifically, a customer facing service (CFS) is a part of a product that is bought by a customer, while a resource facing service (RFS) is indirectly part of a product but is invisible to a customer; it exists to support one or more CFSs.
  • CFS customer facing service
  • RFS resource facing service
  • Service Instance / entity instance A logical representation of a mnning service that has started its life-cycle, and thus has resources allocated to it. The resources may be just reserved or provisioned, but an allocation has taken place. Service instances are available in the inventory either as a resource reservation or as a mnning instance. An instance in particular is a logical or physical representation of an entity, that is described in a model.
  • a managed execution of a plan s steps through which a request is being fulfilled.
  • the steps may be sequential, parallel, distmsted, local, optional, automated, or manual. It is the job of the workflow to organize and determine the execution of the steps and ensure the reliability and correctness of the execution. If a workflow cannot be successfully executed, the affected systems must always be in a consistent state.
  • a first aspect of the present invention provides a service orchestrator for model-driven workflow generation, wherein the service orchestrator comprises a processor configured to obtain a service-model that complies with a predefined meta-model, wherein the meta model specifies service-model syntax and service-model semantics, and generate a workflow based on the service-model and in compliance with the service-model semantics, wherein the service-model defines a composition and/or behavior of a service, the service- model syntax specifies information provided by the service and a format of the provided information, the service-model semantics define a procedure for generating the workflow, and the generated workflow comprises a procedure for creating and/or operating a service instance of the service.
  • the service orchestrator comprises a processor configured to obtain a service-model that complies with a predefined meta-model, wherein the meta model specifies service-model syntax and service-model semantics, and generate a workflow based on the service-model and in compliance with the service-model semantics, wherein the service-model defines a
  • the service orchestrator automatically generates fulfillment workflows based on a predefined meta-model and semantics without the need for hardcoded scripts, commands or templates. This is beneficial, as there is no effort required for the development of scripts or templates that need to be developed for each service. In particular, a reduced effort is needed by service orchestrator vendors and customers to define new services; reduced operational cost for complex service management can be achieved; service models and definitions can be reused; and an increased service portability across different environments is achieved.
  • the service- model further includes an operating logic of a service and the service orchestrator is further configured to generate the workflow based on the operating logic.
  • the meta-model defines at least one dependency among service instances or among services.
  • the at least one dependency is an implicit dependency derived from a meta-class, and/or an explicit dependency pre-defined by the meta-model.
  • the meta-class is an element defined by the meta-model.
  • generating the workflow includes processing to convert the service-model into a dependency graph.
  • the processing to convert the service- model into a dependency graph is further based on the service-model semantics.
  • the at least one dependency relates to a node and/or an edge resulting in the dependency graph.
  • generating the workflow further includes processing the dependency graph to obtain a list of tasks representing the workflow.
  • processing the dependency graph includes applying a direct or reverse topological sorting algorithm to the dependency graph and/or includes applying an optimization algorithm, particularly a Coffman- Graham algorithm, to the dependency graph.
  • the list of tasks includes sequential and/or parallel tasks and/or sub tasks.
  • the generated workflow is a design stage workflow, or a resource availability and constraints verification stage workflow, or a resource reservation stage workflow, or a service instance provisioning stage workflow; wherein in the design stage workflow, a service instance structure is defined; wherein in the resource availability and constraints verification stage workflow, availability of required resources and/or compliance with constraints is verified; wherein in the resource reservation stage workflow, the required resources are reserved; and wherein in the service instance provisioning stage workflow, a service instance is created and/or configured.
  • a second aspect of the present invention provides a method for operating a service orchestrator for model-driven workflow generation, the method comprising the steps of obtaining a service-model that complies with a predefined meta-model, wherein the meta model specifies service-model syntax and service-model semantics, and generating a workflow based on the service-model and in compliance with the service-model semantics, wherein the service-model defines a composition and/or behavior of a service, the service- model syntax specifies information provided by the service and a format of the provided information, the service-model semantics define a procedure for generating the workflow, and the generated workflow comprises a procedure for creating and/or operating a service instance of the service.
  • the service-model further includes an operating logic of a service and the method further includes generating the workflow based on the operating logic.
  • the meta- model defines at least one dependency among service instances or among services.
  • the at least one dependency is an implicit dependency derived from a meta-class, and/or an explicit dependency pre-defined by the meta-model.
  • the meta-class is an element defined by the meta-model.
  • generating the workflow includes processing to convert the service-model into a dependency graph.
  • processing to convert the service-model into a dependency graph is further based on the service-model semantics.
  • the at least one dependency relates to a node and/or an edge resulting in the dependency graph.
  • generating the workflow further includes processing the dependency graph to obtain a list of tasks representing the workflow.
  • processing the dependency graph includes applying a direct or reverse topological sorting algorithm to the dependency graph and/or includes applying an optimization algorithm, particularly a Coffman- Graham algorithm, to the dependency graph.
  • the list of tasks includes sequential and/or parallel tasks and/or sub tasks.
  • the generated workflow is a design stage workflow, or a resource availability and constraints verification stage workflow, or a resource reservation stage workflow, or a service instance provisioning stage workflow; wherein in the design stage workflow, a service instance structure is defined; wherein in the resource availability and constraints verification stage workflow, availability of required resources and/or compliance with constraints is verified; wherein in the resource reservation stage workflow, the required resources are reserved; and wherein in the service instance provisioning stage workflow, a service instance is created and/or configured.
  • the method of the second aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
  • a third aspect of the present invention provides a computer program product comprising a program code for controlling a service orchestrator according to the first aspect or any of its implementation forms or for performing, when running on a computer, the method according to the second aspect or any of its implementation forms.
  • the computer program product of the third aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
  • a fourth aspect of the present invention provides a system comprising the service orchestrator according to the first aspect or any of its implementation forms, a service- model storage configured to provide a service-model to the service orchestrator, a service- instance storage, and at least one infrastructure element management system, configured to create, operate or control at least one infrastructure element hosted in an infrastructure element system, according to the workflow generated by the service orchestrator, to provide a service instance to the service-instance storage.
  • the system of the fourth aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
  • a fifth aspect of the present invention provides a method for operating a system comprising the service orchestrator according to the first aspect or any of its implementation forms, a service-model storage configured to provide a service-model to the service orchestrator, a service-instance storage, and at least one infrastructure element management system, the method comprising the steps of creating, operating or controlling, by the at least one infrastructure element management system, at least one infrastructure element hosted in an infrastructure element system, according to the workflow generated by the service orchestrator, to provide a service instance to the service-instance storage.
  • the method of the fifth aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
  • FIG. 1 shows a schematic view of a service orchestrator according to an embodiment of the present invention.
  • FIG. 2 shows a schematic view of a service orchestrator according to an embodiment of the present invention in more detail.
  • FIG. 3 shows a schematic view of a value dependency meta-model.
  • FIG. 4 shows a schematic view of semantics for aggregation dependency conversion into nodes and edges.
  • FIG. 5 shows a schematic view of semantics for value dependency conversion into nodes and edges.
  • FIG. 6 shows a schematic view of an example for value dependency conversion into nodes and edges.
  • FIG. 7 shows a schematic view of a dependency graph according to the present invention.
  • FIG. 8 shows a schematic view of stages in service orchestration.
  • FIG. 9 shows a schematic view of a workflow according to the present invention.
  • FIG. 10 shows a schematic view of a service orchestrator according to an embodiment of the present invention in more detail.
  • FIG. 11 shows a schematic view of a method according to an embodiment of the present invention.
  • FIG. 12 shows a schematic view of a system according to the present invention.
  • FIG. 13 shows another schematic view of a system according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS
  • FIG. 1 shows a schematic view of a service orchestrator 100 for model-driven workflow generation according to an embodiment of the present invention.
  • the service orchestrator 100 comprises a processor 101, which is configured to obtain a service-model 102.
  • the service-model 102 complies with a predefined meta- model 103, which specifies service- model syntax 104 and service-model semantics 105.
  • the service-model 102 is created, e.g. by a service designer (i.e. by user input) before it is obtained by the service orchestrator 100. That is, the compliance with the meta-model 103 is established during creation of the service-model 102.
  • the service orchestrator 100 however can, but does not need to, check the service-model 102 for compliance with the meta-model 103, and therefore can also obtain the meta- model 103.
  • the service-model 102 defines a composition and/or behavior of a service 107.
  • the service- model syntax 104 specifies information provided by the service 107 and a format of the provided information.
  • the service-model semantics 105 define a procedure for generating a workflow 106.
  • the models as used in the present invention in particular relate to the concept of model and meta-model according to the MOF.
  • a meta-model 103 (that corresponds to an M2 level of the MOF) is a
  • “language” used to define a service-model 102 (and also used to define a resource-model, since the service orchestrator 100 can as well be used to orchestrate resources, not only services; in particular, all functions that are described in this document regarding services 107 can be applied to resources - e.g. any kind of hardware resources in a datacenter - as well). It includes syntax and semantics.
  • a service-model 102 (that corresponds to an Ml level of the MOF) is a specific logical service 107 definition compliant with the meta model 103.
  • a resource-model (that corresponds to an Ml level of the MOF) is a specific logical infrastructure element definition compliant with the meta-model 103. It also can be associated with an infrastructure element management system (e.g.
  • a service-instance 108 (that corresponds to an M0 level of the MOF) is a concrete instance (i.e. a virtual or physical realization) corresponding to a service 107 defined in the service- model 102.
  • a resource-instance (that corresponds to an M0 level of the MOF) is a concrete instance of an infrastructure element defined in a model.
  • the processor 101 of the service orchestrator 100 is further configured to generate a workflow 106 based on the service-model 102 and in compliance with the service-model semantics 105.
  • the service-model semantics 105 in particular specify an algorithm for generating the workflow 106.
  • the generated workflow 106 comprises a procedure for creating and/or operating a service instance 108 of the service 107.
  • the generated workflow 106 allows for service orchestration based on a service model, in that it enables to generate or control a service instance 108 of the service 107, by the information contained in the workflow 106.
  • FIG. 2 shows a schematic view of a service orchestrator 100 according to an embodiment of the present invention in more detail.
  • the service orchestrator 100 of Fig. 2 is based on the service orchestrator 100 of Fig. 1 and therefore includes all of its function and features. To this end, identical features are labelled with identical reference signs. All features that are now going to be described in view of Fig. 2 are optional features of the service orchestrator 100.
  • the service- model 102 optionally includes an operating logic 201 of a service 107, and the service orchestrator 100 is further configured to generate the workflow 106 based on the operating logic 201. That is, the operating logic 201 describes how the service 107 is composed and how it behaves in order to carry out a predefined operation (e.g. a web- server, an email-server, a virtual private network (VPN) connection, a network connection, etc.) for example a desired business logic according to a predefined use case.
  • a predefined operation e.g. a web- server, an email-server, a virtual private network (VPN) connection, a network connection, etc.
  • the meta-model 103 defines at least one dependency 202 among service instances 108 or among services 107.
  • Dependencies of a service 107 or service instance 108 are in particular defined in a configuration element of the service 107.
  • the meta- model 103 may define several types of dependencies 202. Some of them can be defined implicitly in a meta-class 203, others can be defined explicitly by a designer (e.g. a user).
  • the at least one dependency 202 can be an implicit dependency derived from a meta-class 203, and/or an explicit dependency 204 pre-defined by the meta-model 103.
  • the meta-class 203 in particular may be an element defined by the meta-model 103, e.g. according to MOF.
  • Element aggregation or composition This is an implicit dependency that is automatically established between two elements, when one element is composed by another one or when it aggregates another one.
  • Creation operation This is an implicit dependency that is automatically established between a create operation and the elements that it can create.
  • Generic dependency This is an explicit dependency that is established by a designer between two sets of elements.
  • Value dependency This is an explicit dependency that is established by the designer between one client element and a set of supplier’s elements. The value of the client is calculated with a function from the values of the suppliers.
  • Transition operation dependency This is an explicit dependency that is established by the designer between one client operation invocation and a supplier state transition. When the transition is performed, then the operation invocation is executed.
  • Operation transition dependency This is an explicit dependency that is established by the designer between on client transition and a supplier operation. When the operation is executed, then the transition is performed.
  • Operation dependency This is an explicit dependency that is established by the designer between one client operation invocation and another supplier operation. When the supplier operation is executed, then the client operation invocation is executed as well.
  • Transition dependency This is an explicit dependency that is established by the designer between one client transition and another supplier transition. When the supplier transition is performed, the also the client transition is performed.
  • Status bounce dependency This is an explicit dependency that is established by the designer between one operation and two states of a state machine. To execute the operation that element that own it has to move from one state to another before execute the operation and then when finished to move back to the original state.
  • Subordinate dependency This is an explicit dependency that is established between a scalar client element and a vector supplier element. This dependency for the instantiation of many client element instances as the number of vector supplier element size.
  • Fig. 3 shows a value dependency meta-model.
  • a value dependency is a relationship that signifies that a model element requires the value of another model element for its specification or implementation.
  • the value dependency can be used to model dependencies among attributes, operation results and operation arguments.
  • a dependency graph is generated from the service-model 102.
  • the dependencies 202 defined in the meta-model 103 for the service model 102 of a given service 107 are considered. Every specific meta- model 103 dependency 202, when used in a service-model 102, is mapped into at least one node 401 and/or at least one edge 402 in a dependency graph. That is, generating the workflow 106 includes processing to convert the service- model 102 into a dependency graph 403.
  • these implicit dependencies 202 map into a direct edge 402 directed from an owned element to an owner, as e.g. shown in Fig. 4 (which shows a semantic for aggregation dependency conversion to nodes 401 and edges 402).
  • this explicit dependency 202 maps into a direct edge from a client to a supplier.
  • the dependency itself can in particular be mapped as a node 501, 601 in the middle, as e.g. shown in Fig. 5 (which shows a semantic for value dependency conversion to nodes 501 and edges 502), and Fig. 6 (which shows an example for value dependency conversion to nodes 601 and edges 602).
  • the at least one dependency 202 relates to a node 401, 501, 601 and/or an edge 402, 502, 602 resulting in the dependency graph 403, 503, 603.
  • Fig. 7 shows an example of a dependency graph 700 that can result from the above described conversion.
  • service orchestration is an application responsible for assembly of complex, multi-faceted telecom or IT services into repeatable loops. Its primary function is automation of end-to-end service instance 108 provisioning activities. Service orchestration is responsible for realization of a service instance 108 for a given service 107.
  • an overall orchestration process optionally may be composed of different stages as shown in Fig. 8. Each stage allows the generation of a workflow for the stage in which the orchestration process takes place, wherein the single workflows can be arbitrarily combined.
  • the dependency graph 700 for the service instance 108 is taken as an input in the workflow generation.
  • the dependency graph 700 is used to generate information about a target service instance 108 that needs to be created or modified.
  • a service instance structure is defined.
  • the dependency graph 700 is used to generate a workflow to verify that the resources used by the target service instance 108 are available and can be allocated. In other words, availability of required resources and/or compliance with constraints is verified.
  • the dependency graph 700 is used to generate a workflow to reserve the resources needed by the target service instance 108. In other words, the required resources are reserved.
  • the dependency graph 700 is used to generate a workflow to create/modify the resources needed/used by the target service instance 108. In other words, a service instance is created and/or configured.
  • Generating any one of said workflows includes sorting the dependency graph using a reverse topological sorting algorithm. This result in a sequential list of tasks 900, as it is e.g. shown in Fig. 9. Subsequently, the workflows can be combined to obtain the complete workflow 106. The sequential order obtained by the reverse topological sorting algorithm is not optimized. Some of the tasks are independent and can be executed in parallel. An optimization algorithm can be applied to obtain a workflow that takes care of sequential constraints and also allows for possible parallelization. That is, the resulting list of tasks 900 can include sequential and/or parallel tasks and/or subtasks.
  • Fig. 10 shows a schematic view of a service orchestrator 100 according to an embodiment of the present invention in more detail.
  • the service orchestrator 100 of Fig. 10 is based on the service orchestrator 100 of Figs. 1 and 2 and therefore includes all of their function and features. To this end, identical features are labelled with identical reference signs. All features that are now going to be described in view of Fig. 10 are optional features of the service orchestrator 100.
  • the service orchestrator 100 uses a user defined service-model 102 (also referred to as service and resource model) to perform management operations that require coordination of various parts on which services 107 and resources are decomposed. These models must be compliant with a meta-model 103 (also referred to as service and resource meta-model) and follow its semantics 105.
  • service-model 102 also referred to as service and resource model
  • meta-model 103 also referred to as service and resource meta-model
  • the meta-model 103 describes in detail which elements belong to a domain of the service orchestrator 100 and how they are composed to carry out a services 107 business logic.
  • the meta-model 103 incorporates precise semantics 105 on how the service orchestrator 100 interprets various constructs and dependencies.
  • the meta-model 103 can be formalized in UML but a domain specific language (DSL) is provided to facilitate a service description.
  • DSL domain specific language
  • a service designer 1001 is a tool used by a designer (i.e. a user) to define the service- model 102.
  • a master catalog 1002 (also referred to as storage) stores the service-model 102 (or the service- and resource model) defined by the service designer 1001.
  • the service orchestrator 100 obtains the service-model 103 by reading it from the master catalog 1302.
  • the service orchestrator 100 further includes the following sub-units:
  • a request handler (not shown) receives a request for service instance creation and sends the request to the service instance designer 1003 to design the service instance 108.
  • the service instance designer 1003 receives the service instance creation request with input parameters for the service instance 108. Then, it reads the service model 102, and creates the service instance 108 with all the subordinate service instances and resource instance details and dependencies.
  • the dependency graph 700 is created for the service instance 108 by this component considering all dependencies for the service instance 108. This dependency graph 700 is used to generate information about the target service instance 108 that needs to be created or modified.
  • the service orchestrator further includes the following planners (i.e. planning units):
  • a verification planner 1005 uses the dependency graph 700 received from the service instance designer 1003 to generate the workflow to verify that the resources used by the target service instance 108 are available and can be allocated.
  • a reservation planner 1006 uses the dependency graph 700 received from the service instance designer 1003 to generate the workflow to reserve the resources needed by the target service instance 108.
  • a provisioning planner 1004 uses the dependency graph 700 received from the service instance designer 1003 to generate the workflow to create/modify the resources needed/used by the target service instance 108.
  • a workflow engine 1007 is responsible for execution of a workflow 106 generated by the planners and feeds back the results.
  • FIG. 11 shows a schematic view of a method 1100 according to an embodiment of the present invention.
  • the method 1100 is for operating the service orchestrator 100 and thus enables for model-driven workflow generation.
  • the method 1100 comprises a first step of obtaining 1101 a service-model 102 that complies with a predefined meta-model 103, wherein the meta-model 103 specifies service-model syntax 104 and service-model semantics 105.
  • the method 1100 further comprises a second step of generating 1102 a workflow 106 based on the service-model 102 and in compliance with the service-model semantics 105, wherein the service-model 102 defines a composition and/or behavior of a service 107, the service-model syntax 104 specifies information provided by the service 107 and a format of the provided information, the service-model semantics 105 define a procedure for generating the workflow 106, and the generated workflow 106 comprises a procedure for creating and/or operating a service instance 108 of the service 107.
  • Fig. 12 shows a system 1200 according to an embodiment of the present invention.
  • the system 1200 comprises the service orchestrator 100 as described in any one of the figures above.
  • the system 1200 further comprises a service-model storage 1201 (also referred to as master catalog 1002) that is configured to provide a service-model 102 to the service orchestrator 100.
  • the system further comprises a service-instance storage 1202, and at least one infrastructure element management system 1203 that is configured to create, operate or control at least one infrastructure element 1204 hosted in an infrastructure element system 1205, according to the workflow 106 generated by the service orchestrator 100, to provide a service instance 108 to the service-instance storage 1202.
  • Fig. 13 shows a system 1300 according to an embodiment of the present invention in more detail.
  • the system 1300 comprises the service orchestrator 100 as described in any one of the figures above.
  • the system 1300 includes all functions and features of the system 1200 and in particular mentions examples of the service-model storage 1201 (also referred to as master catalog 1002), the service-instance storage 1202, the at least one infrastructure element management system 1203, the at least one infrastructure element 1204, and the infrastructure element system 1205 as labelled in Fig. 13.
  • the service-model storage 1201 also referred to as master catalog 1002
  • the service-instance storage 1202 also referred to as master catalog 1002
  • the service-instance storage 1202 also referred to as master catalog 1002
  • the service-instance storage 1202 also referred to as master catalog 1002
  • the service-instance storage 1202 also referred to as master catalog 1002
  • the at least one infrastructure element management system 1203 the at least one infrastructure element 1204
  • the infrastructure element system 1205 as labelled in
  • a workflow can be generated by using only sub-ordinate / aggregate dependency relationship information and then add other functions by scripts, plugins or templates.
  • the workflow can be directly generated from the service-model 102.
  • the dependency graph is just an intermediate step, which can be suppressed or hidden from visibility.
  • the sub-components mentioned i.e. the service instance designer, the different planners, the workflow engine
  • the respective functionality can be compressed to one step.
  • the present invention is not limited to the field of service orchestration, but can be adapted to any field that involves workflow generation and that can be described using the models according to the present invention.
  • a model for an entity in a workflow in the automation system can be defined equivalent to the service model (which is defined as an exemplary reference in this document) and its dependencies and thus, the workflow of the automation system can be generated from a model according to the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The present invention provides a service orchestrator (100) for model-driven workflow generation, wherein the workflow (106) is generated based on a service model (102). The service model (102) is compliant with a meta model (103). The service orchestrator (100) comprises a processor (101) configured to obtain a service-model (102) that complies with a predefined meta-model (103), wherein the meta-model (103) specifies service-model syntax (104) and service-model semantics (105), and generate a workflow (106) based on the service- model (102) and in compliance with the service-model semantics (105), wherein the service- model (102) defines a composition and/or behavior of a service (107), the service-model syntax (104) specifies information provided by the service (107) and a format of the provided information, the service-model semantics (105) define a procedure for generating the workflow (106), and the generated workflow (106) comprises a procedure for creating and/or operating a service instance (108) of the service (107).

Description

SERVICE ORCHESTRATOR FOR
MODEL-DRIVEN WORKFLOW GENERATION
TECHNICAL FIELD
The present invention relates to the field of service fulfillment in information and communication technology (ICT). More specifically, the present invention relates to a service orchestrator for model-driven workflow generation, wherein the workflow is generated based on a service model. The service model is compliant with a meta model. The present invention also relates to a method, a computer program product and a system for model-driven service orchestration.
BACKGROUND
In the prior art, conventional service orchestrators arrange, sequence, and implement tasks based on rules and policies to coordinate creation, modification, or removal of logical and physical resources in a managed environment, e.g. a data center. Service orchestration is an application responsible for assembly of complex, multi-faceted telecom or IT services in repeatable loops. Its primary function is the automation of end-to-end service instance provisioning activities.
In recent years, network functions virtualization (NFV) and software defined networking (SDN) adoption is increasing significantly. Network functions are e.g. deployed on a virtual infrastructure, e.g. in data centers. A data center environment has a large number of dynamic infrastructure elements such as physical elements (storage, servers, CPUs), logical elements, or virtual elements, which interact to deliver services such as email, firewall, DNS, intrusion detection, etc. Static mapping of infrastructure and application components (i.e. the physical, logical or virtual elements) to services is used in the prior art. Dynamic virtualized systems and cloud computing environments have created an environment where these mappings can change rapidly at any time. Rapid deployment of a virtualized infrastructure or an automated migration of virtual machines in response to fluctuating demand for application services, for example, may lead to a change in the mapping of the virtual elements to the physical elements. To address the dynamic nature of the environment, systems and methods are built to update the policies at runtime. However, the policies applied at mntime are not effectively defined to consider various possible relationship of one component on another.
US 20140372533 Al discloses an apparatus, systems, and methods for cloud agnostic multi-tier application modeling and deployment. The method discloses to obtain dependency information for each component in a system, wherein the dependency information for a component comprises information indicating prerequisites for starting the component. Each component in the multiple components is started based on a starting sequence derived, in part, from the dependency information. Further, a graphical user interface (GUI) representing the dependency information is disclosed. This solution however has the following drawbacks: It captures the dependency information only for starting the services and considers primarily location dependencies or VM co-location information. It doesn’t capture various other dependencies required in a fulfillment process. The dependency and configuration information is captured template driven, which is pre-defined. That is, the dependency and configuration information capturing and processing can’t be adapted to a user’s needs automatically.
US 20170201569 Al discloses an apparatus, systems and methods for automatic distributed application deployment in heterogeneous environments. It is disclosed how to facilitate distributed orchestration and deployment of a cloud based distributed computing application. The disclosure however does not consider obtaining dependency information that is various enough according to a user’s need. Further, no automatic workflow generation for orchestration is disclosed. Instead, a template- and rule-based approach is suggested. This requires cloud agents to provide context information pre-configured in templates, which is not desired by a user.
Further, according to general prior art, all known service orchestrators require specific templates, scripts or commands to carry out an orchestration process. These require a considerable amount of effort to be produced, maintained and ported across different environments, which increases a products time to market (TTM) and a telecom operators total cost of ownership (TCO). Workflows for orchestration of tasks cannot be generated automatically according to a changed state of a system or a user’s desire. Workflows are however pre-defined in the templates. In a conventional service fulfillment process, a workflow specifying a series of tasks is defined either based on scripts, templates or commands. These need to be defined specifically according to each service, which consumes high effort and leads to higher TCO for both a vendor and a service provider.
That is, there is a need for a service orchestrator that uses a general service description that does not require specific scripts or commands to generate a required orchestration workflow for creating a service instance of a service. SUMMARY
In view of the above-mentioned problems and disadvantages, the present invention aims to improve the conventional service orchestrator. The present invention has the objective to provide a model-driven service orchestrator that uses a service description based on a predefined meta- model that does not require specific scripts or command to generate the required orchestration workflow.
That is, the service orchestrator according to the present invention can use a meta-model of a domain in which the service orchestrator is applied, wherein the meta-model specifies service-model syntax and service-model semantics. The service orchestrator is configured to generate an orchestration workflow according to a user defined service model, rather than hardcoding a workflow or a part of it into scripts or templates. A service designer thus can describe a service, its dependencies and how it behaves without the need to specify which particular process is used to obtain such behavior of the service. The service composition and behavior are provided in form of a model that is compliant with the service orchestrator’ s meta- model. In the service orchestrator according to the present invention, orchestration workflows are deduced from the service-model that describe the service using predefined semantics. In particular, the service-model can be converted into a dependency graph that can be manipulated to retrieve an operation order of the workflow (which may include parallel tasks).
To describe the present invention, the following list provides terms and their respective definitions used in this document: Model: A model is an artificial concept that can be used to express information, knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. In other words, a model is a representation of a system using general rules and concepts. This can e.g. be unified modeling language (UML). The model as used in the present invention also supports the concepts of model and meta-model according to the Meta Object Facility (MOF).
Entity: A logic representation in a model of an element that is included in the scope of a system. An entity may have properties. It can go through changes during its lifecycle. An entity can e.g. be a service, a resource, or any kind of product (i.e. a contract good).
Activation: A process that makes a resource or service operationally available with a requested configuration.
Configuration: When used as a noun, this is data and instmctions to a resource to activate a service with pre-defined characteristics. When used as a verb, this is the injection of the data and instructions to a resource or service.
Resource Controller: A logical layer abstracting resources under its control. The purpose of a controller is to present a common interface for the management of resources.
Creation Request: A request to create a service instance from a service type, including parameters to meet dependencies and its configuration.
Service Fulfillment: A process responsible for assembling and making services available to subscribers, tenants and 3rd parties.
Orchestrator: A logical layer abstracting and automating the fulfillment of complex service operations and requests from subscribers, tenants and 3rd parties, in an operator’s network or management domain. Plan: A series of steps that represent a workflow with the purpose of fulfilling an orchestration request within the context of existing services and resources at the time of a plan's creation. A plan is a decomposition into steps for the fulfillment of a service request based on a service model and a resource requirement.
Policy: A policy is a formal statement whose purpose is to govern the management of services and resources during their life-cycle. It controls or modifies how a service or resource operation is fulfilled and how the service is formed. It manages life-cycle events in the scope of a service or resource.
Provisioning: The action of providing resources for a resource request to support a service.
Resource: A resource is an element in an enterprise’s infrastructure utilized by a service or a goods procured by the market in the form of product. Services are generally hosted on resources.
Service: A service is a realization of a product or something provided in support of a product. It represents the technical or engineering and implementation view of the product. Product offering is sold to customers, and service is implemented to help realize this product. More specifically, a customer facing service (CFS) is a part of a product that is bought by a customer, while a resource facing service (RFS) is indirectly part of a product but is invisible to a customer; it exists to support one or more CFSs.
Service Instance / entity instance: A logical representation of a mnning service that has started its life-cycle, and thus has resources allocated to it. The resources may be just reserved or provisioned, but an allocation has taken place. Service instances are available in the inventory either as a resource reservation or as a mnning instance. An instance in particular is a logical or physical representation of an entity, that is described in a model.
Workflow: A managed execution of a plan’s steps through which a request is being fulfilled. The steps may be sequential, parallel, distmsted, local, optional, automated, or manual. It is the job of the workflow to organize and determine the execution of the steps and ensure the reliability and correctness of the execution. If a workflow cannot be successfully executed, the affected systems must always be in a consistent state.
The objective of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.
A first aspect of the present invention provides a service orchestrator for model-driven workflow generation, wherein the service orchestrator comprises a processor configured to obtain a service-model that complies with a predefined meta-model, wherein the meta model specifies service-model syntax and service-model semantics, and generate a workflow based on the service-model and in compliance with the service-model semantics, wherein the service-model defines a composition and/or behavior of a service, the service- model syntax specifies information provided by the service and a format of the provided information, the service-model semantics define a procedure for generating the workflow, and the generated workflow comprises a procedure for creating and/or operating a service instance of the service.
In other words, the service orchestrator automatically generates fulfillment workflows based on a predefined meta-model and semantics without the need for hardcoded scripts, commands or templates. This is beneficial, as there is no effort required for the development of scripts or templates that need to be developed for each service. In particular, a reduced effort is needed by service orchestrator vendors and customers to define new services; reduced operational cost for complex service management can be achieved; service models and definitions can be reused; and an increased service portability across different environments is achieved.
In an implementation form of the first aspect, the service- model further includes an operating logic of a service and the service orchestrator is further configured to generate the workflow based on the operating logic. In a further implementation form of the first aspect, the meta-model defines at least one dependency among service instances or among services.
In a further implementation form of the first aspect, the at least one dependency is an implicit dependency derived from a meta-class, and/or an explicit dependency pre-defined by the meta-model.
In a further implementation form of the first aspect, the meta-class is an element defined by the meta-model.
In a further implementation form of the first aspect, generating the workflow includes processing to convert the service-model into a dependency graph.
In a further implementation form of the first aspect, the processing to convert the service- model into a dependency graph is further based on the service-model semantics.
In a further implementation form of the first aspect, the at least one dependency relates to a node and/or an edge resulting in the dependency graph.
In a further implementation form of the first aspect, generating the workflow further includes processing the dependency graph to obtain a list of tasks representing the workflow.
In a further implementation form of the first aspect, processing the dependency graph includes applying a direct or reverse topological sorting algorithm to the dependency graph and/or includes applying an optimization algorithm, particularly a Coffman- Graham algorithm, to the dependency graph.
In a further implementation form of the first aspect, the list of tasks includes sequential and/or parallel tasks and/or sub tasks.
In a further implementation form of the first aspect, the generated workflow is a design stage workflow, or a resource availability and constraints verification stage workflow, or a resource reservation stage workflow, or a service instance provisioning stage workflow; wherein in the design stage workflow, a service instance structure is defined; wherein in the resource availability and constraints verification stage workflow, availability of required resources and/or compliance with constraints is verified; wherein in the resource reservation stage workflow, the required resources are reserved; and wherein in the service instance provisioning stage workflow, a service instance is created and/or configured.
A second aspect of the present invention provides a method for operating a service orchestrator for model-driven workflow generation, the method comprising the steps of obtaining a service-model that complies with a predefined meta-model, wherein the meta model specifies service-model syntax and service-model semantics, and generating a workflow based on the service-model and in compliance with the service-model semantics, wherein the service-model defines a composition and/or behavior of a service, the service- model syntax specifies information provided by the service and a format of the provided information, the service-model semantics define a procedure for generating the workflow, and the generated workflow comprises a procedure for creating and/or operating a service instance of the service.
In an implementation form of the second aspect, the service-model further includes an operating logic of a service and the method further includes generating the workflow based on the operating logic.
In a further implementation form of the second aspect, the meta- model defines at least one dependency among service instances or among services.
In a further implementation form of the second aspect, the at least one dependency is an implicit dependency derived from a meta-class, and/or an explicit dependency pre-defined by the meta-model.
In a further implementation form of the second aspect, the meta-class is an element defined by the meta-model.
In a further implementation form of the second aspect, generating the workflow includes processing to convert the service-model into a dependency graph. In a further implementation form of the second aspect, the processing to convert the service-model into a dependency graph is further based on the service-model semantics.
In a further implementation form of the second aspect, the at least one dependency relates to a node and/or an edge resulting in the dependency graph.
In a further implementation form of the second aspect, generating the workflow further includes processing the dependency graph to obtain a list of tasks representing the workflow.
In a further implementation form of the second aspect, processing the dependency graph includes applying a direct or reverse topological sorting algorithm to the dependency graph and/or includes applying an optimization algorithm, particularly a Coffman- Graham algorithm, to the dependency graph.
In a further implementation form of the second aspect, the list of tasks includes sequential and/or parallel tasks and/or sub tasks.
In a further implementation form of the second aspect, the generated workflow is a design stage workflow, or a resource availability and constraints verification stage workflow, or a resource reservation stage workflow, or a service instance provisioning stage workflow; wherein in the design stage workflow, a service instance structure is defined; wherein in the resource availability and constraints verification stage workflow, availability of required resources and/or compliance with constraints is verified; wherein in the resource reservation stage workflow, the required resources are reserved; and wherein in the service instance provisioning stage workflow, a service instance is created and/or configured.
The method of the second aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
A third aspect of the present invention provides a computer program product comprising a program code for controlling a service orchestrator according to the first aspect or any of its implementation forms or for performing, when running on a computer, the method according to the second aspect or any of its implementation forms.
The computer program product of the third aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
A fourth aspect of the present invention provides a system comprising the service orchestrator according to the first aspect or any of its implementation forms, a service- model storage configured to provide a service-model to the service orchestrator, a service- instance storage, and at least one infrastructure element management system, configured to create, operate or control at least one infrastructure element hosted in an infrastructure element system, according to the workflow generated by the service orchestrator, to provide a service instance to the service-instance storage.
The system of the fourth aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
A fifth aspect of the present invention provides a method for operating a system comprising the service orchestrator according to the first aspect or any of its implementation forms, a service-model storage configured to provide a service-model to the service orchestrator, a service-instance storage, and at least one infrastructure element management system, the method comprising the steps of creating, operating or controlling, by the at least one infrastructure element management system, at least one infrastructure element hosted in an infrastructure element system, according to the workflow generated by the service orchestrator, to provide a service instance to the service-instance storage.
The method of the fifth aspect and its implementation forms include the same advantages as the service orchestrator according to the first aspect and its implementation forms.
It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
The above-described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which: FIG. 1 shows a schematic view of a service orchestrator according to an embodiment of the present invention.
FIG. 2 shows a schematic view of a service orchestrator according to an embodiment of the present invention in more detail.
FIG. 3 shows a schematic view of a value dependency meta-model.
FIG. 4 shows a schematic view of semantics for aggregation dependency conversion into nodes and edges.
FIG. 5 shows a schematic view of semantics for value dependency conversion into nodes and edges.
FIG. 6 shows a schematic view of an example for value dependency conversion into nodes and edges.
FIG. 7 shows a schematic view of a dependency graph according to the present invention. FIG. 8 shows a schematic view of stages in service orchestration.
FIG. 9 shows a schematic view of a workflow according to the present invention. FIG. 10 shows a schematic view of a service orchestrator according to an embodiment of the present invention in more detail.
FIG. 11 shows a schematic view of a method according to an embodiment of the present invention.
FIG. 12 shows a schematic view of a system according to the present invention.
FIG. 13 shows another schematic view of a system according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS
FIG. 1 shows a schematic view of a service orchestrator 100 for model-driven workflow generation according to an embodiment of the present invention. The service orchestrator 100 comprises a processor 101, which is configured to obtain a service-model 102. The service-model 102 complies with a predefined meta- model 103, which specifies service- model syntax 104 and service-model semantics 105. The service-model 102 is created, e.g. by a service designer (i.e. by user input) before it is obtained by the service orchestrator 100. That is, the compliance with the meta-model 103 is established during creation of the service-model 102. The service orchestrator 100 however can, but does not need to, check the service-model 102 for compliance with the meta-model 103, and therefore can also obtain the meta- model 103. The service-model 102 defines a composition and/or behavior of a service 107. The service- model syntax 104 specifies information provided by the service 107 and a format of the provided information. The service-model semantics 105 define a procedure for generating a workflow 106. The models as used in the present invention in particular relate to the concept of model and meta-model according to the MOF.
In other words, a meta-model 103 (that corresponds to an M2 level of the MOF) is a
“language” used to define a service-model 102 (and also used to define a resource-model, since the service orchestrator 100 can as well be used to orchestrate resources, not only services; in particular, all functions that are described in this document regarding services 107 can be applied to resources - e.g. any kind of hardware resources in a datacenter - as well). It includes syntax and semantics. A service-model 102 (that corresponds to an Ml level of the MOF) is a specific logical service 107 definition compliant with the meta model 103. A resource-model (that corresponds to an Ml level of the MOF) is a specific logical infrastructure element definition compliant with the meta-model 103. It also can be associated with an infrastructure element management system (e.g. a resource controller). A service-instance 108 (that corresponds to an M0 level of the MOF) is a concrete instance (i.e. a virtual or physical realization) corresponding to a service 107 defined in the service- model 102. A resource-instance (that corresponds to an M0 level of the MOF) is a concrete instance of an infrastructure element defined in a model.
The processor 101 of the service orchestrator 100 is further configured to generate a workflow 106 based on the service-model 102 and in compliance with the service-model semantics 105. The service-model semantics 105 in particular specify an algorithm for generating the workflow 106. The generated workflow 106 comprises a procedure for creating and/or operating a service instance 108 of the service 107.
That is, the generated workflow 106 allows for service orchestration based on a service model, in that it enables to generate or control a service instance 108 of the service 107, by the information contained in the workflow 106.
FIG. 2 shows a schematic view of a service orchestrator 100 according to an embodiment of the present invention in more detail. The service orchestrator 100 of Fig. 2 is based on the service orchestrator 100 of Fig. 1 and therefore includes all of its function and features. To this end, identical features are labelled with identical reference signs. All features that are now going to be described in view of Fig. 2 are optional features of the service orchestrator 100.
The service- model 102 optionally includes an operating logic 201 of a service 107, and the service orchestrator 100 is further configured to generate the workflow 106 based on the operating logic 201. That is, the operating logic 201 describes how the service 107 is composed and how it behaves in order to carry out a predefined operation (e.g. a web- server, an email-server, a virtual private network (VPN) connection, a network connection, etc.) for example a desired business logic according to a predefined use case.
Further optionally, as it is shown in Fig. 2, the meta-model 103 defines at least one dependency 202 among service instances 108 or among services 107.
Dependencies of a service 107 or service instance 108 are in particular defined in a configuration element of the service 107.
Turning back to Fig. 2, the meta- model 103 may define several types of dependencies 202. Some of them can be defined implicitly in a meta-class 203, others can be defined explicitly by a designer (e.g. a user).
That is, the at least one dependency 202 can be an implicit dependency derived from a meta-class 203, and/or an explicit dependency 204 pre-defined by the meta-model 103. The meta-class 203 in particular may be an element defined by the meta-model 103, e.g. according to MOF.
The following gives an overview of explicit or implicit dependencies 202 according to the present invention:
Element aggregation or composition: This is an implicit dependency that is automatically established between two elements, when one element is composed by another one or when it aggregates another one.
Creation operation: This is an implicit dependency that is automatically established between a create operation and the elements that it can create.
Generic dependency: This is an explicit dependency that is established by a designer between two sets of elements.
Value dependency: This is an explicit dependency that is established by the designer between one client element and a set of supplier’s elements. The value of the client is calculated with a function from the values of the suppliers.
Transition operation dependency: This is an explicit dependency that is established by the designer between one client operation invocation and a supplier state transition. When the transition is performed, then the operation invocation is executed.
Operation transition dependency: This is an explicit dependency that is established by the designer between on client transition and a supplier operation. When the operation is executed, then the transition is performed.
Operation dependency: This is an explicit dependency that is established by the designer between one client operation invocation and another supplier operation. When the supplier operation is executed, then the client operation invocation is executed as well.
Transition dependency: This is an explicit dependency that is established by the designer between one client transition and another supplier transition. When the supplier transition is performed, the also the client transition is performed.
Status bounce dependency: This is an explicit dependency that is established by the designer between one operation and two states of a state machine. To execute the operation that element that own it has to move from one state to another before execute the operation and then when finished to move back to the original state. Subordinate dependency: This is an explicit dependency that is established between a scalar client element and a vector supplier element. This dependency for the instantiation of many client element instances as the number of vector supplier element size.
In Fig. 3, the dependencies 202 are exemplarily described in view of the value dependency. Fig. 3 in particular shows a value dependency meta-model. A value dependency is a relationship that signifies that a model element requires the value of another model element for its specification or implementation. The value dependency can be used to model dependencies among attributes, operation results and operation arguments.
In view of Figs. 4, 5 and 6, it is now going to be described how a dependency graph is generated from the service-model 102. When designing a service 107, the dependencies 202 defined in the meta-model 103 for the service model 102 of a given service 107 are considered. Every specific meta- model 103 dependency 202, when used in a service-model 102, is mapped into at least one node 401 and/or at least one edge 402 in a dependency graph. That is, generating the workflow 106 includes processing to convert the service- model 102 into a dependency graph 403. For each type of dependency 202, there is a semantic defined about which elements in the dependency 202 will be mapped to a node 401 and which elements in the dependency 202 will be mapped to an edge 402. In other words, the processing to convert the service-model 103 into a dependency graph 403 is further based on the service-model semantics 105.
For example, regarding an element composition or aggregation dependency 202, these implicit dependencies 202 map into a direct edge 402 directed from an owned element to an owner, as e.g. shown in Fig. 4 (which shows a semantic for aggregation dependency conversion to nodes 401 and edges 402). In case of a value dependency, this explicit dependency 202 maps into a direct edge from a client to a supplier. In this case, the dependency itself can in particular be mapped as a node 501, 601 in the middle, as e.g. shown in Fig. 5 (which shows a semantic for value dependency conversion to nodes 501 and edges 502), and Fig. 6 (which shows an example for value dependency conversion to nodes 601 and edges 602).
As can be seen in Figs. 4, 5, and 6, the at least one dependency 202 relates to a node 401, 501, 601 and/or an edge 402, 502, 602 resulting in the dependency graph 403, 503, 603.
Fig. 7 shows an example of a dependency graph 700 that can result from the above described conversion.
As described before, service orchestration is an application responsible for assembly of complex, multi-faceted telecom or IT services into repeatable loops. Its primary function is automation of end-to-end service instance 108 provisioning activities. Service orchestration is responsible for realization of a service instance 108 for a given service 107.
In a specific embodiment, an overall orchestration process optionally may be composed of different stages as shown in Fig. 8. Each stage allows the generation of a workflow for the stage in which the orchestration process takes place, wherein the single workflows can be arbitrarily combined. The dependency graph 700 for the service instance 108 is taken as an input in the workflow generation. In a design stage 801, the dependency graph 700 is used to generate information about a target service instance 108 that needs to be created or modified. In other words, a service instance structure is defined. In a resource availability and constraints verification stage 804, the dependency graph 700 is used to generate a workflow to verify that the resources used by the target service instance 108 are available and can be allocated. In other words, availability of required resources and/or compliance with constraints is verified. In a resource reservation stage 803, the dependency graph 700 is used to generate a workflow to reserve the resources needed by the target service instance 108. In other words, the required resources are reserved. In a service instance provisioning stage 802, the dependency graph 700 is used to generate a workflow to create/modify the resources needed/used by the target service instance 108. In other words, a service instance is created and/or configured.
Generating any one of said workflows includes sorting the dependency graph using a reverse topological sorting algorithm. This result in a sequential list of tasks 900, as it is e.g. shown in Fig. 9. Subsequently, the workflows can be combined to obtain the complete workflow 106. The sequential order obtained by the reverse topological sorting algorithm is not optimized. Some of the tasks are independent and can be executed in parallel. An optimization algorithm can be applied to obtain a workflow that takes care of sequential constraints and also allows for possible parallelization. That is, the resulting list of tasks 900 can include sequential and/or parallel tasks and/or subtasks.
Fig. 10 shows a schematic view of a service orchestrator 100 according to an embodiment of the present invention in more detail. The service orchestrator 100 of Fig. 10 is based on the service orchestrator 100 of Figs. 1 and 2 and therefore includes all of their function and features. To this end, identical features are labelled with identical reference signs. All features that are now going to be described in view of Fig. 10 are optional features of the service orchestrator 100.
The service orchestrator 100 uses a user defined service-model 102 (also referred to as service and resource model) to perform management operations that require coordination of various parts on which services 107 and resources are decomposed. These models must be compliant with a meta-model 103 (also referred to as service and resource meta-model) and follow its semantics 105.
The meta-model 103 describes in detail which elements belong to a domain of the service orchestrator 100 and how they are composed to carry out a services 107 business logic. The meta-model 103 incorporates precise semantics 105 on how the service orchestrator 100 interprets various constructs and dependencies. The meta-model 103 can be formalized in UML but a domain specific language (DSL) is provided to facilitate a service description.
A service designer 1001 is a tool used by a designer (i.e. a user) to define the service- model 102.
A master catalog 1002 (also referred to as storage) stores the service-model 102 (or the service- and resource model) defined by the service designer 1001. The service orchestrator 100 obtains the service-model 103 by reading it from the master catalog 1302.
The service orchestrator 100 further includes the following sub-units:
A request handler (not shown) receives a request for service instance creation and sends the request to the service instance designer 1003 to design the service instance 108.
The service instance designer 1003 receives the service instance creation request with input parameters for the service instance 108. Then, it reads the service model 102, and creates the service instance 108 with all the subordinate service instances and resource instance details and dependencies. The dependency graph 700 is created for the service instance 108 by this component considering all dependencies for the service instance 108. This dependency graph 700 is used to generate information about the target service instance 108 that needs to be created or modified.
The service orchestrator further includes the following planners (i.e. planning units): A verification planner 1005 uses the dependency graph 700 received from the service instance designer 1003 to generate the workflow to verify that the resources used by the target service instance 108 are available and can be allocated. A reservation planner 1006 uses the dependency graph 700 received from the service instance designer 1003 to generate the workflow to reserve the resources needed by the target service instance 108. A provisioning planner 1004 uses the dependency graph 700 received from the service instance designer 1003 to generate the workflow to create/modify the resources needed/used by the target service instance 108. A workflow engine 1007 is responsible for execution of a workflow 106 generated by the planners and feeds back the results.
FIG. 11 shows a schematic view of a method 1100 according to an embodiment of the present invention. The method 1100 is for operating the service orchestrator 100 and thus enables for model-driven workflow generation. The method 1100 comprises a first step of obtaining 1101 a service-model 102 that complies with a predefined meta-model 103, wherein the meta-model 103 specifies service-model syntax 104 and service-model semantics 105. The method 1100 further comprises a second step of generating 1102 a workflow 106 based on the service-model 102 and in compliance with the service-model semantics 105, wherein the service-model 102 defines a composition and/or behavior of a service 107, the service-model syntax 104 specifies information provided by the service 107 and a format of the provided information, the service-model semantics 105 define a procedure for generating the workflow 106, and the generated workflow 106 comprises a procedure for creating and/or operating a service instance 108 of the service 107.
Fig. 12 shows a system 1200 according to an embodiment of the present invention. The system 1200 comprises the service orchestrator 100 as described in any one of the figures above. The system 1200 further comprises a service-model storage 1201 (also referred to as master catalog 1002) that is configured to provide a service-model 102 to the service orchestrator 100. The system further comprises a service-instance storage 1202, and at least one infrastructure element management system 1203 that is configured to create, operate or control at least one infrastructure element 1204 hosted in an infrastructure element system 1205, according to the workflow 106 generated by the service orchestrator 100, to provide a service instance 108 to the service-instance storage 1202.
Fig. 13 shows a system 1300 according to an embodiment of the present invention in more detail. The system 1300 comprises the service orchestrator 100 as described in any one of the figures above. The system 1300 includes all functions and features of the system 1200 and in particular mentions examples of the service-model storage 1201 (also referred to as master catalog 1002), the service-instance storage 1202, the at least one infrastructure element management system 1203, the at least one infrastructure element 1204, and the infrastructure element system 1205 as labelled in Fig. 13. In further embodiments of the present invention, alternative solutions to define a workflow for service provisioning are described below:
Using a template to statically define the workflow.
Instead of using exclusively dependency information, a workflow can be generated by using only sub-ordinate / aggregate dependency relationship information and then add other functions by scripts, plugins or templates.
Instead of generating a separate dependency graph, the workflow can be directly generated from the service-model 102. The dependency graph is just an intermediate step, which can be suppressed or hidden from visibility.
Instead of generating a workflow, only the dependency graph is generated and a template or script is defined to process the dependency graph to execute actions.
The sub-components mentioned (i.e. the service instance designer, the different planners, the workflow engine) can be compressed to one component and the respective functionality can be compressed to one step.
The present invention is not limited to the field of service orchestration, but can be adapted to any field that involves workflow generation and that can be described using the models according to the present invention. For example in case of automation systems (which are not only limited to engineering / manufacturing industry) which involve workflow generation, a model for an entity in a workflow in the automation system can be defined equivalent to the service model (which is defined as an exemplary reference in this document) and its dependencies and thus, the workflow of the automation system can be generated from a model according to the present invention.

Claims

1. A service orchestrator (100) for model-driven workflow generation, wherein the service orchestrator (100) comprises a processor (101) configured to:
- obtain a service-model (102) that complies with a predefined meta-model (103), wherein the meta-model (103) specifies service-model syntax (104) and service-model semantics (105), and
- generate a workflow (106) based on the service-model (102) and in compliance with the service-model semantics (105),
wherein the service-model (102) defines a composition and/or behavior of a service (107), the service-model syntax (104) specifies information provided by the service (107) and a format of the provided information, the service-model semantics (105) define a procedure for generating the workflow (106), and the generated workflow (106) comprises a procedure for creating and/or operating a service instance (108) of the service (107).
2. The service orchestrator (100) according to claim 1, wherein the service- model (102) further includes an operating logic (201) of a service (107) and the service orchestrator (100) is further configured to generate the workflow (106) based on the operating logic (201).
3. The service orchestrator (100) according to any one of the preceding claims, wherein the meta- model (103) defines at least one dependency (202) among service instances (108) or among services (107).
4. The service orchestrator (100) according to any one of the preceding claims, wherein the at least one dependency (202) is an implicit dependency derived from a meta class (203), and/or an explicit dependency (204) pre-defined by the meta-model (103).
5. The service orchestrator (100) according to any one of the preceding claims, wherein the meta-class (203) is an element defined by the meta-model (103).
6. The service orchestrator (100) according to any one of the preceding claims, wherein generating the workflow (106) includes processing to convert the service- model
(102) into a dependency graph (603, 703, 803, 900).
7. The service orchestrator (100) according to any one of the preceding claims, wherein the processing to convert the service-model (102) into a dependency graph (603, 703, 803, 900) is further based on the service-model semantics (105).
8. The service orchestrator (100) according to any one of the preceding claims, wherein the at least one dependency (202) relates to a node (601, 701, 801) and/or an edge (602, 702, 802) resulting in the dependency graph (603, 703, 803, 900).
9. The service orchestrator (100) according to any one of the preceding claims, wherein generating the workflow (106) further includes processing the dependency graph (603, 703, 803, 900) to obtain a list of tasks (1100) representing the workflow (106).
10. The service orchestrator (100) according to any one of the preceding claims, wherein processing the dependency graph (603, 703, 803, 900) includes applying a direct or reverse topological sorting algorithm to the dependency graph (603, 703, 803, 900) and/or includes applying an optimization algorithm, particularly a Coffman- Graham algorithm, to the dependency graph (603, 703, 803, 900).
11. The service orchestrator (100) according to any one of the preceding claims, wherein the list of tasks (1100) includes sequential and/or parallel tasks and/or subtasks.
12. The service orchestrator (100) according to any one of the preceding claims, wherein the generated workflow (106) is a design stage (1001) workflow, and/or a resource availability and constraints verification stage (1004) workflow, and/or a resource reservation stage (1003) workflow, and/or a service instance provisioning stage (1002) workflow;
wherein in the design stage (1001) workflow, a service instance stmcture is defined;
wherein in the resource availability and constraints verification stage (1004) workflow, availability of required resources and/or compliance with constraints is verified;
wherein in the resource reservation stage (1003) workflow, the required resources are reserved; and
wherein in the service instance provisioning stage (1002) workflow, a service instance is created and/or configured.
13. Method (1400) for operating a service orchestrator (100) for model-driven workflow generation, the method (1400) comprising the steps of:
- obtaining (1401) a service-model (102) that complies with a predefined meta-model (103), wherein the meta-model (103) specifies service-model syntax (104) and service- model semantics (105), and
- generating (1402) a workflow (106) based on the service-model (102) and in compliance with the service-model semantics (105),
wherein the service-model (102) defines a composition and/or behavior of a service (107), the service-model syntax (104) specifies information provided by the service (107) and a format of the provided information, the service-model semantics (105) define a procedure for generating the workflow (106), and the generated workflow (106) comprises a procedure for creating and/or operating a service instance (108) of the service (107).
14. Computer program product comprising a program code for controlling a service orchestrator (100) according to one of the claims 1 to 12 or for performing, when running on a computer, the method according to claim 13.
15. A system (1500) comprising:
- the service orchestrator (100) according to one of the claims 1 to 12,
- a service-model storage (1501) configured to provide a service-model (102) to the service orchestrator (100),
- a service-instance storage (1502), and
- at least one infrastructure element management system (1503), configured to create, operate or control at least one infrastructure element (1504) hosted in an infrastructure element system (1505), according to the workflow (106) generated by the service orchestrator (100), to provide a service instance (108) to the service-instance storage (1502).
PCT/EP2018/063605 2018-05-24 2018-05-24 Service orchestrator for model-driven workflow generation WO2019223867A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18727260.4A EP3743811A1 (en) 2018-05-24 2018-05-24 Service orchestrator for model-driven workflow generation
PCT/EP2018/063605 WO2019223867A1 (en) 2018-05-24 2018-05-24 Service orchestrator for model-driven workflow generation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/063605 WO2019223867A1 (en) 2018-05-24 2018-05-24 Service orchestrator for model-driven workflow generation

Publications (1)

Publication Number Publication Date
WO2019223867A1 true WO2019223867A1 (en) 2019-11-28

Family

ID=62245297

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/063605 WO2019223867A1 (en) 2018-05-24 2018-05-24 Service orchestrator for model-driven workflow generation

Country Status (2)

Country Link
EP (1) EP3743811A1 (en)
WO (1) WO2019223867A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10977059B1 (en) 2020-03-25 2021-04-13 Red Hat, Inc. Implementing object validation, web request handling, object relational mapping, or messaging via direct bytecode generation
US11409555B2 (en) * 2020-03-12 2022-08-09 At&T Intellectual Property I, L.P. Application deployment in multi-cloud environment

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372533A1 (en) 2011-02-09 2014-12-18 Cliqr Technologies, Inc. Apparatus, systems, and methods for cloud agnostic multi-tier application modeling and deployment
US20170201569A1 (en) 2016-01-11 2017-07-13 Cliqr Technologies, Inc. Apparatus, systems and methods for automatic distributed application deployment in heterogeneous environments
US20170289060A1 (en) * 2016-04-04 2017-10-05 At&T Intellectual Property I, L.P. Model driven process for automated deployment of domain 2.0 virtualized services and applications on cloud infrastructure

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372533A1 (en) 2011-02-09 2014-12-18 Cliqr Technologies, Inc. Apparatus, systems, and methods for cloud agnostic multi-tier application modeling and deployment
US20170201569A1 (en) 2016-01-11 2017-07-13 Cliqr Technologies, Inc. Apparatus, systems and methods for automatic distributed application deployment in heterogeneous environments
US20170289060A1 (en) * 2016-04-04 2017-10-05 At&T Intellectual Property I, L.P. Model driven process for automated deployment of domain 2.0 virtualized services and applications on cloud infrastructure

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BHAMARE DEVAL ET AL: "Multi-objective scheduling of micro-services for optimal service function chains", 2017 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (ICC), IEEE, 21 May 2017 (2017-05-21), pages 1 - 6, XP033132569, DOI: 10.1109/ICC.2017.7996729 *
THOMAS SPATZIER ET AL: "Topology and Orchestration Specification for Cloud Applications Version 1.0", 25 November 2013 (2013-11-25), XP055552436, Retrieved from the Internet <URL:http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.pdf> [retrieved on 20190206] *
TIAN CILIERS: "Directed Acyclic Graphs && Topological Sorting by Tian Cilliers IOI Training Camp 2 (3-4 February 2018)", 3 February 2018 (2018-02-03), XP055552936, Retrieved from the Internet <URL:http://olympiad.cs.uct.ac.za/presentations/camp2_2018/topsort-tian.pdf> [retrieved on 20190206] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11409555B2 (en) * 2020-03-12 2022-08-09 At&T Intellectual Property I, L.P. Application deployment in multi-cloud environment
US10977059B1 (en) 2020-03-25 2021-04-13 Red Hat, Inc. Implementing object validation, web request handling, object relational mapping, or messaging via direct bytecode generation

Also Published As

Publication number Publication date
EP3743811A1 (en) 2020-12-02

Similar Documents

Publication Publication Date Title
EP3501141B1 (en) A network service design and deployment process for nfv systems
Ferry et al. Cloudmf: Model-driven management of multi-cloud applications
Fowley et al. A classification and comparison framework for cloud service brokerage architectures
US9621428B1 (en) Multi-tiered cloud application topology modeling tool
US20110004564A1 (en) Model Based Deployment Of Computer Based Business Process On Dedicated Hardware
US8612976B2 (en) Virtual parts having configuration points and virtual ports for virtual solution composition and deployment
US20100262558A1 (en) Incorporating Development Tools In System For Deploying Computer Based Process On Shared Infrastructure
Breitenbücher et al. Pattern-based runtime management of composite cloud applications
US20100262559A1 (en) Modelling Computer Based Business Process And Simulating Operation
US20110004565A1 (en) Modelling Computer Based Business Process For Customisation And Delivery
US20080270973A1 (en) Deriving grounded model of business process suitable for automatic deployment
US20100280863A1 (en) Automated Model Generation For Computer Based Business Process
US20150304175A1 (en) Binding of application and infrastructure blueprints
US20100110933A1 (en) Change Management of Model of Service
Wurster et al. Modeling and automated deployment of serverless applications using tosca
US20130290239A1 (en) Method and a system for service lifecycle management in networked environments
US20150052095A1 (en) Model-based approach to intelligent automation in a computing domain
US20180205600A1 (en) Closed-loop infrastructure orchestration templates
US20180136970A1 (en) Methods and systems for configuration-file inheritance
KR20220088333A (en) Dynamic cloud deployment of robotic process automation (rpa) robots
Dukaric et al. BPMN extensions for automating cloud environments using a two-layer orchestration approach
EP3743811A1 (en) Service orchestrator for model-driven workflow generation
Bhattacharjee et al. Cloudcamp: Automating cloud services deployment and management
Štefanic et al. TOSCA-Based SWITCH workbench for application composition and infrastructure planning of time-critical applications
Di Modica et al. Implementation of a fault aware cloud service provisioning framework

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18727260

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018727260

Country of ref document: EP

Effective date: 20200827

NENP Non-entry into the national phase

Ref country code: DE