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 : [email protected] mobile : +94 77 9110413 blog : http://ruwansrants.blogspot.com/ www: :http://wso2.com On Wed, Mar 23, 2016 at 5:54 PM, Prabath Abeysekera <[email protected]> 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: [email protected] > Mobile: +94774171471 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
