Network service description document generation method and apparatus, electronic device, and storage medium

Abstract

This disclosure relates to the field of communication protocol processing technology, and provides a method, apparatus, electronic device, and storage medium for generating network service description documents. The method includes: identifying and processing a Hypertext Transfer Protocol (HTTP) request to obtain a network service description document template; extracting the identifier code from the HTTP request to obtain the gateway address corresponding to the HTTP request; concatenating the gateway address and a preset service path to obtain a target service endpoint address; and performing address injection processing on the network service description document template based on the target service endpoint address to obtain a target network service description document. This improves the smoothness of migration between heterogeneous protocol systems, enhances the stateless characteristics and scalability of the simulated service in the network service description document, ensures the security and controllability of the migration process and business continuity, improves the accuracy of business request routing, enhances the clarity of the migration target, and increases the success rate of migration calls.

Description

Technical Field

[0001] This disclosure relates to the field of communication protocol processing technology, and in particular to a method, apparatus, electronic device, and storage medium for generating network service description documents. Background Technology

[0002] During the upgrade of an enterprise's core system, when replacing the traditional Simple Object Access Protocol (SOAP) Web Service interface with a Representational State Transfer Application Programming Interface (RESTful API), the heterogeneity of the old and new protocols leads to the inability to connect to the backend. In existing technologies, a general application programming interface (API) gateway is usually used as a unified entry point, hoping to bridge the upstream Simple Object Access Protocol (SOAP) client and the new backend service through its protocol conversion function, thereby achieving transparent migration of the upstream system. However, general gateways generally focus on the conversion and routing of business requests and cannot correctly handle the upstream system's request to obtain the service contract, i.e., the Web Services Description Language (WSDL) document. This causes the upstream system to fail to make calls because it cannot obtain a valid WSDL, and the migration goal fails.

[0003] It is evident that existing technologies suffer from problems such as incomplete compatibility of general API gateways with WSDL documents and deviations in the service address pointing to statically pre-built WSDL files, resulting in poor accuracy of business request routing, unclear migration targets, and low call success rates. Summary of the Invention

[0004] In view of this, embodiments of this disclosure provide a method, apparatus, electronic device, and storage medium for generating network service description documents, in order to solve the problems in the prior art where general API gateways cannot be fully compatible with WSDL documents and the service address pointing to statically preset WSDL files is inaccurate, resulting in poor routing accuracy of business requests, unclear migration targets, and low call success rates.

[0005] A first aspect of this disclosure provides a method for generating a network service description document, comprising: identifying a Hypertext Transfer Protocol (HTTP) request to obtain a network service description document template; extracting an identifier from the HTTP request to obtain a gateway address corresponding to the HTTP request; concatenating the gateway address with a preset service path to obtain a target service endpoint address; and performing address injection processing on the network service description document template based on the target service endpoint address to obtain a target network service description document.

[0006] In some embodiments, the process of identifying a Hypertext Transfer Protocol (HTTP) request to obtain a Network Service Description Document (NSD) template includes: performing request parsing on the HTTP request to obtain a Uniform Resource Identifier (URI); performing path matching on the URI to obtain a path matching result; performing response capture on the HTTP request based on the path matching result to obtain initial NSD content; and caching the initial NSD content to obtain the NSD template.

[0007] In some embodiments, the process of extracting the identifier code from the Hypertext Transfer Protocol (HTTP) request to obtain the gateway address corresponding to the HTTP request includes: performing header parsing on the HTTP request to obtain HTTP header data; performing key-value extraction on the HTTP header data to obtain the system identifier code; and performing validity verification on the system identifier code to obtain the gateway address.

[0008] In some embodiments, before identifying and processing the Hypertext Transfer Protocol (HTTP) request to obtain a network service description document template, the method further includes: performing entry address routing consistency processing on the upstream call initial request to obtain an initial HTTP request; performing header injection processing on the initial HTTP request to obtain a transfer protocol request to be forwarded; and performing target service routing processing on the transfer protocol request to be forwarded to obtain an HTTP request.

[0009] In some embodiments, address injection processing is performed on the network service description document template based on the target service endpoint address to obtain the target network service description document, including: performing placeholder positioning processing on the network service description document template to obtain address placeholder position data; performing string replacement processing on the address placeholder position data based on the target service endpoint address to obtain the target document content; and performing response format setting processing on the target document content to obtain the target network service description document.

[0010] In some embodiments, concatenating the gateway address and a preset service path to obtain the target service endpoint address includes: performing protocol format verification on the gateway address to obtain a standardized gateway address; performing path validity verification on the preset service path to obtain a valid service path; and concatenating the standardized gateway address and the valid service path to obtain the target service endpoint address.

[0011] In some embodiments, the Hypertext Transfer Protocol (HTTP) request response capture processing based on the path matching result is used to obtain the initial network service description document content, including: performing filter chain allow processing on the HTTP request based on the path matching result to obtain the initial response object; performing response object wrapping processing on the initial response object to obtain a custom response wrapper; and performing output stream interception processing on the initial response object based on the custom response wrapper to obtain the initial network service description document content.

[0012] A second aspect of this disclosure provides a network service description document generation apparatus, comprising: a first processing module for identifying and processing a Hypertext Transfer Protocol (HTTP) request to obtain a network service description document template; a second processing module for extracting an identifier from the HTTP request to obtain a gateway address corresponding to the HTTP request; a third processing module for concatenating the gateway address and a preset service path to obtain a target service endpoint address; and a fourth processing module for performing address injection processing on the network service description document template based on the target service endpoint address to obtain a target network service description document.

[0013] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0014] A fourth aspect of this disclosure provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0015] The beneficial effects of this disclosed embodiment compared with the prior art are as follows: By identifying and processing the Hypertext Transfer Protocol (HTTP) request, a Network Service Description Document (NSDDoc) template is obtained; by extracting the identifier code of the HTTP request, the gateway address corresponding to the HTTP request is obtained; by concatenating the gateway address and the preset service path, the target service endpoint address is obtained; and by performing address injection processing on the NSDDoc template based on the target service endpoint address, the target NSDDoc is obtained. This improves the transparency and smoothness of migration between heterogeneous protocol systems, enhances the stateless characteristics and scalability of the NSDDoc simulated service, improves the efficiency of system upgrades, reduces coordination costs and business interruption risks, ensures the security and controllability of the migration process and business continuity, improves the accuracy of business request routing, enhances the clarity of the migration target, and increases the success rate of migration calls. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure; Figure 2 This is a flowchart illustrating a method for generating a network service description document according to an embodiment of this disclosure; Figure 3 This is a flowchart illustrating another method for generating network service description documents provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the structure of a network service description document generation device provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, so as to provide a thorough understanding of the embodiments of this disclosure. However, those skilled in the art will understand that this disclosure may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this disclosure with unnecessary detail.

[0019] It should be noted that the user information (including but not limited to terminal device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0020] A method and apparatus for generating a network service description document according to an embodiment of the present disclosure will now be described in detail with reference to the accompanying drawings.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure. The application scenario may include terminal devices 1, 2, and 3, server 4, and network 5.

[0022] Terminal devices 1, 2, and 3 can be hardware or software. When terminal devices 1, 2, and 3 are hardware, they can be various electronic devices with displays and supporting communication with server 4, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 1, 2, and 3 are software, they can be installed in the aforementioned electronic devices. Terminal devices 1, 2, and 3 can be implemented as multiple software programs or software modules, or as a single software program or software module; this disclosure does not limit this. Furthermore, various applications can be installed on terminal devices 1, 2, and 3, such as data processing applications, instant messaging tools, social platform software, search applications, shopping applications, etc.

[0023] Server 4 can be a server that provides various services, such as a backend server that receives requests sent by terminal devices with which it has established communication connections. This backend server can receive and analyze the requests sent by the terminal devices and generate processing results. Server 4 can be a single server, a server cluster consisting of several servers, or a cloud computing service center. This disclosure embodiment does not limit this.

[0024] It should be noted that server 4 can be either hardware or software. When server 4 is hardware, it can be various electronic devices that provide various services to terminal devices 1, 2, and 3. When server 4 is software, it can be multiple software programs or software modules that provide various services to terminal devices 1, 2, and 3, or it can be a single software program or software module that provides various services to terminal devices 1, 2, and 3. This disclosure does not limit the scope of the embodiments.

[0025] Network 5 can be a wired network using coaxial cable, twisted pair, and fiber optic connection, or it can be a wireless network that enables interconnection of various communication devices without wiring, such as Bluetooth, Near Field Communication (NFC), and Infrared. This disclosure does not limit the scope of the network.

[0026] Users can establish a communication connection with server 4 via network 5 through terminal devices 1, 2, and 3 to receive or send information. Specifically, server 4 can obtain Hypertext Transfer Protocol (HTTP) requests through terminal devices 1, 2, and 3; obtain a network service description document template by identifying and processing the HTTP request; extract the identifier code from the HTTP request to obtain the gateway address corresponding to the HTTP request; concatenate the gateway address and a preset service path to obtain the target service endpoint address; and perform address injection processing on the network service description document template based on the target service endpoint address to obtain the target network service description document.

[0027] It should be noted that the specific types, quantities, and combinations of terminal devices 1, 2, and 3, server 4, and network 5 can be adjusted according to the actual needs of the application scenario, and this disclosure embodiment does not impose any restrictions on this.

[0028] Figure 2 This is a flowchart illustrating a method for generating network service description documents according to an embodiment of this disclosure. Figure 2 The method for generating network service description documents can be provided by Figure 1 The server executes this. For example... Figure 2 As shown, the method for generating the network service description document includes: S201, Identify and process the Hypertext Transfer Protocol request to obtain a network service description document template.

[0029] Specifically, a Hypertext Transfer Protocol (HTTP) request can be a network request that conforms to the HTTP specification. The HTTP request may include components such as a request line, request headers, and request body, which are not limited here. The HTTP request may be a query request sent by the upstream calling system to the gateway layer to obtain a network service description document, which can trigger the subsequent document generation process. The HTTP request may be initiated by the upstream calling system according to its business needs and sent to the gateway layer, which serves as the unified entry point.

[0030] The identification process can be a data processing procedure that analyzes and judges the received Hypertext Transfer Protocol (HTTP) requests to determine their type and purpose. This identification process can be used to distinguish between ordinary business requests and specific network service description document (WSD) query requests, thereby determining whether to initiate dynamic document generation logic. The identification process can be executed by a filter component deployed in the WSD simulation service, which can intercept and inspect all requests at the gateway layer.

[0031] A network service description document template can be a document file that includes a service interface description but uses service address information as a placeholder. The network service description document template can serve as the basis for dynamically generating target network service description documents. The network service description document template can include fixed contract content such as service operations and message structures.

[0032] This application embodiment identifies and processes Hypertext Transfer Protocol (HTTP) requests. A filter component deployed at the gateway layer intercepts and inspects the requests, using Uniform Resource Identifier (URI) path matching to determine whether they are network service description document (WSD) query requests, and whether to initiate dynamic document generation logic. Upon successful identification, the network service framework returns the original document containing service operation definitions, message structure, and address placeholders, thus obtaining a WSD template. This enhances the accuracy and automation of HTTP request type identification, improves the efficiency and accuracy of WSD template acquisition, and lays a standardized data foundation for subsequent dynamic generation of target documents.

[0033] For example, in the upgrade of an enterprise financial accounting system, the upstream calling system can be a voucher push system. This voucher push system can be developed based on the network service description language contract of the old financial accounting system, and its client code has the service address of the old system embedded in it. When the enterprise starts the financial accounting system upgrade project, it can replace the old financial accounting system based on Simple Object Access Protocol with a new system based on Representational State Transition Architecture. The voucher push system can initiate a network service description document query request to its configured gateway layer unified entry address. For example, it can send a Hypertext Transfer Protocol request with the request line containing "GET / webservice / ncWebService.wsdl". After receiving the request, the gateway layer identifies it as a request from the group to which the voucher push system belongs, and can inject a system identifier code (which can be "ncSystemCode:") into the Hypertext Transfer Protocol header when forwarding it. https: / / gateway.xxxxx.com / to-group-a; After the filter component in the Web Service Description Document (WSD) simulation service intercepts the Hypertext Transfer Protocol (HTTP) request, it can perform path matching on the Uniform Resource Identifier (URI) to determine if " / webservice / ncWebService.wsdl" matches the predefined Web Service Description Document (WSD) request path " / webservice / ncWebService.wsdl". If so, the request can be allowed to continue. Furthermore, the response wrapper can capture the original Web Service Description Document (WSD) template content returned by the Web Service framework. This template content can include service operation definitions, message structures, and the address placeholder "locationUrl", thus obtaining the Web Service Description Document (WSD) template.

[0034] S202, extract the identifier code from the Hypertext Transfer Protocol request to obtain the gateway address corresponding to the Hypertext Transfer Protocol request.

[0035] Specifically, the identifier extraction process can be a data processing procedure that parses and obtains specific information from a Hypertext Transfer Protocol (HTTP) request. This identifier extraction process can be used to extract specific identifier fields from the HTTP header information of the HTTP request, thereby providing routing information for the subsequent dynamic construction of service addresses. The identifier extraction process can be executed by a filter component deployed in the Network Service Description Document (NSFD) simulation service. This filter component can parse and read the HTTP header of the HTTP request to obtain the gateway address corresponding to the HTTP request.

[0036] The gateway address can be the network access address for the gateway layer to provide services to the outside world. The gateway address can be the result of the identification code extraction process. The gateway address can be used as the target address of the service endpoint in the dynamically generated network service description document, thereby ensuring that the business requests of the upstream calling system can be correctly routed to the gateway layer.

[0037] This application embodiment extracts the identifier code from the Hypertext Transfer Protocol (HTTP) request. A filter component deployed in the Network Service Description Document (NSD) simulation service parses the HTTP header information and extracts a specific identifier code field pre-injected by the gateway layer to obtain the gateway address corresponding to the HTTP request. This decouples the gateway routing information transmission from the NSD contract generation process, improves scalability and deployment flexibility, and provides a routing foundation for the subsequent dynamic construction of complete service endpoint addresses.

[0038] For example, in the above application scenario, a Hypertext Transfer Protocol (HTTP) request containing "GET / webservice / ncWebService.wsdl" can be sent. Upon receiving this request, the gateway layer identifies it as a request from the group to which the credential push system belongs, and can inject a system identifier (e.g., "ncSystemCode: https: / / gateway.xxxxx.com / to-group-a") into the HTTP header during forwarding. When the filter component in the Web Service Description Document (WSD) simulation service intercepts this HTTP request, it can call the request object interface to parse the HTTP header, read the identifier field, and extract the string "https: / / gateway.xxxxx.com / to-group-a". This string is the gateway address obtained through identifier extraction, thus revealing the gateway address corresponding to the HTTP request.

[0039] S203 concatenates the gateway address and the preset service path to obtain the target service endpoint address.

[0040] Specifically, the preset service path can be a fixed Uniform Resource Identifier path fragment defined in the Network Service Description Document Simulation Service and corresponding to the actual backend business interface. The preset service path can serve as a fixed logic for identifying a specific service endpoint. The preset service path can be pre-set by the Network Service Description Document Simulation Service based on its internal configuration and business interface definition.

[0041] The concatenation process can be a data processing procedure that connects the gateway address string with the preset service path string based on the Uniform Resource Locator (URL) specification. This concatenation process can be used to combine differentiated configuration information from the gateway layer with the unified business logic information within the Network Service Description Document (NSD) simulation service, thereby generating a complete and accessible service endpoint address. The concatenation process can be performed by a filter component deployed in the NSD simulation service, which can perform string concatenation operations on the gateway address and the preset service path to obtain the target service endpoint address.

[0042] The target service endpoint address can be a complete service access address formed by concatenation and can be written into the service address field of the customized network service description document. The target service endpoint address can be used to characterize the correct gateway entry address to which the Simple Object Access Protocol client of the upstream calling system should send the request when making subsequent business request calls.

[0043] This embodiment of the application concatenates the gateway address and the preset service path. The filter component deployed in the Network Service Description Document Simulation Service performs the string concatenation operation, dynamically combining the differentiated configuration information of the gateway layer with the unified business logic information within the Network Service Description Document Simulation Service to obtain the target service endpoint address. This achieves the decoupling and dynamic combination of gateway configuration information and the business logic of the Network Service Description Document Simulation Service; enhances the stateless characteristics and horizontal scalability of the Network Service Description Document Simulation Service; and improves scalability and maintainability.

[0044] For example, based on the aforementioned application scenario, after the filter component in the Network Service Description Document Simulation Service intercepts the Hypertext Transfer Protocol (HTTP) request, it can extract the gateway address, which can be "https: / / gateway.xxxxx.com / to-group-a", from the HTTP header of the HTTP request, and can read the preset service path " / webservice / synBasedoc" from the internal configuration. The filter component can perform concatenation processing, joining the gateway address with the preset service path to generate the target service endpoint address, which can be "https: / / gateway.xxxxx.com / to-group-a / webservice / synBasedoc". This target service endpoint address can be used to characterize the correct gateway entry point that the credential push system should use when subsequently calling the credential push service, thus obtaining the target service endpoint address.

[0045] S204, perform address injection processing on the network service description document template based on the target service endpoint address to obtain the target network service description document.

[0046] Specifically, address injection processing can be a data processing procedure that dynamically modifies the content of a document. This address injection processing can be used to replace address placeholders in the network service description document template with dynamically constructed target service endpoint addresses, thereby enabling document customization. Address injection processing can be executed by a filter component deployed in the network service description document simulation service, which can perform string replacement operations on the network service description document template.

[0047] The target network service description document can be a document generated after address injection processing. This target network service description document can include the correct and complete service endpoint address. This target network service description document can be returned to the upstream calling system for its Simple Object Access Protocol (SOP) client to parse and initiate subsequent business requests based on the correct address in it.

[0048] This application embodiment performs address injection processing on the network service description document template based on the target service endpoint address. A filter component deployed in the network service description document simulation service performs a string replacement operation, replacing the address placeholders with the dynamically constructed target service endpoint address to obtain the target network service description document. This enables on-demand dynamic customization of the network service description document; ensures the accuracy of the contract and the consistency of the gateway routing configuration; avoids call failures caused by address errors; and improves the reliability of transparent migration of upstream systems with zero modifications.

[0049] For example, based on the above application scenario, the target service endpoint address can be "https: / / gateway.xxxxx.com / to-group-a / webservice / synBasedoc"; the filter component can obtain the network service description document template returned by the network service framework, where the service address position can be the placeholder "locationUrl"; the filter component can perform address injection processing, replacing all "locationUrl" in the network service description document template with the aforementioned target service endpoint address, generating the target network service description document, which can be returned to the credential push system through the gateway layer. After the Simple Object Access Protocol (SAP) client parses the document, it can initiate subsequent credential push service requests to the correct gateway address, thereby obtaining the target network service description document.

[0050] According to the technical solution provided in this disclosure, Hypertext Transfer Protocol (HTTP) requests are identified and processed. A gateway layer filter intercepts and checks the request, and a Uniform Resource Identifier (URI) path matching method is used to determine if it is a Network Service Description Document (NSDocument) query request. If the identification is successful, the Network Service Framework returns an NSD document template containing service operation definitions, message structures, and address placeholders. The HTTP request is then processed to extract an identifier code. A filter component parses the HTTP header information and extracts a specific identifier code field pre-injected by the gateway layer to obtain the gateway address. The gateway address and a preset service path are concatenated, and the target service endpoint address is dynamically obtained through string concatenation. The target service endpoint address is injected into the network service description document template. A string replacement operation replaces address placeholders in the template with the target service endpoint address, generating the target network service description document. This enhances the accuracy and automation of Hypertext Transfer Protocol request type identification; decouples the gateway routing information transmission from the network service description document contract generation process; improves the stateless nature and horizontal scalability of the network service description document simulating the service; ensures the accuracy of the contract and the consistency of the gateway routing configuration; improves the reliability of transparent migration with zero modification to the upstream system; improves the accuracy of business request routing; enhances the clarity of the migration target; and increases the success rate of migration calls.

[0051] In some embodiments, the process of identifying a Hypertext Transfer Protocol (HTTP) request to obtain a Network Service Description Document (NSD) template includes: performing request parsing on the HTTP request to obtain a Uniform Resource Identifier (URI); performing path matching on the URI to obtain a path matching result; performing response capture on the HTTP request based on the path matching result to obtain initial NSD content; and caching the initial NSD content to obtain the NSD template.

[0052] Specifically, request parsing can be a data processing process that performs structural analysis on the received Hypertext Transfer Protocol (HTTP) request message. This request parsing can be used to extract the Uniform Resource Identifier (URI) from the request message to identify the target resource, thus providing a basis for subsequent identification of the request type. Request parsing can be performed by a filter component deployed in the Network Service Description Document (NSFD) simulation service, which can parse and process HTTP requests forwarded from the gateway layer.

[0053] A Uniform Resource Identifier (URI) can be a string used to uniquely identify a logical or physical resource on the Internet. The URI can include a complete request address identifier, including protocol, host, port, path, and query parameters, without limitation here. The URI can be used as input for subsequent path matching processing to determine the specific service endpoint corresponding to the current request. The URI can be obtained by parsing a Hypertext Transfer Protocol (HTTP) request.

[0054] Furthermore, path matching processing can be a data processing procedure that compares and judges the parsed Uniform Resource Identifier with a predefined target path pattern. This path matching processing can be used to identify specific requests that can be used to obtain the Network Service Description Document (NSD), thereby distinguishing the NSD query request from other types of business requests or invalid requests. The path matching processing can be performed by a filter component deployed in the NSD simulation service, which can perform string matching or regular expression matching on the Uniform Resource Identifier.

[0055] The path matching result can be a Boolean value or a status indicator generated by the path matching process. The path matching result can be used to characterize whether the Uniform Resource Identifier of the current request matches the predefined target path pattern, which can serve as the basis for decision-making in subsequent processes. The path matching result can be obtained by performing path matching processing on the Uniform Resource Identifier.

[0056] Furthermore, response capture processing can be a data processing procedure that allows the request to continue to be processed by the backend service framework after determining that the request is a valid network service description document query request. It can also intercept and save the original response content generated by the backend framework through wrapping technology. This response capture processing can be used to obtain the original content of the network service description document, including the service definition but with the service address as a placeholder. This can provide a basic template for dynamic customization and obtain the initial network service description document content. Response capture processing can be executed by a filter component deployed in the network service description document simulation service. This filter component can be triggered when the path matching result indicates a successful match, and it can intercept and temporarily store the response to the Hypertext Transfer Protocol request.

[0057] The initial network service description document (FSV) content can be the original, unmodified FSV content generated by the backend service framework based on a pre-set template file. The FSV content can be in the form of an Extensible Markup Language (Extreme Markup Language) document that conforms to the Network Service Description Language (WSL) specification, and its service address portion can be a predefined placeholder. The FSV content can serve as the base template for subsequent caching and dynamic address replacement. The FSV content can also be obtained by capturing and processing responses to Hypertext Transfer Protocol (HTP) requests.

[0058] In addition, caching can be a data processing process that stores the obtained initial network service description document content in memory or high-speed storage media. This caching process can be used to avoid repeated disk input / output reads or repeated parsing of the same static template file by the backend framework, thereby improving processing performance and reducing response latency. Caching can be performed by a filter component deployed in the network service description document simulation service, which can perform memory caching of the initial network service description document content.

[0059] For example, in the upgrade of an enterprise financial accounting system, the upstream calling system can be a budget management system. When replacing the old financial accounting system based on Simple Object Access Protocol (SAP) with a new system based on a representational state transition architecture, the budget management system can initiate a network service description document query request to its configured gateway layer unified entry address. For example, it can send a Hypertext Transfer Protocol request with the request behavior "GET / webservice / ncWebService.wsdl HTTP / 1.1"; the system identifier code can be "ncSystemCode: The URL is "https: / / gateway.xxxxx.com / to-budget-system". After the filter component in the simulated web service description document (WSD) service intercepts this Hypertext Transfer Protocol (HTTP) request, it can extract the Uniform Resource Identifier (URI) " / webservice / ncWebService.wsdl" from the request line. It can then perform path matching on this URI, comparing it with the predefined target path " / webservice / ncWebService.wsdl". If they match perfectly, the path matching result is successful. Based on this successful path matching result, the filter component can capture the response to the HTTP request, allowing the request to continue to the backend web service framework. The backend web service framework can then generate WSD content based on pre-defined static files. A custom response wrapper can intercept and capture all Extensible Markup Language (EXPLAIN) data written to the response by the framework, obtaining the initial WSD content. The service address in this initial WSD content can be a placeholder "locationUrl". The filter component can then cache this initial WSD content, storing it in a memory cache object to form a WSD template.

[0060] According to the technical solution provided in this disclosure, by parsing a Hypertext Transfer Protocol (HTTP) request, extracting a Uniform Resource Identifier (URI) from the request message, performing path matching on the URI, and matching it with a predefined target path pattern using strings or regular expressions to obtain the path matching result, and performing response capture processing on the HTTP request based on the path matching result, the request is allowed to be passed to the backend network service framework when a match is successful. The original response content generated by the framework is intercepted and captured by the response wrapper to obtain the initial network service description document (ISP) content. The initial ISP content is cached and stored in memory or a high-speed storage medium to obtain the ISP template. This enhances the recognition accuracy and response capture capability of ISP requests, improves the efficiency of initial document content acquisition and cache reusability, and lays a standardized template foundation for subsequent dynamic address injection.

[0061] In some embodiments, the process of extracting the identifier code from the Hypertext Transfer Protocol (HTTP) request to obtain the gateway address corresponding to the HTTP request includes: performing header parsing on the HTTP request to obtain HTTP header data; performing key-value extraction on the HTTP header data to obtain the system identifier code; and performing validity verification on the system identifier code to obtain the gateway address.

[0062] Specifically, header parsing can be a data processing procedure that parses the received Hypertext Transfer Protocol (HTTP) request message to extract its header information. This header parsing can be used to separate header data containing key routing and control information from the request message, thereby laying the foundation for subsequent extraction of specific identification information. The header parsing can be performed by a filter component deployed in the Network Service Description Document (NSFD) simulation service. This filter component can perform syntax analysis and structural separation processing on the HTTP request forwarded from the gateway layer.

[0063] The Hypertext Transfer Protocol (HTTP) header data can be a set of metadata organized in key-value pairs after the start line in the HTTP request message. This HTTP header data can include standard fields and custom fields injected by the gateway layer, etc., without limitation. This HTTP header data can provide control information for network communication, and can be used to carry system identification information injected by the gateway layer. This HTTP header data can be obtained by performing header parsing processing on the HTTP request.

[0064] Furthermore, key-value extraction processing can be a data processing procedure that searches for and retrieves the corresponding value of a specific key name from the parsed Hypertext Transfer Protocol header data. This key-value extraction processing can be used to locate and extract specific information pre-injected by the gateway layer to identify the upstream calling system and its corresponding gateway route, namely the system identifier code, which can provide a critical routing foundation for the subsequent dynamic construction of service addresses. Key-value extraction processing can be performed by a filter component deployed in the network service description document simulation service. This filter component can call the header data access interface to retrieve and process the Hypertext Transfer Protocol header data.

[0065] The system identifier can be a value of a custom field added to the Hypertext Transfer Protocol (HTTP) request header by the gateway layer when forwarding a network service description document (WSDL) query request. This system identifier may include information such as the gateway domain name and the base address of a specific context path, which is not limited here. The system identifier can be used to uniquely identify the upstream calling system that initiated the request and its corresponding gateway routing configuration. The system identifier can be generated and injected by the gateway layer according to the routing rules configured internally for each upstream calling system. The system identifier can also be obtained by extracting key-value pairs from the HTTP header data.

[0066] In addition, validity verification can be a data processing procedure that checks the extracted system identifier code to determine whether its format is standardized and its content is valid. This validity verification process can be used to ensure that the identifier information obtained from the request is reliable and usable, thereby preventing subsequent processes from failing due to illegal or abnormal header information. The validity verification process can be performed by a filter component deployed in the network service description document simulation service. This filter component can perform non-empty checks, Uniform Resource Locator (URL) format verification, and network location information integrity verification on the system identifier code.

[0067] For example, in the upgrade of an enterprise financial accounting system, the upstream calling system can be a voucher push system. This voucher push system can be developed based on the network service description language contract of the old financial accounting system, and its client code has the service address of the old system embedded in it. When the enterprise starts the financial accounting system upgrade project, it can replace the old financial accounting system based on Simple Object Access Protocol with a new system based on Representational State Transition Architecture. The voucher push system can initiate a network service description document query request to its configured gateway layer unified entry address. For example, it can send a Hypertext Transfer Protocol request with the request behavior "GET / webservice / ncWebService.wsdl HTTP / 1.1". After receiving the request, the gateway layer identifies it as a request from the group to which the voucher push system belongs, and can inject a system identifier code (such as "ncSystemCode:") into the Hypertext Transfer Protocol header when forwarding it. When the filter component in the network service description document simulation service intercepts this Hypertext Transfer Protocol (HTTP) request (https: / / gateway.xxxxx.com / to-group-a), it can perform header parsing. According to the HTTP specification, it performs syntactic analysis on the request message, separating the start line, header fields, and message body. It can also parse the header fields into a program-accessible data structure, obtaining structured HTTP header data. Then, it can call the header data access interface, for example, by passing the predefined key name "ncSystemCode" to the header data set to retrieve the corresponding value, obtaining the system identifier code "https: / / gateway.xxxxx.com / to-group-a". It can then perform validity checks on the system identifier code, verifying whether it is a non-empty string, contains a valid Uniform Resource Locator (URI) format, and contains necessary network location information. After successful verification, the system identifier code can be used as the base address and concatenated with the preset service path " / service / path" to obtain the complete gateway address "https: / / gateway.xxxxx.com / to-group-a / service / path", thus obtaining the gateway address corresponding to the HTTP request.

[0068] According to the technical solution provided in this disclosure, by parsing the Hypertext Transfer Protocol (HTTP) request header, separating the start line, header fields, and message body in the request message through syntax analysis, structured HTTP header data is obtained. Key-value extraction is performed on the HTTP header data, and a predefined key name is passed through the header data access interface to retrieve the system identifier code. The system identifier code undergoes validity verification, including non-empty checks, Uniform Resource Locator (URL) format verification, and network location information integrity verification. After successful verification, it is used as the base address to obtain the gateway address. This enhances the ability to parse and extract HTTP header information, improves the accuracy and reliability of system identifier code acquisition, and enhances data integrity and security during the dynamic construction of the gateway address.

[0069] In some embodiments, before identifying and processing the Hypertext Transfer Protocol (HTTP) request to obtain a network service description document template, the method further includes: performing entry address routing consistency processing on the upstream call initial request to obtain an initial HTTP request; performing header injection processing on the initial HTTP request to obtain a transfer protocol request to be forwarded; and performing target service routing processing on the transfer protocol request to be forwarded to obtain an HTTP request.

[0070] Specifically, the upstream call initial request can be an original request initiated by the upstream calling system to obtain the network service description document. The upstream call initial request may include specific query parameters to indicate the intent to obtain the network service description document, which is not limited here. The upstream call initial request can be a request initiated by the upstream calling system according to its business needs and pointing to the original old system service address.

[0071] Ingress address routing consistency processing is a data processing procedure that unifies the routing of requests from different upstream calling systems that point to different original service addresses to a common gateway ingress address. This ingress address routing consistency processing can be used to converge scattered heterogeneous request ingresses to a unified gateway layer to obtain an initial Hypertext Transfer Protocol request, which can lay the foundation for subsequent unified processing and header information injection. Ingress address routing consistency processing can be performed by a routing component deployed in the gateway layer, which can forward requests to a predefined unified endpoint based on the request's source information or specific identifier.

[0072] The initial hypertext transfer protocol request can be a hypertext transfer protocol request that uniformly points to the gateway entry point and is obtained through entry address routing consistency processing. This initial hypertext transfer protocol request can be used as the input object for header injection processing. This initial hypertext transfer protocol request can be obtained by performing entry address routing consistency processing on the upstream call initial request.

[0073] Furthermore, header injection processing can be a data processing procedure that adds or modifies the content of specific fields in the header information of the initial Hypertext Transfer Protocol (HTTP) request. This header injection processing can be used to carry the routing base address information of the gateway layer itself in the initial HTTP request to obtain the HTTP request to be forwarded, so that downstream services can identify the source of the initial HTTP request and perform customized processing accordingly. The header injection processing can be performed by the routing component deployed in the gateway layer. This routing component can add the corresponding gateway domain name and context path as the value of a specific header field to the initial HTTP request based on the group information configured for different upstream calling systems within its internal system.

[0074] The forwarding transport protocol request can be a hypertext transport protocol request that includes a system identifier code, obtained through header injection processing. This forwarding transport protocol request can be used as the input object for the target service routing processing. This forwarding transport protocol request can be obtained by performing header injection processing on the initial hypertext transport protocol request.

[0075] Furthermore, the target service routing process can be a data processing procedure that routes requests processed by header injection to a dedicated service for generating network service description documents based on the request content or pre-configured rules. This target service routing process can be used to ensure that requests carrying the upstream calling system identifier can be delivered to the network service description document simulation service. The target service routing process can be executed by a routing component deployed at the gateway layer, which can forward the transport protocol request to be forwarded to the unified access point of the network service description document simulation service according to predefined rules.

[0076] For example, in the upgrade of an enterprise's financial accounting system, the upstream calling system can be a voucher push system. This voucher push system can be developed based on the web service description language contract of the old financial accounting system, and its client code has the old system's service address embedded in it. When the enterprise initiates a financial accounting system upgrade project, replacing the old financial accounting system based on the Simple Object Access Protocol with a new system based on a representational state transition architecture, the voucher push system can continue to initiate web service description document query requests to its configured original old system service address. For example, it can send a request like "GET http: / / old-system.nc.com / ncWebService?wsdl". The upstream call begins with an initial request for HTTP / 1.1. Upon receiving this request, the gateway layer can perform entry address routing consistency processing. Based on the source information of the upstream call, it can identify the request as belonging to the group to which the credential push system belongs, and route it uniformly to the predefined gateway entry address "https: / / gateway.xxxxx.com / to-group-a", thus obtaining the initial Hypertext Transfer Protocol (HTTP) request. The gateway layer can then perform header injection processing on the initial HTTP request. Based on the routing group information configured for the credential push system, it can combine the gateway domain name and context path as the value of a specific header field and add it to the request. For example, it can inject "ncSystemCode: https: / / gateway.xxxxx.com / to-group-a" into the HTTP header, obtaining the HTTP request to be forwarded. The gateway layer can then perform target service routing processing on the HTTP request to be forwarded, forwarding it to the unified access point of the Web Service Description Document Simulation Service "http: / / ws-simulator:8070 / webservice / ncWebService.wsdl" according to predefined rules, thereby obtaining the HTTP request.

[0077] According to the technical solution provided in this disclosure, by performing entry address routing consistency processing on the initial upstream call request, the gateway layer routing component uniformly routes it to a predefined gateway entry address based on the request source information, thus obtaining an initial Hypertext Transfer Protocol (HTTP) request. Header injection processing is then performed on the initial HTTP request; the gateway layer routing component, based on the group information configured for the upstream calling system, adds the gateway domain name and context path as the value of a specific header field to the request, thus obtaining a HTTP request to be forwarded. Target service routing processing is then performed on the HTTP request to be forwarded, forwarding it to the unified access point of the Network Service Description Document (NSFDC) simulation service according to predefined rules, thus obtaining the HTTP request again. This enhances the unified convergence and routing capabilities of heterogeneous upstream requests; improves the efficiency of dynamic injection and transmission of upstream calling system identifiers at the gateway layer; and enhances the flexibility and configurability of forwarding requests to dedicated services.

[0078] In some embodiments, address injection processing is performed on the network service description document template based on the target service endpoint address to obtain the target network service description document, including: performing placeholder positioning processing on the network service description document template to obtain address placeholder position data; performing string replacement processing on the address placeholder position data based on the target service endpoint address to obtain the target document content; and performing response format setting processing on the target document content to obtain the target network service description document.

[0079] Specifically, placeholder location processing can be a data processing procedure that searches for predefined address placeholder strings in the content of the network service description document template using a string search algorithm. This placeholder location processing can be used to indicate the text area that needs to be replaced, thereby ensuring the accuracy and efficiency of the replacement operation. Placeholder location processing can be performed by a filter component deployed in the network service description document simulation service, which can scan and record the location of the network service description document template.

[0080] The address placeholder position data can be information that identifies the specific position of the placeholder string in the template document. This address placeholder position data can be used to represent the target position index of subsequent string replacement operations. This address placeholder position data can be obtained by performing placeholder positioning processing on the network service description document template.

[0081] In addition, string replacement processing can be a data processing procedure that replaces the corresponding placeholder text in the template with the target service endpoint address string based on the address placeholder position data. This string replacement processing can be used to customize a general template into a personalized document pointing to a specific gateway entry, thereby obtaining the target document content and enabling the dynamic generation of network service description documents. String replacement processing can be performed by a filter component deployed in the network service description document simulation service. This filter component can perform text replacement processing on the network service description document template based on the address placeholder position data.

[0082] The target document content can be the complete text content of the network service description document after the address field has been replaced. The target document content can include correct service address information. The target document content can be obtained by performing string replacement processing on the address placeholder position data based on the target service endpoint address.

[0083] Furthermore, the response formatting process can be a data processing procedure for configuring the correct Hypertext Transfer Protocol (HTTP) response header information for the document content to be returned. This response formatting process can be used to ensure that the HTTP response conforms to the standard format requirements of the Web Service Description Document (WSD), so that the client of the upstream calling system can correctly identify and parse the returned document content. The response formatting process can be performed by a filter component deployed in the Web Service Description Document (WSD) simulation service, which can perform content type settings and response body writing processing on the target document content.

[0084] For example, in the upgrade of an enterprise financial accounting system, the upstream calling system can be a voucher push system. This voucher push system can be developed based on the network service description language contract of the old financial accounting system, and its client code has the service address of the old system embedded in it. When the enterprise starts the financial accounting system upgrade project, it can replace the old financial accounting system based on Simple Object Access Protocol with a new system based on Representational State Transition Architecture. The voucher push system can initiate a network service description document query request to its configured gateway layer unified entry address. For example, it can send a Hypertext Transfer Protocol request with the request behavior "GET / webservice / ncWebService.wsdl HTTP / 1.1". After receiving the request, the gateway layer identifies it as a request from the group to which the voucher push system belongs, and can inject a system identifier code (such as "ncSystemCode:") into the Hypertext Transfer Protocol header when forwarding it. The filter component in the Network Service Description Document (RSD) simulation service intercepts the Hypertext Transfer Protocol (HTTP) request. It extracts the gateway address "https: / / gateway.xxxxx.com / to-group-a" from the HTTP header and reads the preset service path " / service / path" from its internal configuration. It then concatenates the gateway address with the preset service path to generate the target service endpoint address "https: / / gateway.xxxxx.com / to-group-a / service / path". The filter component can perform placeholder location processing on the preset RSD template, scanning the document content and finding the placeholder string "locationUrl" that marks the service address, recording its location data. Next, it can perform string replacement processing on the address placeholder location data based on the target service endpoint address, replacing "locationUrl" in the template with the complete "https: / / gateway.xxxxx.com / to-group-a / service / path", thus generating target document content including the correct gateway address. Finally, it can set the response format for the target document content, allowing the response content type to be "text / xml". The charset is set to "utf-8", and the processed content can be written into the Hypertext Transfer Protocol response body, thereby obtaining the target network service description document.

[0085] According to the technical solution provided in this disclosure, by performing placeholder location processing on the network service description document template, searching for predefined address placeholder strings using a string search algorithm to obtain address placeholder position data, and performing string replacement processing on the address placeholder position data based on the target server endpoint address, the corresponding placeholder text in the template is replaced with the target server endpoint address to obtain the target document content. The target document content is then processed to set the response format, and the correct Hypertext Transfer Protocol (HTTP) response header information is configured to obtain the target network service description document. This enhances the accurate location and replacement capability of address placeholders in the network service description document template; improves the efficiency and accuracy of string replacement during dynamic document generation; and ensures the standardization of the response format and compatibility with client parsing.

[0086] In some embodiments, concatenating the gateway address and a preset service path to obtain the target service endpoint address includes: performing protocol format verification on the gateway address to obtain a standardized gateway address; performing path validity verification on the preset service path to obtain a valid service path; and concatenating the standardized gateway address and the valid service path to obtain the target service endpoint address.

[0087] Specifically, protocol format verification can be a data processing procedure that parses and verifies the gateway address string to ensure that it conforms to the predetermined network protocol format specification. This protocol format verification can be used to check whether the gateway address starts with a standard protocol and remove redundant characters at the end to obtain a standardized gateway address. This ensures that subsequent address concatenation operations are based on gateway addresses with a unified format and correct structure. Protocol format verification can be performed by a filter component deployed in the network service description document simulation service. This filter component can perform format checks, protocol verification, and redundant character cleanup on the gateway address.

[0088] The standardized gateway address can be a gateway address string that conforms to a predetermined format specification and is obtained through protocol format verification. This standardized gateway address can be used as input for address concatenation and can be obtained by performing protocol format verification on the gateway address.

[0089] In addition, path validity verification can be a data processing procedure that checks the preset service path string to ensure that it conforms to the predetermined path format and security specifications. This path validity verification can be used to verify whether the path starts with a forward slash, whether it contains illegal characters or path traversal sequences, and to obtain a valid service path. This can prevent security risks or service anomalies caused by incorrect service path configuration or malicious tampering. Path validity verification can be performed by a filter component deployed in the network service description document simulation service. This filter component can perform format checks and security verification on the preset service path.

[0090] The valid service path can be a service path string that has been confirmed to be safe and correctly formatted through path validity verification. This valid service path can be used as another input for address concatenation. This valid service path can be obtained by performing path validity verification on a preset service path.

[0091] Furthermore, string concatenation can be a data processing procedure that joins standardized gateway address strings and valid service path strings together according to a predetermined order and format. This string concatenation can be used to dynamically construct complete service endpoint addresses pointing to specific routes at the gateway layer, thereby obtaining the target service endpoint address. This ensures that the service address field in the customized network service description document obtained by the upstream calling system can point to the gateway entry point configured for it. String concatenation can be performed by a filter component deployed in the network service description document simulation service, which can perform concatenation operations on the standardized gateway address and valid service path.

[0092] For example, in the upgrade of an enterprise financial accounting system, the gateway address can be "https: / / gateway.xxxxx.com / to-group-a / ". The filter component can perform protocol format validation on the gateway address, checking whether it starts with a standard protocol and removing redundant trailing slashes to obtain the standardized gateway address "https: / / gateway.xxxxx.com / to-group-a". Then, it can perform path validity validation on the preset service path " / service / path", verifying that it starts with a slash and does not contain illegal characters or path traversal sequences to obtain the valid service path " / service / path". Finally, it can concatenate the standardized gateway address and the valid service path, appending the valid service path directly to the end of the standardized gateway address to generate the target service endpoint address "https: / / gateway.xxxxx.com / to-group-a / service / path", thus obtaining the target service endpoint address.

[0093] According to the technical solution provided in this disclosure, the gateway address is processed by protocol format verification. By parsing and verifying whether it conforms to the predetermined network protocol format specification and removing redundant characters at the end, a standardized gateway address is obtained. The preset service path is processed by path validity verification, checking whether it starts with a forward slash and whether it contains illegal characters or path traversal sequences, to obtain a valid service path. The standardized gateway address and the valid service path are concatenated into strings and connected according to a predetermined order and format to obtain the target service endpoint address. This enhances the format standardization and security of the gateway address and service path; improves the accuracy and robustness of the concatenation operation; and reduces the risk of subsequent call failures due to incorrect address format.

[0094] In some embodiments, the Hypertext Transfer Protocol (HTTP) request response capture processing based on the path matching result is used to obtain the initial network service description document content, including: performing filter chain allow processing on the HTTP request based on the path matching result to obtain the initial response object; performing response object wrapping processing on the initial response object to obtain a custom response wrapper; and performing output stream interception processing on the initial response object based on the custom response wrapper to obtain the initial network service description document content.

[0095] Specifically, the filter chain allowance process can be a data processing procedure in a service specification-based web application processing flow where, after a Hypertext Transfer Protocol (HTTP) request passes the check of the filter chain, it is allowed to continue to be passed to subsequent services or controllers for processing. This filter chain allowance process can be used to ensure that requests identified as web service description document (WSD) queries can reach the WSD definition endpoint of the backend framework to obtain an initial response object, thereby generating the original static WSD template content. The filter chain allowance process can be executed by a filter component deployed in the WSD simulation service. This filter component can be triggered when the path matching result indicates a successful match, passing the HTTP request to the backend service framework for processing.

[0096] The initial response object can be a Hypertext Transfer Protocol (HTTP) response object generated by the backend framework when processing the allowed request, which includes the content of the original Network Service Description Document (NSD) template. This initial response object can serve as the original data source for subsequent content interception and modification operations. The initial response object can contain the NSD contract template without address replacement. The initial response object can also be obtained by performing standard Web service processing on the HTTP request that has been allowed through the filtering chain.

[0097] Furthermore, response object wrapping can create a new object that extends the standard Hypertext Transfer Protocol response wrapper class to intercept and cache all data processing operations on the original response object. This response object wrapping can be used to enhance or modify the behavior of the original object without changing its interface, resulting in a custom response wrapper, which can then enable subsequent dynamic content modifications. Response object wrapping can be performed by a filter component deployed in the network service description document simulation service, which can override the output method to redirect data that should have been written to the network stream to an internal buffer.

[0098] The custom response wrapper can be a concrete implementation class instance created through response object wrapping. This custom response wrapper can be used to encapsulate the original response object and provide the ability to capture the response content. This custom response wrapper can be used to temporarily store the original network service description document response body, so that the filter can obtain the complete response content for subsequent processing after the request processing chain is completed. This custom response wrapper can be obtained by wrapping the initial response object.

[0099] Furthermore, output stream interception processing can be a data processing procedure that intercepts and reads the response content into memory before it is sent back to the client via the output stream using a custom response wrapper. This output stream interception processing can be used to obtain the complete, unmodified web service description document template string and obtain the initial web service description document content. Output stream interception processing can be executed by a filter component deployed in the web service description document simulation service. This filter component can convert byte data into a string by calling the wrapper's buffer read method after calling the filter chain and passing in the wrapper object.

[0100] For example, based on the aforementioned application scenario, the path matching result can be successful. Based on this path matching result, the filter component can perform a filtering chain to allow the Hypertext Transfer Protocol (HTTP) request, passing the request to the backend network service framework. The framework can then generate network service description document content based on pre-defined static files, obtaining the initial response object. Furthermore, the filter component can wrap the initial response object, creating a custom response wrapper that extends the standard HTTP response wrapper class, and overriding the output method to redirect data that should have been written to the network stream to an internal buffer. The filter component can then intercept the output stream of the initial response object based on the custom response wrapper. After the filtering chain is completed, it calls the wrapper's buffer read method to convert the captured byte data into a string, obtaining the original network service description document string containing the predefined address placeholder "locationUrl," thus obtaining the initial network service description document content.

[0101] According to the technical solution provided in this disclosure, a filtering chain is performed on Hypertext Transfer Protocol (HTTP) requests based on path matching results. When a match is successful, the request is passed to the backend service framework to generate an initial response object. The initial response object is then wrapped, and a custom response wrapper extending from the standard response wrapper class is created. The output method is overridden to redirect data to an internal buffer. The output stream of the initial response object is intercepted based on the custom response wrapper. After the filtering chain is completed, the buffer read method is called to convert the captured byte data into a string, thus obtaining the initial network service description document content. This enhances the dynamic interception and caching capabilities of the response content, improves the completeness and controllability of obtaining the initial network service description document content, and lays a modifiable data foundation for subsequent address replacement operations.

[0102] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0103] Figure 3 This is a schematic diagram of another method for generating network service description documents provided in this embodiment of the disclosure. For example... Figure 3 As shown, the method for generating the network service description document includes: Upstream calling systems can initiate initial upstream call requests based on their business needs. These initial upstream call requests can point to the original legacy system service address to obtain the network service description document (FSV). The routing component deployed at the gateway layer can perform entry address consistency processing on this initial upstream call request, converging scattered heterogeneous request entry points to a common gateway entry address, resulting in an initial Hypertext Transfer Protocol (HTP) request. The gateway layer can perform header injection processing on the initial HTP request, adding the corresponding gateway domain name and context path as the value of a specific header field to the request based on the routing group information configured for different upstream calling systems. For example, a system identifier can be injected into the HTP header to obtain the HTP request to be forwarded. The gateway layer can then perform target service routing processing on the HTP request to be forwarded, forwarding it to the unified access point of the network service description document simulated service according to predefined rules, thus obtaining the HTP request.

[0104] After the filter component in the network service description document simulation service intercepts the Hypertext Transfer Protocol (HTTP) request, it can perform request parsing processing, extracting the Uniform Resource Identifier (URI) used to identify the target resource from the request message. The filter component then performs path matching processing on the URI, comparing it with predefined target path patterns within the system to obtain the path matching result. Based on the path matching result, the filter component can perform response capture processing on the HTTP request: when the path matching result indicates a successful match, the filter component can allow the HTTP request through the filter chain, passing the request to the backend network service framework, where the framework will then process it according to predefined parameters. The static file generates the network service description document content, resulting in an initial response object. The filter component then wraps the initial response object, creating a custom response wrapper that can intercept the response content, redirecting data that should have been written to the network stream to an internal buffer. The filter component can then intercept the output stream of the initial response object based on the custom response wrapper. After the filter chain is complete, it reads the data from the buffer to obtain the initial network service description document content. Finally, the filter component can cache the initial network service description document content, storing it in a memory cache object to form a network service description document template that can be quickly read.

[0105] The filter component can extract identifiers from Hypertext Transfer Protocol (HTTP) requests: it performs header parsing, analyzing the request message according to the HTTP specification to parse header fields into data structures accessible to the program, thus obtaining the HTTP header data; it can then perform key-value extraction from the HTTP header data, calling the header data access interface to retrieve the value corresponding to the system identifier field from the header data set, thus obtaining the system identifier; it can also perform validity validation on the system identifier, checking whether it is a non-empty string, whether it contains a valid Uniform Resource Locator (URL) format, and whether it contains the necessary network location information, obtaining the gateway address after successful validation.

[0106] The filter component concatenates the gateway address and the preset service path: it can perform protocol format validation on the gateway address, checking whether it starts with a standard protocol and removing redundant characters at the end to obtain a standardized gateway address; then it can perform path validity validation on the preset service path, verifying whether it starts with a forward slash and whether it contains illegal characters or path traversal sequences to obtain a valid service path; it can concatenate the standardized gateway address and the valid service path, directly appending the valid service path to the end of the standardized gateway address to generate a complete service endpoint address, thus obtaining the target service endpoint address.

[0107] The filter component performs address injection processing on the network service description document template based on the target service endpoint address: It can perform placeholder location processing on the network service description document template, scanning the document content using a string search algorithm to find the placeholder strings marking the service address, recording their position data to obtain the address placeholder position data; then, it can perform string replacement processing on the address placeholder position data based on the target service endpoint address, replacing the placeholders in the template with the complete gateway address, generating document content containing the correct gateway address, thus obtaining the target document content; it can also perform response format setting processing on the target document content, setting the response content type to the standard Extensible Markup Language (XML) format, and writing the processed content into the Hypertext Transfer Protocol (HTTP) response body to obtain the target network service description document; this target network service description document is returned to the upstream calling system through the gateway layer. After its Simple Object Access Protocol (SAPI) client parses the document, it can initiate subsequent business requests to the correct gateway address, achieving transparent migration with zero modifications.

[0108] According to the technical solution provided in this disclosure, Hypertext Transfer Protocol (HTTP) requests are identified and processed. A gateway layer filter intercepts and checks the request, and a Uniform Resource Identifier (URI) path matching method is used to determine if it is a Network Service Description Document (NSDocument) query request. If the identification is successful, the Network Service Framework returns an NSD document template containing service operation definitions, message structures, and address placeholders. The HTTP request is then processed to extract an identifier code. A filter component parses the HTTP header information and extracts a specific identifier code field pre-injected by the gateway layer to obtain the gateway address. The gateway address and a preset service path are concatenated, and the target service endpoint address is dynamically obtained through string concatenation. The target service endpoint address is injected into the network service description document template. A string replacement operation replaces address placeholders in the template with the target service endpoint address, generating the target network service description document. This enhances the accuracy and automation of Hypertext Transfer Protocol request type identification; decouples the gateway routing information transmission from the network service description document contract generation process; improves the stateless nature and horizontal scalability of the network service description document simulating the service; ensures the accuracy of the contract and the consistency of the gateway routing configuration; improves the reliability of transparent migration with zero modification to the upstream system; improves the accuracy of business request routing; enhances the clarity of the migration target; and increases the success rate of migration calls.

[0109] The following are embodiments of the apparatus disclosed herein, which can be used to execute embodiments of the method disclosed herein. For details not disclosed in the apparatus embodiments of this disclosure, please refer to the embodiments of the method disclosed herein.

[0110] Figure 4 This is a schematic diagram of a network service description document generation device provided in an embodiment of this disclosure. Figure 4 As shown, the network service description document generation device includes: The first processing module 401 is used to identify and process the Hypertext Transfer Protocol request to obtain a network service description document template. The second processing module 402 is used to perform identification code extraction processing on the Hypertext Transfer Protocol request to obtain the gateway address corresponding to the Hypertext Transfer Protocol request. The third processing module 403 is used to concatenate the gateway address and the preset service path to obtain the target service endpoint address; The fourth processing module 404 is used to perform address injection processing on the network service description document template based on the target service endpoint address to obtain the target network service description document.

[0111] According to the technical solution provided in this disclosure, Hypertext Transfer Protocol (HTTP) requests are identified and processed. A gateway layer filter intercepts and checks the request, and a Uniform Resource Identifier (URI) path matching method is used to determine if it is a Network Service Description Document (NSDocument) query request. If the identification is successful, the Network Service Framework returns an NSD document template containing service operation definitions, message structures, and address placeholders. The HTTP request is then processed to extract an identifier code. A filter component parses the HTTP header information and extracts a specific identifier code field pre-injected by the gateway layer to obtain the gateway address. The gateway address and a preset service path are concatenated, and the target service endpoint address is dynamically obtained through string concatenation. The target service endpoint address is injected into the network service description document template. A string replacement operation replaces address placeholders in the template with the target service endpoint address, generating the target network service description document. This enhances the accuracy and automation of Hypertext Transfer Protocol request type identification; decouples the gateway routing information transmission from the network service description document contract generation process; improves the stateless nature and horizontal scalability of the network service description document simulating the service; ensures the accuracy of the contract and the consistency of the gateway routing configuration; improves the reliability of transparent migration with zero modification to the upstream system; improves the accuracy of business request routing; enhances the clarity of the migration target; and increases the success rate of migration calls.

[0112] In some embodiments, the first processing module 401 is specifically configured to: perform request parsing processing on the Hypertext Transfer Protocol request to obtain a Uniform Resource Identifier (URI); perform path matching processing on the URI to obtain a path matching result; perform response capture processing on the Hypertext Transfer Protocol request based on the path matching result to obtain initial network service description document (ISP) content; and perform caching processing on the initial ISP content to obtain a ISP template.

[0113] In some embodiments, the second processing module 402 is specifically used to: perform header parsing processing on the Hypertext Transfer Protocol request to obtain Hypertext Transfer Protocol header data; perform key-value extraction processing on the Hypertext Transfer Protocol header data to obtain a system identifier code; and perform validity verification processing on the system identifier code to obtain a gateway address.

[0114] In some embodiments, the network service description document generation apparatus is further configured to: perform entry address routing consistency processing on the upstream call initial request to obtain an initial hypertext transfer protocol request; perform header injection processing on the initial hypertext transfer protocol request to obtain a transfer protocol request to be forwarded; and perform target service routing processing on the transfer protocol request to be forwarded to obtain a hypertext transfer protocol request.

[0115] In some embodiments, the fourth processing module 404 is specifically used to: perform placeholder positioning processing on the network service description document template to obtain address placeholder position data; perform string replacement processing on the address placeholder position data based on the target service endpoint address to obtain target document content; and perform response format setting processing on the target document content to obtain the target network service description document.

[0116] In some embodiments, the third processing module 403 is specifically used to: perform protocol format verification processing on the gateway address to obtain a standardized gateway address; perform path validity verification processing on the preset service path to obtain a valid service path; and perform string concatenation processing on the standardized gateway address and the valid service path to obtain the target service endpoint address.

[0117] In some embodiments, the process of capturing responses to Hypertext Transfer Protocol (HTTP) requests based on path matching results to obtain initial network service description document content is specifically used for: performing filtering chain allowance processing on HTTP requests based on path matching results to obtain an initial response object; performing response object wrapping processing on the initial response object to obtain a custom response wrapper; and performing output stream interception processing on the initial response object based on the custom response wrapper to obtain the initial network service description document content.

[0118] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0119] Figure 5 This is a schematic diagram of the electronic device 5 provided in an embodiment of this disclosure. Figure 5As shown, the electronic device 5 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, it implements the steps in the various method embodiments described above. Alternatively, when the processor 501 executes the computer program 503, it implements the functions of each module / unit in the various device embodiments described above.

[0120] Electronic device 5 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 5 may include, but is not limited to, processor 501 and memory 502. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or different components.

[0121] The processor 501 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0122] The memory 502 can be an internal storage unit of the electronic device 5, such as a hard disk or RAM of the electronic device 5. The memory 502 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 5. The memory 502 can also include both internal and external storage units of the electronic device 5. The memory 502 is used to store computer programs and other programs and data required by the electronic device.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0124] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0125] The above embodiments are only used to illustrate the technical solutions of this disclosure, and are not intended to limit it. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be included within the protection scope of this disclosure.

Claims

1. A method of generating a network service description document, characterized by, include: The Hypertext Transfer Protocol request is identified and processed to obtain a network service description document template. The Hypertext Transfer Protocol (HTTP) request is processed by extracting the identifier code to obtain the gateway address corresponding to the HTTP request. The gateway address and the preset service path are concatenated to obtain the target service endpoint address; The network service description document template is injected with address based on the target service endpoint address to obtain the target network service description document.

2. The method for generating network service description documents according to claim 1, characterized in that, The process of identifying and processing Hypertext Transfer Protocol requests to obtain a network service description document template includes: The Hypertext Transfer Protocol request is parsed to obtain a Uniform Resource Identifier; The Uniform Resource Identifier is subjected to path matching processing to obtain the path matching result; Based on the path matching result, the Hypertext Transfer Protocol request is captured to obtain the content of the initial network service description document. The content of the initial network service description document is cached to obtain the network service description document template.

3. The method for generating network service description documents according to claim 1, characterized in that, The step of extracting the identifier code from the Hypertext Transfer Protocol request to obtain the gateway address corresponding to the Hypertext Transfer Protocol request includes: The Hypertext Transfer Protocol (HTTP) request is parsed to obtain the HTTP header data. The system identifier code is obtained by extracting key values ​​from the Hypertext Transfer Protocol header data. The system identifier code is validated to obtain the gateway address.

4. The method for generating network service description documents according to claim 1, characterized in that, Before the process of identifying and processing the Hypertext Transfer Protocol request to obtain the network service description document template, the method further includes: The initial request for upstream calls is processed to ensure consistent entry address routing, resulting in the initial Hypertext Transfer Protocol request. The initial Hypertext Transfer Protocol request is subjected to header injection processing to obtain the transfer protocol request to be forwarded; The target service routing process is performed on the transmission protocol request to be forwarded to obtain the hypertext transfer protocol request.

5. The method for generating network service description documents according to claim 1, characterized in that, The step of performing address injection processing on the network service description document template based on the target service endpoint address to obtain the target network service description document includes: The network service description document template is processed to locate placeholders, thereby obtaining address placeholder position data; Based on the target server endpoint address, the address placeholder position data is replaced with strings to obtain the target document content; The target document content is processed to set the response format, resulting in the target network service description document.

6. The method for generating network service description documents according to claim 1, characterized in that, The step of concatenating the gateway address and the preset service path to obtain the target service endpoint address includes: The gateway address is subjected to protocol format verification to obtain a standardized gateway address; The preset service path is subjected to path validity verification to obtain a valid service path; The standardized gateway address and the valid service path are concatenated to obtain the target service endpoint address.

7. The method for generating network service description documents according to claim 2, characterized in that, The process of capturing the response to the Hypertext Transfer Protocol request based on the path matching result to obtain the initial network service description document content includes: Based on the path matching result, the Hypertext Transfer Protocol request is filtered and allowed to pass through, resulting in an initial response object; The initial response object is wrapped to obtain a custom response wrapper; The initial response object is intercepted using the custom response wrapper to obtain the content of the initial network service description document.

8. A network service description document generation device, characterized in that, include: The first processing module is used to identify and process Hypertext Transfer Protocol requests to obtain a network service description document template. The second processing module is used to extract the identifier code from the Hypertext Transfer Protocol request to obtain the gateway address corresponding to the Hypertext Transfer Protocol request. The third processing module is used to concatenate the gateway address and the preset service path to obtain the target service endpoint address; The fourth processing module is used to perform address injection processing on the network service description document template based on the target service endpoint address to obtain the target network service description document.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images