All the small things

After being involved in OSGi for a couple of years now, I finally had the chance to attend one of the community events. I have to admit, I was kinda nervous. I talked to so many people in the community for so long through the mailing list or personal mails, but actually never really met one of the folks there, so this was the moment to meet them in person. It was kind a weird, it felt a bit like finally meeting someone you got to know by one of the online flirt portals (not that I ever did something like that, but that’s how I would have imagined it ). You know the prejudice that Computer Scientists are all nerds and freaky to some extend, so this was really exciting. In short, I wasn’t disappointed – more the opposite! I haven’t met anyone I don’t like! Especially Richard Hall(Apache Felix lead), Jan Rellermeyer(ETH Zuerich), Michael Keith(Oracle) and Jo Ritter(ProSyst) seam not only to be really nice guys, but are also very good speakers. So if you have the chance to attend one of their talks, it is worth attending!

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

This time it’ll be a very short post I just want to support my favorite Webbrowser, which I use for years now and which has become my first program I usually install on a new computer. I hope this way I can give something back to the community.

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

Two weeks ago I received great news. The proposal I committed with my fellow coworkers (Boris Terzic and Markus Gumbel) got accepted at the OSGi community event, so I hope I’ll see some of you I only met virtually till now. Concerning the topic – I think it’ll be interesting for all of you working or at least intending to work with security and OSGi. Now, after I am allowed to talk about it, I will be able to share some of the experiences we gained.

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

At the beginning of this month[1], SpringSource published the first beta release of their so called SpringSource Application Platform[2], an (as I would call it) extension of the existing OSGi platform. The move came pretty surprising to me, I have to admit. No announcements prior to the release, no actual hints – nothing. Pretty impressive I have to admit. A company grown that popular being able to work on something from this magnitude without even seeding the glimpse of a rumor. Good job.

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

After revealing details of the new SDK for the iPhone last Thursday, Sun decided to develop a JVM for the iPhone after Apple showed no intention to do so. Well, for some of you, this is not much of a deal. Java is available on many mobile phones, why care about one more or less? From my point of view, this makes a huge difference. OSGi, actually developed to improve the mobile sector and fight the short comings of J2ME, never really succeeded due to the lack of computing resources like memory or CPU power on former cell phones. With the iPhone, things might change.

(more…)