Plug-in service framework for reconfigurable integrated terminal

Abstract

The application discloses a plug-in service framework for a reconfigurable comprehensive terminal, which comprises an application layer, a forwarding layer, a native support layer and a plug-in service layer, wherein the application layer is a front-end page of H5 standard, is responsible for interaction with a user and display and update of an interface; the forwarding layer is mainly used for receiving and forwarding of user requests and service responses; the native support layer mainly comprises two components, namely a rendering engine and an eTS engine; and the service layer mainly comprises a plug-in service engine and various peripheral service devices; and the plug-in service engine is constructed between an application program and an operating system, supports the HTML5 standard, can shield differences of underlying operating systems and provide stable and usable peripheral service devices for upper-layer applications.

Description

Technical Field

[0001] This invention relates to hardware module driver technology for the OpenHarmony operating system, specifically to a pluggable service framework for reconfigurable integrated terminals. Background Technology

[0002] The OpenHarmony operating system is an open-source project incubated and operated by the OpenAtom Foundation. Its goal is to build a framework and platform for an operating system for intelligent terminal devices in a fully connected, intelligent era, based on open source, thus promoting the prosperity and development of the Internet of Things industry. Various peripherals connect via wired and wireless means, forming a super virtual terminal with reconfigurable hardware modules and software functions; this is referred to here as a reconfigurable integrated terminal. Currently, peripheral components are diverse and lack standardized specifications, making it difficult to guarantee rapid hardware component integration. The lack of verification methods when connecting peripheral components further increases system security risks. This paper introduces a plug-in service framework for reconfigurable integrated terminals to achieve flexible reconfiguration of hardware modules and software functions.

[0003] Compared to template-based website programming that integrates both front-end and back-end, the development model that separates front-end and back-end is the mainstream trend. Currently popular cross-platform application development frameworks include Lonic (based on AngularJS), React Native (based on JavaScript), and NativeScript (based on JavaScript). However, these mainstream frameworks have not yet been adapted for the OpenHarmony operating system, making it impossible to build a plug-in service framework based on front-end and back-end separation. Summary of the Invention

[0004] The purpose of this invention is to propose a plug-in service framework for reconfigurable integrated terminals based on the OpenHarmony operating system.

[0005] The technical solution to achieve the purpose of this invention is as follows: a pluggable service framework for reconfigurable integrated terminals, used to support peripheral access for hardware reconfigurable terminals, specifically including an application layer, a forwarding layer, a native support layer, and a pluggable service layer. The pluggable service framework enables cross-layer (application layer to service layer) and cross-language (JavaScript to C++ / eTS) calls through an encapsulated WebSocket interface, wherein:

[0006] The application layer consists of the H5 standard front-end pages, which are responsible for interacting with users and displaying and updating the interface;

[0007] The forwarding layer is mainly used for receiving and forwarding user requests and service responses;

[0008] The native support layer mainly includes the rendering engine and the eTS engine, and has the ability to render UI components and access eTS interfaces;

[0009] The service layer mainly includes a pluggable service engine and various peripheral services. The pluggable service engine is developed using C++. It performs service access authentication by parsing services with the .service suffix; loads peripheral services through the dlopen function; receives requests from the forwarding layer by setting up a WebSocket protocol communication server, and distributes them to the requested peripheral service or the native support layer's eTS engine according to the request type; and receives peripheral service request responses or eTS engine interface request responses through a signal and slot mechanism.

[0010] The peripheral service is a backend function extension library developed by the user. It is developed in C++ and receives and processes requests distributed by the plug-in service engine by inheriting the OnMessage function. Finally, it returns the results to the plug-in service engine through signals and slots.

[0011] Furthermore, in the application layer, the WebStorm development tool is used to build the graphical rendering page based on HTML5 or the Vue front-end framework, generating .vue or .html files; CSS3 is used to control the page style, specifically using inline style sheets, embedded style sheets, or external style sheets, generating .css style files; and ES6 standard JavaScript is used to control the business logic. Here, the JavaScript API encapsulated by the plug-in service framework is used to initiate corresponding peripheral service requests. The service request should include a corresponding request callback function to realize peripheral access and the reception of request responses, generating .js script files containing control logic.

[0012] Furthermore, the forwarding layer uses JavaScript to build a communication client based on the WebSocket protocol. This client listens for service access requests from the application layer's front-end page, parses the requests, saves the successfully parsed request callback functions in a callback pool, and forwards the requests to the service layer's pluggable service engine. The WebSocket-based communication client also listens for the service request results returned by the service layer's pluggable engine and returns them to the front-end user through the callback functions stored in the callback pool.

[0013] Furthermore, the service access request should include a request ID, peripheral service name, peripheral interface, service flag, and access parameters; the request ID is designed as a string with a fixed length of 10 bytes; the peripheral service name is a string with a variable length, up to a maximum of 256 bytes; the peripheral interface has a variable length, up to a maximum of 256 bytes; the service access flag is a string, with the value "eTS" indicating that this service access request is a native interface request, and the value empty indicating that this service access is a low-level interface request; the access parameters are JSON strings with a maximum length of 65536 bytes.

[0014] The service access request parser parses the front-end page request according to the above standards. If the request is parsed correctly, the request callback function is cached, and the request is forwarded to the pluggable service engine of the service layer through the WebSocket communication client. If the parsing fails, the corresponding error type is returned to the front-end user through the callback function.

[0015] Furthermore, the service response should include a response ID, a call status flag, a response status flag, a response hold flag, and a call result. The response ID is designed as a string with a fixed length of 10 bytes; the call status flag is a boolean type, with a value of true indicating a successful call and a value of false indicating a failed call; the response status flag is a numeric type, with a value of 999999 indicating that the current service response is from the open-source HarmonyOS system; the response hold flag is a boolean type, with a value of true indicating that this service response is a long-term response and a value of false indicating that this service response is a one-time response; the call result is a JSON string with a maximum length of 65536 bytes, representing the data returned by the service.

[0016] The service response parser parses the backend response according to the above standards. If the response is parsed correctly, it calls the saved callback function and returns the result to the frontend user. If the parsing is incorrect, it returns the corresponding error type to the frontend user through the callback function.

[0017] Furthermore, in the native support layer, the rendering engine is the rendering process of the OpenHarmony native ArkUI framework, developed using the eTS language. It uses its provided web components to render the front-end pages of the application layer and passes the service port to the forwarding layer to start the WebSocket client. The eTS engine is used to parse the native ArkUI framework .eTS file, developed using the eTS language. It initializes the underlying server and obtains its bound port number by calling the plug-in service engine interface. It starts its socket client by passing the port number to the eTS native plugin, and at the same time completes the native interface request call work.

[0018] A development process for a plug-in service framework for reconfigurable integrated terminals, characterized by the following steps:

[0019] Step S10: Use the open-source HarmonyOS development software DevEcoStudio to build the OpenHarmony system application project. This project is used to compile the device software installation package. The project's directory structure includes front-end page files, peripheral service files, framework files, and configuration files. The front-end page files store the user's H5 page source code, resource files, and compiled camera front-end operation logic files. The peripheral service files store the compiled driver service files for external cameras. The framework files store the SDK for the service framework. The configuration files store the access files for peripheral services.

[0020] Using the Vue front-end framework, develop front-end pages, complete page layout, page navigation, page operations, and page data requests, and complete the development of pages that allow application interaction with users. The page data requests are developed in JavaScript and need to be written using fixed interfaces according to the plugin development requirements. After development is completed, compile the logic files and copy them to the S10 project structure directory.

[0021] Step S20: In the project created in step S10, create an external camera service module and write the processing interface of the Native operation code corresponding to the page data request in step S10. Store the specific functional code of the external camera in the CPP directory of the external camera service module, and return the request result to the front end through a fixed interface for interacting with the plugin framework. Compile the camera module code using the IDE to generate the service SO dynamic library file, and copy it to the project structure directory of S10.

[0022] Step S30: Copy the service library file generated in the external camera service module of step S20 to the project structure directory of step S10, and create a new configuration file to configure the service path and service name of the connected peripheral device. Use the framework's functions to parse and render the front-end page file. Use DevEcoStudio software to package the project and install it on the OpenHarmony system device to complete the project.

[0023] Compared with the prior art, the present invention has the following advantages: (1) It realizes cross-language calls, enabling access to C++ plug-in services or eTS native interfaces through the front-end JavaScript interface, thereby improving the running efficiency of the application. (2) It builds a plug-in service engine between the application and the operating system, supports the HTML5 standard, and can shield the differences of the underlying operating system, providing stable and usable peripheral services to the upper-layer application. (3) Under the framework of the present invention, developers do not need to consider the differences of the underlying operating system, but only need to focus on the implementation of the application code. Using this framework, it can be adapted to multiple mobile operating systems such as Android and SyberOS. (4) By adopting plug-in services, it can realize plug-and-play functionality for various peripherals and has the ability to quickly access peripherals. Attached Figure Description

[0024] Figure 1 This is a diagram of a plug-in service framework.

[0025] Figure 2 Here is a sample code diagram for the client-side implementation.

[0026] Figure 3 Example diagram of a service access request.

[0027] Figure 4 Example diagram of service response.

[0028] Figure 5 This is a sample code diagram for a rendering engine web component.

[0029] Figure 6 This is a sample code diagram for a socket client.

[0030] Figure 7 Here is a sample code diagram for the server-side implementation.

[0031] Figure 8 Example code diagram for peripheral device services.

[0032] Figure 9 Flowchart for developing peripheral service plugins. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] This invention provides a plug-in service framework for reconfigurable integrated terminals, supporting front-end and back-end separation development and cross-language calls. It supports standard HTML5 development, enabling rapid hardware module integration and dynamic loading of corresponding software functions, reducing platform application porting costs, and improving application flexibility and cross-platform compatibility. Figure 1 As shown, the plug-in service framework has a four-layer architecture: application layer, forwarding layer, native support layer, and plug-in service layer. Among them:

[0035] (1) Application layer

[0036] The application layer mainly consists of user-developed H5 standard front-end pages, responsible for interacting with users and displaying and updating the interface.

[0037] Users can use JetBrains' WebStorm development tool to build graphical rendering pages based on HTML5 or the Vue front-end framework, generating .vue or .html files; control page styles using CSS3, specifically inline stylesheets, embedded stylesheets, or external stylesheets, generating .css style files; and control business logic using ES6 standard JavaScript. Here, the JavaScript API encapsulated by the plug-in service framework can be used to initiate corresponding peripheral service requests, enabling peripheral access and generating .js script files containing control logic.

[0038] (2) Forwarding layer

[0039] The forwarding layer is mainly used for receiving and forwarding user requests and service responses.

[0040] The forwarding layer uses JavaScript, such as Figure 2 A communication client based on the WebSocket protocol is built to listen for service access requests from the application layer front-end page, complete request parsing and caching, and forward the requests to the service layer's pluggable service engine. The WebSocket-based communication client is also used to listen for service request results returned by the service layer's pluggable engine and return them to the front-end user through callback functions.

[0041] like Figure 3A service access request conforming to the pluggable service framework standard should include fields such as request ID, peripheral service name, peripheral interface, service flag, and access parameters. The request ID is a string with a fixed length of 10 bytes; the peripheral service name is a string with a variable length, up to a maximum of 256 bytes; the peripheral interface has a variable length, up to a maximum of 256 bytes; the service access flag is a string, with the value "eTS" indicating a native interface request and an empty value indicating a low-level interface request; the access parameters are JSON strings with a maximum length of 65536 bytes. The request parser parses the front-end page request according to the above standard. If the request is parsed correctly, the request callback function is cached, and the request is forwarded to the pluggable service engine in the service layer via a WebSocket communication client; if the parsing fails, the corresponding error type is returned to the front-end user through the callback function.

[0042] like Figure 4 A standard service response from a service plug-in framework should include fields such as response ID, call status flags, response status flags, response hold flags, and call result. The response ID is a string with a fixed length of 10 bytes; the call status flags are boolean, with a value of true indicating success and false indicating failure; the response status flags are numeric, with a value of 999999 indicating a service response from the open-source HarmonyOS system; the response hold flags are boolean, with a value of true indicating a long-lasting response and false indicating a one-time response; the call result is a JSON string with a maximum length of 65536 bytes, representing the data returned by the service. The response parser parses the backend response according to the above standards. If the response is parsed correctly, it calls the saved callback function and returns the result to the frontend user; if the parsing fails, it returns the corresponding error type to the frontend user through the callback function.

[0043] (3) Native support layer

[0044] The native support layer mainly consists of two components: the rendering engine and the eTS engine.

[0045] like Figure 5 The rendering engine is the rendering process of the OpenHarmony native ArkUI framework, developed using the eTS language. It uses the web components it provides to render the front-end pages of the application layer and passes the service port to the forwarding layer to start the Websocket client.

[0046] The eTS engine is used to parse the native ArkUI framework .eTS files. Developed using the eTS language, it initializes the underlying server and obtains its bound port number by calling the pluggable service engine interface; for example... Figure 6 It starts its socket client by passing the port number to the eTS native plugin, and at the same time completes the native interface request call.

[0047] (4) Service layer

[0048] The service layer mainly includes a pluggable service engine and various peripheral services.

[0049] like Figure 7 The pluggable service engine is developed using C++. It loads peripheral services through functions such as dlopen. It sets up a communication server based on the WebSocket protocol, receives requests sent from WebSocket clients and distributes them to the requested peripheral services, and receives results sent from native socket clients. It receives the results returned by peripheral services through a signal and slot mechanism and forwards them to WebSocket clients.

[0050] Peripheral services are backend function extension libraries developed independently by users based on certain development specifications. For example... Figure 8 The peripheral service is developed using C++. It receives and processes requests distributed by the plug-in service engine by inheriting the OnMessage function, and finally returns the results to the plug-in service engine through signals and slots.

[0051] like Figure 9 As shown, a process developed based on this plug-in service framework includes the following specific steps:

[0052] Step S10: Use the open-source HarmonyOS development software DevEcoStudio to build the OpenHarmony system application project. This project is used to compile the device software installation package. The project directory structure includes front-end page files, peripheral service files, framework files, and configuration files. The front-end page files store the user's H5 page source code, resource files, and compiled camera front-end operation logic files, etc. The peripheral service files store the compiled driver service files for external cameras, the framework files store the service framework SDK, and the configuration files store files for accessing peripheral services, etc. Use the mainstream front-end framework Vue to develop the front-end pages, completing page layout, page navigation, page operations, page data requests, etc. The main task of this step is to complete the development of the application's user-interactive pages. Page data requests are developed using JavaScript and require writing fixed interfaces according to plugin development requirements. Other aspects are no different from common front-end development. After development, compile the page data request and other logic files and copy them to the S10 project structure directory.

[0053] Step S20: In the project created in step S10, create a module for the external camera service and write the processing interface for the Native operation code corresponding to the page data request in step S10. Store the specific functional code related to the external camera in the module's CPP directory, such as photo taking, video recording, and focusing functions. Return the request results to the front end through a fixed interface that interacts with the plugin framework. Compile the camera module code using an IDE to generate the service's SO dynamic library file and copy it to the project structure directory of step S10.

[0054] Step S30: Copy the service library files generated in step S20 to the project structure directory of step S10, create a new configuration file to configure the access peripheral service path and service name, and use the framework's functions to parse and render the front-end page files. Package the project using DevEcoStudio software and install it on the OpenHarmony system device to complete the project.

[0055] The above examples are only for illustrating the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be used to limit the scope of protection of the present invention. All equivalent changes or modifications made in accordance with the spirit and essence of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A plug-in service framework for reconfigurable integrated terminals, characterized in that, This is used to support peripheral access for hardware-reconfigurable terminals, specifically including an application layer, a forwarding layer, a native support layer, and a pluggable service layer. Through a encapsulated WebSocket interface, it enables cross-layer and cross-language calls from the application layer to the service layer. The application layer consists of the H5 standard front-end pages, which are responsible for interacting with users and displaying and updating the interface; The forwarding layer is mainly used for receiving and forwarding user requests and service responses; The native support layer mainly includes the rendering engine and the eTS engine, and has the ability to render UI components and access eTS interfaces; The service layer mainly includes a pluggable service engine and various peripheral services, among which, The pluggable service engine is developed using C++. It performs service access authentication by parsing services with the .service suffix; loads peripheral services through the dlopen function; receives requests from the forwarding layer by setting up a WebSocket protocol communication server, and distributes them to the requested peripheral service or the native support layer eTS engine according to the request type; and receives peripheral service request responses or eTS engine interface request responses through the signal and slot mechanism. The peripheral service is a backend function extension library developed by the user. It is developed in C++ and receives and processes requests distributed by the plug-in service engine by inheriting the OnMessage function. Finally, it returns the results to the plug-in service engine through signals and slots.

2. The plug-in service framework for reconfigurable integrated terminals according to claim 1, characterized in that, In the application layer, the WebStorm development tool is used to build the graphical rendering page based on HTML5 or the Vue front-end framework, generating .vue or .html files. CSS3 is used to control the page style, specifically using inline style sheets, embedded style sheets, or external style sheets, generating .css style files. ES6 standard JavaScript is used to control the business logic. Here, the JavaScript API encapsulated by the plug-in service framework is used to initiate the corresponding peripheral service requests. The peripheral service requests include request callback functions to realize peripheral access and the reception of request responses, generating .js script files containing control logic.

3. The plug-in service framework for reconfigurable integrated terminals according to claim 1, characterized in that, The forwarding layer uses JavaScript to build a communication client based on the WebSocket protocol. It listens for service access requests from the application layer's front-end page, parses the requests, saves the callback functions of successfully parsed requests in the callback pool, and forwards the requests to the service layer's pluggable service engine. The WebSocket-based communication client is also used to listen for service request results returned by the service layer's pluggable engine and return them to the front-end user through the callback functions stored in the callback pool.

4. The plug-in service framework for reconfigurable integrated terminals according to claim 3, characterized in that, Service access requests should include a request ID, peripheral service name, peripheral interface, service flags, and access parameters; the request ID is designed as a string with a fixed length of 10 bytes. The peripheral service name is a string type with a variable length, with a maximum length of 256 bytes; Peripheral interface, length is variable, maximum length is 256 bytes; service access flag is of type String, the value "eTS" indicates that this service access request is a native interface request, and the value empty indicates that this service access is a low-level interface request. The access parameter is a JSON string with a maximum length of 65536 bytes; The service access request parser parses the front-end page request according to the above standards. If the request is parsed correctly, the request callback function is cached, and the request is forwarded to the pluggable service engine of the service layer through the Websocket communication client. If a parsing error occurs, the corresponding error type will be returned to the front-end user via a callback function.

5. The plug-in service framework for reconfigurable integrated terminals according to claim 3, characterized in that, The service response should include a response ID, a call status flag, a response status flag, a response hold flag, and a call result. The response ID is designed as a string with a fixed length of 10 bytes. The call status flag is a boolean, with a value of true indicating a successful call and a value of false indicating a failed call; the response status flag is a numeric, with a value of 999999 indicating a service response from the open-source HarmonyOS system; the response hold flag is a boolean, with a value of true indicating a long-lasting response and a value of false indicating a one-time response; the call result is a JSON string with a maximum length of 65536 bytes, representing the data returned by the service. The service response parser parses the backend response according to the above standards. If the response is parsed correctly, it calls the saved callback function and returns the result to the frontend user. If the parsing is incorrect, it returns the corresponding error type to the frontend user through the callback function.

6. The plug-in service framework for reconfigurable integrated terminals according to claim 1, characterized in that, In the native support layer, the rendering engine is the rendering process of the OpenHarmony native ArkUI framework, developed using the eTS language. It uses its provided web components to render the front-end pages of the application layer and passes the service port to the forwarding layer to start the WebSocket client. The eTS engine is used to parse the native ArkUI framework .eTS file. It is also developed using the eTS language. It initializes the underlying server and obtains its bound port number by calling the plug-in service engine interface. It starts its socket client by passing the port number to the eTS native plugin and completes the native interface request call work.

7. A development process for a plug-in service framework for a reconfigurable integrated terminal as described in any one of claims 1-6, characterized in that, Includes the following steps: Step S10: Use the open-source HarmonyOS development software DevEcoStudio to build the OpenHarmony system application project. This project is used to compile the device software installation package. The project's directory structure includes front-end page files, peripheral service files, framework files, and configuration files. The front-end page files store the user's H5 page source code, resource files, and compiled camera front-end operation logic files. The peripheral service files store the compiled driver service files for external cameras. The framework files store the SDK for the service framework. The configuration files store the access files for peripheral services. Using the Vue front-end framework, develop front-end pages, complete page layout, page navigation, page operations, and page data requests, and complete the development of pages that allow application interaction with users. The page data requests are developed in JavaScript and need to be written using fixed interfaces according to the plugin development requirements. After development is completed, compile the logic files and copy them to the S10 project structure directory. Step S20: In the project created in step S10, create an external camera service module and write the processing interface of the Native operation code corresponding to the page data request in step S10. Store the specific functional code of the external camera in the CPP directory of the external camera service module, and return the request result to the front end through a fixed interface for interacting with the plugin framework. Compile the camera module code using the IDE to generate the service SO dynamic library file, and copy it to the project structure directory of S10. Step S30: Copy the service library file generated in the external camera service module of step S20 to the project structure directory of step S10, and create a new configuration file to configure the service path and service name of the connected peripheral device. Use the framework's functions to parse and render the front-end page file. Use DevEcoStudio software to package the project and install it on the OpenHarmony system device to complete the project.

Images