Oct 28 2008

Scripting the bundles for OSGi platform

Category: Uncategorizedciukes @ 11:20 pm

Working with Eclipse platform for my previous employer I never complained about OSGi platform. The bundles, the life cycle, the services specification – all this together makes a great foundation for properly designed application with a number of reasonable components. But the thing that always bothered me is the obligation to develop service bundles in Java only. More I think about this more it becomes a limitation.

If you like to learn more, please read Quick Intro to OSGi before continuing otherwise skip the following paragraph.

Quick Intro to OSGi
Common product build on OSGi platform is a set of bundles. OSGi bundle is a piece of code that may consume or be consumed by other services. Anyone familiar with Spring (or any other IoC framework) should think about components and dependency injection. All the other should think about Puzzles, pieces have to match each other to create big picture – the application.

My attitude is to use right tools for the task and Java is not always the best choice. Unless you are programming language orthodox willing to grow beard then live in the darkest corner of the office and become ‘the useless java guy’ (think of a COBOL programmer while picturing this) you have to admit that the Java world needs dynamic languages like any human needs fresh air. Compilation time checking, interfaces, inheritance, strong typing and hard to use reflection is way too much for modern lighting fast development. The JSR-223 specification and the fact that JRuby and JPython/Jython developers are on Sun Microsystems’ payroll only proves I’m right. (not to mention desperate attempts to introduce a new scripting language: JavaFX).

Having said that, I want to share with you the idea of scripting bundles for OSGi platform. I’m not the first one who is trying to do this but the first who dares to do it at low level and in a portable way (see resources). I hope you will think about the idea and give me some feedback. Ideas for extension, possible problems, use cases – any kind of feedback will be appreciated. I really need it.

Q: Why provide scripting anyway?
A: Being through a lot of projects I had many occasions to compare the way how you tackle problems with different programming languages. In some situations you may win by putting Java aside for a moment and develop a smart script that will do the work in more efficient way.
Q: We have JSR-223, isn’t that enough?
A: The specification defines unified API to use scripting engines, but it has nothing to do with OSGi platform. You may use JSR-223 in your Java bundle but you will still need a piece of wrapper code around a script. The idea is to not use Java in bundle at all – pure scripting to the bones (well, very small amount of Java is acceptable).
Q: What is the benefit for Java people?
A: You can switch between Java and other scripting languages virtually at no cost.
Q: What is the benefit for ‘Ruby/Python/Perl/JavaScript/Other scripting language’ developers?
A: Access to OSGi platform and all the bundles.

The idea itself is very simple at high level but I expect to have a number of small problems at low level. The project is more an attempt to implement all the ideas I have in my head than an attempt to save the world. This is why I share this with you. Thinking through is always better in a group than alone. Let me introduce what I have so far. The scripting engine I took for a test drive is JRuby, the OSGi platform is Eclipse Equinox. I made a little evaluation to test the basics of the idea. Initial set of challenges is small:

  1. Auto-discovery and initialise scripted bundle
    This is a simple extension to standard bundle manifest file. I assume one may want to call a script when when bundle is started/stopped. Ideally I would like to see a solution similar to Spring OSGi project – A listener that can discover scripted bundle and give it a proper initialisation.
  2. Test if scripts can include other scripts located in the same/other bundle
    This one required me to do some hacking in JRuby internals to make it aware of OSGi existence. The changeset is not too intrusive and the original behaviour of the engine remains intact.
  3. Package JRuby as OSGi bundle
    I started with simple ‘create plug-in from JAR archive’ action and then switched to custom plug-in build from sources because of issue #2
  4. How to deal with ruby gems?
    No progress on this one. This is a placeholder for brainstorming: (e.g. Can a Ruby gem be a bundle? Can an OSGi service be a Ruby gem?)

All the work so far is not even a proof of concept, it is only a try out before real work starts. However I see the idea is going to work and JRuby is a good choice for starters. I give myself six months for evaluation and development (feel free to join me). After that time you may expect to read a summary here. You will also get short updates on progress in the meantime.

Please remember to visit the project website and share your thoughts with me.

Resources:

Tags: , , , , , , ,