Hi Suho, On Thu, Mar 24, 2016 at 12:21 AM, Sriskandarajah Suhothayan <[email protected]> wrote:
> 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. > Understood. But, my point was to separately identify the two intended scopes, i.e. device management and analytics and then package things accordingly. So, as a result what will be deployed in each layer is only that is bound to that particular layer at a functional level. > > Regards > Suho > > On Wed, Mar 23, 2016 at 10:37 PM, Ruwan Yatawara <[email protected]> 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 : [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 >> >> > > > -- > > *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 <%28%2B94%29%20779%20756%20757> | 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
