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:
yeh that's amazing. congrats.
regards,
Sakith
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|