OSGi is about modularizing your application. In our demo, we will have three projects (or three bundles) that will be deployed on Apache Felix. I suggest you download the following tools and ligraries before we start out with our project.
1.Apache Felix: http://felix.apache.org/
2.iPOJO library: http://felix.apache.org/
3.Ant: http://ant.apache.org/
4.Bnd tool from aQute: http://www.aqute.biz/Code/Bnd
The Problem Statement
Our problem is going to be very simple. Our service is a simple OSGi service that will display the string “Hello World”.
Getting Started
Like any OSGi service, our service is represented as an interface:
package hello.service;This will be our first project or first bundle. The bundle will have just the interface. Please note that you will have to export hello.service package when building the bundle. To make this task easy, use the bnd tool to create the jar. I have used Ant script to compile and package the projects. Once bundle is ready, you will use it as a dependency library for compiling other projects.
public interface HelloService {
public String sayHello();
}
Implementing our service
The next step is to implement our service. We will create a new project with previous projects jar file as a dependency. The service implementation is also POJO and there is no mention of OSGi service in the code. Let’s have a look at our implementation:
package hello.component;Now we define that we have a iPOJO component. This is done through a xml that is placed along with the project. The xml defines that, we have a component of the class hello.component.HelloComponent. The example below is a very simple one, you can have callbacks, properties set etc in this xml using different xml elements.
import hello.service.HelloService;
public class HelloComponent implements HelloService {
String message = "Hello World";
public String sayHello() {
return message;
}
}
<ipojo>We will compile this project into another bundle that will be deployed in the runtime.
<component classname="hello.component.HelloComponent">
<provides/>
</component>
<instance component="hello.component.HelloComponent"/>
</ipojo>
Using our Service
This is our final project. This project will be consuming the service we created above. The client can be a POJO or a Activator class. Like the service implementation code, we do not code for a service. Instead we go about and code as if the implementation is available to us. iPOJO framework would take care of the rest. Here is our "hello world" client:
package hello.client;I have some sys outs to see how our client work. Just like the service project, we have a xml that will define what is the required service, callback functions etc. Have a look at the xml:
import hello.service.HelloService;
public class HelloClient {
private HelloService m_hello;
public HelloClient() {
super();
System.out.println("Hello Client constructor...");
}
public void start() {
System.out.println("Starting client...");
System.out.println("Service: " + m_hello.sayHello());
}
public void stop() {
System.out.println("Stoping client...");
}
}
<ipojo>The xml specifies that HelloClient requires m_hello to execute. m_hello is a instance of our service. So as long as the service is not available, the HelloClient component do not get executed. The callback xml elements specify which methods to execute when the state of the component changes.
<component classname="hello.client.HelloClient">
<requires field="m_hello"/>
<callback transition="validate" method="start"/>
<callback transition="invalidate" method="stop"/>
</component>
<instance component="hello.client.HelloClient"/>
</ipojo>
Once compiling and packaging of this project is done, we are ready to deploy our example into a runtime and see it working. If you have Felix and iPOJO framework downloaded. Let’s configure Felix to load our bundles when it’s started.
Felix configurations are placed in config.properties under conf folder.You will have to modify the entires for felix.auto.start.1 variable. Here is how it looked like after I modified:
felix.auto.start.1= \
file:bundle/org.apache.felix.shell-1.0.1.jar \
file:bundle/org.apache.felix.shell.tui-1.0.1.jar \
file:bundle/org.apache.felix.bundlerepository-1.0.3.jar \
file:bundle/org.apache.felix.ipojo-1.0.0.jar \
file:bundle/hello.service.jar \
file:bundle/hello.component.jar \
file:bundle/hello.client.jar
We are ready now. Run your felix runtime to see the results! You may download the complete project and experiment with iPOJO. Good luck :)
4 comments :
Couldn't you include just a little more xml configuration?
Hi,
The tutorial was in view of beginners. Wanted to keep it as simple as possible.
I can write another tutorial on iPOJO configurations. I will look at it. Thanks for your comment
-- Abdel Olakara
Could you explain briefly what the benefits of using these services are?
In your example, which is kept simply on purpose, I do not see why I should use this concept as it is a lot more complicated as a straight-forward (or even a DI/IoC) solution could be.
Thanx.
Hi Klaus,
My example will look like a overhead. But when implementing real time services its going to reduce the work a developer has to do. iPOJO reduces the amount of work needed to create and wire a OSGi service.
The OSGi Service Platform sophisticated, component-based solutions and then assemble compatible software components on a customized, 'just-in-time' basis.
More specifically, it provides a standardized, dynamic module system for applications and services that use the Java platform.
Users can therefore manage the lifecycles of software components, which can be installed, assembled, updated, combined with other functions or removed 'on the fly' -- without stopping the OSGi runtime.
Hope things are clear now :)
-- Abdel Olakara
Post a Comment