HI Kishanthan, This is indeed a very helpful to have, one advantage I would see is we can let the tenants to have deployed their own Authenticators, UserStoreManagers and various other extensions without interfering the system. But how would be expose a Core service such as RealmService or RegistryService ?
For example, each tenant will want to access their RealmService to load their configured user-store in their custom Authenticator. How would we make sure the RealmService would return only that tenant's RealmService or it's corresponding user store manager ? Thanks, -Suresh On Thu, May 8, 2014 at 2:45 PM, Kishanthan Thangarajah <[email protected]>wrote: > This is one of the core areas of C5 kernel. In previous carbon versions, > the multi-tenancy aspect was limited to run-time execution only. In there, > we used the Axis2 Configuration & Context model to achieve the > multi-tenancy where each tenant got its own execution space during > run-time. But the OSGi environment was not partitioned for tenants and was > visible to all, where a bundle (the library and its packages) installed by > a tenant was visible to other tenants as well. > > The idea here is to implement Multi-Tenancy at OSGi framework level also, > so that each tenant gets its totally isolated run-time environment. We are > planning to use OSGi "Regions" [1] concept to achieve this with the usage > of OSGi framework hooks. A region is a grouping of bundles in an OSGi > run-time, which is governed by controls when accessing resources (packages, > services) from other regions. > > Each tenant gets its own region and there will be a separate "Kernel" > region where the core bundles/packages/service resides and will be exposed > to tenant regions. We can still limit/decide on what to expose from kernel > region. Each tenant region will be isolated from each other. They will not > see any events (related to bundle, service) or package visibility from > other regions, but only see from it self and kernel. Below image is high > level view of this concept. > > [image: Inline image 1] > > An overview of the framework hooks. > > *RegionResolverHook* - manages the package resolve process for > requirements from bundles in regions. > *RegionBundleFindHook* - manages/filters the BundleContext.getBundle > lookups from region bundles. > *RegionBundleEventHook* - manages/filters the bundle's life-cycle events > for regions. > *RegionBundleCollisionHook* - manages the duplicate bundle resolving in > multiple regions. This will facilitate to have same bundles in different > regions. > *RegionServiceFindHook* and *RegionServiceEventHook* - manages/filters > the service lookup and life-cycle events for regions. > > Thoughts suggestions are welcome. > > Thanks, > Kishanthan. > [1] http://wiki.eclipse.org/Virgo/Concepts#Regions > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Suresh Attanayake Senior Software Engineer; WSO2 Inc. http://wso2.com/ Blog : http://sureshatt.blogspot.com/ Web : http://www.ssoarcade.com/ Facebook : https://www.facebook.com/IdentityWorld Twitter : https://twitter.com/sureshatt LinkedIn : http://lk.linkedin.com/in/sureshatt Mobile : +94755012060 Mobile : +016166171172
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
