Service calling method and apparatus, storage medium, and electronic device

Abstract

The application discloses a service calling method and device, a storage medium and an electronic equipment. It relates to the field of financial technology. The method comprises the following steps: generating a service calling request through a software development kit deployed on the target application side; sending the service calling request to a target daemon process on the target application side through a standard input and output channel, so that the target daemon process sends the service calling request to a server; receiving response data returned by the server based on the service calling request through the target daemon process, and returning the response data to the target application. Through the application, the technical problem that the data security is relatively low because the calling interface needs to be exposed when the service is called in the related art is solved.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a service invocation method and apparatus, storage medium and electronic device. Background Technology

[0002] In the fintech sector, particularly in service calls within and between financial institutions, traditional communication mechanisms such as HTTP / HTTPS are widely used for data exchange and business processing. This approach relies on explicit network addresses and service endpoints to initiate requests and receive responses. However, with the accelerated digital transformation of the financial industry, financial institutions face increasingly severe data security challenges. On the one hand, to meet rapidly changing market demands, service interfaces need to be flexibly adjusted and expanded; on the other hand, it is crucial to ensure that sensitive data, such as customer information and transaction details, are protected from potential cyber threats during the call process. However, when using HTTP / HTTPS, service interfaces are often exposed to the network environment, increasing the risk of hacker attacks and resulting in higher data security risks.

[0003] There is currently no effective solution to the technical problem of low data security caused by exposing APIs when calling services in related technologies. Summary of the Invention

[0004] The main objective of this application is to provide a service invocation method and apparatus, storage medium and electronic device to solve the technical problem in related technologies where exposing the invocation interface is required when invoking a service, resulting in relatively low data security.

[0005] To achieve the above objectives, according to one aspect of this application, a service invocation method is provided. The method includes: generating a service invocation request using a software development kit deployed on a target application; sending the service invocation request to a target daemon process on the target application side via a standard input / output channel, so that the target daemon process sends the service invocation request to a server; and receiving response data returned by the server based on the service invocation request through the target daemon process, so as to return the response data to the target application.

[0006] Furthermore, generating a service call request by deploying a software development kit on the target application side includes: obtaining service call parameter information of the target application, wherein the service call parameters include at least: the logical service name and business parameter information of the target service to be called; calling the hardware security module to obtain the identity token of the target application; and obtaining the service call request based on the identity token, the logical service name, and the business parameter information.

[0007] Furthermore, obtaining the service call request based on the identity token, the logical service name, and the business parameter information includes: mapping the logical service name to the access route of the target service according to a preset declarative file; constructing a protocol message header based on the access route and the identity token; constructing a protocol message body based on the business parameter information; and obtaining the service call request based on the protocol message header and the protocol message body.

[0008] Furthermore, based on the access route and the identity token, constructing the protocol message header includes: calling the hardware security module to sign the access route, the digest of the service parameter information, and the current timestamp to obtain target signature information; and constructing the protocol message header based on the access route, the identity token, and the target signature information.

[0009] Furthermore, after sending the service call request to the server through the target daemon process, the method further includes: verifying the service call request to obtain a verification result; if the verification result indicates that the verification is successful, then forwarding the service call request to the target service corresponding to the service call request, wherein the target service processes the service call request to obtain the response data.

[0010] Further, forwarding the service call request to the target service corresponding to the service call request includes: matching the access route in the service call request based on a preset dynamic routing table to obtain the service endpoint corresponding to the target service; deserializing the protocol message body in the service call request to obtain business parameter information, and constructing a target request message conforming to a preset protocol specification based on the business parameter information; and forwarding the target request message to the service endpoint to perform business logic processing through the target service.

[0011] Furthermore, receiving the response data returned by the server based on the service call request through the target daemon process, and returning the response data to the target application includes: verifying the response data, and after passing the verification, sending the response data back to the software development kit through the standard input / output channel; processing the response data through the software development kit to obtain business data that conforms to the business standards, and returning the business data to the target application.

[0012] To achieve the above objectives, according to another aspect of this application, a service invocation apparatus is provided. The apparatus includes: a generation unit, configured to generate a service invocation request using a software development kit deployed on a target application side; a sending unit, configured to send the service invocation request to a target daemon process on the target application side via a standard input / output channel, so that the target daemon process sends the service invocation request to a server; and a return unit, configured to receive response data returned by the server based on the service invocation request through the target daemon process, so as to return the response data to the target application.

[0013] Furthermore, the generation unit includes: an acquisition subunit, used to acquire service call parameter information of the target application, wherein the service call parameters include at least: the logical service name and business parameter information of the target service to be called; a call subunit, used to call the hardware security module to acquire the identity token of the target application; and a determination subunit, used to obtain the service call request based on the identity token, the logical service name, and the business parameter information.

[0014] Further, the determining subunit includes: a mapping module, used to map the logical service name to the access route of the target service according to a preset declarative file; a first construction module, used to construct a protocol message header according to the access route and the identity token; a second construction module, used to construct a protocol message body according to the business parameter information; and a determining module, used to obtain the service call request based on the protocol message header and the protocol message body.

[0015] Furthermore, the first construction module includes: a calling submodule, used to call the hardware security module to sign the access route, the digest of the service parameter information, and the current timestamp to obtain target signature information; and a construction submodule, used to construct a protocol message header based on the access route, the identity token, and the target signature information.

[0016] Furthermore, the device further includes: a verification unit, configured to verify the service call request after it is sent to the server through the target daemon process, and obtain a verification result; and a forwarding unit, configured to forward the service call request to the target service corresponding to the service call request if the verification result indicates that the verification is successful, wherein the response data is obtained by processing the service call request through the target service.

[0017] Further, the forwarding unit includes: a matching subunit, used to match the access route in the service call request based on a preset dynamic routing table to obtain the service endpoint corresponding to the target service; a first processing subunit, used to deserialize the protocol message body in the service call request to obtain business parameter information, and construct a target request message conforming to a preset protocol specification based on the business parameter information; and a forwarding subunit, used to forward the target request message to the service endpoint to perform business logic processing through the target service.

[0018] Furthermore, the return unit includes: a verification subunit, used to verify the response data, and after the verification is passed, to send the response data back to the software development kit through the standard input / output channel; and a second processing subunit, used to process the response data through the software development kit to obtain business data that conforms to the business standards, and to return the business data to the target application.

[0019] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the service invocation method of any of the above-mentioned methods when it runs.

[0020] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a program, wherein the program controls the device where the storage medium is located to execute the service invocation method described above during runtime.

[0021] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, wherein the computer program or instructions, when executed by a processor, are the service invocation methods described in any of the above.

[0022] In this embodiment, the following steps are adopted: a service call request is generated by a software development kit deployed on the target application side; the service call request is sent to the target daemon process on the target application side through a standard input / output channel, so that the service call request is sent to the server through the target daemon process; the response data returned by the server based on the service call request is received by the target daemon process, so that the response data is returned to the target application. This solves the technical problem in related technologies that the call interface needs to be exposed when calling a service, resulting in relatively low data security.

[0023] In this solution, a software development kit (SDK) is deployed on the target application side. The SSD receives the application's business call requests and constructs a complete service call request. After the service call request is completed, the SSD does not send the request directly over the network; instead, it uses a standard input / output (SIO) channel to send the service call request to the local target daemon process. SIO communication bypasses the network layer, exchanging data only within the local process, reducing data exposure time over the network and increasing security. Upon receiving the service call request message from the SSD, the target daemon process sends the service call request to the server through a secure network channel. Upon receiving the request, the server processes the request based on its business logic, generates response data, and then returns the response data to the target application. By deploying the SSD and the local daemon process on the target application side and employing the Stdio communication mechanism, local processing and secure transmission of service call requests and response data are achieved. This avoids directly exposing the HTTP interface to the network environment as in traditional calling methods, reducing the risk of data interception or attacks, thereby improving the security and efficiency of service calls. Attached Figure Description

[0024] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0025] Figure 1 A hardware structure block diagram of a computer terminal for implementing a service invocation method is shown.

[0026] Figure 2 This is a flowchart of a service invocation method provided according to an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of a service invocation device provided according to an embodiment of this application;

[0028] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0032] Example 1

[0033] According to an embodiment of this application, a method embodiment for service invocation is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a service invocation method is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0035] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0036] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the service invocation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned service invocation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0037] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0038] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0039] Under the aforementioned operating environment, this application provides the following: Figure 2 The service invocation method is shown. Figure 2 This is a flowchart of the service invocation method according to Embodiment 1 of this application.

[0040] Step S201: Generate a service call request using a software development kit deployed on the target application side.

[0041] Optionally, on the target application side, i.e., the fintech sub-institution or other party that needs to invoke the service, a customized software development kit (SDK) is first deployed. The SDK can generate service invocation requests that conform to the target protocol based on the invocation requirements within the application. The target protocol can be the MCP (Model Context Protocol), which allows for the structured embedding of metadata, providing rich context information for service invocations, making it easier for the server to understand and process the requests.

[0042] Step S202: Send the service call request to the target daemon process on the target application side through the standard input / output channel, so that the service call request can be sent to the server through the target daemon process.

[0043] Optionally, the service call request is transmitted from the Software Development Kit (SDK) to the local target daemon process via the standard input / output (Stdio) channel. The target daemon process then sends the service call request to the server via a secure network connection. Stdio (standard input / output) is an inter-process communication (IPC) mechanism provided by the operating system, which enables data exchange between processes through the standard input stream (stdin) and the standard output stream (stdout).

[0044] In an optional embodiment, the SDK generates a service call request conforming to the MCP protocol based on the call requirements, including necessary business parameters and authentication information. Instead of sending the request directly to the network, the SDK sends it via the standard output stream (stdout) to the input stream (stdin) of the local daemon. While listening to stdin, the daemon receives the service call request sent by the SDK. The daemon then uses encryption protocols such as TLS to proxy and forward the request to the server over the network.

[0045] Step S203: Receive the response data returned by the server based on the service call request through the target daemon process, and return the response data to the target application.

[0046] Optionally, after the server processes the service call request and generates response data based on business logic, it encapsulates the response data into a message in MCP protocol format. The server sends the MCP response message back to the target daemon process on the target application side through a pre-defined network connection. The network connection should use a secure transport layer protocol, such as TLS, to ensure the privacy and integrity of the data during transmission. After receiving the response message from the server, the target daemon process parses the received MCP response message, checking whether it conforms to the expected response format and content. If the response data passes all security checks and verifications, the daemon process can further decode it into a format that the application can understand. Finally, the decoded response data is sent back to the target application through the Stdio communication channel in a predetermined application programming interface (API) format.

[0047] In summary, by deploying a Software Development Kit (SDK) on the target application side, the SSD receives the application's business call requests and constructs a complete service call request. After the service call request is completed, the SSD does not directly send the request over the network; instead, it uses the Standard Input / Output (Stdio) channel to send the service call request to the local target daemon process. Stdio communication bypasses the network layer, exchanging data only within the local process, reducing the time data is exposed to the network and increasing security. Upon receiving the service call request message from the SSD, the target daemon process sends the service call request to the server through a secure network channel. Upon receiving the request, the server processes the request based on its business logic, generates response data, and then returns the response data to the target application. By deploying the SSD and a local daemon process on the target application side and employing the Stdio communication mechanism, local processing and secure transmission of service call requests and response data are achieved. This avoids directly exposing the HTTP interface to the network environment as in traditional calling methods, reducing the risk of data interception or attacks, thereby improving the security and efficiency of service calls.

[0048] Optionally, in the service invocation method provided in this application embodiment, generating a service invocation request by deploying a software development kit on the target application side includes: obtaining service invocation parameter information of the target application, wherein the service invocation parameters include at least: the logical service name and business parameter information of the target service to be invoked; invoking the hardware security module to obtain the identity token of the target application; and obtaining the service invocation request based on the identity token, the logical service name and the business parameter information.

[0049] In an optional embodiment, within the target application's business logic, when a service needs to be invoked, the SDK first captures and organizes the service call parameter information, including at least the logical service name of the service to be invoked and the business parameters required to execute the service call. The logical service name can be a key identifier used by the server to identify and route requests, while the business parameters can be specific data from the service call or data that the target service needs to process, depending on the business requirements of the service to be invoked. The SDK ensures that all necessary data is accurately captured by calling interfaces provided by the application or by directly reading parameters from the business logic.

[0050] Then, the SDK invokes the Hardware Security Module (HSM) deployed on the same machine to obtain the identity token for the target application. An HSM is a physical device or software component used for secure operations such as encryption / decryption, key management, and digital signatures. In financial-grade service calls, HSM integration is a critical step in ensuring secure data transmission. Through the HSM, the SDK can obtain an encrypted identity token.

[0051] Finally, based on the obtained identity token, logical service name, and business parameter information, the SDK constructs a complete MCP message as a service call request. The MCP message format allows necessary routing and security information, such as Route-To and X-Auth-Cert, to be carried in the header, while business parameters are encapsulated in the message body.

[0052] Through the above steps, the SDK can not only accurately capture the necessary parameters for service calls, but also enhance security during the call process using HSM. Finally, it sends the request through the Stdio mechanism of the local daemon. The whole process ensures both the efficiency and accuracy of service calls and meets financial-grade security requirements.

[0053] Optionally, in the service invocation method provided in this application embodiment, obtaining the service invocation request based on the identity token, logical service name, and business parameter information includes: mapping the logical service name to the access route of the target service according to a preset declarative file; constructing a protocol message header based on the access route and the identity token; constructing a protocol message body based on the business parameter information; and obtaining the service invocation request based on the protocol message header and the protocol message body.

[0054] In an optional embodiment, the SDK first reads a pre-defined declarative configuration file, which can be stored in formats such as YAML or JSON, and contains mapping rules from logical service names to target service access routes. When the SDK captures a logical service name (e.g., "core / payment"), it looks up the corresponding entry in the declarative configuration file and maps that logical service name to the actual access route for the target service. This step enables dynamic routing of service calls, allowing applications to adapt to changes in the server without hard-coding service endpoints.

[0055] The SDK then constructs the protocol message header, obtaining the access route to the target service from the steps described above, and simultaneously retrieves the application's identity token from the Hardware Security Module (HSM). Using the access route and identity token, the SDK constructs the MCP protocol message header. For example, the access route is placed as the Route-To field, and the identity token is placed in the X-Auth-Cert field or other fields used for authentication, ensuring authentication of the message during transmission.

[0056] Secondly, the SDK constructs the protocol message body, capturing all business parameters required for service calls from the target application's business logic, and encoding the business parameter information into the MCP protocol message body format. This includes data serialization.

[0057] Finally, the constructed MCP message header and body are combined into a complete MCP message, resulting in the service call request described above. This service call request is sent through the Stdio channel of the local daemon. This mechanism avoids network exposure, improves security, and significantly reduces latency because data is transferred between local processes.

[0058] Through the above steps, the SDK ensures that the service call request construction process follows a unified and secure protocol, while improving the flexibility, security, and performance of service calls through dynamic routing, authentication, and efficient data encoding.

[0059] Optionally, in the service invocation method provided in this application embodiment, constructing the protocol message header based on the access route and identity token includes: calling the hardware security module to sign the digest of the access route and business parameter information and the current timestamp to obtain target signature information; and constructing the protocol message header based on the access route, identity token and target signature information.

[0060] In an optional embodiment, a secure hash algorithm, such as SHA-256, is used to hash the business parameter information to obtain a fixed-length hash value. This step is to prevent tampering of the business parameters during transmission. The hash value can be regenerated at the receiving end and compared with the hash at the sending end. Then, the precise time point of the current service call is recorded to verify the freshness of the request and prevent replay attacks.

[0061] The access route, business parameter information digest, and current timestamp are combined to form a dataset to be signed. The combined data set is then signed using a private key by invoking the local HSM device. HSM provides strict key management to ensure that the private key is not accessed without authorization, thereby enhancing the security of the signed information.

[0062] The signature information, access routes, and identity tokens generated in the above steps are integrated into the protocol message header. For example, according to the MCP protocol or a specific protocol specification, the message header is constructed, ensuring that all necessary fields are filled in, such as Route-To (a field in the MCP protocol header used to specify the destination of the message. In the context of a service call, it indicates which specific service endpoint or logical service name the request will be routed to), X-Auth-Cert (a field in the MCP protocol used to carry authentication information. It typically contains the caller's digital certificate or public key, used to verify the message's origin at the receiving end. In financial-grade service calls, this field is crucial for achieving two-way authentication, ensuring that only authorized entities can call the service), and Signature (another key field in the MCP protocol header, containing the result of signing the digest of the entire message (including the message header and message body). This signature is usually made by the sender using a private key, ensuring the integrity of the message and the authenticity of its origin during transmission), etc.

[0063] Through the above steps, a secure protocol message containing key routing information, authentication credentials, and business parameter summaries is constructed. Furthermore, timestamps and signature information are added, enhancing the security and integrity of service call requests and improving the security of financial-grade service calls.

[0064] Optionally, in the service invocation method provided in this application embodiment, after the service invocation request is sent to the server through the target daemon process, the method further includes: verifying the service invocation request and obtaining a verification result; if the verification result indicates that the verification is passed, then forwarding the service invocation request to the target service corresponding to the service invocation request, wherein the target service processes the service invocation request to obtain response data.

[0065] In an optional embodiment, upon receiving a service call request, the server (e.g., the MCP gateway at a fintech headquarters) first checks the Route-To field in the message header to ensure the request is a legitimate service call attempt and verifies that the relevant parameters conform to the agreed-upon format. Then, using the X-Auth-Cert field, it verifies with its public key whether the request sender has permission to access the target service. The purpose of this step is to achieve financial-grade two-way authentication, ensuring that the request initiator is an authenticated entity.

[0066] Then, the server generates a digest based on the business parameters in the message body and compares it with the information provided in the Signature field to verify that the message has not been tampered with during transmission. Furthermore, timestamp checks can also be used to prevent replay attacks. For example, the digest value of the business parameters in the message body can be recalculated using the same digest algorithm (such as SHA-256). The server verifies the signature in the Signature field using the sender's public key to confirm that it matches the recalculated digest value.

[0067] If all checks in the above verification phase pass, the service call request is correctly forwarded to the specific endpoint where the target service resides based on the verified Route-To field. Upon receiving the request, the target service processes it according to its business logic, performing corresponding operations such as payment processing and user verification, and generates response data. The target service encapsulates the processing result into a response message in the MCP protocol format, including status codes, error messages, and processing result data, and then returns it to the fintech sub-institutional application (i.e., the target application mentioned above) through the daemon's Stdio mechanism.

[0068] Through the above mechanism, the service call request verification and forwarding process not only ensures the legality and security of the request, but also guarantees the correct execution of the service call and the timely return of response data.

[0069] Optionally, in the service invocation method provided in this application embodiment, forwarding the service invocation request to the target service corresponding to the service invocation request includes: matching the access route in the service invocation request based on a preset dynamic routing table to obtain the service endpoint corresponding to the target service; deserializing the protocol message body in the service invocation request to obtain business parameter information, and constructing a target request message conforming to a preset protocol specification based on the business parameter information; and forwarding the target request message to the service endpoint to perform business logic processing through the target service.

[0070] In an optional embodiment, after receiving a service call request, the server first parses the Route-To field in the message header and searches for an entry in a preset dynamic routing table that matches this field. The dynamic routing table can be stored in memory for fast lookup, or it can be an updatable configuration file to adapt to dynamic changes in service endpoints. The matching entry in the dynamic routing table provides the actual network location of the target service, including IP address, port number, and other information, enabling the server to determine the specific service endpoint to which the message should be forwarded.

[0071] Then, the server parses the protocol message body, deserializing it from binary or JSON format into a data structure readable by the target service, and recovering the business parameter information. Based on the deserialized business parameter information, the server constructs a request message that conforms to the target service's preset protocol specifications. For example, if the target service is based on traditional HTTP / HTTPS, the server encapsulates the business parameters into an HTTP request body and adds necessary HTTP header information, such as Content-Type.

[0072] Finally, the server uses an encrypted communication channel (such as TLS / SSL) to forward the target request message to the server endpoint. After receiving the request, the target service executes the corresponding business logic processing, generates response data, encapsulates the response information according to the corresponding protocol specifications, and returns it to the server.

[0073] Through the above process, the server can accurately route service call requests to the correct target service, and also ensure the secure transmission of request and response data, as well as the correct processing and application of business parameters.

[0074] Optionally, in the service invocation method provided in this application embodiment, receiving response data returned by the server based on the service invocation request through the target daemon process, and returning the response data to the target application includes: verifying the response data, and after the verification is passed, sending the response data back to the software development kit through the standard input / output channel; processing the response data through the software development kit to obtain business data that conforms to the business standards, and returning the business data to the target application.

[0075] In an optional embodiment, the target daemon receives response data from the server via its standard input / output channels (Stdin / Stdout). Since the entire communication is based on the MCP protocol, the response data is also presented in MCP format, including a response header and a response body. After receiving the response data, the daemon performs a preliminary integrity check on the MCP message, verifying whether it conforms to the MCP protocol format requirements and whether it contains necessary fields such as Status and Message.

[0076] Next, the response data is validated. For example, the X-Auth-Cert field in the response header is verified to confirm that the response data indeed comes from the target server and that the server's identity has been verified in previous calls. If the response header contains a Signature field, the daemon verifies the signature using the target service's public key to ensure the response data has not been tampered with. The Status field in the response header is parsed, and the status code returned by the server is checked to determine whether the request was successfully processed; for example, 200 indicates success, and 400 indicates a client error. The business data in the response body is checked to ensure the correctness of the data format and business logic.

[0077] Finally, the response data is sent back to the target application via a Software Development Kit (SDK). For example, the SDK deserializes the MCP format response data, converting it into a data format that the application can understand. The deserialized data can then be further processed with business logic, such as data transformation and exception handling, ensuring that the application can correctly understand and use the data. After the response data is verified and processed, the SDK returns it to the target application, completing the response phase of the service call.

[0078] Through the above steps, the daemon and SDK work together to ensure the secure receipt and correct processing of response data, and finally return the business data that meets the business standards to the target application, thus completing a complete service call process.

[0079] In an optional embodiment, a fintech sub-institution application (such as the transaction processing system of a fintech branch) needs to call a service (such as a payment processing service) by calling an interface of the MCP Local SDK, such as `mcpClient.invoke("core / payment", {amount: 100})`. The MCP Local SDK on the fintech sub-institution side (i.e., the aforementioned software development kit) parses the access route to the target service (i.e., the payment processing service) based on the declarative configuration file and automatically calls the HSM to add necessary authentication information, such as the digital certificate in X-Auth-Cert, and signs the business parameter digest using a private key to form a Signature field. The SDK converts the request into a message in MCP protocol format, including a request header and a message body composed of business parameter information. Then, the message is sent to a specific daemon through the Stdio mechanism of the local daemon, which is responsible for communication with external services.

[0080] The MCP gateway at the fintech headquarters receives an MCP message from the local daemon. It first parses the message header, extracting fields such as Route-To, X-Auth-Cert, and Signature. The gateway uses a public key to verify the Signature, confirming the sender's identity and the timeliness and freshness of their request. Simultaneously, it checks the X-Auth-Cert to ensure the caller has the necessary permissions to access the specific service. Based on the Route-To field, the gateway looks up the corresponding service endpoint in the dynamic routing table. If the target service originally uses HTTP / HTTPS communication, the gateway converts the MCP message into an HTTP request, including deserializing business parameter information and encapsulating it into an HTTP Request Body. The gateway sends the constructed HTTP request to the target service endpoint, and the service executes its business logic processing and returns response data. The response data may include the processing result, status code, and additional information, such as error details.

[0081] The MCP gateway receives the response data from the target service. If it is an HTTP response, it reserializes it into an MCP format response message. The verified and decoded response data is encapsulated in an MCP response message and returned to the application of the fintech sub-institution via the Stdio mechanism, completing a full service call cycle.

[0082] The service invocation method provided in this application generates a service invocation request by deploying a software development kit on the target application side; sends the service invocation request to the target daemon process on the target application side through a standard input / output channel, so that the target daemon process sends the service invocation request to the server; and receives the response data returned by the server based on the service invocation request through the target daemon process, so as to return the response data to the target application. This solves the technical problem in related technologies that the need to expose the calling interface when invoking a service leads to relatively low data security.

[0083] In this solution, a software development kit (SDK) is deployed on the target application side. The SSD receives the application's business call requests and constructs a complete service call request. After the service call request is completed, the SSD does not send the request directly over the network; instead, it uses the Standard Input / Output (Stdio) channel to send the service call request to the local target daemon process. Stdio communication bypasses the network layer, exchanging data only within the local process, reducing the time data is exposed over the network and increasing security. Upon receiving the service call request message from the SSD, the target daemon process sends the service call request to the server through a secure network channel. After receiving the request, the server processes the request based on its business logic, generates response data, and then returns the response data to the target application. By deploying the SSD and the local daemon process on the target application side and employing the Stdio communication mechanism, local processing and secure transmission of service call requests and response data are achieved. This avoids directly exposing the HTTP interface to the network environment as in traditional calling methods, reducing the risk of data interception or attacks, thereby improving the security and efficiency of service calls.

[0084] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0085] Example 2

[0086] This application also provides a service invocation apparatus. It should be noted that the service invocation apparatus of this application can be used to execute the service invocation method provided in this application. The service invocation apparatus provided in this application will be described below.

[0087] According to embodiments of this application, an apparatus for implementing the above-described service invocation method is also provided, such as... Figure 3 As shown, the device includes: a generation unit 301, a sending unit 302, and a return unit 303.

[0088] The generation unit 301 is used to generate service call requests using a software development kit deployed on the target application side;

[0089] The sending unit 302 is used to send the service call request to the target daemon process on the target application side through the standard input / output channel, so that the service call request can be sent to the server through the target daemon process;

[0090] Return unit 303 is used to receive response data returned by the server based on the service call request through the target daemon process, so as to return the response data to the target application.

[0091] The service invocation apparatus provided in this application embodiment generates a service invocation request through a software development kit deployed on the target application side by a generation unit 301; a sending unit 302 sends the service invocation request to the target daemon process on the target application side through a standard input / output channel, so that the service invocation request is sent to the server through the target daemon process; and a return unit 303 receives the response data returned by the server based on the service invocation request through the target daemon process, so as to return the response data to the target application. This solves the technical problem in related technologies that the call interface needs to be exposed when calling a service, resulting in relatively low data security.

[0092] In this solution, a software development kit (SDK) is deployed on the target application side. The SSD receives the application's business call requests and constructs a complete service call request. After the service call request is completed, the SSD does not send the request directly over the network; instead, it uses the Standard Input / Output (Stdio) channel to send the service call request to the local target daemon process. Stdio communication bypasses the network layer, exchanging data only within the local process, reducing the time data is exposed over the network and increasing security. Upon receiving the service call request message from the SSD, the target daemon process sends the service call request to the server through a secure network channel. After receiving the request, the server processes the request based on its business logic, generates response data, and then returns the response data to the target application. By deploying the SSD and the local daemon process on the target application side and employing the Stdio communication mechanism, local processing and secure transmission of service call requests and response data are achieved. This avoids directly exposing the HTTP interface to the network environment as in traditional calling methods, reducing the risk of data interception or attacks, thereby improving the security and efficiency of service calls.

[0093] Optionally, in the service invocation apparatus provided in this application embodiment, the generation unit includes: an acquisition subunit, used to acquire service invocation parameter information of the target application, wherein the service invocation parameters include at least: the logical service name and business parameter information of the target service to be invoked; an invocation subunit, used to invoke the hardware security module to acquire the identity token of the target application; and a determination subunit, used to obtain the service invocation request based on the identity token, the logical service name and the business parameter information.

[0094] Optionally, in the service invocation apparatus provided in this application embodiment, the determining subunit includes: a mapping module, used to map a logical service name to an access route of the target service according to a preset declarative file; a first construction module, used to construct a protocol message header according to the access route and the identity token; a second construction module, used to construct a protocol message body according to business parameter information; and a determining module, used to obtain a service invocation request based on the protocol message header and the protocol message body.

[0095] Optionally, in the service invocation apparatus provided in this application embodiment, the first construction module includes: an invocation submodule, used to invoke the hardware security module to sign the digest of access route and service parameter information and the current timestamp to obtain target signature information; and a construction submodule, used to construct the protocol message header based on the access route, identity token and target signature information.

[0096] Optionally, in the service invocation apparatus provided in this application embodiment, the apparatus further includes: a verification unit, used to verify the service invocation request after the service invocation request is sent to the server through the target daemon process, and obtain a verification result; and a forwarding unit, used to forward the service invocation request to the target service corresponding to the service invocation request if the verification result indicates that the verification is passed, wherein the target service processes the service invocation request to obtain response data.

[0097] Optionally, in the service invocation apparatus provided in this application embodiment, the forwarding unit includes: a matching subunit, used to match the access route in the service invocation request based on a preset dynamic routing table to obtain the service endpoint corresponding to the target service; a first processing subunit, used to deserialize the protocol message body in the service invocation request to obtain business parameter information, and construct a target request message conforming to a preset protocol specification based on the business parameter information; and a forwarding subunit, used to forward the target request message to the service endpoint to perform business logic processing through the target service.

[0098] Optionally, in the service invocation device provided in this application embodiment, the return unit includes: a verification subunit, used to verify the response data, and after the verification is passed, to send the response data back to the software development kit through a standard input / output channel; and a second processing subunit, used to process the response data through the software development kit to obtain business data that conforms to the business standards, and to return the business data to the target application.

[0099] It should be noted that the generation unit 301, sending unit 302, and returning unit 303 mentioned above correspond to steps S201 to S203 in Embodiment 1. The three units and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0100] Example 3

[0101] Embodiments of this application may provide an electronic device. Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (Only one is shown) Processor 402, memory 404, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0102] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0103] The processor can access information and applications stored in memory via a transmission device to perform the following steps: generate a service call request using a software development kit deployed on the target application side; send the service call request to the target daemon process on the target application side via a standard input / output channel, so that the target daemon process can send the service call request to the server; and receive response data returned by the server based on the service call request through the target daemon process, so that the response data can be returned to the target application.

[0104] The processor can access information and applications stored in memory via a transmission device to perform the following steps: generating a service call request using a software development kit deployed on the target application side, including: obtaining service call parameter information of the target application, wherein the service call parameters include at least: the logical service name and business parameter information of the target service to be called; invoking the hardware security module to obtain the identity token of the target application; and obtaining the service call request based on the identity token, the logical service name, and the business parameter information.

[0105] The processor can invoke information and applications stored in memory through the transmission device to perform the following steps: obtaining a service invocation request based on an identity token, logical service name, and business parameter information, including: mapping the logical service name to the access route of the target service according to a preset declarative file; constructing a protocol message header based on the access route and identity token; constructing a protocol message body based on the business parameter information; and obtaining the service invocation request based on the protocol message header and protocol message body.

[0106] The processor can invoke information and applications stored in memory through the transmission device to perform the following steps: constructing a protocol message header based on the access route and identity token, including: invoking the hardware security module to sign the digest of the access route and business parameter information and the current timestamp to obtain the target signature information; constructing the protocol message header based on the access route, identity token and target signature information.

[0107] The processor can invoke information and applications stored in memory through the transmission device to perform the following steps: After sending the service call request to the server through the target daemon, the method further includes: verifying the service call request and obtaining a verification result; if the verification result indicates that the verification is successful, forwarding the service call request to the target service corresponding to the service call request, wherein the target service processes the service call request to obtain response data.

[0108] The processor can invoke information and applications stored in the memory through the transmission device to perform the following steps: forwarding a service call request to the target service corresponding to the service call request, including: matching the access route in the service call request based on a preset dynamic routing table to obtain the service endpoint corresponding to the target service; deserializing the protocol message body in the service call request to obtain business parameter information, and constructing a target request message that conforms to the preset protocol specification based on the business parameter information; and forwarding the target request message to the service endpoint to perform business logic processing through the target service.

[0109] The processor can access information and applications stored in memory via a transmission device to perform the following steps: receiving response data from the server based on a service call request through the target daemon process, and returning the response data to the target application, including: verifying the response data, and after successful verification, sending the response data back to the software development kit (SDK) through a standard input / output channel; processing the response data through the SSD to obtain business data that conforms to business standards, and returning the business data to the target application.

[0110] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 4 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0111] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0112] Example 4

[0113] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the service invocation method provided in Embodiment 1.

[0114] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0115] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform service invocation method steps.

[0116] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0117] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0118] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of 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 displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

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

[0120] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0121] 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, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0122] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A service invocation method, characterized by, include: Service call requests are generated by deploying a software development kit on the target application side; The service call request is sent to the target daemon process on the target application side through the standard input / output channel, and then the service call request is sent to the server through the target daemon process. The target daemon process receives the response data returned by the server based on the service call request, and then returns the response data to the target application.

2. The method according to claim 1, characterized in that, Generating service call requests using a software development kit deployed on the target application side includes: Obtain the service call parameter information of the target application, wherein the service call parameters include at least: the logical service name and business parameter information of the target service to be called; The hardware security module is invoked to obtain the identity token of the target application. The service call request is obtained based on the identity token, the logical service name, and the business parameter information.

3. The method according to claim 2, characterized in that, Based on the identity token, the logical service name, and the business parameter information, the service call request is obtained as follows: Based on a pre-defined declarative file, the logical service name is mapped to the access route of the target service; Based on the access route and the identity token, construct the protocol message header; Based on the aforementioned business parameter information, construct the protocol message body; The service call request is obtained based on the protocol message header and the protocol message body.

4. The method according to claim 3, characterized in that, Based on the access route and the identity token, the protocol message header is constructed as follows: The hardware security module is invoked to sign the access route, the digest of the service parameter information, and the current timestamp to obtain the target signature information; Based on the access route, the identity token, and the target signature information, construct the protocol message header.

5. The method according to claim 1, characterized in that, After sending the service call request to the server through the target daemon, the method further includes: The service call request is validated to obtain the validation result; If the verification result indicates that the verification is successful, the service call request is forwarded to the target service corresponding to the service call request, wherein the target service processes the service call request to obtain the response data.

6. The method according to claim 5, characterized in that, Forwarding the service call request to the target service corresponding to the service call request includes: The access routes in the service call request are matched based on a preset dynamic routing table to obtain the service endpoint corresponding to the target service. The protocol message body in the service call request is deserialized to obtain business parameter information, and a target request message conforming to the preset protocol specification is constructed based on the business parameter information. The target request message is forwarded to the service endpoint so that business logic processing can be performed through the target service.

7. The method according to claim 1, characterized in that, Receiving response data from the server based on the service call request through the target daemon process, and then returning the response data to the target application includes: The response data is verified, and after the verification is successful, the response data is sent back to the software development kit through the standard input / output channel; The response data is processed using the software development kit to obtain business data that conforms to business standards, and the business data is then returned to the target application.

8. A service invocation device, characterized in that, include: The generation unit is used to generate service call requests using a software development kit deployed on the target application side; The sending unit is used to send the service call request to the target daemon process on the target application side through a standard input / output channel, so that the service call request can be sent to the server through the target daemon process; The return unit is used to receive the response data returned by the server based on the service call request through the target daemon process, so as to return the response data to the target application.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium resides to perform the service invocation method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program executes the service invocation method according to any one of claims 1 to 7 when it runs.

Images