Restlet and OSGI remote services - Part 1
Join the DZone community and get the full member experience.Join For Free
ECF recently released a standards-compliant implementation of OSGi 4.2 remote services admin (RSA).
RSA promises the easy integration with existing SOA frameworks in a standardized OSGi remote services context. To prove the utility of this to myself I decided to integrate the popular Restlet API with ECF's RSA impl expose REST-based web services as standards-compliant OSGi remote services.
I was very happy to find that with the Restlet API, the Restlet-OSGi-integration work, ECF's RSA impl, and ECF's REST API, that doing this was about two-days' work. In addition to being simple to do, there are several advantages of doing this...both for service consumers and service hosts.
Advantages for Service Consumers
- Many clients can/are immediately supported (e.g. browser, new clients, servers that access the service, etc)
- No client-side development at all. ECF's RSA impl creates a proxy (as well as an asynchronous proxy), and makes that proxy available within the local OSGi service registry...with no development at all. This makes it easy to also use OSGi declarative services, Spring/Virgo, or other frameworks to access remote services
- OSGi classloading subtleties are fully dealt-with, as ECF's RSA impl handles the proxy creation in a standardized, secure, service-independent way
- Service interface versioning is automatically supported...by the RSA spec
- RSA's discovery can be used to publish and discover a remote service. With ECF's impl of RSA, this allows the modular use of a variety of network discovery protocols, including Apache Zookeeper, DNS-SD, Service Locator Protocol, Zeroconf/Bonjour, xml-file-based...and also enables using one's own discovery mechanism (proprietary or not)
In another posting, I'll describe some of the advantages on the service host side (i.e. the OSGi server that publishes/exposes the Restlet service).
Opinions expressed by DZone contributors are their own.