Difference between revisions of "OSGi Concepts Services"
Line 16: | Line 16: | ||
</source> | </source> | ||
− | |||
An implementation of this interface could be: | An implementation of this interface could be: | ||
Line 43: | Line 42: | ||
</source> | </source> | ||
− | 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). | + | 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). |
− | [[Image: | + | [[Image:OSGi-DS.png|thumb|200px| ]] |
The bundle consumer must implement the CommandProvider interface | The bundle consumer must implement the CommandProvider interface |
Revision as of 12:39, 22 January 2011
Main Page · Course Description · Course Topics · Schedule, Students, Teams · Course Resources · Course Projects
OSGi Services
- 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";
}
}