Communication system, method and device based on FIDL interface document conversion
By using FIDL interface document conversion to generate target interface code when communicating between different systems, and combining Json and WebSocket technology, the problems of frequent interface code modification and low communication efficiency in the existing technology are solved, and more efficient interface maintenance and communication processes are achieved.
Patent Information
- Application Number
- CN202411900552.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-20
- Publication Date
- 2025-03-18
AI Technical Summary
When communicating between different systems, the prior art requires the development or modification of relevant interface codes for different systems, resulting in large workload, inconvenient maintenance and low communication efficiency.
A communication system based on FIDL interface document conversion is adopted, interface documents are defined through the FIDL interface format, interface definitions are separated from functional codes, and target interface codes are generated using the interface document conversion tool. At the same time, the communication adaptation module is used to convert the communication data into Json strings and transmitted through the WebSocket communication protocol.
It reduces the workload of code modification, improves the maintainability and scalability of interface code, and improves communication efficiency and meets the needs of different communication scenarios through the combination of Json and WebSocket.
Smart Images

Figure CN119645686A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to a communication system, method and device based on FIDL interface document conversion. Background Art
[0002] In the related art, when different systems communicate with each other, the method usually adopted is to develop or modify the relevant interface codes for different systems. Specifically, suppose that when system A needs to obtain data from system B, according to the application programming interface (API) provided by system B, code is written to call the interface of system B. After the call is completed, the response data of system B is converted into the form that system A needs to receive, and then the corresponding data processing work is performed. At this time, if system B modifies the relevant interface, system A and other systems connected to system B also need to modify the relevant code, resulting in excessive workload, inconvenient maintenance, and low communication efficiency.
[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention
[0004] The present invention provides a communication system, method and device based on FIDL interface document conversion, which can define interface documents in FIDL interface format, separate interface definition documents from specific function codes, and convert interface definition documents into target interface codes through interface document conversion tools, which is conducive to development and maintenance and can reduce the workload of code modification. On this basis, based on the proposed communication adaptation mechanism, communication data transmission between multiple subsystems is realized by combining Json data transmission format with WebSocket communication protocol, which can improve communication efficiency.
[0005] In a first aspect, a communication system based on FIDL interface document conversion is provided, comprising: a plurality of subsystems; Each of the multiple subsystems deploys an interface document conversion module respectively, and the interface document conversion module is configured to convert a predefined FIDL interface document into an interface code under a target language type, wherein the FIDL interface document is separated from the function code, and the target language type is a language type adapted to the subsystem; A communication adapter module is deployed inside each subsystem. The communication adapter module is configured to convert the communication data into Json string data when communicating between any two subsystems, and transmit the Json string data according to the WebSocket communication protocol based on the interface code.
[0006] In a second aspect, a communication method based on FIDL interface document conversion is provided, the method is applied to the communication system based on FIDL interface document conversion in the first aspect, the method comprising: In response to an external command, parsing and determining whether a target processor and a target generator in a target language type are deployed inside the interface document conversion module, wherein the external command is used to instruct the generation of interface code in the target language type; In the case where the target processor and the target generator are deployed inside the parsing and judging interface document conversion module, the target processor is used to generate the interface code in the target language type based on the FIDL interface document and the code template configured on the target generator; When any two subsystems communicate, the communication adapter module is used to convert the communication data into Json string data, and based on the interface code, the Json string data is transmitted according to the WebSocket communication protocol.
[0007] In a third aspect, a communication device based on FIDL interface document conversion is provided, the device is applied to the communication system based on FIDL interface document conversion in the first aspect, and the device includes: A parsing module, used for parsing and determining whether a target processor and a target generator of a target language type are deployed inside the interface document conversion module in response to an external command, wherein the external command is used to instruct the generation of an interface code of a target language type; A generation module is used to generate interface code in a target language type by using the target processor based on the FIDL interface document and the code template configured on the target generator when the target processor and the target generator are deployed inside the parsing judgment interface document conversion module; The transmission module is used to convert the communication data into Json string data by using the communication adapter module when communicating between any two subsystems, and transmit the Json string data according to the WebSocket communication protocol based on the interface code.
[0008] In a fourth aspect, an electronic device is provided, comprising: a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory, and executing the method in the second aspect or its various implementations.
[0009] According to a fifth aspect, a computer-readable storage medium is provided for storing a computer program, wherein the computer program enables a computer to execute the method according to the second aspect or its various implementations.
[0010] Through the technical solution provided by the present invention, a communication system based on FIDL interface document conversion is provided, and the system includes multiple subsystems; each of the multiple subsystems deploys an interface document conversion module respectively, and when the subsystem needs to generate an interface code, the interface document conversion module can convert the predefined FIDL interface document into an interface code under the target language type, wherein the FIDL interface document is separated from the function code, and the target language type is a language type adapted to the subsystem. By defining the interface through a unified FIDL file format, separating the interface definition document from the specific code, and using an interface file conversion tool to convert the FIDL interface document into the target interface code, it is convenient for development and use, and improves the maintainability and scalability of the interface part code. In addition, a communication adapter module is deployed inside each subsystem, and the communication adapter module is configured to convert the communication data into Json string data when communicating between any two subsystems, and transmit the Json string data according to the WebSocket communication protocol based on the interface code. This method of using a combination of Json format strings and WebSocket sockets to complete the specific communication process can meet the needs of different communication scenarios to a large extent, realize real-time and persistent data exchange, and fully reduce communication transmission occupancy, shorten the transmission string parsing and generation time, thereby improving communication efficiency.
[0011] It should be understood that the above general description and the following detailed description are only exemplary and explanatory and cannot limit the present invention. Other features and advantages of the present invention will be described in detail in the following specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0013] Figure 1 A system architecture diagram of a communication system based on FIDL interface document conversion provided in an embodiment of the present application; Figure 2 A schematic diagram of the principle flow of performing interface conversion by an interface document conversion module provided in an embodiment of the present application; Figure 3 A schematic diagram of the communication principle flow of a communication adapter module provided in an embodiment of the present application; Figure 4 A flow chart of a communication method based on FIDL interface document conversion provided in an embodiment of the present application; Figure 5A schematic diagram of the structure of a communication device based on FIDL interface document conversion provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0014] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.
[0015] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0016] In the related art, when different systems communicate with each other, the method usually adopted is to develop or modify the relevant interface codes for different systems. Specifically, suppose that when system A needs to obtain data from system B, according to the application programming interface (API) provided by system B, code is written to call the interface of system B. After the call is completed, the response data of system B is converted into the form that system A needs to receive, and then the corresponding data processing work is performed. At this time, if system B modifies the relevant interface, system A and other systems connected to system B also need to modify the relevant code, resulting in excessive workload, inconvenient maintenance, and low communication efficiency.
[0017] In order to solve the above technical problems, the invention of the present invention is to use Franca Interface Definition Language (FIDL) document to define the interface in the current interface development process, which makes the interface code unfavorable for maintenance. The interface definition and function code are separated and converted into the corresponding target language code using the interface conversion tool. At the same time, due to the problem that some interface conversion tools can only be converted into specific language codes, the interface document conversion module proposed in this patent can be converted into codes in multiple languages such as C++ and TypeScript, further broadening its applicability. Since different projects and architectures have different communication requirements, in response to this problem, a communication adaptation mechanism is proposed in this patent to flexibly set the communication mode in different scenarios; based on the communication adaptation mechanism, the WebSocket communication protocol and the Json data format can be combined, and the two communicating parties use WebSocket as the basis to transmit Json strings to realize communication interaction, so as to meet different communication scenarios and further improve communication efficiency. On the basis of the above, developers only need to be responsible for the interface file when developing communication between modules, and the interface file can flexibly generate the target language code, which is convenient and fast. At the same time, the deployment of different modules becomes flexible and convenient, and they can communicate freely within a process, between processes, or between different machines.
[0018] like Figure 1 As shown, a communication system based on FIDL interface document conversion includes: multiple subsystems 110, an interface document conversion module 120 and a communication adaptation module 130; each of the multiple subsystems 110 respectively deploys an interface document conversion module 120, and the interface document conversion module 120 is configured to convert a predefined FIDL interface document into an interface code under a target language type, wherein the FIDL interface document is separated from the function code, and the target language type is a language type adapted to the subsystem; a communication adaptation module 130 is arranged between the multiple subsystems 110, and the communication adaptation module 130 is configured to convert the communication data into Json string data when communicating between any two subsystems 110, and transmit the Json string data according to the WebSocket communication protocol based on the interface code.
[0019] Among them, the subsystem can be a process, physical server, virtual machine, client, etc. configured in the communication system; FIDL interface documents usually refer to .fidl files written in FIDL language, which define remote interfaces, including interface function names, transmitted parameters and return values, etc. These definitions will be used to generate binding codes of different programming languages, i.e., interface codes, thereby simplifying development work. The interface document conversion module 120 can be a functional module deployed with an interface document converter ApiFiddler. The interface document converter ApiFiddler is developed by Java and xtend languages, and provides Jar packages for external use. It has good cross-platform performance and can be used in system environments such as Windows and Ubuntu. The interface document conversion module 120 can convert the FIDL interface document into the interface code of the target language, such as C++ / TypeScript, based on the interface document converter ApiFiddler. Types such as interface, method and broadcast can generally be defined in the FIDL interface document. In specific development, the package and interface fields can be combined into a component to express which functional module the interface is. Method is an interface method, in is used to indicate input parameters, out is used to indicate return results, error is used to indicate error information, and broadcast is a broadcast method, out is used to indicate broadcast information. In addition, as shown in Table 1, other data types such as struct can also be defined.
[0020] Table 1. Commonly used type definitions in FIDL interface documents
[0021] In addition, you can also define all data types in the FIDL interface document. In this case, the interface field is not used, but the typeCollection field is used. In this state, the FIDL interface document is only used to define types and does not provide interfaces.
[0022] In a specific application scenario, multiple subsystems 110 can respectively deploy an independent interface document conversion module 120. The FIDL interface document is converted into an interface code in the target language through the deployed interface document conversion module 120. Among them, different subsystems can be configured with the same or different FIDL interface documents, and the language types of the interface codes generated corresponding to different subsystems 110 can also be the same or different, which can be set according to the actual application scenario. When developers are developing communications between subsystems, they can adjust the FIDL interface document to achieve quick generation of interface codes and simplify the generation operation of interface codes. The entire process does not require modification of related codes, thereby reducing the workload of code modification and facilitating code development and maintenance.
[0023] When converting a FIDL interface document into the interface code of the target language, the interface converter ApiFiddler will convert each FIDL interface document into an interface code file with the same name as the FIDL interface document. Taking the conversion of a FIDL interface document into a C++ interface as an example, the interface in the FIDL interface document will be converted into an interface class in the .hpp file, and the interface method method in the interface will be converted into a pure virtual function in the corresponding interface class. The benefit of setting up the conversion in this way is that other functional modules can implement the interface by implementing pure virtual functions. Similarly, the conversion of the broadcast method is basically the same as the method, and the corresponding registration and deregistration pure virtual functions can be generated.
[0024] The other data types in Table 1 can also be converted. For example, the C++ conversion of the structure type struct can successfully convert the properties and methods defined in the structure in the FIDL interface document, and can also generate a default or parameterized constructor for the structure according to the language characteristics of C++. The same is true for other types. The rule is to convert a type of data type in a unified format. If the conversion cannot be performed, an error will be reported to indicate that the FIDL format definition is incorrect.
[0025] From a logical point of view, APIFiddler can be converted into a common type of interface or into an interface based on a specific communication method. From a technical implementation point of view, the conversion process is actually completed by the generator and processor inside the tool. Figure 2As shown, the interface document conversion module 120 includes a basic framework (main), and corresponding processors and generators are deployed in the basic framework for different language types. The generator is responsible for the generation of the file, which provides the corresponding template for the target file content, and the processor is responsible for the scheduling of the entire process, which is the executor of the relevant function. The two are important components of APIFiddler, and their synergy is the basis for APIFiddler to perform interface conversion. In addition to the internal generator and processor, APIFiddler provides a basic framework externally, which is both the entrance for receiving external commands and the basis for APIFiddler to convert multiple types of language interfaces. When a new target language is needed, only the generator and processor corresponding to the target language need to be added, and it is "inserted" into the external framework to truly achieve complete decoupling between different types, thereby achieving the purpose of multi-language conversion. After using the APIFiddler interface conversion tool to correctly convert the interface type, no other additional work is required. After the conversion is realized, developers can directly introduce and use the code generated by the FIDL interface document, including interface methods and type definitions.
[0026] In a specific application scenario, multiple processors and generators are deployed in the basic framework, and each processor and generator has a one-to-one relationship with the language type. The basic framework can be used to receive external commands (FIDL) that instruct to generate interface code under the target language type, and then internally identify whether the target processor and target generator corresponding to the target language type are deployed by parsing the command line. In the case of parsing and judging that there are target processors and target generators, the basic framework will call the relevant functions in the corresponding target processor to convert the interface code. These functions are responsible for scheduling the entire process. They will read the FIDL interface file and generate the interface code based on the corresponding code template provided by the target generator; in the case of parsing and judging that there are related errors, such as incorrect external command input, failure to find or read the specified FIDL file, and undefined related processors, the basic framework will feedback related errors to indicate that the interface code under the target language type cannot be generated. In this way, the orderly conversion of interface code can be guaranteed, the efficiency of code conversion can be improved, and the generation error of interface code can be reduced.
[0027] Accordingly, the basic framework is configured to respond to an external command (FIDL) to determine whether a target processor and a target generator of the target language type are deployed inside the interface document conversion module, wherein the external command is used to instruct the generation of interface code of the target language type; the basic framework is configured to, in the case of determining that the target processor and the target generator are not deployed inside the interface document conversion module, feedback a relevant error to indicate that the interface code of the target language type cannot be generated. In the case of determining that a target processor and a target generator are deployed inside the interface document conversion module, the target processor is configured to generate interface code of the target language type based on the FIDL interface document and the code template configured on the target generator.
[0028] Among them, the code template sets the specific code structure in the generated target language interface code file based on the relevant elements (such as structures, tables, and services) defined in the FIDL interface document. These templates can be simple text files or more complex scripts or programs, which can generate corresponding code based on the relevant element definitions provided by FIDL. The target language type is the target programming language type for which code needs to be generated, such as C++, Java, Python, etc. The target processor is responsible for scheduling the interface code file generation process, can understand the syntax and rules of FIDL and identify all necessary information, can provide relevant function calls to read and parse the FIDL interface document, and generate the target language interface code file based on the definitions of relevant types, field names, field types, service methods, etc. in the FIDL document.
[0029] Ideally, the communication between subsystems can be fixed in a certain communication mode, which is conducive to improvement and maintenance. However, in the actual production environment, different projects may require different communication modes; at the same time, when in different architectural modes, different communication modes suitable for this architectural mode will be adopted.
[0030] In other words, in actual situations, subsystems may not always use a certain communication method, but rather flexibly select a suitable communication method based on different needs. In view of this realistic scenario, and considering reducing coupling as much as possible, a communication adaptation method can be proposed in this application to meet the needs of flexible configuration of different communication methods.
[0031] Specifically, a variety of communication modes may be deployed in the communication adapter module 130; the communication adapter module is configured to determine the communication requirements and architectural modes between any two subsystems, and select a target communication mode that matches the communication requirements and architectural modes from a variety of communication modes, and create a communication connection between any two subsystems according to the target communication mode. Among them, the communication requirements between the two subsystems may involve multiple aspects, such as message formats, network protocols, communication models, etc.; the architectural mode between the two subsystems mainly refers to how the two subsystems connect, interact and collaborate to achieve data exchange and functional integration. The architectural modes may include monolithic architecture, cluster architecture, distributed architecture, service-oriented architecture, microservice architecture, and content distribution architecture, etc., which can be weighed and selected according to the specific needs and characteristics of the system.
[0032] The essence of communication adaptation is to isolate communication changes. In this application, all the multiple communication methods that need to be used can be introduced into the communication adaptation module framework. When a new scenario appears and a new communication method needs to be adopted, the overall framework of the communication adaptation module will not change. You only need to implement a specific communication method and introduce it into the communication adaptation module.
[0033] After adopting the communication adaptation mechanism, from the perspective of communication between subsystems, the communicating parties have not changed, but the communication method is no longer fixed. It will be selected and configured based on different communication requirements and different architectural methods. In this way, when the communication requirements and architectural methods change, a more suitable communication method can be selected accordingly, thereby improving the overall communication flexibility.
[0034] There are many different communication scenarios in reality, such as cross-platform, cross-language, and cross-machine communication. From a process perspective, there is intra-process communication and inter-process communication. At the same time, the selection of the data transmission format in communication is also very important, as it will greatly affect the quality and efficiency of communication.
[0035] In order to meet the communication needs of the above-mentioned scenarios, WebSocket can be used as the communication basis in this application. In addition to being well adapted to different scenarios, WebSocket also provides a persistent full-duplex communication connection channel for both parties to communicate, satisfying the real-time and continuous data communication exchange; at the same time, in order to solve the problems of high communication transmission occupancy and difficulty in machine parsing and generation in some current data transmission formats, the Json string data structure can be used in this application. The Json format has many characteristics that facilitate communication. Its key-value pair structure is relatively lightweight, occupies less space, is easy for both parties to communicate to generate and parse, and is highly readable, making it easier for developers to perform related debugging.
[0036] like Figure 3As shown, the communication adapter module 130 may be a functional module deployed with a communication adapter, and the communication adapter may include a WebSocket Server module and a WebSocket Client module. When the communication adapter module 130 is started, the WebSocket Server module and the WebSocket Client module are started respectively. At this time, communication can be established with the help of WebSocket to complete the connection between the WebSocket Server module and the WebSocket Client module between different subsystems. The communication address is based on the Socket socket mode, that is, it is composed of an IP address and a port number (ws: / / IP:Port). After the connection is successfully established, the subsystems can communicate with each other, such as interface calls or broadcast signal transmission. The content of the transmission is a string in Json format, and the Json format is conducive to the parsing and generation of the communication sender and receiver. Among them, when any two subsystems communicate with each other, each subsystem can be used as a communication sending subsystem or a communication receiving subsystem. When the communication sending subsystem, the WebSocketClient client module can be used to send a method request to another subsystem, and the WebSocket Server module can also be used to send a broadcast message to another subsystem. The communication receiving subsystem can generate communication feedback data (i.e., return result) corresponding to the communication request data, and then locate the communication sending subsystem based on the interface field carried in the received communication request data, and then send the communication feedback data to the communication sending subsystem identified by the interface field.
[0037] Correspondingly, the communication data includes communication request data. When communicating between any two subsystems, the communication sending subsystem in any two subsystems is configured to convert the communication request data into Json string data, and add an interface field of the interface code corresponding to the communication sending subsystem, and send the Json string data with the added interface field to the communication receiving subsystem in any two subsystems through the WebSocket communication protocol.
[0038] Correspondingly, the communication data also includes communication feedback data. When communicating between any two subsystems, the communication receiving subsystem is configured to parse the Json string data, obtain the communication request data and the interface field, and send the communication feedback data corresponding to the communication request data to the communication sending subsystem identified by the interface field through the WebSocket communication protocol.
[0039] During the communication process, the relevant fields of the Json string are shown in Table 2: Table 2. Json string related fields
[0040] The processing of Json string communication content generally includes two processes: one is to generate a Json format string toJson, and the other is to parse the Json format string fromJson.
[0041] The sender (i.e., the communication sending subsystem) needs to generate a Json string when sending a request. The sender needs to provide relevant input parameters and convert different types of parameters into corresponding Json string contents. Then, according to the content defined by the FIDL interface, add the requested component and method fields to the Json string, and then send it out through WebSocket.
[0042] After the receiver (i.e., the communication receiving subsystem) receives the external request through WebSocket, it needs to parse the Json string. The receiver converts the parameter information in the Json string according to its corresponding type, and then determines which functional module and which related interface the external request is based on the content of the component and method fields, and then sends the corresponding return result of the request to the sender identified by the interface field.
[0043] In summary, the communication system based on FIDL interface document conversion provided by the present invention includes multiple subsystems; each of the multiple subsystems deploys an interface document conversion module respectively, and when the subsystem needs to generate an interface code, the interface document conversion module can convert the predefined FIDL interface document into an interface code under the target language type, wherein the FIDL interface document is separated from the function code, and the target language type is a language type adapted to the subsystem. The interface is defined by a unified FIDL file format, the interface definition document is separated from the specific code, and the interface file conversion tool is used to convert the FIDL interface document into the target interface code, which can facilitate development and use, and improve the maintainability and scalability of the interface part code. In addition, a communication adapter module is deployed inside each subsystem, and the communication adapter module is configured to convert the communication data into Json string data when communicating between any two subsystems, and transmit the Json string data according to the WebSocket communication protocol based on the interface code. This method of using a combination of Json format strings and WebSocket sockets to complete the specific communication process can meet the needs of different communication scenarios to a large extent, realize real-time and persistent data exchange, and fully reduce communication transmission occupancy, shorten the transmission string parsing and generation time, thereby improving communication efficiency.
[0044] Figure 4A flow chart of a communication method based on FIDL interface document conversion provided by an embodiment of the present invention, the method can be as follows Figure 1 The communication system shown is executed based on FIDL interface document conversion. Figure 4 As shown, the method may include the following steps: Step 410: In response to an external command, parse and determine whether a target processor and a target generator in the target language type are deployed inside the interface document conversion module, wherein the external command is used to instruct generation of interface code in the target language type.
[0045] For the disclosed embodiment, the basic framework (main) in the interface document conversion module can effectively receive the external command (FIDL) for instructing the generation of the interface code under the target language type, and then can identify whether the target processor and target generator corresponding to the target language type are deployed by parsing the command line internally. In the case of parsing and judging that there are target processors and target generators, the basic framework will call the relevant functions in the corresponding target processor to convert the interface code. These functions are responsible for scheduling the entire process. They will read the FIDL interface file and generate the interface code based on the corresponding code template provided by the target generator; in the case of parsing and judging that there are related errors, such as incorrect external command input, failure to find or read the specified FIDL file, undefined related processors, etc., the basic framework will feedback the relevant errors to indicate that the interface code under the target language type cannot be generated. In this way, the orderly conversion of the interface code can be guaranteed, the efficiency of the code conversion can be improved, and the generation error of the interface code can be reduced.
[0046] Step 420: When the interface document conversion module is analyzed and determined to have a target processor and a target generator deployed therein, the target processor is used to generate interface code in the target language type based on the FIDL interface document and the code template configured on the target generator.
[0047] Among them, the code template sets the specific code structure in the generated target language interface code file based on the relevant elements (such as structures, tables, and services) defined in the FIDL interface document. These templates can be simple text files or more complex scripts or programs, which can generate corresponding code based on the relevant element definitions provided by FIDL. The target language type is the target programming language type for which code needs to be generated, such as C++, Java, Python, etc. The target processor is responsible for scheduling the interface code file generation process, can understand the syntax and rules of FIDL and identify all necessary information, can provide relevant function calls to read and parse the FIDL interface document, and generate the target language interface code file based on the definitions of relevant types, field names, field types, service methods, etc. in the FIDL document.
[0048] Step 430: When any two subsystems communicate, the communication adapter module is used to convert the communication data into Json string data, and based on the interface code, the Json string data is transmitted according to the WebSocket communication protocol.
[0049] Ideally, the communication between subsystems can be fixed in a certain communication mode, which is conducive to improvement and maintenance. However, in the actual production environment, different projects may require different communication modes; at the same time, when in different architectural modes, different communication modes suitable for this architectural mode will be adopted.
[0050] In other words, in actual situations, subsystems may not always use a certain communication method, but rather flexibly select a suitable communication method based on different needs. In view of this realistic scenario, and considering reducing coupling as much as possible, a communication adaptation method can be proposed in this application to meet the needs of flexibly configuring different communication methods.
[0051] The essence of communication adaptation is to isolate communication changes. In this application, all the multiple communication methods that need to be used can be introduced into the communication adaptation module framework. When a new scenario appears and a new communication method needs to be adopted, the overall framework of the communication adaptation module will not change. You only need to implement a specific communication method and introduce it into the communication adaptation module.
[0052] After adopting the communication adaptation mechanism, from the perspective of communication between subsystems, the communicating parties have not changed, but the communication method is no longer fixed. It will be selected and configured based on different needs and different architectures. In this way, when the needs and architectures change, a more suitable communication method can be selected accordingly, thereby improving the overall communication flexibility.
[0053] There are many different communication scenarios in reality, such as cross-platform, cross-language, and cross-machine communication. From a process perspective, there is intra-process communication and inter-process communication. At the same time, the selection of the data transmission format in communication is also very important, as it will greatly affect the quality and efficiency of communication.
[0054] In order to meet the communication needs of the above-mentioned scenarios, WebSocket can be used as the communication basis in this application. In addition to being well adapted to different scenarios, WebSocket also provides a persistent full-duplex communication connection channel for both parties to communicate, satisfying the real-time and continuous data communication exchange; at the same time, in order to solve the problems of high communication transmission occupancy and difficulty in machine parsing and generation in some current data transmission formats, the Json string data structure can be used in this application. The Json format has many characteristics that facilitate communication. Its key-value pair structure is relatively lightweight, occupies less space, is easy for both parties to communicate to generate and parse, and is highly readable, making it easier for developers to perform related debugging.
[0055] For the disclosed embodiments, a FIDL interface definition document can be used to separate the interface definition document from the specific code, thereby improving the maintainability and scalability of the interface code. At the same time, existing interface conversion tools such as CommonAPI only convert a specific language and are not scalable, while the interface conversion tool proposed in this patent can convert multiple target languages, thereby improving flexibility in use. In order to meet different project requirements and architecture requirements, this patent proposes a communication adaptation method in subsystem communication. At the same time, in view of the low communication efficiency caused by some current communication methods due to high communication transmission occupancy, high frequency and poor transmission effect of large amounts of data, this patent is based on communication adaptation and uses a combination of Json format strings and WebSocket sockets to complete the specific communication process. It can meet the needs of different communication scenarios to a large extent, realize real-time and persistent data exchange, and can fully reduce the communication transmission occupancy, shorten the transmission string parsing and generation time, and thus improve communication efficiency.
[0056] Based on the above Figure 4 The detailed description of the communication method based on FIDL interface document conversion is provided, such as Figure 5 As shown, Figure 5 1 is a structural block diagram of a communication device based on FIDL interface document conversion according to an exemplary embodiment. Figure 5 As shown, the device comprises: The parsing module 51 may be used to respond to an external command and parse and determine whether a target processor and a target generator of a target language type are deployed inside the interface document conversion module, wherein the external command is used to instruct the generation of an interface code of a target language type; The generation module 52 may be used to generate the interface code in the target language type by using the target processor based on the FIDL interface document and the code template configured on the target generator when the target processor and the target generator are deployed inside the parsing judgment interface document conversion module; The transmission module 53 can be used to convert the communication data into Json string data by using the communication adapter module when communicating between any two subsystems, and transmit the Json string data according to the WebSocket communication protocol based on the interface code.
[0057] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.
[0058] In the embodiment of the present application, the FIDL interface definition document can be used to separate the interface definition document from the specific code, thereby improving the maintainability and scalability of the interface code. At the same time, existing interface conversion tools such as CommonAPI only convert a specific language and are not scalable, while the interface conversion tool proposed in this patent can convert multiple target languages, thereby improving flexibility in use. In order to meet different project requirements and architecture requirements, this patent proposes a communication adaptation method in subsystem communication. At the same time, in view of the low communication efficiency caused by the high communication transmission occupancy, high frequency and poor transmission effect of large data volume in some current communication methods, this patent is based on communication adaptation and uses a combination of Json format strings and WebSocket sockets to complete the specific communication process, which can meet the needs of different communication scenarios to a large extent, realize real-time and persistent data exchange, and can fully reduce the communication transmission occupancy, shorten the transmission string parsing and generation time, and thus improve communication efficiency.
[0059] In the above text, the communication device based on FIDL interface document conversion according to the embodiment of the present invention is described from the perspective of functional modules in combination with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented in software form, or can be implemented in combination with hardware and software modules. Specifically, each step of the communication method embodiment based on FIDL interface document conversion in the embodiment of the present invention can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the communication method based on FIDL interface document conversion applied in combination with the embodiment of the present invention can be directly embodied as a hardware decoding processor to execute, or a combination of hardware and software modules in the decoding processor to execute. Optionally, the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps in the above-mentioned communication method embodiment based on FIDL interface document conversion in combination with its hardware.
[0060] Figure 6 is a schematic block diagram of an electronic device 600 according to an embodiment of the present invention.
[0061] like Figure 6 As shown, the electronic device 600 may include: The memory 610 and the processor 620, the memory 610 is used to store the computer program and transmit the program code to the processor 620. In other words, the processor 620 can call and run the computer program from the memory 610 to implement the method in the embodiment of the present invention.
[0062] For example, the processor 620 may be configured to execute the above method embodiments according to instructions in the computer program.
[0063] In some embodiments of the present invention, the processor 620 may include but is not limited to: General-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
[0064] In some embodiments of the present invention, the memory 610 includes but is not limited to: Volatile memory and / or non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct memory bus random access memory (Direct Rambus RAM, DR RAM).
[0065] In some embodiments of the present invention, the computer program may be divided into one or more modules, which are stored in the memory 610 and executed by the processor 620 to complete the method provided by the present invention. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the controller.
[0066] like Figure 6 As shown, the electronic device 600 may further include: The transceiver 630 may be connected to the processor 620 or the memory 610 .
[0067] The processor 620 may control the transceiver 630 to communicate with other devices, specifically, to send data to other devices or receive data sent by other devices. The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include an antenna, and the number of antennas may be one or more.
[0068] It should be understood that the various components in the electronic device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.
[0069] The present invention also provides a computer storage medium having a computer program stored thereon, which, when executed by a computer, enables the computer to perform the method of the above method embodiment. In other words, an embodiment of the present invention also provides a computer program product containing instructions, which, when executed by a computer, enables the computer to perform the method of the above method embodiment.
[0070] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (Digital Video Disc, DVD)), or a semiconductor medium (e.g., a solid-state drive (Solid State Disk, SSD)), etc.
[0071] Those skilled in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments applied herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.
[0072] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.
[0073] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.
[0074] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in this application, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.
Claims
1. A communication system based on FIDL interface document conversion, characterized in that: include: Multiple subsystems; Each of the multiple subsystems is respectively deployed with an interface document conversion module, wherein the interface document conversion module is configured to convert a predefined FIDL interface document into an interface code in a target language type, wherein the FIDL interface document is separated from a function code, and the target language type is a language type adapted to the subsystem; A communication adapter module is deployed inside each of the subsystems. The communication adapter module is configured to convert communication data into Json string data when any two subsystems communicate with each other, and transmit the Json string data according to the WebSocket communication protocol based on the interface code.
2. The communication system based on FIDL interface document conversion according to claim 1, characterized in that: The interface document conversion module includes a basic framework, and corresponding processors and generators are deployed in the basic framework for different language types; The basic framework is configured to parse and determine whether a target processor and a target generator of a target language type are deployed inside the interface document conversion module in response to an external command, wherein the external command is used to instruct the generation of an interface code of a target language type; The basic framework is configured to, when parsing and determining that the target processor and the target generator are not deployed inside the interface document conversion module, externally feedback a relevant error to indicate that the interface code in the target language type cannot be generated.
3. The communication system based on FIDL interface document conversion according to claim 2, characterized in that: When it is determined through analysis that the target processor and the target generator are deployed inside the interface document conversion module, the target processor is configured to generate interface code in the target language type based on the FIDL interface document and the code template configured on the target generator.
4. The communication system based on FIDL interface document conversion according to claim 1, characterized in that: A variety of communication modes are deployed in the communication adaptation module; The communication adaptation module is configured to determine the communication requirements and architectural mode between any two subsystems, and select a target communication mode that matches the communication requirements and the architectural mode from the multiple communication modes, and create a communication connection between any two subsystems according to the target communication mode.
5. The communication system based on FIDL interface document conversion according to claim 1, characterized in that: The communication data includes communication request data. When communicating between any two subsystems, the communication sending subsystem in any two subsystems is configured to convert the communication request data into Json string data, and add an interface field of the interface code corresponding to the communication sending subsystem, and send the Json string data with the interface field added to the communication receiving subsystem in any two subsystems through the WebSocket communication protocol.
6. The communication system based on FIDL interface document conversion according to claim 5, characterized in that: The communication data also includes communication feedback data. When communicating between any two subsystems, the communication receiving subsystem is configured to parse the Json string data, obtain the communication request data and the interface field, and send the communication feedback data corresponding to the communication request data to the communication sending subsystem identified by the interface field through the WebSocket communication protocol.
7. A communication method based on FIDL interface document conversion, characterized in that: The method is applied to the communication system based on FIDL interface document conversion according to any one of claims 1 to 6, and the method comprises: In response to an external command, parsing and determining whether a target processor and a target generator in a target language type are deployed inside the interface document conversion module, wherein the external command is used to instruct the generation of an interface code in a target language type; In the case where the target processor and the target generator are deployed in the interface document conversion module through analysis, the target processor is used to generate the interface code in the target language type based on the FIDL interface document and the code template configured on the target generator; When any two subsystems communicate, the communication data is converted into Json string data using the communication adapter module, and the Json string data is transmitted according to the WebSocket communication protocol based on the interface code.
8. A communication device based on FIDL interface document conversion, characterized in that: The device is applied to the communication system based on FIDL interface document conversion according to any one of claims 1 to 6, and the device comprises: A parsing module, used for parsing and determining whether a target processor and a target generator of a target language type are deployed inside the interface document conversion module in response to an external command, wherein the external command is used to instruct the generation of an interface code of a target language type; A generation module, configured to generate interface code in the target language type by using the target processor based on the FIDL interface document and the code template configured on the target generator when parsing and determining that the target processor and the target generator are deployed inside the interface document conversion module; The transmission module is used to convert the communication data into Json string data by using the communication adapter module when communicating between any two subsystems, and transmit the Json string data according to the WebSocket communication protocol based on the interface code.
9. An electronic device, characterized in that: include: A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute the method according to claim 7.
10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein the computer program causes a computer to execute the method according to claim 7.