Nested Frameworks

I do not think we had application servers in mind when we had our first OSGi discussions in 1998. On the contrary, the OSGi service platform was the application; the idea of running multiple applications inside the same OSGi Service Platform did not cross our minds. Would somebody have explained the concept at that time, it would probably have been considered an anathema to us. Bundles were not meant to be applications, they were meant to be the constituents; the application was what appeared when you ran different bundles together in a service platform.

History played an interesting trick with this model. The class loading model of OSGi was more or less an afterthought, necessary to support the service oriented programming model. This detail caught the eye of many developers struggling with the class loaders in Java. However, instead of seeing a collaborative programming model, most saw class loaders on steroids. With release 4 we provided the zenith of all class loaders: allowing multiple versions to reside in the same framework. This was by many seen as the grail that solved the pesky problem of using multiple libraries that had conflicting version requirements. Though OSGi indeed could solve this problem better than anyone else it is illustrative that multiple versions was completely unnecessary for the original OSGi service oriented programming model. Actually, Richard Hall and BJ Hargrave had to explain the paradoxically sounding idea of exporting implementation classes many times to me.

With release 4, OSGi became salon fähig for the Application Server space. JONAS was the first but over time BEA WebLogic, IBM Websphere, JBoss followed. Even SAP and Oracle promised to follow this lead. The advantages of OSGi on this level are crystal clear but having the OSGi framework so close to the applications creates the temptation to allow applications to also use OSGi. Many applications are bursting out of their WAR format seams. The modularization provided by OSGi seems very attractive to remove the duplication that is embedded in the WAR architecture. It was Spring Source that made this module first available for enterprise developers with their Spring Source server. This lead is now followed by Oracle, IBM, and JBoss in a diverse set of open source projects.

The first automobiles in 1889 looked very much like the technology they replaced: horse carts. Over time the unique capabilities and requirements of an internal combustion engine resulted in the designs we see today. Is there an analogy with Application Servers and OSGi? Is OSGi just like an Application Server's programming model or should it be treated differently?

Though the OSGi indeed has class loaders on steroids, these class loaders can only alleviate the dependency problems caused by today's application models. I do not believe that the Application Server model where a number of WAR files are running in the same VM should be followed by an OSGi model where these WAR files are running in an OSGi framework only sharing their dependencies. Though it is good to manage a dependency (as OSGi does), it is best to not have a dependency in the first place. It is good to handle multiple versions of the same library but the problems caused by multiple versions quickly cascades to umanageable proportions.

I therefore believe that the original model promoted by OSGi, where the application emerges from the installed bundles, is still by far the best model we have. In this model bundles adapt to each other and collaborate with each other through services; exporting implementation classes is an anathema in this model. Any services in the service registry are available to all bundles because the framework is the application.

This model raises the question how to handle multiple independent applications. Do they all require their own framework? The answer is an unequivocal yes! The cost of this model with the current OSGi frameworks could be quite high. Fortunately, the OSGi CPEG is currently working on nested frameworks. Nested frameworks allow the creation of a composite bundle. This is a bundle that acts as a wormhole to another framework. Nested frameworks will have low overhead and can easily share services and packages among each other.

Nested frameworks will likely appear in a future OSGi specification. It will definitely take time to work out all the special cases but it looks very promising so far. Thomas Watson from IBM has been experimenting and the latest versions of Equinox already provide some of the behavior in experimental form. For me, this is the most exciting RFC in progress. The nested model will enable an application programming model very close to the original OSGi service oriented programming model we envisioned a decade ago. However, with this simple recursive rule of nested frameworks we do not limit it to small embedded devices but enable the same model for (very) large enterprise applications running in large application servers as well.

Peter Kriens

Enterprise Specifications

I am currently in Southampton where we are finalizing the specifications for the 4.2 Enterprise release in an EEG meeting. It looks like we will be able to actually release this work during EclipseCon in Santa Clara, March 22-26. It is a sizable body of work, again. The last 8 weeks have been spent editing, editing, editing, and editing for 10-12 hours a day. Yesterday we did an (almost) final review so a few more days and then I am going to take some time off, trying to get my shoulder muscles back in a state where they can move again.

So what is likely going to be in that specification? Though I cannot give any hard guarantees, the following paragraphs give an overview of the intended content.

We had a few errata in Blueprint and some other specs, but all very minor. So most new specifications for the Enterprise release are about Java EE APIs and make them usable in OSGi. These specifications work very hard to preserve the semantics of the Java EE APIs but map them to OSGi services and defines life cycle issues. At the same time, we're trying very hard to be as compatible as possible with existing JEE code.

The hardest problem being that Java has nothing like a service registry; unfortunately most Java EE specs use the factory pattern with class loading tricks in slightly different ways. Working on the OSGi specifications has taught me a lot of things I never wanted to know about these Java EE specs.

The most "Java EEish" spec in this aspect is I guess JNDI. JNDI is a registry that has become part of Java SE. It is a surprisingly complex design for a rather simple problem (registry). This was the first design ever where I ran into a factory of factories, and JNDI even has two: InitialContextFactoryBuilder and ObjectFactoryBuilder. JNDI had to be supported because a lot of Java EE code is using JNDI to link to other subsystems and get configuration information. Key problem was that people tend to use new InitialContext(). The constructor of the InitialContext class then has to work surprisingly hard to find some Context implementation that was intended by the caller or the container.

The Initial Context design is a variation of a static factory pattern, something that does not work well with OSGi because of the dynamic life cycle. Static factories ignore dependencies, putting a huge burden on the deployer to get the ordering right. We did map the different factories to OSGi services and allow the usage of the new InitialContext(). If JNDI is really needed then depending on the JNDI Context Manager service will keep deployments simple because dependencies are managed.

For JDBC we created a Data Source Factory service that can be registered by database drivers. This service can then provide a surprisingly large number of Data Source variations: Data Source, Pooled Connection, XA Data Source, etc.

The OSGi JPA specification leverages this Data Source Factory service. JPA has become a very popular specification very quickly. The core access point for this specification the Entity Manager Factory

Transactions have been added by registering the Java Transaction Architecture (JTA) interfaces as services and allowing them to be used by applications and containers. The enlistment strategy of the resources is up to the container or by the applications themselves.

The WAR specification introduces WABs: Web Application Bundles. These bundles have the same purpose as WARs: serving web content. Part of the specification is a URL Handler that can install a WAR; the URL Handler will convert a WAR to a WAB by adding the appropriate manifest headers for OSGi. This will likely be a very popular way to get started with OSGi for developers that have a lot of experience with WARs.

This release will also support JMX (Java Management Extension). We've defined a number of MBeans that allow management of the OSGi framework and a number of the key services.

Last but definitely not least. My favorite specification is Remote Service Admin. In the previous release we specified a number of properties that enable the distribution of OSGi services. Services are very well suited to distribution; not because they were designed for distribution, but because dynamics are an intrinsic part of their design. The Remote Service Admin specification uses the distribution properties and allows a topology manager (another bundle) to manage a distributed topology of services. Topology managers can be simple like managing a number of key services in a cluster or implement fail-over or load balancing. Included in the specification is an abstraction to discover services from many different sources. This specification is leveraging OSGi to the hilt and by doing so it enables applications to be largely unaware of their distribution. This specification might be the "killer spec" for OSGi.

A key concept in OSGi remote services is configuration types. A configuration type specifies how to configure the remoting of a service to create a communications endpoint. For example, you could have a configuration type for web services. In the coming release, you will likely find an SCA configuration type. SCA being the Service Component Architecture, a specification at OASIS. SCA is a comprehensive specification to create distributed applications in many different technology. The SCA configuration type allows OSGi frameworks to play a role in SCA.

So lots of new stuff! I really hope to see a lot of people at EclipseCon when this specification will be introduced.

Peter Kriens

Versions

Looking at the raging debate at versions again I can't help but feeling that there are many people out there that do not understand what OSGi versions are, or what versions are intended to achieve in general. It is not the syntax that are important, it is about the standardization of the semantics.

Versions are a language designed to let two parties communicate over the barrier of time. It is like a Domain Specific Language between artifacts that evolve over time. By having fixed version syntax and semantics, an importer can express how it feels about future changes in the exporter. These semantics tell the exporter what version to use when it evolves. The version indicates to tools how different importers and exporters an be combined in a system.

The simplest solution to versioning is to use a fixed identity. A imports B version 1. If B changes, it becomes version 2 and A must be recompiled, but this changes A so it must also increment its version, ad nauseum. Such systems only work when all the software is in a single build integrated with the deployment. Every deploy is then based upon a full new build, you're basically always at the latest version. However, when you use third party packages or you sell your software then latest version systems tends to be unworkable because minute changes ripple through the whole system.

We need some oil to ease the friction, meet version ranges. A version range allows A to import B from version 1 to version 2, non inclusive. This way we can allow B to increase it is version from 1.1, 1.2, 1.3, etc. without requiring A to be recompiled, stopping any rippling effects dead in their tracks. By specifying an import range of [1,2) A relies on B to properly version future releases. If a change is backward compatible, B can increase the minor part of the version (second number) but does not have to increase the major number (the first number). If a change is made that would break existing code, then B increases the major number and resets the minor number. Such a breaking change would get version 2.0.

We skimped a bit on backward compatibility, this is not a well defined concept and partly in the eye of the beholder. A new method on an interface is backward compatible for code using that interface but breaks an implementer of that interface. How is this difference handled? Well, we can put the semantics on the minor part of the version. Implementers use a range for a single minor version and not a single major version number. So if A implemented interfaces from B it would not use [1,2) but [1.0,1.1), if it only used the interfaces in B it would use [1,2).

Backward compatible does not mean forward compatible, if A was compiled against 1.4 then all bets are off if it was bound to version 1.4. It is therefore important that A requires the base version it was compiled against as a minimum. That is, [1.4,2).

However, we make many changes that we want to deploy but we do not want this reflected in the dependency. If we force all dependencies to be the latest version we end up with the same situation we had when we had a single number; any change in version ripples through the whole system again. That is why the OSGi version has a micro number, the last part. It indicates that you made a change but this change does not affect any clients. It is a small bug fix or minute functional enhancement. Obviously deployments should have the latest fixes installed but it is not enforced to keep things manageable in the field. So even though A might be recompiled against 1.4.2, it would put out a version range that did not include the micro part: [1.4,2).

Last, and in this case also least, there is often a need to know which of two artifacts is the newest, or has a certain state. This is left to the qualifier.

From the previous description it is clear that a simple version syntax can have surprisingly rich semantics. Having these semantics specified and agreed upon allows tools to automate parts of the process of maintaining the versions of the artifacts. This is a good thing because users are quite horrible in maintaining versions. For example, the bnd tool can automatically set the import range depending on the export range, takes implements versus uses into account, and I am working on automatically calculating export version changes based on a previous release. Also Eclipse PDE has extensive versioning support, and I expect bundlor also to do clever things. And last, but not least, it looks like Sonatype will also standardize on OSGi version. Without having fixed syntax and semantics, all these tools would have to use proprietary mechanisms.

So yes, it can be fun to use π for version 3.14 but it kills any hope of tools that understand the semantics and take the error prone chore of maintaining versions out of our hands.

Peter Kriens

Nice in Nice

Last week I replaced Susan Schwarze (ProSyst) as a panel member at Net at Home. Due to all the Enterprise related work in the OSGi Alliance, there has been very little time to follow to what are undeniably the roots of the OSGi.

When the OSGi Alliance got started, now more than 10 years ago, it had 100% focus on the residential gateway. In those days I visited lots of conferences, trying to sell OSGi to people making computers with 8Mb flash and 16Mb RAM. In those days, anybody presenting something with OSGi in it was reason for wild excitement. The situation has changed dramatically, though the primary success came from a very different industry.

So I drove the 300 kms to Nice without a lot of expectations. Due to traffic, I arrived a bit late but when I entered the room I noticed OSGi on the first slide I saw. And then the second slide, and the second presentation, and the third presentation. Almost all projects that were presented at the conference were based on OSGi! And the most interesting aspect was that nobody was making it sound as a big deal, OSGi seems entrenched in this industry. During my 4-5 years absence, the processors used in the embedded systems have grown large enough to support Java and thus OSGi. Adopting OSGi for a residential projects has become a no-brainer, there are just too many projects to mention here.

It seems that also in this market OSGi has passed a threshold. However, I did notice that very few projects had members that also participated in the OSGi. Many projects have similarities and it seems inevitable that similar bundles are invented over and over again. The reuse that is so successful in enterprise is not that prevalent in the embedded world. I guess the main reason is that the diversity of problems is less for enterprise than for embedded. It is amazing how complex the world becomes when you cannot remain in cyberspace. However, a model like OSGi can make sharing a lot simpler.

Is it therefore not time for the people that do projects in the residential area to collaborate more inside the OSGi Alliance? There seem to be lots of opportunities. Maybe it is time to organize a workshop about how OSGi could play a role in bringing these diverse projects together on the OSGi technology?

Peter Kriens

Complete

Every time when a new industry joins OSGi there is a lot of new people entering the specification work. These people, inevitably, bring their their own culture. Mixing cultures is not always without its problems. Having lived and worked in Holland, Sweden, and France I learned the hard way that moving to another culture can be a tricky thing; it does take some time before you realize that your absolute truth is not really shared by your new countrymen.

So the Enterprise experts bring their prevailing culture. With respect to standards, this culture is heavily influenced by JCP, specifically JEE, and the way things work in the open source world. This is not always aligned with the way OSGi has been run so far. Previous OSGi specs have always been rather rather thoroughly reviewed and picked apart. A running joke in the Alliance is that we start with a telegraph pole but we we end up with a tooth pick. But what a tooth pick!

One of the key things I always liked about the final OSGi specs is that they are complete. Virtually all service specifications and framework specification thoroughly specify edge cases, are fully introspective and provide relevant events to track what is happening inside the service. In JEE vendors have much more freedom. For example, in JEE the deployment aspects are left as an implementation detail. This completeness of OSGi specs is demonstrated by the fact that (so far) all our specs were able to run from a single test framework while only requiring vendors to have their to be tested bundles installed. It is possible to define do the test setup in the test case because the specifications are sufficiently complete. For example, we can deploy a bundle in a framework without having to know the vendor of that framework.

However, some of the EEG members complain we're too specific and do not allow enough space for implementations to do it their way. By giving more leeway to implementations, you allow more innovation and vendors can more easily fit existing products under a specification. These are not invalid arguments.

So I am struggling a bit with this issue. One of my primary roles in the OSGi Alliance is to guard the consistency between the specifications. This causes me sometimes to feel that I am fighting the whole group to guard this consistency. Despite the fact that I am really trying to run the fine line between being conservative and enabling new groups to do it their way. However, the hardest part is that I continuously have to challenge my own beliefs to try to see their point of view. Well, that is what mixing cultures does to you ...

Peter Kriens

OSGi on the Road

A few weeks ago I got a very nice thank you letter from Eric Gaignet, an employee of a regional bus company in the South-West of France called RDTL Voyages. A few years ago he asked me a few questions over email and I had replied him with some architectural advice of how to use OSGi in a vehicle. I remember that at the time I thought this was a wonderful application for OSGi. He reported now that this project had gone very smoothly.

RDTL is a small regional bus carrier (150 buses) with low overhead. A few years ago they realized that new regulations, the impact on the environment, the complexity of the many isolated black box solutions in the bus, and new business opportunities were being combined with an aging IT infra-structure in the bus. This created an interesting opportunity to design a new infra-structure virtually from the ground up, taking advantage of modern technology.

The number of IT solutions in a passenger bus is surprisingly large. Today, a bus interacts with the road systems, it provides up to date information to the electronic displays, it handles the ticketing issues, and reports about the state of the bus. Traditionally, different vendors provide their own isolated solutions.

Not so for RDTL. They started a collaboration with GeenSys, a French IT company specialized in embedded systems to create the e-nove architecture. The input was to create a system where an OSGi gateway in the bus would communicate with an OSGi server in the back office. The gateway connects all the equipment in the bus, provide local information to the driver and aggregates the information to the back-end. Instead of having a proprietary ticketing system, the OSGi gateway connects to a printer, reader, and a display. This all being controlled by OSGi bundles. In the past two years, this architecture was developed and implemented in a remarkably short time. Today, there are more than 30 buses equipped with OSGi gateways.

After I queried Eric for some more information how things had been going, he replied with the following quote:

The best positive experience we got is that we immediately needed an "small application" this summer. I asked a local software company to design this software. They spent 2 days training with Geensys engineers. Thanks to e-nove, they spent only 2 days to design this application. This is great because this was one of the key goals of the project. We can react, adapt and deploy bundles in a very short time.

The e-nove architecture is a very nice example of what you can do with OSGi. It has many of the use cases that drove the development of OSGi in the early years and it is wonderful that it not only has been developed, but it now also been proven to provide the expected advantages. Thanks Eric, for this update!

Peter Kriens

JavaBlend in Ljubljana and Belgrade

About 6 months ago Aleš Justin (JBoss/Redhat) asked me if I could come to Ljubljana for the JavaBlend conference. I told Aleš to talk to OSGi marketing and after some mail exchanges we agreed that if they paid the trip I would come. After this was agreed, I was informed it also included a presentation in Belgrade. Well, from a time perspective this wasn't too much of a difference so I agreed, under the condition I could fly back Friday from Belgrade and then forgot about it.

Normally a conference trip means flying in the night before, giving your presentation, talking to a few people and then trying to get back home as quickly as possible. However, this trip turned out to be quite different; it felt more like a 3 day adventure than work.

The Ljubljana JavaBlend day was very interesting with just very good speakers. Everything helped, the weather was good, the location was excellent (a very nice castle overlooking Ljubljana), and an intriguing number of very young fashion models.

Even my presentation went well. I was fortunate that the speaker before me, Juha Lindfors (OpenRemote), spoke about an open source project doing home automation. Exactly the area that got OSGi started! Though they had taken Tomcat as their platform, I obviously worked on him to move to OSGi. I could honestly say OSGi was made for exactly their purpose.

I learned about Yugoslavia in school and I followed the news about Tito's dead in 1980, the breakup, and the balkan wars. However, the whole geographic situation was a tad fuzzy to me. The first time in former Yugoslavia, the republic Slovenia definitely charmed me, especially because Aleš had taken me on a small sight-seeing tour. However, what I did not know was that Belgrade was more than 500 KM away from Ljubljana. We would do the trip with a bus. I had visions of a small executive bus with leather fauteuils and a lovely stewardess serving us coffee and snacks. Not too bad I thought.

The next day we would leave at 2pm so that would at least gave me some time to get some work done in the morning, which I decided to do in the bar, enjoying some latte. However, this plan was disrupted by Dalibor Topic (Sun) but he made more than up for that by providing a more than worthwhile discussion about JSR 294, the meaning of life, OSGi, and Sun. It is always nice to talk to Dalibor, whom I seem to meet on more conferences than pure chance would predict.

At 2pm we gathered in the lobby and we took a taxi to the Parsek (the conference sponsor), where the bus would leave. There my visions of spacious leather seats were rather rudely shattered. Even Michael O'Leary would've blushed about the available leg space. However, the lack of space turned out not to really matter that much because the trip went amazingly fast. In the bus I was sitting next to Manik Surtani (Redhat) and we had a long and intense discussion about lots of very interesting subjects. Manik was interested in OSGyifing his Infinispan (a data grid) project so I might have made another OSGi convert. Hey, I am the evangelist!

Though Tomaž Cerar had forgotten to bring the promised bottle of whiskey, the hosts kept us well entertained through the evening driving through Croatia. We were told scary stories about the Serbians specifically and Balkan politics in general, creating a nice suspense. The eerie mood was amplified by farmers burning their land all along the highway, supervised by a slowly rising large blood-red moon. The crossing of the Kroation-Serbian border was therefore almost a disappointment when it only took 10 minutes by civilized officers instead of the 2.5 hours and brutal interrogations we were promised. Though the very modern (well in 1971) 5-star (Serbian stars that is) hotel turned a bit scary when they insisted to take my passport and then pushed it through a hole in the wall. Fortunately, I got it back half an hour later, though it took some angry looks.

The next morning we had to travel through the middle of Belgrade to the conference hotel. I still remembered the scary stories of the night before, describing Serbian drivers and Belgrade traffic. Especially the queues over bridges were told to be notorious. Now, it was kind of important to me that we started in time because the plan was that I would be the first speaker, then hop in a taxi, and hopefully catch my flight back from Tesla Airport. After all the horror stories leaving at 7.30 sounded, well, not unimportant. However, the relaxed nature that seems to be part of of all ex-Yugoslavians made us leave well after 8. Traffic was not too bad but I am pretty sure we blatantly violated the rules of the bridges of Königsberg by crossing the same bridge multiple times. And I am sure it was the same Samsung building I saw after about 20 minutes. Thinking about my taxi ride, it was also a bit disconcerting that we seemed to move farther and farther away from the airport. We did arrive before nine, well just. Any hopes to also start at nine were shattered by two introductory speakers that took their time, and more. Then, half way through my presentation, I was told to stop because the taxi was waiting. I felt that I needed at least another 10 minutes to finish and take some questions, only to discover the taxi had disappeared when I came down! Some nerve wrecking 15 minutes later, and several organizers talking in their phones (still relaxed!), an also very relaxed taxi driver showed up. And actually they were right, the drive to the airport was a non-event, though I swear I have seen cars on those roads that I had last seen when I was 5.

Thanks Aleš for inviting me and all the others that made this a really trip wonderful!

Peter Kriens