Disclaimer: This video is about a year old (still Eclipse 3.4) and didn’t go through post production, so do not expect too much from the video quality

If you have problems viewing the video, you can download it from here

Cheers,
Mirko

So, I am happy to introduce the (OSGi)…

Before going on explaining what it is about, what it can do and why you might wonna take a look at it, be warned! As of now, it is still a proof of concept project. It sure does offer help and is better than nothing, but I am not satisfied with some details of the API and implementation, so expect severe changes within the next couple of weeks (if not months). You’ve been warned

Anyway, the goal behind the inspector is to offer a simple framework to detect common coding mistakes in OSGi. Very simple things manifesting in ClassNotFoundExceptions, missing services, unresolved bundles or not attached fragments. It certainly is not the “one to rule them all” solution, but it is a (hopefully) decent effort to help you move faster with your OSGi development.

So, what is the inspector really. Currently, the inspector consists of three major parts: the core, the reasoner and the web GUI. The core offers basic functionality to analyze the running OSGi environment in a convenient way. This includes, but is not limited to:

• imported, exported packages with their versions, properties and directives
• provided services
• pending, removed and failed service requests (partially depending on a R4.2 runtime)
• framework events with special treatment of errors
• dynamic imports
• fragments
• framework capabilities
• class look-up within the runtime (which bundles provide a specific class?)
• …

This all is realized in one single bundle you have to deploy and start as the first bundle in your OSGi runtime (any runtime is fine, as long it is a R4.x one from any implementer).

The reasoner is the second bundle and provides the logic to solve your common problems it uses the core bundle for getting the required information to make reasonable guesses on what’s wrong and even more important, on how to fix it quickly. This part is the most experimental one. The idea is to have an extendable API that is not limited to standard OSGi problems but can be extended to solve your domain specific problems as well. The current implementation only includes one use case yet – ClassNotFoundExceptions propagated to the OSGi runtime. Other reasoners are already work in progress like failing service requests, missing services and not resolved bundles in general (bundles and fragments actually). If you can think of other common OSGi problems, please let me know!

The web gui is a convenient way to take a look at the discovered problems and the suggested solutions. It is very simple and straight forward in order to solve the problems at hand. You don’t need to use it, you could also create a simple command line tool doing exactly the same. I actually would have preferred a command line tool over a web gui, but because of the lack of a common API to provide command line extensions over OSGi implementation, I decided to not yet provide something right now. Maybe later if the the feedback suggests otherwise.

To get you started in no time, I also provide an assembly based on pax-runner that starts all bundles required correctly and allows for easy provisioning of your own domain specific bundles. There is even a very simple tutorial available at github.

So, if you’re interested, take a look at it, give it a spin and let me know what you’re thinking! Any feedback is greatly appreciated!

Here the links for further details:

Binary download: http://github.com/mirkojahn/OSGi-Inspector/downloads
Tutorial: http://wiki.github.com/mirkojahn/OSGi-Inspector/tutorial
Source Code: http://github.com/mirkojahn/OSGi-Inspector
Bug tracking: http://github.com/mirkojahn/OSGi-Inspector/issues

I also have plans for additional features for the next version (maybe this summer) of the inspector, like making the Web GUI extendable, including more JVM information and debugging capabilities like heap dumps or per bundle memory usage, statistics about the application like running threads, used frameworks and their versions, runtime bundle dependencies, search over many of the aforementioned features and much more, but this will be mainly based on user feedback. So stay tuned and let me know what you’re missing.

Finally here are some screen shot to give you an idea how the proof of concept looks right now

As a final note, one may ask if OSGi experts are becoming obsolete by tool support like this. I don’t think so! In my opinion, this is something that is crucial for a wider OSGi adoption and an important helper to silence the OSGi opponents by solving 90% of the beginner problems with regard to basic programming errors. It can serve as a teaching tool to tell people what not to do or how to do things better. OSGi experts now can focus on the important stuff like how to design and build truly modular applications – as they should have been for a while.

Yours,
Mirko

I thought a lot about the resistance of parts of the Java community in reusing the OSGi standard and starting from what we already have and in my conclusion the problem is two fold. First, it has come from a source outside the JSR initially. Well, I know this is debatable, because OSGi was one of the first JSRs and now with JSR 291 it in fact is one, but it is not “developed” within the JSR process, so one can say this is a valid point. Second modularization is in fact a tough call. When looking around, there is no other language or standard (even beyond Java itself) that has entirely tackled the problem and boy since David Parna’s introduction of the concept of modularity in 1972 quite some time has passed. A “fan” or not one has to admit that OSGi has already has gained a name in terms of modularizing the JVM and looking at the time required, well it took over 10 years to get that far. So I think it is fair to say that modularization is not easy to accomplish and to get right. In fact I had my problems (and partially still have) with OSGi as well. Let me explain…

My first contact with OSGi

When I first encountered OSGi I was working at IBM Research trying to explore ways to improve the modularization approach of [UIMA]. UIMA itself already had the notion of components or modules if you prefer already, but in a way it left certain features to get improved. In particular the isolation of each module wasn’t enforced, so introducing 3rd party modules into the runtime was a risky business. Especially when giving the fact that these modules had access to basically all resources. You never know what they are using or how they behave in the system. That, for instance was a reason to separate the processing into an other Java process. If that one fails, not the entire system is affected. OSGi in this context wasn’t THE savior, but it helped to make it more robust. No Java based model can provide real isolation of modules on JVM level (without the need to create a separate JVM instance is still something entirely missing in Java – one can ALWAYS create an OutOfMemoryError if he or she intends to). The great benefit of OSGi was simple. Hiding internal APIs, making dependencies explicit and potentially create a repository of reusable artifacts being usable without pages of manuals describing on how to set-up a system suitable for these modules.

How OSGi is received (on first encounter)

As you may imagine, one of the most important goals was to hide OSGi as much as possible. No services, no Import-Package (but Require-Bundle on one aggregation bundle), basically reduce OSGi to its minimum. Well, the appreciation was… limited. All people I was working with were exceptional bright and determined researchers in MLP. They developed highly sophisticated algorithms on how to analyze unstructured data, but only a few were software engineers. So the code was… working, but not production ready. Enforcing them to apply rules that ultimately made it harder for them getting things done and as a result slowing them down wasn’t something they welcomed very much. This is something I can totally understand and relate to! What is a system worth, if you don’t gain anything! Well, the problem here is that they didn’t gain anything, because they just used their code and to a limited extend the code of others, so the overhead of integrating with others was rather limited. The real benefit is visible when you start reusing multiple artifacts and potentially in different versions. This is something we (as a community) are trying to achieve for decades but failed so far, if you ask me.

Some reflections about our history

Looking at the history of Java it feels like it is a common problem. One tends to address the immediate problems. In principle there is nothing wrong with that, but in often after introducing a new standard you realize that the actual problem is way more complicated or you haven’t anticipated all vital use cases and the trivial approach looking so attractive at the beginning won’t work in the long run. The problem then is only that you don’t want to brake backwards compatibility and eventually this will drive the design of your solution, ultimately removing many otherwise possible ways to go. Talking about history, when we look back, jars where introduced as a distribution format for applets. Surely solving the immediate problem. After a while, Java on the server emerges and yet another problem arose. Separation of different web applications. Well, we know how it ended, eventually we got different class loading solutions for each J2EE vendor, because this part of the specification was left out.

My point is…

Now we have Jigsaw addressing a subset of OSGi’s modularization capabilities, which by itself is perfectly fine (even if it is not OSGi what they are going to use). The problem I fear is only that soon there will be more requirements altering the current approach unfitting. In particular, the great benefit of modules should be to be able to reuse them, without the need to understand all their internals. It was stated that OSGi’s restrictive class loading approach is not suitable for many applications. I tend to agree. I experienced this pain and it wasn’t pleasant. I heard that not allowing split packages is not acceptable, because it is a necessity. Why? Is it, because it is a good design or just because current systems are using it? If you want to create modules, you want to make them robust, so except for the exposed (public) API, it shouldn’t matter how it is implemented. If modules are not enforced to have their own class loader, you can never be sure whether or not you’ll have collisions. Yes, this is a pain in the **** to rethink and rewrite existing code! And I also have better things to do, than to retrofit some working libraries – no doubt! The question we should ask ourselves however is what do we really want? A system seamlessly integrating with existing code or provide a new way of thinking which might not be as simple as hoped, but give us what we need in the long run? Do we want reusable entities or a better provisioning system as plain jars? Don’t get me wrong here, I am not saying OSGi is the solution or should be used at all! Just saying that the requirements are dictating what you should get and if you intend to create “real” modules, the lessons OSGi learned are most valuable, even if you are eventually taking a completely different approach. In fact it has its short comings and flaws as any other system has.

OSGi is not perfect either

Working with OSGi for a while, I came across several places, where I noticed the need for improvement. For instance, OSGi provides a pretty strict module system, which when running is well defined. Unfortunately, there is a problem with how to get to this state or even knowing when this state is achieved. The idea behind its model is that using services, there should not be any dependency on the start order, because everything can change at any time. This is a nice idea, but in real world it is impossible to achieve. For instance, I am currently working with embedded devices and due to the limited hardware the  start-up can take minutes. Based on the dynamics however, a user might already see a web interface popping up, which seems perfectly usable. However, when using OSGi’s ConfigAdmin service to gather all configured configurations, it can happen that not yet started bundles don’t provide the required information, so the resulting configuration is incomplete. Similar things apply to the start order (no start levels are not sufficient) when using security. It is just not standardized how to ensure that certain bundles have to be loaded before everything else in order to start a particular runtime with security on. OSGi limits itself to define the runtime behavior, leaving out configuration issues when moving from one container to another. Basically the configuration for the start levels of each bundle getting loaded is an implementation detail – doesn’t this look familiar to you when using JEE . Also providing tools to inspect the runtime behavior (how the container resolves dependencies is not sufficiently defined, so you have to jump through a lot of hoops or use implementation details of a particular implementation. Not really helpful/desirable from a tooling provider perspective. I could go one and on, like with every other technology. Work in progress is written over everyone of them. So, you see, there is so much that can still be done to improve our situation. No one is perfect and will ever be. We can just try to do our best to progress and learn from our faults.

Properties of a true module system

Well, after talking so much about what’s not right and what can be improved, I guess it is just fair to also draw a rough picture of a system providing the features of true – meaning reusable – modules. To help me out a little, I took the liberty in quoting one of the experts of componentization/modularization (which is not quite the same). Clemens Szyperski is currently working for Microsoft (I think) and so has no real relation to Java at all, but his observations and remarks hold true even in our space.

„A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.“ [Szyperski et. al. 2002, p.41]

… and a more brief definition of required properties.

„The characteristic properties of a component are that it:
• is a unit of independent deployment;
• is a unit of third-party composition;
• has no (externally) observable state.“ [Szyperski et. al. 2002, p.36]

I think this sets the floor for more further investigations. In particular, the citations above are nice, but pretty vague and open to interpretation. For instance, what is “independent” when we’re talking about deployment? What does composition mean in this context? Is it just a descriptor, is it a zip or rpm file containing everything? I don’t know and it doesn’t actually matter I think. What matters is that the resulting system is compelling, concise and valid within itself. Of course, some features seem better than others, but we also need freedom to explore new ways of thinking.

So while thinking about the core features of a (potentially) new module system, for me I identify the following as most important:

• Isolation:  When talking about isolation, I am basically talking about trust. Having a module system defining an isolation on module level (which currently can only achieved by having a custom class loader), gives me as the module designer the trust that I can create something without the fear of breaking something on the user side, just because of an implementation detail that is not part of the public API.I can trust that when I have the isolation on module level, I know what will have to deal with. As they say: Good fences make for good neighbors.
• Information hiding: Yes this is as old as it can get in software engineering, but this is the most critical part in so many ways. First of all, I understand modules as a way of abstraction. Zoom out of the implementation details and just focus on the API. That’s what I want! Black Boxes, only with interfaces (or maybe factories visible). Of course, API contracts purely defined in Java Interfaces are not precise enough to provide all required information (like ranges, value lists, limits,…), but is a starting point. The right documentation should or for now has to do the rest.
• Enabling reuse: Currently the silver bullet to decouple is dependency injection. Although a great way of doing so, it is not enforced. Anyone can just programmatically wire up classes. As a result you get bound to an implementation, which again makes reuse and updates way harder. If I know I have to use a certain API, I usually don’t care who is providing the implementation and that’s key for every robust system.
• Predictability: Well, usually even in JEE we assume we know how an application will behave, once deployed, but in reality, it is just not true. Resolution is based on the class path which can contain, depending on where you deploy your application, basically any classes and libraries. Now you have many not easy to manage factors affecting what gets loaded when. For instance there can be multiple logging frameworks in different versions pressent interfeering with the one provided by your application. Depending when they are found in the class path, they might cause problems or not. A deterministic system, that declaratively defines its dependencies will only see the required ones. Everything else is just hidden and serve other applications if they need it – no interference with each other!
• flexible binding, yet safe binding: This is something increasingly important and also not accomplished satisfyingly by any module system I know of – so far. Basically what one wants is to create an application based on the dependencies known and being able to fix later in time appearing problems without the need to redeploy and change the whole application. For instance if a security vulnerability in one module is detected. The latest version should be deployable and tell the runtime that it is a fixed version of some of the existing ones within the runtime, so those versions can be replaced.
• robustness: Currently no in-JVM approach can guarantee any runtime behavior like the consumed memory or the allocated cpu cycles. If you get a malicious module, it can bring down the entire JVM. There are already research projects out there providing such features, so in theory it should be possible to achieve this on JVM level.

Of course, there is more, but I think the list is contains the most important parts. You might have noticed, there is no mentioning of OSGi or the way OSGi is doing it. I believe there is always more than one way to accomplish your goals, so maybe the OSGi community overlooked a possibility – I honestly don’t know. So if you’re able to come up with any solution that fulfills these requirements, I would be more than happy. Maybe and only maybe you can consider looking at some of the approaches the OSGi was taking to tackle parts of these problems.

Yours,
Mirko

References:

[UIMA]: http://incubator.apache.org/uima/
[Componentization Wars Part II]: http://osgi.mjahn.net/2008/12/04/componentization-wars-part-ii-guerrilla-tactics/
[dmeuima]: http://www.alphaworks.ibm.com/tech/dmeuima/
[Szyperski et. al. 2002]: Szyperski, Clemens ; Gruntz, Dominik ; Murer, Stephan: Component Software. Beyond Object-Oriented Programming. Addison-Wesley Professional, 2002 – ISBN 0201745720

In the interview, I had the chance to actually talk about our latest development and highlight some of the amazing things we are working on. Being involved in OSGi for years now, I got to see quiet some OSGi based projects and designs and believe me most of them seem like toy projects compared to the degree of OSGi utilization the team I am working in has achieved. Working with OSGi behind the curtains for about 4 years we have several products based on a core framework, which is currently driven towards the first product line that is actually worth being called so. Unfortunately I have to note that only very little of this credit belongs to me. Most of it was done before I joined the company. Although it was the reason, why I joined, I am still amazed by how much we are working on the cutting – sometimes more “bleeding” – edge, like OSGi security. I don’t want to sound like some marketing guy promoting something, but if you’re interested in the technology and are looking for real applications running in the field – have a look at my interview. Enough said… Many thanks to my team for the great work and the inspiring and friendly environment one just have to love working in.

Cheers,
Mirko

Yesterday I read about the latest news concerning Sun’s plans about the future of JSR 277, JSR 294 and its new plans on inventing componentization for its JVM called Jigsaw. I hate to say it, but for me, it seems like Sun behaves like a small child trying to insist to be the one driving all development and not letting someone else play with its toys. It’s anything but the behavior of a well establish and industry leading company or one who wants to become one. First they completely ignored the problem of componentization in Java while persuing enterprise development with J(2)EE and missed their chance to actually set the foundation for real software reuse what you would expect from and enterprise ready language specification. Later, when OSGi began to rise they started the JSR 277 and tried to create a competing standard in secret, which didn’t work out too well as we all know. Now, because of the pressure of the community and the lack of showing a better solution they are abandoning the JSR and start developing their own “internal” componentization approach with the Jigsaw project. Of course they are claiming it is not intended to be used outside their own use case for componentizing the JVM, but it is hard for me to believe this. Call me paranoid, but for me it sounds much more like an attempt to develop another system, which after completion is suddenly moved into an official standard. Sun’s statement that they are going to revive JSR 294 and are inviting even the OSGi Alliance to participate to work on it feels more like a distraction so that Sun is able to pursue its plans with Jigsaw in private that without public notice they suddenly can come up with a self made de-facto standard. Again, I might be to paranoid, but it just doesn’t feel right. Is all that just a coincident? I don’t think so. Why can’t they embrace the work done already and see it as a great chance to propel their Language and create a true reusable software stack, no other vendor can offer? Hal Hildebrand just blogged about Sun’s attempt to introduce this new project and the way they are trying to persuade big industry players about their great intents… Well, you should really read his post about it and please tell me, if they have such humble goals, why does everyone they consult have to sign a NDA? I strongly believe that if those ideas are so great, why not share them and let the community decide and participate?

To wrap things up, I ask all of you who feel like me, share you’re opinion! Comment on Hal’s post, blog about it, link to it, spread the word. I believe we – as a community – have to stand up and say what we think to show Sun, that those kind of guerrilla tactics, especially when so easily to look through are not working. Keep your eyes open and don’t fall for the dark side

Cheers,
Mirko

Besides the talks of the already mentioned speakers, there were several other talks I like. Namely the talk of Hans Bossenbroek for Luminis, Jon Bostrom (MobiNoir Consulting) and of course the Key Note of Peter Kriens. To go deeper and talk about every single talk would just be too much for this post, but all the talks either gave me some good insights or were just fun to watch. Well done! I am more technical oriented, so unfortunately the first day wasn’t as interesting for me as the last one was, but I think this is the tradeoff of such an event.

Socializing wise speaking, this conference was pretty good as well. I talked to many interesting people and gained a lot of insight of the community. You can’t imagine how many companies are using OSGi for years now, but are just not talking about it. It is really impressive to see how far they have gone and what they have achieved with OSGi. I really think in the near future, we can expect to see many new areas, where OSGi will become the defacto standard.

Concerning the talk I gave on Wednesday, I just can say that I am more than happy with the feedback. The room was so packed that some people even had to stand, which didn’t really helped me with my nervousness After my talk, I had the chance to talk to several people about security, their experiences and new ways how to tackle the problem I outlined during my presentation. I think, we are on a good way to come up with suitable solutions and I am looking forward to more interesting discussions. People are now starting to use the features OSGi is offering this will drive more, even better solutions, we will need for a broader adoption. Security is crucial and when we are finally starting to deploy multiple applications side by side in one OSGi container, we can’t longer assume that everyone is playing nice. We have to enforce security, that’s what we owe our customers/users. If you hadn’t time to talk to me during the conference or didn’t have the chance to attend the event and are also involved with similar problems I am more than happy to get in contact with you. Just drop me a mail. I think the more input we can get the better the solutions are, we can come up with. Of course, I’ll keep you posted how things develop along the way.

Till then – cheers,
Mirko

The firefox team is currently trying to get a Guinness World Record by the most downloads within one day. To accomplish this, they created a website collecting potential downloaders and coordinating the event. If you’re a supporter of firefox (or wanna to become on) and want to give something back (besides being part of a world record) you might consider registering. Of course giving away your e-mail-address credentials is always something that concerns me, but I actually trust these guys and just hope they are not doing anything stupid with my data.

Besides being part of the effort, I think the latest version of Firefox sports a lot of cool new features, which are just worth checking out. Even the latest beta of Firefox 3 is already great and you might wonna have a look at the features it already provides. As far as I can tell, this version is already stable enough to give it a test drive. So give it a shoot and check it out!

Cheers,
Mirko

In the talk titled “Do not disturb my circles! Secure Application Isolation with OSGi”[1], Markus Gumbel[2], and I are going to talk about how to isolate several application domains within one JVM – based on OSGi mechanisms. No big deal, some of you might say, but depending on your requirements, it actually might become a big deal or even serious issue. In our very case, we will face a Common Criteria(CC)[3], evaluation for our JVM based components ([4], gives a nice introduction on this topic – unfortunately only in German). But first things first…

InterComponentWare AG (ICW)[5],, the company I am working for right now, is one of the (if not the) leading eHealth provider in the business, with a wide ranging product portfolio. The core product is called LifeSensor[6],, which is an electronic health record like Google[7], and Microsoft[8], introduced recently in their first versions. If you, like me, are a little paranoid about privacy issues, I can recommend you “our” service for sure. We take security pretty serious and have a whole department dedicated to this. Medical data are always a big issue. Consider your CreditCard data is lost, you can get reimbursed from your CreditCard company, once the access to your medical data is compromised, it can’t be undone. Pretty serious from my point of view! Anyway, this is actually not where I am aiming at. We (and my group in particular) are involved in the implementation of the German Telematic Infrastructure project specified by the Gematik[9], and commissioned by the German government.

In our talk, we will take the “Konnektor” we are developing as the sample application to illustrate the usage of the OSGi security features. The Konnektor (we use the Cisco AXP platform[10], underneath) is the key device deployed at every medical practice and pharmacy. It is responsible for creating secure connections to the telematic infrastructure back end, as well as other security relevant tasks like reading eHealthCards, signing prescriptions or uploading emergency data on the electronicHealthCards for instance. [11], gives a nice overview, how things are done in more detail. Additionally the specification allows to have third party applications to be deployed on the connector as well, to extend its functionality. A concrete example would be the integration of the LifeSenor mentioned above to directly upload your X-Ray images to your eHealthRecord. You might understand, that security plays a very important role in such a scenario.

The key problem we are faced with is that the functionality of the Konnektor has to be certified according to the CC, which I mentioned at the beginning of this post. Well, certifying software in general is not easy, especially if you are talking about security and something as complex as we have. The real problem in our case however is not certifying that the software does exactly the stuff specified – no more, no less -, but also allowing third party “plug-ins” to extend its features without compromising its certified functionality or the security of the whole system. In a simple scenario, a doctor uploads a new “feature” from a malicious source to the Konnektor and we have to ensure beforehand that nothing serious can happen – tough one! Well, of course, we not only found a way, but also found a way using OSGi’s security features to do the trick even within the same JVM. The Konnektor and potentially dangerous third party extensions running side by side in the same JVM (of course, without restarting – there is a reason why we are using OSGi!).

Like every other cutting edge software project, we also found ourselves struggling with various problems no one has experience before and so I am pretty sure, we can contribute some important insights in the domain of secure OSGi application development. I hope this will be as interesting for you as it is for me to work on this topic. It is really something you can’t find a lot published about, if someone has done something similar or knows about something, I would be happy to hear about it!

Although, the sample we chose is pretty unique domain wise, the basic techniques we will present are applicable in many different domains as well (banking, insurance, development, personal live style,…). Just think of your Eclipse installation. Right now, you install your plug-ins without a SecurityManager and hope that the plug-in only does what it is supposed to do… What if it doesn’t – or better doesn’t intend to play by the rules? I can see OSGi frameworks running as general platforms combining various different application in one JVM in the furture – a kind of a meta Operating System. As soon as this vision becomes reality, I don’t want applications being able to communicate without restrictions with each other. My health insurance provider together with my personal medical record manager in one container… you never know what an insurer might do, when they get a hold of your sensitive medical records. At least I certainly don’t want to try this out!

I realize that parts of this post might sound like a commercial. If so, this is certainly not intended, but I felt the need to explain in more detail than I will be able at the talk, why we did what we did and why this is so important. In the talk, we will stick to the technology only and avoid as much as possible any relation to a concrete product – I really hate talks pretending to point out new technologies or lessons learned, but actually trying to sell a product instead, so you’re safe here for sure!

For those of you attending the conference, don’t hesitate to talk to me, if you have any questions or just say hello. I was and certainly am a big fan of technical discussions. All of you who won’t be able to attend the event and interested in the topic, don’t worry, after the talk, I am certainly blogging more about this topic in the near future Till then, stay tuned!

Cheers,
Mirko

UPDATE: the slides can be downloaded from the OSGi Website for everyone interested (pdf)

–

[1] http://www.osgi.org/CommunityEvent/Program
[2] http://www.osgi.org/CommunityEvent/Speakers#MG
[3] http://www.commoncriteriaportal.org
[4] http://www.bsi.bund.de/cc/
[5] http://www.icw-global.com
[6] https://www.lifesensor.com
[7] http://www.google.com/health
[8] http://www.healthvault.com
[9] http://www.gematik.de
[10] http://www.cisco.com/en/US/prod/routers/ps9701/axp_promo.html
[11] http://www.cisco.com/en/US/prod/collateral/routers/ps9701/data_sheet_c02_459078.html

Well, I guess eventually the guys behind Spring are trying to make money. A very natural thing for a company, of course. After having provided the community with a great framework for so many “supposed to be” JEE applications for free, it is time to gain some revenue. I think they deserve it after all they have done for the community. Actually I find it in particular interesting how the strategic move, choosing GPL[3] as the license of choice, will work out. On the one hand, I can totally understand the point of view, choosing a license, which forces competitors to play with open cards and actually contribute to the community. On the other hand, I have to say, I am thinking twice before putting me in the hassle of dealing with a viral license. For instance, when I lately was involved in the decision between LOGBack[4] and Log4j[5] as a logging back end, the decision was not only based on features, but mostly licenses. In some scenarios, licenses are just a show stopper, so I honestly hope this will not be the case for my fellow colleagues from SpringSource.

Enough philosophizing… Spring released a very interesting extension to the existing OSGi specification. Summarizing all the new features they provide would certainly go beyond the scope of this blog, besides I am by far not as knowledgeable as the developers themselves, so I will just refer to their great introductions [6],[7] and [8]. Instead I want to point out some things I consider worth mentioning.

First of all, the repository[9] is just great. With the experiences I’ve made by migrating existing applications into modular, OSGi based bundles, I can tell this can be pretty time consuming and frustrating, if done accurately (not just adding some headers to the manifest.mf, but also changing the existing code to work within OSGi where necessary).

The second thing I’d like to mention is two sided… On the one side, OSGi is missing another abstraction layer, I think. Defining full functional, domain modules to help people jump start in OSGi is needed – no getting lost in dozens of bundles, versions and services. I think all of you, working with OSGi for a while, have been faced with the problem, where you resolved and started every bundle appropriately, but your program will just not work, because you forgot to deploy the actual implementation of a service. Knowing your system, it won’t be a big thing finding the problem, but in a unfamiliar application with hundreds of bundles deployed and more potentially ready to be deployed from a repository, just waiting to be picked… which one is the one to choose? An abstraction – bundling those, as Spring has done it with its PAR – might help.

But, there is also another side to this story. Maybe all we need is some sort of indicator, a meta data to indicate, that a specific bundle provides/ consumes a distinct service? This will remove the provider lock-in problem caused by solutions like “Require-Bundle” for instance. All we actually need is a (in some way) abstract concept of a working entity (or application or domain module as you might prefer calling it), which is more abstract than usual bundles. This can just be the aggregation of certain packages and service consumers as well as providers. Only APIs, no actual implementation dependencies and for sure no Bundle-SymbolicName dependencies. An ideal application now would only consist of a couple of domain modules, which have to be deployed in the OSGi container. The container (with the help of the repository) now just picks the required bundles and assembles the application. No need to define a specific vendor, everything will be resolved by the framework. That would be my dream…

Anyway, I think this is something, which should be discussed in more detail in official sources. The approach Spring choose is certainly a way to go and test drive, but honestly, I doubt that it’ll turn out to be the right fit in the long run. All solutions I can think of, which were created to solve a certain pain are a serious burden and actual blocker in the long run, like Eclipse Buddy Class Loading, the OSGi Require-Bundle* header or the (unlimited) backwards compatibility required by the jar specification.

The last thing to mention is the introduction of the new headers. In general, I am all in favor of doing so and I am not surprised about the chosen names. Of course, they might clash with later headers, potentially introduced by the OSGi Consortium, but this is nothing new in Java. If you take a look around, developers as it seams, consider the reverse domain nomenclature as a burden and just ignore it. Even if it is now better established on a package level (although there are still rather well known exceptions like the IAIK[10] or even Peter Kriens FileInstall[11] bundle for instance). On a Manifest level however most of us (including myself) can pledge guilty of silently ignoring Java best practices. Unfortunately the magnitude of such a decision hunts you down later. The recent discussion about the name space issues of the OSGi headers, was the perfect reminder for me to give these small things more thorough thought, as we usually tend to liberately ignore them most of the time in favor of fast development. Well, at least I pledge betterment and hopefully so does every responsible developer, too

Cheers,
Mirko

*) Sorry, but I just can’t help it. In my opinion this header is not only a hurdle, but a real drawback from a componentization point of view. From a migration strategy approach, I guess the opposite applies, but what lasts longer – migration or maintenance?

–

[1] http://www.springsource.com/web/guest/2008/applicationservermarket
[2] http://www.springsource.com/web/guest/products/suite/applicationplatform
[3] http://www.gnu.org/licenses/gpl.html
[4] http://logback.qos.ch
[5] http://logging.apache.org/log4j
[6] http://underlap.blogspot.com/2008/04/springsource-application-platform-ships.html
[7] http://blog.springsource.com/main/2008/04/30/introducing-the-springsource-
application-platform
[8] http://blog.springsource.com/main/2008/05/01/completing-the-picture-spring-
osgi-and-the-springsource-application-platform
[9] http://www.springsource.com/repository
[10] http://jce.iaik.tugraz.at
[11] http://www.aqute.biz/Code/FileInstall

The iPhone is way more powerful than regular cell phones and provides a perfect platform for next generation mobile applications with its big display and the new intuitive user interface. Even better, with the eRCP project, Java already has a simple framework foundation for mobile applications and together with native GUI support thanks to eSWT, performance and usability should no longer be an issue. I haven’t heard about any plans to provide eSWT support for the iPhone yet though, but as soon as Sun provides a JVM at the end of June, I guess it is just a matter of time – at least I really hope for it!

Going back in time one can say that Sun missed the opportunity to conquer the mobile market. Java is deployed on millions of devices, but real business only a few companies managed to do with it. Now, with a powerful phone, technologies like OSGi, eRCP and native eSWT widgets, I am really curious how Java competes against Google’s Android. The newcomer against the old-timer, does a wealth of experience and a lively community stand against a giant with the wind of fortune and the hype of the brand in its sails? I guess, there is a good chance for Java and I really hope to see my Java applications running on an iPhone, but that’s a different story. Maybe in a few years my dream comes true and mobile phones no longer need a Java light aka J2ME any more, but will ship with a full blown JSE. So every jPhone ehm, I mean iPhone is sold with Java on board.