Method for generating a proxy and method for invoking a service

Abstract

The application is suitable for the technical field of software development and code generation, and provides a proxy generation method and a service calling method. The proxy generation method comprises the following steps: obtaining a source code project before the compilation of the source code project in a native programming language; identifying a service identifier, a service interface and a service implementation in the source code project to generate a scanning result; analyzing the scanning result to generate an analysis model; and generating a code file of a calling-end proxy and a code file of a service-end proxy according to the analysis model. According to the application, when the service interface changes, the code of the calling end and the service end can be updated synchronously without maintaining an independent description file, the consistency of the code of the calling end and the service end with the actual interface definition can be ensured, and the maintenance cost is reduced.

Description

Technical Field

[0001] This application belongs to the field of software development and code generation technology, and in particular relates to a delegate generation method and a service invocation method. Background Technology

[0002] With the development of distributed and modular software systems, remote calls between services have become commonplace. To shield communication details and reduce coupling between the caller and the service provider, delegation mechanisms are often introduced, enabling the caller to access remote services through a local interface.

[0003] In related technologies, delegation and proxy typically use an independent interface description file as the basis for generation. That is, the interface description file is written first, and then the tool generates the calling and server code based on the interface description file.

[0004] However, the above method relies heavily on a separate interface description file. Any change to the service interface requires simultaneous modification of the interface description file and regeneration of the caller and server code, which increases maintenance costs. Summary of the Invention

[0005] This application provides a proxy generation method and a service invocation method. When the service interface changes, the code of the calling end and the service end can be updated synchronously without maintaining an independent description file. This can ensure the consistency between the code of the calling end and the service end and the actual interface definition, and reduce maintenance costs.

[0006] In a first aspect, embodiments of this application provide a method for generating a proxy, including: Obtain the source code project before the compilation phase of the source code project in the native programming language; Identify service identifiers, service interfaces, and service implementations in the source code project and generate scan results; service identifiers are used to mark the services delegated to the proxy, service interfaces are used to declare the calling methods of the proxy, and service implementations include the business implementation logic that matches the calling methods in the service interfaces; The scan results are analyzed to generate an analytical model; Based on the parsing model, generate the code files for the calling end delegate and the server end delegate.

[0007] In one possible implementation of the first aspect, identifying service identifiers, service interfaces, and service implementations in the source code project and generating scan results includes: determining target source code files based on the configuration information and preset filtering rules of the source code project; the preset filtering rules are used to exclude source code files in the source code project that do not participate in the generation of the delegated proxy; identifying the tag definitions used to identify services in the target source code files as service identifiers; identifying the interface declarations associated with the service identifiers in the target source code files as service interfaces; identifying the business implementation logic in the target source code files that matches the method calls in the service interfaces as service implementations; and determining the scan results based on the service identifiers, service interfaces, and service implementations.

[0008] In one possible implementation of the first aspect, the parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model; parsing the scan results to generate the parsing model includes: constructing a service interface model based on the correspondence between service identifiers and service interfaces in the scan results; parsing the call methods to construct a call signature model; and classifying and parsing the data structures involved in the call methods to construct a data structure model. Based on the service implementation information in the scan results, construct a service implementation model.

[0009] In one possible implementation of the first aspect, the data structures involved in the method call are classified and parsed to construct a data structure model, including: obtaining each data structure and its data type in the method call; the data structure includes parameters, return values, object fields, collection elements, and mapping keys; for each data type, the type classification in the type system is determined based on the structural characteristics of the data type; the sub-class of the data type in the type classification is determined based on the semantic information of the data type; the data type is parsed to determine its internal structural composition information; type metadata corresponding to the data type is generated based on the data type, type classification, sub-class, and internal structural composition information; and a data structure model is generated based on each data structure and its corresponding type metadata.

[0010] In one possible implementation of the first aspect, the parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model. Based on the parsing model, code files for the caller-side delegation proxy and the server-side delegation proxy are generated, including: generating a request parameter model and a response result model corresponding to each call method based on the call signature model; the request parameter model describes the first description information and the first runtime parameter storage information of each parameter in a single call request of the call method, and the response result model describes the second description information and the second runtime parameter storage information of each returned result in a single call response of the call method; generating a caller-side proxy method corresponding to the service interface based on the service interface model and the call signature model, and configuring the request parameter model and the response result model in the caller-side proxy method to form the code file for the caller-side delegation proxy; generating a server-side proxy method based on the service interface model, the call signature model, and the service implementation model, and configuring the request parameter model in the server-side proxy method to form the code file for the server-side delegation proxy.

[0011] In one possible implementation of the first aspect, the delegate generation method further includes: when generating the code file of the caller-side delegate and the code file of the server-side delegate, constructing a runtime binding model based on the structured data types in the data structure model; the runtime binding model is used to complete data creation, assignment, and / or writing operations when processing structured data types at runtime; and writing the runtime binding model into the request parameter model and the response result model respectively.

[0012] In one possible implementation of the first aspect, when the structured data type is an object type, the runtime binding model includes an object binding model, which describes the correspondence between the field metadata of the object type and the fields written at runtime; when the structured data type is a collection type, the runtime binding model includes a collection binding model, which describes the correspondence between the element metadata of the collection type and the element creation and addition methods at runtime; when the structured data type is a mapping type, the runtime binding model includes a mapping binding model, which describes the correspondence between the value type metadata of the mapping type and the value creation and key-value writing methods at runtime.

[0013] Secondly, embodiments of this application provide a service invocation method applied to a calling device, the calling device being configured with a calling-end proxy code file generated by the proxy generation method as described in any of the first aspects; the service invocation method includes: Obtain the call request for the target service interface; the call request includes the call parameters; Based on the call request, determine the service category information and operation type information corresponding to the target service interface, and write the service category information and operation type information into the unified transmission object; Based on the request parameter model configured in the code file of the calling end delegate, the calling parameters are written into the request data field of the unified transport object; Encode the Uniform Transport Object into request data; Send request data to the server device and receive response data from the server device in response to the request data; Decode the response data into a Uniform Transport Object and obtain the response data fields of the Uniform Transport Object; Based on the response result model configured in the code file of the calling end's delegate, the response data fields are converted into the return result of the target service interface.

[0014] Thirdly, embodiments of this application provide a service invocation method applied to a server-side device, the server-side device being configured with a server-side delegate code file generated by the delegate generation method as described in any of the first aspects; the service invocation method includes: Receive request data sent by the calling device; Decode the request data into a Uniform Transport Object; Based on the service category information of the unified transport object, locate the target service of the unified transport object in the code file of the server-side delegated proxy; Based on the operation type information of the unified transmission object, locate the target invocation method in the target service; Based on the request parameter model configured in the server-side delegated proxy code file, the parameter data under the request data field of the unified transmission object is converted into parameter values; Use the parameter values ​​to call the target method and obtain the call result; Based on the call result, determine the response data fields of the unified transmission object; The unified transmission object is encoded into response data and returned to the calling device.

[0015] In one possible implementation of the third aspect, the parameter data under the request data field of the unified transmission object is converted into parameter values ​​according to the request parameter model configured in the code file of the server-side delegation proxy. This includes: determining the type classification corresponding to the parameter data under the request data field of the unified transmission object according to the first description information of the request parameter model configured in the code file of the server-side delegation proxy; in the case of basic type classification, determining the specific basic type of the parameter data under the basic type classification according to the first description information in the request parameter model, and converting the parameter data into the corresponding parameter value according to the specific basic type; in the case of structured type classification, determining the specific structured data type corresponding to the parameter data according to the runtime binding model in the request parameter model, and converting the parameter data into the corresponding parameter value according to the specific structured data type.

[0016] Fourthly, embodiments of this application provide a proxy generation apparatus, comprising: The source code acquisition module is used to acquire the source code project before the compilation period of the source code project of the native programming language. The scanning module is used to identify service identifiers, service interfaces, and service implementations in the source code project and generate scanning results. Service identifiers are used to mark the services delegated to the proxy, service interfaces are used to declare the calling methods of the proxy, and service implementations include the business implementation logic that matches the calling methods in the service interfaces. The parsing module is used to parse the scan results and generate a parsing model; The delegate generation module is used to generate code files for the caller's delegate and the server's delegate based on the parsing model.

[0017] Fifthly, embodiments of this application provide a service invocation apparatus configured on a calling device, the calling device being configured with a calling-end delegate code file generated by the delegate generation method as described in any of the first aspects; the service invocation apparatus includes: The request retrieval module is used to obtain the call request of the target service interface; the call request includes call parameters; The first writing module is used to determine the service category information and operation type information corresponding to the target service interface according to the call request, and write the service category information and operation type information into the unified transmission object; The second writing module is used to write the call parameters into the request data field of the unified transmission object according to the request parameter model configured in the code file of the caller's delegate. The first encoding module is used to encode the Uniform Transmission Object into request data; The data communication module is used to send request data to the server device and receive response data from the server device in response to the request data. The first decoding module is used to decode the response data into a unified transport object and obtain the response data field of the unified transport object; The conversion module is used to convert response data fields into the return results of the target service interface based on the response result model configured in the code file of the calling end's delegate.

[0018] Sixthly, embodiments of this application provide a service invocation apparatus configured on a server-side device, the server-side device being configured with a server-side delegate code file generated by the delegate generation method as described in any of the first aspects; the service invocation apparatus includes: The data receiving module is used to receive request data sent by the calling device; The second decoding module is used to decode the request data into a unified transport object; The service location module is used to locate the target service of the unified transmission object in the code file of the server-side delegated proxy based on the service category information of the unified transmission object. The method location module is used to locate the target invocation method in the target service based on the operation type information of the unified transmission object. The numerical conversion module is used to convert parameter data in the request data field of the unified transmission object into parameter values ​​according to the request parameter model configured in the code file of the server-side delegation proxy. The second calling module is used to call the target calling method using parameter values ​​and obtain the calling result; The field determination module is used to determine the response data fields of the Uniform Transmission Object based on the call result; The encoding module is used to encode the unified transmission object into response data and return the response data to the calling device.

[0019] In one possible implementation of the sixth aspect, the numerical conversion module is specifically used to: determine the type classification of parameter data under the request data field of the unified transmission object based on the first description information of the request parameter model configured in the code file of the server-side delegated proxy; in the case of basic type classification, determine the specific basic type of the parameter data under the basic type classification based on the first description information in the request parameter model, and convert the parameter data into the corresponding parameter value according to the specific basic type; in the case of structured type classification, determine the specific structured data type corresponding to the parameter data based on the runtime binding model in the request parameter model, and convert the parameter data into the corresponding parameter value according to the specific structured data type.

[0020] In a seventh aspect, 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. When the processor executes the computer program, it implements the delegate / proxy generation method of any one of the first aspects, the service invocation method of the second aspect, or the service invocation method of any one of the third aspects.

[0021] Eighthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the delegate / proxy generation method of any one of the first aspects, the service invocation method of the second aspect, or the service invocation method of any one of the third aspects.

[0022] Ninthly, embodiments of this application provide a computer program product that, when run on a computer device, causes the computer device to execute the delegate generation method of any one of the first aspects, the service invocation method of the second aspect, or the service invocation method of any one of the third aspects.

[0023] The beneficial effects of the embodiments of this application compared with the prior art are: This application provides a method for generating a proxy and a method for invoking a service. The proxy generation method obtains the source code project before the compilation phase of the native programming language's source code project, directly using the source code project as the sole input source for generating the proxy. This avoids the need to define and maintain separate interface description files outside of the service interfaces, thus fundamentally preventing the need to synchronously modify external interface description files when service interfaces change. Based on this, a scanning result is generated by identifying the service identifier, service interface, and service implementation in the source code project. The service identifier is used to mark the service of the proxy, the service interface is used to declare the proxy's invocation method, and the service implementation includes the business logic matching the invocation method in the service interface. This method can directly extract the three core elements necessary for building a proxy from the source code project: service identifier, interface declaration, and business implementation, and establishes a correspondence between them. This ensures that the subsequently generated invoking proxy and service proxy maintain internal consistency with the interface definitions in the same source code project. Furthermore, by parsing the scan results, a parsing model is generated, structuring and modeling the service identifier, interface declaration, and business implementation. This provides a unified and directly callable data foundation for generating the code files of the caller-side and server-side delegated proxies. Finally, based on the parsing model, the code files for both the caller-side and server-side delegated proxies are generated, ensuring that both originate from the parsing results of the same source code project. This guarantees that the binding relationships between the interface definitions, calling methods, and business implementations upon which the caller-side and server-side delegated proxies depend remain consistent. Therefore, changes to the service interface only require modifying the source code project and re-executing the generation process to obtain synchronously updated caller-side and server-side delegated proxies, eliminating the need to maintain separate interface description files and thus reducing maintenance costs. Attached Figure Description

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

[0025] Figure 1 This is a flowchart illustrating a proxy generation method provided in this application; Figure 2 This is a schematic diagram of the scanning logic of the source code scanning module provided in this application; Figure 3 This is a flowchart illustrating a data structure model provided in this application; Figure 4 This is a schematic diagram of the parsing logic of the source code parsing module provided in this application; Figure 5 This is a flowchart illustrating a process for generating code files provided in this application; Figure 6 This is a logical diagram generated by the proxy generation module provided in this application; Figure 7 This is a timing diagram of the execution control module provided in this application; Figure 8 This is a flowchart illustrating a service invocation method applied to a calling device provided in this application; Figure 9 This is a flowchart illustrating a service invocation method applied to a server-side device provided in this application; Figure 10 This is a diagram illustrating the lifecycle of the caller provided in this application; Figure 11 This is a diagram illustrating the server-side call lifecycle provided in this application; Figure 12 This is a logical diagram illustrating the encoding of the request parameters provided in this application; Figure 13 This is a logical diagram illustrating the decoding of request parameters provided in this application; Figure 14 This is a logical diagram illustrating the decoding of the response results provided in this application; Figure 15 This is a logical diagram illustrating the basic type decoding provided in this application; Figure 16 This is a logical diagram of the time type decoding provided in this application; Figure 17 This is a schematic diagram of the decoding logic of the field decoder provided in this application; Figure 18 This is a schematic diagram of the decoding logic of the object decoder provided in this application; Figure 19 This is a schematic diagram of the decoding logic of the element decoder provided in this application; Figure 20 This is a schematic diagram of the decoding logic of the set decoder provided in this application; Figure 21 This is a schematic diagram of the decoding logic of the value item decoder provided in this application; Figure 22 This is a schematic diagram of the decoding logic of the mapping decoder provided in this application; Figure 23 This is a schematic diagram of the decoding logic of the extended type decoder provided in this application; Figure 24 This is a schematic diagram of the decoding logic for the JSON value conversion provided in this application; Figure 25 This is a schematic diagram of the structure of a proxy generation device provided in this application; Figure 26 This is a schematic diagram of the structure of a service invocation device configured on the calling device provided in this application; Figure 27 This is a schematic diagram of a service invocation device configured on a server-side device, as provided in this application. Figure 28 This is a schematic diagram of the structure of a computer device provided in this application. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application 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 application with unnecessary detail.

[0027] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0028] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0030] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0032] With the development of distributed and modular software systems, remote calls between services have become commonplace. To shield communication details and reduce coupling between the caller and the service provider, delegation mechanisms are often introduced, enabling the caller to access remote services through a local interface.

[0033] Current mainstream high-level programming languages ​​differ in their ability to obtain and invoke type information at runtime, as well as in their automatic proxy construction methods. In languages ​​like Java and C#, which possess relatively complete runtime loading capabilities, annotation / attribute parsing, reflection invocation, and dynamic proxy capabilities, service frameworks can read service interfaces and create proxy objects at runtime, completing method calls through reflection or dynamic invocation mechanisms. However, in native programming language environments such as C, C++, and Go, service interfaces are typically based on compile-time type definitions. Even with some compile-time or runtime reflection capabilities, service frameworks cannot rely primarily on runtime dynamic proxy mechanisms to construct proxy objects and complete method calls, as is the case in these languages.

[0034] Therefore, in native high-level programming language environments, it is necessary to invent a delegate / proxy generation method that primarily relies on native service interface definitions. This reduces dependence on runtime dynamic proxies and full reflection invocation capabilities, avoids maintaining independent protocol descriptions or repetitive adaptation code outside of interface definitions, thereby reducing synchronization costs associated with interface changes and improving consistency between the caller and service provider in parameter, return value, and data structure processing. In an exemplary embodiment, such as... Figure 1 As shown, a method for generating delegated agents is provided. Taking the application of this method to a computer device as an example, the method includes the following steps: S101 obtains the source code project before the compilation phase of the source code project of the native programming language.

[0035] Native programming languages ​​refer to language environments that are primarily based on compile-time type definitions, static code generation, or finite runtime type capabilities, including but not limited to C, C++, and Go. While native programming language environments may possess some compile-time or runtime reflection capabilities, they typically rely more heavily on runtime loading, dynamic proxies, and complete reflection call chains to construct delegates, unlike languages ​​such as Java and C#.

[0036] A source code project refers to a project directory that includes source code files, header files, and configuration files. It can be organized according to modules, packages, namespaces, or inclusion relationships.

[0037] Before compilation refers to the stage before the source code is compiled into an executable program, i.e., the code generation stage.

[0038] One possible approach is for the computer device to respond to a code generation instruction triggered by a developer, read the source code project directory under a specified path, and take all source files (such as .c, .cpp, and .go files) and header files (such as .h and .hpp files) in that source code project directory as input.

[0039] Another possible approach is for computer devices to automatically retrieve the currently open source code project after a developer saves a source code file via an integrated development environment (IDE) plugin.

[0040] By obtaining the source code project before compilation, the source code project can be used as the sole input source for generating the delegate proxy. There is no need to define and maintain an independent interface description file, which eliminates the need to modify the external description file when the service interface changes.

[0041] S102 identifies service identifiers, service interfaces, and service implementations in the source code project and generates scan results.

[0042] In this context, a service identifier refers to a tag definition in the source code project used to mark the service for which a delegated proxy needs to be generated. Service identifiers can be represented by macros, constants, or variables. The names of macros, constants, or variables represent the service names (for variables whose data type is a class or structure, more service definition information can be included through their member attributes). The interface declarations in the source code unit containing the service identifier (i.e., the target source code file mentioned below) are identified as the corresponding service interfaces. Service identifiers are used to identify the service interfaces for which delegated proxies need to be generated, establishing the association between service identifiers and service interfaces.

[0043] A service interface refers to the interface definition in the source code project used to declare the calling methods of delegated proxies. Examples include interfaces, abstract classes, pure virtual classes, or equivalent interfaces. The service interface determines the interface definitions that need to generate delegate proxies, providing information for subsequent parsing of call signatures (method / function names, parameter lists, and return values). The declaration of the service interface describes the service call contract, mainly including method or function definitions, but does not contain member variables or specific business logic. It resides in the same source code unit as the service identifier.

[0044] A service implementation refers to a class or struct in the source code project that contains the business logic that matches the methods called in the service interface. It includes the specific business logic that matches the method or function signatures in the service interface. The service implementation is used to determine the actual service implementation that the server-side delegation proxy needs to bind to and invoke.

[0045] The scan result refers to a data set that includes at least service identification information, service interface information, and service implementation information. The scan result may also include the location information of the service identification information, service interface information, and service implementation information in the source code project.

[0046] One possible approach is for a computer device to use the compiler's front-end parsing tools to parse the source code project, build an abstract syntax tree, and then traverse the nodes of the abstract syntax tree to identify service identifiers, service interfaces, and service implementations from the nodes.

[0047] Another possible way is, such as Figure 2 As shown, step S102 specifically includes: determining the target source code file based on the configuration information and preset filtering rules of the source code project; determining the tag definition used to identify the service in the target source code file as the service identifier; determining the interface declaration associated with the service identifier in the target source code file as the service interface; determining the business implementation logic that matches the calling method in the service interface in the target source code file as the service implementation; and determining the scan result based on the service identifier, service interface, and service implementation.

[0048] The configuration information refers to the build configuration of the source code project, such as project configuration, module relationships, package paths, namespaces, header file directories, and dependency scopes.

[0049] The preset filtering rules are used to exclude source code files in the source code project that do not participate in the generation of the delegated proxy, such as test source code, generated delegated proxy source code, compilation output directory, version control directory, and third-party dependency directory.

[0050] Tag definitions refer to macro definitions, constant declarations, or variable declarations in a target source code file used to uniquely identify a service.

[0051] An interface declaration refers to a service contract defined in the target source code file, including the method name, parameter list, and return type.

[0052] Service implementation refers to the business logic class that implements all the calling methods in the service interface.

[0053] like Figure 2 As shown, the source code scanning module in the computer device determines the scanning range based on the configuration information and preset filtering rules of the source code project, and reads source code units (i.e., target source code files) from the scanning range. Source code units include source files or header files.

[0054] For service identifiers, the source code scanning module can search for marker forms (i.e., marker definitions) such as macros, constants, and variables in source code units and use the found marker forms as service identifiers. Simultaneously, it extracts service definition information based on the marker forms, establishes the correspondence between service identifiers and service interfaces, and generates service identifier information. The abstract structure of the service identifier ServiceIdentity is as follows: ServiceIdentity =<ServiceId, ServiceClass, ServiceType> Among them, ServiceId is used to represent the unique identifier of the service provider; ServiceClass is used to represent the business category to which the service belongs; and ServiceType is used to represent the specific service object type under this category.

[0055] For service interfaces, the source code scanning module can search for interface, abstract class, pure virtual class, or equivalent interface definitions (i.e., interface declarations) within the scanning scope. It determines whether the interface definition is associated with a service identifier. If the interface definition is associated with a service identifier, then the interface is defined as a service interface. For service interface inheritance, embedding, or other references, the source code scanning module records the relationship between the service interface and the inherited, embedded, or other introduced interfaces, continues scanning related interfaces, and merges their call signatures into the call signature set of the current service interface. For marker interfaces, marker base classes, or embedding declarations used only to represent service attributes, the source code scanning module does not record them. This process generates service interface information.

[0056] For service implementations, the source code scanning module can search for classes, structs, or equivalent implementations (i.e., business logic implementations) that may implement the service interface within the scanning scope, thereby determining the service implementation. Simultaneously, it records the service implementation's type name, source code location, module or namespace, callable methods, and their implementation relationship with the service interface. For service implementations that need to be created through constructors, factory functions, or initialization entry points, it records their instantiation entry points and return type information, thus generating service implementation information.

[0057] The source code scanning module, based on the service identification information, service interface information, and service implementation information determined above, records the parameters, return values, and the location of the source code file, header file, module, package, or namespace of the method or function in the source code unit where the data object information (i.e., service identification information, service interface information, and service implementation information) is located, thereby forming a total scan result. The scan result is then output to the source code analysis module of the computer device. The scan result is shown in Table 1.

[0058] Table 1 Scanning Results

[0059] By identifying the target source code file through configuration information and preset filtering rules, and then sequentially identifying the service identifier, service interface, and service implementation, the core elements related to proxy generation in the source code project can be accurately located, avoiding the scanning of irrelevant files and improving scanning efficiency. By identifying the service identifier, service interface, and service implementation, the three core elements necessary for building a proxy can be directly extracted from the source code project, and the correspondence between the three can be established, ensuring that the subsequently generated call-side and server-side proxy maintains internal consistency with the interface definitions in the same source code project.

[0060] S103, parse the scan results and generate an analytical model.

[0061] Among them, the parsing model refers to the structured intermediate data model generated after semantic parsing of the scan results.

[0062] One possible approach is for the source code analysis module of a computer device to use a syntax parser and a semantic analyzer to perform type inference and dependency analysis on each data object in the scan results, generate a unified intermediate representation, and then organize the intermediate representation into a parsing model.

[0063] As an alternative implementation, the source code parsing module in the computer device receives the scan results output by the source code scanning module, performs semantic parsing on the service identifier, service interface, service implementation, and related data type declarations, and outputs the parsing model required by the code generation module. The parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model. Based on this, step S103 specifically includes: constructing a service interface model according to the correspondence between service identifiers and service interfaces in the scan results; parsing each callable method in the service interface to construct a call signature model; classifying and parsing the data structures involved in the call methods to construct a data structure model; and constructing a service implementation model based on the service implementation information in the scan results.

[0064] The service interface model is a structured data model that describes the service interface and its related information. It includes the service identifier name, service interface name, module / package / namespace, the relationship between interfaces (such as inheritance, embedding or other reference relationships), and the call signature set.

[0065] A call signature model is a structured data model that describes the signature information of callable methods in a service interface. It includes the name of the method or function, parameter names, number of parameters, parameter order, parameter types, return result type, and return expression.

[0066] A data structure model is a structured data model that describes the data types involved in a method call and their internal structure. It includes the data types, field names, field types, field levels, collection element types, mapping key-value types, and nested structures of parameters, return values, and their internal fields.

[0067] A service implementation model is a structured data model that describes the service implementation and its binding relationship with the service interface. It includes the service implementation type, source code location, matching relationship with the service interface, callable methods or functions, and instantiation entry information.

[0068] The source code parsing module can traverse the service identifiers and service interfaces in the scan results. Based on the correspondence between service identifiers and service interfaces (such as being located in the same source code unit), it creates a service interface model. For service interfaces that inherit, embed, or reference other interfaces, these relationships are recorded, and the relevant interfaces are recursively read, merging their call signatures into the call signature set of the current service interface. Marker interfaces, marker base classes, or embedded declarations used only to represent service attributes are not recorded.

[0069] The source code parsing module iterates through each method or function declaration in the service interface, extracts its name, parameter list (including parameter name and parameter type), and return value type, and organizes them into a call signature model according to a preset format.

[0070] The source code analysis module iterates through each data structure and its data type in the called method; based on the structural characteristics of each data type, it determines the type category to which the data type belongs; based on the semantic information of the data type, it determines the sub-category of the data type under its type category; it parses the internal structure of the data type to determine its structural composition information; based on the above data type, type category, sub-category, and structural composition information, it generates the type metadata corresponding to the data type; and it summarizes each data structure and its corresponding type metadata to generate a data structure model.

[0071] The source code analysis module reads the method or function information of the service implementation from the scan results and matches it with the call signature of the corresponding method in the service interface. The call signature includes parameter name, number of parameters, parameter type, parameter order, return result type, and return expression. The module establishes a binding relationship between the successfully matched service implementation and the corresponding service interface. If the service implementation has a constructor, factory function, or initialization entry point, its instantiation method is recorded. Based on the service implementation type information, the binding relationship with the service interface, and the instantiation method, the module constructs the service implementation model.

[0072] As an optional implementation method, the data structure model construction process is as follows: Figure 3 As shown, the specific steps include: S301, obtain each data structure and its data type in the called method.

[0073] Among them, data structure refers to the various data carrying units that appear in the method call, including parameters (variables passed in when the method is called), return value (the result returned after the method is executed), object fields (member variables of a structure or class), collection elements (including single entries in arrays, slices and lists), and mapping key-value pairs (key-value pairs in dictionaries or hash tables).

[0074] Data type refers to the specific type declared for each data structure in a programming language, such as integer, string, structure type, slice type, and mapping type.

[0075] One possible approach is for the computer device to obtain, from the method call declaration, each parameter in the parameter list and its type declaration, as the parameter data structure and its data type; the return value type in the method signature, as the return value data structure and its data type; the name and type of each field in the structure definition, as the object field data structure and its data type; the element type in the collection declaration, as the collection element data structure and its data type; and the key and value types in the map declaration, as the map key-value data structure and its data type. In this way, the computer device obtains each data structure and its corresponding data type from the called method.

[0076] Another possible approach is for the computer device to perform type inference on each expression in the called method using a type checker. For each data structure that appears, such as parameters, return values, object fields, collection elements, and mapping keys, the device recursively collects the data structure and its corresponding data type. For example, for a structure field, it further collects the types of nested subfields within that field; for a collection element, it further collects the element type and its internal structure; and for a mapping key, it further collects the key type, value type, and their internal structure. Ultimately, the computer device forms complete type information containing every data structure and its corresponding data type in the called method.

[0077] S302, for each data type, determine the type classification of the data type in the type system based on the structural characteristics of the data type.

[0078] Among them, structural feature information refers to information describing the internal construction method of a data type, such as whether the data type consists of multiple fields (aggregate type), whether it contains child elements (container type), and / or whether it is a basic value (single value type), etc.

[0079] A type system is a classification framework in a programming language that organizes all data types according to their structural characteristics.

[0080] Type classification refers to the major category to which a data type belongs in the type system, including basic type classification, object type classification, collection type classification, mapping type classification, time type classification, user-defined type classification, and special type classification.

[0081] One possible approach is for the computer device to examine the internal structure of each data type. If the data type is a simple value type built into the compiler, it is classified as a basic type; if the data type is a structure or class containing multiple named fields, it is classified as an object type; if the data type is a container that can hold multiple elements of the same type, it is classified as a collection type; and if the data type is a key-value pair storage structure, it is classified as a mapping type.

[0082] Another possible approach is for computer devices to query the type classification category of each data type through the type classification interface provided by the type system. For example, by determining whether the data type implements a specific container interface or has specific memory layout characteristics, it can be automatically classified into the corresponding type category. For types that cannot be clearly classified by structural characteristics, type classification is determined based on their usage and contextual information.

[0083] S303, Based on the semantic information of the data type, determine the sub-category of the data type in type classification.

[0084] Semantic information refers to the meaning of a data type in a specific programming context, such as whether the type represents an integer, a floating-point number, a date / time, or a string.

[0085] Type subcategories refer to specific types further subdivided based on semantic information within the same type classification. For example, under the basic type classification, type subcategories include integer types, floating-point types, string types, and boolean types; under the set type classification, type subcategories include fixed-length set types and dynamically length set types.

[0086] One possible approach is for the computer device to, after determining the type classification, further read the specific declaration of that type classification in the source code. For example, for basic type classification, the type name can be used to determine whether it belongs to an integer, floating-point number, string, or boolean value; for object type classification, its field list can be parsed to determine whether it is a regular struct or a class with special semantics.

[0087] Another possible approach is for computer devices to infer the specific type class of a variable based on its usage context within the code. For example, a variable categorized as a basic type might be an integer or floating-point number if it's used in arithmetic operations, and a string type if it's used for string concatenation. Computer devices collect this information through data stream analysis to help determine the specific type class of each data type.

[0088] S304, parse the data type to determine the internal structural composition information of the data type.

[0089] The internal structure information refers to the specific details of the data type's internal composition. For object types, this includes field names, field types, and field order; for collection types, it includes element types and whether the collection length is fixed; for mapping types, it includes key types and value types.

[0090] One possible approach is for the computer device to recursively parse each data type. For object types, it iterates through all fields, recording the name, type, and declaration order of each field; for collection types, it parses the element type declarations; for mapping types, it parses the key type and value type declarations separately. After parsing, this information is organized into a structured internal structure.

[0091] Another possible approach is for computer devices to use type reflection mechanisms or type information interfaces provided by code generation tools to directly query the internal member list of each data type. For struct types, this retrieves the names and types of all their fields; for collection types, it retrieves the element types; and for mapping types, it retrieves the key and value types, thus forming complete information about the internal structure.

[0092] S305 generates type metadata corresponding to the data type based on the data type, type classification, type subclass, and internal structure composition information.

[0093] Type metadata refers to a data object that comprehensively describes the type information of a data structure. It integrates the original data type name of the data structure, its type classification, the sub-classes under that classification, and the internal structural composition information of the type, serving as the basis for subsequent encoding / decoding and code generation.

[0094] Computer devices can design type metadata as a key-value pair collection, using type name, type classification, type subclass, and internal structure information as keys to store corresponding values. For internal structure information, different structural description data is stored depending on the data type.

[0095] S306 generates a data structure model based on each data structure and its corresponding type metadata.

[0096] As an optional implementation, the computer device can create an entry for each data structure, containing the original definition of the data structure (such as parameter names, return value names, and field names) and corresponding type metadata, and then summarize all entries into a data structure model. The computer device obtains each data structure and its data type from the calling method. The data structure includes parameters, return values, object fields, collection elements, and mapping keys. For each data type, based on its structural characteristics, the type classification within the type system is determined. Type classification includes basic type classification, object type classification, collection type classification, mapping type classification, time type classification, custom type classification, and special type classification. For example, the `int` type has a single numerical value and no internal fields, belonging to the basic type classification; the `User` structure type has multiple fields, belonging to the object type classification; the `[]int` slice type has multiple elements of the same type, belonging to the collection type classification; and the `map[string]int` mapping type has key-value pairs, belonging to the mapping type classification.

[0097] Then, based on the semantic information of the data type, the sub-category of the data type in the type classification is determined. For example, in the basic type classification, it is further subdivided into Boolean type, integer type, floating-point type, and string type, etc.; in the object type classification, it is further subdivided into structure type and class type, etc.; in the collection type classification, it is further subdivided into fixed-length collection type and dynamic-length collection type, etc.; in the mapping type classification, it is further subdivided into string key mapping type and integer key mapping type, etc.

[0098] Next, the data type is parsed to determine its internal structural composition. For example, for a structure type, its field list is parsed, including the name, type, and order of each field; for a collection type, its element type and length information are parsed; and for a mapping type, its key type and value type are parsed.

[0099] Then, based on the data type, type classification, type subclass, and internal structural composition information, type metadata corresponding to the data type is generated. Type metadata is used to describe the classification information and structural composition information of the data type, including type classification and type subclass identifiers, as well as structural composition information (such as field list and element type).

[0100] Finally, a data structure model is generated based on each data structure and its corresponding type metadata. Each object field, each collection element, each mapping key, and each mapping value in the data structure model carries its corresponding type metadata.

[0101] By performing fine-grained type classification and structure parsing of data types, type metadata carrying information on type classification, type subclass, and internal structure composition is generated, enabling data encoding / decoding and type conversion to be completed at runtime without reflection based on the type metadata.

[0102] As a specific implementation method, such as Figure 4 As shown, the source code parsing module constructs a service interface model based on the correspondence between service identifiers and service interfaces. For service interfaces that inherit, embed, or reference other business interfaces, the source code parsing module continues to read relevant business interfaces based on the interface associations recorded during the scanning phase, and merges their call signatures into the call signature set of the current service interface. Specifically, when parsing service interfaces, call signatures, and data structures, type classification and structure parsing are performed on each parameter type, return value type, object field type, collection element type, and mapping key-value type. The result of the type classification process is based on the data category DataKind (i.e., type classification) and the precise type DataType (i.e., type sub-class). DataKind is used to determine whether the type belongs to a basic type, object type, collection type, mapping type, time type, custom type, or special type. DataType is used to determine the specific encoding / decoding processing method of the type under its data category. The implementation and relationship between the data category DataKind and the precise type DataType are shown in Table 2 below. Table 2. Data Type Definitions and Relationships

[0103] For precise types not listed separately in Table 2, if differentiation is necessary, corresponding precise types can be added under the same data category. For access methods such as pointers, references, and nullable objects, the source code parsing module does not classify them as independent types, but rather as type attribute records for the corresponding type category. The above structure parsing processing is based on the metadata interface DataTypeMeta, which provides the type classification identifier for the current data, defined as follows: DataTypeMeta =<GetDataKind() -> DataKind, GetDataType() ->DataType> Specifically, `GetDataKind()` returns the data category `DataKind` corresponding to the current metadata, and `GetDataType()` returns the exact type `DataType` corresponding to the current metadata. Request parameters, response results, object fields, collection elements, and mapping key-value pairs all reference their type metadata through `DataTypeMeta`. The implementation types of `DataTypeMeta` are shown in Table 3 below: Table 3 DataTypeMeta Implementation Types

[0104] The source code parsing module first reads the type names, type declaration locations, type modifier information, and type composition relationships from the target native language source code. For primitive types, the source code parsing module maps them to the corresponding DataKindPrimitive and precise types; for structs or classes, it maps them to DataKindObject and continues to parse their field metadata FieldMeta[]; for collection classes, it maps them to DataKindCollection and continues to parse their collection type Type and element metadata ElementMeta. If it is a fixed-length collection class, it also needs to parse the collection's fixed length FixedLength; for maps, dictionaries, or key-value containers, it maps them to DataKindMap and continues to parse the key type KeyType and value metadata ValueMeta; for date, time, timestamp, or time interval types, it maps them to DataKindTime; for aliased custom types defined based on primitive types or composite types, it maps them to DataKindCustom and records their original type names and underlying type relationships; for dynamic values, generic values, or undefined types, it maps them to DataKindSpecial. After the above processing, the source code parsing module writes the type classification results into the call signature model and the data structure model. Each parameter and return value in the call signature model records its DataKind, DataType, and necessary associated type information; each object field, collection element, mapping key, and value in the data structure model also records its corresponding DataKind, DataType, and nested type information.

[0105] After forming the service interface model, call signature model, and data structure model, the source code parsing module continues to construct a service implementation model based on the service implementation information in the scanning results. This is done by checking if the methods or functions in the service implementation match the call signature of the service interface. The matching includes parameter names, number of parameters, parameter types, parameter order, return result type, and return expression. Successfully matched service implementations are bound to their corresponding service interfaces. If constructors, factory functions, or initialization entry points exist, their instantiation methods are recorded for use during server-side proxy generation. Through this parsing process, the source code parsing module converts the scanning results into a unified intermediate model, enabling the code generation module to generate proxy files based on this intermediate model.

[0106] By parsing the scan results to generate a parsing model, the service identifier, interface declaration, and business implementation are structured and modeled, providing a unified and directly callable data foundation for generating code files for both the calling end delegate and the server-side delegate.

[0107] S104. Based on the parsing model, generate the code file for the calling end delegate and the code file for the server end delegate.

[0108] Among them, the code file of the calling end delegate refers to the proxy code file that allows the caller to initiate a call in the form of a service interface.

[0109] The code file for server-side delegation and proxy refers to the proxy code file used to route call requests to the service implementation and execute the call.

[0110] One possible approach is for computer devices to use a template engine to populate data from the parsed model into a preset code template, render and generate source code files that conform to the target language syntax, thereby obtaining the code files of the calling end delegate and the code files of the server end delegate.

[0111] Another possible approach is for the computer device to generate a request parameter model and a response result model for each called method based on the call signature and type information in the parsing results. The request parameter model carries the description information and runtime storage information of each parameter in a single call request of the called method, and the response result model carries the description information and runtime storage information of each returned result in a single call response of the called method. Based on the service interface information in the parsing results, a call-side proxy method corresponding to the service interface is generated, and the request parameter model and response result model are configured in the call-side proxy method to form the call-side delegation proxy code file. Based on the service interface information and service implementation information in the parsing results, a server-side proxy method is generated, and the request parameter model is configured in the server-side proxy method to form the server-side delegation proxy code file.

[0112] By generating delegate proxy code files for both the calling and service sides simultaneously based on the same parsing model, both proxies originate from the same source code parsing result, ensuring that the binding relationship between the interface definitions, calling methods, and business implementations that the proxies on both sides depends on remains consistent.

[0113] In this embodiment, by obtaining the source code project before the compilation phase of the native programming language's source code project, the source code project is directly used as the sole input source for generating the delegated proxy. This avoids the need to define and maintain separate interface description files outside of the service interfaces, thus fundamentally preventing the need to synchronously modify external interface description files when service interfaces change. Based on this, by identifying the service identifier, service interface, and service implementation in the source code project, a scanning result is generated. The service identifier is used to mark the services of the delegated proxy, the service interface is used to declare the calling methods of the delegated proxy, and the service implementation includes the business implementation logic matching the calling methods in the service interface. This allows for the direct extraction of the three core elements necessary for building the delegated proxy from the source code project: service identifier, interface declaration, and business implementation. A correspondence between these three elements is established, ensuring that the subsequently generated call-side and service-side delegated proxies maintain internal consistency with the interface definitions in the same source code project. Furthermore, by parsing the scanning result, a parsing model is generated, structuring and modeling the service identifier, interface declaration, and business implementation. This provides a unified and directly callable data foundation for generating the code files of the call-side and service-side delegated proxies. Finally, based on the parsing model, code files for both the calling and server-side delegated proxies are generated. This ensures that both code files originate from the parsing results of the same source code project, guaranteeing consistent binding relationships between the interface definitions, calling methods, and business implementations on which the calling and server-side delegated proxies depend. Therefore, changes to the service interface only require modifying the source code project and re-executing the generation process to obtain synchronously updated code files for both the calling and server-side delegated proxies, eliminating the need to maintain separate interface description files and thus reducing maintenance costs.

[0114] Based on the above embodiments, in an exemplary embodiment, the parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model. Furthermore, the code file generation process is further refined. For example... Figure 5 As shown, it includes the following steps: S501, based on the call signature model, generates the request parameter model and response result model corresponding to each called method.

[0115] The request parameter model describes the first descriptive information and the first runtime parameter storage information for each parameter in a single method call request. The first descriptive information includes the parameter's type classification, sub-type classification, and type metadata. The first runtime parameter storage information includes the parameter's storage location and parameter value address during runtime.

[0116] The response result model is used to describe the second descriptive information and the second runtime parameter storage information of each returned result in a single call response of a method.

[0117] The computer device can iterate through each method call in the call signature model and generate a request parameter model for each parameter of that method. This request parameter model includes parameter description information (i.e., first description information, including parameter name and type metadata, etc.), the order of the parameters in the call signature, and the address of the parameter value passed at runtime. In cases with multiple parameters, the request parameter model corresponding to the call method is formed according to the order of the parameters. Similarly, for each return result of the call method, a response result model instance is generated, containing result description information (i.e., second description information, including result type metadata, etc.) and the address of the result value returned at runtime. For languages ​​that support multiple return values, the response result model corresponding to the call method is formed according to the order of the returned results.

[0118] S502, based on the service interface model and the call signature model, generates a caller proxy method corresponding to the service interface, and configures the request parameter model and response result model in the caller proxy method to form the caller delegation proxy code file.

[0119] Among them, the caller proxy method refers to the proxy method that has the same method signature as the call method in the service interface. When the caller calls the caller proxy method, the proxy method encapsulates the call parameters into request data and sends it to the server.

[0120] The computer device can traverse each service interface in the service interface model. For each method call within each service interface, it generates a proxy method with the same name, parameter list, and return type. Within the implementation of this proxy method, a request parameter model and a response result model are configured. The passed parameter values ​​are written to the parameter value address of the request parameter model. Then, a data codec is called to encode the request parameter model into request data, which is sent to the server over the network. Upon receiving the response data, the response data is decoded into a return value according to the response result model.

[0121] S503 generates a server-side proxy method based on the service interface model, call signature model, and service implementation model, and configures the request parameter model in the server-side proxy method to form the code file for the server-side delegation proxy.

[0122] Among them, the server proxy method refers to the server processing method that has the same method signature as the calling method in the service interface. After the server receives the request data, it calls the server proxy method. The server proxy method decodes the request data into parameter values ​​and then calls the actual service implementation.

[0123] The computer device can traverse the service interface model and service implementation model. For each service interface and service implementation with an established binding relationship, a server-side proxy class is generated. This proxy class generates a server-side proxy method for each called method. The proxy method configures the request parameter model, decodes the request data fields into parameter values, calls the corresponding method in the service implementation, and encodes the call result into response data and returns it.

[0124] As an optional implementation, the delegate generation method further includes: when generating the code file of the caller-side delegate and the code file of the server-side delegate, constructing a runtime binding model based on the structured data types in the data structure model; the runtime binding model is used to complete data creation, assignment, and / or writing operations when processing structured data types at runtime; and writing the runtime binding model into the request parameter model and the response result model respectively.

[0125] Among them, runtime binding model refers to a type of metadata that is built and written into the request parameter model and response result model during the generation period. It is used to describe the data restoration method of structured data types during runtime and includes at least one of object binding model, collection binding model and mapping binding model.

[0126] Structured data types refer to data types with internal members or elements, including object types (structs and classes), collection types (arrays, slices, and lists, etc.), and mapping types (dictionaries and hash tables, etc.), which are different from basic types (integers, floating-point numbers, and strings, etc.).

[0127] One possible approach is for computer devices to construct an object binding model for object types within structured data types. This object binding model contains a set of field metadata for the object type and a set of runtime field target value addresses, describing the correspondence between the object field metadata and the fields written at runtime. During runtime decoding, the data codec writes the field values ​​to the corresponding fields of the target object according to the object binding model.

[0128] Another possible approach is for computer devices to construct a collection binding model for collection types within structured data types. The collection binding model includes collection metadata, element creation functions for creating individual elements, and element addition functions for writing decoded elements into the collection. During runtime decoding, the data codec calls the element creation functions to create element objects, decodes the data into elements, and then calls the element addition functions to write the elements into the target collection.

[0129] Another possible approach is for the computer device to construct a mapping-binding model for mapping types within structured data types. This model includes mapping metadata, value creation functions for creating individual mapping values, and key-value writing functions for writing decoded key-value pairs to the target mapping. During runtime decoding, the data codec calls the value creation functions to create value objects, decodes the keys and values, and then calls the key-value writing functions to write the key-value pairs to the target mapping.

[0130] Computer devices write runtime binding models into the request parameter model and the response result model respectively, so that during runtime encoding and decoding, structured data types can be created and assigned according to the runtime binding model.

[0131] As a specific implementation method, such as Figure 6 As shown, the proxy generation module of the computer device receives the service interface model, call signature model, data structure model, and service implementation model output by the source code parsing module, and generates the code file of the caller-side delegate proxy (hereinafter referred to as the caller-side delegate proxy) and the code file of the server-side delegate proxy (hereinafter referred to as the server-side delegate proxy) based on the above parsing models. The caller-side delegate proxy is used to adapt to the interface call form of the caller, and the server-side delegate proxy is used to adapt to the call form of the actual service implementation. When generating the proxy code, the request parameter model and response result model are generated simultaneously, so that the generated delegate proxy can call the data codec to complete the efficient data conversion of request parameters and response results based on the request parameter model and response result model. The output objects of the above proxy generation module include the caller-side delegate proxy, the server-side delegate proxy, and the proxy assembly file, as shown in Table 4 for the definition of output objects: Table 4 Output Object Definition

[0132] The aforementioned request parameter model and response result model are generated by the proxy generation module during the generation phase and written into the calling end delegate proxy and the server end delegate proxy files, which are directly referenced by the delegate proxy. During runtime, the delegate proxy directly carries or references the call data codec when performing request encapsulation, parameter parsing, and result parsing.

[0133] The request parameter model is used to describe all the metadata involved in a single input parameter in a service call request, and its structure is defined as follows: ReqParam =<ParamMeta, ParamName, ParamIndex, ParamValue> The attributes of ReqParam are described in Table 5 below: Table 5 ReqParam attribute definition

[0134] ParamMeta is used to carry DataTypeMeta or RuntimeBinding. RuntimeBinding is a new form of extended metadata that provides runtime retrieval, creation, appending, or writing capabilities when processing composite objects, collections, or mappings. For cases with more than two parameters, it is represented as ReqParam[].

[0135] The response result model is used to describe all the metadata involved in a single return result in a service call response, and its structure is defined as follows: ResReturn =<ReturnMeta, ReturnValue> The field attributes of ResReturn are shown in Table 6 below: Table 6 ResReturn attribute definition

[0136] ReturnMeta is used to carry DataTypeMeta or RuntimeBinding. RuntimeBinding is responsible for providing extended metadata when handling composite objects, collections, or mappings, enabling runtime retrieval, creation, appending, or writing capabilities. For languages ​​that support multiple return values, multiple return results can be represented as ResReturn[].

[0137] The FieldMeta metadata of an object field is used to describe the field name, the exact type of the field, and the data type metadata of the field itself. Its structure is defined as follows: FieldMeta =<FieldName,FieldDataMeta> The attributes of the FieldMeta mentioned above are described in Table 7 below: Table 7 FieldMeta attribute definition

[0138] Runtime data association model (i.e., runtime binding model) describes the runtime processing binding model between runtime data type metadata and actual data objects. It is an extended metadata form of DataTypeMeta and an implementation of DataTypeMeta. For types such as composite objects, collections, and mappings that require layer-by-layer creation, assignment, or appending of data, the runtime data association model further describes the set of field values, element creation methods, element addition methods, and key-value writing methods, enabling the data codec to complete runtime data binding and transformation according to the metadata determined during generation. The runtime data association model is defined in Table 8 below: Table 8 Definition of runtime data association model

[0139] The aforementioned proxy generation module first generates FieldMeta, ObjectMeta, CollectionMeta, and MapMeta based on the data structure model. For structs or classes, it generates the corresponding ObjectBinding (i.e., object binding model); for collections, it generates the corresponding CollectionBinding (i.e., collection binding model); and for mappings, it generates the corresponding MapBinding (i.e., mapping binding model). ObjectBinding, CollectionBinding, and MapBinding together constitute RuntimeBinding. Subsequently, the proxy generation module generates ReqParam and ResReturn based on the call signature model, and writes the aforementioned type metadata or RuntimeBinding into the ParamMeta of ReqParam or the ReturnMeta of ResReturn. The generated ReqParam and ResReturn are written to the calling-side delegation proxy for request parameter encapsulation and response result parsing; the generated ReqParam is written to the server-side delegation proxy for request parameter parsing and actual service invocation.

[0140] In addition, proxy assembly files are generated. These files store the registration relationships of the generated client-side and server-side delegate proxies and their encoding / decoding metadata, and provide a unified assembly entry point for loading by applications or runtime service invocation frameworks. For different native language environments, proxy assembly files manifest as import summary files, unified registration function files, initialization files, or equivalent assembly source files, enabling the generated delegate proxies to be loaded, registered, or referenced by the runtime service invocation system. The runtime-generated delegate proxies invoke data encoders / decoders based on the request parameter model and response result model, performing encoding / decoding transformations on request parameters, response results, object fields, collection elements, and mapping key-value pairs.

[0141] In this embodiment, by generating code files for both the calling and server-side delegation proxies and configuring request parameter and response result models within them, the runtime can automatically complete parameter encoding, data transmission, and result decoding based on these models, eliminating the need for developers to manually write encoding / decoding logic. By constructing a runtime binding model and incorporating it into the request parameter and response result models, the data codec can perform data creation, assignment, and writing operations according to the data structure determined during generation when processing structured data types at runtime, without requiring runtime reflection to parse the data structure.

[0142] Based on the above embodiments, in an exemplary embodiment, such as Figure 7 As shown, the execution control module in the computer device is used to control the overall execution order of a delegate generation process.

[0143] The execution control module first reads the generation input parameters, which include the location of the source code project, the range of source code to be scanned, and the output directory of the generated files. Based on these input parameters, the execution control module determines the location of the source code project corresponding to this generation and determines the range of source code that the source code scanning module needs to process.

[0144] The source code scanning scope is used to limit the source code scope of the service identifiers, service interfaces, and service implementations involved in this generation, avoiding the scanning of source code content unrelated to this generation. Before calling the source code scanning module, the execution control module cleans up historical generated files according to the generated file output directory. Historical generated files refer to the caller-side delegate proxy files, server-side delegate proxy files, and proxy assembly files that were generated last time and are located in the target output directory. Cleaning up historical generated files is to prevent old generated files from coexisting with the current generation result, which could lead to inconsistencies in proxy assembly relationships, interface methods, or encoding / decoding metadata.

[0145] After completing the above initialization process, the execution control module calls the source code scanning module. The source code scanning module identifies service identifiers, service interfaces, and service implementations within the specified source code scope and returns the scan results to the execution control module. The scan results are then passed to the source code parsing module, which constructs the service interface model, call signature model, data structure model, and service implementation model, and returns the parsed model to the execution control module.

[0146] Then, the proxy generation module is invoked, passing the parsing model and the output directory for the generated files. The proxy generation module generates client-side delegate proxy files, server-side delegate proxy files, and proxy assembly files based on the parsing model and places them in the output directory. After completing the file writing, the proxy generation module returns a list of generated file paths to the execution control module.

[0147] Finally, after receiving the list of generated file paths returned by the proxy generation module, the generation result is output. The generation result includes the generated caller-side delegate proxy file paths, server-side delegate proxy file paths, proxy assembly file paths, and status information indicating whether the generation is complete. Through the above execution control process, source code scanning, source code parsing, and proxy generation are executed collaboratively in a predetermined order, ensuring consistency between the input range, parsing model, and final output file of the generation process.

[0148] In existing service invocation implementations, there are typically two approaches: one is to directly adapt the invocation based on the language's own interface or by having developers manually write proxy code; the other is to generate the invocation code for the caller and the adaptation code for the server using an Interface Definition Language (IDL) file. While both approaches can complete the service invocation, they usually still require handling logic such as parameter encapsulation, return value parsing, error message conversion, and data encoding / decoding adaptation during the service invocation process. If mainly relying on manual implementation, it is easy to generate duplicate code and increase maintenance costs; if relying on IDL files, it may create additional interface descriptions and type mapping relationships outside of the business interface definition. When the interface methods, input parameters, output parameters, or data structures change, developers may need to simultaneously maintain proxy code, IDL files, or encoding / decoding adaptation logic in addition to modifying the business interface and business implementation, increasing change costs and easily leading to problems such as inconsistencies between the caller and server rules, incorrect type mapping, or omissions in field processing.

[0149] To overcome the aforementioned shortcomings, in an exemplary embodiment, a service invocation method is provided, applied to a calling device, which is configured with a calling-end delegate code file generated using a delegate generation method. For example... Figure 8 As shown, the service invocation method includes: S801, obtain the call request for the target service interface.

[0150] Among them, the call request refers to the call initiated by the caller to the target service interface, which includes the call parameters.

[0151] The calling device can leverage the application within it to obtain an instance of the calling delegate proxy through dependency injection or the service locator pattern, and then invoke the method of that instance, passing in the invocation parameters. Alternatively, the calling device can initiate an invocation request through a client stub of the remote procedure call framework.

[0152] S802: Based on the call request, determine the service category information and operation type information corresponding to the target service interface, and write the service category information and operation type information into the unified transmission object.

[0153] The target service interface refers to the definition of the server interface that the caller needs to invoke. The target service interface declares the methods that can be invoked, their parameters, and return value types.

[0154] Service category information refers to the business category to which a service belongs. It can be the ServiceClass field, which corresponds to the business category in the service identifier and is used to locate the business scope of the target service on the server side.

[0155] Operation type information refers to the specific method or operation used to identify this call. It can be the OperationType field, which corresponds to the calling method declared in the service interface, and is used to locate the specific method to be called in the target service.

[0156] A unified transport object refers to a unified data carrier for data exchange between the calling end and the server. It can be a ServiceTransport and includes fields for service category information (ServiceClass), service type (ServiceType), operation type (OperationType), request data (RequestData), and response data (ResponseData). The calling end delegate (i.e., the calling end) can look up the corresponding service category information and operation type information from the pre-generated mapping table based on the name of the called method and the service interface to which it belongs, and then write this information into the corresponding field of the unified transport object.

[0157] S803, based on the request parameter model configured in the code file of the calling end delegate, writes the call parameters into the request data field of the unified transport object.

[0158] The calling end delegates and proxies to obtain the request parameter model corresponding to the called method. Based on the order and type description information of the parameters in the request parameter model, the calling parameter values ​​are written into the request data field of the unified transmission object.

[0159] Alternatively, the calling end can delegate the call to the encoding interface of the data codec, and the data codec can encode the parameter values ​​into a key-value structure according to the request parameter model, and then write it into the request data field.

[0160] S804 encodes the Uniform Transport Object into request data.

[0161] The request data refers to the data obtained after serializing (i.e., encoding) the Uniform Transmission Object. It can be data in string form transmitted over the network, such as a JSON string.

[0162] The calling delegate can invoke the serialization interface of the data codec to encode the Uniform Transport Object (UTO) into a JSON string format for request data. Alternatively, it can encode the UTO into Protocol Buffers (PBR) or Extensible Markup Language (EXPLAIN) format for request data.

[0163] S805 sends request data to the server device and receives response data from the server device in response to the request data.

[0164] The response data refers to the serialized and encoded data returned by the server after processing the request. It can be in string format, such as a JSON string.

[0165] The calling end can send request data to the service address of the server device through a Hypertext Transfer Protocol client or Transmission Control Protocol socket, and then wait for the server to return response data.

[0166] Alternatively, the calling end can delegate the sending of request data to a proxy via asynchronous input / output and register a callback function to trigger the callback processing when the response data is received.

[0167] S806 decodes the response data into a Uniform Transport Object and obtains the response data field of the Uniform Transport Object.

[0168] The calling proxy can invoke the deserialization interface of the data codec to decode the response data into a Uniform Transport Object (UTO), and then read the result data returned by the server from the UTO's response data fields. Alternatively, the calling proxy can parse the response data into a key-value structure and then populate it into the UTO's response data fields.

[0169] S807 converts the response data fields into the return result of the target service interface based on the response result model configured in the code file of the calling end's delegate.

[0170] The returned result refers to the result data obtained by the calling end's delegate after transforming the response data fields according to the response result model, and which is consistent with the return value type of the method declared in the target service interface.

[0171] The calling proxy can obtain the response result model corresponding to the called method, and based on the type description information of the returned result in the response result model, convert the result data in the response data field into the return value type of the target service interface, and return it to the caller.

[0172] Alternatively, the calling end can delegate the call to the data codec's decoding interface, and the data codec can decode the response data fields into return values ​​according to the response result model.

[0173] In this embodiment, the calling end delegate automatically completes the encoding of calling parameters and the decoding of return results through the configured request parameter model and response result model. The caller only needs to initiate the call in the form of the service interface, without needing to know the underlying communication details and data encoding and decoding logic.

[0174] In one exemplary embodiment, a service invocation method is provided, applied to a server-side device configured with code files for a server-side delegate proxy generated using a delegate proxy generation method. For example... Figure 9 As shown, the service invocation method includes: S901 receives request data sent by the calling device.

[0175] The server device can listen on the service port through a Hypertext Transfer Protocol (HTTP) server or a Transmission Control Protocol (TCP) server to receive request data sent by the client device. Alternatively, it can receive request data sent by the client device through a message queue.

[0176] S902 decodes the request data into a Uniform Transport Object.

[0177] The server-side delegate (i.e., the server-side device) calls the deserialization interface of the data codec to decode the request data into a Uniform Transport Object (UTO). Alternatively, a JSON parsing library or a protocol buffer parsing library can be used to parse the request data into a UTO.

[0178] S903, based on the service category information of the unified transport object, locate the target service of the unified transport object in the code file of the server-side delegated agent.

[0179] The target service refers to the service implementation object corresponding to the service category information.

[0180] The server-side delegation proxy can read service category information from the unified transport object, then search for the service implementation object corresponding to that service category information in the registry of the server-side delegation proxy's code file, and use that service implementation object as the target service. Alternatively, the server-side delegation proxy can search for the address and instance information of the target service in the service registry based on the service category information.

[0181] S904: Based on the operation type information of the unified transmission object, locate the target invocation method in the target service.

[0182] Among them, the target invocation method refers to the specific method that the server-side delegate agent locates in the target service based on the operation type information in the unified transmission object, and that this invocation request actually needs to execute.

[0183] Server-side delegation proxies can read operation type information from a unified transport object and then look up the target invocation method corresponding to that operation type information in the method table of the target service. Alternatively, server-side delegation proxies can use a method name mapping table to map the operation type information to a specific method in the target service, thereby locating the target invocation method in the target service.

[0184] S905 converts the parameter data in the request data field of the unified transport object into parameter values ​​based on the request parameter model configured in the code file of the server-side delegated proxy.

[0185] In this context, parameter data refers to the raw parameter content stored in the request data field of the Uniform Transmission Object that has not yet been decoded. This parameter data can be serialized into a key-value structure or JSON format and written into the request data field during encoding on the calling end.

[0186] Parameter values ​​refer to the actual parameters that the target calling method can directly receive and use, obtained by decoding and converting the parameter data in the request data field of the Uniform Transmission Object according to the type information described in the request parameter model. These parameter values ​​are consistent with the parameter types declared in the target calling method and are used for subsequent calls to the actual service implementation.

[0187] The server delegates the acquisition of the request parameter model corresponding to the target method call. Based on the order and type description information of the parameters in the request parameter model, it converts the parameter data under the request data field of the Uniform Transmission Object into parameter values ​​that can be received by the target method call. Alternatively, the server delegates the acquisition of the decoding interface of the data codec, which then decodes the request data field into parameter values ​​based on the request parameter model.

[0188] As an optional implementation, step S905 specifically includes: determining the type classification of parameter data under the request data field of the unified transmission object based on the first description information of the request parameter model configured in the code file of the server-side delegated proxy; in the case of basic type classification, determining the specific basic type of the parameter data under the basic type classification based on the first description information in the request parameter model, and converting the parameter data into the corresponding parameter value according to the specific basic type; in the case of structured type classification, determining the specific structured data type corresponding to the parameter data based on the runtime binding model in the request parameter model, and converting the parameter data into the corresponding parameter value according to the specific structured data type.

[0189] The first description information refers to the parameter type description information contained in the request parameter model.

[0190] Basic types refer to the fundamental data types in a programming language, such as boolean types, integer types, floating-point types, and string types.

[0191] Structured data types are data types that contain internal structures, such as object types, collection types, and mapping types.

[0192] The server delegates and proxies to read the first description information corresponding to the parameter in the request parameter model, extracts the type classification identifier from the first description information, and determines the type classification of the parameter data based on the type classification identifier.

[0193] When the type is categorized as a basic type, the server-side delegate reads the specific basic type identifier (such as DataTypeBool, DataTypeInt, and DataTypeString) of the parameter from the first description information, and then converts the parameter data in the request data field into the corresponding basic type value according to the specific basic type.

[0194] When the type is classified as a structured type, the server-side delegation proxy reads the runtime binding model from the request parameter model. Based on the runtime binding model, it determines the specific structured data type (such as object type, collection type, or mapping type) corresponding to the parameter data, and then calls the corresponding decoder to convert the parameter data into parameter values ​​of the specific structured data type. Specifically, the server-side delegation proxy restores the parameter data to object type parameter values ​​field by field based on the field metadata set in the object binding model and the runtime field target value address set. When the structured data type is a collection type, the server-side delegation proxy iterates through the element sequence in the parameter data, creating elements one by one and adding them to the target collection, based on the element creation function and element addition function in the collection binding model. When the structured data type is a mapping type, the server-side delegation proxy iterates through the key-value pair sequence in the parameter data, creating value objects one by one and writing them to the target mapping, based on the value creation function and key-value write function in the mapping binding model.

[0195] By distinguishing between basic data types and structured data types during the server-side decoding process and employing different conversion methods for each, the conversion of request data into parameter values ​​can be completed efficiently and accurately. In particular, for structured data types, the runtime binding model can restore complex data structures without relying on runtime reflection.

[0196] S906 calls the target method using parameter values ​​and obtains the call result.

[0197] The call result refers to the result data returned by the target method after the server-side proxy calls the target method using the parameter values ​​and the method has completed execution. This call result is consistent with the return value type declared by the target method in the service interface.

[0198] Server-side delegation proxies can use reflection or direct invocation to pass parameter values ​​to the target method in the target service implementation, execute the target method, and obtain the result. Alternatively, server-side delegation proxies can invoke the target method through function pointers or delegates to obtain the result.

[0199] S907, based on the call result, determine the response data fields of the unified transmission object.

[0200] The server-side delegation proxy writes the call result into the response data field of the unified transport object. Alternatively, the server-side delegation proxy calls the encoding interface of the data codec to encode the call result into a key-value structure and then writes it into the response data field.

[0201] S908 encodes the unified transmission object into response data and returns the response data to the calling device.

[0202] The server delegates the call to the serialization interface of the data codec to encode the Uniform Transmission Object into response data, and then returns it to the calling device via a network connection.

[0203] In this embodiment, the server-side proxy automatically decodes the request data and converts the parameter values ​​through the configured request parameter model, and then calls the target invocation method in the target service implementation, thus realizing server-side service invocation without reflection.

[0204] Based on the above embodiments, in an exemplary embodiment, the specific implementation process of the service invocation method is described in detail through the interaction between the calling device and the server device. By determining the delegation, invocation adaptation and encoding / decoding rules during the generation period, and completing request encapsulation, method invocation, response parsing and data encoding / decoding processing based on the generation results during the runtime, the overhead of dynamic parsing and adaptation during the runtime can be reduced.

[0205] In service invocation scenarios, when a calling device initiates a remote call (i.e., a call request), it can encode a unified transmission object carrying the call information (i.e., request data) and pass it to the underlying communication link, which is then responsible for transmitting the data to the server device. Similarly, after processing, the server device also needs to encode the unified transmission object carrying the call result and return it to the calling device through the same communication link. Based on this, the remote call path between the calling device and the server device can adopt a string-based transmission interface protocol and rely on the communication link. That is, the calling device and the server device exchange request and response data through this string-based transmission interface. The communication link is only responsible for providing the remote connection object for the calling device and transmitting request and response data in JSON string format; it is unaware of the specific business service interface components. This transmission interface protocol can be abstractly represented as: ServiceStringTransport { Invoke(req: String) ->res: String } Here, `req` represents the request string, and `res` represents the response string. The calling proxy sends the request string and receives the response string through this stringified transmission interface, while the server proxy receives the request string and returns the response string through the same interface.

[0206] In one implementation, the communication link uses Thrift as the network communication layer to establish a remote connection with the server, providing a string-based transmission interface. This Thrift-based string-based transmission interface is used to balance cross-platform communication capabilities and interface protocol maintenance costs. Thrift provides a unified remote communication foundation for different native language environments, enabling data transmission between the calling and serving ends across different languages, processes, or deployment nodes. Simultaneously, because the communication interface is fixed for string input and output, changes to the business interface do not require synchronous modifications to the communication layer interface definition, thereby reducing the maintenance costs of the remote interface protocol.

[0207] In the aforementioned string-based transmission interface, both the request and response strings are in JSON string format. The calling end delegate encapsulates an interface call into a unified transmission object and encodes it into a JSON request string using a data codec. After processing the call, the server-side delegate writes the response result into the unified transmission object and encodes it into a JSON response string before returning it. Because JSON serialized data can express basic types, structures or classes, collections, and mappings in a unified way, and features clear structure, mature cross-language support, and ease of debugging and logging, it is suitable as the internal data representation format for request and response strings.

[0208] The unified transport object directly contains key fields such as service category, service type, operation type, request data, and response data. This enables the server-side delegation proxy to determine the target service scope based on the service category and service type, determine the method or function to be executed based on the operation type, and parse the call parameters based on the request data. The unified transport object ServiceTransport is represented as: ServiceTransport =< ServiceClass: String, ServiceType: String, OperationType: String, RequestData: Any, ResponseData: Any > In this system, ServiceClass represents the business category to which the service belongs (string type); ServiceType represents the specific service object type within that category (string type); OperationType represents the interface method or function corresponding to this call (string type); RequestData carries the request parameter data (dynamic value type); and ResponseData carries the response result data (dynamic value type). When the calling client's proxy initiates a request, it populates ServiceClass, ServiceType, OperationType, and RequestData, and encodes ServiceTransport as a JSON request string. After the server-side proxy completes the call processing, it populates ResponseData and encodes ServiceTransport as a JSON response string before returning it to the calling client.

[0209] The caller-side delegation proxy is generated according to the service interface model, exposing methods or functions consistent with the original service interface. It passes parameters and receives return results using native language interface calling methods, without needing to directly handle request encapsulation, network communication protocols, parameter serialization, and response parsing logic. The caller-side delegation proxy is based on the caller-side delegation proxy file and works collaboratively in the three processes of registration management, call processing, and communication adaptation to complete the delegation proxy mechanism.

[0210] The caller-side delegation proxy file is a core component of the caller-side delegation proxy layer. It is used to carry service interface proxy methods, proxy registration, request parameter encapsulation, response result parsing, local call adaptation, and remote call adaptation at runtime.

[0211] The proxy methods or functions in the caller's delegation proxy file correspond to the methods or functions of the original service interface. The caller triggers the call processing flow of the delegation proxy layer by invoking the target method or function. During execution, the proxy method or function reads the call signature information and proxy encoding / decoding metadata written during the generation phase to obtain the current call ReqParam and ResReturn. For the registration management process, based on the caller's delegation proxy file registration logic, when the generated caller's delegation proxy file is loaded, referenced, or initialized by the application project, a correspondence is established between the service interface, service identifier, and caller's delegation proxy object. This allows the caller to obtain the corresponding proxy object through the service interface and obtain the location information of the target service through the registry center or an equivalent service location mechanism.

[0212] The invocation processing phase is mainly divided into two dimensions: request processing and response processing. In the request processing, if it's a remote call, the `ReqParam` is written to the `RequestData` of the `ServiceTransport`, and then sent by the communication adaptation logic; if it's a local call, the local service implementation is called directly, and the response is returned via the same path. In the response processing, the proxy receives the `ServiceTransport` returned by the remote service through communication adaptation and converts the `ResponseData` of the `ServiceTransport` into the return value of the service interface based on `ResReturn`. For the communication adaptation process, only when interfacing with the underlying communication framework under the remote call path, the `ServiceTransport` is converted into a JSON request string using a data codec, the request is sent through the Thrift string transmission interface, and the JSON response string is received, then decoded back into a `ServiceTransport` using the data codec. Based on the above invocation chain design of the proxy, the invocation lifecycle is as follows: Figure 10 As shown.

[0213] Through the above-mentioned caller-side delegation and proxy processing method, the caller still initiates the call using the native interface. The caller-side delegation and proxy internally completes service location, local or remote path adaptation call, request JSON encoding, string communication, response JSON decoding and return result adaptation, realizing a unified connection between interface call form, communication transmission form and data encoding and decoding processing.

[0214] Furthermore, the server-side delegation proxy receives remote call requests, parses the request string into a unified transport object, locates the target service and its corresponding method or function based on ServiceClass, ServiceType, and OperationType, and completes request parameter parsing, actual service invocation, and response result encapsulation based on a data codec. The server-side delegation proxy, based on a server-side delegation proxy file, collaboratively completes the delegation proxy mechanism in three processes: registration management, call processing, and communication adaptation.

[0215] The server-side delegation proxy file is a core component of the server-side delegation proxy layer. It handles service registration, service implementation binding, method or function location, request parameter parsing logic, actual service invocation, and response result encapsulation at runtime. The proxy methods or functions in the server-side delegation proxy file correspond to the methods or functions in the service interface and are bound to the actual service implementation. Upon receiving a JSON request string, the server-side delegation proxy decodes it into a ServiceTransport request object and reads its ServiceClass, ServiceType, and OperationType. ServiceClass and ServiceType determine the scope of the target service, while OperationType identifies the interface method or function corresponding to this request.

[0216] Before executing the target method or function, the server-side delegation proxy reads the request parameter model ReqParam required for the current call and parses the RequestData in ServiceTransport into parameter values ​​that the actual service implementation can accept. After completing the parameter parsing, it calls the bound actual service implementation, obtains the call result, and returns it.

[0217] For the registration management process, based on the proxy registration logic of the server-side proxy file, when the generated server-side proxy file is loaded, referenced or initialized by the application project, the corresponding relationship between ServiceClass, ServiceType, server-side proxy and real service implementation is established, and service location information is published.

[0218] For the call processing, the target call method or function in the server-side delegate proxy file is located based on ServiceClass, ServiceType, and OperationType. The request parameters are parsed in combination with the parameter parsing method, the real service implementation is called, and the response result is handed over to the communication adaptation layer.

[0219] For the communication adaptation process, the service receives the JSON request string sent by the calling client's delegate, decodes it into a ServiceTransport using a data codec, passes it to the calling process, calls the target method or function to obtain the return result, writes the return result into the ServiceTransport's ResponseData, encodes it into a JSON response string using a data codec, and returns it to the calling client's delegate through a stringified transmission interface. Based on the above call chain design of the server-side delegate, the server-side call lifecycle is as follows: Figure 11 As shown.

[0220] Through the above-described server-side delegation and proxy processing method, the server can complete request location, parameter parsing, real service invocation, and response return based on the service identifier, call signature, and proxy encoding / decoding metadata determined during the generation period, without relying on the full runtime dynamic proxy mechanism, thus ensuring that the server-side call processing logic is consistent with the call-side delegation and proxy.

[0221] Furthermore, the data codec, based on the aforementioned ServiceTransport, request parameter model, and response result model, is used to complete the conversion between request parameters and ServiceTransport's RequestData, the conversion between ServiceTransport and JSON strings, and the restoration of ServiceTransport's ResponseData into the interface return result. The request parameter model can be represented as ReqParam or ReqParam[], and the response result model can be represented as ResReturn or ResReturn[]: ReqParam=<ParamMeta,ParamName,ParamIndex,ParamValue> ResReturn=<ReturnMeta,ReturnValue> , During request parameter encoding, the data codec receives ReqParam or ReqParam[] and writes the calling interface parameters into RequestData in ServiceTransport based on ParamMeta, ParamName, ParamIndex, and ParamValue. During request parameter decoding, the data codec restores RequestData to the interface parameters acceptable to the actual service implementation on the server side based on ReqParam or ReqParam[]. During response result encoding, the actual service return result is carried as ResponseData in ServiceTransport and returned as a JSON response string. During response result decoding, the data codec restores ResponseData to the return result of the calling interface based on ResReturn or ResReturn[]. During JSON encoding and decoding, the data codec serializes ServiceTransport into a JSON request string or JSON response string, deserializes the JSON request string or JSON response string back into ServiceTransport, or performs fallback processing by converting the source data to be decoded into the target structure data.

[0222] Data codecs include codec schedulers, basic type decoders, time type decoders, field decoders, object decoders, element decoders, collection decoders, value item decoders, mapping decoders, extended type decoders, and JSON codecs. In the actual decoding process, DataKind is used to determine the organization of RequestData, or to determine the target decoder to use. Target decoders include: DataKindPrimitive->Basic Type Decoder DataKindTime->Time Type Decoder DataKindObject->Object Decoder DataKindCollection->Collection Decoder DataKindMap->Mapping Decoder DataKindCustom->Extended Type Decoder DataKindSpecial->Extended Type Decoder The decoder determined by DataKind above can be used for request parameter decoding, response result decoding, and can also be called by object decoding, field decoding, element decoding, or map decoding when processing nested collections.

[0223] DataType, FieldMeta, ElementMeta, ValueMeta, and RuntimeBinding are used for fine-grained processing within their respective decoders; the field decoder is used for field-level hierarchical decoding scenarios; the element decoder is used for decoding each element in a collection; the value decoder is used for decoding a single value in a mapping; and the JSON codec is used for converting between target data and JSON strings, as well as converting intermediate data into target structured data. It is implemented using the standard JSON library provided by the target native language or a third-party JSON library, serving as a general fallback encoding and decoding capability called by the encoding and decoding scheduler.

[0224] The aforementioned codec scheduler is used to coordinate the processing of request parameter encoding, request parameter decoding, response result encoding, and response result decoding. It receives the request parameter model, response result model, and ServiceTransport, and selects different scheduling paths according to the current processing stage.

[0225] When encoding request parameters, the codec scheduler receives ReqParam or ReqParam[]. When the request parameter is ReqParam, it reads ParamMeta, ParamName, ParamIndex, and ParamValue, and reads the DataKind of ParamMeta. Different processing is performed depending on the type of DataKind. For DataKindPrimitive, DataKindTime, DataKindCollection, DataKindCustom, and the directly transmittable DataKindSpecial type, ParamValue is wrapped according to ParamName or ParamIndex.<String,Any> The key-value structure is written to RequestData; for DataKindMap and DataKindObject types, ParamValue is written directly to RequestData. When the request parameter is ReqParam[], it is created.<String,Any> The key-value structure is used to iterate through and retrieve the current ReqParam, sequentially reading ParamMeta, ParamValue, ParamName, and ParamIndex. Using either the current parameter's ParamName or ParamIndex as the key, the ParamValue is written to the created key-value structure and then to RequestData, forming the final ServiceTransport's RequestData. The corresponding request parameter encoding and scheduling logic is as follows: Figure 12 As shown.

[0226] During request parameter decoding, the codec scheduler receives RequestData and ReqParam or ReqParam[]. When the input is ReqParam, it reads ParamMeta, ParamName, ParamIndex, and ParamValue from ReqParam. Based on ParamName or ParamIndex, it reads the corresponding parameter data from RequestData. Then, it reads the DataKind of ParamMeta and determines the DataKind. Depending on the DataKind, the decoding scenarios are as follows: When DataKind is DataKindPrimitive, the basic type decoder is called, with the parameter data, ParamMeta's DataType, and ParamValue as inputs; When DataKind is DataKindTime, the time type decoder is called, with the parameter data, ParamMeta's DataType, and ParamValue as inputs; When DataKind is DataKindCustom or DataKindSpecial, the extended type decoder is invoked, with the parameter data, ParamMeta, and ParamValue as inputs. When DataKind is DataKindObject, the object decoder is called, with the input being the parameter data, ParamMeta, and ParamValue; When DataKind is DataKindCollection, the collection decoder is called, with the input being the parameter data, ParamMeta, and ParamValue; When DataKind is DataKindMap, the mapping decoder is called, with the input being parameter data, ParamMeta, and ParamValue; Finally, the single-parameter data is written to the target parameter pointed to by ParamValue. When the input is ReqParam[], iterate through ReqParam[], reading ParamMeta, ParamName, ParamIndex, and ParamValue in the order of iteration. Then, based on ParamName or ParamIndex, read the corresponding parameter data from RequestData. Next, read the DataKind of ParamMeta, determine the DataKind, and call the corresponding decoder and input data for the ReqParam scenario based on the DataKind. After all ReqParam[] data is processed, the interface parameters are formed. The corresponding request parameter decoding scheduling logic is as follows: Figure 13 As shown.

[0227] When encoding the response result, the codec scheduler receives the ServiceTransport, calls the JSON codec, obtains the encoded JSON response string, and returns it.

[0228] During response decoding, the codec scheduler receives ResponseData and ResReturn or ResReturn[]. When the input is ResReturn, it reads ReturnValue and ReturnMeta from ResReturn, then reads DataKind from ParamMeta and determines DataKind. Depending on the DataKind, the decoding scenarios are as follows: When DataKind is DataKindPrimitive, the basic type decoder is called, with the input being ResponseData, ReturnMeta's DataType, and ReturnValue; When DataKind is DataKindTime, call the time type decoder, with the input being ResponseData, ReturnMeta's DataType, and ReturnValue; When DataKind is DataKindCustom or DataKindSpecial, call the extended type decoder with ResponseData, ReturnMeta, and ReturnValue as inputs. When DataKind is DataKindObject, the object decoder is called, with ResponseData, ReturnMeta, and ReturnValue as inputs; When DataKind is DataKindCollection, the collection decoder is called with ResponseData, ReturnMeta, and ReturnValue as input. When DataKind is DataKindMap, the mapping decoder is called, with ResponseData, ReturnMeta, and ReturnValue as inputs; Finally, ResponseData is written to the return result pointed to by ReturnValue. When the input is ResReturn[], ResReturn[] is traversed, and ReturnValue and ReturnMeta are read from the current ResReturn in turn. DataKind of ParamMeta is read and the DataKind is determined. Then, the corresponding decoder and input data in the ResReturn scenario are called according to DataKind. After all ResReturn[] are processed, the interface return result is formed. The corresponding response result decoding scheduling logic is as follows: Figure 14 As shown.

[0229] The basic type decoder is used to process DataKindPrimitive data decoding, performing value conversion based on the precise type. For DataTypeBool, it converts the input value to a Boolean type in the target language; for DataTypeString, it converts the input value to a string type in the target language. The precise type DataType corresponding to DataKindPrimitive includes: DataTypeBool, DataTypeInt, DataTypeLong, DataTypeInt8, DataTypeInt16, DataTypeInt32, DataTypeInt64, DataTypeUInt, DataTypeULong, DataTypeUInt8, DataTypeUInt16, DataTypeUInt32, DataTypeUInt64, DataTypeFloat, DataTypeDouble, and DataTypeString.

[0230] For DataTypeInt, DataTypeLong, DataTypeInt8, DataTypeInt16, DataTypeInt32, and DataTypeInt64, convert them according to the signed integer type; for DataTypeUInt, DataTypeULong, DataTypeUInt8, DataTypeUInt16, DataTypeUInt32, and DataTypeUInt64, convert them according to the unsigned integer type; for DataTypeFloat and DataTypeDouble, convert them according to the single-precision or double-precision floating-point type in the target language.

[0231] The input definition for the basic type decoder is: PrimitiveDecoderInput=<SrcValue,DataType,TargetValue> Wherein, SrcValue represents the source data to be decoded; DataType represents the exact data type; and TargetValue represents the target value to be written after decoding the source data.

[0232] The basic type decoder's specific decoding logic is as follows: It receives SrcValue, DataType, and TargetValue; it converts SrcValue to the target primitive type based on DataType; and it writes the conversion result to TargetValue. The corresponding basic type decoding logic is as follows: Figure 15 As shown.

[0233] The time type decoder is used to process DataKindTime data. Time type data is used to represent date, time, date and time, timestamp, and time interval objects. It does not contain field, element, or key-value hierarchy. Therefore, the time type decoder does not need to recursively parse object structure, collection elements, or map key-value pairs. It only needs to complete the value conversion based on the precise time type and the time representation method of the target language. Among them, the precise type DataType corresponding to DataKindTime includes: DataTypeDate, DataTypeClockTime, DataTypeDateTime, DataTypeTimestamp, and DataTypeDuration.

[0234] During the decoding process, the input to the time-type decoder is defined as: TimeDecoderInput=<SrcValue,DataType,TargetValue> Wherein, SrcValue represents the source data to be decoded; DataType represents the exact data type; and TargetValue represents the target value to be written after decoding the source data.

[0235] Based on DataType, SrcValue is converted to the target time type. The specific decoding logic is as follows: The function receives SrcValue, DataType, and TargetValue. For DataTypeDate, SrcValue is converted to a date type in the target language; for DataTypeClockTime, SrcValue is converted to a time type in the target language; for DataTypeDateTime, SrcValue is converted to a datetime type that includes both date and time; for DataTypeTimestamp, SrcValue is converted to a timestamp type; and for DataTypeDuration, SrcValue is converted to a time interval type. After all these conversions, the result is written to TargetValue. The corresponding time type decoding logic is as follows: Figure 16 As shown.

[0236] The field decoder is used to decode each field within an object, relying on the aforementioned ObjectBinding (see Table 8), FieldMeta (see Table 7), and BindingValue (see Table 6) to complete the field decoding and restoration. ObjectBinding describes the binding relationship between the object's field metadata and the runtime field target, providing the target object's FieldMeta[] and FieldValues. FieldMeta describes the field metadata, including FieldName, DataKind, DataType, and the corresponding type metadata. BindingValue provides runtime binding information when the field is DataKindObject, DataKindCollection, or DataKindMap, providing a way to create, append, or write object fields, collection elements, or mapped values ​​during decoding. This is represented by the Meta corresponding to ObjectBinding, CollectionBinding, or MapBinding, respectively.

[0237] The input to the field decoder is defined as: FieldDecoderInput=<ObjectFieldData,FieldMeta[],FieldValues> Among them, ObjectDataMap represents object field data that can be read by field name or field identifier (such as key-value objects, structured objects, or equivalent field key-value structures in the target language); FieldMeta[] represents a collection of FieldMeta; FieldValues ​​represents the writing target collection of each field in the target object, which is usually composed of the address, reference, or equivalent writable object of each field of the target object. FieldValues ​​and FieldMeta[] correspond to each other in the order of fields.

[0238] The decoding logic of the field decoder is as follows: It receives ObjectFieldData, FieldMeta[], and FieldValues, reads a FieldMeta in the index order of FieldMeta[], reads FieldName and FieldDataMeta from the current FieldMeta, and reads ReadFieldValue from ObjectDataMap according to FieldName; then reads FieldValue at the current index from FieldValues, and continues to read DataKind and DataType from FieldDataMeta. When DataKind is DataKindPrimitive or DataKindTime, the input is ReadFieldValue, DataType, and FieldValue, and the corresponding decoder is called to complete the conversion and writing.

[0239] When DataKind is DataKindCustom or DataKindSpecial, and the input is ReadFieldValue, FieldDataMeta, and FieldValue, the corresponding decoder is called to complete the conversion and writing.

[0240] When DataKind is DataKindObject, the field decoder determines whether FieldValue is BindingValue. If FieldValue is not BindingValue, the JSON decoder is called with input ReadFieldValue and FieldValue. If FieldValue is BindingValue, the Value and Meta of BindingValue are read, Meta is converted to ObjectBinding, and the internal FieldMeta[] and internal FieldValues ​​of ObjectBinding are read. Then, it is determined whether ReadFieldValue is an object structure that can be read by field, and whether the internal FieldMeta[] and internal FieldValues ​​exist. If the conditions are met, the field decoder is called again to process the internal fields with input ReadFieldValue, internal FieldMeta[], and internal FieldValues. If the conditions are not met, the JSON decoder is called with input ReadFieldValue and Value. In both cases, the next index FieldMeta needs to be read again until all FieldMeta[] is processed, and finally, all target field values ​​pointed to by FieldValues ​​are restored.

[0241] When DataKind is DataKindCollection, the field decoder determines whether FieldValue is BindingValue. If FieldValue is BindingValue, the Meta of BindingValue is converted to CollectionBinding, and the collection decoder is called with the inputs ReadFieldValue, CollectionBinding, and the Value of BindingValue. If FieldValue is not BindingValue, FieldDataMeta is converted to CollectionMeta, and the collection decoder is called with the inputs ReadFieldValue, CollectionMeta, and FieldValue.

[0242] When DataKind is DataKindMap, the field decoder determines whether FieldValue is BindingValue. If FieldValue is BindingValue, the Meta of BindingValue is converted to MapBinding, and the mapping decoder is called, with the inputs being ReadFieldValue, MapBinding, and the Value of BindingValue. If FieldValue is not BindingValue, FieldDataMeta is converted to MapMeta, and the mapping decoder is called, with the inputs being ReadFieldValue, MapMeta, and FieldValue. The corresponding field decoder decoding logic is as follows: Figure 17 As shown.

[0243] The object decoder is used to handle data decoding of DataKindObject, which represents an object data structure composed of multiple fields. The precise type DataType corresponding to DataKindObject includes DataTypeStruct and DataTypeClass. Since object types include structs, classes, or other composite data objects composed of fields, and object types contain field hierarchies, the object decoder needs to determine the field structure based on the object metadata, call the field decoder to decode the field values, and restore the request parameter data or response result data to the target native object.

[0244] The input definition for the object type decoder is: ObjectDecoderInput=<SrcValue,DataTypeMeta,TargetValue> Here, SrcValue represents the source data to be decoded; DataTypeMeta represents the data type metadata corresponding to the target object type, which describes the type name, field metadata set, and field binding information of the target object; TargetValue represents the target write value after the current source data is decoded.

[0245] The object decoder's decoding logic is as follows: It receives `SrcValue`, `DataTypeMeta`, and `TargetValue`; parses `DataTypeMeta` into `ObjectBinding` or `ObjectMeta`; reads `FieldMeta[]` and `FieldValues` from `ObjectBinding` or reads `FieldMeta[]` from `ObjectMeta`; and determines whether `SrcValue` is `ObjectFieldData` and whether both `FieldMeta[]` and `FieldValues` exist. If the above conditions are met, `SrcValue` is converted to `ObjectFieldData`, and the field decoder is called with inputs of `ObjectFieldData`, `FieldMeta[]`, and `FieldValues`. If the above conditions are not met, the JSON decoder is called with inputs of `SrcValue` and `TargetValue`. The corresponding object decoder decoding logic is as follows: Figure 18 As shown.

[0246] The element decoder is used to decode a single element of a set while the set decoder iterates through the set elements. The input to the element decoder is defined as: ElementDecoderInput=<ElementData,ElementMeta,BindingValue> Here, ElementData represents the current element data retrieved by index from any[]; ElementMeta represents the data type metadata of the current element; and BindingValue represents the element receiving object created by ElementFactory, with its structure defined in Table 6. The Value of BindingValue represents the write target after decoding the current element; the Meta of BindingValue represents the runtime binding metadata of the current element. For composite elements such as objects, collections, or mappings, Meta is used to provide runtime binding information such as field writing, child element creation, and key-value writing.

[0247] In the decoding logic, if the element decoder calls a composite type decoder such as an object, collection, or map, the element decoder performs metadata merging processing as needed. Metadata merging processing combines the static type metadata of the collection elements with the runtime bound metadata of the current element to form the actual decoded metadata. ActualElementMeta=Merge(ElementMeta,Meta) ElementMeta, derived from CollectionMeta, describes the data type of the collection elements. If BindingValue.Meta is empty, ActualElementMeta is taken as ElementMeta.

[0248] The specific decoding logic of the element decoder is as follows: It receives ElementData, ElementMeta, and BindingValue; first, it checks whether ElementMeta exists. If ElementMeta does not exist, it calls the JSON decoder, with the input being ElementData and the Value of BindingValue.

[0249] If ElementMeta exists, read ElementMeta's DataKind and DataType.

[0250] When DataKind is DataKindPrimitive, the basic type decoder is called. The input is ElementData, DataType, and the Value of BindingValue. The basic type decoder converts ElementData into the target native basic data type according to DataType and writes it into the Value of BindingValue.

[0251] When DataKind is DataKindTime, the time type decoder is called. The input is ElementData, DataType, and the Value of BindingValue. The time type decoder converts ElementData into the target native time type data according to DataType and writes it into the Value of BindingValue.

[0252] When DataKind is DataKindObject, ElementMeta is converted to ObjectMeta, and FieldMeta[] is obtained from ObjectMeta; simultaneously, FieldValues ​​are obtained from the Meta of BindingValue. If ElementData is ObjectFieldData, and both FieldMeta[] and FieldValues ​​exist, the field decoder is called to write ObjectFieldData into the Value of BindingValue. If ElementData cannot be converted to ObjectFieldData, or if FieldMeta[] or FieldValues ​​of ObjectMeta are missing, the element decoder calls the JSON decoder, with the input being ElementData and the Value of BindingValue.

[0253] When DataKind is DataKindCollection, ElementMeta and BindingValue.Meta are merged to obtain ActualElementMeta. Then, the collection decoder is called, taking ElementData, ActualElementMeta, and the Value of BindingValue as input.

[0254] When DataKind is DataKindMap, ElementMeta and BindingValue.Meta are merged to obtain ActualElementMeta. Then, the mapping decoder is called, taking ElementData, ActualElementMeta, and the Value of BindingValue as input.

[0255] When DataKind is DataKindCustom or DataKindSpecial, the extended type decoder is invoked. The input is the Value of ElementData, ElementMeta, and BindingValue. The corresponding element decoder decoding logic is as follows: Figure 19 As shown.

[0256] The collection decoder is used to process the data decoding of DataKindCollection, which represents a data structure consisting of multiple elements. The exact DataType range corresponding to DataKindCollection includes: DataTypeFixedCollection, DataTypeDynamicCollection, and DataTypeCollection.

[0257] After each element data is obtained, the collection decoder first calls ElementFactory() to create a receiving object for that element, and then hands over the element data, element type metadata, and receiving object to the element decoder for processing.

[0258] The collection decoder depends on CollectionMeta (structure definition in Table 3) and CollectionBinding (structure definition in Table 4).

[0259] Among them, the Type of CollectionMeta represents the exact type of the collection itself, and its value range is DataTypeFixedCollection, DataTypeDynamicCollection, or DataTypeCollection; The CollectionBinding's ElementFactory is a function used to create a receiving object for a single element. Its function form is: ElementFactory()->BindingValue The `AppendElement` method of `CollectionBinding` is a function that writes the decoded elements into the collection. Its function form is: AppendElement(ElementValue,ElementIndex)->void Here, ElementIndex represents the index position of the current element in the collection. For DataTypeFixedCollection, AppendElement writes the element to the fixed position according to ElementIndex; for DataTypeDynamicCollection and DataTypeCollection, AppendElement appends the elements to the target collection in traversal order.

[0260] The input to the set type decoder is defined as follows: CollectionDecoderInput=<SrcValue,DataTypeMeta,TargetValue> Here, SrcValue represents the source data to be decoded; DataTypeMeta represents the data type metadata corresponding to the target collection type, which describes the type of the target collection itself, the metadata of the collection elements, and the binding information of the elements; TargetValue represents the target write value after the source data is decoded.

[0261] The specific decoding logic of the collection decoder is as follows: It receives SrcValue, DataTypeMeta, and TargetValue, and parses CollectionMeta and CollectionBinding from DataTypeMeta. CollectionMeta provides the target collection's own type, element type metadata, and fixed-length information; CollectionBinding provides ElementFactory and AppendElement. Then, it determines whether SrcValue is ElementData[]. ElementData[] represents a sequence of source data for the collection, consisting of multiple element source data, where each ElementData corresponds to an element to be decoded in the collection.

[0262] If SrcValue cannot be converted to ElementData[], the JSON decoder is called. If SrcValue can be converted to ElementData[], the existence of CollectionBinding, ElementFactory, and AppendElement is checked. If any of the above information is missing, the JSON decoder is called with SrcValue and TargetValue as input. If the collection binding information is complete, SrcValue is converted to ElementData[], and then the Type and ElementMeta of CollectionMeta are read. When the Type of CollectionMeta is DataTypeFixedCollection, the ElementData[] is traversed by index to obtain the current element value ElementData and the current index ElementIndex. The ElementFactory is called to create BindingValue, and then the element decoder is called with ElementData, the ElementMeta of CollectionMeta, and BindingValue as input. After the element is decoded, AppendElement is called to write the element to the corresponding index position of the fixed collection with BindingValue.Value and ElementIndex as input. When CollectionMeta.Type is DataTypeDynamicCollection or DataTypeCollection, it iterates through ElementData[] to get the current element value ElementData, calls ElementFactory to create BindingValue, and then calls the element decoder with the input ElementData, the ElementMeta of CollectionMeta, and BindingValue. After the element is decoded, it calls AppendElement to append the element to the target collection with the input BindingValue.Value. The corresponding collection decoder decoding logic is as follows. Figure 20 As shown.

[0263] The value decoder is used to decode a single value in the map. When the map decoder traverses the source data of the map, for each original value corresponding to a key, it calls the value decoder to complete the type conversion and writing of the value.

[0264] The input to the value term decoder is defined as follows: ValueItemDecodeInput=<RawValue,ValueMeta,TargetValue> Wherein, RawValue represents the raw value to be decoded; ValueMeta represents the type metadata of the target value, used to determine the value decoding method; and TargetValue represents the target value to be written after the raw value is decoded.

[0265] The specific decoding logic of the value item decoder is as follows: It receives RawValue, ValueMeta, and TargetValue; first, it checks if TargetValue exists. If TargetValue does not exist, the decoding of the current value item ends; otherwise, it checks if ValueMeta exists. If ValueMeta does not exist, it calls the JSON decoder, with RawValue and TargetValue as input; if ValueMeta exists, it reads DataKind and DataType from ValueMeta. When DataKind is DataKindPrimitive or DataKindTime, and the input is RawValue, DataType, and TargetValue, the corresponding decoder is called to complete the conversion and writing; when DataKind is DataKindObject, DataKindCollection, DataKindMap, DataKindCustom, or DataKindSpecial, and the input is RawValue, ValueMeta, and TargetValue, the corresponding decoder is called to complete the conversion and writing. The corresponding value item decoder decoding logic is as follows: Figure 21 As shown.

[0266] The mapping decoder is used to process the data decoding of DataKindMap, restoring the mapping structure to a mapping or equivalent data structure in the target native language. DataKindMap represents a data structure composed of key-value pairs, and the corresponding precise type DataType range includes: DataTypeMap, DataTypeStringMap, and DataTypeIntegerMap.

[0267] The input to the mapping decoder is defined as: MapDecodeInput=<SrcValue,DataTypeMeta,TargetValue> Here, SrcValue represents the source data to be decoded; DataTypeMeta represents the data type metadata corresponding to the target mapping type, used to describe the key type and value type metadata of the target mapping; TargetValue represents the target write value after the source data is decoded.

[0268] The mapping decoder relies on MapMeta (structure definition in Table 3), MapBinding (structure definition in Table 6), and ActualValueMeta during the decoding process. Specifically, MapMeta's KeyType represents the key type of the target mapping, and MapMeta's ValueMeta represents the data type metadata of the target mapping value. MapBinding's ValueFactory is used to create runtime receiver objects for individual mapping values; its function form is as follows: ValueFactory()->BindingValue (Structure definition see Table 6) MapBinding's SetValue method is used to write the decoded key-value pairs into the target map. Its function form is: SetValue(Key,Value)->void Here, Key represents the target key value after conversion, and Value represents the mapped value after decoding.

[0269] ActualValueMeta metadata merging processing is used to combine the static type metadata of the mapped value and the runtime binding metadata of the current mapped value to form the actual decoded metadata, the structure of which is defined as follows: ActualValueMeta=Merge(ValueMeta,Meta) ValueMeta, derived from ValueMeta of MapMeta, describes the data type metadata of the mapped value; Meta, derived from Meta of BindingValue, describes the runtime binding information of the current mapped value. If BindingValue.Meta is empty, ActualValueMeta is taken as ValueMeta.

[0270] The specific decoding logic of the mapping decoder is as follows: It receives SrcValue, DataTypeMeta, and TargetValue; first, it determines whether SrcValue can be converted into MapSource. The structure of MapSource is defined as follows: MapSource=map<string,any> MapSource represents the source data for mapping, which stores the raw keys as strings and the raw values ​​as arbitrary values. Each item in MapSource contains RawKey and RawValue, where RawKey is the raw key in string form and RawValue is the raw value corresponding to the current key.

[0271] If SrcValue cannot be converted to MapSource, the JSON decoder is invoked, with SrcValue and TargetValue as input. If SrcValue can be converted to MapSource, MapMeta and MapBinding are parsed from DataTypeMeta. If MapMeta is empty or its DataType is DataTypeMap, the JSON decoder is invoked, with SrcValue and TargetValue as input. If MapMeta's DataType is DataTypeStringMap or DataTypeIntegerMap, the system continues to check if MapBinding, ValueFactory, and SetValue all exist. If any of them do not exist, the JSON decoder is invoked, with SrcValue and TargetValue as input; if all of them exist, the MapSource is traversed in order, and the current RawKey and RawValue are read item by item. Here, RawKey represents the raw string key of the current mapped item, and RawValue represents the raw value of the current mapped item. Next, the KeyType of MapMeta is determined. If the KeyType of MapMeta is DataTypeString, the RawKey is directly written to the Key. If the KeyType of MapMeta is any of DataTypeInt, DataTypeLong, DataTypeInt8, DataTypeInt16, DataTypeInt32, and DataTypeInt64, the RawKey is converted to the target signed integer key and written to the Key. If the KeyType of MapMeta is any of DataTypeUInt, DataTypeULong, DataTypeUInt8, DataTypeUInt16, DataTypeUInt32, and DataTypeUInt64, the RawKey is converted to the target unsigned integer key and written to the Key. Then, ValueFactory is called to create BindingValue. Afterwards, the ValueMeta of MapMeta and the Meta of BindingValue are merged to obtain ActualValueMeta. Finally, the value decoder is called, with the input being the Value of RawValue, ActualValueMeta, and the Value of BindingValue. After the mapping value is decoded, SetValue is called again to write the target mapping corresponding to TargetValue, with the input being Key and BindingValue.Value. This process is repeated until all mapping items in MapSource have been processed.The corresponding mapping decoder decoding logic is as follows. Figure 22 As shown.

[0272] The extended type decoder is used to process data of types DataKindCustom and DataKindSpecial, providing unified processing for custom alias types, dynamic types, or special data types in the target language. The precise type DataType corresponding to DataKindCustom includes the following range: DataTypeCustomPrimitive. And DataTypeCustomComposite.

[0273] The DataType range corresponding to DataKindSpecial includes: DataTypeAny and DataTypeOther.

[0274] The input definition for the extended type decoder is as follows: ExtensionDecodeInput=<SrcValue,DataTypeMeta,TargetValue> Here, SrcValue represents the source data to be decoded; DataTypeMeta represents the data type metadata corresponding to the target extended type, which is used to provide DataKind, DataType, and TypeName; TargetValue represents the target value to be written to the decoded result.

[0275] The extended type decoder's specific decoding logic is as follows: It receives SrcValue, DataTypeMeta, and TargetValue; it reads DataType and TypeName from DataTypeMeta; when DataType is DataTypeCustomPrimitive, it creates a corresponding basic precise type identifier based on TypeName according to the original type name and underlying type relationships recorded during generation. Then, it calls the basic type decoder, taking SrcValue, the created basic precise type identifier, and TargetValue as input. The basic type decoder then completes the conversion and writing of the source data to the target custom basic type.

[0276] When the DataType is another type, including DataTypeCustomComposite, DataTypeAny, or DataTypeOther, the JSON decoder is invoked. The inputs are SrcValue and TargetValue. The SrcValue is decoded as a whole according to the target type and written to TargetValue. The corresponding extended type decoder decoding logic is as follows: Figure 23 As shown.

[0277] The JSON codec does not redefine the JSON data format. Instead, it calls native language JSON libraries or third-party JSON libraries to generate JSON strings, parse JSON strings, and convert intermediate data into target structured data.

[0278] It mainly includes three processing functions: a JSON string generation function, a JSON string parsing function, and a JSON value conversion function. Among them, the JSON string generation function is used to convert native language data into JSON strings, and the function definition is as follows: JsonEncode(SrcValue)->JsonString Here, SrcValue represents the native language data to be serialized, which can be basic data types, object data, collection data, mapping data, or other composite data types. JsonString represents the JSON string formed by serializing SrcValue.

[0279] The specific processing logic of the JSON string generation function JsonEncode is as follows: After receiving SourceValue, it first identifies the data format of SourceValue; if SourceValue is a basic type, it generates a string, number, boolean value, or null value according to the basic JSON values; if SourceValue is an object type, it generates a JSON object according to the object field names, field mapping rules, or JSON tags supported by the target language; if SourceValue is a collection type, it generates a JSON array according to the element order; if SourceValue is a mapping type, it generates a JSON object or an equivalent key-value structure according to the key-value relationship; if SourceValue is a complex nested structure, it recursively processes the fields, elements, or key-value pairs. The above serialization process is completed by the native language JSON library or a third-party JSON library, and its output is returned as a JsonString.

[0280] JSON string parsing functions are used to convert JSON strings into target native language data. The function definition is as follows: JsonDecode(JsonString,TargetValue)->void Here, JsonString represents the JSON string to be deserialized; TargetValue represents the target native language data object to be written.

[0281] The specific processing logic of the JSON string parsing function JsonDecode is as follows: After receiving JsonString and TargetValue, it writes data according to the target type of TargetValue. If the target type is a primitive type, the strings, numbers, booleans, or null values ​​in the JSON string are converted to their corresponding primitive values. If the target type is an object type, the field values ​​in the JSON object are written to the target object fields according to the field names, field mapping rules, or JSON tags supported by the target language. If the target type is a collection type, the data is written to the target collection in the order of JSON array elements. If the target type is a mapping type, the data is written to the target mapping according to the JSON object or equivalent key-value structure. If the target type is a complex nested structure, the fields, elements, or keys are recursively parsed. The above deserialization process is handled by the native language JSON library or a third-party JSON library, which writes the parsing results to TargetValue.

[0282] JSON value conversion functions are used to convert source data to be decoded into target structured data. Their function definitions are as follows: JsonValueDecode(SrcValue,TargetValue)->void Here, SrcValue represents the source data to be decoded, which can be object data, array data, mapped data, string, number, boolean value, null value, or other intermediate values ​​for JSON parsing; TargetValue represents the target structure data to be written.

[0283] The specific conversion logic of the JSON value conversion function JsonValueDecode is as follows: After receiving SrcValue and TargetValue, it first calls the JSON string generation function JsonEncode, taking SrcValue as input, and converts SrcValue into JsonString; then it calls the JSON string parsing function JsonDecode, taking JsonString and TargetValue as input, and parses JsonString according to the target type of TargetValue and writes it into the target structure data.

[0284] Therefore, the processing of JSON value conversion functions can be represented as an expression: JsonValueDecode(SrcValue,TargetValue)=JsonDecode(JsonEncode(SrcValue),TargetValue) This expression represents the combined call relationship between the JSON value conversion function and the JSON string generation and parsing functions. The corresponding JSON value conversion decoding logic is as follows: Figure 24 As shown.

[0285] The aforementioned proxy generation and service invocation methods are primarily based on the service interface definitions in the native language. During the generation phase, the interface methods, parameters, return values, and data structure metadata are parsed to automatically generate the calling-side proxy, the server-side proxy, and encoding / decoding auxiliary code. Without relying on full-runtime reflection and dynamic proxy mechanisms, a unified mechanism covering proxy construction, interface call adaptation, request / response processing, and data encoding / decoding is formed, ensuring consistency between interface definitions, proxy calls, and encoding / decoding rules, reducing redundant development and manual maintenance costs. This proxy generation and service invocation method achieves the following technical effects: 1. Based primarily on the service interface definition in the native language, source code scanning, interface parsing, call signature parsing, data structure parsing, and delegate proxy generation are completed during the generation phase, reducing the repetitive maintenance costs of independent interface description files, handwritten proxies, parameter encapsulation, return value parsing, and encoding / decoding adaptation code.

[0286] 2. It is applicable to native programming languages ​​such as C, C++, and Go, or limited reflection language environments. It does not rely on full runtime loading, dynamic proxy, and reflection invocation mechanisms, and can form stable delegation and encoding / decoding processing logic during compilation or generation.

[0287] 3. By using client-side and server-side delegation proxies, native interface calls, local calls, and remote calls are uniformly adapted, enabling callers to initiate calls in the form of native interfaces and reducing the coupling between callers and service providers.

[0288] 4. Integrate proxy generation, proxy assembly, and encoding / decoding metadata generation into the generator processing flow. This enables the synchronous generation of interface definitions, proxy code, assembly entry points, request parameters, response results, and encoding / decoding rules. It also ensures that the calling end, server end, and codec use the same set of type descriptions and processing rules, reducing the risk of inconsistent rules, incorrect type mapping, missing fields, and inconsistent return value processing after interface changes.

[0289] 5. The data codec processes data in layers and combines metadata binding mechanisms to restore complex structures, which can reduce the complete dependence on general deserialization and improve the consistency and accuracy of complex parameter and return value processing.

[0290] 6. JSON strings are used as the unified data transmission format, and combined with string-based transmission interfaces, to reduce the protocol maintenance costs and difficulties in cross-language communication, and to facilitate service calls and data exchange between different native language runtime environments.

[0291] In summary, the delegate / proxy generation method and service invocation method provided in the above embodiments can realize interface-driven automatic generation of delegate / proxy, automatic proxy invocation and efficient encoding / decoding processing in a native programming language environment. While reducing the cost of manual development and maintenance, it improves the consistency, maintainability and execution efficiency of the processing of complex data structures involved in parameters and return values ​​in the service invocation chain.

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

[0293] Corresponding to the delegate / agent generation method in the above embodiment, Figure 25 A schematic diagram of a proxy generation apparatus according to an embodiment of this application is shown. For ease of explanation, only the parts relevant to the embodiment of this application are shown. (Refer to...) Figure 25 The proxy generation apparatus of this embodiment includes: The source code acquisition module 2501 is used to acquire the source code project before the compilation period of the source code project of the native programming language. The scanning module 2502 is used to identify service identifiers, service interfaces, and service implementations in the source code project and generate scanning results. The service identifier is used to mark the services of the delegated proxy, the service interface is used to declare the calling methods of the delegated proxy, and the service implementation includes the business implementation logic that matches the calling methods in the service interface. The parsing module 2503 is used to parse the scan results and generate a parsing model; The delegate generation module 2504 is used to generate code files for the caller's delegate and the server's delegate based on the parsing model.

[0294] As an optional implementation, the scanning module 2502 is specifically used to: determine the target source code file based on the configuration information of the source code project and preset filtering rules; the preset filtering rules are used to exclude source code files in the source code project that do not participate in the generation of the delegated proxy; determine the tag definition used to identify the service in the target source code file as the service identifier; determine the interface declaration associated with the service identifier in the target source code file as the service interface; determine the business implementation logic in the target source code file that matches the method call in the service interface as the service implementation; and determine the scanning result based on the service identifier, service interface and service implementation.

[0295] As an optional implementation, the parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model; the parsing module 2503 includes: a first construction unit, used to construct a service interface model based on the correspondence between service identifiers and service interfaces in the scanning results; and a second construction unit, used to parse the calling method and construct a call signature model. The third construction unit is used to classify and parse the data structures involved in the calling method and build a data structure model; the fourth construction unit is used to build a service implementation model based on the service implementation information in the scanning results.

[0296] As an optional implementation, the third construction unit is specifically used for: obtaining each data structure and its data type in the calling method; the data structure includes parameters, return values, object fields, collection elements, and mapping keys; for each data type, determining its type classification in the type system based on its structural characteristics; determining its sub-class within the type classification based on its semantic information; parsing the data type to determine its internal structural composition information; generating type metadata corresponding to the data type based on its data type, type classification, sub-class, and internal structural composition information; and generating a data structure model based on each data structure and its corresponding type metadata.

[0297] As an optional implementation, the parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model. The delegation / proxy generation module is specifically used for: generating a request parameter model and a response result model corresponding to each calling method based on the call signature model; the request parameter model describes the first description information and the first runtime parameter storage information of each parameter in a single call request of the calling method; the response result model describes the second description information and the second runtime parameter storage information of each returned result in a single call response of the calling method; generating a call-side proxy method corresponding to the service interface based on the service interface model and the call signature model, and configuring the request parameter model and response result model in the call-side proxy method to form the call-side delegation / proxy code file; and generating a server-side proxy method based on the service interface model, the call signature model, and the service implementation model, and configuring the request parameter model in the server-side proxy method to form the server-side delegation / proxy code file.

[0298] As an optional implementation, the proxy generation device further includes: a binding model construction module, used to construct a runtime binding model based on the structured data types in the data structure model when generating the code file of the calling end proxy and the code file of the server end proxy; the runtime binding model is used to complete data creation, assignment and / or writing operations when processing structured data types at runtime; and a writing module, used to write the runtime binding model into the request parameter model and the response result model respectively.

[0299] As an optional implementation, when the structured data type is an object type, the runtime binding model includes an object binding model, which describes the correspondence between the field metadata of the object type and the fields written at runtime; when the structured data type is a collection type, the runtime binding model includes a collection binding model, which describes the correspondence between the element metadata of the collection type and the element creation and addition methods at runtime; when the structured data type is a mapping type, the runtime binding model includes a mapping binding model, which describes the correspondence between the value type metadata of the mapping type and the value creation and key-value writing methods at runtime.

[0300] Corresponding to one service invocation method in the above embodiment, Figure 26 A schematic diagram of a service invocation device according to an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown. (Refer to...) Figure 26 In this embodiment, the service invocation device is configured on the calling end device, which is configured with a code file of the calling end delegate generated by the delegate generation method; the service invocation device includes: The request retrieval module 2601 is used to retrieve the call request of the target service interface; the call request includes call parameters; The first writing module 2602 is used to determine the service category information and operation type information corresponding to the target service interface according to the call request, and write the service category information and operation type information into the unified transmission object; The second writing module 2603 is used to write the call parameters into the request data field of the unified transmission object according to the request parameter model configured in the code file of the caller's delegate. The first encoding module 2604 is used to encode the unified transmission object into request data; The data communication module 2605 is used to send request data to the server device and receive response data from the server device in response to the request data. The first decoding module 2606 is used to decode the response data into a unified transmission object and obtain the response data field of the unified transmission object; The conversion module 2607 is used to convert response data fields into the return results of the target service interface based on the response result model configured in the code file of the calling end delegate.

[0301] Corresponding to one service invocation method in the above embodiment, Figure 27 A schematic diagram of a service invocation device according to an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown. (Refer to...) Figure 27 This application provides a service invocation device configured on a server-side device, the server-side device being configured with a server-side delegate proxy code file generated by a delegate proxy generation method; the service invocation device includes: The data receiving module 2701 is used to receive request data sent by the calling device; The second decoding module 2702 is used to decode the request data into a unified transmission object; The service location module 2703 is used to locate the target service of the unified transmission object in the code file of the server-side delegated proxy based on the service category information of the unified transmission object. The method location module 2704 is used to locate the target call method in the target service based on the operation type information of the unified transmission object. The numerical conversion module 2705 is used to convert parameter data under the request data field of the unified transmission object into parameter values ​​according to the request parameter model configured in the code file of the server-side delegated proxy. The second calling module 2706 is used to call the target calling method using parameter values ​​and obtain the calling result; The field determination module 2707 is used to determine the response data fields of the unified transmission object based on the call result; The encoding module 2708 is used to encode the unified transmission object into response data and return the response data to the calling device.

[0302] As an optional implementation, the numerical conversion module 2705 is specifically used to: determine the type classification of parameter data under the request data field of the unified transmission object based on the first description information of the request parameter model configured in the code file of the server-side delegated proxy; when the type classification is a basic type classification, determine the specific basic type of the parameter data under the basic type classification based on the first description information in the request parameter model, and convert the parameter data into the corresponding parameter value according to the specific basic type; when the type classification is a structured type classification, determine the specific structured data type corresponding to the parameter data based on the runtime binding model in the request parameter model, and convert the parameter data into the corresponding parameter value according to the specific structured data type.

[0303] It should be noted that the information interaction and execution process between the modules in the above-mentioned proxy generation device and service invocation device are based on the same concept as the method embodiment of this application. For details on their specific functions and technical effects, please refer to the method embodiment section, which will not be repeated here.

[0304] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 28 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data required by the delegate / agent generation method or the service invocation method. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements the delegate / agent generation method or the service invocation method.

[0305] Those skilled in the art will understand that Figure 28The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0306] In one exemplary embodiment, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, can implement the steps in the various method embodiments described above.

[0307] In one exemplary embodiment, a computer program product is provided that, when run on a computer device, enables the computer device to perform the steps described in the various method embodiments above.

[0308] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can 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 includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographic device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0309] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0310] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0311] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0312] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0313] 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, and should all be included within the protection scope of this application.

Claims

1. A method for generating a delegated agent, characterized in that, include: Obtain the source code project before the compilation phase of the source code project in the native programming language; Identify the service identifiers, service interfaces, and service implementations in the source code project and generate scan results; the service identifiers are used to mark the services delegated to the proxy, the service interfaces are used to declare the calling methods of the proxy, and the service implementations include business implementation logic that matches the calling methods in the service interfaces; The scan results are analyzed to generate an analytical model; Based on the parsing model, generate the code file for the calling end delegate and the code file for the server end delegate.

2. The proxy generation method according to claim 1, characterized in that, The process of identifying service identifiers, service interfaces, and service implementations in the source code project and generating scan results includes: Based on the configuration information and preset filtering rules of the source code project, the target source code file is determined; the preset filtering rules are used to exclude source code files in the source code project that do not participate in the generation of the delegated proxy. The tag definition used to identify the service in the target source code file is determined as the service identifier; The interface declarations associated with the service identifier in the target source code file are identified as service interfaces; The business logic in the target source code file that matches the method call in the service interface is identified as the service implementation; The scan result is determined based on the service identifier, the service interface, and the service implementation.

3. The proxy generation method according to claim 1, characterized in that, The parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model; the process of parsing the scan results to generate the parsing model includes: Based on the correspondence between the service identifier and the service interface in the scan results, construct a service interface model; The invocation method is parsed to construct an invocation signature model; The data structures involved in the calling method are classified and parsed to construct a data structure model; Based on the service implementation information in the scan results, a service implementation model is constructed.

4. The proxy generation method according to claim 3, characterized in that, The process of classifying and parsing the data structures involved in the calling method and constructing a data structure model includes: Obtain each data structure and its data type in the called method; the data structure includes parameters, return values, object fields, collection elements, and mapping key-value pairs; For each data type, the type classification of the data type in the type system is determined based on the structural feature information of the data type; Based on the semantic information of the data type, determine the sub-category of the data type in the type classification; The data type is parsed to determine its internal structural composition information; Based on the data type, the type classification, the type subclass, and the internal structure composition information, generate type metadata corresponding to the data type; The data structure model is generated based on each of the data structures and the corresponding type metadata.

5. The proxy generation method according to claim 1, characterized in that, The parsing model includes a service interface model, a call signature model, a data structure model, and a service implementation model; the step of generating the caller-side delegation proxy code file and the server-side delegation proxy code file based on the parsing model includes: Based on the call signature model, a request parameter model and a response result model are generated for each of the call methods; the request parameter model is used to describe the first description information and the first runtime parameter storage information of each parameter in a single call request of the call method, and the response result model is used to describe the second description information and the second runtime parameter storage information of each returned result in a single call response of the call method. Based on the service interface model and the call signature model, a caller proxy method corresponding to the service interface is generated, and the request parameter model and the response result model are configured in the caller proxy method to form a caller delegation proxy code file; Based on the service interface model, the call signature model, and the service implementation model, a server-side proxy method is generated, and the request parameter model is configured in the server-side proxy method to form a code file for server-side delegation and proxy.

6. The proxy generation method according to claim 5, characterized in that, Also includes: When generating the code files for the calling end delegate and the server end delegate, a runtime binding model is constructed based on the structured data types in the data structure model. The runtime binding model is used to complete data creation, assignment, and / or writing operations when processing structured data types at runtime; The runtime binding model is written into the request parameter model and the response result model, respectively.

7. The proxy generation method according to claim 6, characterized in that, When the structured data type is an object type, the runtime binding model includes an object binding model, which describes the correspondence between the field metadata of the object type and the fields written at runtime. When the structured data type is a collection type, the runtime binding model includes a collection binding model, which describes the correspondence between the element metadata of the collection type and the runtime element creation and element addition methods; When the structured data type is a mapping type, the runtime binding model includes a mapping binding model, which describes the correspondence between the value type metadata of the mapping type and the runtime value creation method and key-value writing method.

8. A service invocation method, characterized in that, Applied to a calling device, the calling device is configured with a calling device delegate proxy code file generated by the delegate proxy generation method as described in any one of claims 1-7; The service invocation method includes: Obtain the call request for the target service interface; the call request includes call parameters; Based on the call request, determine the service category information and operation type information corresponding to the target service interface, and write the service category information and operation type information into the unified transmission object; Based on the request parameter model configured in the code file of the calling end delegate, the calling parameters are written into the request data field of the unified transport object; Encode the unified transport object into request data; Send the request data to the server device and receive the response data from the server device to the request data; The response data is decoded into the unified transport object, and the response data field of the unified transport object is obtained; Based on the response result model configured in the code file of the calling end delegate, the response data fields are converted into the return result of the target service interface.

9. A service invocation method, characterized in that, Applied to server-side equipment, wherein the server-side equipment is configured with server-side proxy code files generated by the proxy generation method as described in any one of claims 1 to 7; The service invocation method includes: Receive request data sent by the calling device; Decode the request data into a Uniform Transport Object; Based on the service category information of the unified transport object, locate the target service of the unified transport object in the code file of the server-side delegated proxy; Based on the operation type information of the unified transmission object, locate the target invocation method in the target service; Based on the request parameter model configured in the code file of the server-side delegate, the parameter data under the request data field of the unified transmission object is converted into parameter values; The target method is invoked using the parameter values ​​to obtain the invocation result. Based on the call result, determine the response data field of the unified transmission object; The unified transmission object is encoded into response data, and the response data is returned to the calling device.

10. The service invocation method according to claim 9, characterized in that, The step of converting parameter data under the request data field of the unified transport object into parameter values ​​according to the request parameter model configured in the code file of the server-side delegation proxy includes: Based on the first description information of the request parameter model configured in the code file of the server-side delegated proxy, determine the type classification of the parameter data under the request data field of the unified transmission object; In the case of the basic type classification, the specific basic type of the parameter data under the basic type classification is determined according to the first description information in the request parameter model, and the parameter data is converted into the corresponding parameter value according to the specific basic type. When the type is classified as a structured type, the specific structured data type corresponding to the parameter data is determined according to the runtime binding model in the request parameter model, and the parameter data is converted into the corresponding parameter value according to the specific structured data type.

Images