A multi-level object version management method and system for service-oriented systems

Abstract

The present application discloses a multi-level object version management method and system for service-oriented systems. First, the service, service operation and service interface are version-defined. Then, based on the service, service operation and service interface after the version definition, the version relationship constraints are established in combination with the actual system design modeling scenario, and the service operation and the corresponding flow mechanism of the service under the version state are executed. Finally, the version management capabilities including version tracing, conflict detection and impact range analysis are expanded. By introducing a detailed object version management mechanism under the service-oriented system architecture, including unified version number definition, version relationship constraints, version status and its flow mechanism, version tracing, dependency conflict detection and impact range analysis, the problems of low efficiency, poor reliability, difficult maintenance and insufficient flexibility in traditional version management can be effectively solved.

Description

Technical Field

[0001] The present application relates to the field of software engineering technology, and in particular to a multi-level object version management method and system for a service-oriented system. Background Art

[0002] In the current model design and modeling results version management scenario, file-oriented version management technology is widely used. This technology is mainly used to track and manage changes in file versions. Its core mechanisms include local file backup, manual version marking, file merging, and history management. Specifically, every time a file changes, the system automatically generates a backup copy of the file. The user is responsible for manually adding a version number mark to each backup file. When multiple users modify the same file at the same time, possible merge conflicts need to be manually resolved.

[0003] However, this file-oriented version management method has several significant technical problems: First, users need to manually add tags to each file version and merge different versions. This process is not only time-consuming and labor-intensive, but also prone to errors, which reduces overall work efficiency; second, it is difficult to handle merge conflicts in a multi-user collaborative environment: when multiple users edit the same file together, manually resolving conflicts during file merges is not only complicated, but also easy to introduce new errors, affecting the integrity and consistency of the file; third, historical record management is difficult: manual management and maintenance of file historical records can easily lead to loss or confusion of records, making the tracing of historical versions extremely inconvenient; fourth, management object restrictions: existing file-oriented version management technology is mainly suitable for unstructured file management, which is difficult to meet the needs of efficient maintenance of service-oriented architecture digital assets in modern information systems.

[0004] In addition, file-oriented version management technology also faces challenges: First, the lack of unified and standardized version management rules for the service-oriented system architecture leads to unclear management granularity, especially when it comes to multiple element objects in the architecture. The lack of automated constraints makes version management more complicated; Second, under the existing technical framework, the version compatibility check process is cumbersome, which seriously affects the processing efficiency of the system; Third, over-reliance on manual version management increases the risk of human error, which may lead to omissions or errors in the version update process, thereby affecting the stable operation of the system; Fourth, as the system scale expands and the frequency of version updates increases, the maintenance of version control strategies becomes more complicated, increasing the workload and cost of system maintenance; Fifth, existing version management solutions are difficult to quickly respond to changes in business needs and diverse version compatibility requirements, resulting in poor performance when dealing with complex application scenarios.

[0005] To sum up, although the existing file-oriented version management technology has met the basic file version management needs to a certain extent, it still has many shortcomings in terms of multi-user collaboration, high efficiency, high reliability and flexibility. A more advanced and efficient version management solution is urgently needed. Summary of the invention

[0006] The purpose of this application is to overcome the existing technical defects and provide a multi-level object version management method and system for service-oriented systems. By introducing a detailed object version management mechanism under the service-oriented system architecture, including unified version number definition, version relationship constraints, version status and its flow mechanism, version traceability, dependency conflict detection and impact scope analysis, it can effectively solve the problems of low efficiency, poor reliability, difficult maintenance and insufficient flexibility in traditional version management.

[0007] The purpose of this application is achieved through the following technical solutions:

[0008] In a first aspect, the present application proposes a multi-level object version management method for a service-oriented system, the method comprising:

[0009] Versioning services, service operations, and service interfaces. A service includes multiple service operations and each service operation corresponds to at most a single service interface.

[0010] Based on the services, service operations and service interfaces after version definition, version relationship constraints are established in combination with actual system design modeling scenarios;

[0011] Based on the version relationship constraints, the service operation and service flow mechanism corresponding to the version status are executed. The version status includes activated, stable, forced upgrade, and pending synchronization.

[0012] Expanded version management capabilities, including version tracing, conflict detection, and impact scope analysis.

[0013] In a possible implementation, the step of defining versions of services, service operations, and service interfaces includes:

[0014] Define services, service operations, and service interfaces according to version numbers, so that services, service operations, and service interfaces all have version numbers in the format of [n].[n].[n], where n is a non-negative integer;

[0015] Solidify and iteratively modify historical resources through version numbers, and trace and maintain the life cycle;

[0016] Clarify the version management scope of each object.

[0017] In a possible implementation, the steps of solidifying and iteratively modifying historical resources through version numbers and tracing and maintaining the life cycle include:

[0018] If the version number is "[n].[n].[n]+", it means that the corresponding object model allows modification, so iterative modification is performed;

[0019] If the version number is "[n].[n].[n]", it means that the corresponding object model records a fixed version information, so historical resources are solidified and the model corresponding to the solidified version is not modified;

[0020] Trace and maintain the life cycle.

[0021] In a possible implementation, the service operation includes a service operation meta-attribute, a corresponding version service interface of the current state, and a corresponding version service operation of the current state dependency;

[0022] The service interface includes service interface meta-attributes and interface message payload.

[0023] In a possible implementation, the version relationship constraint includes service operations, service interfaces and dependencies.

[0024] The method further includes: upgrading the version corresponding to the service operation when any one of the meta-attribute of the service operation, the interface version corresponding to the service operation and the version corresponding to the service operation changes, and otherwise not changing.

[0025] In a possible implementation, the version relationship constraint also includes services and service operations.

[0026] The method further includes: when a service meta-attribute in the service or a version corresponding to a service operation changes, the version corresponding to the service operation is upgraded, otherwise, no change is made.

[0027] In a possible implementation, based on the version relationship constraint, the steps of executing the service operation and the corresponding flow mechanism of the service in the version state include:

[0028] Based on the version relationship constraint, set the initial version number [n].[n].[n];

[0029] When the service operation or service version status is activated, the service object or service operation object is changed from the stable status to the activated status through the activation operation, and the initial version number [n].[n].[n] is changed to [n].[n].[n]+;

[0030] When the service operation or service version status is stable, the service object or service operation object is changed from the activated status to the stable status through the upgrade operation, and the version number is changed from [n].[n].[n]+ to [n].[n].[n+1];

[0031] When the version status of the service operation is forced to upgrade, when the service operation object is in a stable state and the version of the service operation object it depends on changes, the status of the service operation object is marked as forced to upgrade;

[0032] When the version status of a service operation or service is pending synchronization, the version change history of each service object, service operation object, and service interface object is recorded.

[0033] In a possible implementation, the version tracing step includes: tracing the index of resource history information through the solidified version;

[0034] The steps of conflict detection include:

[0035] Collect all dependent party operation version data to be performed on the conflict detection service operation;

[0036] Group the service operation objects and extract the highest or latest version in each group as the baseline version for conflict detection;

[0037] If there is data in the group that is lower than the baseline version, it indicates that there is a dependency conflict in the dependent party, prompting the risk of data inconsistency during subsequent interface delivery;

[0038] The steps of impact scope analysis include:

[0039] The latest status data of the functional process is used as the basis for searching the impact scope, and the functional process containing the service operation object is reversely scanned based on the service operation;

[0040] Perform impact analysis and statistics based on the granularity of the service operation object, and perform impact analysis and statistics based on the granularity of the service operation version according to the actual scenario segmentation;

[0041] The impact range analysis algorithm can quickly find out the distribution of service operations in the functional process.

[0042] In a second aspect, the present application proposes a multi-level object version management system for a service-oriented system, the system comprising:

[0043] A version definition module is used to define versions for services, service operations, and service interfaces. A service includes multiple service operations and each service operation corresponds to at most a single service interface.

[0044] The constraint establishment module is used to establish version relationship constraints based on the services, service operations and service interfaces after version definition, combined with the actual system design modeling scenario;

[0045] The execution module is used to execute service operations and the corresponding flow mechanism of services in version states based on version relationship constraints. The version states include activated, stable, forced upgrade, and pending synchronization;

[0046] Extension modules are used to extend version management capabilities, including version tracing, conflict detection, and impact scope analysis.

[0047] The above main scheme of the present application and its further options can be freely combined to form multiple schemes, all of which are schemes that can be adopted and claimed for protection in the present application; and in the present application, (non-conflicting options) options and other options can also be freely combined. After understanding the scheme of the present application, those skilled in the art can understand that there are many combinations based on the existing technology and common knowledge, all of which are technical schemes to be protected by the present application, and they are not exhaustively listed here.

[0048] The present application discloses a multi-level object version management method and system for service-oriented systems. First, the service, service operation and service interface are version-defined. Then, based on the service, service operation and service interface after the version definition, the version relationship constraints are established in combination with the actual system design modeling scenario, and the service operation and the corresponding flow mechanism of the service under the version state are executed. Finally, the version management capabilities including version tracing, conflict detection and impact range analysis are expanded. By introducing a detailed object version management mechanism under the service-oriented system architecture, including unified version number definition, version relationship constraints, version status and its flow mechanism, version tracing, dependency conflict detection and impact range analysis, the problems of low efficiency, poor reliability, difficult maintenance and insufficient flexibility in traditional version management can be effectively solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 A flow chart of a multi-level object version management method for a service-oriented system proposed in an embodiment of the present application is shown.

[0051] Figure 2 A logic diagram of the service-oriented system architecture object version state transfer mechanism proposed in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0052] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0053] Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative work shall fall within the scope of protection of this application.

[0054] In the existing technology, file-oriented version management technology faces challenges: first, the lack of unified and standardized version management rules for service-oriented system architecture leads to unclear management granularity, especially when multiple element objects in the architecture are involved, the lack of automated constraints makes version management more complicated; second, under the existing technical framework, the version compatibility check process is cumbersome, which seriously affects the processing efficiency of the system; third, over-reliance on manual version management increases the risk of human error, which may lead to omissions or errors in the version update process, thereby affecting the stable operation of the system; fourth, with the expansion of system scale and the increase in version update frequency, the maintenance of version control strategies becomes more complicated, increasing the workload and cost of system maintenance; fifth, the existing version management scheme is difficult to quickly respond to changes in business needs and diverse version compatibility requirements, resulting in poor performance when dealing with complex application scenarios. Although the existing file-oriented version management technology meets the basic file version management needs to a certain extent, it still has many shortcomings in terms of multi-user collaboration, high efficiency, high reliability and flexibility, and urgently needs a more advanced and efficient version management solution.

[0055] Therefore, in order to solve the above-mentioned technical problems, the embodiment of the present application proposes a multi-level object version management method and system for a service-oriented system. By introducing a detailed object version management mechanism under a service-oriented system architecture, the version information of the service-oriented components can be managed efficiently and reliably in a distributed computing environment, ensuring the compatibility and collaborative working capabilities of various services during the iterative upgrade process of the system, thereby improving the stability and maintainability of the service-oriented system, which is described in detail below.

[0056] Please refer to Figure 1 , Figure 1 A schematic diagram of a process of a multi-level object version management method for a service-oriented system proposed in an embodiment of the present application is shown, and the method includes:

[0057] Step S1: Version definition of services, service operations and service interfaces.

[0058] A service consists of multiple service operations and each service operation corresponds to at most a single service interface.

[0059] According to the concept of service-oriented system architecture, detailed version definitions are made for services, service operations, and service interfaces to facilitate the management and maintenance of these objects. A service is a complete set of functions that can be deployed and maintained independently. A service can contain multiple service operations. The service version number format is [n].[n].[n] (n is a non-negative integer). The service version management scope includes service meta-attributes (such as name, identifier, type, etc.), service operations and their versions, and service interfaces and their versions.

[0060] A service operation is a specific functional unit in a service. Each service operation can independently perform specific tasks. A service operation corresponds to at most one service interface. The version number format of a service operation is also [n].[n].[n]. A service operation includes service operation meta-attributes, the corresponding version service interface of the current state, and the corresponding version service operation of the current state dependency.

[0061] The service interface is the standard interface provided by the service operation to the outside world. It is used to define the input and output of the service operation. The version number format of the service interface is also [n].[n].[n]. The version management scope of the service interface includes the service interface meta-attributes (such as name, identifier, type, etc.) and the interface message payload (signal).

[0062] In a possible implementation, the step of defining versions of services, service operations, and service interfaces includes:

[0063] Define services, service operations, and service interfaces according to version numbers, so that services, service operations, and service interfaces all have version numbers in the format of [n].[n].[n], where n is a non-negative integer;

[0064] Solidify and iteratively modify historical resources through version numbers, and trace and maintain the life cycle;

[0065] Clarify the version management scope of each object.

[0066] Defined by version number, the version number format is set to [major version number].[minor version number].[revision number]. The major version number is increased when there is an incompatible major update, the minor version number is increased when a backward-compatible feature is added, and the revision number is increased when a backward-compatible issue is fixed. The version number can not only be used to record and fix the status of a specific version of the service, service operation, and service interface, but also to track the content and time of each modification.

[0067] When historical resources are solidified and iteratively modified, each time a service, service operation, or service interface is modified, its version number needs to be updated. Use a version control system to manage the versions of code and configuration files to ensure that each version has detailed records. When a new version is officially released, ensure that all relevant documents and configuration files have been updated and are consistent with the version number.

[0068] Clarify the version management scope of each object, that is, what historical resource information can be solidified through the version number, and then trace the entire life cycle of each object through the version number record, clarify the management boundaries of each object, implement effective change control, and ensure the transparency and traceability of the version change process. Through the version management mechanism, reduce manual intervention and improve efficiency and flexibility.

[0069] In a possible implementation, the steps of solidifying and iteratively modifying historical resources through version numbers and tracing and maintaining the life cycle include:

[0070] If the version number is "[n].[n].[n]+", it means that the corresponding object model allows modification, so iterative modification is performed;

[0071] If the version number is "[n].[n].[n]", it means that the corresponding object model records a fixed version information, so historical resources are solidified and the model corresponding to the solidified version is not modified;

[0072] Trace and maintain the life cycle.

[0073] If the version number is [n].[n].[n]+, it means that the object model can be modified and iteratively modified according to the requirements; if the version number is [n].[n].[n], it means that the object model has recorded a fixed version information, and the model corresponding to the solidified version is not allowed to be modified. When the object model is in a modifiable state (that is, the version number is [n].[n].[n]+), it is modified and optimized. After the modification is completed, the version number is updated to [n].[n].[n+1]+, indicating that the new version is still in a modifiable state. When the object model reaches a stable state and needs to be solidified, the version number is updated from [n].[n].[n]+ to [n].[n].[n], and the solidified version number [n].[n].[n] indicates that the version has recorded fixed information and cannot be modified.

[0074] By recording version numbers, you can trace the entire life cycle of an object and understand the change history of each version. Using version number management tools, you can easily query and compare the differences between different versions to ensure the transparency and traceability of changes. For solidified versions, you can reference and reuse them through version numbers to ensure the stability and consistency of the system. For versions that need to be iterated, you can modify and optimize them based on the new version number to ensure continuous improvement of the system.

[0075] Step S2: Based on the version-defined services, service operations, and service interfaces, version relationship constraints are established in combination with actual system design modeling scenarios.

[0076] By defining version numbers for each service, service operation, and service interface, and adjusting the version numbers according to their changes (incompatible major updates, backwards-compatible feature additions, or problem fixes), while ensuring that the version relationship between service operations and services is stable (the interface version of the service operation and the dependent service operation versions are stable, and all service operation versions included in the service are stable), and through version control tools, automated testing, document synchronization, and maintenance of change logs, etc., the version relationship of each component can be effectively managed to ensure the stability and maintainability of the system.

[0077] The version relationship constraints include service operations, service interfaces and dependencies. The method also includes: when any one of the meta-attributes of the service operation, the interface version corresponding to the service operation and the version corresponding to the service operation changes, the version corresponding to the service operation is upgraded, otherwise no change is made.

[0078] The conditions for the service operation version to be stable and solidified are: the interface version corresponding to the service operation must be stable, the interface version number has been solidified and will not be modified; all other service operation versions that the service operation depends on are stable, and the version numbers of all dependent service operations have been solidified and will not be modified; if any of the meta-attributes, interface version, or dependent service operation version of the service operation changes, the service operation version is allowed to be upgraded. If there is no change, upgrading is not recommended or prohibited to avoid version proliferation.

[0079] The version relationship constraint also includes services and service operations. The method also includes: when the version corresponding to the service meta-attribute or service operation in the service changes, the version corresponding to the service operation is upgraded and changed, otherwise, no change is made.

[0080] The conditions for a service version to be stable and solidified are: all service operation versions contained in the service must be stable, and the version numbers of all service operations have been solidified and will no longer be modified; if any of the meta-attributes of the service or the service operation versions contained therein change, the service version is allowed to be upgraded; if there is no change, upgrading is not recommended or prohibited to avoid version proliferation.

[0081] Step S3: Based on the version relationship constraints, execute the service operation and the corresponding flow mechanism of the service under the version status.

[0082] Version status includes activated, stable, forced upgrade, and pending synchronization. Based on version relationship constraints, service operations and service version statuses will flow between several statuses according to different operations: a service or service operation with an initial version number of [n].[n].[n] can be changed from a stable status to an activated status through an activation operation, and the version number becomes [n].[n].[n]+; after the modification is completed, the activated status is changed back to a stable status through an upgrade operation, and the version number is updated to [n].[n].[n+1]. If a service operation is in a stable status and the service operations it depends on change, the service operation will enter a forced upgrade status; if the version of a service operation in other business processes lags behind the latest version, the service to which it belongs will be marked as pending synchronization.

[0083] Based on the version relationship constraints, the steps of executing the service operation and the corresponding flow mechanism of the service in the version state include:

[0084] Based on the version relationship constraint, set the initial version number [n].[n].[n];

[0085] When the service operation or service version status is activated, the service object or service operation object is changed from the stable status to the activated status through the activation operation, and the initial version number [n].[n].[n] is changed to [n].[n].[n]+;

[0086] When the service operation or service version status is stable, the service object or service operation object is changed from the activated status to the stable status through the upgrade operation, and the version number is changed from [n].[n].[n]+ to [n].[n].[n+1];

[0087] When the version status of the service operation is forced to upgrade, when the service operation object is in a stable state and the version of the service operation object it depends on changes, the status of the service operation object is marked as forced to upgrade;

[0088] When the version status of a service operation or service is pending synchronization, the version change history of each service object, service operation object, and service interface object is recorded.

[0089] Figure 2 The logical diagram of the state transfer mechanism of the service-oriented system architecture object version proposed in the embodiment of the present application is shown, which is divided into two parts: "writable" and "reuse", and each part is subdivided into three levels: service, service operation and service interface. Each level contains four states: to be synchronized, activated, stable and passive upgrade. The red arrows indicate the necessary conditions, and the blue and green arrows indicate the driving relationship. Specifically, starting from the state to be synchronized, after activation and stabilization, it finally returns to the stable state; and the reuse path cyclically converts in different states to ensure the flexibility and reliability of the system. The entire process is connected by arrows of different colors, which clearly shows the conversion relationship and conditions between each state.

[0090] First, each service or service operation is assigned an initial version number [n].[n].[n] when it is first created. In the activated state, when a service operation needs to be modified, it is changed from the stable state to the activated state, and the version number is changed from [n].[n].[n] to [n].[n].[n]+. In this state, the service operation and its interface can be modified. Similarly, when a service needs to be modified, it is changed from the stable state to the activated state, and the version number is changed from [n].[n].[n] to [n].[n].[n]+. In this state, the service and the service operations it contains can be modified.

[0091] In the stable state, when the service operation in the activated state is modified, it is changed from the activated state to the stable state through the upgrade operation, and the version number is changed from [n].[n].[n]+ to [n].[n].[n+1]. Similarly, when the service in the activated state is modified, it is changed from the activated state to the stable state through the upgrade operation, and the version number is changed from [n].[n].[n]+ to [n].[n].[n+1].

[0092] In the forced upgrade state, when a service operation is in a stable state and the version of the service operation it depends on changes, the state of the service operation will be marked as "forced upgrade". In this case, the service operation needs to be adjusted accordingly to adapt to the changes of the dependent party.

[0093] In the pending synchronization state, service operations can be reused by multiple business processes. When the version of a service operation in a business process lags behind its latest version, the status of the service operation will be marked as "pending synchronization". In addition, if a service operation contained in a service is in the pending synchronization state, the service itself will also be marked as "pending synchronization".

[0094] Step S4: Expand version management capabilities.

[0095] Version management capabilities include version tracing, conflict detection, and impact analysis. In order to enhance the system's version management capabilities, three key functions are introduced: version tracing, conflict detection, and impact analysis, which can ensure the traceability of resource history information, prevent the risk of data inconsistency caused by dependency conflicts, and improve the understanding of the impact of service operation changes.

[0096] The steps of version tracing include: indexing and tracing resource history information through the solidified version.

[0097] By recording and solidifying the metadata of each version (such as timestamp, submitter, change content, etc.), the system can quickly retrieve and display the historical status of resources, thereby providing comprehensive traceability capabilities and ensuring that developers can easily view the change history of a service or service operation in different versions.

[0098] The steps of conflict detection include:

[0099] Collect all dependent party operation version data to be performed on the conflict detection service operation;

[0100] Group the service operation objects and extract the highest or latest version in each group as the baseline version for conflict detection;

[0101] If there is data in the group that is lower than the baseline version, it indicates that there is a dependency conflict in the dependent party, prompting the risk of data inconsistency during subsequent interface delivery;

[0102] Since different service operations (service interfaces) can be designed by different designers, the dependencies of these service operations may overlap, for example, service operation A depends on service operation M and service operation N, while service operation B depends on service operation M and service operation P. If different service operations depend on different versions of the same service operation object, this will be considered a version conflict, which may lead to the risk of inconsistent data when the subsequent interface is delivered.

[0103] First, obtain all the dependent operation version data of the service operation to be conflict-checked, and group them according to the service operation object. Each group represents the same dependent service operation object and may contain multiple version data. Extract the highest (latest) version in each group as the baseline version for conflict detection. If there is data lower than the baseline version in the group, it is considered that there is a dependency conflict in the dependent party corresponding to these low-version service operations, indicating a potential risk of data inconsistency. In this way, even if multiple designers are responsible for different service operation designs, the consistency of service operation (interface) data can still be guaranteed through conflict detection, so that developers can implement system code based on the design, improve compilation correctness and system stability.

[0104] The steps of impact scope analysis include:

[0105] The latest status data of the functional process is used as the basis for searching the impact scope, and the functional process containing the service operation object is reversely scanned based on the service operation;

[0106] Perform impact analysis and statistics based on the granularity of the service operation object, and perform impact analysis and statistics based on the granularity of the service operation version according to the actual scenario segmentation;

[0107] The impact range analysis algorithm can quickly find out the distribution of service operations in the functional process.

[0108] Since service operations can be used in multiple functional processes, these functional processes will be affected when service operations change. Providing the ability to analyze the impact scope of service operations can significantly improve the efficiency of designers in analysis, maintenance and resource management.

[0109] First, the latest status data of the functional process (i.e., the business chain) is used as the benchmark for impact scope search. Then, based on the service operation, the functional process containing the service operation object is reversely scanned, and impact scope analysis and statistics are performed according to the granularity of the service operation object. According to the actual scenario segmentation, impact scope analysis and statistics are performed according to the granularity of the service operation version. Finally, through the impact scope analysis algorithm, the distribution of a specific version of the service operation in the functional process can be quickly found, which can improve the comprehensive understanding of the impact of service operation changes, help designers to analyze, maintain and manage resources more efficiently, and enhance the stability and consistency of the system.

[0110] Therefore, version traceability can ensure the traceability of resource historical information, conflict detection can prevent the risk of data inconsistency caused by dependencies on different versions, and impact range analysis can improve the comprehensive understanding of the impact of service operation changes, enhance the stability and consistency of the system, and improve the work efficiency of developers. It improves the overall quality of the system as a whole and provides effective management and control means for complex service-oriented system architectures.

[0111] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0112] First, through the version definition and version solidification of the service-oriented system architecture objects, each resource object can record the corresponding model information through the version within its corresponding management scope.

[0113] Second, by establishing the version management scope of the service-oriented system architecture objects and the constraint relationship between different elements, the management boundaries of each resource object are clarified.

[0114] Third, by standardizing the version status design of service-oriented system architecture objects, the traceability and transparency of the version change process can be ensured.

[0115] Fourth, through the version management mechanism, quickly identify, track and even compare the version information of the service objects.

[0116] In summary, by clarifying the version management rules of services, service operations, and service interfaces, we can achieve automatic recording and control of resource changes, ensure the traceability and transparency of version changes, and at the same time, through dependency conflict detection and impact range analysis algorithms, ensure the consistency of service operation data and the stability of the system, thereby improving the performance and maintainability of the entire service-oriented system.

[0117] A possible implementation of a multi-level object version management system for a service-oriented system is provided below, which is used to execute the various execution steps and corresponding technical effects of the multi-level object version management method shown in the above embodiment and possible implementation. The system includes:

[0118] A version definition module is used to define versions for services, service operations, and service interfaces. A service includes multiple service operations and each service operation corresponds to at most a single service interface.

[0119] The constraint establishment module is used to establish version relationship constraints based on the services, service operations and service interfaces after version definition, combined with the actual system design modeling scenario;

[0120] The execution module is used to execute service operations and the corresponding flow mechanism of services in version states based on version relationship constraints. The version states include activated, stable, forced upgrade, and pending synchronization;

[0121] Extension modules are used to extend version management capabilities, including version tracing, conflict detection, and impact scope analysis.

[0122] The present application discloses a multi-level object version management method and system for service-oriented systems. First, the service, service operation and service interface are versioned. Then, based on the service, service operation and service interface after the version definition, the version relationship constraints are established in combination with the actual system design modeling scenario, and the service operation and the service are executed. The corresponding flow mechanism of the service in the version state is executed, and finally the version management capabilities including version tracing, conflict detection and impact range analysis are expanded. By introducing a detailed object version management mechanism under the service-oriented system architecture, including unified version number definition, version relationship constraints, version status and its flow mechanism, version tracing, dependency conflict detection and impact range analysis, the problems of low efficiency, poor reliability, difficult maintenance and insufficient flexibility in traditional version management can be effectively solved.

[0123] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A multi-level object version management method for a service-oriented system, characterized in that: The method comprises: Versioning services, service operations, and service interfaces. A service includes multiple service operations and each service operation corresponds to at most a single service interface. The steps to version services, service operations, and service interfaces include: Define services, service operations, and service interfaces according to version numbers, so that services, service operations, and service interfaces all have version numbers in the format of [n].[n].[n], where n is a non-negative integer; If the version number is "[n].[n].[n]+", it means that the corresponding object model allows modification, so iterative modification is performed; If the version number is "[n].[n].[n]", it means that the corresponding object model records a fixed version information, so historical resources are solidified and the model corresponding to the solidified version is not modified; Trace and maintain the life cycle; Clarify the version management scope of each object; Based on the services, service operations and service interfaces after version definition, version relationship constraints are established in combination with actual system design modeling scenarios; Based on the version relationship constraints, the service operation and service flow mechanism corresponding to the version status are executed. The version status includes activated, stable, forced upgrade, and pending synchronization. Based on the version relationship constraints, the steps of executing the service operation and the corresponding flow mechanism of the service in the version state include: Based on the version relationship constraint, set the initial version number [n].[n].[n]; When the service operation or service version status is activated, the service object or service operation object is changed from the stable status to the activated status through the activation operation, and the initial version number [n].[n].[n] is changed to [n].[n].[n]+; When the service operation or service version status is stable, the service object or service operation object is changed from the activated status to the stable status through the upgrade operation, and the version number is changed from [n].[n].[n]+ to [n].[n].[n+1]; When the version status of the service operation is forced to upgrade, when the service operation object is in a stable state and the version of the service operation object it depends on changes, the status of the service operation object is marked as forced to upgrade; When the version status of a service operation or service is pending synchronization, the version change history of each service object, service operation object, and service interface object is recorded; Expanded version management capabilities, including version tracing, conflict detection, and impact scope analysis; The steps of version tracing include: indexing and tracing resource history information through the solidified version; The steps of conflict detection include: Collect all dependent party operation version data to be performed on the conflict detection service operation; Group the service operation objects and extract the highest or latest version in each group as the baseline version for conflict detection; If there is data in the group that is lower than the baseline version, it indicates that there is a dependency conflict in the dependent party, prompting the risk of data inconsistency during subsequent interface delivery; The steps of impact scope analysis include: The latest status data of the functional process is used as the basis for searching the impact scope, and the functional process containing the service operation object is reversely scanned based on the service operation; Perform impact analysis and statistics based on the granularity of the service operation object, and perform impact analysis and statistics based on the granularity of the service operation version according to the actual scenario segmentation; The impact range analysis algorithm can quickly find out the distribution of service operations in the functional process.

2. The multi-level object version management method according to claim 1, characterized in that: The service operation includes the service operation meta-attributes, the corresponding version of the service interface in the current state, and the corresponding version of the service operation in the current state dependency; The service interface includes service interface meta-attributes and interface message payload.

3. The multi-level object version management method according to claim 1, characterized in that: The version relationship constraints include service operations, service interfaces and dependencies. The method further includes: upgrading the version corresponding to the service operation when any one of the meta-attribute of the service operation, the interface version corresponding to the service operation and the version corresponding to the service operation changes, and otherwise not changing.

4. The multi-level object version management method according to claim 1, characterized in that: The version relationship constraints also include services and service operations. The method further includes: when a service meta-attribute in the service or a version corresponding to a service operation changes, the version corresponding to the service operation is upgraded, otherwise, no change is made.

5. A multi-level object version management system for service-oriented systems, characterized in that: The system comprises: A version definition module, used to define services, service operations and service interfaces according to version numbers, so that services, service operations and service interfaces all have version numbers in the format of [n].[n].[n], where n is a non-negative integer; If the version number is "[n].[n].[n]+", it means that the corresponding object model allows modification, so iterative modification is performed; If the version number is "[n].[n].[n]", it means that the corresponding object model records a fixed version information, so historical resources are solidified and the model corresponding to the solidified version is not modified; Trace and maintain the life cycle; Clarify the version management scope of each object. A service includes multiple service operations and each service operation corresponds to at most a single service interface. The constraint establishment module is used to establish version relationship constraints based on the services, service operations and service interfaces after version definition, combined with the actual system design modeling scenario; An execution module is used to set the initial version number [n].[n].[n] based on the version relationship constraint; When the service operation or service version status is activated, the service object or service operation object is changed from the stable status to the activated status through the activation operation, and the initial version number [n].[n].[n] is changed to [n].[n].[n]+; When the service operation or service version status is stable, the service object or service operation object is changed from the activated status to the stable status through the upgrade operation, and the version number is changed from [n].[n].[n]+ to [n].[n].[n+1]; When the version status of the service operation is forced to upgrade, when the service operation object is in a stable state and the version of the service operation object it depends on changes, the status of the service operation object is marked as forced to upgrade; When the version status of a service operation or service is pending synchronization, the version change history of each service object, service operation object, and service interface object is recorded. The version status includes activated, stable, forced upgrade, and pending synchronization; Extension modules are used to extend version management capabilities, including version tracing, conflict detection, and impact range analysis. Version tracing includes: indexing and tracing resource history information through solidified versions; Conflict detection includes: Collect all dependent party operation version data to be performed on the conflict detection service operation; Group the service operation objects and extract the highest or latest version in each group as the baseline version for conflict detection; If there is data in the group that is lower than the baseline version, it indicates that there is a dependency conflict in the dependent party, prompting the risk of data inconsistency during subsequent interface delivery; Impact analysis includes: The latest status data of the functional process is used as the basis for searching the impact scope, and the functional process containing the service operation object is reversely scanned based on the service operation; Perform impact analysis and statistics based on the granularity of the service operation object, and perform impact analysis and statistics based on the granularity of the service operation version according to the actual scenario segmentation; The impact range analysis algorithm can quickly find out the distribution of service operations in the functional process.

Images