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
