Mike, The subsystem RI is being developed in aries. I'm not proposing that karaf implement subsystems; I think it can use the aries subsystem implementation when it is available.
There are a lot of inputs to the subsystem spec, including karaf features. I'm not very familiar with the equinox provisioning model but from your description I don't think it relates very closely to the public subsystem draft, and it certainly doesn't to the current private draft. It's going to be a while before an actual subsystems implementation is available, and I'm not convinced it will offer sufficient flexibility for what most users will want to do. So I'm proposing we consider an isolation solution that although hard to configure is very general, likely to be compatible with subsystems when they are available, and available now. thanks david jencks On Nov 13, 2011, at 11:11 AM, mikevan wrote: > 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.
