OSGi and AJAX

The new kid on the block is AJAX. I couple of weeks ago a marketing guy dropped this in the conversation and I had no idea what he was talking about. Of course for me Ajax is the king of Salamis,a legendary hero of ancient Greece (I love Wikipedia!), and the relation to HTML totally escaped me.

Now I know better, today I just finished my first AJAX program, and it works on Firefox and IE 6. For the few among my readers that are even later in catching up, a short introduction to AJAX.

AJAX stands for Asynchronous, Javascript And XML. It is an interesting example of an anarchistic standardization process. For some reason, all the major browsers allow you to initiate an XML file download and process the elements independent from the page load. The JavaScript code can then use the information in the XML to create/modify any of the HTML elements that are on the page.

As an exercise I wrote a small RSS feed window that automatically updates when there is new data available, without having to refresh the page. Comments are spread through the html file so you can take a look at the source. Surprisingly, so far it worked on all the browsers I tested.

But what has this to do with OSGi? Well, the OSGi has been struggling with the UI since its inception. The embedded domain that the OSGi Alliance initially addressed has a wide diversity of user interfaces. Sometimes they have a small display, sometimes they can only be used through a web interface, or sometimes there is no UI to speak of. During the specifications of the OSGi for Vehicles, we had several intense sessions about this subject. Unfortunately, there was no consensus in site.

AJAX is a technique that permits the complete separation of view/controller and model, also called MVC. This technique from ancient times (Smalltalk 80 '72) is highly recognized as a way to minimize maintenance cost of GUI applications. The idea is that you have a module that is responsible for the data. The data can only be modified using a number of clearly defined interfaces.

The OSGi Http Service provides excellent facilities to act as a web server. It is very little work to make a servlet that create XML files based on an underlying data structure. AJAX pages create requests for this XML, where the request parameters provide the interface to modify these data structures. I intend to make a demonstration bundle available in this forum.

I have used AJAX to make a page that shows the build status for the OSGi Reference Implementation and Test Suite. I really like the idea behind it, however, coding is not difficult because there is no standard support in Javascript to easily traverse the DOM tree or the XML. The navigation routines in JavaScript fall woefully short of what it should have been. Sometimes you have to use insane and error prone lines like:

  content += 
    items[i].getElementsByTagName("title")[0].childNodes[0].data; 

Navigation of XML trees is of course the domain of XPath. Mozilla has implemented an XPath evaluator but this is unfortunately not supported by the other browsers (yet?).

So, AJAX is good news for bundle developers. The only problem is the ugly Javascript that is often needed to write the code. A standard library could reduce the amount of Javascript needed. Anybody interested in standardizing such a library for OSGi platforms? A standard library significantly improves the interoperability between applications that share the same web server.

 Peter Kriens

posted by Peter @ Thursday, December 01, 2005