Get access to the new Intel® IoT Developer Kit, a complete hardware and software solution that allows developers to create exciting new solutions with the Intel® Galileo and Intel® Edison boards. Visit the Intel® Developer Zone for IoT.
Introduction
The Microsoft Azure* IoT Gateway SDK gives you a myriad of tools that allow you to enable gateway devices in multiple ways. It can also enable almost any device with an internet connection to become a gateway. It works for both Windows* and Linux* development environments that have the ability to compile C and C++ code. It’s also extremely modular, having a lightweight core to drive the modules you can include within it. This core handles how the modules communicate with each other, apathetic of the environment it’s in. This broker is the key to having effective modules, and an overall effective gateway. It also simplifies communicating with the Microsoft Azure* cloud service.
Modules
The SDK includes several modules by default, which can help you understand their structure, application, and communication. They can also provide a good testbed for a gateway, or your custom modules. To begin we will take a look at some of the modules created by Microsoft, and how they play in to the SDK as a whole. Each module is "wrapped" differently depending on whether it’s being used in a Windows or Linux development environment, but is otherwise the same.
hello_world
The hello_world module is designed to output a simple "hello world" message to the systems log. The majority of the code is error checking, to ensure the environment is properly setup by the core features of the SDK before executing. This module is a publisher, this means its goal is to publish messages to the broker, which can then send the message to whoever needs it. In this case it simply sends "helloWorld", "from Azure IoT Gateway SDK simple sample!" to the broker, but other modules could send sensor information, or instructions.
Logger
The Logger module is another simple module, which listens to the broker for any messages, before saving them to a JSON file. The logger does not output any data to the broker, but instead retains all data that has been through the broker. It appends several things to them, like the time of the event the content and the origin of the message, before appending it to the specified JSON log file. This simple module is good to use for error checking, as it can show you in real time, the series of events that lead to an unexpected output.
Building Your "Gateway"
The SDK has a built in function to build your gateway. Of course it doesn’t assemble the hardware through magic blue smoke. Instead it builds the object that acts as a configuration for the SDK to properly interact with modules and hardware. This function takes input in the form of a JSON file, which needs to instruct the program which modules to include, and how the broker needs to act towards them.
Modules
The module portion of the JSON file must include three things. Firstly, the modules name, which must be unique in your SDK. The next field that must be filled out is the path of the module. This path must end in .so or .dll, depending on the operating system your using for your gateway. Finally you must enter the arguments your module is expecting. Modules like the logger expects an argument for the file it’s meant to output to. The hello_world module expects no arguments, and therefore you pass it "null".
Links
This section of the JSON is used to instruct the broker on how to handle messages that are sent to it. Source modules are designated to send messages to the broker. Modules designated as sinks accept messages from the broker. In the case of the "Hello World" sample, the hello_world module is designated a source, and the logger module a sink. Below is an example of a JSON to build the gateway environment on a Linux host machine, taken from the Azure IoT Gateway SDK github.
Conclusion
A developer wishing to design their own module must look through the current modules provided by Microsoft. This article should have given you a good idea of the relationship between modules and the core of the SDK. Upon building your own modules, you need to take into consideration how they are going to react, and be applied in the world of the SDK, and the broker. The true power of a module lies in how it communicates to other modules to do what they need to. So go out there and design your own modules, test them out, and make your gateways act the exact way you want them to!
Resources
The primary source for this documentation is the Azure IoT Gateway SDK GitHub page.
