WO2023200506A1

WO2023200506A1 - Using a wrapper to modify or augment the capabilities of a message broker

Info

Publication number: WO2023200506A1
Application number: PCT/US2023/011799
Authority: WO
Inventors: Peter Gregg Miller; David Michael Sauntry; Kevin Thomas Damour
Original assignee: Microsoft Technology Licensing, Llc
Priority date: 2022-04-14
Filing date: 2023-01-29
Publication date: 2023-10-19

Abstract

Methods, systems, apparatuses, and computer-readable storage mediums are described for tailoring the capabilities of a message broker for Internet of Things (IoT) messages. In an example system, a wrapper identifies a first communication interface utilized by an IoT device and a second communication interface utilized by a message broker. The wrapper determines a difference between the interfaces and generates at least one of a modified publish message or a modified subscribe message based at least on the difference. The modified publish message is generated from a publish message received from the IoT device. The modified subscribe message is generated from a subscribe message received from the message broker. The wrapper transmits at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the IoT device using the first communication interface.

Description

USING A WRAPPER TO MODIFY OR AUGMENT THE CAPABILITIES OF A MESSAGE BROKER

BACKGROUND

In certain types of messaging environments, client devices can be a publisher or a subscriber, or both, of messages of a given topic. In such environments, a client device sending a message (e.g., a publisher) publishes a message to a topic. The message is received by a message broker responsible for determining which subscribers should receive the message and routing the message to those subscribers. In this manner, once a publisher publishes a message to the topic, subscribers of a topic filter that includes that topic receive the message through the broker.

These messaging environments typically require that the client device communicate with the broker over a particular protocol or implement certain functionality. If a different protocol or different functionality is desired, reconfiguration of the broker or even utilization of a different type of broker is needed, making it burdensome to tailor a messaging system to the needs of a particular environment.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Methods, systems, apparatuses, and computer-readable storage mediums are described for tailoring the capabilities of a message broker for Internet of Things (loT) messages. In an example system, a wrapper identifies a first communication interface utilized by an loT device and a second communication interface utilized by a message broker. The wrapper determines a difference between the first communication interface and the second communication interface. The wrapper generates at least one of a modified publish message or a modified subscribe message. The modified publish message is generated based at least on the difference for transmission to the message broker using the second communication interface, where the modified publish message is generated from a publish message received from the loT device using the first communication interface. The modified subscribe message is generated based at least on the determined difference for transmission to the loT device using the first communication interface, where the modified subscribe message is generated from a subscribe message received from the message broker using the second communication interface. The wrapper transmits at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface. Further features and advantages of embodiments, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the methods and systems are not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

FIG. 1 shows a block diagram of an example system for tailoring the capabilities of a message broker, in accordance with an example embodiment.

FIG. 2 shows a flowchart of a method for tailoring the capabilities of a message broker for loT messages, in accordance with an example embodiment.

FIG. 3 shows a flowchart of a method for generating a modified publish message, in accordance with an example embodiment.

FIG. 4 shows a flowchart of a method for generating a modified subscribe message, in accordance with an example embodiment.

FIG. 5 shows a flowchart of a method for wrapping a message broker, in accordance with an example embodiment.

FIG. 6 shows a flowchart of a method for authenticating a wrapper to a message broker, in accordance with an example embodiment.

FIG. 7 is a block diagram of an example processor-based computer system that may be used to implement various embodiments.

The features and advantages of the embodiments described herein will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION

I. Introduction

The following detailed description discloses numerous example embodiments. The scope of the present patent application is not limited to the disclosed embodiments, but also encompasses combinations of the disclosed embodiments, as well as modifications to the disclosed embodiments.

References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the discussion, unless otherwise stated, adjectives such as “substantially” and “about” modifying a condition or relationship characteristic of a feature or features of an embodiment of the disclosure, are understood to mean that the condition or characteristic is defined to within tolerances that are acceptable for operation of the embodiment for an application for which it is intended. Furthermore, if the performance of an operation is described herein as being “in response to” one or more factors, it is to be understood that the one or more factors may be regarded as a sole contributing factor for causing the operation to occur or a contributing factor along with one or more additional factors for causing the operation to occur, and that the operation may occur at any time upon or after establishment of the one or more factors. Still further, where “based on” is used to indicate an effect being a result of an indicated cause, it is to be understood that the effect is not required to only result from the indicated cause, but that any number of possible additional causes may also contribute to the effect.

Numerous exemplary embodiments are described as follows. It is noted that any section/subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section/subsection. Furthermore, embodiments disclosed in any section/ subsection may be combined with any other embodiments described in the same section/ subsection and/or a different section/subsection in any manner.

II. Example Embodiments

In certain types of messaging environments, client devices can be a publisher or a subscriber, or both, of messages of a given topic or multiple topics. In such environments, a client device sending a message (e.g., a publisher) publishes a message to a topic. The message is received by a message broker responsible for determining which subscribers should receive the message and routing the message to those subscribers. In this manner, once a publisher publishes a message to the topic, subscribers of a topic filter that includes that topic receive the message through the broker.

Embodiments described herein address these issues in numerous ways. In an example, a message broker operates in tandem with another service referred to herein as a wrapper. The wrapper is configured to wrap the message broker such that a user of the message broker communicates with the wrapper, rather than directly with the broker. In example implementations, the wrapper implements a desired subset/superset (or a full set) and version of a communication protocol specification. The communication between the wrapper and the message may either be performed over a particular messaging protocol, or any other pooling protocol (e.g., a more efficient protocol) supported by the broker.

In one example system, a wrapper identifies a first communication interface utilized by an loT device and a second communication interface utilized by a message broker. The wrapper determines a difference between the first communication interface and the second communication interface. The wrapper generates at least one of a modified publish message or a modified subscribe message. The modified publish message is generated based at least on the difference for transmission to the message broker using the second communication interface, where the modified publish message is generated from a publish message received from the loT device using the first communication interface. The modified subscribe message is generated based at least on the determined difference for transmission to the loT device using the first communication interface, where the modified subscribe message is generated from a subscribe message received from the message broker using the second communication interface. The wrapper transmits at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface.

Tailoring the capabilities of a message broker as described herein has numerous advantages, including but not limited to improving the utilization of resources (e.g., computing, memory, and/or network resources) of computing devices. For instance, in accordance with disclosed techniques, a wrapper may tailor the functionalities provided by a message broker to the needs of a particular messaging environment, such as by adding, suppressing, or otherwise modifying functionalities that are desired to be exposed and utilized by an loT device (e.g., a client device). By tailoring the functionalities in such a manner, the client may be exposed to and/or utilize only the functionalities that are desired for implementation, rather than the set of functionalities provided by a message broker. For instance, the full set of functionalities may require that devices transmit and/or receive additional information when communicating with message brokers, which may also require additional processing and/or storage resources to process and/or store such information. By enabling a client device to use only the set of functionalities that are desired, the client need not unnecessarily utilize resources for implementing and/or supporting a set of functionalities that are not needed.

Further, techniques described herein also allow for client devices to communicate with message brokers using different interfaces. For instance, a client using a first version of a communication protocol associated with a first interface may be able to transmit messages to and from a message broker using a second version of the communication protocol associated with the second interface. In accordance with disclosed techniques, the interoperability of devices may be provided, enabling such devices to communicate with each other via a wrapper. As a result of providing such interoperability, the overall functioning of these devices is improved.

Still further, using a wrapper as described herein may improve the security of one or more components of a messaging system (e.g., a message broker). For instance, as described in greater detail below, a wrapper may be implemented as the endpoint to which client devices are coupled, while the wrapper authenticates itself to the message broker. Since the message broker (or endpoint associated therewith) may not directly be exposed to client devices, the security of the message broker may be improved.

As such, example embodiments are described herein that are directed to techniques for modifying or augmenting the capabilities (e.g., functionalities) of a message broker. For instance, FIG. 1 shows a block diagram of an example system for tailoring the capabilities of a message broker, in accordance with an example embodiment. As shown in FIG. 1, system 100 includes a client 102, a wrapper 106, a message broker 112, other publishing sources 114, an event hub 116, and a computing device 118. Client 102 includes a message 104. Client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 may be communicatively coupled by one or more networks or peer-to-peer connections (not shown). An example computing device that may incorporate the functionality of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 (or any subcomponents therein, whether or not illustrated in FIG. 1) is described below in reference to FIG. 2. It is noted that system 100 may comprise any number of devices, including those illustrated in FIG. 1 and optionally one or more further devices or components not expressly illustrated. System 100 is further described as follows.

A network that couples any of the components shown in FIG. 1 may include one or more of a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a combination of communication networks, such as the Internet, and/or a virtual network. In example implementations, client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 communicate via the network. In an implementation, any one or more of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 may communicate over the network via one or more application programming interfaces (API) and/or according to other interfaces and/or techniques. Client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 may each include at least one network interface that enables communications with each other. Examples of such a network interface, wired or wireless, include an IEEE 802.11 wireless LAN (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth™ interface, a near field communication (NFC) interface, etc. In some other examples, any one or more of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 may be coupled by one or more peer-to-peer connections that enables wired and/or wireless communications with each other. Further examples of network interfaces are described elsewhere herein.

Client 102 may include one or more computing devices of one or more users (e.g., individual users, family users, enterprise users, governmental users, etc.) that each comprise one or more applications, operating systems, virtual machines, storage devices, etc. that may transmit and/or receive message 104. Client 102 may be any type of stationary or mobile device, such as an Internet of Things (loT) device. As used herein, an loT device comprises any computing device that may connect to another computing device or system via a connection to a network (e.g., the Internet) or a peer-to-peer connection to send and receive data. In some implementations, an loT device includes one or more physical networking components for wirelessly connecting to the Internet for sending and receiving data (e.g., messages). Examples of client 102 include a vehicle (e.g., an electric vehicle) comprising computing functionality, a mobile computer or mobile computing device (e.g., a Microsoft ® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), a mobile phone (e.g., a cell phone, a smart phone such as an Apple iPhone, a phone implementing the Google® Android™ operating system, a Microsoft Windows® phone, etc.), a wearable computing device (e.g., a head-mounted device including smart glasses such as Google® Glass™, Oculus Rift® by Oculus VR, LLC, etc.), a camera, a home assistant device, a smart home device, an appliance, or other type of stationary or mobile device with network connectivity capabilities. Client 102 is not limited to a physical machine, but may include other types of machines or nodes, such as a virtual machine. In some implementations, client 102 may comprise one or more sensors for capturing information in or around client 102, including but not limited to a temperature sensor, a pressure sensor, an accelerometer, a gyroscope, an orientation sensor, an image sensor, a biometric sensor, or a global positioning system (GPS) sensor. Client 102 may interface with other components illustrated in FIG. 1 through APIs and/or by other mechanisms. Message 104 includes any set of information that is generated at client 102 for transmission to another entity (e.g., message broker 112) or information that is generated outside of client 102 (e.g., received 124 from other publishing sources 114) for transmission to client 102. In some implementations, message 104 may include a publish or a subscribe message in a publish- subscribe messaging environment. For instance, message 104 generated at client 102 (e.g., a publish message) may include information relating to conditions local to client 102 (e.g., a condition, such as a weather condition, based on sensor data at client 102). In other examples, message 104 generated outside of client 102 may include any information relating to a topic filter to which client 102 has subscribed, such as alerts relating to an environment in which client 102 is present (e.g., weather alerts). Message 104 may be associated with a message topic (e.g., a topic may be embedded within or along with message 104). The topic may correspond to a grouping of similar types of message (e.g., similar in content, publishing source, location data, associated user, etc.). In examples, messages received by client 102 may be generated by any device, including but not limited to other clients, other publishing sources 114 (which may include any external device or service that generates a messages), or any other device or service not expressly illustrated in FIG. 1. These examples are only illustrative, and it is understood that message 104 may include any type of information generated by client 102 and/or by other publishing sources.

Wrapper 106 may be configured to encode information transmitted between client 102 and message broker 112 such that client 102 and message broker 112 may communicate with a desired set of functionalities. For instance, client 102 and message broker 112 may be configured to communicate with different specifications, message broker 112 may comprise one or more capabilities (e.g., functionalities) that should be or should not be exposed to client 102, or it may be desired that message broker 112 be augmented with one or more additional capabilities not otherwise provided by message broker 112 itself. For example, message broker 112 may be designed or implemented by a different party and/or may not serve the needs of a particular environment (e.g., a given set of client devices). As described in greater detail below, wrapper 106 may be implemented to tailor the functionalities of message broker 112 based on the needs and/or desires of a particular environment, thereby enabling communications between client 102 and message broker 112 using a desired set of functionalities. Wrapper 106 may augment the features of message broker 112 (e.g., by implementing an additional functionality that message broker 112 does not otherwise provide), remove or suppress a feature provided by message broker 112 (e.g., prevent a particular feature from being exposed to customers), or implement a protocol used by client 102 that is different than a protocol used by message broker 112 (e.g., downprotocol wrapping or up-protocol wrapping, and/or any combination thereof). The foregoing list is illustrative only, and other modifications may be implemented by wrapper 106.

For instance, wrapper 106 may identify a fist communication interface utilized by client 102 and a second communication interface utilized by message broker 112. Wrapper 106 may determine a difference between the first and second communication interfaces. In some implementations, the identification of the communication interfaces and/or determination of the difference may be performed on-the-fly or in real-time. In other implementations, the identification and/or determination may be based on predetermined knowledge regarding the communication interfaces utilized by client 102 and message broker 112. Wrapper 106 may be configured to generate a modified message for transmission based at least on the determined difference. For instance, wrapper 106 may generate a modified publish message based at least on the difference for transmission to message broker 112 using the second communication interface, where the modified publish message is generated from a publish message received from client 102. In other examples, wrapper 106 may generate a modified subscribe message based at least on the difference for transmission to client 102 using the first communication interface, where the modified subscribe message is generated from a subscribe message received from message broker 112. Wrapper 106 may transmit the modified publish message to message broker 112 using the second communication interface and/or the modified subscribe message to client 102 using the first communication interface. In some implementations, the first communication interface is associated with a first version of a communication protocol (e.g., a Message Queueing Telemetry Transport (MQTT) protocol), and the second communication interface is associated with a second version of the same communication protocol. In other words, the first and second interfaces may be associated with different versions of the same communication protocol. Further details and examples regarding the operation of wrapper 106 will be discussed below.

Message broker 112 may be configured to receive at least message 104 and/or a topic associated with message 104. In examples, message broker 112 determines whether message 104 is allowed to be published to the topic associated with the message based on a suitable authorization check. If message broker 112 determines that message 104 is allowed to be published, message broker 112 processes the message. If message broker 112 determines that message 104 is not allowed to be published, message broker 112 rejects the message for publishing in the designated topic.

While the above example is described with respect to publishing a message 104 received from client 102, similar techniques may be employed for messages to which client 102 has subscribed. For instance, when a message arrives at message broker 112 for a given topic, message broker 112 may determine whether client 102 has subscribed to receiving messages for a topic filter (which may include a wildcard) that includes the topic. If client 102 has subscribed to messages for the topic filter, message broker 112 may cause a message within the scope of the topic filter to be transmitted to client 102. Further details and examples regarding the operation of message broker 112 will be discussed below.

In some implementations, message broker 112 may publish 128 one or more messages to event hub 116. It is noted that publishing the message(s) to event hub 116 may comprise any suitable technique for providing or otherwise transmitting the message(s) to event hub 116 and is not limited to publishing a message as that term is used herein. Event hub 116 may comprise a data ingestion service configured to receive messages (and/or any other information) and transmit 126 one or more of such messages to other devices, including client 102 and/or computing device 118. Computing device 118 may be any type of stationary or mobile device, similar to client 102 as described above. For instance, computing device 118 may be configured to receive message 104 that is generated local to client 102 (e.g., an alert generated at client 102).

Implementations are not limited to the illustrative arrangement shown in FIG. 1. For instance, client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 may not be separate or remotely located from each other. In some examples, any one or more of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 (or any subcomponents therein) may be part of or accessible via the same computing device or distributed across a plurality of devices. Furthermore, it is understood that each of the components illustrated in FIG. 1 need not be present in all implementations. Furthermore, message broker 112 may publish messages directly to one or more other devices without event hub 116. System 100 may also comprise any number of additional devices not shown in FIG. 1 that may be coupled in any manner in accordance with the disclosed techniques.

The following descriptions are intended to further describe the above example embodiments and describe additional example embodiments in which implementations may be provided. Furthermore, the descriptions that follow explain additional context for such example embodiments and details relating to the implementations. The descriptions that follow are intended to illustrate various aspects and/or benefits that may be achieved based on techniques described herein, and are not intended to be limiting. Accordingly, while additional example embodiments are described, the features described below are not required in all implementations. In example embodiments, techniques may be implemented by or in one or more of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, and computing device 118 (or any of their subcomponents). Other structural and operational implementations will be apparent to persons skilled in the relevant art(s) based on the following discussion.

As described above, disclosed techniques relate to augmenting, modifying, and/or suppressing functionalities of a message broker using a wrapper. In examples, message broker may comprise a Message Queueing Telemetry Transport (MQTT) broker and interfaces between different components and/or services shown in FIG. 1 may be in accordance with any one or more versions of an MQTT protocol. In disclosed techniques, methods are described to support different protocol versions and/or suppress, modify, or extend functionality for a message broker. While examples are described herein with respect to MQTT message brokers and MQTT protocols, these examples are illustrative only, and techniques may be implemented in accordance with other interfaces and/or protocols as appreciated by those skilled in the art.

The approaches described herein may be used with any message broker and are not specific to any particular broker, protocol, or interface. Example embodiments may enable a party to develop and use functionality independent of the specific message broker used. Accordingly, modified interfaces as described may be ported to be used with any broker in accordance with the disclosed techniques.

In implementations, message broker 112 (e.g., an MQTT broker) may comprise a program or service that implements all or a part of a broker specification (e.g., an MQTT protocol specification). In implementations where multiple versions of a protocol specification exist that may be implemented, a broker may select a particular one of the versions for implementation. In some situations, a broker may implement a subset of the protocol specification, rather than a full version of the specification. Thus, message broker 112 may implement all or part of a specification. While examples are described herein with respect to message broker 112 implementing a protocol specification, it is understood that techniques may be applied in other situations as well. For instance, message broker 112 may comprise any other program or service for receiving and/or routing messages between publishers and subscribers in a messaging environment (e.g., programs that are not a part of a protocol specification, not open source, etc.). Thus, disclosed techniques may be applied in various environments in which a message broker is present.

In example systems, users of MQTT brokers connect to the broker using an “MQTT client.” An MQTT client is a program that implements the client side of the MQTT protocol specification. In examples, an MQTT client may be implemented in client 102 described herein. MQTT clients may optionally implement an entire protocol specification, or a modified version thereof (e.g., by implementing only a subset of the entire protocol specification or implementing additional features).

In some examples, a broker may be selected for a project (e.g., a particular implementation) which does not fully meet one or more objectives of the project. Non-limiting examples include a broker implementing an older version of an MQTT specification, a broker only implementing part of an MQTT specification, or a desire to enhance functionality that goes beyond what a protocol specifies or provides. Other examples also include a desire to suppress part of the protocol, such as removing the ability to expose certain types of messages or functionalities. An example of this suppression is where the goals of a project seek to avoid support for Quality-of-Service (QoS) 2 messages. With techniques described herein, such goals may still be achieved even where the broker provides such a functionality.

Example embodiments comprise a service (e.g., wrapper 106) used in tandem with message broker 112. As described herein, wrapper 106 may be responsible for wrapping message broker 112 such that client 102 communicates 120 with wrapper 106 rather than directly communicating with message broker 112, and wrapper 106 communicates 122 with message broker 112. Client 102 may be configured (e.g., programmed) to communicate with a particular endpoint. Rather than configuring client 102 to communicate with an endpoint (e.g., a uniform resource locator (URL), a network address, etc.) associated with message broker 112, client 102 may instead be configured to communicate with an endpoint associated with wrapper 106. In other words, in an example system, the endpoint associated with wrapper 106 is exposed to the clients, while the endpoint associated with message broker 112 is not. In this manner, client 102 may transmit messages and other information discussed herein directly to wrapper 106, rather than to message broker 112. Ensuring that communications flow directly to wrapper 106 (rather than to message broker 112) may be enforced in various ways. In one implementation, network isolation of message broker 112 may performed such that callers (e.g., clients) other than wrapper 106 cannot reach message broker 112. Such a technique may be carried out, for instance, by configuring message broker 112 to be on a private network. In another implementation, authorization to message broker 112 may be locked down such that callers other than wrapper 106 are not able to use message broker 112. For example, message broker 112 may enforce an authentication method made available and used only by wrapper 106. Examples include, but are not limited to, providing a certificate available only to the wrapper, a token signed by an authority that will only grant it to wrapper 106 and no other entity, credentials (e.g., usemame/password) only known to wrapper 106, etc. Any of the foregoing techniques may be implemented individually, or in combination (e.g., layered) to further enhance security (e.g., defense-in-depth).

Wrapper 106 may implement a desired set (e.g., a subset, a full set, a full set with additional features, etc.) of features and/or a particular version of an MQTT protocol specification. In some implementations, wrapper 106 may also be configured to optionally terminate a Transport Layer Security (TLS) protocol. The communication (e.g., the interface) between wrapper 106 and message broker 112 may either be performed over an MQTT protocol, or any other type of protocol supported by the broker.

An illustrative example in which disclosed techniques may be implemented is where a user desires to use a particular message broker that supports a particular version of an MQTT specification (e.g., MQTT version 3.1.1), but the user’s goals are to expose a different version of the MQTT specification (e.g., MQTT version 5) to their customers. In such a situation, wrapper 106 may implement MQTT version 5 to communicate with client 102, but use MQTT version 3.1.1 to communicate with message broker 112. Examples are not limited this type of scenario, and may include other forms in which the goals of the customer or client 102 are different than the features or capabilities provided by message broker 112.

Wrapper 106 may operate in various ways. For instance, the interface (e.g., signatures, behaviors, semantics, etc.) that is desired to be exposed to client devices may be identified. Such an interface may serve as the interface between client 102 and wrapper 106. The interface that is utilized by message broker 112 is also identified. For instance, this interface (i.e., the interface to be provided between wrapper 106 and message broker 112) may be based on the design, properties, and/or characteristics of message broker 112 itself (which may be developed by a third party, may not be easily modified, or may not be modified at all). Wrapper 106 may determine a different (e.g., a delta) between the two interfaces and implement a wrapper that is able to communicate with client 102 using the interface desired to be exposed to the client, and with message broker 112 using the interface exposed by message broker 112. In this manner, wrapper 106 may be configured to enable a seamless or near-seamless communication between the two, without having to modify the functionality of the message broker. In this manner, client 102 may utilize an interface with a first set of functionalities (e.g., based on a first version of a messing protocol), while message broker 112 may utilize an interface with a second set of functionalities (e.g., based on a second version of a messaging protocol) different than the first set.

In one example implementation, wrapper 106 may perform a “down-protocol” wrapping or an “up-protocol” wrapping function. For instance, in down-protocol wrapping, wrapper 106 may enable support for a newer protocol (e.g., a newer version) than the protocol supported by message broker 112. In one example, error codes present in MQTT 5 may not be fully represented MQTT 3.1.1. In such a situation, an MQTT 5 wrapper may still comply with the specification by implementing one or more generic error codes. In another example, wrapper 106 may encode error code information from an MQTT 5 message in one or more portions of an MQTT 3.1.1 message (e.g., in a payload) and transmit the encoded message to message broker 112. When the message is received from message broker 112 (e.g., for transmission to a subscriber), wrapper 106 may extract the encoded information from the MQTT 3.1.1 message, place the encoded information in the appropriate locations of an MQTT 5 packet, and restore the MQTT 5 message for transmission to a subscriber device. In this manner, wrapper 106 may enable communication between client 102 and message broker 112, despite both utilizing different protocols. Other functionalities (e.g., response topics, user properties, or other specific fields in the MQTT 5 or other specifications) can be wrapped by wrapper 106 in a payload (or any other portion) of an MQTT 3.1.1 message, as wrapper 106 controls both the ingress and egress of data between client 102 and message broker 112, When egressing data out to subscribers, wrapper 106 may be configured to take the payload-encoded MQTT 5-specific fields and place them in the appropriate location of the packet. Any suitable techniques for encoding information into the payload of a packet are contemplated, including but not limited to techniques utilizing Protobuf developed by Google LLC, JavaScript Object Notation (JSON), or any custom binary.

In another example implementation, there may be a desire to implement functionality that goes beyond the functionality provided by the broker (e.g., based on a particular version of the MQTT specification used by the broker, or any other functionality). In other words, disclosed techniques may be utilized to add an additional functionality that is not part of the message broker 112, but is part of the interface exposed to the client 102. For instance, it may be desired to include functionality to publish a client’s identifier (e.g., a “Clientld”) along with a message received from the client. In accordance with disclosed techniques, wrapper 106 may enrich a message (e.g., an MQTT 5 message) with a user property indicating the publishing client’s Clientld. This, however, is only an illustrative example, and wrapper 106 may enrich an incoming message or an outgoing message with any desired property, field, header, or other information, since wrapper 106 is configured to control the ingress and egress of messages. In some other implementations, wrapper 106 may also be configured to remove or modify (e.g., alter a functionality that is present in an incoming or outgoing message) properties from a message, if desired.

In another example implementation, message broker 112 may implement one or more features beyond what a user desires to expose to their customers. For example, an MQTT broker may implement a Quality-of-Service (QoS) 2 functionality, but the user may not desire to expose such functionality to their customers. In such a situation, wrapper 106 may be configured to remove such functionality by not exposing it to users, or even providing an appropriate error if such a nonpermitted functionality is leveraged. In this manner, the entity implementing and/or designing wrapper 106 may need to support only a subset of features that are desired to be used, which may simplify the maintenance burden for the entity.

Wrapper 106 may operate in various ways to tailor the capabilities of a message broker. For instance, wrapper 106 may operate according to FIG. 2. FIG. 2 shows a flowchart 200 of a method for tailoring the capabilities of a message broker for loT messages, in accordance with an example embodiment. For illustrative purposes, flowchart 200 and wrapper 106 are described as follows with respect to FIG. 1. While example embodiments are described with respect to components of system 100 and flowchart 200, these examples are illustrative. Flowchart 200 begins with step 202. In step 202, a first communication interface utilized by an loT device is identified. For instance, with reference to FIG. 1, wrapper 106 is configured to identify a first communication interface utilized by client 102. In other words, wrapper 106 may identify a communication interface between client 102 and wrapper 106 as the first communication interface.

In step 204, a second communication interface utilized by a message broker is identified. For instance, with reference to FIG. 1, wrapper 106 is configured to identify a second communication interface utilized by message broker 112. In other words, wrapper 106 may identify a communication interface between wrapper 106 and message broker 112 as the second communication interface.

In examples, identification of the first and second communication interfaces may be carried out in various ways. In some implementations, wrapper 106 may identify one or both interfaces based on predetermined knowledge (e.g., information stored or accessible to wrapper 106 that identifies the communication interface that is used or intended to be used, such as documentation relating to each interface used). In other examples, wrapper 106 may identify one or both communication interfaces on the fly, or in real time. For instance, wrapper 106 may be configured to analyze a message originating from client 102 and/or message broker 112 to identify the communication interface (e.g., based on the semantics used in the messages).

In implementations, the first communication interface and second communication interface may be associated with one or more versions of a communication protocol. For instance, the first communication interface may be associated with a first version of a communication protocol (e.g., an MQTT protocol), and the second communication interface is associated with a second version of the same communication protocol. In some implementations, the first and second communication interfaces may be associated with different communication protocols (e.g., an MQTT protocol and a non-MQTT protocol).

In step 206, a difference between the first communication interface and the second communication interface is determined. For instance, with reference to FIG. 1, wrapper 106 is configured to determine a difference between the first communication and the second communication interface. In one example, the difference may comprise an identification of one or more functionalities that are present in communications from one of client 102 or message broker 112 but are not present in communications from the other. In another example, the difference may comprise an identification of one or more functionalities that are desired to be implemented or withheld from one of client 102 or message broker 112. In other examples, the difference may comprise an identification of one or more differences in a formatting or structure of packets used in the communication between client 102 and wrapper 106, and between wrapper 106 and message broker 112. These examples are only illustrative, and other differences are also contemplated as described herein.

In step 208, at least one of a modified publish message or a modified subscribe message is generated based at least on the determined difference. For instance, with reference to FIG. 1, wrapper 106 is configured to generate at least one of a modified publish message or a modified subscribe message based at least on the determined difference. In examples, wrapper 106 may generate the modified publish message based at least on the determined difference for transmission to message broker 112 using the second communication interface, where the modified publish message is generated from a publish message received from client 102 using the first communication interface. Wrapper 106 may generate a modified subscribe message based at least on the determined difference for transmission to client 102 using the first communication interface, where the modified subscribe message is generated from a subscribe message received from message broker 112 using the second communication interface.

A modified publish message and/or a modified subscribe message may be generated in various ways as described herein. For instance, wrapper 106 may be configured to identify a payload of a message received from one entity (e.g., client 102 or message broker 112) that is encoded with additional information (e.g., a payload encoded with MQTT 5-specific fields), and identify one or more locations of another packet to place such encoded information into. In other examples, wrapper 106 may enrich one or more fields of a message with additional information (e.g., by encoding the message with additional fields, properties, etc.). These examples are only illustrative, and other examples are contemplated and/or described herein.

In step 210, at least one of the modified publish message is transmitted to the message broker using the second communication interface or the modified subscribe message is transmitted to the loT device using the first communication interface. For instance, with reference to FIG. 1, wrapper 106 is configured to transmit at least one of the modified publish message to message broker 112 using the second communication interface, or transmit the modified subscribe message to client 102 using the first communication interface.

As discussed above, wrapper 106 may be configured to modify a publish message received from a client device. For instance, FIG. 3 shows a flowchart 300 of a method for generating a modified publish message, in accordance with an example embodiment. In an implementation, the method of flowchart 300 may be implemented by wrapper 106. FIG. 3 is described with continued reference to FIG. 1. Other structural and operational implementations will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart 300 and system 100 of FIG. 1.

Flowchart 300 begins with step 302. In step 302, a modified publish message is generated by modifying a payload of the publish message. In some implementations, the modifying the payload comprises at least one of adding information to the payload, removing information from the payload, or modifying information in the payload. For instance, with reference to FIG. 1, wrapper 106 may be configured to generate the modified publish message by modifying a payload of a publish message received from client 102, where the modifying the publish message comprises adding information to the payload of the publish message, removing information from the payload of the publish message, or modifying information in the payload of the publish message.

As an illustration, wrapper 106 may encode one or more additional items of information (e.g., a user property) into the payload of a publish message such that message broker 112 may receive a payload-encoded message from wrapper 106. Because wrapper 106 may be configured to control the ingress and egress of messages, wrapper 106 may later receive the payload-encoded message from message broker 112 and determine how to appropriately generate a modified subscribe message from the payload-encoded message. This example is illustrative only, and other examples are described herein for modifying a publish message by wrapping it with based on the difference between the two communication interfaces.

As discussed above, wrapper 106 may be configured to modify a subscribe message received from a message broker. For instance, FIG. 4 shows a flowchart 400 of a method for generating a modified subscribe message, in accordance with an example embodiment. In an implementation, the method of flowchart 400 may be implemented by wrapper 106. FIG. 4 is described with continued reference to FIG. 1. Other structural and operational implementations will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart 400 and system 100 of FIG. 1.

Flowchart 400 begins with step 402. In step 402, a subscribe message is received from a message broker. For instance, with reference to FIG. 1, wrapper 106 may receive a subscribe message from message broker 112. In examples, the subscribe message may comprise a message that was previously transmitted by wrapper 106 to message broker 112, which may include a payload that is encoded with information.

In step 404, a payload of the subscribe message is extracted. For instance, wrapper 106 may be configured to extract a payload of the subscribe message received from message broker 112. As discussed above, the payload may comprise information encoded therein (e.g., response topics, user properties, or other specific fields in a particular version of a specification) that was initially encoded by wrapper 106. Since wrapper 106 is configured to control the ingress and egress of data, wrapper 106 may obtain the payload-encoded subscribe message and extract the information that was encoded therein.

In step 406, a modified subscribe message is generated based on the extracted payload. For instance, with reference to FIG. 1, wrapper 106 is configured to generate a modified subscribe message based at on the extracted payload. For example, where a payload encoded message is obtained, wrapper 106 may take the payload encoded information (e.g., information corresponding to specific fields or properties in a specification), and place the information in an appropriate location of a subscribe packet (e.g., in a portion of a header or any other portion of the subscribe packet) to generate the modified subscribe message. In this manner, wrapper 106 may be configured to modify a message to include information encoded therein, extract such information at a message delivery time (e.g., when egressing data to subscribers), and generate a modified subscribe message in accordance with a communication interface utilized by client 102 with the appropriate information therein (e.g., encoded information that was extracted from a payload of the subscribe message obtained from message broker 112).

As discussed above, wrapper 106 may be communicatively coupled to a client device in implementations. For instance, FIG. 5 shows a flowchart 500 of a method for wrapping a message broker, in accordance with an example embodiment. In an implementation, the method of flowchart 500 may be implemented by wrapper 106. FIG. 5 is described with continued reference to FIG. 1. Other structural and operational implementations will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart 500 and system 100 of FIG. 1.

Flowchart 500 begins with step 502. In step 502, a message broker is wrapped such that an loT device is communicatively coupled to an endpoint associated with the wrapper. For instance, with reference to FIG. 1, wrapper 106 is configured to wrap message broker 112 such that client 102 is communicatively coupled to an endpoint associated with wrapper 106 rather than an endpoint associated with message broker 112. In some implementations, message broker 112 may not expose an endpoint for entities other than wrapper 106 to connect to it (e.g., via network isolation, configuring message broker to be on a private network, etc.), thereby allowing only wrapper 106 to couple to it. In this manner, wrapper 106 may be enabled to control the ingress and egress of data flowing to and from message broker 112, thereby allowing wrapper 106 to selectively encode portions of messages provided to the broker to tailor the functionality thereof.

As discussed above, wrapper 106 may perform various types of authentication with message broker 112. For instance, FIG. 6 shows a flowchart 600 of a method for authenticating a wrapper to a message broker, in accordance with an example embodiment. In an implementation, the method of flowchart 600 may be implemented by wrapper 106. FIG. 6 is described with continued reference to FIG. 1. Other structural and operational implementations will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart 600 and system 100 of FIG. 1. Flowchart 600 begins with step 602. In step 602, a wrapper is authenticated to a message broker. For instance, with reference to FIG. 1, wrapper 106 may be configured to authenticate itself to message broker 112. Such authentication may be carried out in various ways. For instance, message broker 112 may make an authentication method available only to wrapper 106 and no other devices, such that only wrapper 106 is able to authenticate itself to the broker. Examples include a certificate available only to wrapper 106, a token granted only to wrapper 106, credentials known only to the wrapper, or other techniques that wrapper 106 may utilize that may not be available for other devices. In this manner, message broker 112 may ensure that callers other than wrapper 106 may not reach message broker 112.

III. Example Computer System Implementation

Client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, computing device 118, flowchart 200, flowchart 300, flowchart 400, flowchart 500, and/or flowchart 600 may be implemented in hardware, or hardware combined with one or both of software and/or firmware. For example, client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, computing device 118, flowchart 200, flowchart 300, flowchart 400, flowchart 500, and/or flowchart 600 may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium.

Alternatively, client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, computing device 118, flowchart 200, flowchart 300, flowchart 400, flowchart 500, and/or flowchart 600 may be implemented as hardware logic/electrical circuitry.

For instance, in an embodiment, one or more, in any combination, of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, computing device 118, flowchart 200, flowchart 300, flowchart 400, flowchart 500, and/or flowchart 600 may be implemented together in a system on a chip (SoC). The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits, and may optionally execute received program code and/or include embedded firmware to perform functions.

FIG. 7 depicts an exemplary implementation of a computing device 200 in which embodiments may be implemented. For example, client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, computing device 118, flowchart 200, flowchart 300, flowchart 400, flowchart 500, and/or flowchart 600 (and/or any of the steps of flowcharts 200, 300, 400, 500, and/or 600) may be implemented in one or more computing devices similar to computing device 700 in stationary or mobile computer embodiments, including one or more features of computing device 700 and/or alternative features. The description of computing device 700 provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

As shown in FIG. 7, computing device 700 includes one or more processors, referred to as processor circuit 702, a hardware accelerator 703, a system memory 704, and a bus 706 that couples various system components including system memory 704 to processor circuit 702 and hardware accelerator 703. Processor circuit 702 and/or hardware accelerator 703 is an electrical and/or optical circuit implemented in one or more physical hardware electrical circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a central processing unit (CPU), a microcontroller, a microprocessor, and/or other physical hardware processor circuit. Processor circuit 702 may execute program code stored in a computer readable medium, such as program code of operating system 730, application programs 732, other programs 734, etc. Bus 706 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. System memory 704 includes read only memory (ROM) 708 and random-access memory (RAM) 710. A basic input/output system 712 (BIOS) is stored in ROM 708.

Computing device 700 also has one or more of the following drives: a hard disk drive 714 for reading from and writing to a hard disk, a magnetic disk drive 716 for reading from or writing to a removable magnetic disk 718, and an optical disk drive 720 for reading from or writing to a removable optical disk 722 such as a CD ROM, DVD ROM, or other optical media. Hard disk drive 714, magnetic disk drive 716, and optical disk drive 720 are connected to bus 706 by a hard disk drive interface 724, a magnetic disk drive interface 726, and an optical drive interface 728, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAMs, ROMs, and other hardware storage media.

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system 730, one or more application programs 732, other programs 734, and program data 736. Application programs 732 or other programs 734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing any of the features of client 102, wrapper 106, message broker 112, other publishing sources 114, event hub 116, computing device 118, flowchart 200, flowchart 300, flowchart 400, flowchart 500, and/or flowchart 600 and/or further embodiments described herein.

A user may enter commands and information into computing device 700 through input devices such as keyboard 738 and pointing device 740. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, a touch screen and/or touch pad, a voice recognition system to receive voice input, a gesture recognition system to receive gesture input, or the like. These and other input devices are often connected to processor circuit 702 through a serial port interface 742 that is coupled to bus 706, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).

A display screen 744 is also connected to bus 706 via an interface, such as a video adapter 746. Display screen 744 may be external to, or incorporated in computing device 700. Display screen 744 may display information, as well as being a user interface for receiving user commands and/or other information (e.g., by touch, finger gestures, virtual keyboard, etc.). In addition to display screen 744, computing device 700 may include other peripheral output devices (not shown) such as speakers and printers.

Computing device 700 is connected to a network 748 (e.g., the Internet) through an adaptor or network interface 750, a modem 752, or other means for establishing communications over the network. Modem 752, which may be internal or external, may be connected to bus 706 via serial port interface 742, as shown in FIG. 7, or may be connected to bus 706 using another interface type, including a parallel interface.

As used herein, the terms "computer program medium," "computer-readable medium," and “computer-readable storage medium” are used to refer to physical hardware media such as the hard disk associated with hard disk drive 714, removable magnetic disk 718, removable optical disk 722, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media. Such computer-readable storage media are distinguished from and non-overlapping with propagating signals and communication media (do not include propagating signals and communication media). Communication media embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media, as well as wired media. Embodiments are also directed to such communication media that are separate and non-overlapping with embodiments directed to computer-readable storage media. As noted above, computer programs and modules (including application programs 732 and other programs 734) may be stored on the hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Such computer programs may also be received via network interface 750, serial port interface 742, or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device 700 to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of the computing device 700.

Embodiments are also directed to computer program products comprising computer code or instructions stored on any computer-readable medium. Such computer program products include hard disk drives, optical disk drives, memory device packages, portable memory sticks, memory cards, and other types of physical storage hardware.

IV. Further Example Embodiments

A system for tailoring the capabilities of a message broker for loT messages is disclosed herein. The system includes at least one processor circuit; and at least one memory that stores program code configured to be executed by the at least one processor circuit, the program code comprising: a wrapper configured to: identify a first communication interface utilized by an loT device; identify a second communication interface utilized by a message broker; determine a difference between the first communication interface and the second communication interface; generate at least one of: a modified publish message based at least on the determined difference for transmission to the message broker using the second communication interface, the modified publish message being generated from a publish message received from the loT device using the first communication interface, or a modified subscribe message based at least on the determined difference for transmission to the loT device using the first communication interface, the modified subscribe message being generated from a subscribe message received from the message broker using the second communication interface; and transmit at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface.

In one implementation of the foregoing system, the wrapper is configured to generate the modified publish message by modifying a payload of the publish message, the modifying the payload comprising at least one of adding information to the payload, removing information from the payload, or modifying information in the payload.

In another implementation of the foregoing system, the wrapper is configured to: receive, from the message broker, the subscribe message; extract a payload of the subscribe message; and generate the modified subscribe message based on the extracted payload.

In another implementation of the foregoing system, the first communication interface is associated with a first version of a communication protocol, and the second communication interface is associated with a second version of the communication protocol.

In another implementation of the foregoing system, the first version of the communication protocol comprises a first version of an MQTT protocol, and wherein the second version of the communication protocol comprises a second version of the MQTT protocol.

In another implementation of the foregoing system, the wrapper is configured to wrap the message broker such that the loT device is communicatively coupled to an endpoint associated with the wrapper.

In another implementation of the foregoing system, wrapper authenticates itself to the message broker.

A method for tailoring the capabilities of a message broker for loT messages is disclosed herein. The method includes: identifying a first communication interface utilized by an loT device; identifying a second communication interface utilized by a message broker; determining a difference between the first communication interface and the second communication interface; generating at least one of a modified publish message based at least on the determined difference for transmission to the message broker using the second communication interface, the modified publish message being generated from a publish message received from the loT device using the first communication interface, or a modified subscribe message based at least on the determined difference for transmission to the loT device using the first communication interface, the modified subscribe message being generated from a subscribe message received from the message broker using the second communication interface; and transmitting at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface.

In one implementation of the foregoing method, the generating the modified publish message comprises: modifying a payload of the publish message, the modifying the payload comprising at least one of adding information to the payload, removing information from the payload, or modifying information in the payload.

In another implementation of the foregoing method, the method further includes: receiving, from the message broker, the subscribe message; extracting a payload of the subscribe message; and generating the modified subscribe message based on the extracted payload.

In another implementation of the foregoing method, the first communication interface is associated with a first version of a communication protocol, and the second communication interface is associated with a second version of the communication protocol.

In another implementation of the foregoing method, first version of the communication protocol comprises a first version of an MQTT protocol, and wherein the second version of the communication protocol comprises a second version of the MQTT protocol.

In another implementation of the foregoing method, the method further includes wrapping the message broker via a wrapper, such that the loT device is communicatively coupled to an endpoint associated with the wrapper.

In another implementation of the foregoing method, the method further includes authenticating the wrapper to the message broker.

A computer-readable storage medium is disclosed herein. The computer-readable storage medium has program instructions recorded thereon that, when executed by at least one processor of a computing device, perform a method, the method comprising: identifying a first communication interface utilized by an loT device; identifying a second communication interface utilized by a message broker; determining a difference between the first communication interface and the second communication interface; generating at least one of: a modified publish message based at least on the determined difference for transmission to the message broker using the second communication interface, the modified publish message being generated from a publish message received from the loT device using the first communication interface, or a modified subscribe message based at least on the determined difference for transmission to the loT device using the first communication interface, the modified subscribe message being generated from a subscribe message received from the message broker using the second communication interface; and transmitting at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface.

In one implementation of the foregoing computer-readable storage medium, the generating the modified publish message comprises: modifying a payload of the publish message, the modifying the payload comprising at least one of adding information to the payload, removing information from the payload, or modifying information in the payload.

In another implementation of the foregoing computer-readable storage medium, the method further comprises: receiving, from the message broker, the subscribe message; extracting a payload of the subscribe message; and generating the modified subscribe message based on the extracted payload.

In another implementation of the foregoing computer-readable storage medium, the first communication interface is associated with a first version of a communication protocol, and the second communication interface is associated with a second version of the communication protocol.

In another implementation of the foregoing computer-readable storage medium, the first version of the communication protocol comprises a first version of an MQTT protocol, and wherein the second version of the communication protocol comprises a second version of the MQTT protocol. In another implementation of the foregoing computer-readable storage medium, the method further includes wrapping the message broker via a wrapper, such that the loT device is communicatively coupled to an endpoint associated with the wrapper. V. Conclusion

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art(s) that various changes in form and details may be made therein without departing from the spirit and scope of the described embodiments as defined in the appended claims. Accordingly, the breadth and scope of the present embodiments should not be limited by any of the above-described exemplary embodiments but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A system for tailoring the capabilities of a message broker for Internet of Things (loT) messages, the system comprising: at least one processor circuit; and at least one memory that stores program code configured to be executed by the at least one processor circuit, the program code comprising: a wrapper configured to: identify a first communication interface utilized by an loT device; identify a second communication interface utilized by a message broker; determine a difference between the first communication interface and the second communication interface; generate at least one of: a modified publish message based at least on the determined difference for transmission to the message broker using the second communication interface, the modified publish message being generated from a publish message received from the loT device using the first communication interface, or a modified subscribe message based at least on the determined difference for transmission to the loT device using the first communication interface, the modified subscribe message being generated from a subscribe message received from the message broker using the second communication interface; and transmit at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface.

2. The system of claim 1, wherein the wrapper is configured to generate the modified publish message by modifying a payload of the publish message, the modifying the payload comprising at least one of adding information to the payload, removing information from the payload, or modifying information in the payload.

3. The system of claim 1, wherein the wrapper is configured to: receive, from the message broker, the subscribe message; extract a payload of the subscribe message; and generate the modified subscribe message based on the extracted payload.

4. The system of claim 1, wherein the first communication interface is associated with a first version of a communication protocol, and the second communication interface is associated with a second version of the communication protocol.

5. The system of claim 4, wherein the first version of the communication protocol comprises a first version of a Message Queueing Telemetry Transport (MQTT) protocol, and wherein the second version of the communication protocol comprises a second version of the MQTT protocol.

6. The system of claim 1, wherein the wrapper is configured to wrap the message broker such that the loT device is communicatively coupled to an endpoint associated with the wrapper.

7. The system of claim 1, wherein the wrapper authenticates itself to the message broker.

8. A method for tailoring the capabilities of a message broker for Internet of Things (loT) messages, the method comprising: identifying a first communication interface utilized by an loT device; identifying a second communication interface utilized by a message broker; determining a difference between the first communication interface and the second communication interface; generating at least one of a modified publish message based at least on the determined difference for transmission to the message broker using the second communication interface, the modified publish message being generated from a publish message received from the loT device using the first communication interface, or a modified subscribe message based at least on the determined difference for transmission to the loT device using the first communication interface, the modified subscribe message being generated from a subscribe message received from the message broker using the second communication interface; and transmitting at least one of the modified publish message to the message broker using the second communication interface or the modified subscribe message to the loT device using the first communication interface.

9. The method of claim 8, wherein the generating the modified publish message comprises: modifying a payload of the publish message, the modifying the payload comprising at least one of adding information to the payload, removing information from the payload, or modifying information in the payload.

10. The method of claim 8, further comprising: receiving, from the message broker, the subscribe message; extracting a payload of the subscribe message; and generating the modified subscribe message based on the extracted payload.

11. The method of claim 8, wherein the first communication interface is associated with a first version of a communication protocol, and the second communication interface is associated with a second version of the communication protocol.

12. The method of claim 11, wherein the first version of the communication protocol comprises a first version of a Message Queueing Telemetry Transport (MQTT) protocol, and wherein the second version of the communication protocol comprises a second version of the MQTT protocol.

13. The method of claim 8, further comprising: wrapping the message broker via a wrapper, such that the loT device is communicatively coupled to an endpoint associated with the wrapper.

14. The method of claim 13, further comprising authenticating the wrapper to the message broker.

15. A computer-readable medium having program instructions recorded thereon, comprising: computer program logic for enabling a processor to perform the method of any of claims

8-14.