OSGi DevCon/EclipseCon
2008-02-27
I hope you did register at OSGi DevCon/EclipseCon? It is only three weeks to this event and we would really like to see you there. I think this years program is exceptionally strong. For sure the OSGi DevCon program. It was really hard to choose this year from the large number of excellent proposals.Do you know that this year the registration includes tutorials? This is the first time I see this in a conference and I think it is an excellent idea. It allows you to choose without having to worry about the financial consequences. The only problem is that there are so many interesting subjects that it is hard to choose.
The supposed dichotomy between services and extensions keeps people occupied. I hope we can finally decide this year when and where to use what. Not only do we have a tutorial, a presentation, but also a panel about this subject. To muddy the waters even further, a Jazz member will speak about a proposal that is supposed to merge the concepts. Whatever comes out of it, I am pretty sure it will be interesting.
On Tuesday we have a BOF at 19:30. The OSGi Alliance board has a meeting in the valley and many of them will be present to talk to you. This will be an excellent moment to tell them your ideas, issues, and maybe kudos. Oh yeah, and there will be drinks!
After the OSGi BOF, there will be a Distributed OSGi BOF that I really want to attend. Easy, it will be in the same room. My famous friend Jeff McAffer will have an Equinox/OSGi BOF on Wednesday so you will be able to find me there as well.
There is an overview page with the whole OSGi DevCon program.
I am really looking forward to see you this year at OSGi DevCon/EclipseCon. If there is only one conference you can go to this year, I urge you to pick this one. Don't wait too long with registering. There is a maximum and it is very likely they will reach this maximum this year.
See you all in Santa Clara!
Peter Kriens
Comments
Research Challenges for OSGi
2008-02-21
On my flight back from Berlin this week I listened to a podcast from Software Engineering Radio. They interviewed Dave Thomas (OTI Dave Thomas) and it was a very interesting interview. One of the triggering parts was that Dave mentioned that PhD students often have a hard time finding good research challenges. That made me start thinking what the OSGi research challenges would be. Well, these are the ones I came up with.
The OSGi Framework provides isolation between bundles using a class loader model. This model is quite effective, especially when security is also turned on. However, it is clearly not perfect because we have something called the stale service problem. Bundles in an OSGi platform exchange objects. These objects are linked through their class to a class loader which is closely connected to a specific bundle. What happens when this bundle is started and stopped? Well, the specification tells the other bundles to remove their references to any objects by sending out service notifications. These stale references will exist and hang around because they cannot be garbage collected. Those services refer to the class loader so a single stale reference can pin all the loaded classes of a bundle into memory for as long as it lives.
But the refering bundle can remove any references and everything is ok! So what is the problem? Well, if you really came up with that question I suggest you do some code inspections of open source or in-house software. It is sometimes quite amazing what actually ends up being used. Let's face it, this cleaning up is hard and very error prone.
From a specification point of view we have tried to minimize this problem. The service tracker is a direct result of this effort. After Richard S. Hall and Humberto Cervantes pioneered the Service Binder we added the derived Declarative Services to minimize the complexity of handling this stale service problem. However, from a specification point of view there is no way the problem can be handled full (or fool) proof.
The simple solution is to place bundles in different memory spaces. This can be done with one VM per bundle or a more efficient method is to use isolates from JSR 121. The JSR 121 provides a very attractive model for isolation but is very intrusive for the programming model, just like a multiple process model. Once you go to a different memory space all your calls need to be marshalled. Marshalling is the process that moves the parameter objects over the process/isolate boundary. Isolates provide a very efficient socket like interface between isolates but it still means you need some form of serialization or proxying of all your obejcts that cross the boundary. This tends to be very intrusive for object oriented code. It also adds at least a time penalty that is at least a number of magnitudes over normal method calls. There is obviously also a significant memory penalty running code in multiple processes or isolates.
These penalties are such a pity. Java is a language that pioneered (as far as I know) the concept of security on language level. One of the great promises has always been to run the code from different parties in the same VM and have them protected from each other while collaborating when necessary without cost. I really do believe we have come quite far with a standard VM and adding OSGi brings us tantalizing close to this goal.
Therefore, the first research challenge I post to the research community is to create an OSGi platform that provides the advantage of direct method calls but allows a bundle to be safely stopped and removed from the VM, even if other bundles do not cooperate.
Some OSGi installations can have thousands of bundles. During the booting of the framework, these bundles must be wired so that there imports and exports match up in a consistent and optimal way. This is a task that is on the critical part for startup so performance is at a premium.
Why optimal? Isn't good good enough? Well, no. The hardest part addressed in OSGi frameworks is sharing. Most of the OSGi framework is setting rules about this sharing and enforcing them where possible. However, these rules allow considerable leeway in the solutions that the resolver can use. This is necessary because many correct solutions cause the class space to be split between bundles. That is, one bundle can no longer use the services from another bundle because the packages they use for the service or used classes/interfaces come from different bundles. For example, one bundle uses version 1.0 and the other bundle uses version 2.0. Once this happen, these bundles live in different worlds and can not easily collaborate. The resolver must therefore find solutions where packages are shared as much as possible.
A couple of months ago we had a big discussion about this problem, Thomas Watson (IBM) posted the question if the resolver is an NP-complete problem. We had some very interesting and long conference calls (software engineers love this stuff) and I do not think we found real proof for this statement. However, we clearly all agreed it is a hard nut to crack.
So I pose the second grand OSGi challenge: Provide an OSGi resolver that can resolve a set of bundles in linear time, or prove that this is impossible.
The most attractive property of R4 is clearly the fact that it can support multiple versions of the same package in the same VM. Though one should never design a system with this in mind, it is a life saver when you discover two of your bundles require incompatible versions of the same package. And with today's development model of tens if not hundreds of open source products it is almost guaranteed that you will need it.
To allow bundles to collaborate, packages must be shared. It is therefore very beneficial to maximize the flexibility in imports. This is the reason that one can specify a version range for an import package. This range indicates that this bundle can operate with a set of packages. Great! But, ehh, how does the developer manage this?
Normally, there is only a single version on the classpath during development. Tools like PDE, Maven, or JDT provide no support for adding a version dimension to the classpath. The direct result is that many people compile against the latest version. If they use bnd they automatically get an import statement (provided the exporter is a properly marked up bundle) for this latest version. If this has to be maintained by hand then it is even harder. The developer must intricately be aware of what is using what. Import ranges are really hard to set properly because they explode the number of combinations that must be tested. Trying to do this by hand is painful.
As an aside, I believe life would have been easier if we would have had export ranges because the exporter of a package knows exactly to which version he is compatible, being the responsible person for that package. If he changes a package, he is the one thinking and deciding about backward compatibility. The importer is almost always guessing. That is, if I make a change to a package called p, I can knowingly say that I am package p version 2, but I am completely compatible to version 1 I therefore can export p;[1,2]. In contrast, if I import package p I have no clue if version 1 and 2 will be compatible except for the convention of version number interpretation. Alas, export versions did not make it to R4.
The third challenge is therefore support for import version ranges. How should the development tools be altered to support version ranges in such a way that the resolver has maximum flexibility while the import range presents valid tested configurations.
The cool news with an OSGi framework is that you can run multiple applications on a single VM. The bad news is that you can run multiple applications on a single VM. If you share the VM between applications you run into several issues where you would like to know the identity of one you are doing the work for. Inside an JEE application server this is relatively straightforward because applications run autistically in silos. In OSGi, bundles that make up the applications are shared and call each other through the myriad of callbacks. None of the Java or OSGi concepts (Threads, Code base, Bundles, etc) map really well to this identity problem.
The last research challenge is therefore to come up with an identity concept that can be used for security and resource management in a collaborative environment like OSGi.
So, if there are students that are looking for research challenges then the previous problems should keep them occupied. Some of them are really hard problems that do not have clear solutions. However, solving them will solve real problems and enable further possibilities.
Good Luck! Kind regards,
Peter Kriens
The Stale Service Problem
The OSGi Framework provides isolation between bundles using a class loader model. This model is quite effective, especially when security is also turned on. However, it is clearly not perfect because we have something called the stale service problem. Bundles in an OSGi platform exchange objects. These objects are linked through their class to a class loader which is closely connected to a specific bundle. What happens when this bundle is started and stopped? Well, the specification tells the other bundles to remove their references to any objects by sending out service notifications. These stale references will exist and hang around because they cannot be garbage collected. Those services refer to the class loader so a single stale reference can pin all the loaded classes of a bundle into memory for as long as it lives.
But the refering bundle can remove any references and everything is ok! So what is the problem? Well, if you really came up with that question I suggest you do some code inspections of open source or in-house software. It is sometimes quite amazing what actually ends up being used. Let's face it, this cleaning up is hard and very error prone.
From a specification point of view we have tried to minimize this problem. The service tracker is a direct result of this effort. After Richard S. Hall and Humberto Cervantes pioneered the Service Binder we added the derived Declarative Services to minimize the complexity of handling this stale service problem. However, from a specification point of view there is no way the problem can be handled full (or fool) proof.
The simple solution is to place bundles in different memory spaces. This can be done with one VM per bundle or a more efficient method is to use isolates from JSR 121. The JSR 121 provides a very attractive model for isolation but is very intrusive for the programming model, just like a multiple process model. Once you go to a different memory space all your calls need to be marshalled. Marshalling is the process that moves the parameter objects over the process/isolate boundary. Isolates provide a very efficient socket like interface between isolates but it still means you need some form of serialization or proxying of all your obejcts that cross the boundary. This tends to be very intrusive for object oriented code. It also adds at least a time penalty that is at least a number of magnitudes over normal method calls. There is obviously also a significant memory penalty running code in multiple processes or isolates.
These penalties are such a pity. Java is a language that pioneered (as far as I know) the concept of security on language level. One of the great promises has always been to run the code from different parties in the same VM and have them protected from each other while collaborating when necessary without cost. I really do believe we have come quite far with a standard VM and adding OSGi brings us tantalizing close to this goal.
Therefore, the first research challenge I post to the research community is to create an OSGi platform that provides the advantage of direct method calls but allows a bundle to be safely stopped and removed from the VM, even if other bundles do not cooperate.
OSGi Resolver
Some OSGi installations can have thousands of bundles. During the booting of the framework, these bundles must be wired so that there imports and exports match up in a consistent and optimal way. This is a task that is on the critical part for startup so performance is at a premium.
Why optimal? Isn't good good enough? Well, no. The hardest part addressed in OSGi frameworks is sharing. Most of the OSGi framework is setting rules about this sharing and enforcing them where possible. However, these rules allow considerable leeway in the solutions that the resolver can use. This is necessary because many correct solutions cause the class space to be split between bundles. That is, one bundle can no longer use the services from another bundle because the packages they use for the service or used classes/interfaces come from different bundles. For example, one bundle uses version 1.0 and the other bundle uses version 2.0. Once this happen, these bundles live in different worlds and can not easily collaborate. The resolver must therefore find solutions where packages are shared as much as possible.
A couple of months ago we had a big discussion about this problem, Thomas Watson (IBM) posted the question if the resolver is an NP-complete problem. We had some very interesting and long conference calls (software engineers love this stuff) and I do not think we found real proof for this statement. However, we clearly all agreed it is a hard nut to crack.
So I pose the second grand OSGi challenge: Provide an OSGi resolver that can resolve a set of bundles in linear time, or prove that this is impossible.
Multiple Versions
The most attractive property of R4 is clearly the fact that it can support multiple versions of the same package in the same VM. Though one should never design a system with this in mind, it is a life saver when you discover two of your bundles require incompatible versions of the same package. And with today's development model of tens if not hundreds of open source products it is almost guaranteed that you will need it.
To allow bundles to collaborate, packages must be shared. It is therefore very beneficial to maximize the flexibility in imports. This is the reason that one can specify a version range for an import package. This range indicates that this bundle can operate with a set of packages. Great! But, ehh, how does the developer manage this?
Normally, there is only a single version on the classpath during development. Tools like PDE, Maven, or JDT provide no support for adding a version dimension to the classpath. The direct result is that many people compile against the latest version. If they use bnd they automatically get an import statement (provided the exporter is a properly marked up bundle) for this latest version. If this has to be maintained by hand then it is even harder. The developer must intricately be aware of what is using what. Import ranges are really hard to set properly because they explode the number of combinations that must be tested. Trying to do this by hand is painful.
As an aside, I believe life would have been easier if we would have had export ranges because the exporter of a package knows exactly to which version he is compatible, being the responsible person for that package. If he changes a package, he is the one thinking and deciding about backward compatibility. The importer is almost always guessing. That is, if I make a change to a package called p, I can knowingly say that I am package p version 2, but I am completely compatible to version 1 I therefore can export p;[1,2]. In contrast, if I import package p I have no clue if version 1 and 2 will be compatible except for the convention of version number interpretation. Alas, export versions did not make it to R4.
The third challenge is therefore support for import version ranges. How should the development tools be altered to support version ranges in such a way that the resolver has maximum flexibility while the import range presents valid tested configurations.
Application Identity
The cool news with an OSGi framework is that you can run multiple applications on a single VM. The bad news is that you can run multiple applications on a single VM. If you share the VM between applications you run into several issues where you would like to know the identity of one you are doing the work for. Inside an JEE application server this is relatively straightforward because applications run autistically in silos. In OSGi, bundles that make up the applications are shared and call each other through the myriad of callbacks. None of the Java or OSGi concepts (Threads, Code base, Bundles, etc) map really well to this identity problem.
The last research challenge is therefore to come up with an identity concept that can be used for security and resource management in a collaborative environment like OSGi.
Conclusion
So, if there are students that are looking for research challenges then the previous problems should keep them occupied. Some of them are really hard problems that do not have clear solutions. However, solving them will solve real problems and enable further possibilities.
Good Luck! Kind regards,
Peter Kriens
| Previous Posts | Archives |
|---|---|
1. The PKI in Chapter 2 should have been removed;
2. The terminology "framework" is misleading, why not use "OSGi container" instead?
I do not think OSGi has PKI in its specifications, it only uses certificates because this model is very important for our security model; a requirement that many of our users have. However, it does not mandate a specific infrastructure, we tried to allow as much flexibility as possible.
What is in a name? I do not like the word container because, today, it implies a silo model like JEE. OSGi is much more collaborative. We tried to make a specification that is as policy free as possible and the policies are implemented as bundles. I think this model captured rather nicely by the word framework; a skeleton where others provide the flesh.
But I am interested to hear what your arguments are.
Kind regards,
Peter Kriens