Middleware system interacting with soft bus based on general publishing and subscribing mode

Abstract

The invention provides a middleware system interacting with a soft bus based on a general publish-subscribe mode, which belongs to the technical field of communication, and comprises a protocol plug-in management module for dynamically loading a protocol plug-in; the soft bus interaction module receives the publishing / subscribing request message, creates a session service and calls a loaded protocol plug-in, and the protocol plug-in processes a data distribution service message; the message structure management module is connected with the protocol plug-in management module; the data mapping module is connected with the message structure management module; the session management module is respectively connected with the soft bus interaction module and the data mapping module; and the real-time scheduling engine is respectively connected with the protocol plug-in management module and the session management module. The method has the advantages that multiple protocols are supported through a plug-in mechanism, efficient interaction with a device soft bus is achieved, the soft bus is used for issuing capacity, session services are created, a general message structure is adopted, low-delay, high-reliability and efficient heterogeneous system communication is achieved, and the requirements of the Internet of Things and industrial control scenes are met.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a middleware system based on a general publish-subscribe pattern and interacting with a soft bus. Background Technology

[0002] Data Distribution Service (DDS) is a real-time data distribution protocol based on a publish-subscribe model, enabling the publishing and subscription of topic data in a distributed environment. Distributed soft buses, such as the SoftBus in the open-source Harmony operating system, provide a unified framework for communication between devices, supporting device discovery and message passing.

[0003] Because the data distribution service and the distributed soft bus employ different protocols and architectures, interaction between them typically requires a customized gateway or bridge. A typical interaction scheme consists of a data distribution server, a soft bus, and a bridge. The data distribution server runs a DDS protocol stack, such as FastDistributed Data Service (FastDDS), which publishes and subscribes to topic data via the Real-time Publish-Subscribe Protocol (RTPS). Topics are identified by a domain identifier (ID) and a topic name, and data is transmitted in a structured format. The soft bus is based on the OpenHarmony SoftBus framework and enables inter-device communication through service discovery (such as LNN) and messaging (such as sessions). The bridge is typically deployed on an embedded device, located between the data distribution server and the soft bus, and includes a protocol conversion module and a data mapping module. The protocol conversion module parses RTPS packets and converts them into soft bus messages, while the data mapping module defines mapping rules through a fixed configuration file, mapping DDS topics to soft bus service identifiers (Service IDs).

[0004] In existing solutions, bridges are typically custom-developed for specific protocols (such as DDS), employing hard-coded protocol parsing logic. This makes it difficult to support other publish-subscribe protocols, such as Message Queuing Telemetry Transport (MQTT) and Advanced Message Queuing Protocol (AMQP), and the lack of an extensible plug-in mechanism results in poor versatility. Due to the lack of a unified intermediate data representation and efficient mapping mechanism, the process of converting RTPS packets into soft bus messages involves multiple serialization and deserialization operations, with an average latency of 5ms-10ms. This low protocol conversion efficiency fails to meet real-time requirements. Furthermore, the lack of a unified subscription management data structure and the failure to effectively maintain the dynamic mapping relationship between topics and sessions leads to complex and inefficient subscription management for subscription update operations (such as adding or canceling subscriptions). In addition, the lack of a modular protocol management architecture prevents the dynamic addition of new protocols or services, requiring modification of the bridge code and redeployment, which limits the system's scalability. Summary of the Invention

[0005] To address the above technical problems, this invention provides a middleware system based on a general publish-subscribe pattern and interaction with a soft bus.

[0006] The technical problem solved by this invention can be achieved by the following technical solutions: A middleware system based on a general publish-subscribe pattern and interacting with a soft bus includes: The protocol plugin management module is used to dynamically load protocol plugins based on configuration files; The soft bus interaction module is used to create a session service based on the published / subscribed request message received from the device. The session service calls the loaded protocol plugin according to the message type. The protocol plugin processes the data distribution service message according to the protocol corresponding to the protocol plugin and generates a first message. The message structure management module, connected to the protocol plugin management module, is used to convert the first message into a unified predefined message format and generate the second message. The data mapping module, connected to the message structure management module, is used to maintain the mapping relationship between topics and sessions according to the second message, and to map topics to sessions according to the mapping relationship between topics and sessions, so that the publish / subscribe request message is routed to the corresponding session; The session management module is connected to the soft bus interaction module and the data mapping module respectively. It is used to maintain the session identifier and generate a message scheduling request when opening or closing a session associated with the session service. A real-time scheduling engine, connected to the protocol plugin management module and the session management module respectively, is used to process the message scheduling request according to the priority queue and generate scheduling results; The session management module is used to return message sending / receiving feedback information to the device based on the scheduling results.

[0007] Preferably, the protocol plugin management module includes: The configuration file loading unit is used to read configuration files and parse plugin names and paths; The plugin dynamic loading unit, connected to the configuration file loading unit, is used to load protocol plugins according to the dynamic link library and create plugin instances; The plugin initialization unit, connected to the plugin dynamic loading unit, is used to initialize the loaded plugin instance according to the configuration parameters in the configuration file; The plugin instantiation management unit, connected to the plugin initialization unit, is used to store plugin instances in the internal mapping of the plugin manager and record the loading status of protocol plugins.

[0008] Preferably, the protocol plugin management module is also used to manage the lifecycle of the protocol plugin.

[0009] Preferably, the soft bus interaction module includes: The information release configuration unit is used to construct the information release structure and initialize the structure members, which include the release identifier, release mode, communication medium, frequency, capability name, capability data pointer, and data length. The publish callback creation unit is used to allocate a new publish callback object when the publish callback object pointer is null, define the publish result callback function, and record the publish result; The publishing unit is used to call the publishing capability function, passing in the publishing identifier, a pointer to the publishing information structure, and a pointer to the publishing callback object. It records the return value of the publishing capability function, releases the pointer memory, and resets the publishing callback object pointer to a null pointer. The session service creation unit is used to call the session service creation function, passing in the publication identifier, session name and pointer to the publication listener. If the creation of the session service fails, an error log of the failure to create the session service is recorded. The plugin loading unit is used to call the plugin manager, load plugins according to the paths in the configuration file, and record error logs when loading fails. The subscription mapping initialization unit is used to clear the subscription mapping table in order to receive new subscriptions.

[0010] Preferably, the message structure management module includes: A message type definition unit is used to define message types, including subscription messages, unsubscribe messages, publish messages, and error messages; The serialization topic list unit is used to define the serialization function, which iterates through each element in the string vector in turn. If it is not the first element in the string vector, a delimiter is added to the output stream, each element is added to the output stream, the content in the output stream is converted into a string, and a second message containing the serialized topic list is returned. The deserialization topic list unit is used to define deserialization functions, record log information of the input string, parse the input string, split the input string according to the delimiter, add the split substrings to the string vector, and return a second message containing the deserialization topic list.

[0011] Preferably, the data mapping module includes: The subscription message processing unit is used to receive a session identifier and a list of topics, traverse each topic in the topic list, check whether there is a corresponding topic in the subscription mapping table, add the session identifier to the session identifier vector corresponding to the topic if there is a corresponding topic, add the vector corresponding to the session identifier to the subscription mapping table if there is no corresponding topic, and output a notification message that a new topic has been subscribed to to the protocol plugin. The unsubscribe processing unit is used to receive a session identifier and a list of topics, traverse each topic in the topic list, check whether the session identifier vector corresponding to the topic in the subscription mapping table exists, and if the session identifier exists, remove the session identifier from the session identifier vector and update the session identifier vector.

[0012] Preferably, the unsubscribe processing unit is further configured to remove the topic corresponding to the session identifier vector from the subscription mapping table when it detects that the updated session identifier vector is empty, and output a notification message of unsubscribing from the topic to the protocol plugin.

[0013] Preferably, it further includes: The fault tolerance and monitoring module is connected to the session management module, the data mapping module, and the protocol plugin management module, respectively. It is used to monitor the running status of the protocol plugin and update the plugin status information; monitor the subscription update status of the data mapping module and update the subscription status synchronously; and detect the heartbeat signal of the soft bus. When a heartbeat failure is detected in the soft bus, it notifies the session management module to update the session information.

[0014] Preferably, the protocol plugin includes one or more combinations of a distributed data service plugin, a message queue telemetry transport protocol plugin, or an advanced message queue protocol plugin.

[0015] Preferably, the predefined message format includes a JavaScript object representation format and a protocol buffer format.

[0016] The advantages or beneficial effects of the technical solution of this invention are as follows: This invention supports multiple protocols through a plug-in mechanism, interacts efficiently with the device's soft bus, utilizes the soft bus's publishing capabilities to create session services, and adopts a general message structure to achieve low-latency, high-reliability, and efficient heterogeneous system communication, meeting the needs of IoT and industrial control scenarios. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the architecture of a middleware system based on a general publish-subscribe pattern and interacting with a soft bus, which is a preferred embodiment of the present invention. Detailed Implementation

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

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0020] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0021] In a preferred embodiment of the present invention, based on the aforementioned problems of lack of universality, low protocol conversion efficiency, complex subscription management, and insufficient scalability in the prior art, a middleware system based on a universal publish-subscribe pattern and interaction with a soft bus is provided. This system runs on a general Linux system 10, such as the openEuler operating system, with the Linux system 10 providing the operating environment for the system of the present invention. It supports multiple protocols through a plug-in mechanism, manages the publish-subscribe protocol using a universal plug-in interface, and interacts efficiently with the OpenHarmony device soft bus of the open-source Harmony OS. It utilizes the software development kit (SDK) publishing capabilities of the OpenHarmony device soft bus and creates session services, adopting a universal message structure such as JSON format to achieve low-latency, high-reliability, and efficient heterogeneous system communication, meeting the needs of IoT and industrial control scenarios.

[0022] like Figure 1 As shown, the middleware system includes: Protocol plugin management module 1 is used to dynamically load protocol plugin 30 according to the configuration file; The soft bus interaction module 2 is used to create a session service based on the publish / subscribe request message received from the device 20. The session service calls the loaded protocol plugin 30 according to the message type. The protocol plugin 30 processes the data distribution service message according to the protocol corresponding to the protocol plugin 30 and generates a first message. The first message includes the configured domain identifier and topic. The message structure management module 3 and the connection protocol plugin management module 1 are used to convert the first message into a unified predefined message format and generate the second message; wherein, the second message includes a topic name, a domain identifier and data content; The data mapping module 4 is connected to the message structure management module 3. It is used to maintain the mapping relationship between topics and sessions according to the second message, and to map topics to sessions according to the mapping relationship between topics and sessions, so that publish / subscribe request messages are routed to the corresponding sessions. The session management module 5 is connected to the soft bus interaction module 2 and the data mapping module 4 respectively. It is used to maintain the session identifier and generate message scheduling requests when opening or closing a session associated with the session service. The real-time scheduling engine 6 is connected to the protocol plugin management module 1 and the session management module 5 respectively, and is used to process message scheduling requests according to the priority queue and generate scheduling results. The session management module 5 is used to return message sending / receiving feedback information to the device based on the scheduling results.

[0023] Specifically, the protocol plugin management module 1 defines a C++ interface class that includes methods for initializing plugins, publishing messages, subscribing to topics, unsubscribing, and closing plugins. During program initialization, protocol plugin 30 is dynamically loaded via a dynamic link library based on the plugin path specified in the configuration file, and the entire lifecycle of the plugin is managed.

[0024] Protocol plugin 30 can use the FastDDS plugin. The FastDDS plugin processes DDS messages through the Real-time Publish-Subscribe (RTPS) protocol, enabling the configuration of domain IDs and topics, and also supports the configuration of Quality of Service (QoS) policies.

[0025] Furthermore, the protocol plugin management module 1 can also support dynamic expansion to new protocols. For example, it can be extended to protocol plugins such as Message Queuing Telemetry Transport (MQTT) and Advanced Message Queuing Protocol (AMQP) 30. By adopting a general interface to decouple the protocol implementation, the problem of the lack of universality in existing technologies is solved.

[0026] The soft bus interaction module 2 publishes DDS capabilities and creates session services through the soft bus interface. This service is used to process publish and subscribe request messages from the soft bus applications on the OpenHarmony device 20 side, enabling seamless interaction between OpenHarmony applications and middleware, and solving the problem that existing technologies cannot effectively integrate the soft bus.

[0027] Received messages are processed through callback methods registered with the Session service. After parsing the message, the corresponding predefined interface of Protocol Plugin Management Module 1 is called according to the message type to perform operations such as publishing and subscribing.

[0028] The message structure management module 3 defines a general message structure, which includes a topic name, domain ID, and data content. By unifying the message format, the protocol conversion and data mapping process can be simplified, efficiency can be improved, and the problem of high conversion latency in existing technologies can be solved.

[0029] For example, the format for publishing a message is as follows: { "msgType": "Publish", "topic": "SensorData", "domainId": 0, "data": {"temperature": 25.5, "timestamp": 1698765432} } For example, the format of the subscription message is: { "msgType": "Subscribe", "topics": "SensorData,ControlCmd", "domainId": 0 } Data mapping module 4 is used to maintain the mapping relationship between sessions and topics, dynamically associate sessions, and improve the efficiency of message forwarding and querying.

[0030] The session management module 5 is associated with the data mapping module. When a session associated with the session service is opened or closed, the ID value of each session is maintained.

[0031] The real-time scheduling engine 6 uses priority queues to manage message transmission tasks, combines a timestamp mechanism to optimize real-time performance, and supports QoS policies such as reliability and latency budget. This engine ensures low-latency transmission of high-priority messages, meeting real-time requirements. High-priority messages (such as sensor data) are processed first, with latency budget controlled within 10ms.

[0032] This invention's system leverages the universality of its plug-in mechanism, enabling flexible adaptation to plug-ins from different protocols. The message structure management module 3 implements a unified, universal message structure, while the interaction between the data mapping module 4 and the session management module 5 achieves dynamic subscription management. This invention enhances the system's scalability and efficiency through dynamic plug-in loading and real-time subscription updates.

[0033] In a preferred embodiment, the protocol plug-in management module 1 includes: The configuration file loading unit is used to read configuration files and parse plugin names and paths; The plugin dynamic loading unit and the connection configuration file loading unit are used to load the protocol plugin 30 according to the dynamic link library and create plugin instances; The plugin initialization unit connects to the plugin dynamic loading unit and is used to initialize the loaded plugin instance according to the configuration parameters in the configuration file. The plugin instantiation management unit and the plugin initialization unit are used to store plugin instances in the internal mapping of the plugin manager and record the loading status of protocol plugin 30.

[0034] Specifically, the protocol plugin management module 1 is responsible for defining general plugin interfaces and dynamically loading protocol plugins, and initializing plugin instances through configuration files.

[0035] The specific processing procedure of Protocol Plug-in Management Module 1 is as follows: Define the plugin interface: Create a C++ abstract class Plugin, and declare virtual functions: ~Plugin() (virtual destructor), initialize(const std::string& config) (initialization), publish(const std::string& topic, const std::string& data) (publish message), subscribe(const std::string& topic) (subscribe to topic), unsubscribe(const std::string& topic) (unsubscribe), and shutdown() (shutdown plugin).

[0036] Use `extern "C"` to export the `createPlugin()` and `destroyPlugin()` functions for dynamically instantiating and destroying plugin objects.

[0037] Load configuration file: Read the configuration file . / config / plugins.xml, parse the plugin name and path, such as the path to the .so file of the FastDDS plugin.

[0038] Dynamically load plugins: Call dlopen to open the dynamic link library (.so file) and load the plugin module; use dlsym to get the createPlugin function pointer and call it to create a Plugin instance.

[0039] Initialize plugin: Call the initialize method on the loaded plugin instance, passing in the parameters from the configuration file, such as the RTPS configuration of FastDDS.

[0040] Manage plugin instantiation: Store plugin instances in the internal mapping (name -> Plugin*) of PluginManager and record the loading status.

[0041] Error handling: If loading fails (loadPluginsFromConfig returns false), log the error (FRAME_LOGE), but allow the program to continue running to support some plugin failure scenarios.

[0042] Compared to traditional plugin loading (such as Apache modules or some DDS bridges), which typically uses static linking or pre-compiled plugin frameworks, plugins need to be specified at compile time, and loading depends on fixed configuration files or code modifications. For example, existing DDS bridges may load FastDDS modules through hard-coded library paths, lacking dynamic extensibility. In contrast, the protocol plugin management module 1 of this embodiment supports runtime plugin loading and unloading without requiring a system restart or recompilation. Dynamic calls to dlopen and dlsym replace static linking, and the plugins.xml configuration file allows for updates to the plugin list at any time. The plugin interface abstracts protocol details (such as FastDDS's RTPS or MQTT's Paho), offering greater versatility and cross-protocol extension support compared to existing protocol-specific interfaces. Secure plugin unloading is achieved through the shutdown method; existing technologies often do not support hot-swapping, requiring system downtime for maintenance. Plugins are completely decoupled from the core middleware; existing technologies often embed plugin logic into the main program, requiring adjustments to the main code to modify plugins.

[0043] In a preferred embodiment, the protocol plugin management module 1 is also used to manage the lifecycle of the protocol plugin 30.

[0044] In a preferred embodiment, the soft bus interaction module 2 includes: The information release configuration unit is used to construct the information release structure and initialize the structure members, which include the release identifier, release mode, communication medium, frequency, capability name, capability data pointer, and data length. The publish callback creation unit is used to allocate a new publish callback object when the publish callback object pointer is null, define the publish result callback function, and record the publish result; The publishing unit is used to call the publishing capability function, passing in the publishing identifier, a pointer to the publishing information structure, and a pointer to the publishing callback object. It records the return value of the publishing capability function, releases the pointer memory, and resets the publishing callback object pointer to a null pointer. The session service creation unit is used to call the session service creation function, passing in the publication identifier, session name and pointer to the publication listener. If the creation of the session service fails, an error log of the failure to create the session service is recorded. The plugin loading unit is used to call the plugin manager, load plugins according to the paths in the configuration file, and record error logs when loading fails. The subscription mapping initialization unit is used to clear the subscription mapping table in order to receive new subscriptions.

[0045] Specifically, the softbus interaction module 2 initializes the softbus service, publishes capabilities, and creates a Session service through SoftBusClient::init_softbus.

[0046] The specific processing procedure of the soft bus interaction module 2 is as follows: Initialize variables: Declare the return value ret and initialize it to SOFTBUS_OK, create an IPublishCb pointer cb and initialize it to nullptr.

[0047] Configure publishing information: Construct a PublishInfo structure, setting publisherId = 100, mode = DISCOVER_MODE_ACTIVE, medium = COAP, freq = LOW, capability = "ddsCapability", capabilityData = nullptr, and dataLen = 0. Create a publish callback: If cb is nullptr, allocate a new IPublishCb object, define the OnPublishResult lambda function, and record the publish result (FRAME_LOGW). Publish Capability: Call PublishLNN(DDS_PUBLISH_NAME, &info, cb) to publish the "ddsCapability" service, record the return value ret; release cb memory (delete cb), and reset cb to nullptr.

[0048] Create a Session service: Call CreateSessionServer(DDS_PUBLISH_NAME, DDS_TO_DSOFTBUS_SESSION_NAME, &publishListener) to create the “dds-publish” Session service and register a publishListener to handle events.

[0049] If ret != SOFTBUS_OK, log the error (FRAME_LOGE).

[0050] Call CreateSessionServer(DDS_PUBLISH_NAME, DSOFTBUS_TO_DDS_SESSION_NAME, &subscribeListener) to create the “dds-subscribe” Session service and register the subscribeListener.

[0051] Load plugins: Call g_pluginManager.loadPluginsFromConfig(". / config / plugins.xml") to load plugins. If it fails, log the process but continue running.

[0052] Initialize subscription mapping: Call subscription_map_.clear() to clear the subscription mapping table and prepare to receive new subscriptions.

[0053] In a preferred embodiment, the message structure management module 3 includes: The message type definition unit is used to define message types, which include subscribe messages, unsubscribe messages, publish messages, and error messages; The serialization topic list unit is used to define the serialization function, which iterates through each element in the string vector in turn. If it is not the first element in the string vector, a delimiter is added to the output stream, each element is added to the output stream, the content in the output stream is converted into a string, and a second message containing the serialized topic list is returned. The deserialization topic list unit is used to define deserialization functions, record log information of the input string, parse the input string, split the input string according to the delimiter, add the split substrings to the string vector, and return a second message containing the deserialization topic list.

[0054] Specifically, the message structure management module 3 defines a message type enumeration and provides serialization / deserialization functions to handle the conversion of the topic list.

[0055] The specific processing procedure of message structure management module 3 is as follows: Define message type: Declare enumeration DDSMsgType, which includes SUBSCRIBE_TYPE (0), UNSUBSCRIBE_TYPE (1), PUBLISH_TYPE (2), and ERROR_TYPE (4).

[0056] For serializing a list of topics: First, define the function `serializeSimple(const std::vector<st ... <std::string>& vec, char delimiter = ','); initialize std::ostringstream oss; iterate through vec, adding the delimiter (default ',') to each non-first element, and append each string to oss; return oss.str() as the serialized result.

[0057] For deserializing the list of topics: First, define the function `deserializeSimple(const std::string& s, char delimiter = ',')`; log the input string (FRAME_LOGI); initialize an empty `std::vector`. <std::string>vec; Parse the input string using std::istringstream iss(s); Loop through std::getline(iss, token, delimiter) and add the token separated by each delimiter to vec; Return vec as the deserialized result.

[0058] JSON, as a lightweight data exchange format, is widely used in distributed systems such as MQTT and REST APIs. In existing technologies, DDS bridges may use JSON for data serialization, but these typically use statically defined fields, lacking cross-protocol uniformity and dynamic adaptability. The message structure management module 3 of this embodiment adopts a unified message format, defining a general JSON format that includes msgType (Publish / Subscribe), topic, and data fields, supporting multiple publish-subscribe protocols.

[0059] Compared to the static JSON model where fields need to be predefined, this invention enables dynamic field mapping. The nlohmann::json library supports dynamic parsing of JSON fields, allowing the data content to be expanded at runtime, such as adding new sensor data.

[0060] In a preferred embodiment, the data mapping module 4 includes: The subscription message processing unit is used to receive the session identifier and the topic list, traverse each topic in the topic list, check whether the corresponding topic exists in the subscription mapping table, if the corresponding topic exists, add the session identifier to the session identifier vector corresponding to the topic, if the corresponding topic does not exist, add the vector corresponding to the session identifier to the subscription mapping table, and output the notification information of the new topic subscription to the protocol plugin 30. Specifically, the processing procedure for subscription messages (update_subscriptions) is as follows: Input parameters: session_id (integer), topic_list (topic vector).

[0061] Initialize std::vector <int>values contains session_id.

[0062] Lock the mutex mutex_.lock().

[0063] Log (FRAME_LOGI) and print the current subscription_map_ state.

[0064] Iterate over topic_list: Check if the topic exists (subscription_map_.contains(topic)).

[0065] If not, insert a new mapping with subscription_map_.insert(topic, values) and notify the plugins with PluginsSubscribe(topic).

[0066] If so, append the session ID with subscription_map_.append(topic, session_id).

[0067] Log the updated state and print the subscription_map_ state.

[0068] Unlock the mutex mutex_.unlock().

[0069] As a preferred embodiment, the data mapping module 4 comprises: An unsubscription processing unit, configured to receive a session identifier and a topic list, iterate over each topic in the topic list, detect whether the session identifier exists in a session identifier vector corresponding to the topic in a subscription mapping table, and remove the session identifier from the session identifier vector and update the session identifier vector when the session identifier exists.

[0070] As a preferred embodiment, the unsubscription processing unit is further configured to remove the topic corresponding to the session identifier vector from the subscription mapping table when it is detected that the updated session identifier vector is empty, and output notification information of the unsubscription of the topic to the protocol plug-in 30.

[0071] Specifically, the specific processing procedure of the unsubscription processing (update_unsubscriptions) is as follows: Input parameters: session_id (integer), topic_list (topic vector).

[0072] Lock the mutex mutex_.lock().

[0073] Log the FRAME_LOGI and print the current subscription_map_ status.

[0074] Iterate through topic_list: Get the list of sessions for the topic (subscription_map_.getSafe(topic)).

[0075] If the list is empty or does not contain session_id, skip the current topic.

[0076] Otherwise, remove the session_id (using std::remove and erase).

[0077] If the list is empty, call subscription_map_.remove(topic) to delete the mapping and call PluginsUnSubscribe(topic) to notify the plugin.

[0078] Otherwise, call subscription_map_.replace(topic, sessions) to update the mapping.

[0079] Record the update log and print the subscription_map_status.

[0080] Release the mutex using mutex_.unlock().

[0081] Data mapping module 4 manages the subscription mapping table through SoftBusClient and handles dynamic updates for subscriptions and unsubscriptions.

[0082] Traditional subscription management (such as DDS bridges) typically uses static subscription tables or databases, with subscription relationships initialized at startup and updates requiring manual configuration or system restarts. For example, defining topic-subscriber mappings through configuration files lacks real-time performance. In contrast, this invention implements dynamic subscription management, offering real-time performance. The `subscription_map` supports dynamic addition or deletion of subscriptions at runtime, with an update latency of <0.5ms, representing a 75%-90% improvement compared to the 2-5ms of existing technologies.

[0083] Compared to existing technologies that mostly rely on manual maintenance of subscription tables, this invention achieves automatic cleanup by triggering deleteSession onOnSessionClosed.

[0084] Compared to existing technologies where subscription management and the protocol layer are separated and lack dynamic linkage, this invention achieves synchronous updates of the protocol layer subscription through plugin collaboration, using PluginsSubscribe / PluginsUnSubscribe to interact with plugins.

[0085] Compared to existing technologies that use broadcast or single-point forwarding, which are inefficient, this invention combines findSessionsByTopic and publish_message to achieve multi-point distribution by topic, enabling efficient routing.

[0086] Existing technologies are limited by static configuration and have poor scalability. This invention supports large-scale theme management, such as 1000+ themes, and has good scalability.

[0087] In a preferred embodiment, it further includes: The fault tolerance and monitoring module 7 is connected to the session management module 5, the data mapping module 4, and the protocol plug-in management module 1, respectively. It is used to monitor the running status of the protocol plug-in 30 and update the plug-in status information; monitor the subscription update status of the data mapping module 4 and update the subscription status synchronously; and detect the heartbeat signal of the soft bus. When a heartbeat failure is detected in the soft bus, it notifies the session management module 5 to update the session information.

[0088] Specifically, the fault tolerance and monitoring module 7 monitors the entire process and updates the subscription and plugin status. For example, it detects faults through heartbeat detection on the soft bus and notifies the session management module to update session information; it also supports logging to ensure system reliability.

[0089] In a preferred embodiment, the protocol plugin 30 includes one or more combinations of a distributed data service (FastDDS) plugin, a message queue telemetry transport protocol (MQTT) plugin, or an advanced message queue protocol (AMQP) plugin.

[0090] Specifically, FastDDS plugins are extended functional components developed based on FastDDS. FastDDS is a high-performance, open-source Data Distribution Service (DDS) implementation that follows the DDS standard defined by the OMG (Object Management Group). These plugins can add additional features to the FastDDS system, such as specific data processing logic, integration capabilities with other systems, and support for customized communication protocols, to meet the diverse data distribution and communication needs in different application scenarios.

[0091] In addition to the FastDDS plugin, MQTT or AMQP plugins can also be developed, with the interface remaining consistent; only the protocol implementation needs to be replaced.

[0092] MQTT plugins are plugins developed to enhance the functionality of MQTT-related systems. MQTT is a lightweight messaging protocol based on a publish / subscribe model, designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. It is widely used in the Internet of Things (IoT), industrial monitoring, smart homes, and other fields. For example, when integrating MQTT communication functionality into certain applications, using MQTT plugins can simplify the development process of MQTT clients, provide more configuration options, or enable interaction with other systems, such as storing MQTT messages in a database or triggering specific business logic.

[0093] AMQP plugins are components that extend the functionality of systems that support the AMQP protocol. AMQP is an open standard application-layer messaging protocol used for message passing and queue management in distributed systems. AMQP provides a reliable, secure, and efficient message transmission mechanism, supports various message models and interaction modes, and is widely used in enterprise application development, financial trading systems, and other fields. For example, using AMQP plugins in message middleware can implement advanced functions such as message filtering, transformation, and routing, or integrate with other systems to meet the message processing needs of complex business scenarios.

[0094] In a preferred embodiment, the predefined message format includes JavaScript Object Notation (JSON) format and protocol buffer format.

[0095] Specifically, JSON is a lightweight data-interchange format that is easy for humans to read and write, and also easy for machines to parse and generate. JSON uses a text format that is completely independent of programming languages ​​to store and represent data, making it widely used in internet application development for transferring and storing data between different systems, such as front-end and back-end data exchange.

[0096] Furthermore, to better suit high-throughput scenarios, the JSON message format can be replaced with Protobuf to reduce serialization overhead. Protobuf is an open-source data serialization format and mechanism used for efficient serialization and deserialization of structured data. Protobuf uses a .proto file to define the data structure and a specific compiler to generate code in the corresponding programming language, serializing the data into a binary format. Compared to text formats like JSON, Protobuf has significant advantages in data transmission efficiency and data size reduction, and is often used in performance-critical scenarios such as distributed systems and network communication.

[0097] The workflow of this invention's system is as follows: OpenHarmony device 20 sends a subscription / publish request to soft bus interaction module 2, creating a session service and triggering session management module 5. Message structure management module 3 generates uniformly formatted messages. Data mapping module maintains the mapping relationship between topics and sessions according to the data mapping rules output by message structure management module 3, and maps topics to sessions according to the mapping relationship, collaborating with session management module 5 to implement message routing. Real-time scheduling engine 6 allocates priorities, optimizes message priorities and latency. Protocol plugin management module 1 dynamically loads protocol plugins 30 (such as FastDDS). The plugin processes messages and generates message formats, connecting to message structure management module 3 and real-time scheduling engine 6.

[0098] The system of the present invention adopting the above technical solution has the following advantages or beneficial effects: Through a unified JSON message structure and efficient session management, the average latency of protocol conversion is reduced to 1.8ms, a 60%-80% reduction compared to the 5-10ms latency of existing technologies. This is thanks to serialization optimization and efficient processing of topic lists, which significantly improves real-time performance and meets the millisecond-level response requirements in smart home and industrial IoT scenarios.

[0099] The system supports processing 1200 messages per second, which is 50%-140% higher than traditional bridging solutions (approximately 500-800 messages / second). Through dynamic loading of protocol plugin 30 and asynchronous session management, the system achieves high-concurrency message processing and is suitable for high-frequency data transmission scenarios, such as sensor networks and real-time control systems.

[0100] It operates continuously for 24 hours without data loss, achieving a reliability of 99.95%, which is superior to existing technologies (approximately 99%). Through a soft bus heartbeat detection and retransmission mechanism, combined with dynamic updates to subscription mapping, communication stability is ensured, and the risk of data loss is reduced.

[0101] The C++ plugin interface (Plugin class) supports dynamic loading of protocol plugins 30, allowing protocol extensions to be implemented without modifying the core code. Compared to existing hard-coding solutions, the plugin mechanism reduces the adaptation time for new protocols from weeks to days, significantly improving scalability.

[0102] The middleware system of this invention promotes standardized interaction between publish-subscribe protocols (such as DDS) and the OpenHarmony soft bus through a universal plug-in interface and a unified message structure, providing a unified communication framework for the Internet of Things, Industrial Internet and smart home fields, and helping to reduce the problem of protocol fragmentation within the industry.

[0103] By supporting the publish-subscribe capability of OpenHarmony applications, the system enhances the interoperability between the OpenHarmony ecosystem and external systems, and promotes cross-platform collaboration of smart devices, such as the linkage between smart home devices and industrial control systems.

[0104] The plugin mechanism allows developers to reuse core middleware; only 30 protocol plugins need to be developed to support new protocols, which is expected to save 30%-50% of development time and costs. For example, the development cycle for adapting MQTT plugins is shortened from 4-6 weeks in the traditional approach to 1-2 weeks.

[0105] Dynamically loading plugins and configuration files supports hot deployment, eliminating the need for downtime to update protocols and reducing system maintenance costs by approximately 20%. This is especially important for IoT systems that require frequent updates.

[0106] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.< / int> < / std::string> < / std::string>

Claims

1. A middleware system based on a general publish-subscribe pattern and interacting with a soft bus, characterized in that, include: The protocol plugin management module is used to dynamically load protocol plugins based on configuration files; The soft bus interaction module is used to create a session service based on the published / subscribed request message received from the device. The session service calls the loaded protocol plugin according to the message type. The protocol plugin processes the data distribution service message according to the protocol corresponding to the protocol plugin and generates a first message. The message structure management module, connected to the protocol plugin management module, is used to convert the first message into a unified predefined message format and generate the second message. The data mapping module, connected to the message structure management module, is used to maintain the mapping relationship between topics and sessions according to the second message, and to map topics to sessions according to the mapping relationship between topics and sessions, so that the publish / subscribe request message is routed to the corresponding session; The session management module is connected to the soft bus interaction module and the data mapping module respectively. It is used to maintain the session identifier and generate a message scheduling request when opening or closing a session associated with the session service. A real-time scheduling engine, connected to the protocol plugin management module and the session management module respectively, is used to process the message scheduling request according to the priority queue and generate scheduling results; The session management module is used to return message sending / receiving feedback information to the device based on the scheduling results.

2. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The protocol plugin management module includes: The configuration file loading unit is used to read configuration files and parse plugin names and paths; The plugin dynamic loading unit, connected to the configuration file loading unit, is used to load protocol plugins according to the dynamic link library and create plugin instances; The plugin initialization unit, connected to the plugin dynamic loading unit, is used to initialize the loaded plugin instance according to the configuration parameters in the configuration file; The plugin instantiation management unit, connected to the plugin initialization unit, is used to store plugin instances in the internal mapping of the plugin manager and record the loading status of protocol plugins.

3. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The protocol plugin management module is also used to manage the lifecycle of the protocol plugin.

4. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The soft bus interaction module includes: The information release configuration unit is used to construct the information release structure and initialize the structure members, which include the release identifier, release mode, communication medium, frequency, capability name, capability data pointer, and data length. The publish callback creation unit is used to allocate a new publish callback object when the publish callback object pointer is null, define the publish result callback function, and record the publish result; The publishing unit is used to call the publishing capability function, passing in the publishing identifier, a pointer to the publishing information structure, and a pointer to the publishing callback object. It records the return value of the publishing capability function, releases the pointer memory, and resets the publishing callback object pointer to a null pointer. The session service creation unit is used to call the session service creation function, passing in the publication identifier, session name and pointer to the publication listener. If the creation of the session service fails, an error log of the failure to create the session service is recorded. The plugin loading unit is used to call the plugin manager, load plugins according to the paths in the configuration file, and record error logs when loading fails. The subscription mapping initialization unit is used to clear the subscription mapping table in order to receive new subscriptions.

5. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The message structure management module includes: A message type definition unit is used to define message types, including subscription messages, unsubscribe messages, publish messages, and error messages; The serialization topic list unit is used to define the serialization function, which iterates through each element in the string vector in turn. If it is not the first element in the string vector, a delimiter is added to the output stream, each element is added to the output stream, the content in the output stream is converted into a string, and a second message containing the serialized topic list is returned. The deserialization topic list unit is used to define deserialization functions, record log information of the input string, parse the input string, split the input string according to the delimiter, add the split substrings to the string vector, and return a second message containing the deserialization topic list.

6. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The data mapping module includes: The subscription message processing unit is used to receive a session identifier and a list of topics, traverse each topic in the topic list, check whether there is a corresponding topic in the subscription mapping table, add the session identifier to the session identifier vector corresponding to the topic if there is a corresponding topic, add the vector corresponding to the session identifier to the subscription mapping table if there is no corresponding topic, and output a notification message that a new topic has been subscribed to to the protocol plugin. The unsubscribe processing unit is used to receive a session identifier and a list of topics, traverse each topic in the topic list, check whether the session identifier vector corresponding to the topic in the subscription mapping table exists, and if the session identifier exists, remove the session identifier from the session identifier vector and update the session identifier vector.

7. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 6, characterized in that, The unsubscribe processing unit is also used to remove the topic corresponding to the session identifier vector from the subscription mapping table when it detects that the updated session identifier vector is empty, and output a notification message of unsubscribing from the topic to the protocol plugin.

8. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, Also includes: The fault tolerance and monitoring module is connected to the session management module, the data mapping module and the protocol plugin management module respectively, and is used to monitor the running status of the protocol plugin and update the plugin status information. Monitor the subscription update status of the data mapping module and update the subscription status synchronously. It also detects the heartbeat signal of the soft bus and notifies the session management module to update the session information when a heartbeat failure is detected on the soft bus.

9. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The protocol plugins include one or more combinations of distributed data service plugins, message queue telemetry transport protocol plugins, or advanced message queue protocol plugins.

10. The middleware system based on a general publish-subscribe pattern and soft bus interaction as described in claim 1, characterized in that, The predefined message formats include JavaScript object representation format and protocol buffer format.

Images