Transport-Independent Remote Services

ECF recently released version 3.13.1 of it's implementation of the OSGi Remote Services and Remote Service Admin specifications.

Over the past year, we have made it much easier for us and others to create custom distribution providers.   This has made it possible to quickly create a variety of open source distribution providers...for example, HTTP/HTTP/REST/Jax-RS implementations, TCP, Hazelcast, JMS, AMQP, MQTT and JavaGroups) as well as others. 

Why is this useful and important?   In my view, it's important because it allows service developers to define, implement, and deploy transport-independent Remote Services.   Transport-independence gives the flexibility to address changing requirements without the need to alter the service.

For example, consider a small remote service for accessing a database of Students.  Ideally, the service interface, implementation, and client would be one distribution system/transport and never have be changed.   In practice, however, it's often necessary to respond to non-functional transport-related requirements...for example changing needs for interoperability/integration, changing security requirements, network performance requirements, bandwidth, service availability on an unreliable network, the need to use new protocols, etc. 

This new tutorial shows how Remote Services can be declared, implemented, deployed and versioned without any dependencies on the underlying distribution system or transport.   Pluggable distribution providers may be substituted with no service or application-level code changes.   This is accomplished by adherence to standards (OSGi Services/Remote Services and Jax-RS) as well as ECF's pluggable distribution provider approach.