In a previous post, I described how ECF Remote Services provided a way to create, implement, test, deploy and upgrade transport-independent remote services.

A 'transparent' remote services distribution system would attempt to hide this fact from the service designer and implementer.   Alternatively, the ECF Remote Services approach allows one to choose a distribution provider(s) to meet the reliability and availability requirements for that remote service, and/or potentially change that selection in the future if requirements change. Also, the dynamics of OSGi services (inherited by Remote Services), allows network failure to be mapped by the distribution system to dynamic service departure. For example, using Declarative Services, responding at the application level to a network failure can be as simple as implementing a method:

void unbindStudentService(StudentService service) throws Exception {
 // Make service unavailable to application
this.studentService = null;
 // Also could respond by using/binding to a backup service, removing
 // service from UI, etc
}

1. The distribution system detects the failure
2. The distribution system maps the detected failure to a service unregistration of the proxy

If those two things happen, then using DS the proxy unregistration will result in the unbind method above being called by DS.But the two requirements on the distribution system above may not be satisfied by all distribution providers. For example, for a typical REST/http-based service, there may be no way for the distribution system to detect network failure, and so no unbinding of the service can/will occur.

The use of transport-independent remote services, along with the ability to choose/use/create custom distribution providers as appropriate allows micro service developers to easily deal with the realities of distributed computing, as well as changing service requirements.