On Sun, Nov 13, 2011 at 19:11, mikevan <[email protected]> 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? > If you mean felix, as a framework, that does not seem right to me. The framework only implements the minimal set of spec (Core). All other parts of the OSGi specs are implemented by other felix subprojects (COnfigAdmin, EventAdmin, etc...) or Aries (Blueprint, JPA, JMX ...). Actually, why would we care about where this implementation comes from ? And I don't think Karaf is trying to implement Subsystem, just leverage the implementation from Aries. > > 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. > Equinox is not the subsystem RI afaik, it is developped in Aries. > 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. > Supporting isolation using regions does not mean forcing to use them, as David explained, it's just about adding the possibility for a user to deploy a feature into a know region. > > ----- > 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. > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
