The almost-hysterical interest in the internet of things has put .NET developers in a tough position. IoT, of course,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
means the internet of things, which usually means RESTful interfaces, Java development and things not associated with .NET at all. In general, .NET users have a strong architectural example for IoT that could jumpstart IoT development. Just follow the Azure IoT Hub model whether you're planning for Azure or not. Focus on the service bus for your coupling middleware, and don't be afraid to throw Java into your mix.
Any application architect will tell you that IoT is a use case and not an application model. Like accounting or retail banking, IoT needs application architecture to frame the relationship between its components. And to divide the mission into components that can be developed, reused and deployed efficiently. Given that few companies have any real IoT development experience, defining an effective IoT model is a difficult challenge to meet. The best approach is to follow the cloud.
Microsoft and Amazon both have an implicit vision for building IoT applications. It starts with a community of devices that have to be connected, registered, authenticated and managed in the same way as any other traditional user device. These IoT devices are sources of events, which could require real-time handling, repository cataloging and analytics, or both. Business applications, including current ones, must then draw on the results of this event processing. Since Microsoft Azure is a preferred cloud partner to .NET development, it's easiest to frame your .NET IoT application by referencing the Azure IoT Hub elements.
The Azure IoT Hub components are responsible for device connection and management. Everything that is device-related is managed here, and the output of an Azure IoT Hub (or any IoT hub) is a set of messages or events that represent IoT telemetry. Control messages to IoT elements are similarly connected through an IoT hub. If you don't plan to use Azure, then the structure of a self-developed device connection and control element should, as much as possible, match that of an Azure IoT Hub, particularly with respect to interfaces.
Message or event? It can be confusing
To move beyond the Azure IoT Hub, you'll need to consider what your IoT elements are generating. The terms message and event are often confused or conflated. Message systems direct information to a specific recipient and event systems simply report on a condition. Most broad IoT applications will generate both from the devices, and so it's convenient to think of the output from an Azure IoT Hub as a series of parallel message and event streams.
Azure IoT tends to handle events and messages through common processes. An Event Hub component can ingest events and post them to processes or route them to storage elements as needed. And a Stream Analytics component integrated with the Event Hub can do real-time analysis for complex event processing. You can build either of these components using standard .NET message and event tools, or with Windows 10 Core IoT devices (based on third-party boards and custom development).
The Event Hub and Stream Analytics logic, whether you use Azure or your own, is a combination of classification and analytic-event-generation stage. The Azure IoT Hub devices feed through this portion of an IoT application to allow them to be associated with some handling logic, which could be either IoT-specific application components or current business applications. It is very important that your Hub and Stream Analytics components harmonize the diverse device-specific event/message forms into a common application-specific event/message. If you don't do this, then all your logic will have to be changed to accommodate a new device and you risk inconsistent handling of IoT data. You can harmonize in the Event Hub and Stream Analytics process using handlers or include handlers in a next element. For true messages, which will normally expect a response, a handler should provide state control and association between the application and the IoT device to ensure a response in a proper form.
The business logic distribution process should be based on a publish-and-subscribe interface to decouple applications from devices and enhance development efficiency. Ideally, your IoT application will include handlers that are associated with messages/events in a Hub/Stream Analytics component. And then convert formats and bind the resulting messages to applications using some form of service bus queue. It's critical here to have a bus architecture that can interface with all your applications and is itself resilient and distributable. Microsoft's Service Bus is fully distributable, cloud compatible and can support application interfaces of nearly any type. It's available both as an Azure service and as a Windows Server component.
Behind a publish-and-subscribe bus component is business logic itself. Because it is ideal if any given information source (event) or message (request/response) has a standard format, it may be necessary to develop a stub to match an application/component to the format of a message bus you've selected. Some remapping of data is often supported by the bus itself, but be prepared to accommodate special requirements for legacy applications.
Feel free to mix it up with .NET
The final point to remember is that there is nothing wrong with mixing .NET (and C#) applications with Java in any of these areas. In the device-handling part of an Azure IoT Hub application, many sensors and controllers will connect to the internet or a company virtual private network through an intermediate gateway. You can build one using the Windows 10 Core IoT kit, but you could also use Java or any other language supported by a sensor/controller vendor.
When building even in the deeper elements of your IoT applications, you may find Java or other platforms useful. Event distribution using Event Hub can accommodate multiple languages and middleware tools. That's even true with service-bus-coupled applications on the back end. Pick what works best, accommodate what you already have, and build what you need to conform to the cloud model described here. Your IoT application can then grow and fulfill your business needs far into the future.
Learn how IoT analytics tools help improve product quality
Best practices for making IoT data actionable
How to build information security architecture