A “somewhat” standard IoT middleware stack will remain a work in progress.
Middleware will play a part as the connectivity layer for sensors in the IOT landscape and but also as the connectivity layer between application layers in the IoT stack. Many writers confuse platforms and middleware, or in effect consider a wide definition of middleware that includes all software between the device and the application as the middleware. This broader definition is not really that useful in the architectural context, as it confuses the functionality required to be delivered by each of these layers, which are very distinct. I will cover IoT platforms separately in my next article. In my earlier blog showing a Simplified Architecture for IoT I have shown middleware as the layer above the network only, but of course in reality it pervades the whole of the IoT solution.
Middleware for IoT is required for various reasons. The summary of reasons is as follows:
- Difficult to define and enforce a common standard among all the diverse devices belonging to diverse domain in IoT.
- Middleware acts as a bond joining the heterogeneous components together.
- Applications of diverse domains demand abstraction /adaptation layer.
- Middleware provides API (application programming interfacing) for physical layer communications, and required services to the applications, hiding all the details of diversity. 
It is important to note, that enterprise customers will use a combination of existing middleware alongside emerging IoT and M2M integration approaches for meeting the requirements of their IoT projects. The lack of common vendor and platform-agnostic connectivity standards will slow wider IoT adoption, especially from the perspective of enterprise IoT initiatives of reasonable scale, as the grable with vertical IoT solutions and platforms that do not easily integrate.
Typically enterprise customers will not need to care about the middleware used to connect the sensor devices, unless they are building solutions from the ground up. Typically enterprise customers will be buyings solutions that include the sensors, the network and the middleware to deliver the data to their platform of choice. The key to success is to ensure that the services and data are accessible to your existing enterprise middleware via API’s
It is also easy to get confused as to where API’s fit in the IoT landscape. According to Mulesoft
APIs are enabling interconnectivity in places you wouldn’t imagine. From kitchen appliances to cars, the “Internet of Things” has become a reality. 
API’s are a neat way to address IoT devices and the services that they create, but they don’t in themselves create IoT or even enable the connectivity. In terms of IoT, API’s provide the following key features:
- Device registration
- Exposing devices as APIs
- Applying API management best practises to manage device APIs.
Ensuring that the IoT solution is addressable via API’s is critical. Implementing IoT systems that are closed and only offer data via the vendor’s provided applications should be avoided. Use of a good open source enterprise middleware solution from Mulesoft, WSO2, RedHat is probably the best choice for your IoT solutions, ensuring that the middleware platform provides a full range of functionality from API management, through to basic messaging, routing and transformation functionality.
MachineShop has long known that middleware – and importantly a new approach to middleware – is a key element in driving IoT growth. 
Being the only IoT platform that takes an API-first approach, MachineShop enables all processes to be expressed as discrete services without the limitations of a proprietary platform. The true distinction is that MachineShop is a Platform of Services as opposed to a Platform as a Service. This unique approach transforms the way enterprises and developers build, integrate and manage solutions
to unlock business value and intelligence.
If you thinking of building an IoT solution from the ground up, then the middleware used to connect your sensors is of critical importance. Aside from the basic task of getting reading the information from your sensor network, you will need to be concerned with interoperability, management, scalability, security and privacy. These issues are discussed below :
This is the classic function of middleware, providing the basic connectivity between physical devices, to data-link to network, transport, session and sometimes application layer of TCP/IP stack. This function also deals with the format and structure of the encoding of the information exchanged among things.
IoT-middleware exposes multiple APIs to perform these interoperation functionalities. SOA-based architecture Ubiquitous Service-Discovery Service are some of the common approaches adopted.
IoT-middleware must be context aware for working into smart environments. Context awareness can be achieved by context detection and context processing. Context detection collects data and identifies the factors that have significant impacts on the response. Context processing extracts the context data, processes it and performs or takes decision based
The middleware performs context detection by collecting information from the sensor devices and extracts required context data by utilizing available data mining algorithms.
Device discovery and management
Device discovery and management enables any device in the IoT network to detect all its neighboring devices and make its presence known to each neighbor in the network. Device ontology is used for storing information about the heterogeneous devices.
From IoT perspective, these modules need to be reliable, fault-tolerant, adaptive and optimized for resource consumption.
Security and privacy
Security and privacy are responsible for confidentiality, authenticity, and nonrepudiation. There has been much written about security and IoT and that many middleware vendors have not implemented security as a fundamental part of their middleware architecture. Implementing security as an after thought could have serious implications for the robustness and safety of the solution and may limit its use in certain industries such as health, finance and critical infrastructure
Managing data volume
Managing data volumes is an integral part of IoT-middleware. It is believed that there will be trillions of objects which will be part of this enormous network and Zettabytes will be stored or exchanged among the objects. In other words the explosion of the amount of data collected and exchanged is beyond what current enterprise middleware can cope with. Solutions such as CR-X are addressing these problems. Therefore it is imperative to get novel methods to find, fetch, and transfer data.
Some of the projects that are developing device level middleware include Linksmart, UBIWARE, UBIROAD and SMEPP., SOCRADES,, GSN, ASPIRE, SIRENA
Not all of these projects fully support the requirements of middleware for sensor networks, and standards are still evolving in this space. Although much of the research has been done in the last decade, commercial winners have not yet emerged and innovation is still underway. Standards will follow once the innovation cycle slows.
In my next post will explore the platform level, many of which incorporate commercial implementations of the middleware required build a sensor network from the bottom up.
1 & 4 A Survey of Middleware for Internet of Things, Soma Bandyopadhyay, Munmun Sengupta, Souvik Maiti, and Subhajit Dutta