Method and apparatus for realizing extensibility for composition process

Abstract

The embodiments of the present disclosure provide a method and apparatus for realizing extensibility for an composition process. The method comprises: selecting a reusable function unit, and, on the basis of the reusable function unit, obtaining a first definition file set; analyzing the first definition file set to obtain a first orchestration object; performing orchestration processing on the first orchestration object to obtain a second orchestration object; on the basis of the second orchestration object, obtaining a second definition file set; and, on the basis of the second definition file set, obtaining a target plug-in, such that the target plug-in provides extensibility for components.

Description

Method and device for realizing assembly process scalability

[0001] Cross-references to related publications

[0002] The present disclosure is based on Chinese Patent Publication No. 2024100288008, filed on January 5, 2024, entitled “Method and Device for Implementing Scalability of Assembly Process”, and claims the priority of the patent disclosure, and all the contents disclosed therein are incorporated into the present disclosure by reference. Technical Field

[0003] The embodiments of the present disclosure relate to the technical field of enterprise application development, and in particular, to a method and apparatus for implementing assembly process scalability. Background Art

[0004] Traditional application development faces numerous challenges: 1. Insufficient development capabilities; 2. The tendency to choose the wrong technology; and 3. Insufficient delivery speed. To address these issues, a common technical solution is to use "assembled applications" to save time and increase delivery speed.

[0005] In related technologies, the basic object of the "assembly application" technology is components, and package packages or version packages are built by selecting components with fixed functions.

[0006] However, when a fixed-function component is missing functionality, it is often necessary to modify the component code, recompile and package it to output a new component version, and then use the new component version to build a package or version package. This process is relatively complicated and has low flexibility. Summary of the Invention

[0007] The embodiments of the present disclosure provide a method and apparatus for implementing scalability of an assembly process.

[0008] According to one embodiment of the present disclosure, a method for implementing extensibility of an assembly process is provided, comprising: selecting a reusable functional unit, and obtaining a first definition file set based on the reusable functional unit; parsing the first definition file set to obtain a first orchestration object; performing orchestration processing on the first orchestration object to obtain a second orchestration object; obtaining a second definition file set based on the second orchestration object; and obtaining a target plug-in based on the second definition file set, so that the target plug-in provides extensibility capabilities for the component.

[0009] According to another embodiment of the present disclosure, a device for implementing extensibility of an assembly process is provided, including: 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, to orchestrate 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.

[0010] According to another embodiment of the present disclosure, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when running.

[0011] According to another embodiment of the present disclosure, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG1 is a flow chart of an application assembly according to the related art;

[0013] FIG2 is a flow chart of a method for implementing assembly process extensibility according to an embodiment of the present disclosure;

[0014] FIG3 is a flowchart 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;

[0015] 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;

[0016] 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;

[0017] FIG6 is a first schematic diagram of a framework of a method for implementing assembly process scalability according to an embodiment of the present disclosure;

[0018] FIG7 is a schematic diagram of a framework of an assembly process according to an embodiment of the present disclosure;

[0019] FIG8 is a schematic diagram of a plug-in arrangement process according to an embodiment of the present disclosure;

[0020] 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;

[0021] FIG10 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;

[0022] FIG11 is a schematic diagram of a framework of an orchestration process for a script-type plug-in according to an embodiment of the present disclosure;

[0023] FIG12 is a schematic diagram of a framework for expanding capability accumulation according to an embodiment of the present disclosure;

[0024] 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;

[0025] 14 is a schematic diagram of a framework of an API selected and a generated API during conversion between a web service protocol and a rest protocol according to an embodiment of the present disclosure;

[0026] FIG15 is a schematic structural diagram of a device for implementing scalability of an assembly process according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0027] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings and in conjunction with embodiments.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0029] Traditional application development faces numerous challenges: 1. insufficient development capabilities; 2. incorrect technology choices; and 3. slow delivery. To address these challenges, a common technical solution is code reuse, reusing existing, mature code. This saves time and speeds up delivery.

[0030] Gartner's "assembled applications" address these issues by introducing a new architecture. It aims to leverage modularity to enable greater agility and efficient code reuse among technical and business teams. By leveraging an assembly-based mindset, assembly-based platform, and assembly-based architecture, enterprise-level applications can be developed, promoting the deep integration of digital technologies and business applications. In complex and volatile environments, "assembled applications" can enhance enterprises' adaptability and innovation capabilities. By establishing specifications for component integration and decoupling, they provide a standard basis for component integration development and promote component standardization and certification governance.

[0031] The core of "assembled applications" is called "Packaged Business Capability (PBC)." PBC is a software-defined, minimal business function. Gartner's official definition of PBC states: "A PBC is a well-defined, functionally identifiable software component." A PBC is a bounded collection whose components are a data schema (a collection of database objects), a set of services, a set of APIs (Application Programming Interfaces), and an event channel.

[0032] FIG1 is a flowchart of an application assembly according to related technology. As shown in FIG1 ,

[0033] PBC is used for application assembly. The complete process of application assembly is divided into the following four stages:

[0034] In the production phase, professional developers (Pro-Code) use local programming language tools to develop various capability components and build and deploy PBC components or applications.

[0035] During the operation phase, 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.

[0036] During the assembly phase, non-professional developers (Business-IT) use low-code or full-code tools to assemble and develop business applications or solutions to meet business innovation needs.

[0037] In the usage phase, users solve business problems and achieve business goals through business applications or solutions.

[0038] Related assembly techniques are primarily component-based, building packages or versioned packages by selecting components. When existing components lack functionality, code modifications and recompilation and repackaging are often necessary, resulting in a complex and inflexible process. There is also no flexible mechanism for adjusting component configurations without modifying the components, or for providing components with different business configurations for different scenarios.

[0039] 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 "extensibility" mentioned in this disclosure refers specifically to the "assembly process extensibility", which means that new component business capabilities can be quickly built based on existing components. Achieving extensibility can greatly improve 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 assembly process extensibility, which is also a major problem in the implementation of assembled applications.

[0040] FIG2 is a flow chart of a method for implementing assembly process extensibility according to an embodiment of the present disclosure. As shown in FIG2 ,

[0041] In this embodiment, a method for implementing assembly process scalability is provided, which includes the following steps:

[0042] Step S201: selecting a reusable functional unit and obtaining a first definition file set based on the reusable functional unit;

[0043] In one embodiment, the reusable functional unit includes at least one of the following: a component, a plug-in.

[0044] In an exemplary embodiment, the first definition file set can be obtained based on at least one set of components, or based on at least one set of plug-ins, or based on a combination of at least one set of components and at least one set of plug-ins.

[0045] Step S202: parsing the first definition file set to obtain a first arrangement object;

[0046] Step S203, performing arrangement processing on the first arrangement object to obtain a second arrangement object;

[0047] Step S204, obtaining a second definition file set based on the second arrangement object;

[0048] 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.

[0049] The difference between the first arrangement object and the second arrangement object lies in the different values ​​of the fields.

[0050] By following these steps, when a package or version package needs to be modified, you can select and combine reusable functional units and use the plug-ins generated by these reusable functional units to expand the component's capabilities. This avoids modifying component code and improves the efficiency of package or version package modifications. This allows for faster application development and addresses some of the challenges and issues in traditional development.

[0051] In one embodiment, before selecting the reusable functional unit and obtaining the first definition file set based on the reusable functional unit, the method further includes:

[0052] Target plugins are plugins that act as reusable units of functionality.

[0053] In one exemplary embodiment, after the target plug-in is used as a plug-in for the reusable functional unit, steps S201 through S205 are repeated to perform a plug-in-plug-in orchestration-plug-in cycle on the target plug-in. This facilitates the generation of new plug-ins using the target plug-in, or the generation of new plug-ins based on the component and the target plug-in, thereby reusing the plug-in's extensible capabilities. Therefore, when generating a new plug-in, the plug-in for the reusable functional unit can select the target plug-in generated in steps S201 through S205, or a known plug-in with specific functionality.

[0054] In one embodiment, after obtaining the target plug-in based on the second definition file set so that the target plug-in provides extensibility for the component, the method further includes:

[0055] Get package or version package based on target plug-ins and components of reusable functional units.

[0056] In an exemplary embodiment, 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.

[0057] In an exemplary embodiment, a method for combining a target plug-in with a component of a reusable functional unit is as follows:

[0058] 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 introduce the plug-in script file.

[0059] Registering plugins: 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.

[0060] Use plugin functionality: Attach plugin functionality to a component 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 functionality.

[0061] Composing a new component: Once the functionality of a plugin has been successfully attached to a component, the component can be treated as a new component with that functionality. The use and configuration of the plugin functionality can be controlled through the component's props or state.

[0062] Package as a package or version: 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.

[0063] In one embodiment, the first orchestration object or the second orchestration object includes: an API object, a configuration object, and a script object; wherein,

[0064] For the first orchestration object: the API object includes the API definition information obtained by parsing the first definition file set, and the configuration object and the script object are both empty;

[0065] For the second orchestration object: the API object includes the API definition information generated by the orchestration, the configuration object includes the configuration file information set by the orchestration, and the script object includes the file address, execution engine, and running parameters of the script set by the orchestration.

[0066] 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 ,

[0067] In one embodiment, the method further comprises:

[0068] S301, obtaining an API plug-in based on the API object;

[0069] S302: Performing an arrangement process again based on the API plug-in to obtain a new API plug-in.

[0070] In an exemplary embodiment, the input of API-type plug-in orchestration is the component definition file. After the plug-in orchestration process and the plug-in generation process, the output is the API plug-in. The API plug-in contains the definition file and can be set as plug-in orchestration again. That is, the API plug-in orchestration can perform a "plug-in-plug-in orchestration-plug-in" cycle.

[0071] Configuration-type plug-in orchestration and script-type plug-in orchestration are not based on component definition files. Both add new functions during the orchestration process. The orchestration process has no input, and the output is configuration-type plug-ins and script-type plug-ins respectively. Therefore, neither supports the "plug-in-plug-in orchestration-plug-in" cycle process.

[0072] In one embodiment, parsing the first definition file set to obtain the first arrangement object includes:

[0073] A dependency analysis is performed on the reusable functional unit based on the first definition file set to select dependent components or plug-ins.

[0074] FIG4 is a flow chart of a method for obtaining a first arrangement object based on a first definition file according to an embodiment of the present disclosure. As shown in FIG4 ,

[0075] In one embodiment, parsing the first definition file set to obtain the first arrangement object includes:

[0076] S401, parsing the API field, configuration field, and script field of the first definition file to obtain a parsing result;

[0077] S402: Perform an orchestration operation on the first orchestration object, which is an API object, a configuration object, or a script object, based on the parsing result.

[0078] In an exemplary embodiment, the first definition file for a component or plug-in can identify API interface details (exposed APIs) and dependent APIs and components / plug-ins (dependent APIs) based on the API field. This information provides a detailed description of the API provided by the component / plug-in. The parsed configuration and script fields are empty and require manual editing.

[0079] FIG5 is a flow chart of a method for obtaining a second arrangement object based on a first arrangement object according to an embodiment of the present disclosure. As shown in FIG5 ,

[0080] In one embodiment, performing orchestration processing on the first orchestration object to obtain the second orchestration object includes:

[0081] S501, when the first orchestration object is an API object, in response to a call operation of API parameters, obtain a second orchestration object; wherein the API parameters include: API protocol, request method, request path, request parameters, and response parameters;

[0082] S502, when the first orchestration object is a configuration object, in response to an editing operation of configuration parameters and dependent reusable functional units, obtaining a second orchestration object;

[0083] S503: When the first arrangement object is a script object, a second arrangement object is obtained in response to the editing operation of the script parameters and the script file name.

[0084] In an exemplary embodiment, orchestrating a first orchestration object to obtain an operation of a second orchestration object can be understood as freely combining API fields of different components / plug-ins of the first orchestration object according to business needs, and writing configuration fields of a configuration object or script fields of a script object to form new configuration content and script content.

[0085] In one embodiment, obtaining a target plug-in based on the second definition file set includes:

[0086] When the first orchestration object is an API object or a configuration object, a target plug-in is obtained based on the second definition file set.

[0087] In one embodiment, obtaining a target plug-in based on the second definition file set includes:

[0088] In the case where the first orchestration object is a script object, a target plug-in is obtained based on the second definition file set and the script parameters.

[0089] The following example explains the above method:

[0090] Generally speaking, the method disclosed herein uses three processes: an assembly process, a plug-in arrangement process, and a plug-in generation process.

[0091] The assembly process is the process of combining components. During the assembly process, users select components based on business requirements. The assembly tool analyzes component dependencies and automatically selects dependent components.

[0092] Both components and plug-ins must provide a unified and standardized definition file. 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.

[0093] The API definition fully describes the API information of a component / plug-in, including the details of the API provided to the outside world, the dependent APIs, and the dependent components.

[0094] During the plugin orchestration process, the orchestrator imports the definition file and generates an orchestration object. This object is the visual representation of the component or plugin within the orchestrator. Users complete the orchestration by combining orchestration objects within the orchestrator's interface. The plugin orchestration process generates orchestration objects, which include 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 for the orchestration settings, and the script object describes the file location, execution engine, and runtime parameters of the orchestration script.

[0095] The plugin publishing process: Based on the plugin orchestration output, a definition file is constructed. Finally, the definition file and the plugin orchestration output are published to the assembly tool to become a new plugin.

[0096] The method described in the present disclosure uses definition files as resources, builds extension capabilities through a plug-in orchestration process, and ultimately publishes the extension capabilities as plug-ins for use in subsequent assembly processes, thereby achieving extensibility in the application assembly process.

[0097] FIG6 is a schematic diagram of a framework of a method for implementing assembly process scalability according to an embodiment of the present disclosure. As shown in FIG6 ,

[0098] The complete steps for building assembly process extension capabilities described in this disclosure are shown in the figure below and include the following five steps:

[0099] Step 1: The user selects a component and generates a definition file.

[0100] FIG7 is a schematic diagram of a framework of an assembly process according to an embodiment of the present disclosure. As shown in FIG7 ,

[0101] 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).

[0102] The definition file is a description specification of components and plug-ins. It has a fixed format and is a complete information description of the component or plug-in. 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).

[0103] The API definition includes the details of the API interfaces provided by the component (exposed APIs), the dependent APIs and dependent components (dependent APIs), and 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 the 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, and the specification is the protocol file address, which is a complete definition of a set of interfaces. For the REST protocol interface, the specification is the swagger file address; for the web service protocol interface, the specification is the wsdl file address; for the RPC protocol interface, the specification is the proto file address.

[0104] Dependent APIs are the components and interfaces that a component depends on. Name and kind describe the dependent component or plugin, with the kind type indicating whether the object is a component or plugin. apiName is the name of the dependent API. The method, url, and specification fields under dependent APIs have similar meanings to the fields of the same name under exposed APIs and are used to describe an API.

[0105] Steps 2 to 3: Parse component definitions and generate orchestration objects; use the user orchestration plug-in to generate orchestration objects.

[0106] This step is primarily the responsibility of the plug-in orchestrator, which implements the plug-in orchestration process. Using the definition file output in Step 1 as the data source, the plug-in orchestrator parses specific fields in the definition file, constructs an orchestration object, and displays it in the orchestration interface. Users use the plug-in orchestrator interface to orchestrate functions, ultimately outputting the orchestration object.

[0107] FIG8 is a schematic diagram of a plug-in arrangement process according to an embodiment of the present disclosure. As shown in FIG8 ,

[0108] The first orchestration object generated by parsing the definition file and the second orchestration object generated by the plugin both adhere to the orchestration object definition specification and 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 plugin is "API type orchestration object B." Both have the same definition format, differing only in the specific field values.

[0109] The plugin orchestrator can orchestrate three types of objects: API, configuration, and scripts.

[0110] API orchestration is suitable for adding extended functionality to components. For example, when a single API in an existing component cannot meet the requirements, but combining multiple APIs can, the plugin orchestrator can combine the APIs of multiple components and add business logic to ultimately generate a single API that meets the requirements. Another typical application scenario is API forwarding, where plugin orchestration generates a new API that acts as a proxy for the component API. During the process of forwarding requests from the new API to the component API, business functions can be orchestrated, such as adding authentication, monitoring, request filtering, and statistics. In both scenarios, plugin orchestration can be used to provide extended capabilities for existing components without intrusive modifications to the components and without affecting the existing functionality and APIs of the components.

[0111] Orchestration configuration is suitable for providing multi-business scenario configurations for components. When components need to use different configurations according to different business scenarios, plug-in orchestration can provide multiple sets of configurations, namely configuration type plug-ins. Users can select these configuration plug-ins when assembling different business scenario version packages, thereby achieving the purpose of dynamic assembly configuration during the assembly process.

[0112] Script orchestration is suitable for scenarios where you need to provide component scripts, auxiliary functions, or sidecar capabilities (a capability that separates application functionality from the application itself and runs it as a separate process). For example, when deploying a version package, you need to set common environment variables and file permissions for components. These functions are not provided by a specific component and are not related to the business, so they are more suitable for implementation using separate tool scripts. Plugin orchestration provides a convenient method for scripting in these scenarios without intruding on the component to modify it.

[0113] Before the user orchestrates, the plug-in orchestrator imports the definition file, parses the definition file, and generates the first orchestration object. The first orchestration object is displayed on the orchestrator interface for the user to use.

[0114] 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 based on the exposed API field, downloads and parses the swagger file to obtain detailed API information, and constructs an orchestration object for each API. The orchestration object contains the definition and dependencies of this API.

[0115] 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.

[0116] The dependent field in an orchestration object describes dependencies and corresponds to the dependent field in the definition file. For example, in an API orchestration object, the dependent field describes the dependent API and the corresponding component. When orchestration is complete, the dependent field in the definition file is generated based on the dependent field in the orchestration object, representing the plugin's dependencies. When a user selects a plugin during assembly, the assembly tool automatically selects the components that the plugin depends on based on the dependent field in the plugin definition file.

[0117] FIG9 is a schematic diagram of a framework of the parsing and orchestration process for an API type plug-in according to an embodiment of the present disclosure. As shown in FIG9 ,

[0118] The orchestration process for an API plug-in: The user selects an API on the orchestrator interface, enters the request parameters for calling the API, and defines a new API, including the API protocol, request method, request path, request parameters, and response parameters. The output of the API plug-in orchestration is an API orchestration object.

[0119] FIG10 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 FIG10 ,

[0120] Configuration type plug-in orchestration object: The initial content of the configuration corresponding to the orchestration object is empty and has no fixed definition. The specific data is filled in by the user in the orchestrator.

[0121] Configuration plug-in orchestration process: Users directly write business configurations in the orchestrator and fill in dependent component and plug-in information. Finally, the orchestrator generates a configuration orchestration object.

[0122] The supported configuration file formats include json, xml, toml, yaml, and csv.

[0123] FIG11 is a schematic diagram of a framework of an orchestration process for a script type plug-in according to an embodiment of the present disclosure. As shown in FIG11 ,

[0124] Orchestration object of script type plug-in: The initial content of the orchestration object corresponding to the script is empty and has no fixed definition. The specific script is filled in by the user in the orchestrator.

[0125] The orchestration process for script-type plug-ins: Users directly write scripts in the orchestrator, enter the script file name, run the engine, and run parameters. Finally, the orchestrator generates a script orchestration object.

[0126] There are no strict restrictions on the file formats and programming languages ​​supported by the scripts. It only requires that the component can provide an execution engine of the corresponding format, such as shell scripts, Python scripts, Java scripts, Lua scripts, etc.

[0127] Step 4: Generate definition files.

[0128] After the compilation is completed, a definition file is generated based on the compilation object output.

[0129] When generating definition files from orchestration objects, the basic information section is the same for the three orchestration objects (API, configuration, and script). It is filled in by the user during orchestration, including the plug-in name (name), description (description), and version (version). The type field (kind) is automatically generated as the plug-in type (plugin). Dependent components and plug-ins (dependent) are generated from the dependent field (dependent) of the orchestration object.

[0130] The API orchestration object uses the API definition field (api) to generate the API definition field (api) of the definition file. Since this is an API orchestration object, it does not involve configuration-type and script-type orchestration, so the configuration field (config) and script field (script) are blank.

[0131] Configure the orchestration object and use the configuration field (config) to generate the configuration field (config) of the definition file. Since this is a configuration type orchestration object and does not involve API type and script type orchestration, the API definition field (api) and script field (script) are left blank.

[0132] The scripting object uses the script field (script) to generate the script field (script) of the definition file. Since this is a script-type orchestration object, it does not involve API-type and configuration-type orchestration, so the API definition field (api) and configuration field (config) are left blank.

[0133] Step 5: Publish the plugin.

[0134] Package the plug-in definition file and orchestration output file generated in step 4 and publish them to the assembly tool to form a plug-in.

[0135] API and configuration plugins orchestrate definition files, but no additional output files. Script plugins orchestrate output files that include definition files and user-written scripts.

[0136] All three types of orchestration described above generate definition files. Definition files serve as common definition specifications for components and plug-ins, containing complete component information. Orchestration output can only be published as a plug-in based on the definition file.

[0137] Plugins provide definition files that can be used in the component assembly and orchestration process, just like components. Repeating steps 1 through 5 forms a "component / plugin - assembly - orchestration - plugin release" cycle. Each cycle orchestrates new APIs, configurations, and scripts based on existing components and plug-ins, providing extensibility for the assembly process. This process can be used to build extensibility when existing component / plug-in functionality or configurations don't meet requirements.

[0138] FIG12 is a schematic diagram of a framework for expanding capability accumulation according to an embodiment of the present disclosure. As shown in FIG12 ,

[0139] In the first iteration, the user selects components A and B and follows steps 1 to 5 to create plugin X. In the second iteration, the user selects components C and plugin X to create plugin Y. Subsequent iterations can still be performed based on components A, B, and C and plugins X and Y to meet user needs.

[0140] In an exemplary embodiment, when assembling a company's user management system, it is found that the old version of the client uses a web service interface, and the new version of the client uses a rest interface. The old version of the server provides a web service interface, and the new version of the server provides a rest interface. Now the old version of the server needs to be taken offline, but it is impossible to ensure that all clients are updated to the new version in a short period of time, so a compatibility layer is needed, that is, the client uses the web service interface to send a request to the server rest interface, and the compatibility layer is responsible for the protocol conversion. This requirement can be met by using the present disclosure in the assembly process. The plug-in orchestration process provides the function of forwarding the web service interface to the rest interface, so that the old version of the client can continue to use it, and the old version of the server can be taken offline. The entire assembly process does not require modification of the component code.

[0141] 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. As shown in FIG13 ,

[0142] The component server described above is divided into two components, each of which provides an interface: Component A provides the GET / user / :id interface to query user basic information. Component B provides the GET / role / :id interface to query user roles.

[0143] Step 1: The user selects a component and generates a definition file.

[0144] Select components A and B in the assembly tool and let the assembly process merge the component definitions.

[0145] Component A is named user-manager (name), of type (kind) component type (component), version v1 (version), provides a user-info interface (GET / user / :id), and depends on component x (dependent).

[0146] Component B is named role-manager (name), of type component type (kind), version v1 (version), provides a role-info interface (GET / user / :id), and depends on component y (dependent).

[0147] Get two swagger files from the two definition files: user-info-swagger.json and role-info-swagger.json.

[0148] The swagger.json file describes the interface name, protocol, input parameter structure, and output parameter structure.

[0149] Step 2: Parse the component definition and generate an orchestration object. After step 1, import the definition files of the two components into the plug-in orchestrator. The plug-in orchestrator reads the definition files and generates an orchestration object. Each API corresponds to an orchestration object, which is displayed on the orchestrator interface.

[0150] Step 3: User orchestration and generation of orchestration output.

[0151] FIG14 is a schematic diagram of a framework of an API selected and a generated API during conversion between a web service protocol and a rest protocol according to an embodiment of the present disclosure. As shown in FIG14 ,

[0152] The user selects the above two interfaces in the orchestrator for calling, provides a web service protocol interface, and provides conversion functions between the web service protocol and the rest protocol, and provides a new web service interface definition.

[0153] After the orchestration is completed, the orchestrator generates an orchestration object.

[0154] The orchestrated API provides a web service protocol. When a web service request is received, it converts the request into a REST request, calls the corresponding interface, and returns.

[0155] Step 4: Generate definition files.

[0156] The plug-in publishing process constructs a definition file based on the orchestration object output in step 3.

[0157] The user fills in the basic information in the definition file during orchestration, including the plugin name, description, and version. The configuration field (config) and script field (script) are left blank, and the type field is automatically generated as the plugin type (plugin). Dependent components and plugins (dependent) are generated from the dependent field (dependent) of the orchestration object. The dependencies are user-manager and role-manager components. Since these two components depend on components x and y, respectively, the web service-api plugin also needs to depend on components x and y. The API definition field (api) in the definition file is generated by the orchestration object.

[0158] Step 5: Publish the plug-in. Package the plug-in definition file and the orchestration output file generated in Step 4 and publish them to the assembly tool to create a plug-in.

[0159] The subsequent assembly process can use component A, component B and this plug-in to provide interface compatibility between the web service client and the rest server. The entire process does not require modifying the code of components A and B.

[0160] Summary: This implementation example demonstrates how to use assembly, orchestration, and publishing plug-ins to implement extended functionality for interface protocol conversion without modifying the original component code.

[0161] In another exemplary embodiment, when assembling a company's assessment system component, the user needs to provide different error code configurations according to different scenarios. The error code is packaged together with the code and is not easy to modify. By using the method disclosed in this invention, multiple error code configurations are compiled during the assembly process to meet the needs.

[0162] The assessment system mainly relies on two components, namely component A and component B.

[0163] Step 1: The user selects a component and generates a definition file.

[0164] Since configuration orchestration does not require input based on component definition files, configuration orchestration does not require component selection. Configuration-type plug-in orchestration does not require step 1.

[0165] Step 2: Parse the component definition and generate the orchestration object.

[0166] Configuration orchestration is not based on component definition files. Instead, the orchestrator directly generates an orchestration object containing default values. Configuration-type plug-in orchestration does not require step 2.

[0167] Step 3: The user orchestrates the components and generates orchestration output.

[0168] Users edit business configurations directly in the orchestrator and write them to a configuration file named business-scene-a.yaml. The configuration data only needs to be formatted as key-value pairs; the orchestrator has no additional requirements for the format. Once the configuration is generated as a plugin, it only needs to be recognized by the components using it.

[0169] Step 4: Generate definition files.

[0170] The plug-in publishing process constructs a definition file based on the orchestration object output in step 3.

[0171] The user fills in the basic information of the definition file during orchestration, including the plugin name, description, and version. The API field (api) and the script field (script) are left blank, and the type field is automatically generated as the plugin type (plugin). Dependent components and plugins (dependent) are generated from the dependent field (dependent) of the orchestration object. Dependencies are filled in by the user during orchestration, and the dependency is the user-score-manager component. The configuration field (config) in the definition file is generated from the config field of the orchestration object.

[0172] Step 5: Publish the plugin.

[0173] The plugin definition file and orchestration output file generated in step 4 are packaged and published to the assembly tool as a plugin. The plugin provides the configuration for scenario A. Similarly, plugins can be generated based on the configurations for other scenarios orchestrated by components A and B. Subsequent assembly processes select components A and B and combine them with different configuration plugins, enabling the assessment system to dynamically select configurations during the assembly process without intruding on existing component code.

[0174] Summary: This implementation example demonstrates how to use assembly, orchestration, and publishing plug-ins to implement configuration plug-in functionality without modifying the original component code, providing existing components with the ability to dynamically switch configurations.

[0175] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by adding the necessary general hardware platform with the help of software, of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD-ROM), including a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present disclosure.

[0176] This embodiment also provides a device for implementing the scalability of the assembly process. The device is configured to implement the above-mentioned embodiments and preferred embodiments, and the details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0177] FIG15 is a schematic diagram of a structure of a device for implementing scalability of an assembly process according to an embodiment of the present disclosure. As shown in FIG15 , the device includes:

[0178] An assembling module 151 is configured to select a reusable functional unit and obtain a first definition file set based on the reusable functional unit;

[0179] The plug-in arrangement module 152 is configured to parse the first definition file set to obtain a first arrangement object; and

[0180] Performing arrangement processing on the first arrangement object to obtain a second arrangement object;

[0181] The plug-in generation module 153 is configured to obtain a second definition file set based on the second arrangement object; and

[0182] The target plug-in is configured to be obtained based on the second definition file set, so that the target plug-in provides extensibility capability for the component.

[0183] The difference between the first arrangement object and the second arrangement object lies in the different values ​​of the fields.

[0184] Furthermore, the reusable functional unit includes at least one of the following: a component, a plug-in.

[0185] Furthermore, the apparatus is further configured to: before selecting the reusable functional unit and obtaining the first definition file set based on the reusable functional unit, further include:

[0186] Target plugins are plugins that act as reusable units of functionality.

[0187] Furthermore, the apparatus is further configured to: obtain a target plug-in based on the second definition file set so that the target plug-in provides extensibility for the component, and further include:

[0188] Get package or version package based on target plug-ins and components of reusable functional units.

[0189] Furthermore, the device is further configured such that: the first arrangement object or the second arrangement object includes: an API object, a configuration object, and a script object; wherein,

[0190] For the first orchestration object: the API object includes the API definition information obtained by parsing the first definition file set, and the configuration object and the script object are both empty;

[0191] For the second orchestration object: the API object includes the API definition information generated by the orchestration, the configuration object includes the configuration file information set by the orchestration, and the script object includes the file address, execution engine, and running parameters of the script set by the orchestration.

[0192] Furthermore, the device is further configured to: obtain an API plug-in based on the API object;

[0193] The API plug-in is re-orchestrated to obtain a new API plug-in.

[0194] Furthermore, the apparatus is further configured to: parse the first definition file set to obtain a first arrangement object, including:

[0195] A dependency analysis is performed on the reusable functional unit based on the first definition file set to select dependent components or plug-ins.

[0196] Furthermore, the apparatus is further configured to: parse the first definition file set to obtain a first arrangement object, including:

[0197] Parsing the API field, configuration field, and script field of the first definition file to obtain a parsing result;

[0198] An orchestration operation is performed on the first orchestration object, which is an API object, a configuration object, or a script object, based on the parsing result.

[0199] Furthermore, the apparatus is further configured to perform arrangement processing on the first arrangement object to obtain a second arrangement object, including:

[0200] In the case where the first orchestration object is an API object, a second orchestration object is obtained in response to a call operation of API parameters; wherein the API parameters include: an API protocol, a request method, a request path, request parameters, and response parameters;

[0201] In the case where the first orchestration object is a configuration object, in response to an edit operation of configuration parameters and dependent reusable functional units, a second orchestration object is obtained;

[0202] In the case where the first arrangement object is a script object, a second arrangement object is obtained in response to an editing operation of a script parameter or a script file name.

[0203] Furthermore, the device is further configured to obtain a target plug-in based on the second definition file set, including:

[0204] When the first orchestration object is an API object or a configuration object, a target plug-in is obtained based on the second definition file set.

[0205] Furthermore, the device is further configured to obtain a target plug-in based on the second definition file set, including:

[0206] In the case where the first orchestration object is a script object, a target plug-in is obtained based on the second definition file set and the script parameters.

[0207] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0208] An embodiment of the present disclosure further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when run.

[0209] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0210] An embodiment of the present disclosure further provides 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 perform the steps in any of the above method embodiments.

[0211] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0212] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0213] Obviously, those skilled in the art should understand that the modules or steps of the present disclosure described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices, they can be implemented using program code executable by the computing device, and thus, they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present disclosure is not limited to any particular combination of hardware and software.

[0214] The foregoing description is merely a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, or improvements made within the principles of the present disclosure shall be included within the scope of protection of the present disclosure.

Claims

1. A method for implementing the scalability of an assembly process, comprising: Selecting reusable functional units and obtaining a first set of definition files based on the reusable functional units; Parsing the first set of definition files to obtain a first orchestration object; Performing an orchestration process on the first orchestration object to obtain a second orchestration object; Obtaining a second set of definition files based on the second orchestration object; Obtaining a target plugin based on the second set of definition files, so that the target plugin provides scalability capabilities for components.

2. The method according to claim 1, wherein, The reusable functional units include at least one of the following: components, plugins.

3. The method according to claim 2, wherein, Before selecting reusable functional units and obtaining a first set of definition files based on the reusable functional units, it further includes: Regarding the target plugin as the plugin of the reusable functional unit.

4. The method according to claim 2, wherein After obtaining a target plugin based on the second set of definition files, so that the target plugin provides scalability capabilities for components, it further includes: Obtaining a package or version package based on the target plugin and the components of the reusable functional unit.

5. The method according to claim 1, wherein, The first orchestration object or the second orchestration object includes: API objects, configuration objects, script objects; where For the first orchestration object: the API object includes API definition information obtained by parsing the first set of definition files, and the configuration object and script object are both null values; For the second orchestration object: the API object includes API definition information generated by orchestration, the configuration object includes configuration file information set by orchestration, and the script object includes the file address, execution engine, and running parameters of the script set by orchestration.

6. The method according to claim 5, wherein, It further includes: Obtaining an API plugin based on the API object; Performing an orchestration process again based on the API plugin to obtain a new API plugin.

7. The method according to claim 1, wherein Parsing the first set of definition files to obtain a first orchestration object, including: Performing a dependency analysis on the reusable functional units based on the first set of definition files to select the dependent components or plugins.

8. The method according to claim 1, wherein Parsing the first set of definition files to obtain a first orchestration object, including: Parsing the API fields, configuration fields, and script fields of the first set of definition files to obtain parsing results; Performing an orchestration operation on the first orchestration object as an API object or a configuration object or a script object based on the parsing results.

9. The method according to claim 8, wherein Performing an orchestration operation on the first orchestration object as an API object or a configuration object or a script object based on the parsing results, including: When the first orchestration object is an API object, in response to a call operation of API parameters, obtaining the second orchestration object; where the API parameters include: API protocol, request method, request path, request parameters, and response parameters; When the first orchestration object is a configuration object, in response to an edit operation of configuration parameters and the dependent reusable functional units, obtaining the second orchestration object; When the first orchestration object is a script object, in response to an edit operation of script parameters and script file names, obtaining the second orchestration object.

10. The method according to claim 9, wherein, Obtaining a target plugin based on the second set of definition files, including: When the first orchestration object is an API object or a configuration object, a target plugin is obtained based on the second definition file set.

11. The method according to claim 9, wherein, Obtaining a target plugin based on the second definition file set includes: When the first orchestration object is a script object, a target plugin is obtained based on the second definition file set and the script parameters.

12. A computer-readable storage medium storing a computer program therein, wherein, When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 11 are implemented.

13. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method described in any one of claims 1 to 11 are implemented.

Images