Spring and OSGi: Jumping Beans

This week there was an interesting discussion going on in the Spring-OSGi mailing list. In this mailing list, a number of people discuss their fantastic work marrying Spring with OSGi. This project has created a lot of interest; Even JBoss seems to have been inspired by this work and is moving to OSGi, putting the majority of application servers on firm OSGi footing!

Anyway, the discussion was about the dynamics of services. Hal Hildebrand (Oracle) started a discussion about the cardinality of services. This opened a floodgate of mails that I tried to ignore due to after-vacation overload. However, Costin Leau (Interface21) asked me to jump in so I was forced to analyze the thread. I got myself a cup of strong coffee and wrestled through the mail flood.

The issue was revolving around the cardinality. The cardinality indicates how many services of a given type you require and how many of them you are interested in. The OSGi-Spring specification treats OSGi services similar to beans. This allows you to inject beans into other beans, following the concept of inversion of control and dependency injection. For unary services like an OSGi Log Service this works fairly well. However, the devil is usually in the details, so let us take a closer look.

The key differences between beans and OSGi services are:

• Beans are passive, beans are non-existent until someone creates them with Class.newInstance(). The whole idea of Inversion of Control (IoC) is that this creation is done by an outsider and not the POJO itself.


• You rarely require two beans of the same class. Why would you use two different database objects or log objects?

Most Java programmers will recognize this model. Many developers use the Class.forName to find a class and then use Class.newInstance to create an instance for extendibility. Virtually any (non-OSGi) Java application uses this model to extend or configure itself this way. Notice that there is a strong 1:1 relation between the Class and the instance in this model.

In contrast, OSGi services are more like jumping beans; they have a life of their own. When beans start jumping all over the place (spring, as they say in Dutch!) then most programmers will be shocked to the bones. Fortunately, once they grasp the power of a dynamic model they usually fall in love it. However, this model implies that the IoC is not limited to configuration and activation, it means that the IoC container must handle life cycle issues during the active life of the application.

Obviously, many Spring applications will not be able to handle these dynamics, or even want to handle these dynamics. The Spring-OSGi group therefore chose to hide these dynamics behind a proxy. Instead of directly injecting the service object, a proxy to this object is injected into the configured bean. This gives us a choice to control the behavior later when the underlying service arrives or goes away. However, it also gives us a choice of optionality and multiplicity. The proxy mechanism of Spring gives us full control, the tricky thing is to define what to do with this control.

These are exactly the issue we spent a lot of time discussing during the development of declarative services, inspired by Richard Hall’s service binder and designed by BJ Hargrave (IBM). Declarative services do not use proxies but instead bind and unbind services to the application using injection. After lots of deep discussions we came up with the following policies for binding and unbinding services to the application.

Mandatory/Optional
A mandatory service means that the service must be present before the application is activated and the application will be deactivated when there is no such service available anymore. An optional service does not influence the life cycle of the application. The declarative runtime can unbind a service and bind another service at will when the service is optional. Normal Spring beans are similar to mandatory services.

Mandatory is normally indicated in the cardinality as 1.., and optionality as 0.. .

Unary/Multiple
The application can be interested in a single service (unary) or it can track a set of services. The set may require some explanation. The dynamic service registry enables some very interesting software patterns. For example, one bundle manages a Bluetooth hardware interface. The whiteboard pattern shows that the simplest solution for this bundle is to register a service per discovered device, and unregister this service when the device is no longer reachable. Other bundles can then just track these services from the registry and use when required. This pattern nicely decouples the lifecycle of the bundles that participate, making clients easier to develop.

The idea that you can add and remove beans dynamically from a configured bean is new to Spring but it follows naturally from the OSGi model.

This cardinality is indicated with ..1 for unary and ..n for multiple.

Static/Dynamic
Once an application is activated because its dependencies are met, the lifecycle state of a referred service can change. The traditional choice is to deactivate the application and restart it when the conditions are right again; this is called the static policy. Some people are repelled by this idea but in an OSGi system this is quite natural, and well under the control of the operator. An update can cause a ripple effect of many bundles restarting but well designed systems should be robust enough to handle this. Hmm, let me rephrase, if your system can’t handle this model, it will fail in the end anyway.

In certain cases, it would do no harm to replace a service on the fly. If an application uses the Log Service, it is likely not interested which Log Service it uses. If this service is unregistered, it could easily be unbound and then bound again with a new instance. Most stateless services can be replaced this way. Binding and unbinding during the active life of the application is called the dynamic model.

Usage
Let us now take a look at the possible combinations and see what they mean, and where they are applicable.

• static, 1..1 – The simplest case. The service must be present before the application is activated and the application is deactivated when the service disappears. The world looks perfectly simple and static for the application. The typical use case for this policy is the Http Service. Many applications should only be started when the Http Service is present and when it goes away the application has no purpose anymore. A once chosen Http Service can not just be replaced because the application must register the servlet with the Http Service; the Http Service is not stateless with respect to the application.


• static, 0..1 – The common case when the service is not really required to operate the application and the programmer does not want to bother when the service shows up later. The application is therefore unconditionally activated, regardless if the service is present. However, if a service is bound to the application before activation, the application is deactivated when that specific service goes away, even if another becomes available. This cardinality could for example be used for the Configuration Admin service because it is likely to be there or not.


• static, 1..n – This case is not very useful, tracking multiple services require a dynamic policy to make sense.


• static, 0..n – See previous.


• dynamic, 1..1 – The service must be present before the application is activated, however, the service can be unbound and bound again if a replacement can be found. This mode is useful when you have a stateless service but you require its presence to operate. For example, if the application needs to send messages then it can not function without a message service. However, it does not really care which message service is used.


• dynamic, 0..1 – An optional service that can dynamically be replaced. The application is unconditionally activated and never deactivated on behalf of this service. This policy is typically used for a Log Service. Logging is nice, but not generating a fire alarm because you can not log it is bound to make some unhappy customers.


• dynamic, 1..n – At least one service is needed, but many are handled. The application is only activated when at least one service is present and is deactivated when no more services can be found. This can be useful if you perform an expensive function that is only relevant when there is at least one consumer. For example, assume you run a GPS device in a phone so battery power is at premium. If there are no positioning listeners, it is no use to run the GPS chip thereby reducing power.


• dynamic, 0..n – The typical tracking case. The application is unconditionally activated and never deactivated on behalf of this service. Services are bound and unbound as they come and go. For example, if you are tracking a set of Bluetooth devices in the service registry then this is your policy to use.

Spring
The Spring-OSGi spec can copy the concepts from the declarative services because they have exactly the same issues. The discussion in the mail group got confused because the interaction between the policies for proxying (static/dynamic) were confused with optionality.

Spring adds the concept of proxies. It is my advice that the rules are as close as possible to the declarative services model which means that in most cases the application must participate in the binding and unbinding. It is tempting to automatically replace the service reference in a proxy but most of the time services are stateful and then it is easy to confuse them. Associating proxying with dynamic does not make sense because normally the application must do some action during binding. Maybe Spring needs an extra policy to indicate that replacing the service in the proxy is allowed or not, for example statefull and stateless. Then again, I am starting to have serious doubts how useful proxy rebinds are in reality.

Anyway, this year will be an interesting year for declarative services. It is clear from this issue that declarative services did a good job in this area but the possibilities of Spring will likely encompass all the important features of declarative and then add more. I am not sure if it is a good idea to have declarative services compete with Spring. My personal preference is that the Spring-OSGi specification becomes an official OSGi R5 spec … Let me know if you have ideas how we should handle this.

Peter Kriens

OSGi Alliance at the end of 2006

The end of the year is nearing and that is a time to reflect. What did we achieve this year and where will we be heading to? Bear with me.

Evangelism
For me, this year was special because for the first time in my life I spent much of my time in non-technical work. The OSGi Alliance board had appointed me their official evangelist. That was a bit getting used to; suddenly I had to visit conferences, present OSGi technology and just talk about it instead of doing it. The hardest part was learning how to consistently use the word “OSGi” as an adjective for some trademark reason.

This evangelism thing is a bit hectic: EclipseCon in Santa Clara, ApacheCon in San Diego, ApacheCon Europe Dublin, Oredev in Malmö, Javapolis in Antwerp, CCNC in Las Vegas, OOPSLA in Portland, and BCC in Birmingham. Busy, but most of the conferences were very gratifying because I met so many people that are enthusiastic about the OSGi technology. It never ceases to amaze me that there are so many people that can enthusiastically tell me that they had been using OSGi for many, many years; most of the times from companies that I never heard of. But I love those stories and they make my work very rewarding. Next year it looks like there will be a similar schedule so do not hesitate to talk to me when you see me in my “Ask me about OSGi” shirt..

Mobile Specifications
In 2006 we had to finalize the Mobile specifications, which had some political hurdles. The project had run as a joint project between the JCP (JSR 232) and the OSGi Alliance. One of the key aspects has been the device management; a specification that uses the same concepts as the OMA DM protocol. JSR 246 had developed a similar specification for MIDP that was originally based on the work done in the OSGi but unfortunately deviated significantly. Fortunately, the spec leads Jon Bostrom (Nokia) and Jens Petzold (BenQ) realized that two similar but different specifications in the JCP would not be such a good idea. It was therefore great that the companies worked together and aligned the APIs.

There is a always a lot of work in finalizing specifications. Not only must the text be edited, reviewed, and reviewed, and reviewed … it is also necessary to ensure that the reference implementations and test suites are correct and nicely packaged. The mobile specification was truly an international effort, which did not make it easier. We had teams in Brazil, US, Hungary, Finland, and Bulgaria all working together to finalize the required artifacts. Great work and thanks all for the cooperation and patience!

After the mobile specification was finalized, I received one of the first prototypes from Nokia, an E70, that offered an OSGi framework. I remember racing to the local UPS to get it when it had arrived in Montpellier last June. The first versions needed some work but if everything works out I should get a new version today! I hope to write about many demos with this phone in the next year.

Even after working with the mobile specification for a long time, I still believe that the vision of an OSGi platform in a mobile phone opens a huge market of both niche and mass market applications.

Automotive
From the outside there was not much news from the vehicle/automotive front. Part of the reason is that many members have been too actively involved in the EU sponsored Global System for Telematics (GST) project to spent much time inside the OSGi Alliance. However, a number of companies have remained active in the OSGi vehicle expert group and are working on some very interesting projects. One good decision of this group was to align the vehicle management specification with the mobile device management specification, including diagnostics. The Mobile OMA DM based device management architecture was slightly extended in cooperation with the mobile expert group and then included wholesale. Based on this specification, the vehicle group then developed an abstraction of the vehicle data. This abstraction allows applications to use vehicle data without having to concern themselves with actual models and car types. For example, an application can close all the doors on any compliant car or find out if it is raining.

However, the most important and interesting work has been the navigation model, driven by Olivier Pavé and Rob van den Berg (both Siemens VDO). This navigation model is my personal favorite. By providing a standardized API to the on-board navigation system the OSGi specifications will enable a very large number of interesting applications. A standard navigation system allows third parties to combine their unique data with position and guidance information. These applications can leverage a highly complex navigation system for their own goals, enabling applications that today are not feasible.

For example, the Guide Michelin could offer a bundle that helps you select a restaurant, make the reservations, and guide you to the selected restaurant. Or it could even notify you for a restaurant that is worth a detour. They even could push the envelope and suggest a trip to a restaurant that is worth the trip.

I hope that we will be able to finalize the vehicle work next year. I also have good hopes that some of the results of the GST project will be merged with the OSGi vehicle specifications. Next month (Jan 11) we will have a vehicle workshop in Detroit, looking at the guest list I am sure this will be a very interesting meeting that will put the OSGi vehicle group back on track.

Enterprise
The new kid on the block is the OSGi Enterprise Group! The OSGi Alliance is gaining a momentous amount of steam in the enterprise/server world lately. Though the core technology is very useful as is, there are clearly many requirements that could improve the core and extend the set of available standardized services. Service distribution seems to be at the top of the list, but there are many more areas, as became visible in the workshop. The challenge will be to keep the core lean and mean so that its applicability for the other markets does not get lost. However, I have full confidence that we will succeed there; there are too many people involved that distinctly dislike bloat and the success of POJO’s is a clear sign that our industry is becoming acutely aware of the threats of coupling.

BJ Hargrave (IBM) and I arranged a very successful Enterprise Workshop in September in the San Francisco bay area. This workshop has resulted in an active group of members that are willing to run an OSGi EG. The board approved a new Enterprise Expert Group last month, appointing Tim Diekmann (Siemens) and Eric Newcomer (IONA) as co-chairs.

Spring-OSGi
Before 2006, OSGi technology was put on the map for most people by the Eclipse adoption of the OSGi service platform. This year, the visibility increased significantly because Interface 21, the company behind Spring, decided to support OSGi frameworks. That definitely was a good idea looking at the market response. Adrian Colyer (Interface21) took the lead but the work was shared by Hal Hildebrand (Oracle) and Andy Piper (BEA). The most interesting part for in this process was the reaction of the participants of this group to the OSGi technology. Initially the approach was to “support” OSGi frameworks. During the project, you saw the participants get more enthusiastic about the combination. It would surprise me if OSGi did not become a premier deployment platform for Spring. And vice versa. Spring has some very interesting techniques that overlap the Declarative Services from OSGi. I think it is definitely worth the effort to investigate how these two can work together. I hope Interface 21 will become an OSGi member soon so we can explore the possibilities of specifying the Spring-OSGi collaboration in a future specification.

JSR 277 and JSR 294 module systems
The dramatic highlight of this year is obviously JSR 277 and its brethren JSR 294. JSR 277 attempts to define a module system for the future Java 7 that has a significant overlap with the functionality of the OSGi core framework, JSR 294 is doing the same but restricts itself to changes to the VM and language.

I desperately tried to be on the JSR’s expert group but I was repeatedly denied, despite efforts from people like Doug Lea. Despite this rejection, I tried to evaluate the first draft from JSR 277 without too much bias in my blog. This blog was very well read by the industry. In general the reaction was that Sun should align with other standard groups if they have achieved significant results in the market and not try to reinvent the wheel. Last week I ran into Stanley Ho and Alex Buckley (JSR 277 and JSR 294 spec leads from Sun) at Javapolis an Antwerp. We had a good and pleasant discussion and I hope this will bear some fruit. However, these JSRs will be an ongoing saga so I am curious what next year will bring us.

JSR 291 OSGi Service Platform for J2SE
IBM filed JSR 291 with Glyn Normington (IBM) as lead this year. Though the OSGi specifications were already part of the JCP in JSR 232 (Mobile) it was felt that the visibility of a JME specification by the JCP SE/EE Executive Committee was too low for comfort. JSR 291 was setup as an open expert group that would provide requirements to the OSGi Alliance. All design work is done inside the OSGi Alliance by its members. Interestingly, this process was setup because of intellectual property rights but the separating the requirements gathering process from the API design worked really well in JSR 232 and now in JSR 291. Maybe this separation of concerns should be tried more often in the JCP?

Anyway, JSR 291 is moving along and will produce a specification next year. This will come out as OSGi Release 4.1, likely in April.

Apache Felix
Last year I was asked to support an incubation project at Apache: Felix. This project was based on Oscar, the first and popular open source implementation of the OSGi specifications. It was really nice to see how Richard S. Hall rallied a large group of people with enormous energy around this project. They have been working in incubation status during this year and are now ready to graduate to a top level project. I hope, and expect, that this graduation will push many more Apache projects to first enable their artifacts to run on an OSGi platform and later commit themselves to Felix. Many of Apache’s software projects scream for an underlying OSGi platform that can unify the myriad of plugin systems and class loader abuse present in Apache and other open source code.

OSGi Popularity
The best part for me this year was the tremendous increase in outside awareness of the OSGi Alliance. I remember sadly staring at 8770 Google hits for OSGi in 2005, today we have between 1.5 and 2.5 million hits. I do not really know what the number means, and it seems to depend on where you ask it, but the trend is to my liking. Same for Google alerts. In the beginning of this year I received about one Google Alert per week on the OSGi keyword (My week was good when I received two). Today I receive one every day with 5-10 links. Also the statistics of this blog look like we are on the root of the archetypical hockey stick curve. And best, the last few weeks we received a flurry of requests for membership as well as introductions to speak on conferences. If this trend continues, next year will be very busy, but I will love it!

Future
So much more has happened this year but I am already impressed that certain readers got this far. Let us close with a short outlook for next year.

I expect that 2007 will be the year of the Enterprise. Much of the OSGi Alliance’s effort will go into creating a specification for server side/enterprise applications. I think that the key parties in this market will join the work so we can have a lean mean industry wide platform for server side applications.

I als see many signs that the home automation market is making a revival. This market is where we came from and it would do me great pleasure if we could increase our activities in this market. For the mobile market I expect several vendors to provide OSGi capability. This will create a flurry of development work. However, most of this work will be in specialized applications. The popularity of the platform will then likely become visible in 2008/2009. For 2007, mobile will offer interesting opportunities that can pay off handsomely.

OSGi DevCon
At last, I’d like to put in a plug for the OSGi developers conference which is held jointly with EclipseCon 2007 in Santa Clara 5-8 March. The OSGi track will be focused on server side, embedded, desktop, mobile, and other areas where OSGi platforms are used. If you have an interest in this area, please join us and meet all those other people that are involved in creating an eco-system for universal middleware.

Ok, this blog is way too long. Let me finish by wishing all the readers a fantastic 2007 and I hope to meet many of you next year on a workshop, member meeting, a conference, or online.

Peter Kriens

PHP on an OSGi Framework?

Last week (2006/12/08) the OSGi Alliance had a webinar for their members. Last month, Susan Schwarze from marketing had asked me very sweetly to provide a demonstration for this webinar. After some soul searching I had proposed to make a demonstration using the OSGi Framework in a multi language setting. The scenario of the demo was simple: show how to start a framework, get some basic bundles installed, install some applications from the OSGi Bundle Repository (OBR) to show it all works, and then as grande finale, install a PHP interpreter and port a PHP Wiki to an OSGi bundle in real time. And this all must happen in 20 minutes.

The most interesting part of the demo was obviously the PHP part. I always thought that having a PHP interpreter on an OSGi framework would be really cool (However, hard this is to explain to my kids and wife)! With an OSGi based PHP interpreter you can deploy PHP applications as OSGi bundles. This is attractive to companies that today use PHP on remote servers as well as device vendors that want to design their web sites in PHP.

The demo was not the first time I had come up with PHP. I had searched the web for a PHP interpreter written in Java already several times but I had never found one until I discussed this demo with BJ Hargrave. He mentioned that there was an open source project/company doing a Java based PHP interpreter: Quercus. The interpreter is a part in the bigger Resin webserver. With my usual optimism, I though: “How hard can it be to port this interpreter to an OSGi bundle?”

Well, hard.

It started all very hopeful because there was a class Quercus Servlet and the OSGi HttpServer supports servlets very well. Unfortunately, the Quercus Servlet was assuming it ran inside the Resin server, making it impossible to use with another web server. Writing my own servlet was luckily only a few hours. Unfortunately, I could not resist simplifying the Quercus Servlet which added a few unnecessary hours to undo these simplifications when I understood why the complications were there in the first place.

The next problem I ran into was the file system. Normally PHP assumes that all the sources are in the file system and in our case the files had to come from a bundle. Quercus/Resin supported a virtual file system but it took some time to find out how you could provide a new source for files. It turned out you had to write your own Path sub-class and then set the root path to an instance of your type. All other files are then relative to that root. Reading was very easy to program, I just mapped all the read primitives to the resource access in the bundle. However, writing was a lot harder. At first, I decided to allow the bundle that carries the PHP files to specify its URI and a set of writable directories. That is, I architected the following headers:

PHP-Path: /mywiki
PHP-Data config, data, wiki.d

I got this to work but ran into the problem that some PHP programs actually re-write their own source files. Having special writable directories forced me to modify several PHP programs, obviously not a desirable architecture. Then it suddenly hit me (under the shower!) that I could just do the rather standard technique of copy-on-write. So I got rid of the PHP-Data header altogether. A read would now always first look on the file system (actually the bundle’s data directory) and then in the bundle’s resources. A bit tricky was the handling of directories; they should be automatically created when you wrote a file that also resided in the jar. After this (awfully late) insight, it became quite easy and I could use several PHP programs from the net without any modifications. This worked so well that I could show off this model with a real functioning Wiki that was wrapped in a bundle directly from the Internet!

However, I wanted one more splash and I found this splash in the Quercus modules. The Quercus interpreter was designed to be very modular; all its commands were written in separate modules which were loaded at startup. This model was too tantalizing to not use it to show off the dynamic capabilities of the OSGi Framework. Would it not be impressive if you could install a new Quercus Module on the fly as a bundle (Again, an excitement my family rarely shares)? So I decided to create a Service Tracker that listened to Quercus Module services. Those service objects were then added/removed as a module to the Quercus interpreter. I had to write a new remove function inside the interpreter because, like so many programs, it had no concept of modules that could go away.

Quercus Modules could now be written as OSGi bundles. This turned out very simple to do because bnd (a program/plugin that creates bundles from a recipe) supports declarative services as well. I could just create a small bnd file that builds the bundle and indicates what class should be registered under the QuercusModule interface. Like:

Private-Package: com.caucho.quercus.lib.zip
Import-Package: *
Service-Component: com.caucho.quercus.lib.zip.ZipModule;
provide:=com.caucho.quercus.module.QuercusModule

I had decided early on that I did not want to do the demo live. I guess I am becoming chicken at my old age; the chance that something fails is just a bit too high. I therefore used Instant Demo. This application can record everything that happens in a window. You can edit this recording and provide sound as well. Instant Demo then converts the total set of files to a flash file so you can play it in any browser. I must say, using such a program is a humbling experience because every little error requires a restart. It was painful to have to repeat the same actions over and over again just to get it right.

Anyway, after a lot of hard work I finally succeeded in making four short movies about this demo. If you are interested, download this presentation and play it. Let me know if you think we should have more of such demos. Should we also do this for JRuby and run Ruby-On-Rails applications on OSGi Frameworks? Hmm, sounds cool!

Peter Kriens

P.S. The Quercus interpreter is not available because the code is not industrialized. It really worked for a demo (nothing was faked) but it requires more work to harden it for real use. However, I will contact the resin people to see if they like to modularize their webserver. Their web server screams for OSGi technology!

Unfaithful thoughts

Say “OSGi” and Java is not very far behind, they have been married since the early days. When we started working on the specifications Java was our obvious partner, and OSGi’s parents were well acquainted which made the marriage quite convenient. We needed a portable and security sensitive environment and we were very smitten with Java. However, the world has moved on since then and many other interesting partners are popping up all the times. People tell me that the adoption of OSGi technology is often hindered by the overhead that is introduced by a Java Virtual Machine and its sometimes obese library (it was very slim when we started!). We should also not forget the enormous amount of legacy code available in a diverse range of languages that many companies are unable to port. So far we had to deny them the wonderful features that OSGi offers like modularization and (remote) management. Why not let our minds wander off a bit and see what options there are?

A very interesting trend at this moment is the efforts of many to port native environments to the Java VM. Last week at Oredev a Ruby expert told me that JRuby (the Java implementation of the interpreter) had a significant better thread model than Ruby itself. JRuby is getting awfully close to implement the full Ruby language, which could create a drive to make JRuby a preferred environment because it can painlessly integrate any efforts written in Java. A similar story can be told about Jython, a Java based implementation of Python.

Even PHP is possible; I am currently preparing a demonstration for the 7 December OSGi members only webinar. We will show standard PHP applications running on an OSGi framework. The PHP interpreter (Quercus, from the Resin web server) is completely written in Java and it was not hard to turn it into a bundle. I just needed an activator that tracks bundles with PHP pages and registers a servlet under the right namespace. It is really cool to see how you can now write a web site in PHP and deploy it to an OSGi framework as a bundle!

The Java VM misses a few instructions to implement dynamically typed languages efficiently, but there are discussions going on to add these instructions to the VM. VM based solutions remain almost all of the advantages of using Java because they use the same programming and security model. Using the Java VM as the common denominator is therefore a very nice model and I expect to see many examples of this model in the coming years.

The VM model still leaves out native applications, and there are some really cool native applications out there. The standard Java solution is JNI, which, well, ehh, sucks; JNI is extremely intrusive and pedantic. Porting a C application to run under a Java VM is a painful exercise. The alternative is to use some communication mechanism, like for example sockets, and communicate over this medium. Doable, but it is hard because it requires addressing mechanisms, marshalling (serializing) to communicate any parameters, and many more chores: see CORBA if you want to know how painful this can be.

One of the best features of the OSGi Framework is the service registry. The service registry really decouples bundles from each other. A bundle that needs to communicate with another bundle never directly addresses that other bundle but uses a shared service to communicate. A service is defined by the API it implements and a set of properties. Services are detected or found dynamically and then bound. The service registry arbitrates between providers and consumers and provides appropriate security and life cycle control.

The most elegant solution to the legacy and native problem is an implementation of the service registry in C. Most languages besides Java support a very easy integration with C libraries. On the PC and on Linux it is quite easy to directly call DLLs or shared libraries from most dynamic languages. Writing a service registry in C that has the same semantics as the OSGi service registry should not be rocket science. Using a fast communication medium like shared memory would minimize any overhead. Key problems are the garbage collection, leasing issues, and marshalling. You could optimize the registry for tightly coupled clusters, though the technology obviously enables more loosely coupled solutions.

There are of course many interesting questions remaining. Should the management of the bundles remain in Java, or should these aspects be moved to a C library as well, allowing full Java free implementations? Obviously Java will be the best supported environment for a long time to come, however, living apart together might not be a bad solution to satisfy the requirements that I am hearing more and more.

Peter Kriens

Domain Specific Languages

Last week I visited the OOPSLA in Portland to promote the OSGi. During that time I also visited many different sessions. Interestingly, only this week I started to see a trend in the conference, strangely enough not while I was there. Trends on OOPSLA are important; this is the conference where objects, patterns, aspects, and many other innovations were first discussed.

The trend is the focus on domain specific languages. We seem to be entering the time when Java is not the one size that fits all we something think it is. Interestingly, one of the key persons in the Java world (Guy Steele) had a presentation about Fortress, a language that is intended to replace Fortran. The syntax is highly optimized for mathematics. A key aspect is that the language should be readable by the domain experts. This means they have operator overloading because there are many mathematical operators that have formalized definitions. They allow the overloading of many Unicode characters, solving one of the problems with C++ where there were too few operators to work with.

However, there were many other presentations that address the language issue. A company called Intentional Software presented an editor that could display and edit the same abstract syntax tree in many different forms. This ranged from a mathematical expressions with all the nice looking formatting, to Java code, and all the way to the graphically display menu structure of a mobile phone. Again, the interesting aspect is that syntax does matter. But there was more. Another presentation told the story of a company that had 400 pages of requirements and domain knowledge. The estimate was that the system was roughly going to be 20.000 pages: a 50x increase in size. The presenter’s solution was to model the domain in a domain specific language and generate the system from the program written in that language. The expectation was that the system could be written in around 4000 pages of code. During the rest of the OOPSLA there were many more Domain Specific Language (DSL) presentations.

You see the shimmers of Domain Specific Languages in things like Ant and Maven. The XML files that parametrize Ant and Maven define a language. Unfortunately, they picked XML, which caused much of the clarity of a domain specific language to be lost in the sea of tags. Many developers have attempted to design domain specific languages using XML; the art of real language design seems lacking in today’s computer science classes. And it is so easy today with javacc, antlr, and other compiler compilers.

What does this mean for the OSGi service platform? The OSGi Service Platform is currently highly Java oriented, do we need other languages?

First there is already a domain specific language for Eclipse plugins called eScript, written as an example for the Eclipse FAQ book. Unfortunately it does not run as is on Eclipse 3.3, but it is an interesting approach. Instead of mucking around with MANIFEST.MF, plugin.xml, resources and Java code, it is all specified in one concise file. I think this approach is promising. An environment like Eclipse contains so much functionality, it would be very nice if one could tap into that functionality with a short script instead of all the work involved today.

I think the OSGi service platform is a great platform to provide the runtime for Domain Specific Languages. The OSGi provides a wonderful plumbing infrastructure for the generators that map the DSL programs. The nice thing about DSLs is that they only specify domain related issues and leave the plumbing and other chores to the environment. This implies that any overhead that the OSGi service platform requires can easily be created by the generators. This will make it very easy for people to write highly productive and specialized code while not being bothers with plumbing.

Look for DSL and you will find more than just modems. After a long time where very few languages were developed, I expect to see many domain languages to see the light in the coming years. I hope the Java community can embrace this opportunity by allowing these languages to run on the Java VMs and not oppose these innovations. Domain Specific Languages could be a great boon for our productivity, and could make the OSGi Service Platform more attractive to a larger audience.

     Peter Kriens

OSGi Developer Conference

The OSGi has teamed up with EclipseCon 2007, 5-8 March, Santa Clara California to organize the 2007 OSGi developer conference. This will be the premier conference for OSGi developers to attend in 2007.

We are currently looking for submissions! Long talks, short talks, tutorials, demos, and panels. Please submit a proposal to the Eclipse submissions site in the OSGi track. Proposals will be reviewed by the program committee, where we have a seat.

Some of the submission deadlines are near, please submit your proposal as soon as possible. The submissions must be registered at the EclipseCon Submissions site. Do not forget to register at the OSGi track.

I know there are a large number of interesting projects under way that are heavily using OSGi technologies. If you are working on one of those projects, do not hesitate to submit a proposal, we have quite a few slots.

We have a proposal on the table to add an OSGi user groups meeting at the
end of the conference. We will let you know more soon.

Peter Kriens

JSR 277 Review

The JSR 277 Java Module System is an important JSR for the OSGi Alliance and me. Though we have been working on Java modularization since 1998 I did not get a chair on the table; the table was already full with 14 seats. Last week, the current 20 man Expert Group has recently dispatched their Early Draft. So this is a personal account of my reading of the Early Draft.

JSR 277 defines a static module system that is similar to the OSGi Require-Bundle approach. Modules define their metadata in the MODULE-INF/METADATA.module resource. Dependencies are pecified in the import clause with the module’s symbolic name and version range. Other clauses in the module’s metadata list the resources and classes that are visible to other modules. When a JSR 277 application gets started, it should have a main class with a static main method. However, a module must be resolved, as well as its required modules, before the main method is called.

Module definitions can be obtained from repositories. Repositories contain module definitions that provide metadata to guide the resolving process. Name and version ranges are supported from the metadata. However, an import policy class can be used to do more complex resolving strategies. Repositories can be file or URL based, allowing for remote repositories. Repositories are hierarchically linked; if a repository can not find a module definition, it will delegate to its parent. At the top of the chain is a system repository and above that a boot repository. Module definitions are instantiated before they can be used; this associates a class loader with a module. When all the modules are resolved and instantiated, the main class is called and the program can execute. There is no API for unloading a module.

The ambition level of JSR 277 is significantly lower than where the OSGi specifications are today, even way lower than we set out in 1998. In a way, for me the JSR 277 proposal feels rather toyish. The Expert Group took a simplistic module loading model and ignored many of the lessons that we learned over the past 8 years. No built in consistency, no unloading, no package based sharing. Maybe we wasted a lot of time or solved unimportant problems, but I really do not think so. It would be ok if they had found a much cleaner model, well supported by the VM, but it is clearly not. Their model is based on delegated class loaders, just like the OSGi framework minus 8 years of experience. Ok, I am biased, so let us take a closer look. Though just a warning, the following text is utterly boring unless you are handicapped with a deep interested in Java class loaders. Much of the work over the past 8 years was making bundle developers worry about application functionality and let the OSGi framework worry about class loaders. This stuff should be under the covers. Alas.

The key disappointment in JSR 277 is the lack of dynamics. There is no dynamic loading and unloading of modules/bundles, any change will require a reboot of the VM. The model is geared to the traditional application model of starting an application, running, and then killing the VM. Fortunately, JSR 291 Dynamic Component Support addresses dynamics and more comprehensive module loading, so let’s hope that will become the Java standard.

The most surprising feature of JSR 277 is a total lack of consistency checking. Modules are loaded by name and version only; there is no verification that the graph of class loaders form a consistent class space. Take the example in paragraph 8.3.3.3. There are four modules: A, B, C, and D (-> means import).

A -> B v1.0, C v1.0
B -> D v1.1
C -> D v1.0

Modules resolve independently, implying that module B will resolve to module D v1.1 and module C will resolve to module D v1.0. The result is that module A can see the same class coming from module D v1.0 and module D v1.1, likely resulting in class cast exceptions. Or more concrete, assume module A is your application and module B and module C implement some web framework and module D is javax.servlet 2.1 and 2.4. If you use a Servlet, do you get it through module B or C? Errors resulting from this inconsistency can be very hard to trace. There exists a method in the Module class called deepValidate() that uses a brute force method by loading all the classes in all modules to see if class cast pr class not found exceptions occur. Obviously this is very expensive and not even bound to find most consistency problems, just loading problems!

A key problem with the Require-Bundle/Module approach is ordering. Though the EDR implies that classes are searched in a specific order, this still depends on what other modules do. Assume we have:

  A -> B, C, D
  B -> D

The order for module A is not B, C, D but instead B, D, C because module B also imports module <D (assuming classes we re-exported). This is one of the reasons I do not like Require-Bundle, though practically we have much less of a problem than JSR 277 will have. The issue is split packages.

Split packages are packages that come partly from one module and partly from another module. Split packages are nasty because the package security access does not work and it is also easy to unexpectedly shadow classes and resources.

Security problems occur with split packages when you load class com.p.A from module A, and com.p.B from module B. The different class loaders will make it impossible for A to see package private methods in B despite the fact they reside in the same package. This is not a theoretical problem especially if multiple versions of the same module are supported. It is easy to pickup a new class from a new version but then load the auxiliary classes from a module that is listed earlier.

Worst of all, none of this is under the control of the importer. The importer just imports a name and version, and then receives whatever the exporter decides to export. Obviously, this is a brittle connection. For example, module A contains packages a and b. One day module A is refactored and package b is moved to module B. This is not uncommon because big modules are not easy to work with, more about that later. Unfortunately, all clients of module A must now be changed to add module B to their import lists even though nothing has changed except the packaging. Why is this not a problem with OSGi imports? Well, OSGi imports packages, in the previous example package b will just be obtained from module B without any change. It might not seem like a big deal, but for large systems this can amount to major work.

Another problem with modules is their fan out. Typical projects create JARs that are useful in a number of situations. For example, a program like bnd (creates bundle manifest headers from the class files) can be used as an Ant task, an Eclipse plugin, from the command line, and a Maven plugin. It will therefore have to import packages from Ant, Eclipse, and Maven. Those dependencies are needed and are therefore more or less ok (though it is nice to make them optional, a feature missing from JSR 277). However, Ant will import another (large) set of modules. Similarly for maven and Eclipse, ad nauseum. The bnd program is a terrifying example, but the problem is that the usual fan out of a module is large and the fact that dependencies are transitive can worsen this effect. If you want to see the effect of module like imports, check out maven. A simple hello world program can drag in hundreds of modules due to the transitive dependencies. Modules (and Require Bundle) as well are a typical example of creating a constructs to solve a problem but simultaneously creating problems on the next level, problems which are usually ignored in the first version only to bite the early adopters.

A puzzling aspect of 277 is the dependency on super packages from JSR 294. Super packages are shrouded in a veil of mystery. The only public information so far came from Gilad Bracha’s blog. JSR 277 unveils a bit more but many questions are left unanswered. Super packages list all their member classes and a class can only be member of a single module. In 277, it is implied that this module file maps closely to the module metadata. If this is true, than this is a huge constraint. It means that the deployment format is rigidly bound to the development time modules. Each development module must be deployed separately.

I’ve found that managing the packaging is a powerful tool for the deployer. I have written many bundles that mix and match packages from different projects. This flexibility is needed because there are two counter acting forces. On one side you want to simplify deployment by deploying the minimum number of bundles. Anybody that had to chase dependencies knows how annoying the need for more and more bundles. On the other hand, bigger bundles are likely to create more dependencies because they contain more (sometimes unnecessary) code. So you like to minimize the number of external dependencies. Sometimes the best solution is to include the code of other JARs in a deployment JAR. The proposed super packages will put a stop to that model: it will be impossible to manage the deployment packaging because the programmer has decided the packaging a priori; bad idea.

The biggest regret the EG members will have within 2 years is the import policy. Why? Isn’t it a nice idea that the programmer can participate in the resolving? Well, in Java the solution to those problems looks deceptively simple: use a class to abstract the required functionality. An import policy is a class in your module that gets called during the resolving of the module. It can inspect the module metadata, query the repositories and bind other modules.

In the OSGi Alliance, we inherited a similar idea from Java Embedded Server (JES), the archetypical OSGi framework developed by SUN. After countless hours talking and testing we decided that it was a bad idea because of 2 key reasons:

1. By definition, you do not have a valid Java environment before you resolved all the required modules. Code executed in a module that is not resolved is in limbo and is bound to run into problems. There are also several security related issues.


2. Having a procedural solution will prevent management systems from predicting what module will resolve to what module. Within the OSGi specifications, we spent countless hours to make the systems predictable for this reason. This is necessary because in the future more and more systems will be managed (I can’t wait for that day!). Inserting a user class in to the resolution process leaves the management system in the blind. Interestingly, Java made the same mistake with security permissions. Abstracting the permissions as a class is good OO practice, but it kills any possible optimization. A declarative approach could have significantly reduced the 20%-30% overhead of Java security while the flexibility that the model offers is rarely used.

Wasn’t there anything I liked? Well, I like the idea of the repositories. The OSGi framework maintains the repository internally with its installed bundles, it left external repositories outside the specification by standardizing the installation API. Repositories allow the framework to download or find modules just before activation. This is an interesting model, pursued by Maven and the OSGi Alliance with OBR.

However, I think the JSR 277 repository model is too simplistic. It codifies the current maven repository model, which is still immature and will likely change over time. For example, the current model takes only two extra constraints into account: OS, and platform. Unfortunately, life is seriously more complicated. OS’s have their own versioning scheme, processors have compatibility matrices (i.e. an x86 runs on a i586, win32 is compatible with WinXP but not vice versa), the OS is often a variation of OS and window system. Encoding these constraints in the file name is obviously bound to collide with reality one day. In contrast, the OSGi OBR uses a generic requirement-capability model derived from JSR 124 that is much better suited for finding the right module.

Well, the paper document I have reviewed is heavily covered with my marker and I could continue for more pages. However, it is too much for this blog. Well, ok, last complaint: the syntax for version ranges, it is too tempting to leave it alone (though it is not that important). The industry more or less has standardized on versions with a major, micro, minor number and a string qualifier. JSR 277 adds an update number that is between minor and qualifier (Maybe one day someone can explain to me why we need all those number while the only thing that is signaled is a change that is backward compatible or not, but developers seem to like to have all those numbers). However, I have no problem adding another number beneath minor. I do have a problem with a version range syntax that is obtuse and non-standard.

Intervals have a mathematical notation that is easy to understand. Parentheses are non-inclusive and brackets are inclusive. The interval 1 < x <= 5 is therefore represented as (1,5]. [2.3,5.1) indicates any version that is more or equal to 2.0 and less than 5.1. Simple, elegant, has been around since Pythagoras. Choosing this notation for the OSGi specifications was a no-brainer.

Now, let us take a look at what JSR 277 brewed. They use the same terminals as regular expressions, but they have a very different meaning. A partial version can be suffixed with a + (anything later) or a * (anything with the same prefix). So if you say 1+ you mean [1,∞) or 1. 1* is [1,2). The JSR uses square brackets to fix the first positions while floating the last. For example, 1.[2.3+] is [1.2.3, ∞) and 1.[2.3*] is [1.2.3,1.2.4). The JSR 277 syntax has no easy formulation for the not uncommon case [1,5). The only way to express this is with concatenation of version ranges: 1*;2*;3*;4*. Ok, enough about this strange syntax.

Conclusion. JSR 277 takes a simplistic view of the world, ignoring many real life problems: consistency, optionality, split packages, etc. The only way this EG can pass its final review is lack of attention for detail of the Executive Committee or alternatively, serious muscle power of SUN. JSR 277 is a missed opportunity for Java. I do not doubt that this specification will end up in Java 7, but it will further fragment the Java world for no technical reason. Not only is this specification impossible to implement on J2ME any time soon, it will also leave the many OSGi adopters out in the cold. Why?

Peter Kriens