A distributed serial orchestration service execution method and system

Through the distributed serial orchestration service execution system, custom packet headers are used to parse HTTP messages, reduce network requests and cross-routing communication, solve the problems of large load pressure on the ESB bus and insufficient real-time performance, and achieve the improvement of system stability and real-time performance.

CN115658164BActive Publication Date: 2025-08-12HUNAN UNIV
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211177357.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-09-26
Publication Date
2025-08-12
Estimated Expiration
2042-09-26

AI Technical Summary

Technical Problem

Traditional ESB buses are under load when orchestrating services are performed in industrial enterprises, and performance losses are caused by excessive network requests.

Method used

The distributed serial orchestration service execution system is adopted to work together through the ESB bus, orchestration service execution server and ordinary server, and to parse HTTP messages using custom message headers to reduce network requests and cross-routing communications, and realize distributed calls of services.

Benefits of technology

It improves the stability and real-time of the system, reduces the load pressure of the ESB bus, and reduces network communication time and bandwidth usage.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115658164B_ABST
    Figure CN115658164B_ABST
Patent Text Reader

Abstract

A distributed serial orchestration service execution method and system. The method first registers the information of a device service application to an ESB bus, then uses the ESB bus to orchestrate the registered service to form orchestration information, and then requests the ESB bus to call the orchestration service. The ESB bus sends a corresponding service request to the server where the service to be called is located according to the orchestration rules corresponding to the requested service and the type or user configuration of the server where the service to be called is located. If the service request received by the server is a normal service request, the server calls the corresponding device service application to obtain a result and returns it to the ESB bus. If it is an orchestration service request, the orchestration service execution server first calls the corresponding device service application to obtain a result, then queries the corresponding service orchestration rule information based on the custom message header in the orchestration service request, calls subsequent services according to the orchestration rule information, and sends the current service execution status to the ESB bus after completion.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of distributed industrial Internet technology, and in particular to a distributed serial orchestration service execution method and system. Background Art

[0002] With the continuous expansion of industrial modules, the traditional SCADA and MES architectures, centered around PLCs and built on a fieldbus backbone, are no longer suitable. In the Industry 4.0 era, the coexistence of multiple systems and interconnected devices based on IoT technology are becoming mainstream. A more mature solution, based on the SOA architectural philosophy, abstracts heterogeneous device resources into network services and manages them through an enterprise service bus (ESB). Furthermore, the ESB bus can orchestrate and integrate registered services without the need for additional code development, effectively achieving resource and business restructuring.

[0003] Generally speaking, in industrial enterprises, the ESB bus is deployed on a high-performance computer platform, and the equipment services in different workshops are deployed on different platform servers and registered with the ESB bus. The ESB bus orchestrates and integrates the services registered on it to form a larger-granularity service for users to call. Due to the characteristics of industrial production, the services involved in the orchestration have a certain degree of aggregation, for example, they are all in one workshop. There is a problem with this process: the execution of the orchestration service requires the deep participation of the ESB bus, and all orchestration business processes require the ESB bus for collaborative calls, which increases the load pressure of the ESB bus. At the same time, from the perspective of stability, if the ESB bus has an abnormality, the orchestration service will not be called for execution. On the other hand, if Figure 1 As shown in the figure, the ESB bus makes requests to the applications deployed on each server in turn, which will generate multiple network requests and response messages, causing loss of system real-time performance. In addition, it does not take service aggregation into consideration, resulting in multiple routings for each request, further causing performance loss. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a distributed serial orchestration service execution method and system that is compatible with traditional deployed service systems and effectively improves system stability and real-time performance.

[0005] In order to solve the above technical problems, the present invention adopts the following technical methods: a distributed serial orchestration service execution system, including an ESB bus, multiple orchestration service execution servers and multiple ordinary servers, the ESB bus is connected to the orchestration service execution servers and the ordinary servers respectively, and the orchestration service execution servers and the ordinary servers are respectively mounted with device service applications;

[0006] The ESB bus includes a service management module, a service orchestration management module, a service orchestration execution module, a user interaction module, and a server interaction module;

[0007] The service management module is used for service registration, query, deletion, and orchestration rule setting;

[0008] The service orchestration management module is used to store and manage orchestration services and assign a unique orchestration information number ServiceID in the system to each orchestration service;

[0009] The service orchestration execution module is used to parse and load the orchestration service called by the user, and send a service request to the orchestration service execution server or the ordinary server according to the orchestration rules;

[0010] The user interaction module is used to communicate with the client to facilitate user orchestration of service calls and status inquiries;

[0011] The server interaction module establishes a connection with the orchestration service execution server to send the orchestration rule information requested by the orchestration service execution server and receive the orchestration service execution status information fed back by the orchestration service execution server;

[0012] The common server is an HTTP server for sending and receiving HTTP messages and serving application call responses;

[0013] The orchestration service execution server includes an HTTP message sending and receiving module, an ESB interaction module, an orchestration service verification module, and an orchestration service execution module;

[0014] The HTTP message transceiver module is used to receive and respond to HTTP requests and determine whether the request message is a normal service request or an orchestration service request;

[0015] The ESB interaction module is used to communicate with the ESB bus, obtain orchestration information, and feedback the current execution status of the orchestration information;

[0016] The orchestration service verification module is used to verify the compliance of the current service request;

[0017] The orchestration service execution module is used to call the service program according to the orchestration rules and feed back the current request execution status to the ESB bus.

[0018] Furthermore, the ESB interaction module of the orchestration service execution server reads the ESB bus address information in the server configuration file, actively establishes contact with the ESB bus, and obtains the synchronized ESB bus orchestration library through subscription or active request; the ESB interaction module feeds back the execution status of the service to be accessed in the orchestration information to the ESB bus based on the execution result of the orchestration service execution module.

[0019] As another aspect of the present invention, a distributed serial orchestration service execution method includes the following steps:

[0020] Step S1: Mount the device service application to the orchestration service execution server and the common server, register the device service application information to the ESB bus, and establish a connection between the orchestration service execution server and the ESB bus;

[0021] Step S2: The user orchestrates the registered services using the ESB bus to form orchestration information. The ESB bus assigns a unique orchestration information number ServiceID to the orchestration information and synchronizes it to the orchestration service execution server that mounts the called service in the orchestration information.

[0022] Step S3: The user initiates a request to the ESB bus to call the orchestration service. The ESB bus returns the SessionID of the orchestration service request execution to the user. The ESB bus becomes the first orchestration work executor. The orchestration work executor sends a corresponding service request to the server to be called according to the type of the server where the service to be called is located to call the corresponding service. If the server where the service to be called is located is an orchestration service execution server and participates in the orchestration execution, the orchestration work executor sends an orchestration service request to the orchestration service execution server to complete the call of the corresponding service. The orchestration service execution server is updated to become the next orchestration work executor. If the server where the service to be called in the orchestration information is located is an ordinary server, or although it is an orchestration service execution server but does not participate in the orchestration execution, the orchestration work executor sends an ordinary service request to the server where the service to be called is located to complete the call of the corresponding service. The orchestration work executor then processes the next call service until one orchestration service request is sent. The orchestration service execution server that receives the orchestration server request at this time is updated to become the next orchestration work executor.

[0023] The first orchestration service execution server that receives the orchestration service request becomes the second orchestration work executor, and so on. The orchestration service execution server that receives the orchestration service request becomes the N+1th orchestration work executor, until all services in the orchestration information are called. After each orchestration work executor calls a service and obtains the result, it pushes the current service execution status to the ESB bus, and the ESB bus distributes it to call status followers, or uses topic publishing for followers to subscribe and receive.

[0024] Furthermore, in step S3, the user knows the orchestration information and confirms that the server where the first service to be called in the orchestration information is located is the orchestration service execution server and participates in the orchestration execution. The user can replace the ESB bus to independently construct the orchestration service request and send it to the orchestration service execution server.

[0025] Furthermore, the orchestration information formed in step S2 includes the service call sequence, the relationship between the previous and next service parameters, custom parameters, the server type, whether the server participates in the execution of the orchestration, and the orchestration information version.

[0026] Furthermore, the orchestration service request is an HTTP message including a custom message header x-rdcs and x-sindex; the format of the x-rdcs is {"ServiceID":"xxxxx","SessionID":"ESBKey_xxxx"}, where ServiceID is the orchestration information number, which is the unique orchestration information number generated by the ESB bus for the orchestration information in step S2; SessionID is the orchestration service request execution number, which is set in the custom message header when the ESB bus or the user constructs the orchestration service request and has temporal and spatial uniqueness; the format of the x-sindex is {"ServiceIndex":"value"}, where ServiceIndex is the orchestration index number, and value is an integer value used to identify the sequence value of the current service in the orchestration information.

[0027] Furthermore, the user can query or subscribe to the orchestration service execution status topic from the ESB bus through the orchestration service request execution number SessionID obtained in step S3.

[0028] Furthermore, the orchestration service execution server receives and determines the service request sent by the ESB bus using the following method:

[0029] The HTTP message transceiver module of the orchestration service execution server monitors HTTP requests from the network and determines whether the message header contains the x-rdcs and x-sindex headers. If the message header does not contain the x-rdcs and x-sindex headers, it is determined that the request message is a normal service request, that is, a normal service response thread is started; if the message header contains the x-rdcs and x-sindex headers, it is determined that the request message is an orchestration service request, that is, an orchestration service execution response thread is started.

[0030] Preferably, when executing a common service response thread, the orchestration service execution server loads the corresponding service application according to the request message and returns the result to the ESB bus;

[0031] When the orchestration service execution server executes the orchestration service execution response thread:

[0032] 1) First, use the orchestration service execution module to parse the information in the x-rdcs and x-sindex headers to obtain the orchestration information number ServiceID, the orchestration service request execution number SessionID, and the orchestration index number ServiceIndex;

[0033] 2) The orchestration service execution module then queries the local cache for orchestration information corresponding to the ServiceID based on the ServiceID. If not, it requests the orchestration information corresponding to the current ServiceID from the ESB bus through the ESB interaction module. If so, it directly proceeds to the next step.

[0034] 3) The orchestration service verification module parses and verifies the orchestration information in conjunction with the ServiceIndex to confirm whether the ServiceIndex in the orchestration information sequence is the service to be accessed. If not, the verification fails, and the ESB interaction module reports the error to the ESB bus and ends. If so, the verification passes, and the orchestration service execution module obtains the rules defined in the orchestration information for the current service, constructs the request parameter body of the current service based on the incoming request message, and then accesses the service to obtain the return result.

[0035] 4) The orchestration service execution server acts as the current orchestration work executor. Its orchestration service execution module sends a corresponding service request to the server where the next service is located based on the current service return result and orchestration information;

[0036] 5) If a normal service request is sent in 4), the corresponding service is called and the return result is obtained. The execution status is fed back to the ESB bus or the orchestration service execution status subscriber, and 4) is repeated;

[0037] 6) If the orchestration service request in 4) is sent, the corresponding service is called and the return result is obtained. The execution status is fed back to the ESB bus or the orchestration service execution status subscriber, and the current orchestration service execution response thread ends.

[0038] In order to improve the stability and real-time performance of the system, the present invention converts the traditional central orchestration service execution mode into a distributed serial orchestration service execution mode. Specifically, in the traditional central orchestration service execution mode, the ESB bus sequentially requests applications deployed on each server, generating multiple network requests across multiple levels of routing, which will cause a loss of system real-time performance. In the distributed serial orchestration service execution mode provided by the present invention, the ESB bus sends an HTTP message with a custom message header, which contains a unique orchestration information number ServiceID, an orchestration service request execution number SessionID, and The orchestration information of the orchestration index number ServiceIndex is obtained, and the orchestration service execution server can parse specific fields in the HTTP message header. Therefore, after the ESB bus sends an orchestration service request, the orchestration service execution server can replace the ESB bus to request and call the application on the server according to the orchestration rules. This model is compatible with traditional deployed service systems and fully considers the aggregation of various services in the spatial topology structure in the service orchestration under industrial scenarios. It can effectively reduce network requests on the ESB bus, reduce the number of cross-route communications, and reduce network communication time overhead and bandwidth occupancy, thereby effectively improving the stability and real-time performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a diagram of the traditional orchestration service call process;

[0040] Figure 2 This is a structural diagram of a distributed serial orchestration service execution system according to an embodiment of the present invention;

[0041] Figure 3 Schematic diagram of the orchestration service invocation process in the distributed serial orchestration service execution method according to an embodiment of the present invention;

[0042] Figure 4 This is a workflow diagram for orchestrating services of the ESB bus in the present invention;

[0043] Figure 5 This is a flowchart of a common service response thread or an orchestration service execution response thread of the orchestration service execution server starting thread A in the present invention;

[0044] Figure 6 This is a flowchart of an orchestration service execution response thread in an execution thread A of an orchestration service execution server in the present invention;

[0045] Figure 7 This is a flowchart of the execution thread B of the orchestration service execution server in the present invention;

[0046] Figure 8 Generate a distribution workflow diagram for the orchestration information of the ESB bus in the present invention. DETAILED DESCRIPTION

[0047] In order to facilitate understanding by those skilled in the art, the present invention will be further described below with reference to embodiments and drawings. The contents mentioned in the embodiments are not intended to limit the present invention.

[0048] like Figure 2 As shown, a distributed serial orchestration service execution system includes an ESB bus, two orchestration service execution servers, a common server, and a device service application with a CGI interface specification mounted under each orchestration service execution server and the common server.

[0049] The ESB bus interacts with the orchestration service execution server and regular servers via HTTP. Each orchestration service execution server and regular server interacts with its corresponding service application using the Common Gateway Interface protocol. The following describes the ESB bus, orchestration service execution server, and regular servers in detail.

[0050] ESB bus: Similar to a traditional service bus, it provides routing functions as well as service registration and orchestration. The ESB bus includes a service management module, a service orchestration management module, a service orchestration execution module, a user interaction module, and a server interaction module. The service management module is used for service registration, querying, and deletion, as well as orchestration rule setting. The service orchestration management module is used to store and manage orchestration services and assign a unique orchestration information number (ServiceID) to each orchestration service within the system. The service orchestration execution module is used to parse and load orchestration services invoked by users and send service requests to the orchestration service execution server or a regular server according to the orchestration rules. The server interaction module receives orchestration service execution results uploaded by the orchestration service execution server and categorizes and stores them according to the orchestration service request execution number (SessionID) generated by the service orchestration management module. The user interaction module provides an orchestration service query interface based on the SessionID to query the execution status of each sub-service of the current orchestration service. The ESB bus can also respond to requests from the orchestration service execution server and publish the stored or newly orchestrated orchestration information on the orchestration service execution server to the orchestration server via the server interaction module.

[0051] like Figure 4As shown, when the user requests an orchestration service from the ESB bus through the user interaction module on the client, the service orchestration execution module of the ESB bus will serve as the first orchestration work executor, first parsing the orchestration information, and then determining the type of the server where the first service to be called in the orchestration information is located. If the server where the first service to be called is located is an orchestration service execution server and participates in the orchestration execution, then an orchestration service request will be sent to the orchestration service execution server (the orchestration service request is an HTTP message including the custom message headers x-rdcs and x-sindex, and the format of x-rdcs is {"ServiceID":"xxxxx","SessionID" : "ESBKey_xxxx"}, where ServiceID is the orchestration information number, which is the unique orchestration information number generated by the ESB bus for the orchestration information; SessionID is the orchestration service request execution number, which is set in the custom message header when the ESB bus or the user constructs the orchestration service request and has temporal and spatial uniqueness. The service execution ID generated by the ESB bus starts with a specific field. The user generates the service execution ID and ensures its uniqueness; the format of x-sindex is {"ServiceIndex":"value"}, where ServiceIndex is the orchestration index number and value is an integer. Value, used to identify the sequence value of the current service in the orchestration information), complete the call of the corresponding service, and after obtaining the return result, push the current service execution status to the ESB bus, and transfer it to the orchestration service execution server to update and become the next orchestration work executor; if the server where the first service to be called in the orchestration information is located is a common server, or although it is an orchestration service execution server, it does not participate in the orchestration execution (an orchestration service execution server can have multiple service applications, it is possible that service a allows the orchestration service execution server to become the orchestration work executor, but service b does not. The reason for this difference is that some services will cause the load of the orchestration service execution server to be relatively large, deployment The performance of the platform is low, so the orchestration service execution server is not suitable to be the orchestration work executor at this time, that is, there is a situation of not participating in the orchestration execution. Whether it participates in the orchestration execution can be known from the orchestration information). Then, a normal service request is sent to the server (a normal service request is an HTTP message without the custom message headers x-rdcs and x-sindex). After obtaining the return result, the current service execution status is pushed to the ESB bus. The ESB bus then processes the next to-be-called service in the aforementioned manner until an orchestration service request is sent. At this time, the orchestration service execution server that receives the orchestration server request is updated to become the next orchestration work executor.

[0052] Ordinary server: Use Apache HTTP server, which is an open source network server used to send and receive HTTP messages and service application call responses. It can parse user request messages sent via HTTP, support various service application standard protocol specifications to communicate with the target service application, and return the processing results through the HTTP protocol after obtaining the processing results.

[0053] The orchestration service execution server has the basic functions of a traditional HTTP server, but it can also parse specific fields in the HTTP message header to obtain the orchestration service information to be loaded, execute according to the orchestration information, and provide feedback on the current service execution status. This is the biggest difference between it and ordinary servers. Therefore, it can replace the ESB bus as the orchestration work executor. Based on the type of server where the service to be called is located, it sends the corresponding service request to the server to be called to implement the corresponding service call. The orchestration service execution server includes an HTTP messaging module, an ESB interaction module, an orchestration service verification module, and an orchestration service execution module. The HTTP messaging module is used to receive and respond to HTTP requests and determine whether the request message is a regular service request or an orchestration service request. The ESB interaction module is used to communicate with the ESB bus to obtain orchestration information and provide feedback on the current orchestration information execution status. The orchestration service verification module is used to verify the compliance of the current service request. The orchestration service execution module is used to call the service program according to the orchestration rules and provide feedback on the current request execution status to the ESB bus.

[0054] After the orchestration service execution server is started, there are two threads: thread A and thread B. Their working process is as follows.

[0055] Thread A: Figure 5 As shown, the HTTP message transceiver module monitors HTTP requests from the network and determines whether the message header contains x-rdcs and x-sindex headers. If there are no x-rdcs and x-sindex headers in the message header, it is determined that the request message is a normal service request, that is, the normal service response thread is started, and the corresponding service application is loaded according to the request message to obtain the result and then returned to the ESB bus; if there are x-rdcs and x-sindex headers in the message header, it is determined that the request message is an orchestration service request, that is, the orchestration service execution response thread is started, as shown in FIG. Figure 6 As shown:

[0056] 1) The HTTP message transceiver module parses the information in the x-rdcs and x-sindex headers, obtains the orchestration information number ServiceID, the orchestration service request execution number SessionID, and the orchestration index number ServiceIndex, and responds to the sender that the message has been received.

[0057] 2) The HTTP message transceiver module then queries whether the orchestration information of the ServiceID is cached locally based on the ServiceID. If not, it requests the orchestration information corresponding to the current ServiceID from the ESB bus through the ESB interaction module; if so, it directly goes to the next step.

[0058] 3) The orchestration service verification module parses and verifies the orchestration information in conjunction with the ServiceIndex to confirm whether the ServiceIndex in the orchestration information sequence is the current service to be accessed. If not, the verification fails, and the ESB interaction module reports the error to the ESB bus and ends; if so, the verification passes, and the orchestration service execution module obtains the rules defined in the orchestration information of the current service, combines the incoming request message to construct the request parameter body of the current service, and then accesses the service to obtain the return result.

[0059] 4) The orchestration service execution server, as the current executor of the orchestration work, sends a corresponding service request to the server to be called based on the type of server where the next service to be called is located, and based on the current service return result and orchestration information to implement the call of the corresponding service.

[0060] 5) If the server where the next service to be called in 4) is located is a common server, or is an orchestration service execution server but does not participate in orchestration execution, a common service request is sent to the server where the service to be called is located. The server that receives the common service request calls the corresponding service application. The ESB interaction module of the orchestration service execution server, which is the current executor of the orchestration work, obtains the return result and feeds back the execution status to the ESB bus or the orchestration service execution status subscriber, then repeats 4).

[0061] 6) If the server hosting the next service to be called in 4) is an orchestration service execution server and is participating in the orchestration execution, an orchestration service request is sent to the orchestration service execution server. The server receiving the orchestration service request invokes the corresponding service. The ESB interaction module of the orchestration service execution server, currently executing the orchestration task, obtains the return result and reports the execution status to the ESB bus or the orchestration service execution status subscriber, including the current orchestration information number, orchestration service request execution number, and orchestration index number. This completes the response to an orchestration service request on the orchestration service execution server currently executing the orchestration task.

[0062] Thread B: If Figure 7 As shown, thread B is used to interact with the ESB bus and other servers. The process is as follows Figure 7As shown, first connect to the ESB bus, request the ESB bus, pull the orchestration information related to this server and store it locally, then start the service orchestration information subscription thread, listen to the ESB bus to publish new orchestration messages, and when receiving the new orchestration information published by the ESB bus, it will be stored locally.

[0063] For the aforementioned distributed serial orchestration service execution system, if the orchestration service requested by the client is required to first call Figure 2 In the example, the service application under the orchestration service execution server 1 is called, the service application under the ordinary server 2 is called, and finally the service application under the orchestration service execution server 3 is called. Both the orchestration service execution server 1 and the orchestration service execution server 3 participate in the orchestration execution. The working principle of the distributed serial orchestration service execution system refers to the distributed serial orchestration service execution method in this embodiment, which specifically includes the following:

[0064] Step S1: Mount the device service application to Figure 3 The orchestration service execution server and the common server are shown, and the information of the device service application is registered to the ESB bus, and the orchestration service execution server is connected to the ESB bus.

[0065] Step S2: Figure 8 As shown, users use the ESB bus to orchestrate registered services (combining fine-grained services into larger-grained services to provide services externally), forming orchestration information that includes the service call sequence, the relationship between the previous and next service parameters, custom parameters, the server type, whether the server participates in the orchestration execution, and the orchestration information version. The ESB bus assigns a unique orchestration information number ServiceID to the orchestration information and synchronizes it to the orchestration service execution server that mounts the called service in the orchestration information.

[0066] Step S3: Figure 3 As shown, the user initiates a request to the ESB bus to call the orchestration service. The ESB bus returns the SessionID of the orchestration service request to the user. The ESB bus becomes the first orchestration work executor. According to the orchestration rules corresponding to the requested service, it confirms that the server where the first service to be called is located is orchestration service execution server 1, and orchestration service execution server 1 participates in the orchestration execution. Therefore, the ESB bus sends an orchestration service request to orchestration service execution server 1, and orchestration service execution server 1 is updated to become the second orchestration work executor.

[0067] As the second orchestration work executor, orchestration service execution server 1 starts the orchestration service execution response thread in the aforementioned thread A:

[0068] The HTTP message transceiver module parses the information in the x-rdcs and x-sindex headers, obtains the orchestration information number ServiceID, the orchestration service request execution number SessionID and the orchestration index number ServiceIndex, and responds to the ESB bus that the message has been received.

[0069] The HTTP message transceiver module then queries whether the orchestration information of the ServiceID is cached locally based on the ServiceID. If not, it requests the orchestration information corresponding to the current ServiceID from the ESB bus through the ESB interaction module; if so, it directly goes to the next step.

[0070] The orchestration service verification module parses and verifies the orchestration information in conjunction with the ServiceIndex to confirm whether the ServiceIndex in the orchestration information sequence is the current service to be accessed. If not, the verification fails, and the ESB interaction module reports the error to the ESB bus and ends; if so, the verification passes, and the orchestration service execution module obtains the rules defined in the orchestration information of the current service, constructs the request parameter body of the current service in combination with the incoming request message, and then accesses the first service, obtains the return result, and feeds back the execution status of the first service to the ESB bus, pushing the current orchestration information number, orchestration service request execution number, and orchestration index number execution status.

[0071] As the second orchestration work executor, orchestration service execution server 1 determines that the server where the second service is located is ordinary server 2 based on the current service return result and orchestration information. Therefore, it sends an ordinary service request to ordinary server 2. Ordinary server 2 calls the corresponding service application. The orchestration service execution module of orchestration service execution server 1 obtains the return result and feeds back the execution status of the second service to the ESB bus through the ESB interaction module, pushing the current orchestration information number, orchestration service request execution number, and orchestration index number execution status.

[0072] Orchestration Service Execution Server 1 then continues as the second orchestration worker. Based on the current service response and the orchestration information, it determines that the server hosting the third service is Orchestration Service Execution Server 3, and that Orchestration Service Execution Server 3 is participating in the orchestration execution. Therefore, Orchestration Service Execution Server 1 sends an orchestration service request to Orchestration Service Execution Server 3. Orchestration Service Execution Server 3 invokes the corresponding service application. The Orchestration Service Execution Module of Orchestration Service Execution Server 1 receives the response and, through the ESB interaction module, reports the execution status of the third service to the ESB bus. It also pushes the current orchestration information number, orchestration service request execution number, and orchestration index number execution status. The entire orchestration service response is now complete.

[0073] It is not difficult to see from the above process of calling services that after each service is called and the result is obtained, the current orchestration work executor will send the current service execution status to the ESB bus, and the ESB bus will then distribute it to call status followers, or use topic publishing to allow followers to subscribe and receive.

[0074] It is worth noting that if, after calling the third service in the aforementioned distributed serial orchestration service execution method, a fourth service deployed on orchestration service execution server 4 needs to be called, and orchestration service execution server 4 does not participate in the orchestration execution, then after orchestration service execution server 3 calls the third service, orchestration service execution server 3 then acts as the third orchestration work executor and sends a normal service request to orchestration service execution server 4. Orchestration service execution server 4 then calls the fourth service, thus completing the entire orchestration service response. If there are N services to be called after the fourth service, the subsequent calling method is the same as the aforementioned calling method. The orchestration service execution servers that receive the orchestration service requests will become the current orchestration work executors in the order in which they receive the requests, and will call the corresponding services in sequence until all services have been called.

[0075] In summary, in order to improve the stability and real-time performance of the system, the present invention converts the traditional central orchestration service execution mode into a distributed serial orchestration service execution mode. Specifically, Figure 1 As shown, in the traditional central orchestration service execution mode, the ESB bus sequentially requests and calls the applications deployed on each server, generating multiple network requests across multiple levels of routing, which will cause a loss of system real-time performance. In the distributed serial orchestration service execution mode provided by the present invention, the ESB bus sends an HTTP message with a custom message header. The message header contains orchestration information such as a unique orchestration information number ServiceID, an orchestration service request execution number SessionID, and an orchestration index number ServiceIndex. The orchestration service execution server can parse specific fields in the HTTP message header. Therefore, after the ESB bus sends the orchestration service request, the orchestration service execution server can replace the ESB bus to request and call the application on the server according to the orchestration rules (such as Figure 3 This model is compatible with traditional deployed service systems and fully considers the aggregation of various services in the spatial topology structure in the service orchestration under industrial scenarios. It can effectively reduce network requests on the ESB bus, reduce the number of cross-route communications, and reduce network communication time overhead and bandwidth occupancy, thereby effectively improving the stability and real-time performance of the system.

[0076] The above embodiments are preferred implementation schemes of the present invention. In addition, the present invention can also be implemented in other ways. Any obvious replacement without departing from the concept of the present technical solution is within the scope of protection of the present invention.

[0077] In order to make it easier for ordinary technicians in this field to understand the improvements of the present invention over the prior art, some drawings and descriptions of the present invention have been simplified, and for the sake of clarity, some other elements are omitted in this application document. Ordinary technicians in this field should realize that these omitted elements may also constitute the content of the present invention.

Claims

1. A distributed serial orchestration service execution method, characterized in that: The steps include: Step S1: Mount the device service application to the orchestration service execution server and the common server, register the device service application information to the ESB bus, and establish a connection between the orchestration service execution server and the ESB bus; Step S2: The user orchestrates the registered services using the ESB bus to form orchestration information. The ESB bus assigns a unique orchestration information number ServiceID to the orchestration information and synchronizes it to the orchestration service execution server that mounts the called service in the orchestration information. Step S3: The user initiates a request to the ESB bus to call the orchestration service. The ESB bus returns the SessionID of this orchestration service request to the user. The ESB bus becomes the first orchestration work executor. The orchestration work executor sends a corresponding service request to the server where the service to be called is located according to the type of the server where the service to be called is located, and implements the call of the corresponding service. If the server where the service to be called is located is an orchestration service execution server and participates in the orchestration execution, the orchestration work executor sends an orchestration service request to the orchestration service execution server to complete the call of the corresponding service. The orchestration service execution server is updated to become the next orchestration work executor. If the server where the service to be called in the orchestration information is located is a common server, or is an orchestration service execution server but does not participate in the orchestration execution, the orchestration work executor sends a common service request to the server where the service to be called is located to complete the call of the corresponding service. The orchestration work executor then processes the next service call until it sends an orchestration service request once, and then the orchestration service execution server that receives the orchestration server request at this time is updated to become the next orchestration work executor; The first orchestration service execution server that receives the orchestration service request becomes the second orchestration work executor, and so on. The orchestration service execution server that receives the orchestration service request becomes the N+1th orchestration work executor, until all services in the orchestration information are called. After each orchestration work executor calls a service and obtains the result, it pushes the current service execution status to the ESB bus, and the ESB bus distributes it to call status followers, or uses topic publishing for followers to subscribe and receive.

2. The distributed serial orchestration service execution method according to claim 1, wherein: In step S3, the user knows the orchestration information and confirms that the server where the first service to be called in the orchestration information is located is the orchestration service execution server and participates in the orchestration execution. The user can replace the ESB bus to independently construct the orchestration service request and send it to the orchestration service execution server.

3. The distributed serial orchestration service execution method according to claim 2, wherein: The orchestration information formed in step S2 includes the service call sequence, the relationship between the previous and next service parameters, custom parameters, the server type, whether the server participates in the orchestration execution, and the orchestration information version.

4. The distributed serial orchestration service execution method according to claim 3, wherein: The orchestration service request is an HTTP message including custom headers x-rdcs and x-sindex. The format of x-rdcs is {"ServiceID":"xxxxx", "SessionID":"ESBKey_xxxx"}, where ServiceID is the orchestration information number, which is the unique orchestration information number generated by the ESB bus for the orchestration information in step S2; SessionID is the orchestration service request execution number, which is set in the custom header when the ESB bus or the user constructs the orchestration service request and has temporal and spatial uniqueness; the format of x-sindex is {"ServiceIndex":"value"}, where ServiceIndex is the orchestration index number, and value is an integer value used to identify the sequence value of the current service in the orchestration information.

5. The distributed serial orchestration service execution method according to claim 4, characterized in that: The user can query or subscribe to the orchestration service execution status topic from the ESB bus through the orchestration service request execution number SessionID obtained in step S3.

6. The distributed serial orchestration service execution method according to claim 5, characterized in that: The orchestration service execution server receives and determines the service request sent by the ESB bus using the following method: The HTTP message transceiver module of the orchestration service execution server monitors HTTP requests from the network and determines whether the message header contains the x-rdcs and x-sindex headers. If the message header does not contain the x-rdcs and x-sindex headers, it is determined that the request message is a normal service request, that is, a normal service response thread is started; if the message header contains the x-rdcs and x-sindex headers, it is determined that the request message is an orchestration service request, that is, an orchestration service execution response thread is started.

7. The distributed serial orchestration service execution method according to claim 6, wherein: When executing a common service response thread, the orchestration service execution server loads the corresponding service application according to the request message and returns the result to the ESB bus; When the orchestration service execution server executes the orchestration service execution response thread: 1) First, use the orchestration service execution module to parse the information in the x-rdcs and x-sindex headers to obtain the orchestration information number ServiceID, the orchestration service request execution number SessionID, and the orchestration index number ServiceIndex; 2) The orchestration service execution module then queries the local cache for orchestration information corresponding to the ServiceID based on the ServiceID. If not, it requests the orchestration information corresponding to the current ServiceID from the ESB bus through the ESB interaction module. If so, it directly proceeds to the next step. 3) The orchestration service verification module parses and verifies the orchestration information in conjunction with the ServiceIndex to confirm whether the ServiceIndex in the orchestration information sequence is the service to be accessed. If not, the verification fails, and the ESB interaction module reports the error to the ESB bus and ends. If yes, the verification is successful. The orchestration service execution module obtains the rules defined in the orchestration information of the current service, builds the request parameter body of the current service based on the incoming request message, and then accesses the service to obtain the return result. 4) The orchestration service execution server acts as the current orchestration work executor. Its orchestration service execution module sends a corresponding service request to the server where the next service is located based on the current service return result and orchestration information; 5) If a normal service request is sent in 4), the corresponding service is called and the result is returned. The execution status is fed back to the ESB bus or the orchestration service execution status subscriber, and 4 is repeated. 6) If the orchestration service request in 4) is sent, the corresponding service is called and the return result is obtained. The execution status is fed back to the ESB bus or the orchestration service execution status subscriber, and the current orchestration service execution response thread ends.

8. A distributed serial orchestration service execution system, characterized by: The system adopts the distributed serial orchestration service execution method according to any one of claims 1 to 7 to perform service orchestration, the system comprising an ESB bus, multiple orchestration service execution servers, and multiple ordinary servers, the ESB bus being connected to the orchestration service execution servers and the ordinary servers, respectively, and the orchestration service execution servers and the ordinary servers being mounted with device service applications; The ESB bus includes a service management module, a service orchestration management module, a service orchestration execution module, a user interaction module, and a server interaction module; The service management module is used for service registration, query, deletion, and orchestration rule setting; The service orchestration management module is used to store and manage orchestration services and assign a unique orchestration information number ServiceID in the system to each orchestration service; The service orchestration execution module is used to parse and load the orchestration service called by the user, and send a service request to the orchestration service execution server or the ordinary server according to the orchestration rules; The user interaction module is used to communicate with the client to facilitate user orchestration of service calls and status inquiries; The server interaction module establishes a connection with the orchestration service execution server to send the orchestration rule information requested by the orchestration service execution server and receive the orchestration service execution status information fed back by the orchestration service execution server; The common server is an HTTP server for sending and receiving HTTP messages and serving application call responses; The orchestration service execution server includes an HTTP message sending and receiving module, an ESB interaction module, an orchestration service verification module, and an orchestration service execution module; The HTTP message transceiver module is used to receive and respond to HTTP requests and determine whether the request message is a normal service request or an orchestration service request; The ESB interaction module is used to communicate with the ESB bus, obtain orchestration information, and feedback the current execution status of the orchestration information; The orchestration service verification module is used to verify the compliance of the current service request; The orchestration service execution module is used to call the service program according to the orchestration rules and feed back the current request execution status to the ESB bus.

9. The distributed serial orchestration service execution system according to claim 8, wherein: The ESB interaction module of the orchestration service execution server reads the ESB bus address information in the server configuration file, actively establishes contact with the ESB bus, and obtains the synchronized ESB bus orchestration library by subscription or active request; The ESB interaction module feeds back the execution status of the service to be accessed in the orchestration information to the ESB bus according to the execution result of the orchestration service execution module.

Citation Information

Patent Citations

  • Application program automatic publishing method based on process arrangement

    CN110908698A

  • Dynamic routing arrangement method and system realized based on Spring Cloud Gateway

    CN113794636A