IoT service-oriented architecture can simplify the process of adjusting an IoT deployment to changes in the real-world by focusing on functionality instead of events.
Application architects designing IoT applications might simply set up sensors in a traditional architecture model, but service-oriented architecture could bring them greater advantages if they understand how it alters the perspective to IoT software functionality.
The traditional device-centric model for IoT is a community of open sensors accessible on the network that generate events, a series of open controllers that influence real-world elements. Applications receive events from the sensors and send commands to the controllers. It all sounds logical, but it has a number of problems.
Service-oriented architecture (SOA) for IoT is subtly different and focuses on software functionality that can be reused for different tasks. In a service model, the goal is to start with how the IoT application should interact with the outside world, compared to the technical aspects of how IoT works in the traditional model. For example, a vehicle location system in a vast yard facility should locate vehicles, not read sensors. The request for vehicle location is then pushed down toward the hardware. The vehicle has a position and the things in the yard have a position. After the hardware identifies the positions, the application architects focus on how they know it. In this case, the sensors establish those positions.
The IoT service is then designed to deliver functionalities that fulfill the requirements; in this case, the positions. The service's outputs -- their API definitions -- fulfill the original mission, but also related missions that are derived from the same information. The devices themselves are invisible, which gives this model some increased benefits.
SOA for IoT bolsters security
The low cost and simple setup of IoT devices create both their appeal and disadvantages. The need to keep device costs, power consumption and complexity low makes it difficult to secure them adequately. If IoT devices are visible on an open network, including a building network or VPN, malware or hackers can reach them.
Virtualizing the device layer with SOA for IoT brings the same advantages to IoT applications as virtualization of server resources does to IT.
With the service model, application architects would not put IoT devices on an open network at all; they put devices on a private subnet that is accessible only by the IoT services. These services are easier to secure as part of the IoT software itself.
Application architects can apply any traditional service-API security brokers and tools to the service component software. The services present as a set of service APIs that provide the rest of the application with information or the command interfaces needed to control IoT components. The services can simply represent what a sensor or controller would do, or they can be complex, containing interpretive elements that put sensor events in context or convert convoluted controller commands into simple actions, such as close-gate.
SOA smooths over differences in applications and sensors
Another benefit of the service model of IoT is that it insulates the IoT applications from the fact that different sensors and controllers work differently. For example, sensors from different vendors and models could report temperatures in Celsius or Fahrenheit or in a variety of message formats. The IoT applications will have to match the sensors or controllers that it talks directly with and change if the sensors or controllers change. A simple difference can break the application. This approach can lead to what developers call brittle software.
An IoT service can also harmonize how sensors work, for example, whether they report a condition or a change in condition. A light sensor might only be able to report on its current position -- on or off -- while another sensor may be capable of reporting both its current position and when its position changed from off to on. This difference in reporting would be difficult to accommodate in an application that tied sensors directly to the application logic without redoing the design of the application. With SOA for IoT, the service presents a harmonious view of how sensors and controllers work, so differences in the devices or changes to the devices won't affect the logic.
Services organize and anonymize data
Services structure and share IoT data and serialize control commands. Imagine an IoT sensor being queried by a dozen different applications many times per minute or second. It would be swamped by the load. A service can take over the sensor interface and distribute the load. The service can scale to provide the data reliably and securely to as many users as necessary. With IoT control elements converted into services, the services can organize requests to prevent overloading the controller or colliding to create ambiguous results. Finally, services can anonymize information when personal details aren't necessary. Traffic analysis doesn't need to know exactly who is where, only the distribution of vehicles. That reduces regulatory risks in using the data.
How SOA for IoT applies in a real-world distribution center
IoT applications want sensors and controllers to relate to context in the real world. Real-world changes or changes in sensors and controllers are enough to break a device-centric IoT implementation. In the traditional IoT model, if the yard is reorganized and the position of a vehicle changes or sensors are placed differently, everything in the application that figured out position breaks. If only a position service is visible to the application level, then only that service needs to be changed.
For example, a distribution center might have a service that reports a condition called internal transportation congested, which means that the trucks or lifts carrying goods from warehouse to packing and shipping are behind schedule. Recognizing that could mean understanding the outputs of a half dozen or more sensors and the trend in conditions was over the last five minutes. To address the issue, the center might need to slow the picking process or assign additional trucks, which could also require multiple control outputs. Making this a service could change the application to simply say "if internal-transport-congested, then activate relieve-congestion." The service component would do the rest.
Services in IoT virtualize the device layer
Virtualizing the device layer with SOA brings the same advantages to IoT applications as virtualization of server resources does to IT. Applications are portable, scalable, resilient and secure. They can easily accommodate changes in hardware, expansions in the information model or desired control outputs because all of those are implemented within the services and referenced by applications in the proven service or microservice model that's already a fixture in modern application design.
