Mapping method, apparatus, and device

Abstract

This application discloses a mapping method, apparatus, and device. The method includes: defining a DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; parsing the DSL configuration file to construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward mapping table and the reverse mapping table point to the same operation configuration object; receiving an HTTP request; and performing corresponding conversions based on the HTTP request, the forward mapping table, and the reverse mapping table. This application improves positioning accuracy and efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a mapping method, apparatus, or device. Background Technology

[0002] SOAP (Simple Object Access Protocol) has been widely used in web service communication for enterprise systems in finance, government, and telecommunications since the 2000s. Its XML-based message format, WSDL interface description, and enterprise-level specifications such as WS-Security have formed a huge stock of technical assets. Meanwhile, JSON-RPC (JSON Remote Procedure Call) dominates in modern microservice architectures and blockchain node communication scenarios due to its lightweight structure, low bandwidth consumption, and ease of parsing by front-end / mobile devices.

[0003] Currently, mapping between SOAP and JSON-RPC generally requires systematic bidirectional conversion processing at the protocol semantic level.

[0004] However, the above method requires developers to write a large number of templates or scripts, resulting in low mapping efficiency. Summary of the Invention

[0005] The main objective of this application is to provide a mapping method, apparatus, or device that improves mapping accuracy and efficiency.

[0006] To achieve the above objectives, firstly, this application provides a mapping method, comprising: Define a DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; Parse the DSL configuration file and build a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, where the forward mapping table and the reverse mapping table point to the same operation configuration object; Receive HTTP requests; Perform the corresponding transformation based on the HTTP request, the forward mapping table, and the reverse mapping table.

[0007] In one embodiment, the DSL configuration syntax includes at least the following nodes: Service definition node, operation mapping node, and global configuration node; The service definition node includes the service name, SOAP namespace, SOAP service address, and JSON-RPC service address; The operation mapping node contains a bidirectional association between SOAP operation names and JSON-RPC method names, operation type, parameter mapping list, response mapping configuration, and error mapping rules; The global configuration node includes type conversion rules, naming conventions, request ID generation strategies, error propagation rules, and gateway masquerading mode switches.

[0008] In one embodiment, parsing the DSL configuration file and constructing a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys includes: Parse the DSL configuration file to obtain all operation mapping nodes in the DSL configuration file; For each operation mapping node in all operation mapping nodes of the DSL configuration file, create a first entry with SOAP operation name as the key and operation configuration object as the value, and a second entry with JSON-RPC method name as the key and operation configuration object as the value; Summarize the first entry corresponding to each operation mapping node to obtain the set of first entries corresponding to all operation mapping nodes; Summarize the second entries corresponding to each operation mapping node to obtain the set of second entries corresponding to all operation mapping nodes; Insert the first set of entries into the first table to build a forward mapping table with SOAP operation names as keys, and insert the second set of entries into the second table to build a reverse mapping table with JSON-RPC method names as keys.

[0009] In one embodiment, parsing the DSL configuration file further includes: Verify the integrity of the service definition, the operation definition, and the bidirectional mapping fields between SOAP operation names and JSON-RPC method names in the operation mapping node.

[0010] In one embodiment, performing a corresponding transformation based on the HTTP request, the forward mapping table, and the reverse mapping table includes: If the access path of the HTTP request is the SOAP protocol entry path, then extract the SOAP operation name in the HTTP request, query the forward mapping table to obtain the operation configuration, and perform the SOAP to JSON-RPC request conversion and the corresponding response inverse conversion. If the access path of the HTTP request is the entry path of the JSON-RPC protocol, then the method field in the HTTP request is extracted, the reverse mapping table is queried to obtain the operation configuration, so as to perform the request conversion from JSON-RPC to SOAP and the corresponding response inverse conversion. If the HTTP request access path is the WSDL document generation entry path, then the WSDL document is dynamically generated and returned based on the service definition and operation mapping list in the DSL configuration file.

[0011] In one embodiment, performing a SOAP-to-JSON-RPC request conversion includes: Based on the parameter mapping list in the operation configuration, extract the parameter values ​​corresponding to each parameter from the parsed SOAP request XML; Construct a JSON-RPC request object, where the method field is set to the JSON-RPC method name in the operation configuration, the params field is set to the extracted parameter values, and the id field is generated according to a preset strategy; Serialize the JSON-RPC request object into a JSON string and output it.

[0012] In one embodiment, performing a JSON-RPC to SOAP request conversion includes: Parse the JSON-RPC request and extract the method, params, and id fields; After retrieving the operation configuration from the reverse mapping table based on the method field, create a SOAP envelope and set a namespace for the SOAP envelope; Based on the parameter mapping list in the operation configuration, the values ​​of each SOAP parameter are sequentially taken from the extracted params field to construct sub-elements, which are then added to the Body of the SOAP envelope. Write the extracted id field into a custom header field in the Header of the SOAP envelope; Serialize the completed SOAP envelope into an XML string and output it.

[0013] In one embodiment, a WSDL document is dynamically generated based on the service definitions and operation mapping lists in the DSL configuration file, including: Read the service name, namespace, and operation mapping list from the DSL configuration file; Based on the parameter type definition of each operation in the operation mapping list, dynamically generate the corresponding XSD Schema as the types section of the WSDL document; Iterate through each operation in the operation mapping list and generate a message definition, an operation definition in portType, and an operation binding in binding for each operation; Generate a service definition and set the port address in the service definition to the gateway's own SOAP ingress address; The WSDL document is dynamically generated by integrating the types section, message definition, operation definition in portType, operation binding in binding, and service definition.

[0014] Secondly, embodiments of this application provide a mapping apparatus, including: The configuration syntax module is used to define the DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs. The DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node. The mapping table construction module is used to parse the DSL configuration file and build a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys. The forward mapping table and the reverse mapping table point to the same operation configuration object. The request receiving module is used to receive HTTP requests; The transformation module is used to perform corresponding transformations based on HTTP requests, forward mapping tables, and reverse mapping tables.

[0015] Thirdly, embodiments of this application provide a computer 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 any of the methods described above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0017] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0018] This application provides a mapping method, apparatus, and device, including: defining a DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; parsing the DSL configuration file to construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward and reverse mapping tables point to the same operation configuration object; receiving an HTTP request; and performing corresponding conversions based on the HTTP request, the forward mapping table, and the reverse mapping table. By designing the DSL configuration syntax, this application allows developers to simultaneously declare the correspondence between SOAP operation names and JSON-RPC method names, as well as complete parameter mappings, response templates, and error rules in a single YAML configuration node. This ensures that adding a new operation mapping only requires adding configuration code, without modifying any program code, thus improving positioning accuracy and efficiency. Simultaneously, clients of both SOAP and JSON-RPC protocol systems can communicate transparently without any modification; configuration redundancy is eliminated, and the consistency of bidirectional mapping is ensured, further improving positioning accuracy and efficiency. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 This is a schematic diagram of the structure of a mapping system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a mapping method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a DSL configuration loading and operation mapping table construction process provided in an embodiment of this application; Figure 4 This is a schematic diagram of a protocol gateway layer request routing process provided in an embodiment of this application; Figure 5 This is a flowchart illustrating a dynamic WSDL generation method provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating a process of disguising a JSON-RPC service as a SOAP service, as provided in an embodiment of this application. Figure 7 This is a schematic diagram illustrating a process of disguising a SOAP service as a JSON-RPC service, as provided in an embodiment of this application. Figure 8 This is a schematic diagram of the structure of a mapping device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0021] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

[0022] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0023] It should be understood that in the various embodiments of this application, the sequence number of each process 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 application.

[0024] It should be understood that in this application, "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0025] It should be understood that in this application, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "and / or B" can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0026] It should be understood that in this application, "B corresponding to A", "B corresponding to A", "A corresponds to B", or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0027] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0028] The data involved in this application may be data authorized by the tester or fully authorized by all parties. The collection, dissemination, and use of the data shall comply with the relevant laws, regulations and standards of the relevant countries and regions. The implementation methods / executives of this application may be combined with each other.

[0029] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0030] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0031] SOAP (Simple Object Access Protocol) has been widely used in web service communication for enterprise systems in finance, government, and telecommunications since the 2000s. Its XML-based message format, WSDL interface description, and enterprise-level specifications such as WS-Security have created a vast portfolio of technological assets. Meanwhile, JSON-RPC (JSON Remote Procedure Call), with its lightweight structure, low bandwidth consumption, and ease of parsing by front-end / mobile devices, dominates in modern microservice architectures and blockchain node communication scenarios. However, SOAP and JSON-RPC differ fundamentally in their design philosophies. SOAP uses an XML envelope model, identifies operations through the SOAPAction header, and transmits errors using SOAP Fault. JSON-RPC, on the other hand, is based on JSON objects, routes requests through the method field, relies on the id field for request-response pairing, and expresses errors through the error object. This structural difference means that conversion between the two cannot rely on simple field name mapping; a systematic bidirectional conversion process at the protocol semantic level is necessary.

[0032] Currently, the technical solutions most similar to this invention mainly include: XSLT (Extensible Stylesheet Transformation Language), which achieves structural transformation from XML to the target format through template matching, but lacks a built-in correspondence between SOAP operation names and JSON-RPC method names. Each operation requires writing an independent matching template, resulting in a linear increase in configuration as the number of operations increases; jq, as a dedicated JSON processing tool, does not support XML parsing at all and cannot directly process SOAP messages; MuleSoft DataWeave and Apache Camel DSL, although supporting multi-format conversion, are general-purpose data conversion languages ​​without semantic support for specific protocol pairs. They require a large amount of script logic to manually write conditional judgments to describe the mapping relationship between operations; Java SOAP frameworks such as Apache CXF and Spring-WS require the conversion logic to be implemented in a hard-coded manner. Adding new operations requires modifying Java code, recompiling and re-deploying, and neither of them supports the JSON-RPC protocol.

[0033] The aforementioned existing technologies generally suffer from the following drawbacks: First, they lack the ability to concisely express operational-level semantic mapping, making it impossible to simultaneously declare the bidirectional correspondence between SOAP operation names and JSON-RPC method names, as well as the complete mapping information of parameters, responses, and errors, in a single configuration. Developers are forced to write a large number of templates or scripts. Second, they have poor scalability. Each new operation mapping requires modification of the source code (or the addition of a new template / script) and undergoes a complete code modification-compilation-deployment cycle, with maintenance costs increasing linearly with the number of operations. Third, they lack the ability to disguise gateways for protocols, making it impossible to present a service of one protocol as another protocol, and even more impossible to dynamically generate documents conforming to the WSDL 1.1 specification from the configuration, requiring heterogeneous system clients to be modified to achieve transparent interoperability. Fourth, configuration redundancy is severe in bidirectional conversion scenarios. Existing tools require writing two independent configurations for SOAP→JSON-RPC and JSON-RPC→SOAP, making it difficult to guarantee consistency.

[0034] To address the aforementioned issues, this application provides a mapping method.

[0035] Please see Figure 1 , Figure 1 This is a schematic diagram of the structural domain of a mapping system provided in an embodiment of this application. Figure 1 As shown, it includes the following: DSL configuration layer, intelligent conversion engine layer, and protocol gateway layer.

[0036] External callers include two types: SOAP clients and JSON-RPC clients, representing callers using the SOAP and JSON-RPC protocols, respectively. SOAP clients first initiate a WSDL query request to the gateway's WSDL generation interface (path 1), obtain the dynamically generated WSDL document, and then send a SOAP request to the SOAP request entry point (path 2). JSON-RPC clients, on the other hand, directly send a JSON-RPC request to the JSON-RPC request entry point (path 3), without needing to obtain the WSDL beforehand.

[0037] The protocol gateway layer, serving as the system's external entry point, provides three core endpoints: / smart-gateway / wsdl (dynamic WSDL generation interface), / smart-gateway / soap (SOAP request entry point), and / smart-gateway / jsonrpc (JSON-RPC request entry point). This layer is responsible for receiving external requests and routing them according to the path, forwarding SOAP requests to the SOAP→JSON-RPC conversion module, forwarding JSON-RPC requests to the JSON-RPC→SOAP conversion module, and forwarding WSDL query requests to the dynamic WSDL generation module.

[0038] The intelligent conversion engine layer comprises three functional modules: a dynamic WSDL generation module, a SOAP→JSON-RPC conversion module, and a JSON-RPC→SOAP conversion module. During execution, all conversion modules query the operation mapping table, parameter mapping rules, conversion rules, and gateway configuration in the DSL configuration layer to obtain the operation configuration and mapping logic. The SOAP→JSON-RPC conversion module receives a SOAP request, queries the forward mapping table to obtain the operation configuration, completes the protocol conversion, generates a JSON-RPC request, and forwards it to the real backend JSON-RPC service. Simultaneously, it receives the JSON-RPC response returned from the backend, reverse-converts it into a SOAP response, and returns it to the SOAP client. The JSON-RPC→SOAP conversion module performs the reverse conversion, queries the reverse mapping table to obtain the operation configuration, converts the JSON-RPC request into a SOAP request, forwards it to the real backend SOAP service, and then reverse-converts the SOAP response into a JSON-RPC response and returns it to the JSON-RPC client.

[0039] The DSL configuration layer stores the core configuration information that drives the entire system, including operation mapping tables (recording the bidirectional association between SOAP operation names and JSON-RPC method names), parameter mapping rules, conversion rules, and gateway configurations. These configurations exist in the form of YAML format DSL files, which are loaded and in-memory forward and reverse mapping tables are built when the system starts.

[0040] The actual backend services include a real JSON-RPC service and a real SOAP service. Requests, after being transformed by the gateway, are forwarded to the corresponding backend services. The responses from the backend services are then reverse-transformed by the gateway and returned to the original caller. Through this architecture, this system achieves bidirectional transparent proxying and protocol masquerading for both SOAP and JSON-RPC protocols.

[0041] Please see Figure 2 , Figure 2 This is a flowchart illustrating a mapping method provided in an embodiment of this application. Figure 2 As shown, it includes the following steps: Step S201: Define the DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs.

[0042] The DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node.

[0043] In one embodiment, the DSL configuration syntax includes at least the following nodes: Service definition node, operation mapping node, and global configuration node; The service definition node includes the service name, SOAP namespace, SOAP service address, and JSON-RPC service address; The operation mapping node contains a bidirectional association between SOAP operation names and JSON-RPC method names, operation type, parameter mapping list, response mapping configuration, and error mapping rules; The global configuration node includes type conversion rules, naming conventions, request ID generation strategies, error propagation rules, and gateway masquerading mode switches.

[0044] Specifically, the DSL configuration syntax includes at least the following three top-level nodes: The service definition node (services) contains the service name (name), SOAP namespace URI (namespace), SOAP service address (soapEndpoint), and JSON-RPC service address (jsonRpcEndpoint).

[0045] Operations: Located below the service definition node, it contains a set of operation configuration nodes. Each operation configuration node must contain at least the following: soapOperation: SOAP operation name; jsonRpcMethod: JSON-RPC method name, the two forming a bidirectional association; operationType: operation type (e.g., sync synchronous or async asynchronous); parameters: parameter mapping list, each parameter defining soapParam (SOAP parameter element name), jsonRpcParam (JSON-RPC parameter field name), type (parameter type), required (required), position (position number), contentType (content type, e.g., cdata or plain), nestedXml (whether it contains nested XML), xmlSchema (optional, used to specify the nested XML parsing strategy); response: response mapping configuration, including soapResponseElement (SOAP response value element name), jsonRpcResultField (JSON-RPC result field name), responseFormat (response format, e.g., xml or json), template (response XML template); errorMapping: error mapping rules, defining the correspondence between soapFaultCode and jsonRpcErrorCode, jsonRpcErrorMessage.

[0046] Global configuration nodes (transformationRules and gatewayConfig): contain type conversion rules, naming conventions, request ID generation strategy, error propagation rules, and gateway masquerading mode switches (such as jsonRpcToSoapProxy.enabled and soapToJsonRpcProxy.enabled).

[0047] Step S202: Parse the DSL configuration file and construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys.

[0048] The forward mapping table and the reverse mapping table both point to the same operation configuration object.

[0049] In one embodiment, parsing the DSL configuration file and constructing a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys includes: parsing the DSL configuration file to obtain all operation mapping nodes of the DSL configuration file; for each operation mapping node in the DSL configuration file, creating a first entry with SOAP operation names as keys and operation configuration objects as values, and a second entry with JSON-RPC method names as keys and operation configuration objects as values; summarizing the first entries corresponding to each operation mapping node to obtain a set of first entries corresponding to all operation mapping nodes; summarizing the second entries corresponding to each operation mapping node to obtain a set of second entries corresponding to all operation mapping nodes; inserting the set of first entries into a first table to construct a forward mapping table with SOAP operation names as keys, and inserting the set of second entries into a second table to construct a reverse mapping table with JSON-RPC method names as keys.

[0050] Parsing the DSL configuration file also includes verifying the integrity of the service definition, the operation definition, and the bidirectional mapping fields between SOAP operation names and JSON-RPC method names in the operation mapping node.

[0051] Specifically, when the system starts, the configuration manager reads and parses the aforementioned DSL configuration file to construct two memory hash mapping tables. The forward mapping table uses SOAP operation names as keys, and the reverse mapping table uses JSON-RPC method names as keys. Both tables point to the same operation configuration object, thus supporting O(1) time complexity queries in any direction.

[0052] In one embodiment, the parsing and construction process includes the following sub-steps: Sub-step 1: Parse the DSL configuration file and obtain all operation mapping nodes. The DSL parser reads the YAML file, converts it into an in-memory configuration object tree, and extracts all operation mapping nodes from the operations list under each service.

[0053] Sub-step 2: For each operation mapping node, establish bidirectional entries. For each operation mapping node, the system creates an operation configuration object (OperationConfig), which encapsulates all configuration information such as the parameter mapping list, response template, and error mapping rules for that operation. Then: Establish the first entry: with the soapOperation field value of the node as the key and the operation configuration object as the value; establish the second entry: with the jsonRpcMethod field value of the node as the key and the same operation configuration object as the value.

[0054] Sub-step 3: Summarize the first entries of all operation mapping nodes to obtain a set of first entries. Iterate through all operation mapping nodes and collect all first entries into a set.

[0055] Sub-step 4: Summarize the second entries of all operation mapping nodes to obtain a set of second entries. Similarly, collect all second entries into another set.

[0056] Sub-step 5: Insert into the hash table and build a forward and reverse mapping table. Insert all key-value pairs from the first set of entries into the first hash table (e.g., a HashMap in Java).<String,OperationConfig> The first step is to obtain the forward hash table (soapOperationMap); then, all key-value pairs from the second set of entries are inserted into the second hash table to obtain the reverse hash table (jsonRpcMethodMap).

[0057] To ensure configuration correctness, the parsing process includes verification steps: verifying the completeness of service definitions (checking if each service contains required fields such as name and namespace), the completeness of operation definitions (checking if each operation contains the soapOperation and jsonRpcMethod fields), and the completeness of the bidirectional mapping fields between SOAP operation names and JSON-RPC method names in the operation mapping nodes (ensuring both are not empty and unique within the same service). If verification fails, the system will throw a clear configuration error exception upon startup and terminate the startup process.

[0058] For example, for the first operation in the above configuration, the system will store the operation configuration object with "SyndocInf" as the key, and simultaneously store the same operation configuration object with "document.getInfo" as the key. The second operation is similar. The final forward mapping table contains the keys "SyndocInf" and "SyndocInf2", and the reverse mapping table contains the keys "document.getInfo" and "document.processVoucher".

[0059] Figure 3 This document illustrates a flowchart of the DSL configuration loading and operation mapping table construction provided in an embodiment of this application. Upon system startup, the `soapjsonrpc-config.yaml` configuration file is first read, and the DSL parser performs configuration verification. The verification process includes three key steps: Verification 1, checking if at least one service definition is included; Verification 2, checking if each service contains at least one operation definition; and Verification 3, checking if each operation is configured with both the `soapOperation` and `jsonRpcMethod` fields. If any verification fails, the system outputs an `IllegalArgumentException` and prevents system startup, ensuring the integrity and correctness of the configuration.

[0060] Once all verifications pass, the system begins constructing two in-memory hash mapping tables. First, a forward mapping table (soapOperationMap) is built, using the soapOperation name from each operation configuration node as the key and the complete operation configuration node as the value. Then, a reverse mapping table (jsonRpcMethodMap) is built, using the jsonRpcMethod name from each operation configuration node as the key and the complete operation configuration node as the value. The lookup time complexity for both mapping tables is O(1), ensuring efficient runtime lookups.

[0061] After the mapping table is built, the system further loads global conversion rules (such as type conversion, naming conventions, request ID generation strategies, etc.) and gateway configurations (such as masquerade mode switch, WSDL generation templates, etc.). Finally, the configuration loading is complete, and the system is ready to receive and process SOAP or JSON-RPC requests from clients. This process ensures the correct one-time loading of the DSL configuration and the rapid establishment of the bidirectional index, providing a foundation for subsequent protocol conversions.

[0062] Step S203: Receive HTTP request.

[0063] Specifically, after the protocol gateway layer starts, it listens on three HTTP endpoints: / smart-gateway / soap (SOAP protocol entry point), / smart-gateway / jsonrpc (JSON-RPC protocol entry point), and / smart-gateway / wsdl (WSDL document generation entry point). When an external client (SOAP client or JSON-RPC client) initiates an HTTP request, the gateway receives the request and distributes it according to the request path.

[0064] Step S204: Perform the corresponding conversion based on the HTTP request, the forward mapping table, and the reverse mapping table.

[0065] In one embodiment, the corresponding conversion is performed based on the HTTP request, the forward mapping table, and the reverse mapping table, including: if the access path of the HTTP request is the SOAP protocol entry path, then the SOAP operation name in the HTTP request is extracted, the forward mapping table is queried to obtain the operation configuration, so as to perform the SOAP to JSON-RPC request conversion and the corresponding response inverse conversion; if the access path of the HTTP request is the JSON-RPC protocol entry path, then the method field in the HTTP request is extracted, the reverse mapping table is queried to obtain the operation configuration, so as to perform the JSON-RPC to SOAP request conversion and the corresponding response inverse conversion; if the access path of the HTTP request is the WSDL document generation entry path, then the WSDL document is dynamically generated and returned according to the service definition and operation mapping list in the DSL configuration file.

[0066] The process of converting SOAP requests to JSON-RPC includes: extracting the parameter values ​​corresponding to each parameter from the parsed SOAP request XML according to the parameter mapping list in the operation configuration; constructing a JSON-RPC request object, where the method field is set to the JSON-RPC method name in the operation configuration, the params field is set to the extracted parameter values, and the id field is generated according to a preset strategy; and serializing the JSON-RPC request object into a JSON string and outputting it.

[0067] The process of converting a JSON-RPC request to SOAP includes: parsing the JSON-RPC request and extracting the method, params, and id fields; querying the reverse mapping table based on the method field to obtain the operation configuration, creating a SOAP envelope, and setting a namespace for the SOAP envelope; according to the parameter mapping list in the operation configuration, taking values ​​from the extracted params field to construct sub-elements for each SOAP parameter and adding them to the body of the SOAP envelope; writing the extracted id field into a custom header field in the header of the SOAP envelope; and serializing the completed SOAP envelope into an XML string and outputting it.

[0068] The process involves dynamically generating a WSDL document based on the service definitions and operation mapping lists in the DSL configuration file. This includes: reading the service name, namespace, and operation mapping list from the DSL configuration file; dynamically generating the corresponding XSD Schema as the types section of the WSDL document based on the parameter type definition of each operation in the operation mapping list; traversing each operation in the operation mapping list and generating a message definition, an operation definition in portType, and an operation binding in binding for each operation; generating a service definition and setting the port address in the service definition to the gateway's own SOAP entry address; and integrating the types section, message definition, operation definition in portType, operation binding in binding, and service definition to dynamically generate the WSDL document.

[0069] Specifically, the protocol gateway layer executes different conversion logic based on the access path of the HTTP request and the pre-built forward and reverse mapping table. This can be divided into three cases: Scenario 1: The HTTP request access path is the SOAP protocol entry path ( / smart-gateway / soap). In this case, the gateway performs SOAP to JSON-RPC request conversion and the corresponding inverse response conversion. The specific steps are as follows: Sub-step 1: Extract the SOAP operation name. Parse the SOAP XML from the HTTP request body to obtain the SOAP operation name by reading the SOAPActionHTTP header or parsing the local name (ignoring namespaces) of the first child element in the SOAP Body. For example, for the following SOAP request: <soap:envelope xmlns:soap="http: / / schemas.xmlsoap.org / soap / envelope / "> <soap:body> <syndocinf xmlns="http: / / syn.doc.itf.hk / ISynBasedoc"> <string><![CDATA[ <voucher> ...< / voucher> ]]>< / string> < / syndocinf> < / soap:body> < / soap:envelope> The extracted SOAP operation is named "SyndocInf".

[0070] Sub-step 2: Query the forward mapping table to obtain the operation configuration. Using the extracted SOAP operation name as the key, retrieve the corresponding operation configuration object from soapOperationMap. If the query fails (i.e., the operation does not exist in the configuration), a SOAP Fault response is returned with error code soap:Server and error message "Operation mapping not found".

[0071] Sub-step 3: Perform a SOAP to JSON-RPC request conversion. This conversion further includes extracting the parameter values ​​corresponding to each parameter from the parsed SOAP request XML based on the parameter mapping list in the operation configuration. Specifically, for each parameter definition, locate the child element with the same name as soapParam in the SOAP Body. If contentType is cdata, extract the CDATA section content; if nestedXml is true, retain the XML within the child element as a string. The extracted values, sorted by position, can be constructed into an array or a key-value pair object.

[0072] Construct a JSON-RPC request object: Set the `method` field to the `jsonRpcMethod` in the operation configuration; set the `params` field to the parameter values ​​extracted in the previous step; generate the `id` field according to a preset strategy, such as using a UUID (if `requestIdGeneration.strategy` is `uuid`) or a timestamp. For the example above, the generated JSON-RPC request object is: {"jsonrpc":"2.0", "method":"document.getInfo", "params": {"documentXml": " <voucher> ...< / voucher> "}, "id": "550e8400-e29b-41d4-a716-446655440000"} The JSON-RPC request object is serialized into a JSON string and forwarded to the backend JSON-RPC service via HTTP POST (the address is taken from jsonRpcEndpoint in the service configuration).

[0073] Sub-step 4: Receive the backend JSON-RPC response and perform inverse response transformation. After the backend JSON-RPC service returns the response: parse the JSON response. If the response contains an error field, map the JSON-RPC error code and error message to the SOAP Fault's faultcode and faultstring according to the errorMapping rules in the operation configuration, and construct a SOAPFault response to return.

[0074] If it is a normal response (containing a result field), the value is extracted from the result according to the response.jsonRpcResultField, and the template is populated according to response.responseFormat (such as xml) and response.template (for example, replacing {bdocid} with the actual value) to generate SOAP Body content, and then encapsulated in SOAP Envelope and returned to the client.

[0075] Scenario 2: The HTTP request access path is the JSON-RPC protocol entry path ( / smart-gateway / jsonrpc). In this case, the gateway performs JSON-RPC to SOAP request conversion and the corresponding inverse response conversion. The specific steps are as follows: Sub-step 1: Parse the JSON-RPC request and extract the method, params, and id fields. Parse the JSON string in the HTTP request body to obtain the method, params, and id fields. If the request does not conform to the JSON-RPC 2.0 specification (e.g., the method field is missing), return standard error code -32600.

[0076] Sub-step 2: Query the reverse mapping table to obtain the operation configuration. Using the extracted method as the key, retrieve the operation configuration object from jsonRpcMethodMap. If the query fails, return a JSON-RPC error: {"jsonrpc":"2.0", "error":{"code":-32601,"message":"Method not found"}, "id": null}.

[0077] Sub-step 3: Perform the JSON-RPC to SOAP request conversion. This conversion further includes: creating a SOAP envelope object and setting the SOAP namespace (taken from the namespace in the service configuration).

[0078] Based on the parameter mapping list in the operation configuration, extract the value corresponding to each jsonRpcParam from JSONparams, and create a SOAP child element (element name soapParam) for each parameter. If the parameter type is xml and contentType is cdata, wrap the value as a CDATA node. Add all child elements to the SOAP Body.

[0079] Write the id field value of the original request into the custom header field X-Request-ID of the SOAP Header so that it can be populated back in the response.

[0080] Serialize the SOAP envelope into an XML string. For example, for the `document.processVoucher` method in the above configuration, the input JSONparams are `{"batchNumber":"B2024001","systemCode":"ERP","voucherData":"`. <data>...< / data> The generated SOAP request body is: <soap:envelope xmlns:soap="http: / / schemas.xmlsoap.org / soap / envelope / "> <soap:header> <x-request-id> 123< / x-request-id> < / soap:header> <soap:body> <syndocinf2 xmlns="http: / / syn.doc.itf.hk / ISynBasedoc"> <string> B2024001< / string> <string1> ERP< / string1> <string2><![CDATA[ <data>...< / data> ]]> < / syndocinf2> < / soap:body> < / soap:envelope> The SOAP request is forwarded to the backend SOAP service via HTTP POST (the address is taken from soapEndpoint).

[0081] Sub-step S4: Receive the backend SOAP response and perform inverse response transformation. After the backend SOAP service returns the response: parse the SOAP response XML. If the response contains a Fault element, convert the SOAP Fault to a JSON-RPC error object according to the errorMapping rules and backfill the original id.

[0082] If it is a normal response, locate the element specified by response.soapResponseElement in the SOAP Body, extract its text content or sub-XML, and construct a normal JSON-RPC response: {"jsonrpc":"2.0", "result": extracted value, "id": the original id recovered from the Header}.

[0083] Scenario 3: The HTTP request access path is the WSDL document generation entry path ( / smart-gateway / wsdl). In this case, the gateway dynamically generates a WSDL document conforming to the WSDL 1.1 specification based on the service definitions and operation mapping list in the DSL configuration file and returns it. The specific steps are as follows: Sub-step 1: Read the service name, namespace, and operation mapping list from the DSL configuration file. Locate the corresponding service configuration based on the service name in the request parameters (e.g., ?service=DocumentService).

[0084] Sub-step 2: Generate the types section. Iterate through the parameter definitions for each operation in the operation mapping list, dynamically generating the corresponding XSD Schema type definition for each parameter (e.g., for the xsd:string type parameter, generate...).<xsd:elementname="string" type="xsd:string" / > For complex types, generate anonymous complex types. These definitions are then summarized into... <types>In the section.

[0085] Sub-step 3: Generate message definitions. Generate input messages for each operation separately. <message name="操作名Request">) and output messages ( <message name="操作名Response">The part element of the message references the element generated in step S2042C.

[0086] Sub-step 4: Generate the operation definition in portType. <porttype>Under the node, define each operation. <operation>, specifies the input and output messages.

[0087] Sub-step 5: Generate operation bindings in the binding. <binding>Under the node, each operation in portType is bound to the SOAP 1.1 protocol, via... <soap:binding>Specify the transport protocol and style, through <soap:operation>Specify the SOAPAction value.

[0088] Sub-step 6: Generate the service definition. <service>and <port>,in <soap:addresslocation>Set it to the gateway's own SOAP entry address (e.g., http: / / gateway.example.com / smart-gateway / soap), instead of the address of the backend JSON-RPC service. This setting achieves protocol masquerading, making SOAP clients unaware that the backend is actually using the JSON-RPC protocol.

[0089] Sub-step 7: Integrate and output the WSDL document. Combine the generated types, message, portType, binding, service, and other nodes into a complete XML document according to the WSDL 1.1 specification, set Content-Type: application / wsdl+xml, and return it to the client.

[0090] For example, for the DocumentService mentioned above, the generated WSDL will contain two operations, SyndocInf and SyndocInf2, whose port addresses point to the / smart-gateway / soap endpoint of the gateway. Mainstream SOAP client tools (such as wsimport) can automatically generate proxy code based on this WSDL and make normal calls.

[0091] Figure 4 The diagram illustrates a request routing flowchart for the protocol gateway layer provided in an embodiment of this application. Upon receiving an HTTP request, the protocol gateway layer first determines the access path of the request and then proceeds to one of three processing branches based on the path: / smart-gateway / wsdl, / smart-gateway / jsonrpc, and / smart-gateway / soap.

[0092] Branch 1: WSDL generation path ( / smart-gateway / wsdl). The gateway reads the wsdlGeneration configuration in gatewayConfig and checks if autoGenerate is true. If true, it calls the dynamic WSDL generation module to dynamically generate a document conforming to the WSDL 1.1 specification based on the DSL service definition and operation mapping list, and returns the WSDL XML to the SOAP client; if false, it returns a predefined static WSDL document.

[0093] Branch 2: JSON-RPC request path ( / smart-gateway / jsonrpc). The gateway parses the JSON request body, extracting the method, params, and id fields. It queries the reverse mapping table (jsonRpcMethodMap) using the method value as the key. If the corresponding operation configuration is not found, a standard JSON-RPC error response is returned (error.code=-32601, method does not exist); if the operation configuration is found, the JSON-RPC to SOAP conversion module is called to convert the JSON-RPC request to a SOAP request before forwarding it to the backend SOAP service. Upon receiving the backend SOAP response, the gateway performs a reverse conversion from SOAP to JSON-RPC, ultimately returning a JSON-RPC response to the caller.

[0094] Branch 3: SOAP Request Path ( / smart-gateway / soap). The gateway uses a namespace-aware XML parser to parse the SOAP request body, extracting the local name of the operation element as the SOAP operation name. It then queries the forward mapping table (soapOperationMap) using this operation name as the key. If the operation configuration is not found, a smart fallback mode is activated (e.g., attempting to extract general parameters or returning an error); if the operation configuration is found, the SOAP to JSON-RPC conversion module is called to convert the SOAP request to a JSON-RPC request before forwarding it to the backend JSON-RPC service. Upon receiving the backend JSON-RPC response, the gateway performs a reverse conversion from JSON-RPC to SOAP, ultimately returning a SOAP response to the caller.

[0095] Through the above three-way distribution, this gateway realizes bidirectional transparent conversion between SOAP and JSON-RPC protocols and dynamic generation of WSDL.

[0096] Figure 5 A flowchart of the dynamic WSDL generation method provided in this application embodiment is shown. When a SOAP client initiates a GET / smart-gateway / wsdl?service=service_name request, the WSDL generator first reads the service name in the request parameters, and then searches for the corresponding service definition in the services list configured in the DSL to obtain the service name, namespace URI, service address, and operation list.

[0097] Based on the acquired service information, the WSDL generator creates the WSDL's definitions root element, sets the target namespace, and declares a set of XML namespaces (such as wsdl, soap, xsd, etc.). It then generates the five core nodes of the WSDL sequentially: 1. Generate wsdl:types nodes: For each operation, generate a request model and a response model. The request model is named "Operation Name + Request", and an xsd:element definition is generated for each parameter under the operation, setting the name to soapParam and the type to the corresponding XSD type (such as xsd:string). The response model is named "Operation Name + Response", and contains the definition of the return value element.

[0098] 2. Generate wsdl:message nodes: Generate input messages (referencing request model) and output messages (referencing response model) for each operation.

[0099] 3. Generate wsdl:portType node: Generate wsdl:operation node for each operation, and set input and output to reference the corresponding input and output messages respectively.

[0100] 4. Generate wsdl:binding node: Set the binding type to SOAP 1.1 and set the soapAction property of soap:operation for each operation (taken from the operation name or namespace combination in the DSL configuration).

[0101] 5. Generate the wsdl:service node: Define the wsdl:port port, and its soap:address location address points to the gateway's own SOAP entry address (i.e., / smart-gateway / soap), rather than the actual address of the backend JSON-RPC service. This crucial setting achieves protocol masquerading, making SOAP clients completely unaware that the backend uses the JSON-RPC protocol.

[0102] Finally, the entire DOM tree is serialized into a standard XML string conforming to the WSDL 1.1 specification and returned to the SOAP client with Content-Type: text / xml. The client can then automatically generate proxy code based on this WSDL and invoke the gateway normally.

[0103] Figure 6 A flowchart illustrating how a JSON-RPC service is disguised as a SOAP service, as provided in an embodiment of this application, is illustrated. In this scenario, the SOAP client interacts with the protocol gateway, while the backend actually provides a JSON-RPC service, but the client is completely unaware of this protocol difference.

[0104] Step 1: Obtain the WSDL document. The SOAP client first sends a GET request to the protocol gateway at the path / smart-gateway / wsdl?service=DocumentService (in this example, / smart-gateway / wsdServer / DocumentService). Upon receiving the request, the gateway reads the DSL configuration and calls the dynamic WSDL generation module to dynamically generate a document conforming to the WSDL 1.1 specification based on the service definitions and operation mapping list, and returns it to the SOAP client. The client then generates client proxy code based on this WSDL for subsequent calls.

[0105] Step 2: SOAP Request Conversion. The SOAP client sends a SOAP request (e.g., a SyndocInf operation) to the gateway using the generated proxy code. Upon receiving the SOAP request, the gateway performs a SOAP→JSON-RPC conversion (see other patent descriptions in this application for conversion details), converting the SOAP request into a JSON-RPC request, where the method field is set to document.getInfo, and then forwards the request to the actual JSON-RPC backend service.

[0106] Step 3: Response Reverse Conversion. After processing the request, the JSON-RPC backend service returns a JSON-RPC response (containing a result or error field). Upon receiving this response, the gateway performs a reverse conversion from JSON-RPC to SOAP, returning the converted SOAP response to the SOAP client. At this point, the SOAP client has completed a full call, remaining completely unaware that the backend is using the JSON-RPC protocol, thus achieving protocol spoofing.

[0107] Figure 7 A flowchart illustrating the SOAP service disguised as a JSON-RPC service provided in an embodiment of this application is shown. In this scenario, the JSON-RPC client interacts directly with the protocol gateway. The gateway converts the request into the SOAP protocol, calls the real SOAP service in the backend, and then reverse-converts the response back into JSON-RPC format and returns it to the client.

[0108] Step 1: Send a JSON-RPC request. The JSON-RPC client sends a request conforming to the JSON-RPC 2.0 specification to the protocol gateway, for example: {"method":"document.getInfo","params":{...},"id":"req-001"}. This request includes the method name, parameters, and a request identifier id.

[0109] Step 2: Request Conversion and Forwarding. After receiving the JSON-RPC request, the protocol gateway performs a JSON-RPC→SOAP conversion (see other patent descriptions in this application for conversion details), converting the JSON-RPC request into a corresponding SOAP request (e.g., a SyndocInf operation), and forwards it to the backend's actual SOAP service.

[0110] Step 3: Response Transformation and Return. After processing, the backend SOAP service returns a SOAP response (either a normal response or a SOAP Fault). Upon receiving this response, the gateway performs a reverse transformation from SOAP response to JSON-RPC response: if it's a normal SOAP response, it's converted to a JSON-RPC result object; if it's a SOAP Fault, it's converted to a JSON-RPC error object (error codes and error messages are converted according to mapping rules). After the transformation, the gateway returns the JSON-RPC response (e.g., {"jsonrpc":"2.0","result":[...],"id":"req-001"}) to the JSON-RPC client. Throughout this process, the JSON-RPC client can call the SOAP backend service without any modification, effectively disguising the SOAP service as a JSON-RPC service.

[0111] This application provides a mapping method, including: defining a DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; parsing the DSL configuration file to construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward and reverse mapping tables point to the same operation configuration object; receiving an HTTP request; and performing corresponding conversions based on the HTTP request, the forward mapping table, and the reverse mapping table. By designing the DSL configuration syntax, this application allows developers to simultaneously declare the correspondence between SOAP operation names and JSON-RPC method names, as well as complete parameter mappings, response templates, and error rules in a single YAML configuration node. This ensures that adding a new operation mapping only requires adding configuration code, without modifying any program code, thus improving positioning accuracy and efficiency. Simultaneously, clients of both SOAP and JSON-RPC protocol systems can communicate transparently without any modification; configuration redundancy is eliminated, and the consistency of bidirectional mapping is ensured, further improving positioning accuracy and efficiency.

[0112] 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 application.

[0113] The following are device embodiments of this application. For details not described in detail, please refer to the corresponding method embodiments described above.

[0114] Figure 8 This diagram illustrates a mapping device according to an embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown. The mapping device includes: Configuration syntax module 801 is used to define DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; The mapping table construction module 802 is used to parse the DSL configuration file and construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward mapping table and the reverse mapping table point to the same operation configuration object. Request receiving module 803 is used to receive HTTP requests; The conversion module 804 is used to perform corresponding conversions based on the HTTP request, the forward mapping table, and the reverse mapping table.

[0115] In one embodiment, the DSL configuration syntax includes at least the following nodes: Service definition node, operation mapping node, and global configuration node; The service definition node includes the service name, SOAP namespace, SOAP service address, and JSON-RPC service address; The operation mapping node contains a bidirectional association between SOAP operation names and JSON-RPC method names, operation type, parameter mapping list, response mapping configuration, and error mapping rules; The global configuration node includes type conversion rules, naming conventions, request ID generation strategies, error propagation rules, and gateway masquerading mode switches.

[0116] In one embodiment, the mapping table construction module 802 is also used to parse the DSL configuration file and obtain all operation mapping nodes of the DSL configuration file; For each operation mapping node in all operation mapping nodes of the DSL configuration file, create a first entry with SOAP operation name as the key and operation configuration object as the value, and a second entry with JSON-RPC method name as the key and operation configuration object as the value; Summarize the first entry corresponding to each operation mapping node to obtain the set of first entries corresponding to all operation mapping nodes; Summarize the second entries corresponding to each operation mapping node to obtain the set of second entries corresponding to all operation mapping nodes; Insert the first set of entries into the first table to build a forward mapping table with SOAP operation names as keys, and insert the second set of entries into the second table to build a reverse mapping table with JSON-RPC method names as keys.

[0117] In one embodiment, the mapping table construction module 802 is also used to verify the integrity of the service definition, the integrity of the operation definition, and the integrity of the bidirectional mapping fields between SOAP operation names and JSON-RPC method names in the operation mapping node.

[0118] In one embodiment, the conversion module 804 is further configured to extract the SOAP operation name in the HTTP request, query the forward mapping table to obtain the operation configuration if the access path of the HTTP request is the SOAP protocol entry path, so as to perform SOAP to JSON-RPC request conversion and corresponding response inverse conversion. If the access path of the HTTP request is the entry path of the JSON-RPC protocol, then the method field in the HTTP request is extracted, the reverse mapping table is queried to obtain the operation configuration, so as to perform the request conversion from JSON-RPC to SOAP and the corresponding response inverse conversion. If the HTTP request access path is the WSDL document generation entry path, then the WSDL document is dynamically generated and returned based on the service definition and operation mapping list in the DSL configuration file.

[0119] In one embodiment, the conversion module 804 is further configured to extract the parameter values ​​corresponding to each parameter from the parsed SOAP request XML according to the parameter mapping list in the operation configuration; Construct a JSON-RPC request object, where the method field is set to the JSON-RPC method name in the operation configuration, the params field is set to the extracted parameter values, and the id field is generated according to a preset strategy; Serialize the JSON-RPC request object into a JSON string and output it.

[0120] In one embodiment, the conversion module 804 is further configured to parse the JSON-RPC request and extract the method field, params field, and id field; After retrieving the operation configuration from the reverse mapping table based on the method field, create a SOAP envelope and set a namespace for the SOAP envelope; Based on the parameter mapping list in the operation configuration, the values ​​of each SOAP parameter are sequentially taken from the extracted params field to construct sub-elements, which are then added to the Body of the SOAP envelope. Write the extracted id field into a custom header field in the Header of the SOAP envelope; Serialize the completed SOAP envelope into an XML string and output it.

[0121] In one embodiment, the conversion module 804 is further configured to read the service name, namespace, and operation mapping list from the DSL configuration file; Based on the parameter type definition of each operation in the operation mapping list, dynamically generate the corresponding XSD Schema as the types section of the WSDL document; Iterate through each operation in the operation mapping list and generate a message definition, an operation definition in portType, and an operation binding in binding for each operation; Generate a service definition and set the port address in the service definition to the gateway's own SOAP ingress address; The WSDL document is dynamically generated by integrating the types section, message definition, operation definition in portType, operation binding in binding, and service definition.

[0122] This application provides a mapping device specifically used for: defining a DSL configuration syntax dedicated to SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; parsing the DSL configuration file to construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward and reverse mapping tables point to the same operation configuration object; receiving HTTP requests; and performing corresponding conversions based on the HTTP request, the forward mapping table, and the reverse mapping table. By designing the DSL configuration syntax, this application allows developers to simultaneously declare the correspondence between SOAP operation names and JSON-RPC method names, as well as complete parameter mappings, response templates, and error rules in a single YAML configuration node. This ensures that adding a new operation mapping only requires adding configuration code, without modifying any program code, thus improving positioning accuracy and efficiency. Simultaneously, clients of both SOAP and JSON-RPC protocol systems can communicate transparently without any modification; configuration redundancy is eliminated, and the consistency of bidirectional mapping is ensured, further improving positioning accuracy and efficiency.

[0123] This application Figure 9 A schematic diagram of a computer device is provided. (Example) Figure 9 As shown, the computer device 9 in this embodiment includes a processor 901, a memory 902, and a computer program 909 stored in the memory 902 and executable on the processor 901. When the processor 901 executes the computer program 909, it implements the steps in the various mapping method embodiments described above, for example... Figure 2 Steps 201 to 204 are shown. Alternatively, when processor 901 executes computer program 909, it implements the functions of each module / unit in the above-described mapping device embodiments, for example... Figure 8 The functions of modules / units 801 to 804 shown.

[0124] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the mapping methods provided in the various embodiments described above.

[0125] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0126] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the execution of the executable instructions by the at least one processor causes the device to implement the mapping methods provided in the various embodiments described above.

[0127] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0128] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 application.< / soap:addresslocation> < / port> < / service> < / soap:operation> < / soap:binding> < / binding> < / operation> < / porttype> < / message> < / message> < / types>

Claims

1. A mapping method, characterized by, include: Define a DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; The DSL configuration file is parsed to construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward mapping table and the reverse mapping table point to the same operation configuration object; Receive HTTP requests; Perform the corresponding transformation based on the HTTP request, the forward mapping table, and the reverse mapping table.

2. The mapping method of claim 1, wherein, The DSL configuration syntax includes at least the following nodes: Service definition node, operation mapping node, and global configuration node; The service definition node includes the service name, SOAP namespace, SOAP service address, and JSON-RPC service address; The operation mapping node contains a bidirectional association between SOAP operation names and JSON-RPC method names, operation types, parameter mapping lists, response mapping configurations, and error mapping rules. The global configuration node includes type conversion rules, naming conventions, request ID generation strategies, error propagation rules, and gateway masquerading mode switches.

3. The mapping method of claim 1, wherein, The process of parsing the DSL configuration file and constructing a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys includes: Parse the DSL configuration file to obtain all operation mapping nodes of the DSL configuration file; For each operation mapping node in all operation mapping nodes of the DSL configuration file, create a first entry with the SOAP operation name as the key and the operation configuration object as the value, and a second entry with the JSON-RPC method name as the key and the operation configuration object as the value; The first entries corresponding to each operation mapping node are summarized to obtain a set of first entries corresponding to all operation mapping nodes; The second entries corresponding to each operation mapping node are summarized to obtain a set of second entries corresponding to all operation mapping nodes; Insert the first set of entries into the first table to construct a forward mapping table with SOAP operation names as keys, and insert the second set of entries into the second table to construct a reverse mapping table with JSON-RPC method names as keys.

4. The mapping method of claim 3, wherein, The parsing of the DSL configuration file also includes: Verify the integrity of the service definition, the operation definition, and the bidirectional mapping fields between SOAP operation names and JSON-RPC method names in the operation mapping node.

5. The mapping method as described in claim 1, characterized in that, The step of performing the corresponding conversion based on the HTTP request, the forward mapping table, and the reverse mapping table includes: If the access path of the HTTP request is the SOAP protocol entry path, then the SOAP operation name in the HTTP request is extracted, the forward mapping table is queried to obtain the operation configuration, so as to perform the SOAP to JSON-RPC request conversion and the corresponding response inverse conversion. If the access path of the HTTP request is the JSON-RPC protocol entry path, then the method field in the HTTP request is extracted, the reverse mapping table is queried to obtain the operation configuration, so as to perform the JSON-RPC to SOAP request conversion and the corresponding response reverse conversion; If the access path of the HTTP request is the WSDL document generation entry path, then the WSDL document is dynamically generated and returned according to the service definition and operation mapping list in the DSL configuration file.

6. The mapping method as described in claim 5, characterized in that, The process of performing the SOAP to JSON-RPC request conversion includes: Based on the parameter mapping list in the operation configuration, extract the parameter values ​​corresponding to each parameter from the parsed SOAP request XML; Construct a JSON-RPC request object, where the method field is set to the JSON-RPC method name in the operation configuration, the params field is set to the extracted parameter values, and the id field is generated according to a preset strategy; Serialize the JSON-RPC request object into a JSON string and output it.

7. The mapping method as described in claim 5, characterized in that, The process of performing the JSON-RPC to SOAP request conversion includes: Parse the JSON-RPC request and extract the method, params, and id fields; After obtaining the operation configuration by querying the reverse mapping table based on the method field, a SOAP envelope is created and a namespace is set for the SOAP envelope; According to the parameter mapping list in the operation configuration, the values ​​of each SOAP parameter are sequentially taken from the extracted params field to construct sub-elements, which are then added to the Body of the SOAP envelope. Write the extracted id field into a custom header field in the Header of the SOAP envelope; Serialize the completed SOAP envelope into an XML string and output it.

8. The mapping method as described in claim 5, characterized in that, The step of dynamically generating a WSDL document based on the service definitions and operation mapping list in the DSL configuration file includes: Read the service name, namespace, and operation mapping list from the DSL configuration file; Based on the parameter type definition of each operation in the operation mapping list, the corresponding XSD Schema is dynamically generated as the types section of the WSDL document; Iterate through each operation in the operation mapping list and generate a message definition, an operation definition in portType, and an operation binding in binding for each operation; Generate a service definition and set the port address in the service definition to the gateway's own SOAP ingress address; The WSDL document is dynamically generated by integrating the types section, the message definition, the operation definition in the portType, the operation binding in the binding, and the service definition.

9. A mapping device, characterized in that, include: The configuration syntax module is used to define a DSL configuration syntax specifically for SOAP and JSON-RPC protocol pairs, wherein the DSL configuration syntax declares at least a bidirectional association between SOAP operation names and JSON-RPC method names in a single configuration node; The mapping table construction module is used to parse the DSL configuration file and construct a forward mapping table with SOAP operation names as keys and a reverse mapping table with JSON-RPC method names as keys, wherein the forward mapping table and the reverse mapping table point to the same operation configuration object; The request receiving module is used to receive HTTP requests; The conversion module is used to perform corresponding conversions based on the HTTP request, the forward mapping table, and the reverse mapping table.

10. A computer device, characterized in that, Includes a memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors to cause the one or more processors to implement the mapping method as described in any one of claims 1 to 8.

Images