Hi Ruwan, Analytics is indeed a primary requirement in any IoT "eco-system". There's no doubt whatsoever about it. In fact, analytics is what inspires folks to achieve operational efficiency and all that stuff end-to-end with proper use of monitoring against organization-specific KPIs, as you also have mentioned. Also, analytics, together with other important entities such as sensors, business processes, etc are presented, rightly so, as key elements of any IoT eco-system. But, IMO, everyone needs to understand that this is a collection of processes, each having its own scopes and implementations, that are tied together to achieve the high-level composite organizational goals that are expected to address in any IoT eco-system.
Along the aforementioned lines, if we take device management to be one such process, what does it mean to write a "device management plugin", one might wonder? You write a device management plug-in primarily to let the core framework know what device information needs to be captured, what operations to be controlled, what push-notification mechanisms to be used, etc. Therefore, writing a "device management plug-in" is purely something that is specific to "device management", and also is the functional requirement that is expected in the context of device management. Analytics is on the other hand is something that "supplements" device management (or any other domain i.e. enterprise integration, etc that makes use of monitoring and analytics) to achieve operational efficiency and all other intended goals, therefore is non-functional, IMO. As I believe, one need to understand the aforesaid two focuses separately, yet with a comprehensive understanding on how they both need to be used in tandem to achieve overall goals of any organization or echo-system. This doesn't, IMO, mean that the two aspects should be tied together at the "functional" level. Instead what we can do, IMO, is probably to separate the two aspects as two different projects within the underlying tooling platform and then present it to the users and guide them through how each of the aspects needs to be addressed at development level as well as deployment level. Any opinion that is supportive of or against the above is much appreciated. Cheers, Prabath On Wed, Mar 23, 2016 at 10:37 PM, Ruwan Yatawara <ruw...@wso2.com> wrote: > Hi Prabath, > > IoTS is basically the representation of WSO2's IoT Platform vision in the > flesh (Well, not literally). The idea behind it, is to provide users with > the necessary tools and components needed to get started with writing > device types that will later go in actual deployments. So someone who is > evaluating or test driving our platform per say, would find a more > integrated and therefore appealing story by discovering our device > management capabilities and analytics capabilities, integrate seamlessly > with no additional effort. > > Analytics maybe a non-functional requirement when we try to view IoTS as > just a device management framework. But in reality it is much bigger than > that, the whole driving force behind IIOT is the need to improve > operational efficiency of businesses through monitoring and analysis of > data from an array of sensory networks. Therefore IMHO, by all means > analytics becomes a primary functional requirement. We are just getting our > beaks wet by making available a bunch of DAS scripts with the plugin. In > the future, we may even find it necessary to put data models for machine > learning frameworks in there. > > Furthermore, having all the information pertaining to a particular device > type maybe advantageous when it comes to import/export of device types. For > an example, lets for a moment assume there is a device cloud by the name of > abc.com that runs on top of wso2's IOT framework. I as an independent > hardware vendor have written a device type to manage and monitor my device > on my laptop using the tooling available for IoTS. So with the current > approach, all I have to do is grab that device type (Which should ideally > be a deploy-able archive, contrary to our current feature based approach) > and upload it to abc.com cloud. In one go, my device type will be > deployed. > > Yes, this does bring to the table, the need to deploy various types of > different artifacts in different systems. But I believe we have done > something similar when it comes to deployment of imported API artifacts in > APIM (Which are deploy-able zip archives, containing sequences, images, DB > entries and what-not) > > Due to reasons mentioned above. I am of the opinion that we should bundle > analytics scripts with the plugin. > > Thanks and Regards, > > Ruwan Yatawara > > Senior Software Engineer, > WSO2 Inc. > > email : ruw...@wso2.com > mobile : +94 77 9110413 > blog : http://ruwansrants.blogspot.com/ > www: :http://wso2.com > > > On Wed, Mar 23, 2016 at 5:54 PM, Prabath Abeysekera <praba...@wso2.com> > wrote: > >> Hi Everyone, >> >> As most of you know, IoTS is a unified platform that allows users to come >> up with "plugins" and seamlessly add them to the framework to be able to >> manage different types of devices. For instance, if an organization named >> "Org-X" manufactures a device type "Dev-X", they can simply adopt IoTS and >> extend its plug-in model to come up with a plug-in to support end-to-end >> device management and more upon "Dev-X" devices. To make plug-in generation >> process easier for the developers who are involved in the same, a maven >> archetype is used. The aforesaid archetype is simply used to create a >> skeleton of the plug-in, which can then be enriched with different >> communication protocols, etc depending on the expectations of different >> device manufacturers, etc. >> >> Currently, the maven archetype explained above has the following >> structure. >> >> -- component >> --*analytics* >> --controller >> --manager >> --plugin >> --ui >> >> Once the above skeleton is generated, then the developers customize the >> same to come up with the desired plug-in implementations and package things >> up to be able to push it to the CDM-F. >> >> Right now the model being used is that, all the aforementioned resources >> such as the plugin implementation, analytics scripts, etc are packed up as >> a single archive. IMO, having analytics scripts bundled up with the rest of >> the bits is not a good approach depending on a few reasons. >> >> 1. When it comes real production deployments, these analytics scripts >> will be deployed in a separate DAS cluster as opposed to how things are >> when the same is done within the scope of a single server. So, if the two >> components are running separately, there's no point packaging everything up >> as a single archive as we'd have to break things down to two separate >> packagings (a) to be deployed into IoTS (b) to be deployed into DAS. >> >> 2. Analytics, I believe, primarily is a non-functional requirement. >> Therefore, bundling non-functional bits with functional bits is not a good >> practice. >> >> 3. If we ship analytics scripts with a particular plug-in, the natural >> expectation is that it would only cover specific bits bound to the scope of >> particular plug-in. However, in a practical environment, what majority of >> the folks are looking at are much more advanced and composite KPIs and >> related analytics to be able to help organizational strategies, etc. So it >> is highly likely that people might generally be interested in brining in >> analytics as a separate step relieving the need to pack the scripts, etc >> with the functional bits. i.e. plug-in implementation. >> >> >> Instead what I propose is to have a separate "project type" or something >> similar as part of the underlying tooling platform, which can effectively >> be used to compose all analytics related scripts, etc. We can then package >> it up separately and deploy into the relevant DAS clusters to get the >> analytics up and running. >> >> >> Some of the stuff I've brought up might be subjective, but I am of the >> opinion that we need to remove analytics related scripts from the plug-in >> skeleton. >> >> WDYT? >> >> >> Cheers, >> Prabath >> -- >> Prabath Abeysekara >> Technical Lead >> WSO2 Inc. >> Email: praba...@wso2.com >> Mobile: +94774171471 >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Prabath Abeysekara Technical Lead WSO2 Inc. Email: praba...@wso2.com Mobile: +94774171471
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
