IBM, together with the Apache Software Foundation, BEA Systems, Inc., Intel Corporation, Nokia, Nortel Networks, Richard Hall, SAS Institute, Inc., and undersigned have submitted a new JSR: JSR 291: Dynamic Component Support for JavaTM SE. This JSR will bring the OSGi dynamic component model into Java SE. At last, I have been advocating such a JSR inside the OSGi for more years than I care to remember. The OSGi Service Platform is a Java specification; not having a JSR for this crucial specification is seriously hindering its adoption

A little known fact is that the OSGi Service Platform did start out as one of the first JSRs: JSR 8: Open Services Gateway Specification. In 1999, when the JCP first got started, we were asked by SUN to run the process according to the JCP 1.0. This caused a lot of discussions because of the intellectual property rules. Some members of the Connected Alliance (the predecessor to the OSGi Alliance) felt that the JCP gave SUN unfair power over the specifications that were to be developed by the whole group. After lots of deliberations it was therefore decided to develop the specifications inside a new organization that would have equal and fair intellectual property rules: the OSGi Alliance was born. Unfortunately, this meant we had to exit the JCP, though SUN remained as a member and provided some significant contributions.

Since then, many things have changed. The JCP is now a crucial force for Java. In this cacophonic world, JCP has become for many developers a minimum requirement relevancy. The OSGi Alliance has also changed course, in the beginning we were about residential gateways. Today, we can provide a comprehensive component model that significantly reduces the complexity of application development and can therefore take applications to new levels of functionality. What also changed was the success of JSR 232. This JSR showed us that the JCP and the OSGi Alliance can successfully work together.

Back to JSR 291. Why is this JSR so relevant for Java SE? The simple answer is size. Applications get more and more bloated because of today they include so many features. Features, that are often never used by the users. A component model reduces coupling and therefore allows applications to be delivered in separate parts instead of a big blob. An interesting example is Java itself. The current evolutionary model of Java of adding more and more packages is becoming cumbersome, even for todays roomy desktops. One of the reasons for a monolithic approach has always been the portability of applications: Write Once, Run Everywhere. This model is breaking apart due to the breadth and depth of Java. Providing Swing on a headless device is a waste of precious resources. A component model could solve this problem because missing functions can be downloaded and installed on demand. Such a component model will make it easier to include a much wider range of Java standards; only standards that are actually needed are downloaded. Currently, what to include or not to include in a language release is a very serious question because of this size constraint. Just like it is for large applications.

In the past 7 years, we have shown that the OSGi specifications have tremendous value for developers, as is demonstrated by the widespread adoption from embedded, desktop, to server applications. However, wider adoption is hindered by the fact that these specifications are not part of the JCP. I think that JSR 291 will bring the OSGi specifications under the attention of a broader range of Java developers. However, best of all, the OSGi Service specifications can provide a component model to Java that it so urgently needs, making Java even more competitive with proprietary solutions than it is today. I am really looking forward to work in this JSR. This JSR will be run with an open mailing list, so please tune in.

Peter Kriens
OSGi Evangelist

The biggest chunk of functionality for the OSGi Mobile Service Platform is the Device Management Tree (DMT) Admin. The Dmt Admin API is a matchmaker between management applications (both remote management servers as well as local applications) and the components that are available on a device. The Dmt Admin maintains a conceptual tree structure of interior and leaf nodes. Interior nodes have children, and leaf nodes have a primitive value like an integer, float, string, time, date etc. Plug-ins map this conceptual tree to actual hardware registers or other value sources. The conceptual tree is closely modeled after the OMA Device Management specification.

In the past two days I have written my first plug-in for the Mobile Expert Group. This group is considering using the Dmt Admin for their R4 specification but they want to make the API simpler for Java applications. I had to write a prototype to make a change request.

Initially the task to write a plug-in looks daunting. The interface that must be implemented has 22 methods, and they look quite, well, not simple. Fortunately, as I found out, most methods do not require an implementation to make the plug-in work. Actually, I was quite surprised how easy it was to implement a simple leaf node. You only have to write a Plugin service that is registered with the Framework when you start up. This plug-in service is asked for a session object that you must implement. This session is used to access the plug-in.

My first attempt was to create a plug-in that maintained the position. The OSGi R4 specification has a Position object that lends itself very well to this concept. A Position object contains six fields: longitude, latitude, altitude, track, and speed. Each of the values is a Measurement object that contains three fields: value, error, and Unit. Overall, a Position is mapped to a sub-tree of eighteen nodes. Not big, but also not trivial.

A key problem of writing a plug-in is to map the URIs (which are String[] objects for the plug-in) to your function. My first attempt was hard-coding this relation, but that became very cumbersome amazingly quickly. I must admit that I am allergic to any redundancy in code, but even less sensitive people should have been affronted. I developed this allergy 10 years ago when working on an application with thousands of fields that were hardcode in hundreds of places.

So for my first attempt used some tables to minimize the redundancy, but the results were still not very satisfactory. Intricate knowledge of the tree was necessary in too many different places.

Looking at the code I remembered having a class that makes any Java object look like a Map, very similar in vein to Java beans. Could I use this? The properties of a bean also form a tree. Properties that result in primitive types like String, byte[] can be mapped to leaf nodes and the remaining properties are treated as interior nodes. This turned out to be a very interesting architecture. I threw away all the code I had written and the plug-in became almost completely generic. Virtually all the code needed for my plug-in was now provided by the Position and Measurement classes. That is the way I like it! Even better, the only change I had to make to my bean inspector was to be able to reason about the tree, even in the absence of instances. The original class only worked with instances.

What the prototype showed me was that, with a little bit of help, it is almost trivial to write a Dmt Admin plug-in. As proof, hereby a class that implements a (non-transactional) plug-in for locales. The remaining code is completely agnostic of the problem domain area.

public class TinyPlugin extends TestPlugin {
  TinyPlugin(BundleContext context) { super("./Tiny", context);}

  public Locale[] getLocales() { return Locale.getAvailableLocales(); }

  public String getDefaultLocale() {
return Locale.getDefault().toString();
  }
     
  public void setDefaultLocale(String locale) {
    String parts[] = locale.split("_");
    Locale l = new Locale(parts[0],
parts.length > 1 ? parts[1] : "",
     parts.length > 2 ? parts[2] : "");
     Locale.setDefault(l);
  }
}

Tree:
     ./Tiny
          Locales
          defaultLocale

This class (together with a library of generic code) implements a full Dmt Admin plug-in. It will be hard to make a similar plug-in with less code. And as you probably have found out in this article, I am a staunch believer in small is beautiful (and robust).

     Peter Kriens
     OSGi Evangelist

When adding a new portable to my home network I again realized how wide the gap is between technically unchallenged people and the rest of the world. As a technical person, I sometimes have this snug feeling of superiority because I can get things to work that the rest of the world can only look at in bewilderment. I gladly accept the compliments of our partner when we fixed the PC or connected the new stereo, as if I deserve it. When I look around, I see that many colleagues are similar.

However, sometimes I wonder if our skills are not blinding us from the complexity we put on the rest of the world. And this is not because we are so clever and our users are not, it is actually often the other way around. Users are often too clever to learn unnecessary details and complexities, they just refuse to bring up the patience.

Why is it that the whole consumer industry has been incapable of creating a viable alternative to the iPod, over a period of three years? Why do I still notice, at the worst possible moments, that my address book in my phone is not synchronized? Why does connecting a new PC to the network in a secure way feels like rocket science?

I think a reason is that technical people are not bothered with complexity, we usually do not even notice it, and often thrive on it. A friend of mine is getting started with Java and I am helping him out. Teaching him Java confronts me with the complexity that I no longer notice. It is frightening to see how complicated Java has become over the past 10 years.

I think this complexity in software development is inevitable. However, by being used to a highly abstract and complex world we sometimes do not realize how simplistic the services are that people really like and pay for. For example, a service like “Push to Talk” looks like nothing special but made a huge difference for customers and the Nextel’s bottom line. Another example is how Ericsson has made billions selling business phone systems where the primary function was to provide 3 digit short numbers instead of the normal numbers.

However, we do not have to take the full blame, in most companies the feature set of products is defined by marketing. They are in charge of the product definitions. Marketing people always love simplicity because it makes the feature list longer! However, too many features do not only make a product harder to use, they also make the product harder to develop.

This also points some of the blame to the end users themselves. Cost is the single most important aspect that people use to compare products. I can understand this, because most products are so complex that a reasonable comparison is only possible after a detailed study. And who has time for that? Except when a product is really easy to use, the market recognizes this and rewards the manufacturer with a high profit margin, see the iPod as a prime example.

So how can we build simpler products? Not every company has a Steve Jobs that uniquely combines a deep understanding (and control) of management, marketing, technology, and most important, the requirement for simplicity.

Therefore, management has to become aware that quality costs but that this cost can also result in higher profits. Marketing must realize a short feature list where all features work as advertises is better than a long feature list with a lot of cruft. We technicians can help by never underestimating the patience of our end-users to figure out our products.

Peter Kriens
OSGi Evangelist

I can hardly believe that it is already nine years ago that Ericsson Research hired me to do a project called Perspective to write a 3D user interface (VRML) to personal information store. At that time I was living on the Swedish west coast and flew once a week to Stockholm. After a few weeks the manager Anders Danne asked me to join the department for a planning meeting in the beautiful Baltic skärgarden (archipelago) and give a presentation. Surprised I asked about what subject, “anything”, he answered. “Great”, I replied, “Do I get time to prepare it?”. “No problem, take whatever time you need”, he answered, right the answer I was hoping for. So I spent a week thinking very deeply and came up with a project to create a personal assistant that read your mails, saw where you browsed, knew where you used your phone, was aware of the programs you looked at, and tracked your location. The assistant did not only track all this information, it tried to infer relations, and provide timely advice to its patron. The key driver for me was that in the long run search is just not enough; we need our assistant to tell us things at appropriate times, not just to respond to our queries.

Though I was a trifle disappointed with the lackluster response to my presentation to, I was pleasantly surprised when Anders asked me to run a follow-up project based on the ideas in the presentation. So in January ’98 I sat down to try to code “Marvin”, the name of the alter-ego that should provide all these goodies. (Yes, you are right, that is where the name came from).

Why do I tell you this nostalgic story? This weekend I started going through a pile of CACM magazines and one of them focused on Personal Information Managers. More than eight years later I now see in print many of the ideas that I had, but with so few solutions yet. In my original presentation I sketched a scenario in 2003, assuming I was pessimistic. It is kind of discouraging to see that in even in 2006 most of these concepts are seen as pure research and futuristic.

The biggest disappointment was, however, to see that the ambitions of the projects were pretty low. The all tried to find concrete solutions using XML, folders, databases, RDF, and other stuff. I always intended to use Artificial Intelligence techniques for my project because I think that we need solutions where the computer has some understanding of our daily problems, that it has at least some common sense. Without this, as users, we will spent just too much time categorizing and cataloguing our heaps of information. None of the projects in the CACM even mentioned Artificial Intelligence. This holy grail of computing seems to have completely disappeared from the researchers radar screens.

So why did I leave this exciting and interesting field of research? The reason was that I based my working ideas on small units of Java code that categorized and catalogued information in a specially developed database, called an InfoBase. Due to the diversity of the real world, I had made this a pluggable system so that it was easy to add new plugins written in Java.

Based on this work, I was asked one day to present my ideas at Ericsson in Linkoping, a little village in the middle of nowhere, eh, Sweden. When I arrived after driving 4 hours through the snow, it turned out there was a confusion; they expected me to port the Java Embedded Server to their e-box in one day, and oh yes, they also needed a cool demo. The purpose of the demo was to show to IBM, Oracle, Nortel, Deutsche Telekom and many other companies the concept of a residential gateway. I made the grave mistake of succeeding that grueling day (notice that even Java did not run on the e-box yet). Thereafter I was sucked in the vortex of what became in the end the OSGi Alliance.

Eight years later I can look back at some very interesting years developing the OSGi technology, and I feel I worked on the future. Despite this satisfaction, there is a tinge of regret I did not pursue this incredibly interesting area of personal information management. Well maybe one day a big research company sees that OSGi technology is incredibly useful in this application area.

    Peter Kriens
    OSGi Evangelist