Note that 'transport-independent' does not mean 'transparent'.
For example, with network services it's always going to relatively likely that a remote service (whether an OSGi Remote Service or any other kind of service) could fail at runtime. The truth of this is encapsulated in the first fallacy of distributed computing: The network is reliable.
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
}
This is only possible if
- The distribution system detects the failure
- The distribution system maps the detected failure to a service unregistration of the proxy
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.
