OSGi Services
Service Layer
The Service Layer provides a dynamic, concise and consistent programming model for Java bundle developers, simplifying the development and deployment of service bundles by de-coupling the service’s specification (Java interface) from its implementations. This model allows bundle developers to bind to services only using their interface specifications. The selection of a specific implementation, optimized for a specific need or from a specific vendor, can thus be deferred to run-time (see OSGi Service Platform).
- A bundles can register and use services in OSGi. OSGi provides therefore a central registry for this purpose. A service is defined by a Java interface (POJI - Plain Old Java Interface) [1].
- Access to the service registry is performed via the class BundleContext. OSGi injects the BundleContext into each bundle during the startup of the bundle. A bundle can also register itself to the BundleContext ServiceEvents which are for example triggered if a new service is installed or de-installed.
For example, let us suppose that one wants to define a service that is capable to define the day and time. For the purpose one defines an interface:
package cs.ecl.osgi.simple.declarativeservice.say;
public interface Sayable {
String say();
}An implementation of this interface could be:
package cs.ecl.osgi.simple.declarativeservice.say.internals;
import java.util.Date;
import cs.ecl.osgi.simple.declarativeservice.say.Sayable;
public class TodaySay implements Sayable {
public String say() {
return " Declarative Service: Today is " + new Date();
}
}The relationships between the interface that is exposed to the client and the implementation that is hidden, must be defined in a xml file:
<?xml version="1.0"?>
<component name="sayable">
<implementation class="cs.ecl.osgi.simple.declarativeservice.say.internals.TodaySay"/>
<service>
<provide interface="cs.ecl.osgi.simple.declarativeservice.say.Sayable"/>
</service>
</component>Thus, the bundle that provides the service could register its services to an OSGi registry, while the bundle that needs the service could query the registry. The model is Service Oriented Architecture (SOA) inside the JVM (Java Virtual Machine).
The bundle consumer must implement the CommandProvider interface
package cs.ecl.osgi.simple.declarativeservice.consumer;
import org.eclipse.osgi.framework.console.CommandInterpreter;
import org.eclipse.osgi.framework.console.CommandProvider;
import cs.ecl.osgi.simple.declarativeservice.say.Sayable;
public class SaySingleConsumer implements CommandProvider {
private Sayable s;
public synchronized void bindSayable(Sayable s) {
this.s = s;
}
public synchronized void unbindSayable(Sayable s) {
this.s = null;
}
public synchronized void _run(CommandInterpreter ci) {
if (s != null) {
System.out.println(s.say());
} else {
ci.println("Error, No Service of type Sayable available");
}
}
@Override
public String getHelp() {
return "\n\t run - EXECUTE the Sayable service";
}
}