SOA Strategy and IoT (Internet of Things) – Part 1


So far we have put the focus on the context of a company or a public body, regardless of the industrial sector to which it belongs. We have been insisting on the benefits that an SOA strategy can bring to the business processes of any activity, and therefore, to companies and institutions, and ultimately to the quality of the services that these entities provide to citizens. But in this post, we will look up and we will look beyond, far beyond: on the horizon, coming quickly to our lives, we find the Internet of Things (IoT): nothing less than the connection and interaction of everything around us with the internet.


The SOA strategy and the Internet of Things



The concept is so broad that it’s difficult to cover, but it is also so inevitable that it is worrying to think about how this new wave will arrive. What is certain is that it will arrive.

If, in a supposedly bounded and controlled context such as a company, the way in which information flows, the way the systems are connected, is so decisive to achieve a sustainable, scalable and maintainable ecosystem with reasonable costs … what will happen if the IoT explodes without control?. Said less alarmist but equally precise: can IoT ignore the principles and guidelines of an SOA strategy?. Issues that on a business scale have proven to be absolutely critical and determinant in the success or failure of an interoperability strategy, how do they impact on the IoT?.


We will try to analyze those key factors that accompany an SOA strategy, and its role in IoT.


The SOA strategy in the Internet of Things: key factors.


– Semantic Standardization.

We have recently dedicated an entry to this topic. In the context of the IoT, we will analyze it with an example. Imagine a refrigerator connected to the internet, and equipped with RFID readers to control the stock of products it contains. Imagine that the installed software is able to identify when a product starts to be scarce or exhaustive, informing the user through a viewer or sending notifications to the mobile that can be seen in real time, or in a report requested by the user in his app. Suppose further that when the user decides, he can automatically generate a list of items to buy, an order, which once confirmed is sent to a service published by the supermarket chosen by the user to order the purchase, which is naturally paid through a telematic payment service.


Science fiction? Absolutely not. The necessary technology exists and is affordable. In that scenario, there are several messages to be designed between different actors.

1. Low stock message: Our refrigerator notifies us that the yogurts are running low.

2. Zero stock message: no yogurts remain.

3. Send order message: We have configured an order in our mobile or in the console of the refrigerator and we click on “buy”.

4. Confirmation of purchase message: we validate the payment order and confirm the charge with the payment gateway that our bank uses. This may not be necessary if our payment console (or the mobile itself) uses state-of-the-art authentication systems (fingerprint for example).

The application that is run in the refrigerator, will identify the product “yogurt” in a certain way. The application that the user has on their mobile to interact with their fridge as well. The supermarket, on the other hand, too. If these systems do not use a common system to identify the products, this example scenario presents important restrictions: we can not use any supermarket, for example. Only the one that is compatible with our system of identification of articles in the refrigerator and mobile app.


Instead, the interoperability strategy based on SOA principles raises two mutually compatible alternatives:

1. Having an interoperability standard for the retail trade (following our example). We would ensure semantic interoperability among the different actors within the retail business processes, from end to end.

2. Introducing a mediating, orchestrating and transformative platform (an ESB) among the different actors, so that the actors who do not use the same semantics in their messages remain independent (loosely coupled) from the other systems and their own semantic peculiarities.


Both tactics are compatible with each other, and could (should) coexist in an example like the one we have raised. In this way, the ESB platform would flex the requirements for any new players who can enter the scene (new refrigerators manufacturers, new specialized apps, or new stores) in terms of compliance with the sector interoperability standard. And the standard, would ensure that in the mid and long term, the user will not be tied to a number of companies that understand each other at the messaging level.


– Abstraction

In the day to day of the citizens, many patterns are repeated. Even in different activities, viewed with a certain level of detail. A simple example could be the buying process. Buying something may seem very different when we compare what we do when doing the monthly shopping, with what we do when we are buying shoes, or a ticket for a concert. In each case, the detail of the process has obvious differences, but at a certain level of abstraction the buying process is always the same: a seller offers a product (full cart, shoes or ticket) to a customer, in exchange for the payment of an amount accepted by both (in cash, or by means of electronic payment).


The arrival of IoT should take this into account in order to design efficient and easily maintainable integrations (from a corrective and evolutionary point of view). Extreme connectivity promoted by the IoT will deal with a series of patterns (indeed, we may speak of a set of patterns), which are repeated over and over again. It is down to a certain level of detail when differences can cause the impression of an overwhelming variety of processes.


A correct strategy should always seek a level of abstraction that allows to handle interoperability patterns many times, in situations and uses seemingly distant in the eyes of the end user. An in-depth analysis of the information flows, of the events that trigger the communication between the different devices, entities and users, is needed. Here the analysis and modeling of the processes can help to understand perfectly who, what, when and how the information moves in a certain scenario.


– Events and Processes orientation

IoT is an excellent example of how determining a good integration strategy can be. The classic vertical approach, which seeks to find a technological solution to a functional problem of a given user profile, usually leads to reactive, non-proactive patterns. And the reactive pattern par excellence is the request-response pattern, which we discussed in the previous entry.


But IoT has a lot in common with robotics and especially with home automation. IoT aims to take the immense capacities of the internet to the daily events of people and to the operation of the devices and appliances we use in our day to day. Therefore it can not fall into the classical vertical approach of reactive solutions. No doubt there will be cases where that pattern will fit well, but never by default. The approach required by IoT, by its very nature, is event-driven. And to correctly discover significant events in the information flows to be implemented, nothing better than an analysis of the transversal processes, which allows to discover how some scenarios are related to others, and how the flow of events and associated information extends naturally in the daily behavior of citizens and their interaction with things.


There are still other key factors to analyze, but not to make this entry too long, we will continue in the next post.


Te puede interesar


Submit a Comment

Your email address will not be published. Required fields are marked *

Follow me on social media

Share This