| 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 
 |