| Re: [ecf-dev] Egg cooking |
Hi Wim,
You might also want to make the following point wrt remote services operating on unreliable networks:
1) OSGi Remote Services spec *allows* implementations to map network failure (e.g. network partitions, host failures, etc) onto OSGi service dynamics. What do I mean by this? Well, let's say you are a client/consumer of a remote service, and the network partitions/fails underneath that remote service. One intuitive possibility is that for the consumer, that the OSGi remote service proxy goes away (gets unregistered locally). This can/would trigger things like DS unbind/bind, ServiceTracker notification, and/or ServiceListener notification on the consumer of the remote service, allowing it to respond at runtime. For example, in your hotplate scenario...there could be logic for shutting down/off the hotplate if the remote service disappears because of network partition or host failure.
2) To get the runtime behavior described in 1, however, it depends upon some sort of reasonably timely *failure detection* in the RS/RSA implementation. Such failure detection is not at all guaranteed by the RS specification, and in fact, is only even known by me to be present in ECF's RS implementation.
3) With ECF's provider architecture, it's quite possible to design/develop/test the remote service using one (or several) remote service providers, and then test/deploy with either the same or some other provider. This makes it quite easy for failure detection to be *added or changed* as required by the application needs, without totally replacing the RS/RSA implementation. Also, with some remote services the non-functional requirements for reliability may very well change during impl/testing/deployment, and this can be easily accommodated without having to replace the entire RS/RSA implementation. This flexibility is one very tangible benefit of ECF's open, mature APIs, modular provider structure. To be direct about it, I don't know of any other RS/RSA impl where such modularity even exists.
Sorry for the long posting, but reliability/partial failure is often a very big deal for applications (sometimes for safety reasons as in your demo!)...and it's very difficult to handle in general for distributed systems. So it might be helpful if we made these points about ECF's open modularity/provider architecture as frequently and as publicly as possible.
Thanks,
Scott
On 8/16/2014 3:59 AM, Wim Jongman wrote:
WimCheers,Hi Scott,Great idea. I will do that. I have already bought the hotplate and have successfully switched a relay with the remote pins (I did not yet dare to switch a 1000 watt heatplate ;). Next step is to hook up a heat sensor.
On Sat, Aug 16, 2014 at 12:05 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
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
On Fri, Aug 15, 2014 at 2:26 PM, Harshana Eranga Martin <harshana05@xxxxxxxxx> wrote:
Cool! :-) Congratz!
Thanks and Regards,
Harshana
--
Harshana Eranga Martin
Senior Software Engineer
Asian Mobile Banking
Web: https://www.commbank.com.au/
ECF Committer: http://www.eclipse.org/ecf/
Blog: http://harshana05.blogspot.com
Profile: https://www.google.com/profiles/harshana05
On 15 August 2014 16:46, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
_______________________________________________Cheers,Hi,Our talk is accepted [1].
Wim
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
_______________________________________________
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
--
Sakith Indula,Depatrment of Computing and Information Systems,Sabaragamuwa University Of Sri Lanka.
_______________________________________________ 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
_______________________________________________
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
_______________________________________________ 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
_______________________________________________
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