A capability orchestration method and system

Abstract

Embodiments of the present application disclose a capability arrangement method and system. The method comprises: in response to a service requirement, analyzing the service requirement to obtain a resource model and constraint conditions; determining target atomic capabilities from a plurality of atomic capabilities based on the resource model and the constraint conditions, and arranging the plurality of target atomic capabilities into a capability chain, wherein each atomic capability is obtained by encapsulating an operation capability of a heterogeneous platform; and executing the plurality of target atomic capabilities according to the capability chain to complete the service requirement. The technical solution of the embodiments of the present application can reduce the response complexity for the service requirement.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of data processing technology, and in particular to a capability orchestration method and system. Background Technology

[0002] During the construction and operation of cloud platforms, business requirements such as business migration to the cloud, resource activation, network connectivity, load balancing configuration, security policy application, monitoring access, log access, and backup policy configuration usually involve multiple platforms, which means that business requirements need to be responded to by calling multiple platform interfaces.

[0003] However, the parameter formats, authentication methods, and idempotency mechanisms of different platforms are inconsistent, making it impossible to respond to business needs based on a single automated process, resulting in high response complexity, which urgently needs to be addressed. Summary of the Invention

[0004] This invention provides a capability orchestration method and system that solves the problem of high complexity in responding to business requirements.

[0005] According to one aspect of the present invention, a capability orchestration method is provided, which may include:

[0006] In response to business needs, the business needs are analyzed to obtain resource models and constraints;

[0007] Based on resource models and constraints, target atomic capabilities are determined from multiple atomic capabilities, and multiple target atomic capabilities are arranged into a capability chain. Each atomic capability is obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0008] Execute multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0009] According to another aspect of the present invention, a capability orchestration system is provided, which may include: a requirement parser, an orchestration decision engine, and an execution controller; wherein,

[0010] The requirement parser is used to respond to business requirements by parsing them to obtain resource models and constraints.

[0011] The orchestration decision engine is used to determine target atomic capabilities from multiple atomic capabilities based on resource models and constraints, and orchestrate multiple target atomic capabilities into a capability chain. The multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0012] The execution controller is used to execute multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0013] According to another aspect of the present invention, an electronic device is provided, which may include:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by at least one processor to implement the capability orchestration method provided in any embodiment of the present invention when executed by at least one processor.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided having computer instructions stored thereon for causing a processor to execute and implement the capability orchestration method provided in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer program product is provided, on which a computer program is stored, which, when executed by a processor, implements the capability orchestration method provided in any embodiment of the present invention.

[0019] The technical solution of this invention, in response to business needs, parses the business needs to obtain a resource model and constraints; based on the resource model and constraints, it determines target atomic capabilities from multiple atomic capabilities and orchestrates these target atomic capabilities into a capability chain. These multiple atomic capabilities can be obtained by encapsulating the operational capabilities of heterogeneous platforms; and it executes the multiple target atomic capabilities according to the capability chain to fulfill the business needs. This technical solution, through three core steps—business needs parsing, atomic capability orchestration, and capability chain execution—establishes an automated closed-loop process from business needs to resource delivery. This fundamentally solves the problem of high response complexity caused by inconsistencies in parameter formats, authentication methods, and idempotency mechanisms across different platforms, thus reducing the response complexity to business needs.

[0020] It should be understood that the description in this section is not intended to identify key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a capability orchestration method provided according to an embodiment of the present invention;

[0023] Figure 2 This is a flowchart of another capability orchestration method provided by an embodiment of the present invention;

[0024] Figure 3 This is a flowchart of another capability orchestration method provided according to an embodiment of the present invention;

[0025] Figure 4 This is a flowchart of another capability orchestration method provided according to an embodiment of the present invention;

[0026] Figure 5 This is an architecture diagram of an atomic capability encapsulation and dynamic orchestration system provided according to an embodiment of the present invention;

[0027] Figure 6 This is an execution flowchart of the atomic capability encapsulation and dynamic orchestration system provided in an embodiment of the present invention;

[0028] Figure 7 This is a structural block diagram of a capability orchestration system provided according to an embodiment of the present invention;

[0029] Figure 8 This is a schematic diagram of the structure of an electronic device that implements the capability orchestration method of the present invention. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The same applies to "target," "original," etc., and will not be repeated here. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solution of this invention all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to maintain user personal information security and network security.

[0033] Figure 1 This is a flowchart illustrating a capability orchestration method provided in an embodiment of the present invention. This embodiment is applicable to situations where multiple atomic capabilities are orchestrated to respond to business needs involving multiple platforms. The method can be executed by the capability orchestration system provided in this embodiment of the invention. This system can be implemented in software and / or hardware and can be integrated into an electronic device, which can be a user terminal or a server, particularly a capability orchestration server in a cloud management platform or a separately deployed capability orchestration service cluster.

[0034] See Figure 1 The method of this invention specifically includes the following steps:

[0035] S110. In response to business needs, analyze the business needs to obtain the resource model and constraints.

[0036] In this context, business requirements can be understood as resource delivery or operational intentions proposed by users or upper-level systems. In the embodiments of this invention, these can be work orders, portal forms, application programming interface (API) calls, or requests parsed by smart assistants, without any specific limitations.

[0037] Parsing can be understood as the process of converting unstructured business requirements into structured data.

[0038] A resource model can be understood as structured data describing one or more of the following: resource type (such as cloud host, subnet), specifications (such as 4 cores 8G), and attributes required by business needs.

[0039] Constraints can be understood as implicit restrictions in business requirements, such as one or more of the following: security partitioning (production zone III), network connectivity, service level agreement (SLA), and delivery time limit. These are related to the actual situation and are not specifically limited here.

[0040] The business requirements are parsed to obtain resource models and constraints. For example, when the business requirement entry receives a natural language work order for "deploying two 4-core 8GB application servers in Production Zone III," semantic recognition and keyword extraction can be used to convert it into a standardized resource model and constraints containing the resource type "cloud host," specifications "4 cores 8GB," quantity "2 units," and security partition "Production Zone III." As another example, when a business requirement is initiated via an API call, JSON or interface parameters are directly received and mapped to an internally unified resource model and constraints, supplemented with default constraints, such as a delivery deadline of "standard." Of course, other parsing methods can also be used; no specific limitations are specified here.

[0041] In this step, the ambiguous business requirements are transformed into machine-understandable resource models and constraints through parsing, laying the foundation for subsequent automated orchestration and avoiding ambiguity and errors caused by manual translation of business requirements.

[0042] S120. Based on the resource model and constraints, the target atomic capability is determined from multiple atomic capabilities, and the multiple target atomic capabilities are arranged into a capability chain. The multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0043] In this context, a heterogeneous platform can be understood as multiple heterogeneous platforms. In this embodiment of the invention, optionally, the multiple platforms may include underlying platforms such as cloud platforms, network platforms, security platforms, intelligent computing platforms, and operation and maintenance platforms that can provide different APIs and operational capabilities.

[0044] Atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms. They can be understood as a unit capable of independently completing a minimal technical action, possessing clearly defined inputs, outputs, preconditions, postconditions, and rollback operations. It should be noted that in this embodiment of the invention, atomic capabilities are not simple API forwarding, but rather add one or more of the following to the underlying API: parameter validation, status judgment, access control, idempotency control, result verification, and anomaly compensation. Table 1 provides an example of atomic capabilities.

[0045] Table 1 Atomic Ability

[0046]

[0047] A capability chain can be understood as a directed acyclic graph (DAG) composed of multiple target atomic capabilities according to execution dependencies (such as serial or parallel).

[0048] Based on resource models and constraints, target atomic capabilities are determined from multiple atomic capabilities, and these target atomic capabilities are orchestrated into a capability chain. For example, based on the parsed resource model (e.g., cloud host) and constraints (e.g., security partition), matching atomic capabilities (i.e., target atomic capabilities) are retrieved from the capability registry, such as "cloud.vm.create" and "security.group.apply". Then, based on the execution dependencies between these target atomic capabilities, it is determined that "quota check" and "subnet IP check" can be performed in parallel, while "create cloud host" must be executed afterward, thus forming a DAG (i.e., capability chain). As another example, if multiple matching target atomic capabilities exist (e.g., the ability to create cloud hosts on different cloud platforms), an optimal target atomic capability can be selected based on one or more of factors such as platform compatibility, version stability, and historical success rate, and the final capability chain is generated accordingly.

[0049] In this step, atomic capabilities are automatically matched and orchestrated, transforming complex manual processes into executable automated plans, thus solving the problems of complex cross-system dependencies and low efficiency of manual script maintenance.

[0050] S130. Execute multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0051] In this process, the adapters for each target atomic capability are called sequentially or concurrently according to the topological order of the capability chain to complete the specific platform operation. For example, the capability chain is parsed, and target atomic capabilities without dependencies (such as quota checks and IP checks) are executed concurrently; for target atomic capabilities with dependencies (such as cloud host creation depending on quota checks), the corresponding capability adapters are called serially according to the topological order to complete the business requirements. These adapters can be understood as execution components that convert atomic capability calls into specific platform APIs, scripts, or commands; they can also be called platform adapters or platform adaptation ends.

[0052] In this step, the automated execution capability chain enables unified scheduling and status management of cross-platform operations, significantly reducing the complexity of responding to business needs across multiple platforms.

[0053] The technical solutions of this invention can be applied in various scenarios, and four examples are given here. First, automated cloud delivery. Specifically, after a user submits an application deployment request, atomic capabilities such as specification verification, resource creation, network configuration, load balancing, monitoring access, configuration management database (CMDB) write-back, and work order closure are automatically invoked to achieve automated execution from request to resource delivery. Second, elastic scaling. Specifically, after a business triggers a scaling policy, a unified capability chain is used to perform quota checks, availability zone selection, instance creation, addition to load balancing, monitoring access, and scaling result verification, reducing manual operations. Third, intelligent computing inference service deployment. Specifically, when a user applies for a model inference service, capabilities such as intelligent computing resource allocation, model artifact retrieval, inference instance deployment, service entry point creation, network policy configuration, monitoring metric access, and service availability verification are invoked. Fourth, cross-cloud capability adaptation. For another example, the same "create cloud host" capability can be implemented by different adapters on different cloud platforms. This allows the upper-layer orchestration process to rely only on standard capability descriptors and not directly bind to the underlying vendor interfaces. And so on, without making specific limitations here.

[0054] The technical solution of this invention, in response to business needs, parses the business needs to obtain a resource model and constraints; based on the resource model and constraints, it determines target atomic capabilities from multiple atomic capabilities and orchestrates these target atomic capabilities into a capability chain. These multiple atomic capabilities can be obtained by encapsulating the operational capabilities of heterogeneous platforms; and it executes the multiple target atomic capabilities according to the capability chain to fulfill the business needs. This technical solution, through three core steps—business needs parsing, atomic capability orchestration, and capability chain execution—establishes an automated closed-loop process from business needs to resource delivery. This fundamentally solves the problem of high response complexity caused by inconsistencies in parameter formats, authentication methods, and idempotency mechanisms across different platforms, thus reducing the response complexity to business needs.

[0055] An alternative technical solution involves executing multiple target atomic capabilities according to a capability chain, including:

[0056] Based on the capability chain, determine the current atomic capability to be executed among multiple target atomic capabilities;

[0057] In response to the successful execution of the current atomic capability, retrieve the historical execution results of the current atomic capability and use the historical execution results as the current execution result of the current atomic capability;

[0058] In response to the current atomic capability being in an executing state, return the waiting state for the current atomic capability or the execution result of the capability that subscribed to the current atomic capability;

[0059] In response to the failure of the current atomic capability and the permission to retry, the resource creation status corresponding to the current atomic capability is checked, and the retry action is performed based on the resource creation status.

[0060] Here, the current atomic capability can be understood as the next target atomic capability to be scheduled based on the DAG topology order and the completion status of executed nodes. The current atomic capability is determined based on the capability chain. This implements dynamic task scheduling based on dependencies, ensuring that each target atomic capability only starts execution after all its preconditions are met, thus guaranteeing the correctness and orderliness of the execution process.

[0061] Successful execution indicates that the current atomic capability has been successfully invoked within the context of this business request. Historical execution results can be understood as relevant information recorded during previous executions of the current atomic capability. If the current atomic capability has been successfully executed, the corresponding historical execution result can be used as the current execution result. This achieves idempotency in invocation, avoiding duplicate resource creation and configuration due to network jitter or process retries, ensuring operational consistency, and saving system resources. The above idempotency means that when the same request is executed once or multiple times, the final execution result remains consistent, without generating duplicate resources or configurations.

[0062] The "in execution" state can be understood as the current atomic capability being triggered, but the underlying platform has not yet returned the final execution result. When the current atomic capability is in the "in execution" state, it can return to a waiting state or subscribe to the capability's execution result, i.e., pausing the current process and using polling or callback methods to obtain the final execution result. This handles asynchronous operations, avoiding the resource waste caused by synchronous blocking, and can capture the final execution result in a timely manner, thus ensuring that the process continues execution at the correct point in time.

[0063] Allowing retries represents the retry strategy defined in the capability descriptor (such as the maximum number of retries and the interval). Resource creation status can be understood as confirming whether any residual resources remain at the underlying level before re-execution, avoiding duplicate creation. If the current atomic capability fails and retries are allowed, the resource creation status is verified, and retry actions are performed accordingly. This enhances the security of the retry mechanism, avoiding duplicate creation issues caused by "timeout-actual success" errors through pre-verification, and improving the intelligence of exception recovery.

[0064] For example, an identifier is generated for each business requirement, forming a capability execution key. If the target atomic capability corresponding to the same capability execution key has been successfully executed, the historical execution result is read directly to avoid duplicate resource creation; if it is in the execution state, a waiting state is returned or the capability execution result is subscribed; if it fails and retry is allowed, the existence of a half-complete resource is checked before retrying (i.e., the resource creation status is checked).

[0065] The above technical solution, through idempotent control, asynchronous waiting, and intelligent retry mechanisms, solves the problems of repeated execution and uncertain resource status in atomic capability calls, enabling the execution controller to stably and correctly advance the process when faced with various complex runtime states.

[0066] Figure 2 This is a flowchart of another capability orchestration method provided by an embodiment of the present invention. This embodiment is an optimization based on the above-described technical solutions. In this embodiment, optionally, multiple target atomic capabilities are orchestrated into a capability chain, including: obtaining capability descriptors for multiple target atomic capabilities; and orchestrating multiple target atomic capabilities into a capability chain based on each capability descriptor. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0067] See Figure 2 The method in this embodiment may specifically include the following steps:

[0068] S210. In response to business needs, analyze the business needs to obtain the resource model and constraints.

[0069] S220. Based on the resource model and constraints, the target atomic capability is determined from multiple atomic capabilities, wherein the multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0070] S230. Obtain capability descriptors for multiple target atomic capabilities, and arrange the multiple target atomic capabilities into a capability chain based on each capability descriptor.

[0071] In this context, the target atomic capability can be understood as a standardized atomic capability selected by the orchestration decision engine to meet business requirements. A capability descriptor can be understood as structured data describing the atomic capability interface, parameters, dependencies, permissions, version, idempotency, and rollback information; an example is shown in Table 2. Optionally, in this embodiment of the invention, the capability descriptor can be expressed using database records or service registration metadata.

[0072] Table 2 Capability Descriptors

[0073]

[0074] The system retrieves capability descriptors for multiple target atomic capabilities. For example, after identifying a target atomic capability, a query request is sent to the capability registry center, carrying a unique identifier. The registry center returns the complete capability descriptor corresponding to that target atomic capability. As another example, to improve performance, each capability descriptor is cached locally. Based on this, when the capability descriptor of a target atomic capability needs to be retrieved, the system first checks if it exists in the local cache and if the version is valid. If a match is found, it is read directly from the local cache, avoiding remote calls. Furthermore, multiple target atomic capabilities are orchestrated into a capability chain based on each capability descriptor.

[0075] In this step, standardized capability descriptors are obtained, providing a unified data foundation for subsequent dependency analysis and orchestration, ensuring the decoupling of orchestration logic from the underlying capability implementation. Then, by automatically constructing capability chains using the metadata in the capability descriptors, the orchestration logic is automated, reducing the workload of manually defining processes and ensuring the correctness of the execution sequence.

[0076] S240. Execute multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0077] The technical solution of this invention, by acquiring and utilizing capability descriptors for atomic capability orchestration, makes the generation of capability chains no longer hard-coded, but dynamically deduced based on the metadata of the atomic capabilities themselves, which greatly improves the flexibility and scalability of atomic capability orchestration.

[0078] Figure 3 This is a flowchart of another capability orchestration method provided by an embodiment of the present invention. This embodiment is based on and optimized from the above-described technical solutions. In this embodiment, optionally, orchestrating multiple target atomic capabilities into a capability chain based on each capability descriptor may include: determining the execution dependency relationship between multiple target atomic capabilities based on at least one of the preconditions, postconditions, and dependent capabilities represented by each capability descriptor, wherein the preconditions represent the technical conditions that need to be met before executing the corresponding atomic capability, the postconditions represent the result conditions that need to be verified after executing the corresponding atomic capability, and the dependent capabilities represent the atomic capabilities that need to be relied upon in addition to the corresponding atomic capability; and orchestrating multiple target atomic capabilities into a capability chain according to the execution dependency relationship. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0079] See Figure 3 The method in this embodiment may specifically include the following steps:

[0080] S310. In response to business needs, analyze the business needs to obtain the resource model and constraints.

[0081] S320. Based on the resource model and constraints, the target atomic capability is determined from multiple atomic capabilities, wherein the multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0082] S330, a capability descriptor for acquiring the capabilities of multiple target atoms.

[0083] S340. Based on at least one of the preconditions, postconditions, and dependent capabilities represented by each capability descriptor, determine the execution dependency relationship between multiple target atomic capabilities, wherein the preconditions represent the technical conditions that need to be met before executing the corresponding atomic capability, the postconditions represent the result conditions that need to be verified after executing the corresponding atomic capability, and the dependent capabilities represent the atomic capabilities that need to be relied upon in addition to the corresponding atomic capability.

[0084] Execution dependency can be understood as the sequential or parallel relationship between the defined target atomic capabilities.

[0085] For example, compare the postconditions of atomic capability A (e.g., the instance status is running) with the preconditions of atomic capability B (e.g., the target cloud host exists and is in a normal state). If the postconditions of A can serve as evidence of the preconditions of B, then it can be deduced that B depends on A.

[0086] For another example, directly reading the dependency field in the capability descriptor of atomic capability B, if the value is ["network.subnet.query", "quota.check"], then it is determined that before executing B, the two atomic capabilities network.subnet.query and quotaa.check in the list must be executed first.

[0087] In this step, the execution dependencies between atomic capabilities are automatically derived, replacing manual or fixed script maintenance, making the orchestration results more accurate and avoiding process failures caused by incorrect execution order.

[0088] S350. Arrange multiple target atomic capabilities into a capability chain based on execution dependencies.

[0089] For example, each target atomic capability is treated as a node, and all execution dependencies determined in the previous step (such as "A→B" indicating that B depends on A) are treated as directed edges to construct a complete directed graph.

[0090] Optionally, the directed graph can be topologically sorted to obtain a linear execution sequence. During this process, the presence of cycles (e.g., A→B→C→A) in the directed graph is checked. If a cycle exists, it indicates an incorrect atomic capability dependency definition or an unmet business requirement, and the reason for non-arrangement is returned.

[0091] In this step, abstract execution dependencies are transformed into concrete, executable capability chains, providing a clear execution blueprint for the execution controller and improving the efficiency of automated delivery.

[0092] S360 executes multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0093] The technical solution of this invention, by utilizing preconditions, postconditions and dependent capabilities to construct a capability chain, ensures that the orchestration process is based on evidence and that the generated execution plan is logically rigorous, thereby effectively solving the problems of lack of condition expression between atomic capabilities and difficulty in automatically deriving dependencies.

[0094] An optional technical solution involves determining the execution dependencies between multiple target atomic capabilities based on at least one of the preconditions, postconditions, and dependent capabilities represented by each capability descriptor, including:

[0095] In response to the preconditions and postconditions represented by each capability descriptor, it is determined that the postcondition of the first atomic capability among multiple target atomic capabilities satisfies the precondition of the second atomic capability, thus obtaining the execution dependency relationship representing the execution of the second atomic capability after the first atomic capability.

[0096] In response to at least one of the preconditions, postconditions, and dependent capabilities represented by each capability descriptor, it is determined that there is no data dependency between the first atomic capability and the second atomic capability, and an execution dependency relationship representing the parallel execution of the first atomic capability and the second atomic capability is obtained.

[0097] Among them, the first atomic capability and the second atomic capability are different target atomic capabilities.

[0098] When the postconditions of the first atomic capability satisfy the preconditions of the second atomic capability, the execution dependencies representing the execution of the second atomic capability after the first atomic capability are obtained. Based on this, directed edges from the first atomic capability to the second atomic capability can be added to the DAG. Generating execution dependencies based on objective condition matching rather than manual specification makes the orchestration results more robust and self-explanatory, and allows for rapid identification of which precondition was not met after a failure.

[0099] In the absence of data dependencies between the first and second atomic capabilities, the execution dependency relationship representing the parallel execution of the first and second atomic capabilities is obtained. That is, if two target atomic capabilities have no data dependencies and resource mutual exclusion, they can be marked as parallel execution. Here, data dependency can be understood as the output of one target atomic capability being the data or state required for the input of another target atomic capability. Automatically identifying and marking parallelizable target atomic capabilities maximizes the utilization of concurrency capabilities, shortens the overall delivery time for complex business requirements, and improves platform response speed.

[0100] For example, assuming the business requirement is "to create a group of application servers and provide services to the outside world through load balancing", the following capability chain is generated: quota.check and network.subnet.ip_check are executed in parallel; after passing, cloud.vm.create is executed; after the cloud host is successfully created, monitor.agent.install, cmdb.resource.write and security.group.apply are executed in parallel; after the security rules are completed, lb.listener.bind is executed; finally, network.connectivity.verify is executed.

[0101] The above technical solution defines in detail the logic for determining serial and parallel dependencies, which not only ensures the correctness of the execution order but also optimizes execution efficiency, achieving a balance between correctness and timeliness.

[0102] Another alternative technical solution, the aforementioned capability orchestration method, may further include:

[0103] In response to the failure of any precondition for the target atomic capability to be met, a target reason is generated and returned, wherein the target reason is the reason for refusing to execute the target atomic capability.

[0104] In response to any target atomic capability failing during execution, the postconditions of the target atomic capability are checked, or at least one of the following actions is performed for the target atomic capability: retry, rollback, and compensation.

[0105] In response to the failure of a postcondition for any target atom capability to be met, a compensation action is performed for the target atom capability.

[0106] Among them, the failure to meet the preconditions indicates that the necessary conditions were not met during the pre-execution check. The target reason can be understood as information describing why the preconditions failed, such as "insufficient quota" or "no remaining IPs in the subnet".

[0107] If the preconditions for any target atomic capability are not met, the underlying operation is not executed and the target reason is returned directly. For example, before calling the adapter for the "cloud.vm.create" capability, its preconditions are evaluated. By querying the CMDB or cloud platform API, it is found that the tenant's Central Processing Unit (CPU) quota is exhausted, indicating that the "quota sufficient" condition is not met. At this point, the execution of the target atomic capability can be immediately stopped, i.e., the underlying creation interface is not called. Then, the specific reason "tenant CPU quota insufficient" is encapsulated into an error response and returned to the upper-layer business requirement entry point. This proactive detection and prevention of operation failures due to unmet environmental conditions avoids invalid API calls and partially configured resource states, while returning a clear failure reason to the user facilitates quick location and resolution of problems.

[0108] In the event that any target atomic capability fails during execution, a predefined failure handling strategy is executed. For example, if cloud host creation times out, the underlying platform task status can be queried. If the resource has already been created, post-condition verification is performed; otherwise, at least one of the following actions is executed: retry, rollback, or compensation. A systematic exception recovery mechanism is provided, which, through retry, rollback, and compensation actions, maximizes the consistency of the system state and avoids the generation of a "half-configured state."

[0109] The failure to meet a postcondition indicates that the target atomic capability was successfully executed, but the final state does not meet expectations. Compensation actions, unlike rollback actions, are remedial actions that bring the system to a consistent state. Compensation actions are executed when the postconditions of any target atomic capability are not met. For example, if a cloud host is successfully created but the network is unreachable, compensation actions are executed, such as reconfiguring routes, unbinding load balancers, or deleting resources. This provides remedial measures for scenarios where operations succeed but the results are not as expected, significantly enhancing the system's fault tolerance and delivery quality, and ensuring the correctness of the final state.

[0110] The above technical solution defines failure handling strategies for the three stages of preconditions, execution process, and postconditions, forming a complete exception handling closed loop and improving the robustness of the automated process.

[0111] Figure 4This is a flowchart of another capability orchestration method provided by an embodiment of the present invention. This embodiment is based on and optimized from the above-described technical solutions. In this embodiment, optionally, determining a target atomic capability from multiple atomic capabilities based on a resource model and constraints includes: reading capability descriptors of multiple atomic capabilities from a capability registry center, and determining a capability descriptor that matches the resource model and constraints from the multiple capability descriptors; and using the atomic capability described by the determined capability descriptor as the target atomic capability. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0112] See Figure 4 The method in this embodiment may specifically include the following steps:

[0113] S410. In response to business needs, analyze the business needs to obtain the resource model and constraints.

[0114] S420. Read capability descriptors of multiple atomic capabilities from the capability registry center, and determine the capability descriptor that matches the resource model and constraints from the multiple capability descriptors. The multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0115] The capability registry center can be understood as a centralized service for managing capability descriptors, capability versions, permission tags, dependencies, availability status, and adapter addresses. In this embodiment of the invention, the capability registry center may optionally be implemented using a database, configuration center, or service registry center.

[0116] Capability descriptors are read from the capability registry, and those matching the resource model and constraints are selected from multiple descriptors to filter out target atomic capabilities that meet business needs based on the resource model and constraints. For example, the parsed constraints "Security Partition = Production III Zone" and "Operation Type = Network Change" are used as query conditions to search for capability descriptors in the capability registry whose `permission_tag` field contains "Production III Zone" and "Network Change". As another example, "Resource Type = Cloud Host" in the resource model is converted into a query for `capability_type`, such as `capability_type = compute`, and combined with the keyword "create" in `capability_name` for fuzzy matching to find the corresponding capability descriptor. Rule matching in the capability registry automates capability discovery and filtering, eliminating the need for hard-coding underlying vendor interfaces for upper-layer orchestration logic, making it easy to maintain and extend.

[0117] S430. Take the atomic capabilities described by the determined capability descriptors as target atomic capabilities, and arrange multiple target atomic capabilities into a capability chain.

[0118] For example, when only one capability descriptor fully matches all resource models and constraints, its corresponding atomic capability is directly used as the target atomic capability. As another example, when multiple capability descriptors (such as the same atomic capability in different versions, or similar atomic capabilities from different vendors) match, a comprehensive score can be calculated based on capability version stability, execution success rate, and platform affinity. The capability descriptor with the highest score is selected, and its corresponding atomic capability is used as the target atomic capability.

[0119] This step transforms logical "business requirements" into executable "target atomic capabilities," ensuring that the selected target atomic capabilities are best suited to the current business needs.

[0120] S440: Execute multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0121] The technical solution of this invention, by limiting the process from dynamically discovering to selecting target atomic capabilities from the capability registry center, replaces the method of hard-coding calls to specific platform APIs, thus achieving cross-platform capability adaptation.

[0122] An optional technical solution, the above capability orchestration method may further include:

[0123] For capability descriptors to be registered to the capability registry, the capability descriptors shall be validated based on at least one of the following: field integrity, input and output type, existence of dependencies, availability of rollback operation, and compliance of permission tags.

[0124] In response to the successful verification of the capability descriptor, a corresponding capability version is generated for the atomic capability described by the capability descriptor, and the capability descriptor and capability version are registered with the capability registry center.

[0125] For newly packaged or updated atomic capabilities, their capability descriptors must be registered with the capability registry. The capability registry then performs a series of automated checks (i.e., validations) to ensure the quality and executability of the capability descriptors. For example, upon receiving a capability descriptor, the capability registry first checks if all required fields exist, and then checks if the capability identifier listed in the dependency field already exists in the capability registry and is in an "available" state. As another example, the capability registry checks if the rollback capability identifier specified in the rollback_action field exists and if its permission_tag matches the registered capability. Simultaneously, it verifies whether the permission_tag itself conforms to predefined permission tag requirements. Through automated validation, the standardization, completeness, and executability of the capability descriptors added to the database are guaranteed, preventing orchestration failures caused by incorrect atomic capability definitions from the outset.

[0126] Furthermore, if the capability descriptor verification passes, a capability version can be generated for the corresponding atomic capability, and the capability descriptor and capability version can be registered with the capability registry center. For example, after successful verification, the capability registry center checks if the capability_id exists. If it does not exist (new atomic capability), an initial capability version 1.0.0 is generated; if it exists (atomic capability upgrade), the major or minor version number is incremented, such as upgrading from 1.0.2 to 1.0.3, while retaining the old capability version. Then, all the contents of the capability descriptor, along with the generated capability version, are stored in the capability registry center, and the atomic capability discovery list is updated, enabling the orchestration decision engine to query and retrieve the atomic capability of the new capability version. This achieves the governance and evolution of capability versions; old capability version processes can still run stably, while new capability versions are used by new processes, thereby solving the problem of difficult capability version governance and standardizing capability asset accumulation.

[0127] The above technical solution, through rigorous verification and version management of the capability registration process, ensures the quality and traceability of the atomic capability library, providing a high-quality capability foundation for reliable upper-layer orchestration services.

[0128] Based on this, in order to better understand the above technical solutions as a whole, the following will provide an exemplary description of the atomic capability encapsulation and dynamic orchestration system.

[0129] For example, see Figure 5 , Figure 6 As shown in Table 3, the system includes a business requirement entry point, a requirement parser, a capability registry center, an atomic capability library, an orchestration decision engine, an execution controller, a platform adaptation terminal, and a result storage unit. Based on this, the execution flow of the system is as follows:

[0130] 1. Define capability descriptors: The capability development end encapsulates the underlying API or script operation capabilities into atomic capabilities, and supplements each atomic capability with one or more of the following: input parameters, output parameters, preconditions, postconditions, dependent capabilities, rollback operations, idempotent keys, and permission tags.

[0131] 2. Registering Capability Descriptors and Capability Versions: The capability registry verifies the capability descriptors and generates capability versions upon successful verification. Then, it registers both the capability descriptors and capability versions. If an atomic capability is upgraded, the old version is retained for stable execution of already published processes.

[0132] 3. Parse business requirements: After receiving business requirements, the requirement parser converts the natural language, form fields, or interface parameters in the business requirements into resource models and constraints.

[0133] 4. Matching atomic capabilities: The orchestration decision engine retrieves capability descriptors that meet the requirements of resource type, security partition, permission label and version from the capability registry based on resource model and constraints, and then retrieves the atomic capability (i.e. target atomic capability) corresponding to the capability descriptor from the atomic capability library.

[0134] 5. Generate DAG capability chain: The orchestration decision engine generates DAG capability chain based on the preconditions, postconditions and capability dependencies between each atomic capability.

[0135] 6. Execution Capability Chain: The execution controller executes each atomic capability in the DAG topology order, injecting context parameters into each atomic capability and recording the requirement identifier, capability version, input parameters, output parameters, execution time, and result status. Parallel execution is performed on nodes that can be executed concurrently, while timing is maintained for nodes that need to be executed sequentially. In this example, the execution controller can interface with various underlying platforms through a platform adapter to invoke the corresponding operational capabilities.

[0136] 7. Abnormal retry and rollback: When an atomic capability fails to execute, the execution controller first executes the retry action according to the retry policy in the capability descriptor; if it still fails, it calls the rollback action in the reverse topology order of the executed nodes, or executes the compensation action to bring the system back to a consistent state.

[0137] 8. Execution result closure: After execution, all postconditions are verified, and the resource identifier, network address, monitored object, CMDB record, work order status and audit log are written to the result storage unit.

[0138] Table 3 Main functions and outputs of each module

[0139]

[0140] The above example describes atomic capabilities by defining unified capability descriptors; registers, verifies, and manages versions of various atomic capabilities through a capability registry center; converts business requirements into resource models and constraints through a requirement parser; matches capability descriptors from the capability registry center and then matches atomic capabilities from the atomic capability library through an orchestration decision engine, automatically generating a DAG capability chain; the execution controller calls the platform adapter according to the DAG topology order and performs idempotent control, concurrency control, exception retries, and rollback compensation; finally, the execution results are written back to each underlying platform. In other words, through atomic capability encapsulation and dynamic orchestration, underlying operational capabilities are abstracted into reusable, verifiable, orchestratable, and rollbackable atomic capabilities, and business requirements are automatically orchestrated into DAG capability chains for automated invocation, thereby enabling the combination and automatic delivery of atomic capabilities across clouds, networks, and resource types.

[0141] The above example has at least the following advantages:

[0142] 1. By using a unified capability descriptor, APIs, scripts, and tools from heterogeneous platforms are encapsulated into atomic capabilities, reducing the dependence of upper-layer processes on specific platform interfaces.

[0143] 2. By using preconditions and postconditions, the system can determine whether the conditions are met before execution and automatically verify the delivery results after execution, reducing the number of semi-configured states.

[0144] 3. By using DAG orchestration, complex delivery processes are broken down into capability chains that can be parallelized, serialized, and rolled back, thereby improving the efficiency and stability of automated delivery.

[0145] 4. By using idempotent keys and execution context records, duplicate resource creation can be avoided, and retrying on failure, resuming execution from breakpoints, and tracing results can be supported.

[0146] 5. Through capability version governance and access control, capability assets are reusable, auditable, and evolvable, making them suitable for standardized management in production environments.

[0147] 6. By shielding the differences between underlying platforms through platform adapters, a scalable foundation for the cloud management platform is provided.

[0148] Figure 7 This is a structural block diagram of a capability orchestration system provided in an embodiment of the present invention. This device is used to execute the capability orchestration method provided in any of the above embodiments. This device and the capability orchestration methods of the above embodiments belong to the same inventive concept. Details not described in detail in the embodiments of the capability orchestration system can be found in the embodiments of the above capability orchestration methods. See also... Figure 7 Specifically, the device may include: a demand parser 510, an orchestration decision engine 520, and an execution controller 530.

[0149] Among them, the requirement parser 510 is used to respond to business requirements, parse the business requirements, and obtain the resource model and constraints.

[0150] The orchestration decision engine 520 is used to determine target atomic capabilities from multiple atomic capabilities based on resource models and constraints, and orchestrate multiple target atomic capabilities into a capability chain. Each atomic capability is obtained by encapsulating the operational capabilities of heterogeneous platforms.

[0151] The execution controller 530 is used to execute multiple target atomic capabilities according to the capability chain to fulfill business requirements.

[0152] Optionally, the orchestration decision engine 520 may include:

[0153] The capability descriptor acquisition submodule is used to acquire capability descriptors for multiple target atomic capabilities;

[0154] The Atomic Capability Orchestration submodule is used to orchestrate multiple target atomic capabilities into capability chains based on each capability descriptor.

[0155] Based on this, the optional atomic capability orchestration submodule may include:

[0156] The execution dependency determination unit is used to determine the execution dependency between multiple target atomic capabilities based on at least one of the preconditions, postconditions and dependent capabilities represented by each capability descriptor.

[0157] Atomic capability orchestration unit, used to orchestrate multiple target atomic capabilities into a capability chain based on execution dependencies;

[0158] Among them, the preconditions represent the technical conditions that need to be met before executing the corresponding atomic capabilities, the postconditions represent the result conditions that need to be verified after executing the corresponding atomic capabilities, and the dependent capabilities represent the atomic capabilities that need to be relied upon in addition to the corresponding atomic capabilities.

[0159] Based on this, an optional dependency determination unit is implemented, specifically for:

[0160] In response to the preconditions and postconditions represented by each capability descriptor, it is determined that the postcondition of the first atomic capability among multiple target atomic capabilities satisfies the precondition of the second atomic capability, thus obtaining the execution dependency relationship representing the execution of the second atomic capability after the first atomic capability.

[0161] In response to at least one of the preconditions, postconditions, and dependent capabilities represented by each capability descriptor, it is determined that there is no data dependency between the first atomic capability and the second atomic capability, and an execution dependency relationship representing the parallel execution of the first atomic capability and the second atomic capability is obtained.

[0162] Alternatively, the aforementioned capability orchestration system may also include:

[0163] The target reason return module can be used to generate and return a target reason in response to the failure of any target atomic capability's preconditions, where the target reason is the reason for refusing to execute the target atomic capability;

[0164] The postcondition verification module is used to verify the postconditions of the target atomic capability in response to the failure of any target atomic capability during execution, or to perform at least one of the actions of retry, rollback and compensation for the target atomic capability.

[0165] The compensation action execution module is used to perform compensation actions on the target atomic capability in response to the failure of the postcondition of any target atomic capability.

[0166] Optionally, the execution controller 530 is used specifically for:

[0167] Based on the capability chain, determine the current atomic capability to be executed among multiple target atomic capabilities;

[0168] In response to the successful execution of the current atomic capability, retrieve the historical execution results of the current atomic capability and use the historical execution results as the current execution result of the current atomic capability;

[0169] In response to the current atomic capability being in an executing state, return the waiting state for the current atomic capability or the execution result of the capability that subscribed to the current atomic capability;

[0170] In response to the failure of the current atomic capability and the permission to retry, the resource creation status corresponding to the current atomic capability is checked, and the retry action is performed based on the resource creation status.

[0171] Optionally, the aforementioned capability orchestration system may further include: a capability registry center and an atomic capability library; wherein,

[0172] Orchestration decision engine, specifically used for:

[0173] Read capability descriptors for multiple atomic capabilities from the capability registry, and determine the capability descriptor that matches the resource model and constraints from the multiple capability descriptors;

[0174] The atomic capabilities described by the determined capability descriptors are used as target atomic capabilities, and multiple target atomic capabilities are arranged into capability chains;

[0175] The execution controller is specifically used for:

[0176] According to the capability chain, call and execute multiple target atomic capabilities in the atomic capability library to fulfill business requirements.

[0177] In addition, the aforementioned capability orchestration system may optionally include:

[0178] The capability descriptor verification module is used to verify capability descriptors to be registered to the capability registry center based on at least one of the following: field integrity, input / output type, existence of dependencies, availability of rollback operation, and compliance of permission tags.

[0179] The capability descriptor registration module is used to generate a corresponding capability version for the atomic capability described by the capability descriptor in response to the capability descriptor passing the verification, and register the capability descriptor and capability version to the capability registry center.

[0180] The capability orchestration system provided in this invention, through a requirement parser, responds to business needs by parsing the business requirements to obtain resource models and constraints. Through an orchestration decision engine, based on the resource models and constraints, it determines target atomic capabilities from multiple atomic capabilities and orchestrates these target atomic capabilities into a capability chain. These multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms. Through an execution controller, it executes the multiple target atomic capabilities according to the capability chain to fulfill the business requirements. This device, through three core steps—business requirement parsing, atomic capability orchestration, and capability chain execution—establishes an automated closed-loop process from business requirements to resource delivery. This fundamentally solves the problem of high response complexity caused by inconsistencies in parameter formats, authentication methods, and idempotency mechanisms across different platforms, thus reducing the response complexity to business requirements.

[0181] The capability orchestration system provided in the embodiments of the present invention can execute the capability orchestration method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0182] It is worth noting that in the embodiments of the above capability orchestration system, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0183] Figure 8A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0184] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0185] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0186] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as capability orchestration methods.

[0187] In some embodiments, the capability orchestration method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the capability orchestration method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the capability orchestration method by any other suitable means (e.g., by means of firmware).

[0188] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips or system-on-a-chips (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0189] Computer programs used to implement the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0190] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0191] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0192] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0193] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0194] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication unit 19, or installed from storage unit 18, or installed from ROM 12. When the computer program is executed by processor 11, it performs the functions defined in the methods of the embodiments of the present invention.

[0195] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0196] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A capability orchestration method, characterized in that, include: In response to business requirements, the business requirements are analyzed to obtain resource models and constraints; Based on the resource model and the constraints, target atomic capabilities are determined from multiple atomic capabilities, and the multiple target atomic capabilities are arranged into a capability chain, wherein each atomic capability is obtained by encapsulating the operational capabilities of heterogeneous platforms; Execute multiple target atomic capabilities according to the capability chain to fulfill the business requirements.

2. The method according to claim 1, characterized in that, The step of arranging the multiple target atomic capabilities into a capability chain includes: Acquire capability descriptors for multiple target atomic capabilities; Based on each of the capability descriptors, the multiple target atomic capabilities are arranged into a capability chain.

3. The method according to claim 2, characterized in that, The arrangement of multiple target atomic capabilities into a capability chain based on each of the capability descriptors includes: Based on at least one of the preconditions, postconditions, and dependent capabilities represented by each of the capability descriptors, the execution dependencies between the multiple target atomic capabilities are determined; Based on the execution dependencies, the multiple target atomic capabilities are arranged into a capability chain; Wherein, the precondition represents the technical conditions that need to be met before executing the corresponding atomic capability, the postcondition represents the result conditions that need to be verified after executing the corresponding atomic capability, and the dependent capability represents the atomic capabilities that need to be relied upon in addition to the corresponding atomic capability.

4. The method according to claim 3, characterized in that, The step of determining the execution dependency relationship between multiple target atomic capabilities based on at least one of the preconditions, postconditions, and dependent capabilities represented by each capability descriptor includes: In response to the preconditions and postconditions represented by each of the capability descriptors, it is determined that the postcondition of the first atomic capability among the plurality of target atomic capabilities satisfies the precondition of the second atomic capability, thereby obtaining the execution dependency relationship representing that the second atomic capability is executed after the first atomic capability; In response to at least one of the preconditions, postconditions, and dependent capabilities represented by each of the capability descriptors, it is determined that there is no data dependency between the first atomic capability and the second atomic capability, and an execution dependency relationship representing the parallel execution of the first atomic capability and the second atomic capability is obtained.

5. The method according to claim 3, characterized in that, Also includes: In response to the failure to meet any of the preconditions for the target atomic capability, a target reason is generated and returned, wherein the target reason is the reason for refusing to execute the target atomic capability; In response to any of the target atomic capabilities failing during execution, the postconditions of the target atomic capability are checked, or at least one of retry, rollback, and compensation is performed for the target atomic capability. In response to the failure to meet any of the postconditions of the target atomic capability, a compensation action is performed for the target atomic capability.

6. The method according to claim 1, characterized in that, The execution of multiple target atom capabilities according to the capability chain includes: Based on the capability chain, determine the current atomic capability to be executed among the multiple target atomic capabilities; In response to the successful execution of the current atomic capability, the historical execution results of the current atomic capability are obtained, and the historical execution results are used as the current execution result of the current atomic capability; In response to the current atomic capability being in an executing state, return either a waiting state for the current atomic capability or the execution result of the capability subscribed to the current atomic capability; In response to the failure of the current atomic capability and the permission to retry, the resource creation status corresponding to the current atomic capability is verified, and a retry action is performed based on the resource creation status.

7. The method according to claim 1, characterized in that, The process of determining the target atomic capability from multiple atomic capabilities based on the resource model and the constraints includes: Read capability descriptors of multiple atomic capabilities from the capability registry, and determine the capability descriptor that matches the resource model and the constraints from the multiple capability descriptors; The atomic capability described by the determined capability descriptor is taken as the target atomic capability.

8. The method according to claim 7, characterized in that, Also includes: For the capability descriptor to be registered to the capability registry, the capability descriptor is validated based on at least one of the following: field integrity, input / output type, existence of dependencies, availability of rollback operation, and compliance of permission tags. In response to the capability descriptor passing the verification, a corresponding capability version is generated for the atomic capability described by the capability descriptor, and the capability descriptor and the capability version are registered to the capability registration center.

9. A capability orchestration system, characterized in that, include: The components include a requirements parser, an orchestration decision engine, and an execution controller; among them, The requirement parser is used to respond to business requirements, parse the business requirements, and obtain resource models and constraints. The orchestration decision engine is used to determine target atomic capabilities from multiple atomic capabilities based on the resource model and the constraints, and to orchestrate the multiple target atomic capabilities into a capability chain, wherein the multiple atomic capabilities are obtained by encapsulating the operational capabilities of heterogeneous platforms; The execution controller is configured to execute multiple target atomic capabilities according to the capability chain to fulfill the business requirements.

10. The system according to claim 9, characterized in that, Also includes: Capability registry and atomic capability library; among which, The orchestration decision engine is specifically used for: The capability descriptors of multiple atomic capabilities are read from the capability registry, and the capability descriptor that matches the resource model and the constraints is determined from the multiple capability descriptors. The atomic capabilities described by the determined capability descriptors are taken as target atomic capabilities, and multiple target atomic capabilities are arranged into a capability chain; The execution controller is specifically used for: According to the capability chain, multiple target atomic capabilities in the atomic capability library are invoked and executed to fulfill the business requirements.

Images