The subsystem spec is part of the Service Platform early draft 4.3. From my research, it appears that a service platform is what we would think of as an OSGi framework (felix, equinox, and knoplerfish), not an OSGi container (Karaf, Virgo Kernel). With this in mind, shouldn't felix be implementing the subsystem spec instead of Karaf?
In practice, there are a few weaknesses with the subsystem spec. If we look at the OSGi subsystem reference implementation (equinox), we can see some problems that may be part of the subsystem spec when it is revised. 1) In Equinox, which uses a subsystem provisioning mechanism, either the scope of a subsystem is closed or open. You can either share everything, or nothing. In a closed subsystem, I believe that sharing of packages within the subsystem is done via service references. In Karaf, we use a features provisioning mechanism that shares everying in a bundles Export-Package section. In an open subsystem, everything that is in your subsystem's bundles' Export-Package section is shareable, similar to how a features provisioning mechanism works. Shouldn't there be some sort of way to expose specific packages in a closed subsystem without wrapping them up as services? 2) In a features provisioning mechanism, you can use "cascading" features, ie features composed of features. This is a very powerful tool, especially when you consider that in operational environments, you may want to place slower features in thier own karaf instances and then create multiple instances of that karaf instance in order to increase the performance of your application. Consider this use case: You have an application composed of 30 modules, each with their own unique features provisioning file. In your parent features document, you reference each of the 30 modules' features files, and then deploy each of the features. Now, one of your 30 modules uses a file-based caching mechanism, and the file IO required is determined to be a bottleneck. Using a features provisioning mechanism, you can remove this feature from your application, deploy it alone into another karaf instance, and then increase the number of this karaf instance in order to remove the bottleneck. This isn't possible with the subsystem provisioning mechanism identified in the subsystem specification. Instead, you would have 30 subsystem "plans" (as they are called in Virgo), and you would need to deploy each one individually instead of "cascading" them into a master provisioning document. Now, this may seem like a non-issue, but what if you have multiple cascading layers of your provisioning files? Say your provisioning files cascades up to 4 layers deep? This becomes very complicated to manage in a subsystem provisioning environment, but is fairly straightforward in a features provisioning environment. Ok, so that was probably clear as mud, and I'd be happy to clarify it if anyone wants me to do so. My conclusions? Our features mechanism is very powerful and it would be a mistake to replace it with a subsystem mechanism. Additionally, Karaf should not be implementing the subsystem provisioning system. Instead, karaf should be leveraging the subsystem implementation used by the underlying service platform (eg. felix, equinox, et. al.). If Felix implements the subsystem spec, then karaf would modify the features provisioning mechanism to allow features to be closed or open, and to assume that all features are open subsystems. Additionally, Karaf's features implementation would allow for the continuation of cascading features. ----- Mike Van (All links open in new tabs) Committer - Kalumet Atraxia Technologies NCI Inc Mike Van's Open Source Technologies Blog -- View this message in context: http://karaf.922171.n3.nabble.com/Isolation-support-in-karaf-tp3503578p3504986.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
