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:
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.
Cheers,
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
|