Difference between revisions of "OSGi Concepts Services"

From CDOT Wiki
Jump to: navigation, search
(mySOApic)
Line 43: Line 43:
  
 
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).
 
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:OSGi-DS.png|thumb|200px| ]]
+
[[Image:OSGi-DS.png|thumb|300px| ]]
  
 
The bundle consumer must implement the CommandProvider interface
 
The bundle consumer must implement the CommandProvider interface

Revision as of 12:45, 22 January 2011

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).

OSGi-DS.png

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";
	}
}