- Rajiv Anand
A term like “middleware” has been bastardized by software industry in so many ways that it is no surprise when people are rightly confused even by its IETF definition “those services found above the transport (i.e. over TCP/IP) layer set of services but below the application environment”. Web servers, App servers and CMS are all classified into this category, understandably further befuddling an already nebulous semantics around the term.
If I have to explain middle-ware to non-technical person, I ask them to understand the challenge of asking a person to talk to people from 16 different countries and culture, each speaking a different language, at the same time and make perfect sense out of the conversation.
In particular context of Internet of Things, the challenge is same. Software responsible for doing a thing like that typically has to connect to a number of different models of devices made by different manufacturers. Device X could be completely different in its capabilities to Device Y and they might speak completely different protocols. Sometimes they might even connect differently, for example one device will connect over Ethernet while the other on a serial port.
If a software like this was not there, there will be a number of complications and duplication of the functionality everywhere.
While middleware, like Tagit’s own product Trapeze, is responsible to connect to devices and systems, speak their language to interpret their state and events and then transform into something well understood by other applications, the functionality extends way beyond that. Turns out that this is also perfect place to do other chores that relieve upstream applications. Filtering, aggregation, detecting situations from events are some of the “higher level” functionality that can be delegated to middleware. Turns out that devices are chatterboxes, particularly RFID devices generate huge volumes of events. A simple 5 second scan of an area can lead into thousands of tag reads for just 10 items and all of that might be just a duplicate series of events that happened just 5 minutes ago. Event processing layer within the middle-ware is a perfect place to eliminate the chatter on the wire, leverage built-in knowledge of standards such as EPCGlobal and GS1 to make life of interpreting events simpler and reduce resource consumption and complexity of integrating applications.
In case of Trapeze, all of this is just a part of the functionality. Trapeze was built with integration flexibility in mind both on the devices side as well as application side and to make it completely extensible, it uses a provider model. A new device becomes available, you write a provider and literally drag and drop it on administrative interface. Trapeze will now know how to discover and communicate with this device right away. Trapeze knows about most of the standard enterprise applications such as Supply Chain Management (SCM), Warehouse Management System (WMS), Enterprise Resource Planning (ERP), and databases such as SQL server, Oracle, PostgreSQL etc. but the same provider model is available for any legacy or homegrown application that you’d need to integrate with.
In a system responsible to interact with the physical world and automate business processes, middleware is a critical and irreplaceable part of the solution stack. Sometimes it might be confusing to not have a clear line between where middleway ends and where other enterprise applications begin, it probably is immaterial to the solution design. The key aspect to an optimal design is to handle events at earliest possible place in the flow, wherever you have the information enough to process it. With IoT sensors and the sheer amount of events they can generate, it is crucial to handle them in the middleware and only bubble up events that have business relevance, something Trapeze was exactly designed to do.