Hi Felix, On 3 September 2014 05:04, Felix Meschberger <[email protected]> wrote: > Hi > > Am 01.09.2014 um 01:07 schrieb David Bosschaert <[email protected]>: > >> On 30 August 2014 08:36, Felix Meschberger <[email protected]> wrote: >>> 2. OSGi Platform services have to be adapted as well. Particularly nasty >>> probably are things like SCR and Blueprint which manage objects on behalf >>> of bundles and must thus be knowledgeable of that situation maybe also by >>> virtue of the MultieTenantActivator and the BundleContext wrappers. >> >> >> Yes, I think in any kind of approach here platform services must be >> aware of the multi-tenancy. One of the things that I have been >> thinking about is to make OSGi Subsystems fully multi-tenant capable. >> It still means that the platform services have to be 'subsystem-aware' >> but at least this limits the awareness to one tenant-support API >> instead of having to understand many different types of multi-tenant >> solutions. Depending on your use case, today's OSGi Subsystems might >> already be good enough. > > Would that mean we would have a subsystem per tenant ? > > If so, considering we have, say, 50 bundles to be made > „multi-tenant-supporting“, it would mean would multiply 50 bundles by X > tenants. So for 100 tenants we would have 100 subsystems with a total of 5000 > bundles and class loaders ? Can/does that really scale ? I am scared.
I think it would mean a subsystem per tenant, but that subsystem may not contain much code. With OSGi subsystems you can share code from your parent subsystem. How much is shared is completely configurable (with Composite Subsystems). Typically a subsystem would contain at least one bundle but that bundle might just handle some configuration and import the rest from its parent subsystem, if the code is all shared. No need to be scared about that just yet ;) > On the other hand, if tenants have differing sets of bundles, I agree that it > might make sense to have subsystems per tenant. But this is another topic of > multi tenancy, which involves resource allocation which we cannot handle in > standard JVMs yet. > > Or, I may be completely off track ... Bottom line is that this kind of setup hasn't really been tried much yet AFAIK. I think subsystems can help here because of the fact that they are standardized so that services such as EventAdmin/ConfigAdmin if they are 'Subsystem Aware' can be re-used. It might be useful to do a little experiment to see how well this would work, but I think it should certainly not mean large amounts of duplicated code :) Cheers, David
