We already have Dev Studio support for "analytics" artifacts. In this case it depends, If the plugin developer believes that he his sensor need some specialised analytics and charts then we should have the capability to provide that, this can be achieved via added the analytics in to the same cApp. But there can also be cases where they will have some common analytics for multiple devices in that case analytics can be a separate deployment.
@Prabath for your Qn 1, I think if the IoT plugin is a .car then we can deploy the whole plugin in DAS too and there DAS will only deploy the necessary analytics artifacts. So it will not be an issue. Regards Suho 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 > > -- *S. Suhothayan* Technical Lead & Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
