Why OSGi?

I chose OSGi to develop this framework for several reasons:

The first (and main) reason is the flexibility that provides. In OSGi a service (as all services in Service Oriented Architecture) is formed by an interface and an implementation. To access a service you only need to know the interface, not the implementation. The implementation is automatically bound with the interface. And even you can manage many implementations at the same time!

This implementations can appear or disappear in real time, so at the beginning of your algorithm you could have 10 different crossovers implementations but only one at the end. OSGi gives you the capability of manage the dynamism of services.

To create a service you don’t need to touch code, just create an XML that specifies:

  • The interface (a normal Java Interface) to implement
  • The class that implement this interface(s).
  • And, if you need it, the methods to bind or unbind other service interfaces automatically (and set filters, the cardinality or the optionality). For example “I need at least two different crossovers to start”.

This is called Declarative Service Specification. If you need more information this is a good tutorial.

Finally, OSGi includes Event Admin manager. This service is a publish/subscribe mechanism. In normal OOP you call a method with arguments. With this mechanism you send the argument to “space” and the interested “guys” who need this data could filter and take it to use. For example, send an event when a fitness evaluation is performed and other service(s) could read this information for their purposes. The fitness operator don’t need to know how many other services are listening, neither have a control. This is another quick tutorial to understand the event admin.

But, what about distributed programming? The final advantage of OSGi is the Remote Services Specification, that means the local services are indistinguishable from the distributed ones in other process, machines or networks. The previous ideas presented are compatible with this specification. In my case, I am using Eclipse Communication Framework, but other implementations could be used. With this implementation you stablish how the services communicate (using REST, SOAP, TCP…) but you don’t have to modify the service code!

More information about this ideas, but more focused to the application in EAs, are in a journal revision process, so, I’ll notify when it is published 🙂

Advertisements

About fergunet

PhD at Computer Science. I like Doctor Who.
This entry was posted in OSGi and tagged , , , , . Bookmark the permalink.

3 Responses to Why OSGi?

  1. Pablo says:

    A few questions:
    – Does spring provide the same declarative approach?
    – How reliable is the EventAdmin service?
    – What is the performance overhead of using the Eclipse Communication Service?

    Thanks.

    Pablo.

    • fergunet says:

      – Yes, Spring has the same approach, you can select an specific implementation in the XML definition. However, I am not sure if it can manage several implementations at the same time and in a dynamic way as OSGi does (I used Spring 4 years ago).
      – If you are using Event Admin in the same machine it should work as a normal listener model. It also provides synchronous and asynchronous posting of events, so the second. I also tested it in distributed machines just for synchronization purposes and worked well.
      – It depends of the provider you need to use. Now ECF includes several transmission mechanisms such as JMS, XMPP, TCP, REST… but you can extend it implementing a new provider, so I think it depends of the provider you use. I have in mind to perform an algorithmic study and profiling with all available providers (and Event Admin) to study the overhead (that obviously, exist). In the case of Evolutionary Algorithms it is not a good idea to add overhead for each operation (there are thousands of operations in each generation), so, for example, instead of call a method for each individual is better to send a list of the whole population. Of course, is better to work with large problem instances if you are going to parallelize the algorithm (but this is applicable to all EA frameworks).

      This issues are still under investigation, of course, every conclusion I find will be published here.

      Regards!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s