Difference between revisions of "OSGi Concepts Services"

From CDOT Wiki
Jump to: navigation, search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Ecl_menu}}<h2>OSGi Services</h2>
 
{{Ecl_menu}}<h2>OSGi Services</h2>
 +
 +
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 [http://www.osgi.org/Release4/HomePage 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) [http://www.vogella.de/articles/OSGi/article.html#OSGiintro_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) [http://www.vogella.de/articles/OSGi/article.html#OSGiintro_services].
Line 16: Line 25:
  
 
</source>
 
</source>
 
  
 
An implementation of this interface could be:
 
An implementation of this interface could be:
Line 43: Line 51:
 
</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:filename|thumb|widthpx| ]]
+
[[Image:OSGi-DS.png|thumb|300px| ]]
  
The bundle consumer must
+
The bundle consumer must implement the CommandProvider interface
 
<source lang="java">
 
<source lang="java">
  

Latest revision as of 08:57, 25 January 2011

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

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