Message routing method and apparatus for internet of things device, electronic device, and program product

Abstract

The application is suitable for the technical field of Internet of Things, and provides a message routing method and device of Internet of Things equipment, electronic equipment and program product. The message routing method of Internet of Things equipment comprises the following steps: obtaining a to-be-routed message sent by Internet of Things equipment; the to-be-routed message comprises device model information, message type information and a target service identifier; determining a target listener corresponding to the to-be-routed message according to the device model information; determining a target strategy factory component corresponding to the to-be-routed message according to the message type information through the target listener; and determining a target message processing strategy corresponding to the to-be-routed message according to the target service identifier through the target strategy factory component. Through the scheme, the maintenance cost of the message routing method of Internet of Things equipment can be reduced, and the convenience of the message routing of Internet of Things equipment is improved.

Description

Technical Field

[0001] This application belongs to the field of Internet of Things (IoT) technology, and particularly relates to a message routing method, apparatus, electronic device, and program product for IoT devices. Background Technology

[0002] IoT device access platforms need to handle heterogeneous communication protocols and data formats from multiple vendors and device models. Traditional message routing mechanisms generally rely on conditional branching statements, such as using if-else or switch structures at the message entry point to distribute messages based on device model. This approach results in lengthy and complex code structures, significantly reducing maintainability. Adding a new device model requires modifying the core routing logic, easily introducing regression defects, and thus is difficult to maintain. While the static factory pattern centrally manages the mapping between device models and processors, the factory class needs to hard-code logic for all models, and adding a new model still violates the open / closed principle, making it difficult to maintain. Message queue routing technology is suitable for inter-service communication scenarios, but it lacks flexibility for fine-grained routing within services and cannot distinguish between different message types from the same device, resulting in mixed processing of different business messages from the same device, making it difficult to maintain.

[0003] It can be seen that the message routing methods for IoT devices in the existing technology are difficult to maintain, which ultimately reduces the convenience of message routing for IoT devices. Summary of the Invention

[0004] In view of this, embodiments of this application provide a message routing method, apparatus, electronic device, and program product for Internet of Things (IoT) devices to solve the technical problem of low convenience caused by the difficulty in maintaining message routing methods for IoT devices in the prior art.

[0005] In a first aspect, embodiments of this application provide a message routing method for an Internet of Things (IoT) device, including: Obtain the message to be routed sent by the IoT device; the message to be routed includes device model information, message type information, and target service identifier; Based on the device model information, determine the target listener corresponding to the message to be routed; The target listener determines the target policy factory component corresponding to the message to be routed based on the message type information. The target policy factory component determines the target message processing policy corresponding to the message to be routed based on the target service identifier.

[0006] Optionally, before determining the target listener corresponding to the message to be routed based on the device model information, the method further includes: The message to be routed is parsed, and the parsed message to be routed is encapsulated using a preset message model to obtain the encapsulated message to be routed.

[0007] Optionally, determining the target listener corresponding to the message to be routed based on the device model information includes: The encapsulated message to be routed is published to the Spring Event Bus to instruct each listener associated with the Spring Event Bus to perform the following process: based on the encapsulated message to be routed, obtain the device model information, and based on the device model information and the target device model corresponding to the listener, determine whether the listener is the target listener.

[0008] Optionally, the message type information is a data reporting type or an event reporting type; determining the target policy factory component corresponding to the message to be routed based on the message type information includes: If the message type information is a data reporting type, then the first policy factory component is determined as the target policy factory component; the first policy factory component is used to determine the message processing policy corresponding to the message to be routed of the data reporting type. If the message type information is an event reporting type, then the second policy factory component is determined as the target policy factory component; the second policy factory component is used to determine the message processing policy corresponding to the message to be routed of the event reporting type.

[0009] Optionally, determining the target message processing policy corresponding to the message to be routed based on the target service identifier through the target policy factory component includes: The target identification key corresponding to the message to be routed is determined by the target policy factory component based on the target service identifier. Match the target Bean component corresponding to the target identifier key from the key-value mapping set; the key-value mapping set includes several Bean components, each Bean component records the corresponding identifier key and message processing strategy; The message processing strategy recorded by the target Bean component is determined as the target message processing strategy.

[0010] Optionally, the key-value map set is created in the following way: Using the Spring container, strategy implementation class components with arbitrary service identifiers are scanned out. For each strategy implementation class component, a corresponding Bean component is constructed based on the identifier key and message processing strategy recorded by the strategy implementation class component, and the corresponding Bean component is stored in the key-value mapping set.

[0011] Optionally, the message to be routed may further include service data payload or event content data; after determining the target message processing strategy corresponding to the message to be routed, the method further includes: The target message processing strategy is used to process the business data payload or the event content data.

[0012] Secondly, embodiments of this application provide a message routing device for an Internet of Things (IoT) device, comprising: The message acquisition unit is used to acquire unroutable messages sent by IoT devices; the unroutable messages include device model information, message type information, and target service identifier. The first determining unit is used to determine the target listener corresponding to the message to be routed based on the device model information; The second determining unit is used to determine the target policy factory component corresponding to the message to be routed based on the message type information through the target listener. The third determining unit is used to determine the target message processing strategy corresponding to the message to be routed based on the target service identifier through the target policy factory component.

[0013] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the message routing method for an Internet of Things device as described in any of the first aspects above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the message routing method for an Internet of Things device as described in any of the first aspects above.

[0015] Fifthly, embodiments of this application provide a computer program product that, when run on a display device, causes the display device to perform the steps of the message routing method for IoT devices as described in any of the first aspects above.

[0016] The beneficial effects of the message routing method for IoT devices provided in this application embodiment are as follows: In the message routing method for IoT devices provided in this application embodiment, the message to be routed sent by the IoT device is first obtained. The message to be routed includes device model information, message type information, and a target service identifier. Then, based on the device model information, the target listener corresponding to the message to be routed is determined. Next, based on the message type information, the target policy factory component corresponding to the message to be routed is determined using the target listener. Finally, based on the target service identifier, the target message processing policy corresponding to the message to be routed is determined using the target policy factory component. Since this solution determines the target message processing policy based on the target service identifier using the target policy factory component, it eliminates the need for conditional branching statements. Furthermore, when adding a new IoT device, only the message processing policy and its corresponding service identifier need to be written, without requiring large-scale modifications to the initial code. Moreover, since this solution determines the target policy factory component corresponding to the message to be routed based on the message type information, different business messages from the same device can be processed through different policy factory components. All of these factors reduce the maintenance cost of the message routing method for IoT devices and ultimately improve the convenience of message routing for IoT devices. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating the implementation of the message routing method for IoT devices provided in this application embodiment; Figure 2 This application provides a schematic diagram of the structure of a message routing device for an Internet of Things (IoT) device. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] It should be noted that the terminology used in the embodiments of this application is only for explaining specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

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

[0021] In IoT device access platforms, message routing mechanisms rely on static factory patterns or conditional statements, resulting in tight coupling between the processing logic of device model information and message type information. Specifically, expanding device model information requires modification of the core factory class code, violating the open / closed principle; message type information is only routed at the first level based on device model, failing to achieve fine-grained separation between data reporting types and event reporting types. Furthermore, the registration of strategy implementation classes depends on manually configuring mapping relationships, lacking an automatic discovery mechanism. This increases code maintenance costs, reduces system testability, and limits flexibility in large-scale device access scenarios.

[0022] For example, when integrating a new model TX3190A smoke detector into the AEP platform, this device supports both data reporting and event reporting messages. The existing solution requires hard-coding a new device model mapping entry in the static factory class and extending the if-else branch at the message entry point to differentiate message types. Specifically, developers must modify the factory class registration logic to adapt to the TX3190A device model information and adjust routing condition statements to handle the differences between data reporting and event reporting types. This coupling of device model information and message type information prevents different business logics for the same device from evolving independently, requiring testing to cover the newly added branch paths and extending the functional verification cycle.

[0023] If the above issues are not addressed, the system will struggle to adapt to the rapid iteration of device models, leading to a continuous expansion of the codebase; the complexities of message processing logic will further exacerbate the risk of introducing defects, affecting the stability of services in multi-tenant scenarios; and operations and maintenance personnel will need to frequently maintain the mapping configuration between device models and processors, increasing the complexity of platform deployment. Therefore, the rigidity of the existing architecture will hinder the scalability of the IoT platform in environments with diverse devices.

[0024] To address the above issues, this application provides a message routing method for IoT devices. The execution subject of the message routing method for IoT devices provided in this application can be an electronic device. For example, the electronic device may include, but is not limited to, mobile phones, tablets, desktop computers, and laptops.

[0025] Please see Figure 1 , Figure 1 The flowchart illustrates the implementation of the message routing method for an IoT device provided in this application embodiment. This message routing method may include steps S101 to S104, as detailed below: In S101, the unrouted message sent by the IoT device is obtained; the unrouted message includes device model information, message type information, and target service identifier.

[0026] In this application embodiment, an Internet of Things (IoT) device refers to a physical entity that possesses sensing, computing, and communication capabilities, and is able to access an IoT platform and interact with data. These devices typically include sensors, actuators, and smart terminals, and their functions include collecting environmental data, executing control commands, or reporting status.

[0027] Pending messages: These are messages generated by IoT devices and sent to the IoT platform that require specific processing. These messages carry information such as the device's status, collected data, or triggered events, and are the core carrier for interaction between the device and the platform.

[0028] Device model information: Data used to uniquely identify the specific model or type of an IoT device. This information allows the system to identify the source device of a message and perform preliminary classification and processing accordingly. For example, different device models may correspond to different communication protocols or data parsing rules.

[0029] Message type information: This information is used to distinguish the business meaning or data nature represented by the message to be routed. Common message types include data reporting and event reporting. This information is crucial for fine-grained message processing and strategy selection.

[0030] Target service identifier: Used to further distinguish specific business services or data content under specific device models and message types.

[0031] First, the method in this embodiment includes acquiring a pending message sent by an IoT device. This pending message is the basis for the interaction between the IoT device and the platform, and its content typically includes device model information, message type information, and a target service identifier. For example, a smart smoke detector can send a pending message containing its device model (e.g., "TX3190A"), message type (e.g., "event reporting"), and target service identifier (e.g., "1").

[0032] In one possible implementation, after obtaining the message to be routed sent by the IoT device, the process also includes parsing the message to be routed and encapsulating the parsed message to be routed using a preset message model to obtain the encapsulated message to be routed.

[0033] Parsing a message to be routed refers to decomposing the received raw, unprocessed message according to specific rules or protocols to extract the structured or unstructured data it contains. Its function is to separate the raw message from its transmission format, making its internal information recognizable and accessible to the program.

[0034] A predefined message model refers to a predefined, standardized data structure or object template used to uniformly represent and store key information from parsed IoT device messages. Its purpose is to provide a unified, abstract message representation, shielding the differences in underlying message formats and enabling subsequent routing and processing logic to operate based on a standardized data structure. This model can be an object definition in a predefined programming language, containing fields such as device model, message type, target service identifier, and business data payload.

[0035] Message encapsulation refers to the process of structuring and standardizing parsed raw message data according to a predefined message model. Its purpose is to uniformly convert heterogeneous raw messages into a standardized format that conforms to internal processing logic, thereby simplifying subsequent routing decisions and business processing logic, and improving system robustness and maintainability. This can be achieved by filling the parsed field values ​​(such as device model, message type, etc.) into the corresponding attributes of a predefined message model object to form a complete message object. Alternatively, it can be achieved by converting the parsed data into a JSON or XML string that conforms to the predefined message model definition, ensuring that messages flow in a unified serialization format within the system.

[0036] The encapsulated message to be routed refers to a message that has undergone parsing and message encapsulation and conforms to the standard format of a preset message model. It serves as the unified data carrier for subsequent routing decisions and business processing within the system, typically manifested as an object instance within a program or serialized data conforming to a specific data structure specification.

[0037] In S102, the target listener corresponding to the message to be routed is determined based on the device model information.

[0038] In this embodiment, the target listener refers to a component configured to receive and process messages of a specific type. During message routing, the target listener is responsible for determining the subsequent message processing flow based on certain characteristics of the message (such as device model), and is the first-level distribution mechanism of message routing.

[0039] This step aims to perform initial routing based on the type of device from which the message originates. For example, a message sent by a gas detector with device model "AEC2368b" needs to be routed to a listener that specifically handles gas detector messages.

[0040] In one possible implementation, "determining the target listener corresponding to the message to be routed based on the device model information" can be achieved by publishing the encapsulated message to be routed to the Spring event bus, so that each listener associated with the Spring event bus can perform the following process: obtain the device model information based on the encapsulated message to be routed, and determine whether the listener is the target listener based on the device model information and the target device model corresponding to the listener.

[0041] Spring Event Bus is an event handling mechanism provided by the Spring framework based on a publish / subscribe pattern. It allows different components in an application to communicate loosely coupledly by publishing and listening to events. When a component publishes an event, all listeners interested in that event are notified and execute their corresponding processing logic. Its implementation can be based on the Spring framework's `ApplicationEventPublisher` and `ApplicationListener` interfaces. Publishers publish events using the `publishEvent` method, and listeners handle events by implementing the `ApplicationListener` interface and overriding the `onApplicationEvent` method. Alternatively, Spring Boot's `@EventListener` annotation can be used to directly annotate methods, and the Spring container will automatically register them as event listeners. In this approach, Spring Event Bus acts as the core message distribution mechanism, responsible for broadcasting the encapsulated and processed messages to all registered listeners, thereby achieving dynamic listener discovery and activation. Each listener associated with Spring Event Bus is a component pre-registered with Spring Event Bus, designed to handle specific types of events or messages. Each listener typically contains specific business logic, such as making judgments based on device model information.

[0042] Each listener can be a standalone Spring Bean that implements the `ApplicationListener` interface and internally maintains one or more lists or rules of "target device models" that it can handle. Alternatively, listeners can also be methods annotated with `@EventListener`, which, when invoked, receive an event object and decide whether to process it based on the event content (such as device model information).

[0043] These listeners are the units that actually execute the device model matching logic. After receiving a message, they determine whether they are the "target listener" for that message based on their own configuration. Obtaining the device model information based on the encapsulated and processed message to be routed is the first step in the listener's judgment logic, ensuring that it can extract the key device model information from the received message.

[0044] The core logic of a listener's self-judgment is determining whether it is the target listener, based on the device model information and the target device model it corresponds to. This determines which listener is ultimately selected as the target listener. Each listener can be configured with one or a group of device models it is responsible for during initialization. When it receives a message, it compares the device model in the message with its own configured device models; if they match, it considers itself the target listener. Furthermore, listeners can implement more complex matching rules, such as supporting regular expressions to match device models, or matching based on a prefix of the device model, to accommodate a wider range of device types.

[0045] This application's solution achieves dynamic determination of the target listener by publishing the encapsulated message to the Spring Event Bus. Specifically, after the message to be routed is parsed and encapsulated, it is published as an event to the Spring Event Bus. The Spring Event Bus, as the core distribution mechanism, broadcasts this event to all listeners associated with it. Upon receiving the event, each listener independently executes its judgment logic: first, it retrieves the device model information from the encapsulated message; then, it compares the retrieved device model information with its own pre-defined target device model. If the comparison shows a match, the listener determines itself as the target listener for that message. This publish / subscribe mechanism highly decouples the listener selection process, avoiding centralized queries or traversals, thereby improving the system's efficiency and flexibility when processing a large number of messages with different device models.

[0046] In S103, the target listener determines the target policy factory component corresponding to the message to be routed based on the message type information.

[0047] In this embodiment, the target policy factory component refers to the component responsible for creating or providing specific message processing policies based on message type information. This component associates message types with corresponding processing logic, thereby achieving differentiated processing for different types of messages.

[0048] This step, based on device model routing, further refines the routing according to the message's service type. For example, a listener processing messages from an "AEC2368b" device needs to select different policy factories based on whether the message is a "data report" or an "event report" after receiving it.

[0049] In one possible implementation, the message type information is either a data reporting type or an event reporting type. Based on the message type information, the target policy factory component corresponding to the message to be routed is determined, including: if the message type information is a data reporting type, then a first policy factory component is determined as the target policy factory component; the first policy factory component is used to determine the message processing policy corresponding to the message to be routed of the data reporting type; if the message type information is an event reporting type, then a second policy factory component is determined as the target policy factory component; the second policy factory component is used to determine the message processing policy corresponding to the message to be routed of the event reporting type.

[0050] The message type information is a key field in the message to be routed, used to indicate the business nature or purpose of the message. Restricting it to either a data reporting type or an event reporting type signifies that the system has performed a preliminary classification of the messages sent by IoT devices. Data reporting types typically refer to sensor data, status data, etc., sent periodically or on demand by the device; this data often needs to be stored, analyzed, or displayed. Event reporting types typically refer to alarms, faults, operation logs, etc., triggered by the device under specific conditions; these events may require immediate response, notification, or triggering of specific business processes.

[0051] The first strategy factory component is a logical unit or software module specifically designed to process data reporting type messages. Its core function is to determine the specific message processing strategy to be applied to the message based on its characteristics. This component can be a class implementing a specific interface or a configuration module containing a series of rules and mapping relationships. The second strategy factory component is a logical unit or software module specifically designed to process event reporting type messages. Similar to the first strategy factory component, its core function is to determine the specific message processing strategy to be applied to the message based on its characteristics. This component can also be a class implementing a specific interface or a configuration module containing a series of rules and mapping relationships.

[0052] The purpose of determining the target policy factory component for a message to be routed is to accurately select a suitable policy factory component based on the message type information of the message. Its function is to direct different types of messages to different processing "factories," thereby achieving specialization and modularization of message processing logic.

[0053] This application's solution refines and categorizes message type information, explicitly limiting the message type of the message to be routed to either data reporting or event reporting. Based on this, when the system needs to determine the target policy factory component corresponding to the message to be routed based on the message type information, it no longer uses a general mechanism that might require complex internal logic for differentiation and processing. Instead, it directly makes conditional judgments based on the specific classification of the message type. Specifically, if the message type information is identified as a data reporting type, the system directly designates a preset first policy factory component as the target policy factory component. This component is specifically responsible for processing data reporting type messages and further determines its corresponding message processing strategy. Conversely, if the message type information is identified as an event reporting type, the system designates a preset second policy factory component as the target policy factory component. This component is specifically responsible for processing event reporting type messages and further determines its corresponding message processing strategy. This mechanism makes the intermediate link in message routing—the determination process of the policy factory component—more direct and efficient. In this way, messages of different business natures are clearly diverted to their respective dedicated strategy factory components for further processing, thereby ensuring the professionalism and accuracy of message processing logic and providing a clear and optimized entry point for determining subsequent message processing strategies.

[0054] The following example illustrates this. Assume an IoT platform receives a message to be routed, containing a message type information field. During the target policy factory component determination phase, the system first reads this message type information. If the value of this field is "DATA_UPLOAD", the system immediately recognizes this as a data reporting message and, based on a pre-defined mapping, designates a component instance named "DataUploadStrategyFactory" as the target policy factory component. This "DataUploadStrategyFactory" component may internally contain policy selection logic for different sensor data (such as temperature, humidity, and power). If the message type information field value is "EVENT_REPORT", the system recognizes this as an event reporting message and designates a component instance named "EventReportStrategyFactory" as the target policy factory component. This "EventReportStrategyFactory" component may internally contain policy selection logic for different event types (such as device offline, alarm triggering, and firmware update). In this way, the system can quickly and accurately direct different types of messages to their respective policy factories, avoiding complex type judgments and branching processes in a single general factory.

[0055] The above technical solution clearly categorizes message type information into data reporting types and event reporting types, and configures dedicated first and second policy factory components for each type, thereby achieving refined and specialized determination of policy factory components. This classification processing mechanism enables the system to avoid complex general judgment logic when determining the target policy factory component based on message type information, and directly perform rapid matching and distribution based on the business nature of the message. This not only significantly improves the efficiency and accuracy of policy factory component selection during message routing, but also provides a clear and independent logical entry point for the subsequent processing of different message types, greatly enhancing the maintainability, scalability, and flexibility of the entire message routing system, making it easier to manage and iterate processing strategies for specific message types.

[0056] In S104, the target policy factory component determines the target message processing policy corresponding to the message to be routed based on the target service identifier.

[0057] In this embodiment, the target message processing strategy refers to a component that defines specific business processing logic for a given message type and target service identifier. This strategy encapsulates operations such as message content parsing, data storage, and business logic triggering, and is the final execution unit for message processing.

[0058] This step is the final stage of message routing, designed to precisely locate the message processing strategy that executes the final business logic based on the specific business service identifier. For example, a strategy factory component that handles "data reporting" needs to return a message processing strategy specifically for handling temperature data reporting when it receives a target service identifier of "temperature data".

[0059] In one possible implementation, the step of determining the target message processing strategy corresponding to the message to be routed based on the target service identifier through the target strategy factory component includes: determining the target identifier key corresponding to the message to be routed based on the target service identifier through the target strategy factory component; matching the target Bean component corresponding to the target identifier key from the key-value mapping set; the key-value mapping set includes several Bean components, each Bean component recording a corresponding identifier key and message processing strategy; and determining the message processing strategy recorded by the target Bean component as the target message processing strategy.

[0060] The target identifier key is a string or number used to uniquely identify a specific service or business logic, serving as an intermediary bridge between the target service identifier and the specific message processing strategy. This target identifier key can be determined by hashing the target service identifier, concatenating strings, or directly using the target service identifier itself.

[0061] A key-value mapping set is a data structure that stores the correspondence between identifier keys and message processing strategies, allowing the system to quickly look up and retrieve the corresponding message processing strategy based on the identifier key.

[0062] A Bean component is a software component instance that can be managed and invoked by the system. It encapsulates specific message processing logic and related metadata, such as identifier keys and message processing strategies. In object-oriented programming, a Bean component can be an instance of a class that implements a specific interface, which defines the methods for message processing. The message processing strategy defines the specific business logic or algorithm for processing specific types of messages; it can be an implementation of an interface or abstract class, containing the concrete methods for processing messages.

[0063] The solution in this application, through the aforementioned technical means, further refines the process of determining the message processing strategy based on the already determined target strategy factory component according to device model information and message type information. Specifically, the target strategy factory component first generates a target identifier key based on the target service identifier. This target identifier key, as an abstract representation, transforms the original service identifier into a format that facilitates internal system lookup and matching. Subsequently, the system uses this target identifier key to search within a pre-built key-value mapping set. This key-value mapping set efficiently stores the association between each identifier key and its corresponding Bean component. Once a target identifier key is matched, the corresponding target Bean component can be obtained. Since each Bean component pre-records its corresponding message processing strategy, by obtaining the target Bean component, the target message processing strategy required for the message to be routed can be accurately determined. This mechanism cleverly decouples the service identifier from the specific processing logic, making the message processing strategy determination process more dynamic and flexible. In this way, the system can avoid hard-coded strategy mapping, thereby enabling low-cost expansion and maintenance when facing constantly changing business needs and new IoT services.

[0064] This application further proposes that the key-value mapping set be created in the following way: by using the Spring container, strategy implementation class components including arbitrary service identifiers are scanned out, and for each strategy implementation class component, a Bean component corresponding to the strategy implementation class component is constructed according to the identifier key and message processing strategy recorded by the strategy implementation class component, and the Bean component corresponding to the strategy implementation class component is stored in the key-value mapping set.

[0065] A key-value mapping collection is a data structure used to store a series of key-value pairs, where each key is unique and associated with a specific value. In message routing scenarios, the key can represent a service identifier or a strategy identifier, while the value can be the message processing strategy corresponding to that identifier or its encapsulation (such as a Bean component). This collection can be implemented in various ways, such as hash tables, tree mappings, or concurrent mappings, to meet different performance and concurrency requirements.

[0066] The Spring container is a core component of the Spring framework, responsible for managing the lifecycle of objects, dependency injection, and configuration in an application. It provides a runtime environment for creating, configuring, and managing Bean components. The Spring container can instantiate objects, resolve dependencies, and provide various services based on configurations (such as XML configuration, Java configuration, or annotations).

[0067] Scanning for strategy implementation class components that include arbitrary service identifiers means that the Spring container automatically detects and identifies classes in the application that include arbitrary service identifiers when it starts up or runs.

[0068] Strategy implementation components are classes that specifically implement message processing logic. Each strategy implementation component encapsulates a specific message processing behavior, such as data parsing, format conversion, business logic processing, or data storage. These components typically implement a common interface to ensure they have a unified calling method.

[0069] An identifier key is a string or enumeration value used to uniquely identify a specific message processing strategy. As the key in a key-value mapping set, it enables the system to quickly locate the corresponding message processing strategy based on the target service identifier. Identifier keys can be provided by the strategy implementation class component itself, or defined through naming conventions or configuration files.

[0070] A message processing strategy refers to a set of processing steps and logic defined for a specific type of message or business scenario. It defines how to parse, validate, transform, store, or forward received messages. A message processing strategy can be a simple function call or a complex business process orchestration.

[0071] Building the corresponding Bean component for the strategy implementation class means that when the Spring container scans the strategy implementation class component, it creates a corresponding Bean component based on its definition. The Bean component is an object instance managed by the Spring container, containing all the functionality and configuration of the strategy implementation class. This construction process typically involves instantiating the class, injecting dependencies, and applying any configuration or post-processing. Storing it in a key-value map collection means that the completed Bean component (or its key information, such as the identifier key and message handling strategy) is added to a predefined key-value map collection. This collection is typically a singleton Bean, managed by the Spring container, and available throughout the application's lifecycle. In this way, all dynamically discovered strategies can be centrally managed and accessed at runtime.

[0072] This application's solution optimizes the creation process of key-value mapping collections by introducing the dynamic scanning and management capabilities of the Spring container. Specifically, during system initialization or runtime, the Spring container is configured to automatically scan all classes in the application identified as strategy implementation components. These strategy implementation components typically declare their identity as message handling strategies through specific annotations or interface implementations, carrying their corresponding identifier keys. Once the Spring container discovers these strategy implementation components, it constructs a corresponding Bean component for each component, which encapsulates the specific identifier key and message handling strategy.

[0073] Subsequently, these constructed Bean components, along with their associated identifier keys and message processing strategies, are automatically stored in a key-value mapping collection. This mechanism eliminates the need for manual configuration or hard coding of the key-value mapping collection; instead, it dynamically populates and updates based on the actual strategy implementation classes existing in the application. When upstream processes (such as determining the target identifier key via the target strategy factory component) need to match the target Bean component from the key-value mapping collection, they can efficiently retrieve it directly from this dynamically constructed collection, ensuring the flexibility and scalability of message routing. This automated creation and management of key-value mapping collections significantly reduces the complexity of system maintenance and improves the ease of integrating new strategies, enabling the entire message routing system to better adapt to ever-changing business needs.

[0074] This application further proposes that the aforementioned message to be routed also includes business data payload or event content data; after determining the target message processing strategy corresponding to the message to be routed, it also includes: processing the business data payload or event content data through the target message processing strategy.

[0075] Among them, business data payload or event content data is the core component of the unrouted messages sent by IoT devices, carrying the business information or event information actually collected or generated by the device. For example, it can be environmental parameters collected by sensors (such as temperature, humidity, and pressure), the operating status of the device (such as switch status and power information), or specific alarm events (such as device failure or abnormal intrusion).

[0076] Processing business data payloads or event content data through a target message processing strategy means applying the best processing logic to the actual content of the message after determining the optimal processing logic for a specific message.

[0077] This processing can encompass a variety of operations, such as storing received data in a database or data lake for persistence; performing format conversion, cleaning, or aggregation on the data to meet the needs of downstream systems; triggering specific business processes based on the data content, such as automatically sending an alarm notification when the temperature exceeds a preset threshold; or calling external service interfaces to forward the processed data to third-party applications or platforms.

[0078] As can be seen from the above, in the message routing method for IoT devices provided in this application embodiment, the message to be routed sent by the IoT device is first obtained, wherein the message to be routed includes device model information, message type information, and target service identifier; then, based on the device model information, the target listener corresponding to the message to be routed is determined; then, through the target listener, based on the message type information, the target policy factory component corresponding to the message to be routed is determined; finally, through the target policy factory component, based on the target service identifier, the target message processing policy corresponding to the message to be routed is determined. Since this solution determines the target message processing policy based on the target service identifier through the target policy factory component, it does not require the use of conditional branch statements; and when adding a new IoT device, only the message processing policy and the corresponding service identifier need to be written, without large-scale modification of the initial code; and since this solution determines the target policy factory component corresponding to the message to be routed based on the message type information, different business messages of the same device can be processed through different policy factory components; all of the above can reduce the maintenance cost of the message routing method for IoT devices and ultimately improve the convenience of message routing for IoT devices.

[0079] Based on the message routing method for IoT devices provided in the above embodiments, this application further provides a message routing apparatus for IoT devices that implements the above method embodiments. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a schematic diagram of the structure of a message routing device for an Internet of Things (IoT) device provided in an embodiment of this application. Figure 2 As shown, the message routing device 20 for IoT devices may include: a message acquisition unit 21, a first determination unit 22, a second determination unit 23, and a third determination unit 24. Wherein: The message acquisition unit 21 is used to acquire the message to be routed sent by the IoT device; the message to be routed includes device model information, message type information and target service identifier.

[0080] The first determining unit 22 is used to determine the target listener corresponding to the message to be routed based on the device model information.

[0081] The second determining unit 23 is used to determine the target policy factory component corresponding to the message to be routed based on the message type information through the target listener.

[0082] The third determining unit 24 is used to determine the target message processing strategy corresponding to the message to be routed based on the target service identifier through the target policy factory component.

[0083] Optionally, the message routing 20 of the IoT device may also include a message processing unit, wherein: The message processing unit is specifically used for: The message to be routed is parsed, and the parsed message to be routed is encapsulated using a preset message model to obtain the encapsulated message to be routed.

[0084] Optionally, the first determining unit 22 is specifically used for: The encapsulated message to be routed is published to the Spring Event Bus to instruct each listener associated with the Spring Event Bus to perform the following process: based on the encapsulated message to be routed, obtain the device model information, and determine whether the listener is the target listener based on the device model information and the target device model corresponding to the listener.

[0085] Optionally, the message type information is either a data reporting type or an event reporting type; the second determining unit 23 is specifically used for: If the message type information is data reporting type, then the first policy factory component is determined as the target policy factory component; the first policy factory component is used to determine the message processing policy corresponding to the data reporting type message to be routed. If the message type information is an event reporting type, then the second strategy factory component is determined as the target strategy factory component; the second strategy factory component is used to determine the message processing strategy corresponding to the message to be routed for the event reporting type.

[0086] Optionally, the third determining unit 24 is specifically used for: The target policy factory component determines the target identifier key corresponding to the message to be routed based on the target service identifier. Match the target Bean component corresponding to the target identifier key from the key-value mapping set; the key-value mapping set includes several Bean components, each of which records the corresponding identifier key and message processing strategy; The message processing strategy recorded by the target Bean component is determined as the target message processing strategy.

[0087] Optionally, the message routing 20 for IoT devices may also include a key-value mapping set creation unit, wherein: The key-value mapping collection creation unit is specifically used for: The Spring container scans for strategy implementation class components that include arbitrary service identifiers. For each strategy implementation class component, based on the identifier key and message processing strategy recorded by the component, a corresponding Bean component is constructed and stored in a key-value mapping collection.

[0088] Optionally, the message to be routed may also include business data payload or event content data; the message routing 20 for IoT devices may also include a data processing unit, wherein: The data processing unit is specifically used for: The business data payload or event content data is processed through the target message processing strategy.

[0089] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of this application. Their specific functions and technical effects can be referred to the method embodiments section, and will not be repeated here.

[0090] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 provided in this embodiment may include: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program corresponding to the message routing method for an IoT device. When the processor 30 executes the computer program 32, it implements the steps described above in the embodiment of the message routing method applied to an IoT device, for example... Figure 1 S101~S104 are shown. Alternatively, when processor 30 executes computer program 32, it implements the functions of each module / unit in the above-described embodiment of the message routing device for IoT devices, for example... Figure 2 The functions of units 21-24 shown.

[0091] For example, computer program 32 can be divided into one or more modules / units, one or more of which are stored in memory 31 and executed by processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 32 in electronic device 3. For example, computer program 32 can be divided into message acquisition unit 21, first determination unit 22, second determination unit 23, and third determination unit 24. For the specific functions of each unit, please refer to... Figure 2 The relevant descriptions in the corresponding embodiments are not repeated here.

[0092] Those skilled in the art will understand that Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or use different components.

[0093] The processor 30 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0094] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, or flash card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units is merely an example. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the message routing device of the IoT device can be divided into different functional units to complete all or part of the functions described above. The functional units in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0096] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0097] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.

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

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

[0100] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A message routing method for an Internet of Things (IoT) device, characterized in that, include: Obtain the unroutable messages sent by IoT devices; The message to be routed includes device model information, message type information, and target service identifier; Based on the device model information, determine the target listener corresponding to the message to be routed; The target listener determines the target policy factory component corresponding to the message to be routed based on the message type information. The target policy factory component determines the target message processing policy corresponding to the message to be routed based on the target service identifier.

2. The method according to claim 1, characterized in that, Before determining the target listener corresponding to the message to be routed based on the device model information, the method further includes: The message to be routed is parsed, and the parsed message to be routed is encapsulated using a preset message model to obtain the encapsulated message to be routed.

3. The method according to claim 2, characterized in that, The step of determining the target listener corresponding to the message to be routed based on the device model information includes: The encapsulated message to be routed is published to the Spring Event Bus to instruct each listener associated with the Spring Event Bus to perform the following process: based on the encapsulated message to be routed, obtain the device model information, and based on the device model information and the target device model corresponding to the listener, determine whether the listener is the target listener.

4. The method according to claim 1, characterized in that, The message type information is either a data reporting type or an event reporting type; determining the target policy factory component corresponding to the message to be routed based on the message type information includes: If the message type information is a data reporting type, then the first policy factory component is determined as the target policy factory component; the first policy factory component is used to determine the message processing policy corresponding to the message to be routed of the data reporting type. If the message type information is an event reporting type, then the second policy factory component is determined as the target policy factory component; the second policy factory component is used to determine the message processing policy corresponding to the message to be routed of the event reporting type.

5. The method according to claim 1, characterized in that, The step of determining the target message processing policy corresponding to the message to be routed based on the target service identifier through the target policy factory component includes: The target identification key corresponding to the message to be routed is determined by the target policy factory component based on the target service identifier. Match the target Bean component corresponding to the target identifier key from the key-value mapping set; the key-value mapping set includes several Bean components, each Bean component records the corresponding identifier key and message processing strategy; The message processing strategy recorded by the target Bean component is determined as the target message processing strategy.

6. The method according to claim 5, characterized in that, The key-value mapping set is created in the following way: Using the Spring container, strategy implementation class components with arbitrary service identifiers are scanned out. For each strategy implementation class component, a corresponding Bean component is constructed based on the identifier key and message processing strategy recorded by the strategy implementation class component, and the corresponding Bean component is stored in the key-value mapping set.

7. The method according to any one of claims 1 to 6, characterized in that, The message to be routed also includes business data payload or event content data; After determining the target message processing strategy corresponding to the message to be routed, the method further includes: The target message processing strategy is used to process the business data payload or the event content data.

8. A message routing device for an Internet of Things (IoT) device, characterized in that, include: The message acquisition unit is used to acquire messages to be routed sent by IoT devices; The message to be routed includes device model information, message type information, and target service identifier; The first determining unit is used to determine the target listener corresponding to the message to be routed based on the device model information; The second determining unit is used to determine the target policy factory component corresponding to the message to be routed based on the message type information through the target listener. The third determining unit is used to determine the target message processing strategy corresponding to the message to be routed based on the target service identifier through the target policy factory component.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the message routing method for the Internet of Things device as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, When the computer program product is executed by a processor, it implements the steps of the message routing method for the Internet of Things device as described in any one of claims 1 to 7.

Images