WO2025145992A1 - 组装过程扩展性的实现方法及装置 - Google Patents

组装过程扩展性的实现方法及装置 Download PDF

Info

Publication number
WO2025145992A1
WO2025145992A1 PCT/CN2024/143403 CN2024143403W WO2025145992A1 WO 2025145992 A1 WO2025145992 A1 WO 2025145992A1 CN 2024143403 W CN2024143403 W CN 2024143403W WO 2025145992 A1 WO2025145992 A1 WO 2025145992A1
Authority
WO
WIPO (PCT)
Prior art keywords
orchestration
plug
api
definition file
script
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
PCT/CN2024/143403
Other languages
English (en)
French (fr)
Inventor
盛龙
杨鑫
蒲哲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Publication of WO2025145992A1 publication Critical patent/WO2025145992A1/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons

Definitions

  • the embodiments of the present disclosure relate to the technical field of enterprise application development, and in particular to a method and device for implementing assembly process scalability.
  • the basic object of the "assembly application” technology is the component, and a package or version package is built by selecting components with fixed functions.
  • the embodiments of the present disclosure provide a method and device for realizing the scalability of an assembly process.
  • a device for implementing extensibility of an assembly process comprising: an assembly module, configured to select a reusable functional unit and obtain a first definition file set based on the reusable functional unit; a plug-in orchestration module, configured to parse the first definition file set to obtain a first orchestration object; and, perform orchestration processing on the first orchestration object to obtain a second orchestration object; a plug-in generation module, configured to obtain a second definition file set based on the second orchestration object; and, configured to obtain a target plug-in based on the second definition file set, so that the target plug-in provides extensibility capabilities for the component.
  • a computer-readable storage medium in which a computer program is stored, wherein the computer program is configured to execute the steps of any one of the above method embodiments when running.
  • an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
  • FIG1 is a flow chart of an application assembly according to the related art
  • FIG. 3 is a flow chart of a method for performing plug-in-plug-in orchestration-plug-in on an API plug-in according to an embodiment of the present disclosure
  • FIG. 4 is a flowchart of a method for obtaining a first arrangement object based on a first definition file according to an embodiment of the present disclosure
  • FIG. 5 is a flowchart of a method for obtaining a second orchestration object based on a first orchestration object according to an embodiment of the present disclosure
  • FIG6 is a first schematic diagram of a framework of a method for implementing assembly process extensibility according to an embodiment of the present disclosure
  • FIG7 is a schematic diagram of a framework of an assembly process according to an embodiment of the present disclosure.
  • FIG9 is a schematic diagram of a framework of a parsing and orchestration process for an API type plug-in according to an embodiment of the present disclosure
  • FIG12 is a schematic diagram of a framework for expanding capability accumulation according to an embodiment of the present disclosure.
  • FIG13 is a schematic diagram of a framework for information interaction among a client, a script, and a server according to an embodiment of the present disclosure
  • FIG14 is a schematic diagram of the framework of the API selected and the API generated during the conversion between the web service protocol and the rest protocol according to an embodiment of the present disclosure
  • PBC Packaged Business Capability
  • FIG. 1 is a flowchart of an application assembly according to the related art. As shown in FIG. 1 ,
  • PBC is used for application assembly.
  • the complete process of application assembly is divided into the following four stages:
  • the asset operator is responsible for operating the PBC component assets, maintaining and managing the component assets' business description metadata information, asset categories, lifecycles, versions, authorizations, SLAs (service level agreements), etc.
  • Non-professional developers use low-code or full-code tools to assemble and develop business applications or solutions to meet business innovation needs.
  • the assembly technology in related technologies is mainly based on components.
  • components to build a package or version package when an existing component has missing functions, it is often necessary to modify the code and recompile and package the output component version.
  • the process is relatively complicated and inflexible. There is no flexible mechanism to adjust the configuration of the component without modifying the component, or to provide different business configurations for components in different business scenarios.
  • the assembly stage is in the design stage of the entire application assembly process. This stage assembles and develops enterprise applications or solutions based on existing component assets.
  • the "scalability” mentioned in this disclosure refers specifically to the “assembly process scalability", which means that new component business capabilities can be quickly built based on existing components. Achieving scalability can greatly enhance the adaptability of assembled applications to different enterprises and complex business scenarios, and can also provide users with richer component integration and component operation and maintenance functions. At present, the industry has not yet achieved a method to achieve scalability in the assembly process, which is also a major problem in the implementation of assembled applications.
  • FIG. 2 is a flow chart of a method for implementing assembly process extensibility according to an embodiment of the present disclosure. As shown in FIG. 2 ,
  • Step S203 performing arrangement processing on the first arrangement object to obtain a second arrangement object
  • Step S205 obtaining a target plug-in based on the second definition file set, so that the target plug-in provides extensibility capabilities for the component.
  • the difference between the first arrangement object and the second arrangement object lies in the different values of the fields.
  • the plug-ins generated by the reusable functional units are used to expand the capabilities of the components, avoiding the modification of component codes and improving the efficiency of modifying the package or version package. This can speed up application development and solve some challenges and problems in traditional development.
  • the method before selecting the reusable functional unit and obtaining the first definition file set based on the reusable functional unit, the method further includes:
  • Target plugins are plugins that act as reusable units of functionality.
  • the method further includes:
  • combining the target plug-in and the components of the reusable functional unit is beneficial for supplementing the functions not covered by the component through the plug-in without modifying the component code, thereby facilitating the generation of package packages or version packages that meet performance requirements based on the target plug-in and the component.
  • a method of combining a target plug-in with a component of a reusable functional unit is as follows:
  • Import plug-in Introduce the plug-in file into the component code. You can use the import statement or use the script tag in HTML to import the plug-in script file.
  • Register the plugin Depending on how the plugin is used, you may need to register the plugin in the component. Some plugins may be registered automatically, while others require manual execution of the registration function.
  • Use plugin functions Add plugin functions to components by calling the API or methods provided by the plugin. At the appropriate time, call the methods provided by the plugin to implement the corresponding functions.
  • Composing new components When the functionality of a plugin is successfully attached to a component, the component can be considered a new component with that functionality.
  • the use and configuration of the plugin functionality can be controlled through the props or state of the component.
  • Package as a package or version package Package the component and provide corresponding parameters and configuration options. You can use tools or scripts to package and publish the component package or version.
  • the first orchestration object or the second orchestration object includes: an API object, a configuration object, and a script object; wherein:
  • the API object includes the API definition information generated by the orchestration
  • the configuration object includes the configuration file information set by the orchestration
  • the script object includes the file address, execution engine, and running parameters of the script set by the orchestration.
  • FIG3 is a flow chart of a method for performing plug-in-plug-in orchestration-plug-in on an API plug-in according to an embodiment of the present disclosure. As shown in FIG3 ,
  • a target plug-in is obtained based on the second definition file set and the script parameters.
  • the assembly process is the process of combining components. During the assembly process, users select components based on business requirements, and the assembly tool performs dependency analysis on the components and automatically selects the dependent components.
  • the definition file has a certain fixed format and is a complete information description of the component or plug-in.
  • the content includes basic information, component/plug-in dependencies, topology information, resource information, business configuration and API definition. This disclosure mainly focuses on the API definition part in the definition file.
  • the orchestrator imports the definition file and generates an orchestration object.
  • the orchestration object is the visual representation of the component or plug-in in the orchestrator.
  • the user uses the interface to combine the orchestration objects in the orchestrator to complete the orchestration.
  • the plug-in orchestration process generates the orchestration object, which includes API objects, configuration objects, and script objects.
  • the API object contains the API definition information generated by the orchestration
  • the configuration object contains the configuration file information of the orchestration settings
  • the script object describes the file address, execution engine, and running parameters of the orchestration script.
  • Plugin publishing process According to the plugin orchestration output, a definition file is constructed, and finally the definition file and plugin orchestration output are published to the assembly tool to become a new plugin.
  • the method described in the present disclosure uses definition files as resources, constructs extension capabilities through a plug-in orchestration process, and finally publishes the extension capabilities as plug-ins for use in subsequent assembly processes, thereby realizing the extensibility of the application assembly process.
  • FIG. 7 is a schematic diagram of a framework of an assembly process according to an embodiment of the present disclosure. As shown in FIG. 7 ,
  • the user selects components in the assembly tool according to actual needs. Each component needs to provide a definition file. After the user selects the components, the assembly process will output a set of these definition files (ie, the first definition file set).
  • the definition file is a description specification of components and plug-ins. It has a fixed format and is a complete information description of components or plug-ins. It is also the basis for assembly tools to identify components and plug-ins.
  • the definition file content includes basic information, component/plug-in dependencies (dependent), topology information (topo), resource information (resource), script information (script), business configuration (config) and API definition (api).
  • the API definition includes the API interface details provided by the component (exposed APIs), the dependent APIs and dependent components (dependent APIs), which is a detailed description of the API provided by the component.
  • the API provided by the component can be a variety of application layer protocols, such as rest protocol, web service protocol and rpc protocol.
  • the method and url fields describe the http layer method and address of an interface
  • the protocol describes the application layer protocol type of the interface
  • the specification is the protocol file address, which is a complete definition of a set of interfaces.
  • the specification is the swagger file address
  • the specification is the wsdl file address
  • the specification is the proto file address.
  • dependent APIs are the components and interfaces that the component depends on, where name and kind describe the dependent component or plugin, and the kind type indicates whether the object is a component or plugin.
  • apiName is the name of the dependent API.
  • the method, url, and specification under dependent APIs have similar meanings to the fields of the same name under exposed APIs, and are used to describe an API.
  • Steps 2 to 3 Parse component definition and generate orchestration objects; user orchestration plug-in to generate orchestration objects.
  • This step is mainly the responsibility of the plug-in orchestrator, which is the specific implementation of the plug-in orchestration process.
  • the definition file output in step 1 is used as the data source, and the specific fields of the definition file are parsed, and the orchestration object is constructed and displayed in the orchestration interface. Users use the plug-in orchestrator interface to perform function orchestration, and the final output is the orchestration object.
  • FIG8 is a schematic diagram of a plug-in arrangement process according to an embodiment of the present disclosure. As shown in FIG8 ,
  • the first orchestration object generated by parsing the definition file and the second orchestration object generated by the plug-in both comply with the definition specification of the orchestration object, and the two are equivalent. For example, if the first orchestration object generated by the definition file is "API type orchestration object A”, then the second orchestration object generated by the orchestration is "API type orchestration object B". Both have the same definition format, and only the specific field values are different.
  • the plugin orchestrator can orchestrate three types of objects: API, configuration, and script.
  • the orchestration API is suitable for adding extended functions to components. For example, when a single API in an existing component cannot meet the requirements, but combining multiple APIs can meet the requirements, the APIs of multiple components are combined in the plug-in orchestrator and business logic is added to finally generate an API that meets the requirements.
  • Another typical application scenario is API forwarding.
  • the plug-in orchestration generates a new API as a proxy for the component API.
  • business functions can be orchestrated, such as adding authentication, monitoring, request filtering, and statistics.
  • plug-in orchestration can be used to provide extension capabilities for existing components without intrusive modification of the components and without affecting the existing functions and APIs of the components.
  • Orchestration configuration is applicable to providing multi-business scenario configurations for components.
  • components need to use different configurations according to different business scenarios, multiple sets of configurations can be provided through plug-in orchestration, namely configuration type plug-ins. Users can select these configuration plug-ins when assembling different business scenario version packages, thus achieving the purpose of dynamic assembly configuration during the assembly process.
  • Script orchestration is applicable to scenarios where tool scripts, auxiliary functions or sidecar capabilities (the ability to separate application functions from the application itself as a separate process) are provided for components. For example, when the version package is deployed, it is necessary to set the common environment variables and file permissions of the components. These functions are not what a component should provide and are irrelevant to the business. They are more suitable to be implemented using separate tool scripts. Plugin orchestration provides a convenient way to orchestrate scripts for these scenarios without intruding into the components for modification.
  • the plug-in orchestrator imports the definition file, parses the definition file, and generates a first orchestration object, which is displayed on the orchestrator interface for the user to use.
  • the parsing process of the API type plug-in import the definition file, parse the API definition (api field), the orchestrator obtains the swagger file according to the exposed API field, downloads and parses the swagger file to obtain detailed information of the API, and constructs an orchestration object for each API.
  • the orchestration object contains the definition and dependencies of this API.
  • the specific parsing fields are: traverse all APIs under the exposed APIs in the definition file, parse swagger to obtain API detailed information, generate the api field in the component object, and take the dependent APIs field in the definition file to generate the dependent field in the component object.
  • the dependent field in the orchestration object describes the dependency relationship, which corresponds to the dependent in the definition file.
  • dependent describes the dependent API and the components corresponding to the dependent API.
  • the dependent field in the definition file is generated based on the dependent field of the orchestration object, that is, the dependency of the plug-in.
  • the assembly tool can automatically check the components that the plug-in depends on based on the dependent field in the plug-in definition file.
  • FIG. 9 is a schematic diagram of a framework of a parsing and orchestration process for an API type plug-in according to an embodiment of the present disclosure. As shown in FIG. 9 ,
  • API plug-ins users select APIs in the orchestrator interface, fill in the request parameters for calling the API, and define new APIs, including API protocols, request methods, request paths, request parameters, and response parameters.
  • API protocols including API protocols, request methods, request paths, request parameters, and response parameters.
  • the output of API plug-in orchestration is the API orchestration object.
  • FIG. 10 is a schematic diagram of a framework of an orchestration process for a configuration type plug-in according to an embodiment of the present disclosure. As shown in FIG. 10 ,
  • Configuration type plug-in orchestration object The initial content of the configuration corresponding to the orchestration object is empty, there is no fixed definition, and the specific data is filled in by the user in the orchestrator.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本公开实施例提供了一种组装过程扩展性的实现方法及装置，所述方法包括：选择可复用功能单元，基于所述可复用功能单元得到第一定义文件集；对所述第一定义文件集进行解析，得到第一编排对象；对所述第一编排对象进行编排处理，得到第二编排对象；基于所述第二编排对象得到第二定义文件集；基于所述第二定义文件集得到目标插件，以使所述目标插件为组件提供扩展性的能力。

Description

组装过程扩展性的实现方法及装置
相关公开的交叉引用
本公开基于2024年1月5日提交的发明名称为“组装过程扩展性的实现方法及装置”的中国专利公开2024100288008，并且要求该专利公开的优先权，通过引用将其所公开的内容全部并入本公开。
技术领域
本公开实施例涉及企业应用开发的技术领域，具体而言，涉及一种组装过程扩展性的实现方法及装置。
背景技术
传统的应用程序开发面临诸多挑战：一、没有足够的开发能力；二、容易选错技术方向；三、交付不够迅速。为了解决这些问题，一种常见的技术型方案是使用“组装式应用”的技术，以节省时间，提高交付速度。
相关技术中，“组装式应用”技术的针对的基础对象是组件，通过选择固定功能的组件构建套餐包或者版本包。
但是，当固定功能的组件存在功能缺失的情况时，往往需要对组件采用修改代码的方式，重新编译打包输出新的组件版本，再使用新的组件版本构建套餐包或者版本包，过程较为复杂且灵活性低。
发明内容
本公开实施例提供了一种组装过程扩展性的实现方法及装置。
根据本公开的一个实施例，提供了一种组装过程扩展性的实现方法，包括：选择可复用功能单元，基于所述可复用功能单元得到第一定义文件集；对所述第一定义文件集进行解析，得到第一编排对象；对所述第一编排对象进行编排处理，得到第二编排对象；基于所述第二编排对象得到第二定义文件集；基于所述第二定义文件集得到目标插件，以使所述目标插件为组件提供扩展性的能力。
根据本公开的另一个实施例，提供了一种组装过程扩展性的实现装置，包括：组装模块，设置为选择可复用功能单元，基于所述可复用功能单元得到第一定义文件集；插件编排模块，设置为对所述第一定义文件集进行解析，得到第一编排对象；以及，对所述第一编排对象进行编排处理，得到第二编排对象；插件生成模块，设置为基于所述第二编排对象得到第二定义文件集；以及，设置为基于所述第二定义文件集得到目标插件，以使所述目标插件为组件提供扩展性的能力。
根据本公开的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本公开的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
附图说明
图1是根据相关技术的应用组装的流程图；
图2是根据本公开实施例的组装过程扩展性的实现方法的流程图；
图3是根据本公开实施例的对于API插件进行插件-插件编排-插件的方法的流程图；
图4是根据本公开实施例的基于第一定义文件得到第一编排对象的方法的流程图；
图5是根据本公开实施例的基于第一编排对象得到第二编排对象的方法的流程图；
图6是根据本公开实施例的组装过程扩展性的实现方法的框架示意图一；
图7是根据本公开实施例的组装过程的框架示意图；
图8是根据本公开实施例的插件编排过程的框架示意图；
图9是根据本公开实施例的对于API类型插件的解析和编排过程的框架示意图；
图10是根据本公开实施例的对于配置类型插件的编排过程的框架示意图；
图11是根据本公开实施例的对于脚本类型插件的编排过程的框架示意图；
图12是根据本公开实施例的扩展能力积累的框架示意图；
图13是根据本公开实施例的客户端、脚本、服务端进行信息交互的框架示意图；
图14是根据本公开实施例的在web service协议和rest协议转换的过程中选择的API和生成的API的框架示意图；
图15是根据本公开实施例的组装过程扩展性的实现装置的结构示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本公开的实施例。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
相关技术中，传统的应用程序开发面临诸多挑战：一，没有足够的开发能力；二，选错技术方向；三，交付不够迅速。为了解决这些问题，一种常见的技术型方案是“代码重用”，将已有的、较成熟的代码重新应用。以此，可以节省时间，提高交付速度。
而Gartner所提出来的“组装式应用”是通过引入一种新的架构来解决上述问题，它希望引入模块化的理念使技术和业务团队可以更敏捷、更有效地重用代码。通过组装式思维、组装式平台、组装式架构来研发企业级应用，促进数字技术与业务应用深度融合。在复杂多变的情况下，“组装式应用”能提升企业的适应和创新能力，通过制定组件集成和解耦相关规范，为组件的集成开发提供标准依据，推进组件的标准化和认证治理等工作。
“组装式应用”的核心被称为“封装的业务能力(Packaged Business Capability，PBC)”，PBC是一种软件定义的最小化的业务功能。Gartner对于PBC的官方定义指出：PBC是一个定义良好的，能够在功能上被用户识别的软件组件。PBC是一个有边界的集合，这个集合的组成元素是数据schema(数据库对象的集合)，一组服务，一组API(Application Programming Interface，应用程序编程接口)和事件通道。
图1是根据相关技术的应用组装的流程图，如图1所示，
PBC应用于应用组装，应用组装的完整过程分为以下四个阶段：
生产阶段，专业开发者(Pro-Code)使用本地编程语言工具开发各种能力组件，构建、部署PBC组件或应用。
运营阶段，资产运营者负责运营PBC组件资产，维护和管理组件资产的业务描述元数据信息、资产类目、生命周期、版本、授权、SLA(服务级别协议)等。
组装阶段，非专业开发者(Business-IT)使用低代码或全代码工具进行业务应用或解决方案的组装与开发，以应对业务创新需求。
使用阶段，使用者通过业务应用或解决方案解决业务问题，达成业务目标。
相关技术中的组装技术主要基于组件，通过选择组件构建套餐包或版本包，当现有组件有功能缺失时，往往需要修改代码，重新编译打包输出组件版本，过程较为复杂且灵活性低。对于组件使用的配置，也没有灵活的机制在不修改组件的情况下进行调整，或对不同业务场景提供给组件不同的业务配置。
组装阶段处于整个应用组装流程中的设计阶段，该阶段基于已有组件资产进行组装、开发企业应用或解决方案。本公开中提及的“扩展性”专指“组装过程扩展性”，它是指基于已有组件，能够快速搭建出新的组件业务能力。实现扩展性可以极大提升组装式应用对不同企业和复杂业务场景的适应性，也可以为用户提供更加丰富的组件集成和组件运维等功能。目前业界还没有实现组装过程扩展性的方法，也是组装式应用实施落地的一大难题。
图2是根据本公开实施例的组装过程扩展性的实现方法的流程图，如图2所示，
在本实施例中提供了一种组装过程扩展性的实现方法，该方法包括如下步骤：
步骤S201，选择可复用功能单元，基于可复用功能单元得到第一定义文件集；
在一种实施方式中，可复用功能单元包括以下至少之一：组件、插件。
在一种示例性的实施方式中，可以基于至少一组组件得到第一定义文件集，也可以基于至少一组插件得到第一定义文件集，也可以基于至少一组组件与至少一组插件的结合得到第一定义文件集。
步骤S202，对第一定义文件集进行解析，得到第一编排对象；
步骤S203，对第一编排对象进行编排处理，得到第二编排对象；
步骤S204，基于第二编排对象得到第二定义文件集；
步骤S205，基于第二定义文件集得到目标插件，以使目标插件为组件提供扩展性的能力。
其中，第一编排对象和第二编排对象的区别在于字段的取值不同。
通过上述步骤，当需要对套餐包或者版本包进行修改时，通过选择和组合可复用功能单元，利用可复用功能单元生成的插件对组件进行能力扩展，避免了对组件代码的修改的操作，提高了对套餐包或者版本包进行修改的效率。这样可以更快地进行应用程序开发，并解决传统开发中的一些挑战和问题。
在一种实施方式中，在选择可复用功能单元，基于可复用功能单元得到第一定义文件集之前，还包括：
将目标插件作为可复用功能单元的插件。
在一种示例性的实施方式中，将目标插件作为可复用功能单元的插件之后，重复步骤S201至步骤S205，以便于对目标插件进行插件-插件编排-插件的循环过程，从而便于利用目标插件生成新的插件，或者可以基于组件和目标插件生成新的插件，以此实现插件的扩展能力的复用。因此，在生成新插件的过程中，可复用功能单元的插件可以选择上述步骤S201至步骤S205生成的目标插件，也可以选择具有特定功能的已知的插件。
在一种实施方式中，基于第二定义文件集得到目标插件，以使目标插件为组件提供扩展性的能力之后，还包括：
基于目标插件和可复用功能单元的组件得到套餐包或者版本包。
在一种示例性的实施方式中，将目标插件和可复用功能单元的组件进行结合，有利于通过插件补充组件没有涉及的功能，无需修改组件的代码，从而便于根据目标插件和组件生成符合业绩要求的套餐包或者版本包。
在一种示例性的实施方式中，将目标插件和可复用功能单元的组件进行结合的方法如下：
引入插件：将插件文件引入到组件的代码中，可以通过import语句或者在HTML中使用scr ipt标签引入插件的脚本文件。
注册插件：根据插件的使用方式，可能需要在组件中注册插件。有些插件可能会自动注册，而有些需要手动执行注册函数。
使用插件功能：通过调用插件提供的API或者方法，将插件的功能附加到组件中。在适当的时机，调用插件提供的方法来实现相应的功能。
组成新的组件：当插件的功能成功附加到组件中后，就可以将组件视为具有该功能的新组件。可以通过组件的props或者state来控制插件功能的使用和配置。
封装为套餐包或版本包：将该组件进行封装，并提供相应的参数和配置选项。可以使用工具或者脚本来打包和发布组件的套餐或者版本。
在一种实施方式中，第一编排对象或者第二编排对象包括：API对象、配置对象、脚本对象；其中，
对于第一编排对象：API对象包括解析第一定义文件集得到的API定义信息，配置对象、脚本对象均为空值；
对于第二编排对象：API对象包括编排生成的API定义信息，配置对象包括编排设置的配置文件信息，脚本对象包括编排设置的脚本的文件地址、执行引擎、运行参数。
图3是根据本公开实施例的对于API插件进行插件-插件编排-插件的方法的流程图，如图3所示，
在一种实施方式中，该方法还包括：
S301，基于API对象得到API插件；
S302，基于API插件再次进行编排处理，以得到新的API插件。
在一种示例性的实施方式中，API类型插件编排的输入是组件的定义文件，经过插件编排过程和插件生成过程，输出的是API插件，API插件包含定义文件，可以再次设置为插件编排，即API插件编排可以进行“插件-插件编排-插件”的循环过程。
配置类型插件编排和脚本类型插件编排并不基于组件的定义文件，二者都是在编排过程中新增功能，其编排过程没有输入，输出的分别是配置类型插件和脚本类型插件，所以二者都不支持“插件-插件编排-插件”的循环过程。
在一种实施方式中，对第一定义文件集进行解析，得到第一编排对象，包括：
基于第一定义文件集对可复用功能单元进行依赖分析，以选择被依赖的组件或者插件。
图4是根据本公开实施例的基于第一定义文件得到第一编排对象的方法的流程图，如图4所示，
在一种实施方式中，对第一定义文件集进行解析，得到第一编排对象，包括：
S401，对第一定义文件的API字段、配置字段、脚本字段进行解析，得到解析结果；
S402，基于解析结果对第一编排对象为API对象或者配置对象或者脚本对象进行编排操作。
在一种示例性的实施方式中，在对于组件或者插件的第一定义文件来说，能根据API字段识别出API接口详细信息(exposed APIs)和依赖的API和依赖的组件/插件(dependent APIs)，这些信息是对组件/插件提供的API的详细描述。解析出的配置字段、脚本字段的解析结果是空值，需要人工进行编写。
图5是根据本公开实施例的基于第一编排对象得到第二编排对象的方法的流程图，如图5所示，
在一种实施方式中，对第一编排对象进行编排处理，得到第二编排对象，包括：
S501，在第一编排对象为API对象的情况下，响应于API参数的调用操作，得到第二编排对象；其中，API参数包括：API协议、请求方法、请求路径、请求参数和响应参数；
S502，在第一编排对象为配置对象的情况下，响应于配置参数、依赖的可复用功能单元的编辑操作，得到第二编排对象；
S503，在第一编排对象为脚本对象的情况下，响应于脚本参数、脚本文件名的编辑操作，得到第二编排对象。
在一种示例性的实施方式中，对第一编排对象进行编排处理，得到第二编排对象的操作，可以理解为对第一编排对象的不同组件/插件的API字段根据业务需求进行自由组合，对配置对象的配置字段或者脚本对象的脚本字段进行编写，以形成新的配置内容和脚本内容。
在一种实施方式中，基于第二定义文件集得到目标插件，包括：
在第一编排对象为API对象或者配置对象的情况下，基于第二定义文件集得到目标插件。
在一种实施方式中，基于第二定义文件集得到目标插件，包括：
在第一编排对象为脚本对象的情况下，基于第二定义文件集和脚本参数得到目标插件。
以下结合示例对上述方法进行解释说明：
总体来说，本公开的方法使用到三个过程：组装过程、插件编排过程、插件生成过程。
组装过程，是组件组合的过程。组装过程中，用户根据业务需求选择组件，组装工具对组件进行依赖分析，并自动选择被依赖的组件。
组件和插件都要提供统一规范的定义文件，定义文件具有一定固定格式，是组件或插件的完整信息描述，内容包括基础信息，组件/插件依赖关系，拓扑信息，资源信息，业务配置和API定义，本公开中主要关注定义文件中的API定义部分。
API定义完整描述一个组件/插件的API信息，包括对外提供的API详情、依赖的API、依赖的组件。
插件编排过程，由编排器导入定义文件，生成编排对象，编排对象是组件或插件在编排器中的可视化表现形式。用户在编排器中使用界面组合编排对象完成编排，插件编排过程生成编排对象，生成的编排对象包括API对象、配置对象、脚本对象。API对象包含编排生成的API定义信息，配置对象包含编排设置的配置文件信息，脚本对象描述编排脚本的文件地址、执行引擎和运行参数。
插件发布过程。根据插件编排输出，构造定义文件，最终将定义文件和插件编排输出发布到组装工具，成为新的插件。
本公开描述的方法是以定义文件作为资源，以插件编排过程构建扩展能力，最终将扩展能力发布为插件供后续组装过程使用，实现应用组装过程扩展性的方法。
图6是根据本公开实施例的组装过程扩展性的实现方法的框架示意图，如图6所示，
本公开描述的构建组装过程扩展能力的完整步骤见下图，包含以下5个步骤：
步骤1：用户选择组件，生成定义文件。
图7是根据本公开实施例的组装过程的框架示意图，如图7所示，
用户在组装工具中根据实际需求选择组件，每个组件需要提供定义文件，用户选择完组件后，组装过程会输出这些定义文件集合(即：第一定义文件集)。
定义文件是组件和插件的描述规范，具有固定格式，是组件或插件的完整信息描述，也是组装工具识别组件和插件的基础，定义文件内容包括基础信息，组件/插件依赖关系(dependent)，拓扑信息(topo)，资源信息(resource)，脚本信息(script)，业务配置(config)和API定义(api)。
API定义包括组件提供的API接口详细信息(exposed APIs)，依赖的API和依赖的组件(dependent APIs)，是对组件提供的API的详细描述。其中，组件提供的API可以是多种应用层协议，例如rest协议，web service协议和rpc协议等。method和url字段描述一个接口的http层方法和地址，protocol描述接口的应用层协议类型，specification是协议文件地址，该文件是一组接口的完整定义。对于rest协议接口，specification是swagger文件地址；对于web service协议接口，specification是wsdl文件地址；对于rpc协议接口，specification是proto文件地址。
dependent APIs是组件依赖的组件和接口，其中，name和kind描述依赖的组件或插件，kind类型表明该对象是组件(component)或插件(plugin)。apiName是依赖的API名称。dependent APIs下的method、url、specification和exposed APIs下的同名字段含义类似，用来描述一个API。
步骤2至3：解析组件定义，生成编排对象；用户编排插件，生成编排对象。
该步骤主要由插件编排器负责，插件编排器是插件编排过程的具体实现。以步骤1输出的定义文件为数据源，解析定义文件特定字段，构造编排对象并将其展现在编排界面中，用户使用插件编排器界面进行功能编排，最终输出的是编排对象。
图8是根据本公开实施例的插件编排过程的框架示意图，如图8所示，
由定义文件解析生成的第一编排对象，和插件编排生成的第二编排对象都遵守编排对象的定义规范，二者是等价的。例如定义文件生成的第一编排对象是“API类型编排对象A”，则编排生成的第二编排对象是“API类型的编排对象B”，二者都有相同的定义格式，仅具体字段取值不同。
插件编排器可以编排三种对象：API、配置、脚本。
编排API适用于为组件增加扩展功能的场景，例如，已有组件中单个API无法满足需求，但组合多个API可以满足需求时，通过在插件编排器中组合多个组件的API并添加业务逻辑，最终生成一个满足需求的API。另一种典型的应用场景是API转发，插件编排生成新的API作为组件API的代理，在新API转发请求到组件API的过程中，可以编排业务功能，比如添加鉴权，监控，请求过滤和统计等。以上两种场景中，都可以使用插件编排来为已有组件提供扩展能力，且不需要对组件侵入修改，不影响组件现有功能和API。
编排配置适用于为组件提供多业务场景配置的情况，当组件需要根据不同业务场景使用不同的配置时，通过插件编排可以提供出多套配置，即配置类型插件，用户组装不同业务场景版本包时可以选择这些配置插件，实现组装过程动态组装配置的目的。
脚本编排，脚本编排适用于为组件提供工具脚本、辅助功能或sidecar能力(将一种将应用功能从应用本身剥离出来作为单独进程的能力)的场景，例如，当版本包部署时需要设置组件公共的环境变量和文件权限，这些功能并不是某个组件应该提供的，和业务无关，比较适合使用单独的工具脚本实现。插件编排为这些场景提供了便捷的方法来编排脚本，无需侵入组件进行修改。
在用户编排前，插件编排器导入定义文件，解析定义文件，生成第一编排对象，第一编排对象会展示在编排器界面给用户使用。
API类型插件的解析过程：导入定义文件，解析其中API定义(api字段)，编排器根据exposed API字段获取swagger文件，下载并解析swagger文件获得API的详细信息，对每一个API构造编排对象，编排对象包含此API的定义和依赖。
具体解析字段是：遍历定义文件exposed APIs下的所有API，解析swagger获取API详细信息，生成组件对象中api字段，取定义文件的dependent APIs字段生成组件对象中的dependent字段。
编排对象中的dependent字段描述依赖关系，该字段对应定义文件中的dependent。例如API编排对象，dependent描述依赖的API和依赖API对应的组件。当编排完成时，会根据编排对象dependent字段生成定义文件中的dependent字段，即插件的依赖关系。当用户在组装过程中选择插件时，组装工具能够根据插件定义文件中的dependent字段自动勾选插件依赖的组件。
图9是根据本公开实施例的对于API类型插件的解析和编排过程的框架示意图，如图9所示，
API类型插件的编排过程：用户在编排器界面选择API，填写调用API的请求参数，并定义新的API，包括API协议，请求方法，请求路径，请求参数和响应参数。API类型插件编排的输出是API编排对象。
图10是根据本公开实施例的对于配置类型插件的编排过程的框架示意图，如图10所示，
配置类型插件的编排对象：配置对应的编排对象初始内容是空，没有固定的定义，具体数据由用户在编排器中填写。
配置类型插件的编排过程：用户在编排器中直接编写业务配置，并填写依赖的组件和插件信息，最终编排器生成配置编排对象。
其中，支持的配置文件格式包括json、xml、toml、yaml和csv等。
图11是根据本公开实施例的对于脚本类型插件的编排过程的框架示意图，如图11所示，
脚本类型插件的编排对象：脚本对应的编排对象初始内容为空，没有固定的定义，具体脚本由用户在编排器中填写。
脚本类型插件的编排过程：用户在编排器中直接编写脚本，并填写脚本的文件名，运行引擎，运行参数。最终编排器生成脚本编排对象。
脚本支持的文件格式和编程语言没有严格的限制，只需要组件能够提供对应格式的执行引擎即可，例如shell脚本、python脚本、java script脚本，lua脚本等。
步骤4：生成定义文件。
编排完成后，根据编排输出的编排对象，生成定义文件。
由编排对象生成定义文件的过程中，基础信息部分对于三种编排对象(API，配置和脚本)是相同的，由用户在编排时填写，包括插件名称(name)、描述(description)、版本(version)，类型字段(kind)自动生成为插件类型(plugin)，依赖的组件和插件(dependent)由编排对象的依赖字段(dependent)生成。
API编排对象，使用API定义字段(api)生成定义文件的API定义字段(api)。由于是API编排对象，不涉及配置类型和脚本类型的编排，所以配置字段(config)和脚本字段(script)为空缺值。
配置编排对象，使用配置字段(config)生成定义文件的配置字段(config)。由于是配置类型编排对象，不涉及API类型和脚本类型的编排，所以API定义字段(api)和脚本字段(script)为空缺值。
脚本编排对象，使用脚本字段(script)生成定义文件的脚本字段(script)。由于是脚本类型编排对象，不涉及API类型和配置类型的编排，所以API定义字段(api)和配置字段(config)为空缺值。
步骤5：发布插件。
将步骤4生成的插件定义文件和编排输出文件打包发布到组装工具，成为插件。
API类型和配置类型的插件编排出了定义文件，没有额外的编排输出文件。脚本类型插件编排输出文件除了定义文件还有用户编写的脚本。
上述3种类型编排都会生成定义文件，定义文件作为组件和插件共同的定义规范，包含组件的完整信息，编排输出基于定义文件才能发布为插件。
插件提供了定义文件，可以和组件一样用于组件组装和编排过程。重复步骤1至5，则可以构成“组件/插件-组装-编排-发布插件”的循环过程，每一次循环都基于已有组件和插件编排出了新的API，配置和脚本，为组装过程提供扩展能力，当已有组件/插件功能或配置不能满足需求时，可以通过上述过程来构建扩展能力。
图12是根据本公开实施例的扩展能力积累的框架示意图，如图12所示，
第一次循环过程，用户选择组件A和B，按照步骤1至5编排出插件X。第二次编排时，选择组件C和插件X，编排出插件Y。后续仍然可以基于组件A、B、C和插件X、Y进行满足用户需求的组装。
在一种示例性的实施方式中，在组装某公司用户管理系统时，发现旧版本客户端使用web service接口，新版本客户端使用的是rest接口，旧版服务端提供web service接口，新版服务端提供rest接口，现需要下线旧版服务端，但短时间内无法确保所有客户端都更新到新版，所以需要兼容层，即客户端使用web service接口发送请求到服务端rest接口，由兼容层来负责协议转换。可以通过在组装过程中使用本公开满足该要求。插件编排过程提供web service接口转发到rest接口的功能，以便旧版客户端能够继续使用，且旧版服务端可以下线。整个组装过程不需要修改组件代码。
图13是根据本公开实施例的客户端、脚本、服务端进行信息交互的框架示意图，如图13所示，
上述的组件服务端分为两个组件，每个服务提供一个接口：组件A提供GET/user/:id接口，查询用户基础信息。组件B提供GET/role/:id接口查询用户角色。
步骤1：用户选择组件，生成定义文件。
在组装工具中选择A，B两个组件，由组装过程合并组件定义。
组件A名称是user-manager(name)，类型(kind)是组件类型(component)，版本v1(version)，提供user-info接口(GET/user/:id)，依赖组件x(dependent)。
组件B名称是role-manager(name)，类型是组件类型(kind)，版本v1(version)，提供role-info接口(GET/user/:id)，依赖组件y(dependent)。
从两个定义文件中分别获得两个swagger文件：user-info-swagger.json和role-info-swagger.json。
swagger.json文件描述了接口名称，协议，输入参数结构和输出参数结构。
步骤2：解析组件定义，生成编排对象；步骤1完成后，将两个组件的定义文件导入到插件编排器，插件编排器读取定义文件生成编排对象，每一个API对应一个编排对象，展示在编排器界面上。
步骤3：用户编排，生成编排输出。
图14是根据本公开实施例的在web service协议和rest协议转换的过程中选择的API和生成的API的框架示意图，如图14所示，
用户在编排器中选择上述两个接口进行调用，并提供web service协议接口，以及web service协议和rest协议转换功能，提供新的web service接口定义。
编排完成后，编排器生成编排对象。
编排出的API提供web service协议，当收到web service请求时，会将请求转为rest请求，调用相应的接口后返回。
步骤4：生成定义文件。
插件发布过程根据步骤3输出的编排对象，构造定义文件。
定义文件基础信息由用户在编排时填写，包括插件名称、描述、版本，配置字段(config)和脚本字段(script)空缺，类型字段自动生成为插件类型(plugin)。依赖的组件和插件(dependent)由编排对象的依赖字段(dependent)生成，依赖的是user-manager和role-manager两个组件，由于这两个组件分别依赖x组件和y组件，所以web service-api插件也需要依赖组件x和y。定义文件中的API定义字段(api)由编排对象生成。
步骤5：发布插件。将步骤4生成的插件定义文件和编排输出文件打包发布到组装工具，成为插件。
后续组装过程可以使用组件A、组件B和此插件提供web service客户端到rest服务端的接口兼容功能，整个过程不需要修改组件A和B的代码。
总结：本实施示例演示了使用组装、编排和发布插件，在不修改原有组件代码的条件下，实现接口协议转换的扩展功能。
在另一种示例性的实施方式中，在组装某公司考核系统组件时，用户需要根据不同场景提供不同的错误码配置，错误码是和代码一起打包的，不容易修改，通过使用本公开的方法，在组装过程中编排出多份错误码配置满足需求。
考核系统主要依赖两个组件构成，分别是组件A和组件B。
步骤1：用户选择组件，生成定义文件。
由于配置编排并不需要基于组件定义文件做输入，所以配置编排不需要选择组件，配置类型的插件编排不需要步骤1。
步骤2：解析组件定义，生成编排对象。
配置编排不会基于组件定义文件，而是由编排器直接生成包含缺省值的编排对象，其中，配置类型的插件编排不需要步骤2。
步骤3：用户编排组件，生成编排输出。
用户在编排器中直接编辑业务配置，将业务配置数据写入配置文件中，文件名为business-scene-a.yaml。配置的数据格式只需要满足是key-value键值对即可，编排器对配置的格式没有额外要求。配置生成插件后，只需要使用配置的组件能够识别即可。
步骤4：生成定义文件。
插件发布过程根据步骤3输出的编排对象，构造定义文件。
定义文件基础信息由用户在编排时填写，包括插件名称、描述、版本，API字段(api)和脚本字段(script)空缺，类型字段自动生成为插件类型(plugin)。依赖的组件和插件(dependent)由编排对象的依赖字段(dependent)生成，依赖是由用户在编排时填写的，依赖的是组件user-score-manager。定义文件中配置字段(config)由编排对象config字段生成。
步骤5：发布插件。
将步骤4生成的插件定义文件和编排输出文件打包发布到组装工具，成为插件。插件提供了场景A(sceneA)下的配置。同理可以基于组件A和组件B编排其他场景下的配置生成插件。后续组装过程通过选择组件A和组件B，结合不同的配置插件，实现考核系统在组装过程动态选择配置的功能，对已有组件代码没有侵入。
总结：本实施示例演示了使用组装、编排和发布插件，在不修改原有组件代码的条件下，实现配置插件化功能，为已有组件提供动态切换配置的扩展能力。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件添加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。
在本实施例中还提供了一种组装过程扩展性的实现装置，该装置设置为实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图15是根据本公开实施例的组装过程扩展性的实现装置的结构示意图，如图15所示，该装置包括：
组装模块151，设置为选择可复用功能单元，基于可复用功能单元得到第一定义文件集；
插件编排模块152，设置为对第一定义文件集进行解析，得到第一编排对象；以及，
对第一编排对象进行编排处理，得到第二编排对象；
插件生成模块153，设置为基于第二编排对象得到第二定义文件集；以及，
设置为基于第二定义文件集得到目标插件，以使目标插件为组件提供扩展性的能力。
其中，第一编排对象和第二编排对象的区别在于字段的取值不同。
进一步地，可复用功能单元包括以下至少之一：组件、插件。
进一步地，该装置还设置为：在选择可复用功能单元，基于可复用功能单元得到第一定义文件集之前，还包括：
将目标插件作为可复用功能单元的插件。
进一步地，该装置还设置为：基于第二定义文件集得到目标插件，以使目标插件为组件提供扩展性的能力之后，还包括：
基于目标插件和可复用功能单元的组件得到套餐包或者版本包。
进一步地，该装置还设置为：第一编排对象或者第二编排对象包括：API对象、配置对象、脚本对象；其中，
对于第一编排对象：API对象包括解析第一定义文件集得到的API定义信息，配置对象、脚本对象均为空值；
对于第二编排对象：API对象包括编排生成的API定义信息，配置对象包括编排设置的配置文件信息，脚本对象包括编排设置的脚本的文件地址、执行引擎、运行参数。
进一步地，该装置还设置为：基于API对象得到API插件；
基于API插件再次进行编排处理，以得到新的API插件。
进一步地，该装置还设置为：对第一定义文件集进行解析，得到第一编排对象，包括：
基于第一定义文件集对可复用功能单元进行依赖分析，以选择被依赖的组件或者插件。
进一步地，该装置还设置为：对第一定义文件集进行解析，得到第一编排对象，包括：
对第一定义文件的API字段、配置字段、脚本字段进行解析，得到解析结果；
基于解析结果对第一编排对象为API对象或者配置对象或者脚本对象进行编排操作。
进一步地，该装置还设置为：对第一编排对象进行编排处理，得到第二编排对象，包括：
在第一编排对象为API对象的情况下，响应于API参数的调用操作，得到第二编排对象；其中，API参数包括：API协议、请求方法、请求路径、请求参数和响应参数；
在第一编排对象为配置对象的情况下，响应于配置参数、依赖的可复用功能单元的编辑操作，得到第二编排对象；
在第一编排对象为脚本对象的情况下，响应于脚本参数、脚本文件名的编辑操作，得到第二编排对象。
进一步地，该装置还设置为：基于第二定义文件集得到目标插件，包括：
在第一编排对象为API对象或者配置对象的情况下，基于第二定义文件集得到目标插件。
进一步地，该装置还设置为：基于第二定义文件集得到目标插件，包括：
在第一编排对象为脚本对象的情况下，基于第二定义文件集和脚本参数得到目标插件。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
本公开的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本公开的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本公开的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。
以上所述仅为本公开的优选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (13)

  1. 一种组装过程扩展性的实现方法，包括：
    选择可复用功能单元，基于所述可复用功能单元得到第一定义文件集；
    对所述第一定义文件集进行解析，得到第一编排对象；
    对所述第一编排对象进行编排处理，得到第二编排对象；
    基于所述第二编排对象得到第二定义文件集；
    基于所述第二定义文件集得到目标插件，以使所述目标插件为组件提供扩展性的能力。
  2. 根据权利要求1所述的方法，其中，所述可复用功能单元包括以下至少之一：组件、插件。
  3. 根据权利要求2所述的方法，其中，在选择可复用功能单元，基于所述可复用功能单元得到第一定义文件集之前，还包括：
    将所述目标插件作为所述可复用功能单元的插件。
  4. 根据权利要求2所述的方法，其中，基于所述第二定义文件集得到目标插件，以使所述目标插件为组件提供扩展性的能力之后，还包括：
    基于所述目标插件和所述可复用功能单元的组件得到套餐包或者版本包。
  5. 根据权利要求1所述的方法，其中，所述第一编排对象或者所述第二编排对象包括：API对象、配置对象、脚本对象；其中，
    对于所述第一编排对象：所述API对象包括解析第一定义文件集得到的API定义信息，配置对象、脚本对象均为空值；
    对于所述第二编排对象：所述API对象包括编排生成的API定义信息，所述配置对象包括编排设置的配置文件信息，所述脚本对象包括编排设置的脚本的文件地址、执行引擎、运行参数。
  6. 根据权利要求5所述的方法，其中，还包括：
    基于所述API对象得到API插件；
    基于所述API插件再次进行编排处理，以得到新的API插件。
  7. 根据权利要求1所述的方法，其中，对所述第一定义文件集进行解析，得到第一编排对象，包括：
    基于所述第一定义文件集对所述可复用功能单元进行依赖分析，以选择被依赖的组件或者插件。
  8. 根据权利要求1所述的方法，其中，对所述第一定义文件集进行解析，得到第一编排对象，包括：
    对所述第一定义文件集的API字段、配置字段、脚本字段进行解析，得到解析结果；
    基于所述解析结果对所述第一编排对象为API对象或者配置对象或者脚本对象进行编排操作。
  9. 根据权利要求8所述的方法，其中，基于所述解析结果对所述第一编排对象为API对象或者配置对象或者脚本对象进行编排操作，包括：
    在所述第一编排对象为API对象的情况下，响应于API参数的调用操作，得到所述第二编排对象；其中，所述API参数包括：API协议、请求方法、请求路径、请求参数和响应参数；
    在所述第一编排对象为配置对象的情况下，响应于配置参数、依赖的可复用功能单元的编辑操作，得到所述第二编排对象；
    在所述第一编排对象为脚本对象的情况下，响应于脚本参数、脚本文件名的编辑操作，得到所述第二编排对象。
  10. 根据权利要求9所述的方法，其中，基于所述第二定义文件集得到目标插件，包括：
    在所述第一编排对象为API对象或者配置对象的情况下，基于所述第二定义文件集得到目标插件。
  11. 根据权利要求9所述的方法，其中，基于所述第二定义文件集得到目标插件，包括：
    在所述第一编排对象为脚本对象的情况下，基于所述第二定义文件集和所述脚本参数得到目标插件。
  12. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被处理器执行时实现所述权利要求1至11任一项中所述的方法的步骤。
  13. 一种电子装置，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述权利要求1至11任一项中所述的方法的步骤。
PCT/CN2024/143403 2024-01-05 2024-12-27 组装过程扩展性的实现方法及装置 Pending WO2025145992A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410028800.8A CN120276761A (zh) 2024-01-05 2024-01-05 组装过程扩展性的实现方法及装置
CN202410028800.8 2024-01-05

Publications (1)

Publication Number Publication Date
WO2025145992A1 true WO2025145992A1 (zh) 2025-07-10

Family

ID=96244242

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/143403 Pending WO2025145992A1 (zh) 2024-01-05 2024-12-27 组装过程扩展性的实现方法及装置

Country Status (2)

Country Link
CN (1) CN120276761A (zh)
WO (1) WO2025145992A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103279358A (zh) * 2013-06-08 2013-09-04 北京首钢自动化信息技术有限公司 一种面向行业应用的解释型业务组件动态构建方法
US20190265986A1 (en) * 2018-02-27 2019-08-29 Avid Technology, Inc. Plug-ins as microservices
CN112286513A (zh) * 2019-07-23 2021-01-29 北京京东尚科信息技术有限公司 基于组件元数据的可视化设计方法和装置
CN113094042A (zh) * 2021-04-29 2021-07-09 国电南瑞科技股份有限公司 一种基于浏览器的电力自动化系统自定义组件的实现与解析方法
CN114528012A (zh) * 2020-11-03 2022-05-24 北京迈格威科技有限公司 编排文件处理方法、装置、设备及介质
CN117112109A (zh) * 2023-08-29 2023-11-24 零束科技有限公司 基于可视化界面的微服务编排、微服务调用方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103279358A (zh) * 2013-06-08 2013-09-04 北京首钢自动化信息技术有限公司 一种面向行业应用的解释型业务组件动态构建方法
US20190265986A1 (en) * 2018-02-27 2019-08-29 Avid Technology, Inc. Plug-ins as microservices
CN112286513A (zh) * 2019-07-23 2021-01-29 北京京东尚科信息技术有限公司 基于组件元数据的可视化设计方法和装置
CN114528012A (zh) * 2020-11-03 2022-05-24 北京迈格威科技有限公司 编排文件处理方法、装置、设备及介质
CN113094042A (zh) * 2021-04-29 2021-07-09 国电南瑞科技股份有限公司 一种基于浏览器的电力自动化系统自定义组件的实现与解析方法
CN117112109A (zh) * 2023-08-29 2023-11-24 零束科技有限公司 基于可视化界面的微服务编排、微服务调用方法及装置

Also Published As

Publication number Publication date
CN120276761A (zh) 2025-07-08

Similar Documents

Publication Publication Date Title
US11048499B2 (en) Infrastructure validation architecture for serverless execution frameworks
CN111338637B (zh) 一种代码生成方法及装置
CN112235357B (zh) 跨平台应用开发系统
US20070005734A1 (en) Generically extensible client application
US20090132220A1 (en) Method For Creating A Telecommunications Application
US8683428B2 (en) Automated generation of client/driver communication interfaces
WO2017054531A1 (zh) 一种基于yang模型的编译方法、及对应的接口、组件和系统
CN109002362A (zh) 一种服务方法、装置、系统以及电子设备
US20090129575A1 (en) System And Computer Program Product For Creating A Telecommunications Application
KR20040051738A (ko) 이기종 네트워크 장비의 구성 관리를 위한 엑스엠엘 기반망 관리 시스템 및 방법
US7752598B2 (en) Generating executable objects implementing methods for an information model
JP2010123127A (ja) ウェブページを作成するために使用されるコンポーネントベースのジャバウェブアプリケーション開発フレームワーク
US9519628B2 (en) Method for generating simple object access protocol messages and process engine
CN113179269B (zh) 基于物联网的协议数据解析方法、系统、介质
US11372632B2 (en) Systems and methods for creating and deploying applications and services
CN112698817B (zh) 基于微服务架构的消息接入方法、装置、系统及存储介质
CN113726869A (zh) 通信方法、网关以及电子设备
Challita et al. Model-based cloud resource management with TOSCA and OCCI
CN115951884A (zh) 一种信息处理方法、装置及微前端架构系统
CN115982257A (zh) 接口创建方法以及相关设备
CN114816357A (zh) 一种服务于流程银行的服务编排系统
WO2025145992A1 (zh) 组装过程扩展性的实现方法及装置
CN115454421A (zh) 低代码化接口的开发方法及装置
CN105320499A (zh) 一种应用程序的适配方法和相关装置
US9977700B2 (en) System and method for providing an application programming interface for deploying a service bus artifact from a local development environment to a cloud environment

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: 24915206

Country of ref document: EP

Kind code of ref document: A1