Object-oriented real-time message bus implementation method

Abstract

The invention relates to an object-oriented real-time message bus implementation method, which is characterized in that a real-time message bus provides a point-to-point or point-to-many communication mode, a required packaging function is realized for packaging, and a streaming-oriented connected network mode is realized; the real-time message bus is provided with a plurality of interfaces so as to realize message transmission between the client and the server; the real-time message bus defines implementation interfaces based on TCP / IP middleware, and each interface comprises a publishing factory interface object, a subscription request interface object and a subscription response interface object; the real-time message bus realizes different interface functions through a pure virtual function, and different module object components can be effectively packaged, so that an object-oriented interface is subjected to polymorphic separation from implementation, and asynchronous communication is carried out; and the real-time message bus supports adaptive compiling of different operating systems, so that an object-oriented interface has a cross-platform function. According to the invention, the simplicity, stability and reliability of TCP / IP remote procedure call are realized, and the advantages are obvious.

Description

Technical Field

[0001] The present invention relates to the technical field of network communication, and in particular to an object-oriented real-time message bus implementation method. Background Art

[0002] The traditional TCP / IP protocol programming method can no longer meet the requirements of low-code agile development. At the same time, the quality and ability of the developers of the underlying basic software will also affect the quality of the software framework. If the message bus can realize the asynchronous communication mode, this is undoubtedly a better communication mode. Among them, the complex communication process is properly decoupled so that its bus technology meets practical needs, which is also the core element of the system.

[0003] Since the TCP / IP protocol is suitable for point-to-point communication, it is difficult to use this model to build and design bus technology. Therefore, many message bus technologies are designed based on the UDP / IP protocol. However, this will make the overall coding of software components extremely complicated, that is, to implement the reliable UDP mode with the unreliable UDP transmission mode, and it will also bring challenges to the real-time performance, stability and maintainability of the system.

[0004] However, the distributed remote procedure call framework (MCE) implemented using the TCP / IP protocol layer can help us build distributed applications with minimal effort. Among them, MCE allows us to focus on application logic and is responsible for all interactions with low-level network programming interfaces. Based on the MCE framework, you don't have to worry about details such as opening network connections, serializing and deserializing data for network transmission, or retrying failed connection attempts.

[0005] Commercial or open source message bus technology provides producer and consumer design patterns, but when the real-time message bus is weakened to a point-to-point mode during use, the original bus's biggest advantage no longer exists. In addition, the problems exposed by the message bus continue to occur on site, resulting in complex operation and maintenance and difficult tracking during project implementation. Among them, commercial message middleware software generally does not provide source code. We cannot know the complex logic of the bus's internal design, which makes it more difficult to troubleshoot errors and locate problems, making the operating costs of more and more projects uncontrollable. Therefore, an object-oriented real-time message bus implementation method used in the field of TCP / IP real-time communication systems is provided to solve the actual problem.

[0006] It should be understood that the above statements merely provide background technology related to the present invention and do not necessarily constitute prior art. Summary of the invention

[0007] The purpose of the present invention is to provide an object-oriented real-time message bus implementation method to achieve the simplicity, stability and reliability of TCP / IP oriented remote procedure calls.

[0008] In order to achieve the above-mentioned purpose, the present invention provides an object-oriented real-time message bus implementation method, the real-time message bus provides a point-to-point or point-to-multiple communication mode, and implements the required encapsulation function for the packaging class to realize a stream-oriented connected network mode; a plurality of interfaces are arranged on the real-time message bus to realize the message transmission between the client and the server; the real-time message bus is based on the TCP / IP middleware definition implementation interface, each interface includes: a publishing factory interface object, a subscription request interface object and a subscription response interface object; and the real-time message bus realizes different interface functions through pure virtual functions, can effectively encapsulate different module object components, so that the object-oriented interface and the implementation are polymorphically separated and asynchronous communication is performed; the real-time message bus supports adaptive compilation for different operating systems, so that the object-oriented interface has cross-platform functions.

[0009] Wherein, when the real-time message bus performs message transmission, the structure of the message includes: a channel header, a message type and a message body.

[0010] Preferably, the channel header includes a source group number, a source host number, a process number, a node name and option configuration; and the message type includes string, XML, JSON or Protobuf.

[0011] Preferably, the communication modes include: master-slave communication mode, broadcast communication mode and balanced communication mode.

[0012] Preferably, in the master-slave communication mode, the real-time message bus can complete the sending request message of the host or slave, and when executing the sending request message, it is executed in sequence according to the priority order; in the broadcast communication mode, this mode sends messages to all receivers to send the same message or command to all client groups; in the balanced communication mode, a balancing factor is set in this mode to distribute requests to multiple client groups to balance the load and improve performance.

[0013] Preferably, the interface mode is designed using a distributed remote procedure call method, and the distributed remote procedure call is implemented using a callback function.

[0014] Preferably, the publishing factory interface object is used to create or obtain resources or objects related to the publish-subscribe model; the subscription request interface object is an object created by the server, which contains the client's subscription information or specific content of the request; the subscription response interface object is an object created inside the client, which is used to encapsulate response data or callback function to notify the client that the information has been successfully subscribed.

[0015] Preferably, the publishing factory interface object is called and accessed by the client to implement initialization and establish communication with the server; the server returns the created subscription request interface object to the client for use, and the client sends a subscription request or performs other related operations through the subscription request interface object; the client passes the pointer to the internally created subscription response interface object as a parameter to the server for use, thereby realizing a remote process callback mode between the client and the server.

[0016] Preferably, the pure virtual functions include: create, destroy, send and receive, which are respectively creating an object, destroying an object, sending a message and receiving a message.

[0017] Preferably, the real-time message bus can immediately capture the exception when a problem occurs in the communication link, generate an exception message and mark it, and then perform corresponding processing through the client.

[0018] Preferably, the real-time message bus encapsulates a thread-level concurrent model queue, supporting the FIFO common queue mode and the LIFO stack mode.

[0019] Preferably, the real-time message bus can set an overflow time when a delay or congestion occurs in the network or communication. Once the set overflow time is exceeded, the system is notified to perform corresponding processing to avoid long waiting or congestion.

[0020] Preferably, the real-time message bus can utilize middleware or plug-ins to implement a compression algorithm to compress messages and reduce the amount of data in the message transmission process.

[0021] Preferably, the real-time message bus communicates confidential messages based on an SSL plug-in and provides a whitelist access list to ensure communication security.

[0022] Preferably, the real-time message bus can be implemented based on a JNI interface calling method.

[0023] Preferably, the real-time message bus can filter messages through a filtering function and output the filtered messages.

[0024] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the object-oriented real-time message bus implementation method is implemented.

[0025] The present invention also provides an electronic device, comprising a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the object-oriented real-time message bus implementation method is implemented.

[0026] In summary, compared with the prior art, the object-oriented real-time message bus implementation method provided by the present invention has at least the following beneficial effects:

[0027] (1) The encapsulated real-time message bus of the present invention has the characteristics of simplicity, real-time performance, reliability and stability;

[0028] (2) The real-time message bus of the present invention supports multiple flexible communication modes such as point-to-point and point-to-multipoint, and the client group object can dynamically perceive the real-time status of the master and slave nodes and transparently access the desired master or slave;

[0029] (3) The real-time message bus of the present invention enables the client, client group and server to implement a simple interface method, which can significantly simplify the complexity and difficulty of application software development, enhance the ability of operation control, effectively improve the efficiency of on-site operation and maintenance, and reduce the operation and maintenance costs of online projects;

[0030] (4) The real-time message bus of the present invention is completely based on thread-safe design, provides an interface layer abstraction for object-oriented programming, uses efficient cross-thread queues internally, and the receiving end realizes communication with the outside based on the trigger mechanism of asynchronous messages;

[0031] (5) The real-time message bus of the present invention is released in the form of an independent component driver library, oriented to a connected communication mechanism, with no restrictions on the length of the transmitted data packet, diversified support for channel parameter configuration, support for multiple communication modes, concise configuration files, flexible and convenient deployment, and the use of a simple coding framework design to meet large and complex distributed network communication requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 This is a schematic diagram of the message bus structure in the present invention;

[0033] Figure 2 This is a schematic diagram of the client interface inheritance relationship in the present invention;

[0034] Figure 3 This is a schematic diagram of the server interface inheritance relationship in the present invention;

[0035] Figure 4 It is a schematic diagram of the communication mode in the present invention;

[0036] Figure 5 It is a schematic diagram of the master-slave communication mode in the present invention;

[0037] Figure 6 It is a schematic diagram of the client group broadcast and balanced communication mode in the present invention;

[0038] Figure 7 This is a schematic diagram of the server broadcast communication mode in the present invention;

[0039] Figure 8 It is a schematic diagram of the bus filtering function in the present invention;

[0040] Fig. 9 This is a schematic diagram of sending an abnormal message notification in the present invention;

[0041] Fig.10 This is a schematic diagram of a host switching message notification in the present invention;

[0042] Fig.11 It is a schematic diagram of the message queue and priority notification in the present invention. DETAILED DESCRIPTION

[0043] The following is combined with Figures 1 to 11 , the present invention is further explained by describing a preferred specific embodiment in detail.

[0044] It should be noted that the drawings are in a very simplified form and use non-precise proportions. They are only used to conveniently and clearly assist in explaining the embodiments of the present invention, and are not used to limit the conditions for the implementation of the present invention. Therefore, they have no substantive technical significance. Any structural modification, change in proportional relationship or adjustment of size, without affecting the effects and purposes that can be achieved by the present invention, should still fall within the scope of the technical content disclosed by the present invention.

[0045] It should be noted that, in the present invention, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only the elements explicitly listed, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0046] Further, such as Figure 1 As shown, the present invention provides an object-oriented real-time message bus, which defines a message structure for transmitting messages, including a channel header, a message type, and a message body. Wherein, the channel header is composed of a source group number, a source host number, a process number, a node name, and an option configuration, and the source group number and the source host number need to be globally defined in distributed deployment. In this case, the source group number and the source host number only need to be passed as parameters when constructing a component object. In a preferred embodiment of the present invention, the source group number is defined as srcGroupId, and the source host number is defined as srcHostId.

[0047] The message type (ie, the format of the message body) may include string, XML, JSON, or Protobuf.

[0048] In the present invention, a message bus is a mechanism for transmitting messages between systems or components (clients and servers), which allows different systems or components to communicate through standardized interfaces, thereby realizing the exchange and sharing of messages; wherein, the message bus uses a message structure to define the format and content of a message, and the message structure provides a unified message representation method for the message bus, so that messages can be correctly transmitted and processed between different systems or components; the message bus provides specific message processing functions by implementing pure virtual functions or abstract methods in an abstract interface base class.

[0049] It can be understood that the message structure defines the representation and storage methods of messages; the abstract interface base class defines the behavior of operating messages; the message structure can be defined as a part of the abstract interface base class to provide a unified message representation method; the abstract interface base class can define the methods for operating the message structure, and the specific implementation is completed by the derived class.

[0050] Furthermore, the object-oriented real-time message bus of the present invention defines an implementation interface based on a TCP / IP communication middleware, and includes three interface objects: a PublisherFactory interface object, a SubscriberRequest interface object, and a SubscriberResponse interface object; the PublisherFactory interface object is used to create or obtain resources or objects related to the publish-subscribe (pub-sub) mode; the Subscription Request interface object is an object created by the server, and contains the specific content of the client subscription information or request; the Subscription Response interface object is an object created inside the client, and is used to encapsulate response data or callback functions to notify the client that the subscription information has been successfully subscribed.

[0051] The PublisherFactory interface object is called and accessed by the client to initialize and establish communication with the server, and the server returns the created SubscriberRequest interface object to the client for use, and the client sends a subscription request or performs other related operations through the SubscriberRequest interface object. At the same time, the client also passes the pointer of the internally created SubscriberResponse interface object as a parameter to the server for use, thereby realizing the remote procedure call (RPC Callback) mode between the client and the server.

[0052] It should be noted that, in the present invention, the interface model is designed using a distributed remote procedure call (RPC) approach, and the distributed remote procedure call is implemented using a callback function. Specifically, after the client remotely calls the service, the service can notify the client of the result of the operation through the callback interface in an asynchronous manner, so that the data stream-oriented connected TCP / IP model can achieve communication and ensure the stability and reliability of real-time message bus message transmission.

[0053] Furthermore, the SubscriberRequest interface object and the SubscriberResponse interface object both encapsulate the write function interface, and can serialize the state of the object, that is, convert it into a byte stream to be sent by the network protocol stack.

[0054] Furthermore, the SubscriberRequest interface object also provides an alive function interface, a destroy function interface, a getNodeMode function interface and a getNodeElement function interface; the alive function interface is used to check whether an object or process is still active; the destroy function interface is used to delete or destroy an object and release the resources it occupies; the getNodeMode function interface is used to obtain mode or status information related to a node; the getNodeElement function interface is used to obtain a document object model element associated with a specific identifier or condition.

[0055] like Figure 2 and Figure 3 As shown in the figure, McebusObject is a base class of an abstract interface, which defines common properties and methods to implement the above three interface objects, including four pure virtual functions: create, destroy, send, and receive, which are used to create objects, destroy objects, send messages, and receive messages, respectively. These pure virtual functions do not provide specific implementations in the base class, but are left to the derived classes to implement. Specifically, by defining basic operations as pure virtual functions, McebusObject provides an interface that describes the functions that the derived class must implement, and the derived class "fills" the interface by providing the specific implementation of the pure virtual function, and allows different derived classes to implement the same interface in different ways, thereby realizing the separation of interface and implementation, and improving the reusability and scalability of the code.

[0056] Further, such as Figure 2 and Figure 3As shown, McebusClient, McebusClientGroup and McebusServer are three derived classes, which inherit the common properties and methods of McebusObject and implement the pure virtual functions according to their own needs. Among them, the functions implemented in McebusClient are creating a one-to-one client, destroying a one-to-one client, sending a message to a one-to-one client, and receiving a message from a one-to-one client; the functions implemented in McebusClientGroup are creating a one-to-many client, destroying a one-to-many client, sending a message to a one-to-many client, and receiving a message from a client cluster; the functions implemented in McebusServer are creating a server, destroying a server, sending a message to a server, and receiving a message from a server.

[0057] It is understandable that the pure virtual functions of create, destroy, and send messages in the three derived classes have been implemented, and there is no need to further refine the internal logic. However, only the pure virtual function of receive message needs to be further implemented as a receiving message triggered by an internal event. Therefore, McebusClient needs to inherit and encapsulate an McebusClientEx extension class, and only implement the receive pure virtual function. Similarly, the encapsulation of McebusClientGroupEx and McebusServerEx is also implemented in the same way.

[0058] It should be noted that the objects of the three derived classes, McebusClient, McebusClientGroup and McebusServer, correspond to the corresponding configured files respectively, in which the file names and file paths can be defined separately as needed without being restricted by any system environment requirements.

[0059] Furthermore, the configuration file corresponding to the McebusClient derived class is mcebus.client, and the content attributes fully comply with the MCE (Multi-VPN-Instance CE) configuration options. In a preferred embodiment of the present invention, "McebusSender.Proxy" is a bus sender proxy, and its attribute value is "McebusSender:default-h127.0.0.1-p 10000"; "Mcebus.Client.Endpoints" is an adapter for the endpoint, and its attribute value is "default-h localhost". Thus, MCE can be used as the communication middleware to configure the dual network requirements, and "McebusSender.Proxy" is used as the bus sender proxy. The client can read this attribute to create a reference to the "McebusSender" object in the server.

[0060] The configuration file corresponding to the McebusServer derived class is mcebus.server, and its content attributes also follow the MCE configuration options. For example, "Mcebus.Server.Endpoints" is the adapter of the service endpoint, and its attribute value is "default-hlocalhost-p 10000". Therefore, the dual network requirements can also be configured according to the MCE communication middleware.

[0061] Furthermore, the McebusServer derived class can set the real-time status of the master and slave machines of the current node in the server cluster.

[0062] The configuration file corresponding to the McebusClientGroup derived class is mcebus.ini, which consists of two keywords, "[MASTER]" and "[SLAVE]", which correspond to their own client configuration file key value "file", and their attribute value is "mcebus.client" file. The related attributes of the file content are also the specific format defined by MCE as described above. Among them, for the single-machine version, only the "[MASTER]" independent file is configured, while for the dual-machine version, both need to specify all configuration files, such as [MASTER] and [SLAVE].

[0063] Specifically, first, when the McebusObject derived object is initialized, the "create" pure virtual function is used to build the communication middleware process. The Create process also includes the process of initializing the session object and establishing a link with the remote server (although the link may not be successful immediately, there is an independent task scheduling inside the subsequent real-time message bus to continuously try to connect with the remote server); secondly, once the link is successfully created during the Create process, the message will be processed. At this time, the "send" request function is used, and the "receive" response function will be automatically triggered by the internal queue event of the bus to directly obtain the data message in the queue; finally, when the system task is completed or needs to exit, the "destroy" destruction function is used to perform internal cleanup.

[0064] Among them, the "send" request function is used in blocking mode. The blocking delay can be controlled by the time adjustment function "setTimeout" provided by the interface, and the unit is milliseconds; and the "getTimeot" function can be used to view the overflow time of the current object configuration. Its default value is "-1", which means using the time overflow value provided by the online debugger (In Circuit Emulator, ICE) for processing.

[0065] Furthermore, in real-time message buses, in order to deal with delays and congestion caused by factors such as network or communication, a custom overflow time (timeout) can usually be set. When a call exceeds the set overflow time during the creation or sending process, the system will perform corresponding processing to avoid long waiting or congestion.

[0066] Among them, the "receive" response function is used in a non-blocking mode. When an external source generates a message and enters its own bus queue, the scheduling task inside the bus will actively trigger the callback function "receive" to allow the client user to consume the message in time. In addition, considering the parallelism and real-time nature of the message bus, the overall logical message is a lightweight type, so it is recommended that the "receive" function directly process the message. For complex logical processing processes, it is necessary to use a thread queue to push the message into the stack, and another independent task will process the message popped from the queue.

[0067] like Figure 4 As shown, it represents the communication mode of the client and the server. It includes point-to-point mode, that is, the "1:1" mode, which consists of 1 client and 1 server; and point-to-multiple mode, that is, the "1:N" mode, which consists of 1 client and 2 or more servers. It can be understood that the real-time message bus provides a point-to-point or point-to-multiple communication mode, and implements the required encapsulation function for the packaging class to realize a stream-oriented connected network mode.

[0068] Among them, the point-to-point mode is applicable to the server side where the client points to the target object, and the point-to-multipoint mode is applicable to the server cluster with master-slave redundancy, in which the real-time status of the host and slave machines inside is automatically identified by the real-time message bus.

[0069] like Figure 5 As shown, it represents the master-slave communication mode of the McebusClientGroup client group. Among them, the real-time message bus selects the corresponding parameters to complete the sending request message of the host or the slave. The "primary" and "second" in the figure indicate the priority order, which are primary and secondary respectively. When executing the sending request message, it is executed in sequence according to the priority order. Specifically, in an embodiment of the present invention, the channel parameter ChannelHeader option option is used for bit operation: selecting the macro "CHANNEL_OPTION_PROMARYNODE" = 0x04 indicates that the target object is the current host; selecting the macro "CHANNEL_OPTION_SECONDNODE" = 0x08 indicates that the target object is the current slave.

[0070] like Figure 6 As shown, in addition to the master-slave mode mentioned above to select the target object to send messages, the McebusClientGroup client group can also use the broadcast mode or the balanced mode for related request access. Among them, the broadcast mode represents a communication mode in which messages are sent to all receivers. In the McebusClientGroup client group, the broadcast mode can be used to send the same message or command to all client groups; the balanced mode is set with a balance factor to achieve a load-balanced communication mode. In the McebusClientGroup client group, the balanced mode can be used to distribute requests to multiple client groups to balance the load and improve performance.

[0071] Specifically, in the broadcast mode of the embodiment of the present invention, different bits in the channel parameter ChannelHeader option option are set, and the macro "CHANNEL_OPTION_BROADCAST" = 0x02 is selected to indicate that the target object is all session connections on the client or server side. The broadcast mode is suitable for the scenario requirements of operating global variables in the server cluster; in the balanced mode of the embodiment of the present invention, when processing large-scale connection access, load balancing is a key strategy, which can help the server cluster effectively distribute tasks and share loads. In the load balancing mode, the requests of the client group will be dynamically distributed to different servers in the cluster to optimize resource utilization, improve response speed and increase system scalability. The macro "CHANNEL_OPTION_BALANCE" = 0x10 can be selected to indicate that the target object is the host in the load balancing mode. The balanced mode is suitable for the client group to handle large-scale subscription and query conditions.

[0072] like Figure 7 The following figure shows the broadcast mode of the McebusServer server. The parameter process is consistent with the options of the above channel parameters. The McebusServer is suitable for broadcasting all session connections on the server consistently, such as sending the generated alarm message to all clients in a unified group.

[0073] like Figure 8 As shown in the figure, the filtering function "setFilter" is encapsulated in the three objects of McebusClient, McebusClientGroup and McebusServer, which mainly targets the signal parameter options, such as process number, host node name, source group number, source host number, etc. When the remote message source arrives at the "response-write" interface, it will be judged according to the filtering conditions. Messages that do not meet the conditions will be directly filtered out as discarded objects at the bottom of the bus, and then the filtered messages will be output through "DataDriver-callback".

[0074] like Fig. 9 As shown in the figure, when McebusClientGroup sends a message to the host, if there is a problem with the communication link (such as network interruption, connection timeout, etc.), the real-time message bus will immediately capture the exception and generate an exception message. After capturing the exception, the message bus will generate a specific type of exception message and use the macro MCE_MSG_ERROR_NETWORK to identify it. It is understandable that this macro is usually defined as an integer value or enumeration type, which is used to uniquely represent network exceptions in the message system. At this time, the relevant exception information needs to be pushed into the queue inside the bus, triggering the response function for the client to call for appropriate processing.

[0075] Specifically, the client sends a message to the server. During the sending process, the bus fails due to a network anomaly. At this time, the message bus will send a specific type of response message to the client. The message type is MCE_MSG_ERROR_NETWORK (macro definition). After receiving the message, the client determines the anomaly based on the message type and performs corresponding processing logic, including retrying to send the message, recording the error log, and displaying an error prompt to the user.

[0076] like Fig.10 As shown in the figure, when a host switching event occurs, a slave in the server cluster switches to the host, and the client group automatically sends an internal message. The internal exception is reflected in the form of MCE_MSG_SWITCHPRIMARY macro, and the relevant exception information needs to be pushed into the queue inside the real-time message bus to trigger the response function for the client to call for appropriate processing.

[0077] Specifically, when a host in the server cluster switches, the server cluster will send a specific type of response message, which will be transmitted through the internal queue of the message bus and finally sent to the client. The message type is MCE_MSG_SWITCHPRIMARY (macro definition). After receiving it, the client determines the service host switch based on the message type and performs corresponding processing logic.

[0078] like Fig.11 As shown, the real-time message bus of the present invention encapsulates a thread-level queue, that is, supports the FIFO common queue mode and the LIFO stack mode, forming two composite modes. When the message priority is particularly high, the caller can choose to fill the channel parameter option option, that is, "CHANNEL_OPTION_URGENT" = 0x20 is sent first.

[0079] Specifically, the encapsulated queue is a thread-level concurrent model queue that can ensure secure scheduling access control between different thread tasks. The queue supports FIFO (First Input First Output) or LIFO (Last Input First Output) combination modes. The two models have different usage scenarios. FIFO pushes messages into the tail of the queue according to the time sequence, and LIFO pushes messages into the head of the queue with the highest priority according to the urgency (URGENT) of the internal messages. It is understandable that in the process of messages entering the queue, some messages have a higher degree of urgency, and the messages can be placed at the head of the queue so that the system can process them with priority, such as control commands.

[0080] Specifically, the queue supports FIFO queue mode and LIFO stack mode. On this basis, the priority of the message can also be configured through the priority option in the message parameters (fill in "CHANNEL_OPTION_URGENT" = 0x20). According to the priority option of the message, the message is added to the appropriate position of the queue and can be sent first.

[0081] In the present invention, the queue model encapsulated by the real-time message bus supports the extended defined message format and has thread-level safe access operations, and can provide efficient thread-safe input and output functions.

[0082] Preferably, in a specific embodiment of the present invention, the present invention can adapt to the needs of different programming languages, including native C++ object-oriented programming, and can also implement a JNI interface calling method to provide support for JAVA programming language interface functions.

[0083] Furthermore, due to factors such as network or communication, the real-time message bus may be delayed or blocked during the creation or sending of a call, and the real-time message bus of the present invention has an overflow time setting method, and the overflow time can be customized. When a call exceeds the set overflow time during the creation or sending process, the system will perform corresponding processing to avoid long waiting or blocking. Specifically, in this embodiment, a setTimeout function interface is provided to set the creation or sending delay time parameter.

[0084] Furthermore, according to the requirements of network information security, in order to ensure the session connection between the client and the server, the source group number and host number security access permission policy is enhanced, a whitelist access list is provided, and particularly sensitive data can be communicated based on the SSL (Secure Sockets Layer) plug-in.

[0085] Furthermore, the real-time message bus of the present invention can define an automatic compression function for the message transmission process, and utilize middleware or plug-ins to implement a compression algorithm to compress messages, thereby reducing the amount of data in the data transmission process, and by compressing data, reducing the bandwidth and transmission time required for transmission, thereby improving the efficiency and performance of network transmission.

[0086] Furthermore, the real-time message bus of the present invention is based on the C++ language according to the requirements of different programming languages, and encapsulates and adapts to the programming requirements of different languages, so that the object-oriented interface has cross-language functions.

[0087] In summary, the present invention provides an object-oriented real-time message bus implementation method, which can be published in the form of an independent component driver library, is oriented to a connected communication mechanism, has no restrictions on the length of the transmitted data packet, supports diversified channel parameter configuration, supports multiple communication modes, has concise configuration files, is flexible and convenient to deploy, and can meet large and complex distributed network communication requirements using a simple coding framework design.

[0088] Although the content of the present invention has been described in detail through the above preferred embodiments, it should be appreciated that the above description should not be considered as a limitation of the present invention. After reading the above content, it will be apparent to those skilled in the art that various modifications and substitutions of the present invention will occur. Therefore, the protection scope of the present invention should be limited by the appended claims.

Claims

1. An object-oriented real-time message bus implementation method, characterized in that: The real-time message bus provides a point-to-point or point-to-multipoint communication mode, and implements the required encapsulation function for the packaging class, thereby realizing a stream-oriented connected network mode; The real-time message bus is provided with multiple interfaces to realize message transmission between the client and the server; The real-time message bus defines and implements interfaces based on TCP / IP middleware, and each interface includes: a publishing factory interface object, a subscription request interface object, and a subscription response interface object; and the real-time message bus implements different interface functions through pure virtual functions, can effectively encapsulate different module object components, and polymorphically separates the object-oriented interface from the implementation to perform asynchronous communication; The real-time message bus supports adaptive compilation for different operating systems, so that the object-oriented interface has cross-platform functions; Wherein, when the real-time message bus transmits a message, the structure of the message includes: a channel header, a message type and a message body.

2. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The channel header includes source group number, source host number, process number, node name and option configuration; The message type includes string, XML, JSON or Protobuf.

3. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The communication modes include: master-slave communication mode, broadcast communication mode and balanced communication mode.

4. The object-oriented real-time message bus implementation method according to claim 3, characterized in that: In the master-slave communication mode, the real-time message bus can complete the sending request message of the master or slave, and when executing the sending request message, it is executed in order of priority; In the broadcast communication mode, the mode sends the message to all recipients, so as to send the same message or command to all client groups; In the balanced communication mode, a balancing factor is set in the mode to distribute requests to multiple client groups to balance the load and improve performance.

5. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The interface mode is designed in a distributed remote procedure call manner, and the distributed remote procedure call is implemented using a callback function.

6. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The publishing factory interface object is used to create or obtain resources or objects related to the publish-subscribe mode; The subscription request interface object is an object created by the server, which contains the client subscription information or specific content of the request; The subscription response interface object is an object created inside the client to encapsulate response data or callback function and notify the client that the subscription information has been successfully subscribed.

7. The object-oriented real-time message bus implementation method according to claim 6, characterized in that: The publishing factory interface object is called and accessed by the client to implement initialization and establish communication with the server; The server returns the created subscription request interface object to the client for use. The client sends a subscription request or performs other related operations through the subscription request interface object. The client passes the pointer of the internally created subscription response interface object as a parameter to the server for use, thereby realizing the remote process callback mode between the client and the server.

8. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The pure virtual functions include: create, destroy, send and receive, which are respectively to create an object, destroy an object, send a message and receive a message.

9. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus can immediately capture the exception when a problem occurs in the communication link, generate an exception message and mark it, and then perform corresponding processing through the client.

10. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus encapsulates a thread-level concurrent model queue, supporting the FIFO common queue mode and the LIFO stack mode.

11. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus can set an overflow time when the network or communication is delayed or blocked. Once the set overflow time is exceeded, the system is notified to perform corresponding processing to avoid long waiting or blocking.

12. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus can utilize middleware or plug-ins to implement a compression algorithm to compress messages and reduce the amount of data in the message transmission process.

13. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus communicates confidential messages based on an SSL plug-in and provides a whitelist access list to ensure communication security.

14. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus can be implemented based on the JNI interface calling method.

15. The object-oriented real-time message bus implementation method according to claim 1, characterized in that: The real-time message bus can filter messages through a filtering function and output the filtered messages.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the object-oriented real-time message bus implementation method according to any one of claims 1 to 15 is implemented.

17. An electronic device, characterized in that: The invention comprises a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the object-oriented real-time message bus implementation method according to any one of claims 1 to 15 is implemented.

Images