Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

[Sumedha Rubasinghe]

Harshan,
The purpose of descriptor was to remove boiler plate code. If there is
anything specific, use the handwritten plugin approach.

If it's not already there, let's make both descriptor and handwritten
plugin to co-exist on a single runtime.

On Thu, Dec 1, 2016 at 1:25 PM, Harshan Liyanage  wrote:

> Hi Ayyoob,
>
> There are some instances where we need to cater plugin-specific
> functionalities which can't be achieved through a boiler-plate
> implementation. This behavior can be seen in mostly mobile-device plugins.
> For most of the times we don't need specific internal implementation. For
> example sometimes we need to store some device data in plugin database
> table and fetch it using a specific query. How are we planning to move
> forward in such scenarios? Can this deployer generate tables other than
> device table and feature table? If not I suggest to add following
> capabilities to the deployer model.
>
>- Ability to specify custom tables
>- Ability to specify custom queries/DAOs
>- Extension model where we can specify custom implementations which
>are required for the device plugin
>
> WDYT?
>
> Thanks,
>
> Harshan Liyanage
> EMM/IoT TG
> Mobile: *+94765672894*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>
> On Tue, Nov 22, 2016 at 10:10 PM, Ayyoob Hamza  wrote:
>
>> Hi Dilan,
>>
>>
>>> Does this mean we can basically have a ready-to-use device plug-in
>>> implementation, just by configuring a descriptor file ?
>>>
>> Yes thats the idea, In here the plugin means the osgiService which
>> contains the definition of the device type. we found from the existing
>> device type that it all follows the same implementation template as the
>> plug-in(DeviceManagementService) implementation. Therefore I created a
>> generic template which populates the DeviceManagementService through a
>> configuration file.
>>
>> Thanks,
>> Ayyoob
>>
>>
>> ___
>> 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
>
>


-- 
/sumedha
m: +94 773017743
b :  bit.ly/sumedha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

[Harshan Liyanage]

Hi Ayyoob,

There are some instances where we need to cater plugin-specific
functionalities which can't be achieved through a boiler-plate
implementation. This behavior can be seen in mostly mobile-device plugins.
For most of the times we don't need specific internal implementation. For
example sometimes we need to store some device data in plugin database
table and fetch it using a specific query. How are we planning to move
forward in such scenarios? Can this deployer generate tables other than
device table and feature table? If not I suggest to add following
capabilities to the deployer model.

   - Ability to specify custom tables
   - Ability to specify custom queries/DAOs
   - Extension model where we can specify custom implementations which are
   required for the device plugin

WDYT?

Thanks,

Harshan Liyanage
EMM/IoT TG
Mobile: *+94765672894*
Email: hars...@wso2.com
Blog : http://harshanliyanage.blogspot.com/
*WSO2, Inc. :** wso2.com *
lean.enterprise.middleware.

On Tue, Nov 22, 2016 at 10:10 PM, Ayyoob Hamza  wrote:

> Hi Dilan,
>
>
>> Does this mean we can basically have a ready-to-use device plug-in
>> implementation, just by configuring a descriptor file ?
>>
> Yes thats the idea, In here the plugin means the osgiService which
> contains the definition of the device type. we found from the existing
> device type that it all follows the same implementation template as the
> plug-in(DeviceManagementService) implementation. Therefore I created a
> generic template which populates the DeviceManagementService through a
> configuration file.
>
> Thanks,
> Ayyoob
>
>
> ___
> 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

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

[Ayyoob Hamza]

Hi Dilan,


> Does this mean we can basically have a ready-to-use device plug-in
> implementation, just by configuring a descriptor file ?
>
Yes thats the idea, In here the plugin means the osgiService which contains
the definition of the device type. we found from the existing device type
that it all follows the same implementation template as the
plug-in(DeviceManagementService) implementation. Therefore I created a
generic template which populates the DeviceManagementService through a
configuration file.

Thanks,
Ayyoob
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

[Sumedha Rubasinghe]

Pretty useful. This also makes the device plugins deployable without
restarting the server.

I believe we can extend the same to write hot deployable device plugins
using Java (no OSGi).

On Tue, Oct 25, 2016 at 9:02 PM, Ayyoob Hamza  wrote:

> Hi All,
>
> Current structure for device type plugin for WSO2 IoT looks like following:
>
> devicetype-plugin
>  | - device manager extension (An OSGi service )
>  | - api (jax-rs)
>  | - UI
>  | - analytics (descriptors - deployer)
>
>
> However, what goes inside device manager extension component is pretty
> much a boiler plate code that can be replaced by a descriptor. This is
> common for all the plugins (eg: Android, Windows, Virtual Firalarm,
> Raspberypi, Android Sense ...) we have written so far.
>
> But the ability to write Java based device manager extension can be useful
> @ times where custom behaviour is needed.
>
> So I have done a PoC that will allow both of these approaches to be
> supported when writing a device type plugin.
>
> This concept is previously discussed in [1] too. A sample descriptor is in
> [2].
>
> [1] [Architecture] [CDM-F] "Descriptor"-driven plug-ins for CDM-F
> [2] https://github.com/ayyoob/carbon-device-mgt/blob/deploye
> r/components/device-mgt-extensions/org.wso2.carbon.device.mg
> t.extensions.device.type.deployer/src/test/resources/sample.xml
> [3] https://github.com/ayyoob/carbon-device-mgt/tree/deploye
> r/components/device-mgt-extensions/org.wso2.carbon.device.mg
> t.extensions.device.type.deployer
>
> Thanks,
> *Ayyoob Hamza*
> *Software Engineer*
> WSO2 Inc.; http://wso2.com
> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
/sumedha
m: +94 773017743
b :  bit.ly/sumedha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

[Ayyoob Hamza]

Hi All,

Current structure for device type plugin for WSO2 IoT looks like following:

devicetype-plugin
 | - device manager extension (An OSGi service )
 | - api (jax-rs)
 | - UI
 | - analytics (descriptors - deployer)


However, what goes inside device manager extension component is pretty much
a boiler plate code that can be replaced by a descriptor. This is common
for all the plugins (eg: Android, Windows, Virtual Firalarm, Raspberypi,
Android Sense ...) we have written so far.

But the ability to write Java based device manager extension can be useful
@ times where custom behaviour is needed.

So I have done a PoC that will allow both of these approaches to be
supported when writing a device type plugin.

This concept is previously discussed in [1] too. A sample descriptor is in
[2].

[1] [Architecture] [CDM-F] "Descriptor"-driven plug-ins for CDM-F
[2] https://github.com/ayyoob/carbon-device-mgt/blob/deploye
r/components/device-mgt-extensions/org.wso2.carbon.device.mg
t.extensions.device.type.deployer/src/test/resources/sample.xml
[3] https://github.com/ayyoob/carbon-device-mgt/tree/deploye
r/components/device-mgt-extensions/org.wso2.carbon.device.mg
t.extensions.device.type.deployer

Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture