OSGi and the User Interface

A problem I have been working on last week with a friend is the user interface (UI) for an embedded device (he actually works on providing personalized health information, but the problems are very similar). We did not start this field, the problem has been bugging the different expert groups since the OSGi began in 1998. Tom Idermark from Ericsson and I once wrote RFP 8 for “Client Access”. I even developed a prototype on an OSGi Release 1 framework. The RFP is now 7 years old but still reads as if it was written yesterday.

So what is the problem? In an OSGi device, the UI must be adaptive to many influences: The available services, the end users, the output device, the state. At the same time the UI must run on a device severely constrained in memory and CPU cycles, not an easy problem.

This is hard, and I mean really hard. The main reason why it is so hard is that the user interface is a highly valued piece of real estate; the user identifies all the services with what it will see on the screen. Being a good citizen and seamlessly blending your bundle in the generic UI does not always improves your relationship with the marketing department. Telling them that the logo is a bit warped because the generic version did not map well to the hardware is likely to make enemies for life; only Microsoft gets away with warped logos.

Still, from a usability point of view it is important that we find a (non exclusive) solution to the OSGi UI problem. Such an OSGi UI should address the following concerns:

• Bundles should be able to provide information, receive information, as well as notify the end user(s).


• Securely accessible local and remote


• Must be able to look very good


• The style should be consistent on a device, without requiring the bundles to be intricately aware of that style


• The end user(s) must be able to control the UI, if applicable

Web based UIs have an advantage here because they can be accessed remotely and locally, they can offload some processing to the client, today’s HTML can be used to build very rich UIs, and there is a lot of experience. The key problem is the portability of the different web techniques. Last week I was again confronted with the surprising variations browsers display in their Javascript and HTML implementations. The OSGi specifications supports Servlets, objects that generate web content, usually HTML. Servlets have the disadvantage that they want to control a complete page, it is very hard to merge the output of multiple servlets into a single page.

Portals are software frameworks that address some of these issues. The JSR 168, which is implemented in the Apache Pluto project, addresses some of the issues. Portlets are like servlets but deliver a fragment instead of a whole page. The Portal container merges different Portlets onto a single page.

However, Portals are really oriented to heavy weight computing and not applicable for smaller devices. The Portlets approach to the site style is too lightweight; it only defines a few Cascading Style Sheet classes for this purpose. Interestingly, Google has analyzed 1 billion web pages for their HTML coding style and found a surprisingly small number of primitives. Supporting the top 20 primitives would go a long way. Kumanan Yogaratnam and Eddie Drake of Espial and Myrio proposed a solution in this direction last OSGi congress.

A significant disadvantage of HTML is that the content gets mixed with form. The alternative is XML, and I have very good experiences with bundles that provide XML instead of HTML. The required formatting, based on the output device, is then created with different or a combination of XSLT stylesheets.

I have no complete solution but it looks like the parts are coming together to provide a more complete solution. Now we only have to find a group of companies that need this desperately so we can spec it!

     Peter Kriens
     OSGi Evangelist

The OSGi from a Python Perspective

Years ago, in the eighties and early nineties I spent every Wednesday night from 8 PM to 3 AM hacking with a Petr van Blokland, a long time friend. We spent our time doing a virtual tour through the computing world. We used any possible language, library, or created new ones when necessary. We even wrote our own Prolog interpreter. We developed lots of programs and had even more fun. After I moved to Sweden we kept in touch but all night hack sessions were of course no longer possible.

Yesterday he was here in Beaulieu and I introduced him to the OSGi specifications. It was kind of scary to see how great the divide has become technologically. I had to move to the PC because of Java in the late nineties, he kept on buying Macs. He fell in love with Python and I had to use, well again, Java. Though we always are much at ease with each other on the semantic level, the lack of common ground is a big challenge.

For me his visit is a wonderful opportunity to see how a highly experienced and intelligent software developer looks when he is confronted with OSGi out of the blue. The biggest hurdle is of course Java. I complained before, and will complain later, but Java is a very crufty language (try using inner classes). It is amazing how clean a Python class looks in comparison to a Java class with the same functionality.

I tried to get him hooked on Python development in Eclipse (that at least would give us a Geneva where we could further negotiate). We tried PyDev and TruStudio. Though neither plugin is bad, they still pale in comparison to the Java support in Eclipse. Eclipse is the first IDE I accepted because its support for Java development is fantastic. However, I do not think I would use Eclipse if the Java support was on par with PyDev/TruStudio.

We decided to try to make a bundle that used Jython servlets. Jython is a implementation of Python on Java. Wrapping the Jython JAR turned out to causes all kinds of packaging problems because it was using lots of external links. It was kind of sobering when you realized how arcane much of the work is you have to do to make a simple bundle. We then moved on to declarative services and there I also saw the XML with the eyes of a highly skilled Python developer.

I am the first person to know that for each piece of cruft in the declarative service XML, or Java source code, or manifest, there is a good reason. The OSGi Alliance tries to solve a problem that is very hard: make independently developed applications work together. This is much harder than a monolithic application, but we should not forget that simple things should remain simple. There is an increased awareness of this, noticing the LAMP and Ruby on rails discussions that all reflect badly on Java.

Several parties are working hard on making tools that will take any pain out of bundle development. The Eclipse team is improving their plugin development tools (a plugin is a bundle, not sure why they stick to the name plugin) and I had the pleasure of testing an SDK for the next generation mobile phones. The SDK uses a different technique than the standard Eclipse Plugin Development Environment, I actually prefer theirs over the Eclipse variation. For example, the SDK allows multiple deployment artifacts from the same bundle which Eclipse does not allow.

Both environments are just not good enough yet, I feel.  Neither has a really clear UI that guides you through the process and helps you add new features, all editors are very focused on a single artifact instead of taking a more holistic approach. Then again, Eclipse has only recently adopted the OSGi specifications and it is natural that the tooling will take a couple of iterations to get it right.

On the plus side, when we had entered all the cruft and updated our first bundle, I could see his eyes light up when he realized we never had to restart the framework to get the new functionality up and running. That part always remains sooo cool.

TomTom for Sale, Trades for OSGi Phone

Yesterday I had to attend the Vehicle Expert Group meeting in Sophia-Antipolis (Nic)e at Siemens VDO. Nice is about 300 km from where I live so I decided to drive. Got up at 5.45, in the car at 6.15, and after programming the TomTom navigation unit I was on my way. It was a beautiful day so I enjoyed the stars, the twilight, the sunset, and a wonderful espresso. After 2.5 hours, Truus (as we call the TomTom) told me to take exit 42. This was not the normal route so I naïvely concluded that Truus had found a better way. After 45 minutes in traffic jams on small back-roads I ended up in the middle of nowhere: I had told Truus to go to “Lucioles”, not realizing that Sofia-Antipolis has 3 different places with Lucioles in the name. Obviously, the first line had not been the right one. Entered the right spot (I thought), went there, found that the Siemens VDO had moved. Had to dig up the new address on my computer but unfortunately, Truus feigned ignorance of “Avenue de Roumanille”, or for that matter any other road I could see in the neighborhood. I called the meeting host, Olivier Pavé, but got no answer. I then drove up to an information area where I still could not find the place on the map. Fortunately, Olivier called me and told me he would pick me up. Anybody interested in a second-hand TomTom?

At first I blamed my self for not being more prepared but then I started thinking. Why do we always blame ourselves? Isn’t it the task of the technology to handle the chores of life?

• Why did it force me to enter an address, which is error prone (especially at 6.15 in the morning!).


• Why did I have to rely on the last address I had, while it could have been updated over the net?


• Why did I have stale maps (they were bought in April last year, the road clearly looked older than 2 years)?

I told the group that what I really want is to tell my navigation system to go to “Olivier Pavé”. We discussed this use case, how it could be implemented. The navigation system could send an SMS to Olivier, which then replies with its position (after confirmation of course). The navigation system then just navigates there. Nice use case! Unfortunately my TomTom is a closed system so implementing this use case is a major amount of work. Even if I could operate on Truus (she is running Linux), I would have to invest a major amount of work to only one brand.

Olvier Pavé then told me about their plan to port a Midlet based online navigation system to the OSGi Mobile Service Platform. Nokia had promised them a phone to make this prototype. They demoed the Midlet, leaving Truus in the dust, because it knew the “Avenue de Roumanille” in the smallest detail!

In the OSGi Mobile Platform architecture, they would have to split the navigation system in a Navigation Service, a Position service, and a Navigation UI. This architecture would enables me to write an application that implements my  “Go to Olivier” use case, without having to write my own navigation system (and without having to go to a standardization process). Such a use case is impossible with MIDP.

This example clearly illustrates the vision of Jon Bostrom, Nokia’s Director for Java: Provide a platform for middleware and third parties will create an avalanche of innovation. Fortunately, operators are starting to see the light: Sprint has just become an OSGi member. Welcome!

     Peter Kriens
     OSGi Evangelist

Why You Should Bundleize

Being ahead of the pack is not always easy. This weekend I wasted hours and I’ll blame the rest of the world that they haven’t seen the benefit of OSGi yet.

I am preparing an OSGi course that will be posted on this site. One of the components is support for Rendezvous/Bonjour/mDNS. Behind these aliases is a zero-configuration architecture developed by Apple. The interesting part for me is the serice location protocol. Apple used a very clever trick: multicast DNS. DNS always had the possibility to provide information about services with the SRV query. However, normal DNS consists of dedicated servers that are configured with the required information. With a service location protocol you’d rather have a solution where each device could provide this information independently. The trick was to have a DNS server in each device combined with multi-cast addressing. A device that wants to know a service or address just broadcasts the query, any device that has the given information responds with the answers. This is of course a bit of a simplification, the complexity of the protocol lies in the optimizations to reduce traffic.

So I wanted a bundle supporting the mDNS protocol. After a lot of searching I found an article that described a Java implementation called jRendezvous. This looked good, at least it looked like a decent implementation and the license was LGLP. I should have looked further …

I took the library, copied it in Eclipse and turned it into a bundle, 10 minutes work. Unfortunately, it did not work as it should; the service was discovered but could not be resolved. The library fortunately included a browser. This browser recognized my Xerox printer immediately, but it did not resolve my test service. After several hours of debugging well written, but unfamiliar, code I found the problem. The library was written with a well configured DNS system in mind. I did not have such a DNS configured, which meant my IP address ended up in the record as the host name and confused the library. The browser tried to resolve the IP address as if it was a hostname and this obviously failed. The fix was easy and I was so happy. Being a good citizen, I tried to find a way to provide the author of jRendezvous with the patch. The package was written by Arthur van Hoff, one of Java’s founding fathers. Out of curiosity I clicked on the Products link of his site and was unpleasantly surprised with one of those products: JmDNS, a new and novel implementation of the jRendezvous library. Sigh.

So downloaded the project from sourceforge (they had changed the license to Apache 2.0) and spent another 10 minutes turning this code into a bundle, hoping that my problems were fixed in this new release. Unfortunately, it was not fixed, worse the structure of the code was significantly different so I would have to start debugging again. I decided to report the issue to the JmDNS forum, see what happens.

The underlying problem of this story is of course unrelated to JmDNS. We, as an industry, need a standardized format and catalog for software libraries. The OSGi Service Platform is the only suitable candidate for such a delivery model. The OSGi platform provides a good module system for Java that makes it an excellent candidate for such a repository. The OSGi Alliance is working on finalizing the OSGi Bundle Repository, do you have the bundles to fill it?

     Peter Kriens
     OSGi Evangelist

Your Personal Dietitian

What is the fun of conferences? Why travel thousands of miles to sit in stuffy rooms without windows but too many co-geeks; hear information that is so detailed and focused that you will rarely need it? Well, these places still seem to attract a large concentration of highly intelligent and creative people that can revive the excitement of your own work. This week, I was at the CCNC 2006 in Las Vegas this week where the posters and demos created the excitement for me (after our OSGi panel of course!).

The most intriguing demo/idea came from Ellen Badinelli from Scanavert. This company has come up with the idea to match product identifications (UPC, Barcode, RFID, etc) with personal information. She fired of a scary number of food/medication incompatibilities that would almost make you afraid to eat. One of the many examples: Using orange juice together with antibiotics severely reduces its effectiveness.

There are not just food-food or food-medication incompatibilities. Allergies, illnesses, being male or female, age, race, or pregnancy can influence the effectiveness or danger of food as well as medications. For example, using certain pain-killers while pregnant can cause serious harm to the fetus. Ellen pointed out the male conspiracy of Tylenol warnings: Alcohol consumption is pointed out but the dangers to pregnant women or not on the package. Many of these threats or loss of effectiveness are very obscure and are therefore missed by most people.

Obviously nobody with an actual life has the time to be aware of all these possible interactions. To be honest, I am not even sure I want to be aware of this as a person in good health. However, when your child has an allergy, when you are pregnant, or when you use certain medications it would be nice if you could get some help tracking these issues. With our ageing populations, the need for this type of assistance will clearly increase.

Scanavert’s basic idea is to use product identification codes (bar codes, RFID) to identify products, look up their ingredients and match them against other foods and medications that are used as well as a personal profile. The software then flags any known dangers. The intriguing part is how people will use this service. Scanavert’s basic idea is that shoppers use a device to scan the bar code (or read the RFID tag) and get a message when there are issues. For example, the mum (this is a quotation, real men do not shop) does the shopping and scans all the goods she places in her cart. The device then warns her for any threats or provides advice.

I am not sure about scanning all the goods, from my experience people refuse to do any effort unless there is an acute need or payoff. However, as a parent of an allergic child or in other cases of heightened awareness, it would be great if you could point your mobile phone to a product and get personalized information about that product. “Are these cornflakes ok for my allergic daughter”? Or, “If I use this medicine, what should I pay attention to”? It is an intriguing idea that could be extrapolated to other areas. For example, when I want to buy a set of recordable DVDs, it could tell me that I need the DVD+R and not the DVD–R version (Anybody needs 50 DVD–R discs?).

There are already demos that link a product code to reviews, but being able to get a personalized advice based on product identification is intriguing with many possible extensions. For example, if Ellen is wrong, and the dad does the shopping for once, he can point at the breakfast cereals and be told that the kids refuse to eat the healthy kind so he better buys the chocolaty version or stand to waste his money.

So what is the OSGi angle to this article? Well, there are several. The OSGi Mobile Service platform is obviously enabling applications like this. The client code will require an interface to the RFID or bar code scanner, an interface to the backend, local logic, and more. The OSGi model allows these connections to be abstracted by services so that the code can be used in many different environments.

However, the link is even better. Several members of the OSGi had the use case of a barcode reader on the fridge for inventory tracking. Not that feasible, but if you could consult a bar code reader in the kitchen for food/medication incompatibilities I think you have a product people might be willing to pay for. So the idea is also applicable for an OSGi home server.
I wrecked my brain to find a related use case for the vehicle to have a truly convergent use case for OSGi service platforms, but alas I could not come up with one: gas is hard to mark with a bar code.

     Peter Kriens
     OSGi Evangelist

Cool OSGi Panel

I have rarely been participating in a promotion of OSGi that went so well as our panel on the CCNC 2006 in Las Vegas. And as some can testify, I have been at many. It was my task to kick off the panel. For the occasion, I had written a new presentation that took a different approach. Instead of listing and explaining the features, I tried to define the problem we are trying to solve. In 1998 our goal was to create a standard for applications that run on home gateways. We were faced with a couple of hard problems: no defined hardware platform or operating system, a bewildering number of network standards and devices, unattended devices, and last but not least the requirement to enable competition in implementations.

By trying to solve the incredibly hard software problem of home automation, we more or less accidentally created a very elegant component software system that solves a much broader class of problems than home automation. From this problem analysis, I sketched the vision of where we want to go: To become the component model of choice for embedded, desktop, and server applications. Of course this is a high level vision that sometimes irritates people because there is definitely much work to do before we are there. However, the wonderful part was that in this case that the vision became so nicely rooted in the real world.

Dave Marples could take the stage and talk about the GST project. This is a European Union sponsored project to standardize the telematics unit in cars. With his usual flair he explained how important OSGi was for this project. Vince Izzo (Business Development, Motorola) then had a very interesting story about the Home Genie project. The Home Genie project was a home automation product marketed by Shell. The project unfortunately failed but the experience made him very enthusiastic about the OSGi Service Platform. He goes on record that the OSGi Framework was rock solid and a pleasure to work with. This was a very strong testimony for the OSGi Service Platform, but even better, it indirectly explained why OSGi is not as big as it should be today. We started out to solve the home automation software problem but when we did, it had become clear that that our target market had collapsed.

Jon Bostrom could go in for the kill with his exciting vision for the mobile phone. Jon has been involved with mobile phones and Java before there were Java phones. He worked with NTT Docomo to start iMode and has been involved with almost all Java related phone technology. He is currently Director Java Platforms at Nokia. His work has always been an uphill battle. It is hard to believe with 800 million Java phones on the market, but many people industry laughed at the idea of putting Java on a phone. I guess these people must feel like the book publishers that turned down J. K. Rowling. Jon has become convinced that the current model of Java on the phone is hindering the further evolution of the market. The current standard, MIDP, is so crippled that you can not do much more than games. In this standard, developers can not create components that are leveraged by other components. In the real world there are a tremendous number of exciting ideas that need a device like a mobile phone. Tapping this market will release an enormous amount of energy that can benefit the operator, the manufacturer, service providers, and obviously the end users. To quote a paraphrase of Jon: “We need to let the developers stand on the shoulders of other developers”. Something you can specifically not do in MIDP. The work we have done in the OSGi to create a mobile platform specifically enables a cooperative application/component model. To show the dedication of Nokia to this model, he told the audience that there will be phones with an OSGi Mobile Platform available in the coming months.

The beautiful thing of the panel was that we had this high level, software oriented, but rather high level vision of a bundle market that was supported by 3 different industries with concrete applications. However, the best thing came when we had the questions. There is always an attendant that looks very skeptical and asks: “Are there any deployments of this”? And it felt so good to be able to answer: “Yes, we had 10 million downloads of Eclipse in the last year”.

   Peter Kriens
   OSGi Evangelist

The OSGi specificati

The OSGi specification process is surprisingly civilized. In most cases we find a solution that everybody can live with. However, during the R4 specification, there was one aspect that caused a lot of discussion. The final solution was what all committees do: we made it optional.

I am talking about Require-Bundle. The Require-Bundle header directly links one bundle to another. If bundle A requires bundle B, then A can only run when B is present. You might be surprised that there was any opposition against this concept at all; this is the way modules have been linked since the dawn of computing. So what is good enough for our predecessors, why would it not be good enough for us?

The opposition was led by the people that had extensive experience with earlier OSGi releases. In the original specifications we only linked by packages. A bundle could require a package, but it could not decide the provider of this package. The packaging of the packages in the bundles is therefore not constrained. However, why is it important to not constrain the packaging? This is best explained by an example that shows where you run into problems by requiring bundles.

Initially you deliver a large subsystem as a single bundle. All your application bundles, out of convenience, require this BIG bundle. Normally, most application bundles only use a fraction of this big bundle. One day you realize that this bundle has grown a bit too big and decide to split it into two smaller bundles. You now effectively orphaned all the application bundles out there because there required bundle no longer exists. It is normally extremely difficult to update existing, deployed, bundles, if at all possible. Basically, when this happens you have something to explain to your boss.

The standard OSGi solution is to link bundles through packages with manifest headers. Packages are the minimum granularity because classes in a package should be highly cohesive. If they are not highly interconnected or dependent, they should not be in the same package. Linking packages significantly simplifies the deployment of bundles. The grouping of packages is no longer important; all links are constructed from the package names and versions. This gives you substitutability; any bundle can now provide key packages. The Framework will

Suddenly you can surprise your boss with all these new options!

So if package linking is so obviously advantageous, why on earth did we add Require-Bundle? The key reason is that Require-Bundle is conceptually more familiar and easier to use. The big disadvantage of package binding is that it requires calculating the list of imported packages, which can be a long list in big legacy applications. The argument that this list can be fully calculated because all information is in the class file was not deemed strong enough.

So, use import and export package and not require bundle. Do not be tempted with the conceptual simplicity because you will pay the price later.

     Peter Kriens
     OSGi Evangelist

Eclipse Corona Project. Distributed OSGi?

As a virginal committer on Eclipse/Equinox I receive all kinds of mail about Eclipse projects. Today an interesting project proposal drew my attention: Corona. Ok, the name is a bad start. The Apache model of names without a cause is becoming a trend. The full project name is almost less intelligible: Tools Services Framework. However, when you look beyond these words, you can see the interesting bits. In this case this is the corona core, which is described as:

Corona Core - A set of OSGi-based plug-ins that implement the Corona framework. These plug-ins define the extension points for shared Repositories, Projects, Tasks and Collaboration spaces. Additionally, we will deliver an implementation of a Link concept and the existing Marker concept. Finally, we will provide a Manageability abstraction within the Core that can be mapped onto a Web Services Distributed Management (WSDM) interface.

Now there is a lot of inevitable jargon in this text. Extension points are an Eclipse concept that is similar to services. Extension points have a type that is defined in XML files; plugins/bundles can indicate they provide certain extension points. They, however, lack the dynamic aspects of services. Extension points used to have the advantage of lazy initialization, that is, no class loader of the provider was created until the provider was used. Originally extension points were a pure Eclipse feature but the Equinox team has ported this to a bundle so all OSGi Service Platforms can use this mechanism. However, declarative services provide a better solution today, extension point are an Eclipse 2.0 legacy.

The Corona core plans a distributed computing environment. We have been discussing distributed versions of the OSGi Framework for beginning. The OSGi service registry is a mouth-watering abstraction for a distributed architecture. The dynamic nature of distributed systems is a perfect match for the service registry. The reflective capabilities of the services make it straightforward to map services from one platform to another platform. This mechanism does not work for all services because the calls of some services are not serializable, however, many specially designed services can work fine.

Overall the Corona project looks like a great opportunity for the OSGi Service Platform to obtain distributed capabilities. However, the project is described as having a very high number of dependencies on large subsystems. The complicated part of this project is to keep the corona core as small and independent as possible.  It will be tempting to bind the core to all kinds of subsystems but this will make the system overly complex and less useful for other applications.

The current success of the OSGi specifications is the fact that we kept things simple and as uncoupled as possible. Now we are maturing and more and more people are building the whole construction is becoming more complex, this is true for all evolution. When I was first using Java in 1995 I told the software veteran Ralph Johnson that I liked Java over Smalltalk because it was so small, he sighed, and told me to wait and see … A wise man.
We took a great deal of effort with the OSGi Service Platform to allow systems to be build from small components. The OSGi service model was designed from ground up to beat the coupling problem that is so pervasive and pestering in larger object oriented systems. The Corona project is going to be a very interesting test case to see if it is possible to develop a set of independent components or just a new blob.

     Peter Kriens
     OSGi Evangelist