| Re: [ecf-dev] Egg cooking |
|
Hi Wim,
Congrats on the talk acceptance. After listening to yet another radio show about the 'the Internet of things' (what is it?, why would anyone want it?, how is it going to be made safe?, etc) I had the following idea: perhaps you could show that having guarantees of failure detection for remote service (with an unreliable network) could be shown to make this cooking example *safer*. I'm thinking of the following scenario: say some device (or UI) tells the 'hotplate' device to turn itself on to begin cooking...via a remote service. Suppose that the network connecting these devices goes down for whatever reason, with the hotplate still on (!). Using one of the remote service providers that does failure detection (e.g. generic, jms), this will mean the host remote service container will get notified about the failure after some configurable timeout, and can take appropriate action (e.g. turn everything off, ring alarms, etc). Via ECF's impl of OSGi Remote Services/RSA, this can all be accessed at the level of the remote service being registered and unregistered...rather than requiring lots of extra app-level code to handle these such failure cases (which obviously don't occur for the local case). The idea here is to use the dynamics of OSGi (remote) services to represent network failure, rather than requiring the service or app creator to write a lot of app-level functionality to safely handle such cases. This along with the other aspects of ECF's impl of OSGi (remote) services...e.g. discovery, async/sync remoting, high-level service abstractions (service type interfaces), multi-provider support for distribution and discovery, service type versioning, OSGi service-level security/service permissions, could I think make a very strong case for the use of OSGi remote services as a scalable, flexible, IoT communications infrastructure. Scott On 8/15/2014 12:35 PM, sakith indula wrote:
|