The OSGi specificati
2006-01-08
The OSGi specification process is surprisingly civilized. In most cases we find a solution that everybody can live with. However, during the R4 specification, there was one aspect that caused a lot of discussion. The final solution was what all committees do: we made it optional.
I am talking about Require-Bundle. The Require-Bundle header directly links one bundle to another. If bundle A requires bundle B, then A can only run when B is present. You might be surprised that there was any opposition against this concept at all; this is the way modules have been linked since the dawn of computing. So what is good enough for our predecessors, why would it not be good enough for us?
The opposition was led by the people that had extensive experience with earlier OSGi releases. In the original specifications we only linked by packages. A bundle could require a package, but it could not decide the provider of this package. The packaging of the packages in the bundles is therefore not constrained. However, why is it important to not constrain the packaging? This is best explained by an example that shows where you run into problems by requiring bundles.
Initially you deliver a large subsystem as a single bundle. All your application bundles, out of convenience, require this BIG bundle. Normally, most application bundles only use a fraction of this big bundle. One day you realize that this bundle has grown a bit too big and decide to split it into two smaller bundles. You now effectively orphaned all the application bundles out there because there required bundle no longer exists. It is normally extremely difficult to update existing, deployed, bundles, if at all possible. Basically, when this happens you have something to explain to your boss.
The standard OSGi solution is to link bundles through packages with manifest headers. Packages are the minimum granularity because classes in a package should be highly cohesive. If they are not highly interconnected or dependent, they should not be in the same package. Linking packages significantly simplifies the deployment of bundles. The grouping of packages is no longer important; all links are constructed from the package names and versions. This gives you substitutability; any bundle can now provide key packages. The Framework will
Suddenly you can surprise your boss with all these new options!
So if package linking is so obviously advantageous, why on earth did we add Require-Bundle? The key reason is that Require-Bundle is conceptually more familiar and easier to use. The big disadvantage of package binding is that it requires calculating the list of imported packages, which can be a long list in big legacy applications. The argument that this list can be fully calculated because all information is in the class file was not deemed strong enough.
So, use import and export package and not require bundle. Do not be tempted with the conceptual simplicity because you will pay the price later.
Peter Kriens
OSGi Evangelist
I am talking about Require-Bundle. The Require-Bundle header directly links one bundle to another. If bundle A requires bundle B, then A can only run when B is present. You might be surprised that there was any opposition against this concept at all; this is the way modules have been linked since the dawn of computing. So what is good enough for our predecessors, why would it not be good enough for us?
The opposition was led by the people that had extensive experience with earlier OSGi releases. In the original specifications we only linked by packages. A bundle could require a package, but it could not decide the provider of this package. The packaging of the packages in the bundles is therefore not constrained. However, why is it important to not constrain the packaging? This is best explained by an example that shows where you run into problems by requiring bundles.
Initially you deliver a large subsystem as a single bundle. All your application bundles, out of convenience, require this BIG bundle. Normally, most application bundles only use a fraction of this big bundle. One day you realize that this bundle has grown a bit too big and decide to split it into two smaller bundles. You now effectively orphaned all the application bundles out there because there required bundle no longer exists. It is normally extremely difficult to update existing, deployed, bundles, if at all possible. Basically, when this happens you have something to explain to your boss.
The standard OSGi solution is to link bundles through packages with manifest headers. Packages are the minimum granularity because classes in a package should be highly cohesive. If they are not highly interconnected or dependent, they should not be in the same package. Linking packages significantly simplifies the deployment of bundles. The grouping of packages is no longer important; all links are constructed from the package names and versions. This gives you substitutability; any bundle can now provide key packages. The Framework will
Suddenly you can surprise your boss with all these new options!
So if package linking is so obviously advantageous, why on earth did we add Require-Bundle? The key reason is that Require-Bundle is conceptually more familiar and easier to use. The big disadvantage of package binding is that it requires calculating the list of imported packages, which can be a long list in big legacy applications. The argument that this list can be fully calculated because all information is in the class file was not deemed strong enough.
So, use import and export package and not require bundle. Do not be tempted with the conceptual simplicity because you will pay the price later.
Peter Kriens
OSGi Evangelist
Add a comment