These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Why dynamic modules?
Author
Previous Topic Next Topic
Salgare
Center for Advanced Studies
Gallente Federation
#1 - 2016-08-30 20:02:35 UTC
Lucia Denniard, Diana;

Here is one possible scenario for the need of an api to framework to spi on an embedded device.

You have a home that has a single bridging device from the home to the cloud, running an api/spi framework. This framework could be viewed as a "plug-n-play" both on the api side (cloud side) and the spi side (inhome). Say the home owner buys some new off the shelf electronic device that happens to support control4, or zigbee, or opendof. The controller can recognize the new - inside the firewall/home protocols/devices and dynamically download the needed bridging module for that device.

We did a system like this in japan which required full 3 phase security. The factory burnt private keys in the off the shelf devices which allowed access to a cloud security service which would register the device and then issue a new private key to the device.

The home owner could then purchase various subscription services which would also automatically download service modules. Since this bridging framework device is running on a single jvm, there is a common library of jars on the system, however some devices/services require different versions of the same modules, thus multiple versions of the same jar can exist in the same framework feeding different consumer modules.

In OSGi if one breaks their application into three jars, dynamic software updates of the service can happen bump-less.

Client jar utilizes only a pure interface jar, which has an implementation jar. With the implementation jar being the module most likely to require modification.
Salgare
Center for Advanced Studies
Gallente Federation
#2 - 2016-08-30 22:03:57 UTC  |  Edited by: Salgare
Diana, based on the last devfleet conversation do I understand that you concede the OP architecture is beyond what say Elixir could produce on its own?

Now if we could focus on coupling and that OO is not just about polymorphism and encapsulation in a given "unit" (class in java) but it involves coupling concepts with other units. Loose coupling is critical for extensibility of several OOA patterns.

It is common for Loosely coupled modules to be determined at load time, with some implementations allowing for loading at full runtime.

If I remember correctly, the comment came up about what this has to do with OO programing, implying that the OP framework could be written in a non-OO language. This is where my argument of complexity turning into spaghetti code comes into play. This is exactly what we did in the C days, which is what drove to c++ and java in the first place.
Diana Olympos
Deep Core Mining Inc.
Caldari State
#3 - 2016-09-22 18:06:14 UTC
Download the module needed, update it, and voilà ?
Salgare
Center for Advanced Studies
Gallente Federation
#4 - 2016-09-22 18:39:15 UTC  |  Edited by: Salgare
Diana Olympos wrote:
Download the module needed, update it, and voilà ?


You seem to have blown past the majority of the problem domain

I can provide an OOA UML diagram of the problem domain if that would help.

I'll highlight some of the requirements:

You have a home that has asingle bridging device from the home to the cloud, running an api/spi framework. This framework could be viewed as a "plug-n-play" both on the api side (cloud side) and the spi side (inhome). Say the home owner buys some new off the shelf electronic device that happens to support control4, or zigbee, or opendof. The controller can recognize the new - inside the firewall/home protocols/devices and dynamically download the needed bridging module for that device.

We did a system like this in japan which required full 3 phase security. The factory burnt private keys in the off the shelf devices which allowed access to a cloud security service which would register the device and thenissue a new private key to the device.

The home owner could then purchase various subscription services which would also automatically download service modules. Since this bridging framework device is running on a single jvm, there is a common library of jars on the system, however some devices/services require different versions of the same modules, thus multiple versions of the same jar can exist in the same framework feeding different consumer modules.

In OSGi if one breaks their application into three jars, dynamic software updates of the service can happen bump-less.

Client jar utilizes only a pure interface jar, which has an implementation jar. With the implementation jar being the module most likely to require modification.
Salgare
Center for Advanced Studies
Gallente Federation
#5 - 2016-09-23 22:49:49 UTC