Last weekend I was thinking about one of the swanky keywords of the Industry a little deeper than before, IoT, from an Architecture’s frame of reference. I was on the Internet browsing through various reference architectures and subsequently into various design aspects. I wanted to architect and design an Application as close as possible to a real, mainstream IoT App with each of its “thing” having its own DB foot print and could possibly and completely disjoint from the Application’s core DB Architecture. It could possibly have its own “device embed” – very much like a Yammer feed embed script or a Twitter/Facebook login button script – provided by its vendor such that it could be part of the Application (IoT dashboard as well for management purposes).
Then, I was trying to visualize a Smart home and its digital blueprint having a Hall, Kitchen and a Bedroom with each of it having a bunch of connected “things” (devices) that constitutes each room. A possible soft dashboard (for now let’s assume a Tablet interface) using which I could control various aspects of my Smart Home. As mentioned earlier each “thing” (or a device) could have its own DB foot print which may or may not be the part of the overall DB schema of the Smart Home (let’s assume it’s not a SaaS scenario for simplicity sakes). As I was trying to analyze, I kind of identified a pattern wherein each “thing” has its own little “world” with its own metadata, data, services, soft-embeds (scripts for Applications to use them). Each “thing” has to roll itself up into its parent container which by itself could be soft or a hard “thing” and sometimes (or most of the times?) a “thing” could be a conglomeration of a set of “things”.
Good given this, how I do create an Application as realistic as the above scenario with very less simulation and a maximum reality? I needed to fake lot of devices and their inputs and outputs etc.
It is at this point that I started drawing parallels between the Smart Home scenario and any normal Web Application.
If any of my “Page” represents a Room, let’s say Kitchen, then all the “things” or devices are akin to the “controls” on the Page like labels, textboxes, listboxes etc. And the Page itself could be a “thing” that constitutes rest of the associated logical “things” (in this case, textboxes, listboxes, labels, and buttons). All these “things” on the Page “thing” should/could be managed from a central dashboard to manage behaviors and properties of any “thing”. In the IoT world each “thing” could be reachable over the web and it could have its own DB schema that could be disjoint from the overall application that it is being part of. Right so, as long as my “thing-Textbox” metadata is stored in a NoSQL DB and is exposed out as a REST API, I could have it connected to dashboard/s to manage it. Now the same “thing-Textbox” could keep track of all the changes that it has seen so far by various users who have been using the Application. I could individually query the “thing-Textbox” to give me trends of modification of text over a period of last 3 weeks (for a specific user or a group of users) etc. And the same concept could be extended to all other “thing-controls” on the “page-thing” – or to the overall “page-thing” itself.
Now, I may not want to use alien scripts (e.g. WebTrends) to find out typical analytics of my page, but it gets interwoven into various “things” and all that is needed is to create a query that spans across “things” (this depends on the flexibility that the underlying framework provides, which is not existent today ) or may be identify field/s (e.g. text for a textbox, id and text for a combobox etc) that should be automatically propagate into the overall Application’s DB Schema (NoSQL or RDBMS, irrespective, it’s the job of the “thing” now to have it propagate the fields appropriately to its parent “thing” which in turn will propagate it up further till it reaches current Application’s schema).
Now, for some controls (custom?), I could create embeds such that they could be a plug-n-play on the “page-thing”.
Now I could take the jQuery textbox and enhance it such that it could keep track of all the changes by various users into a NoSQL DB which could be configurable. Now this DB also contains all other attributes of the Textbox and it will be managed from a dashboard (as we change attributes in the Dashboard for this “thing” it reflects the actual instance, may be send out a notification to the Application to repaint this “thing”). I could also identify and associate a “parent thing” and which field/s have to be propagated to the “parent-thing”. Now the “parent-thing” could have the logic or a configurable callback such that it could decide the fate of the propagated field/s from all its children.
Now my “thing-textbox” is pretty autonomous, it has its own DB foot print, it has its own attributes, and it keeps track of the events that occurred with it in its life time, its metadata could be reached out to using a REST API. Also it could give out predictive analytics (using appropriate and configurable Machine Learning algorithm) around the “thing-textbox” (in the IoT world it could be an Air Conditioner) based on the context. Now in my “page-thing” could either add an “Air Conditioner embed” along with other “thing-textbox” etc. It’s a blend of “things”.
Sounds like this will give me an Application with almost zero simulation and would have Architected & Designed an IoT Application without having to use any devices. All I created is just another Web Application but with an IoT perspective.
So, a more logical way to put this is all the Objects on the Serverside and Client Side will extend from a Base Class called “Thing” which has all the needed framework to perform and expose behaviors of a “thing” as opposed to “Object”.
This is a thought process to look at things from a different angle and next time, I will publish my findings around this more from a practical standpoint as I design and implement such Application.