Hello World

If there is one confusing aspect to OSGi then it is probably the bewildering array of programming models. One of the most asked questions lately is: why so many? Why doesn't OSGi standardize on one programming model?

Well, I think having these diverse solutions is proving the strength of OSGi. We set out to make a system that allows you to build applications from decoupled and highly cohesive modules. Decoupling means that you have no assumptions what happens over your (hopefully) close horizon. The dynamic nature of OSGi is a result of the fact that we did not want to bake in the assumption in every module that other modules are magically bound to their life cycle. However, this also means we wanted to minimize the assumptions about the programming model; we wanted to specify the absolute minimum to get collaborations going, but not more.

This clearly opened the road for others to provide programming models. And I think this is good because OSGi is about Universal Middleware. This implies that it is used in a large number of application areas: from copiers to large enterprise applications. Programming models can optimize the model for a particular application area and make it easier to use in that area. I am sure we could have specified something that was as useful as both iPOJO and Spring to their audiences. Still, because they both work on top of OSGi they can interoperate seamlessly. Components written with SAT interact with the Felix Dependency manager without being aware that these components are written with another programming model.

However, where do you start when you like to get into OSGi. So let us have a look at the different models and see how a simple Hello and Goodbye world would look in the different models.

The Example
All the examples are based on a HelloWorld service that has a hello() and goodbye() method. There is an implementation that logs the hello and goodbye messages and there is a client that calls these methods when it is activated and deactived (or when the HelloWorld service disappears).

public interface HelloWorld {
  void hello();
  void goodbye();
}

In the style of POJOs, we define our business logic in a client class and an implementation class:

public class HelloWorldClient {
  HelloWorld hello;

  public void setHello(HelloWorld hello) {
    this.hello= hello;
    if ( hello == null )
      this.hello.goodbye();
    else
      hello.hello();
   this.hello = hello;
  }
}

And the implementation:

public class HelloWorldClient {


  
  
}

Plain Old Osgi Objects
The plain OSGi way to attack the implementation is with a simple Bundle Activator.

public class HelloWorldImpl implements BundleActivator, HelloWorld, ServiceFactory {
public void hello() {

}
void goodbye();
}