Hi Everyone, *Current plug-in architecture of CDM-F*
If we look at the current plug-in model of CDM-F (1.x), it consists of three primary components. 1. A Class that extends "DeviceManager" interface providing information on what features/configurations to be managed, what datasources are used for persisting plug-in specific information, what push notification mechanism has to be configured for a given device type, device type provisioning instructions, etc. 2. A control API in the form of a JAX-RS service that let's us expose control operations upon the aforementioned features. 3. A UI component providing the front-end of the plug-in related functionalities 4. Optionally, analytics scripts, which is to be taken out of the scope of a device plug-in. Please refer more info on this in thread "[IoTS] Is it the right thing to package "analytics" scripts with a plugin implementation?" in architecture@. *Key characteristics of the current plug-in model* If we carefully look at the aforementioned model, it has the following characteristics. * A class to "describe" how a plug-in should be modeled and represented to the core device management framework together with its list of features. * A JAX-RS service to expose the features defined by the class above. * A UI component that talks to the API described in the above step. *How to make it "descriptor-driven"* My proposal is that, you can quite easily turn this model into a "descriptor-driven" implementation, which will greatly enhance the usability of the device management framework, as below. * We don't necessarily need a "java class" to "describe" a plug-in as it can simply be done with a descriptor-file with some sort of a framework-provided DSL. The key advantage is that, the whole model is "zero-code" so, you don't need to be a java developer to craft a plug-in and put it into the framework. If getting used to a DSL is cumbersome, we can totally make a Developer Studio plug-in that wraps this DSL and provide the user with an easy-to-use UI for plug-in composition. * The operations that should be exposed as part of the control API can easily be extracted out of the list of features given in the plug-in descriptor. We should then be able to auto-generate the JAX-RS together with the required control-operations during the deployment time of the descriptor. * For the UI too, we should be able to adopt somewhat a combined approach comprising both auto-generated + manual composition aspects. However, before we do that, we might need to work on a proper UI abstraction for the framework, which can then be extended by this sort of a model. WDYT? If the aforementioned model sounds like a good alternative to the current plug-in model, I'd like to propose adding this to CDM-F 2.0. 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
