Re: [Architecture] [C5] OSGi Multi-Tenancy

[Samisa Abeysinghe]

On Mon, Jun 16, 2014 at 9:29 PM, Kishanthan Thangarajah  wrote:

>
>
>
> On Mon, Jun 16, 2014 at 5:59 PM, Samisa Abeysinghe 
> wrote:
>
>> So we have both of:
>> - a tenant having specific bundles only available to that tenant
>>  - a bundle available for multiple tenants, where the respective
>> tenant's use of the bundle is tenant aware
>>
>
> Yes, but the latter will only be available for kernel region (core)
> bundles.
>

​Yah, fair enough!
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Kishanthan Thangarajah]

On Mon, Jun 16, 2014 at 5:59 PM, Samisa Abeysinghe  wrote:

> So we have both of:
> - a tenant having specific bundles only available to that tenant
>  - a bundle available for multiple tenants, where the respective
> tenant's use of the bundle is tenant aware
>

Yes, but the latter will only be available for kernel region (core) bundles.

>
> am I right?
>
>
> Thanks,
> Samisa...
>
>
> Samisa Abeysinghe
>
> Vice President Delivery
>
> WSO2 Inc.
> http://wso2.com
>
>
>
> On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>>
>> On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:
>>
>>> Hi Kishanthan,
>>>
>>> A useful feature indeed, does this mean a tenant can install bundle for
>>> his own space ?
>>>
>>
>> Yes, each tenant will have a separate space (Region) and they can install
>> bundles on to it. Other tenants will not be aware of this (bundle and
>> service life-cycle events will be filtered) and cannot access those bundles
>> (import package requirements will be filtered) .
>>
>> Also a bundle, with same symbolic name and version, can be installed on
>> multiple tenant regions. This is handled using the BundleCollsionHook.
>>
>>>
>>> Regards,
>>> /Nuwan
>>>
>>>
>>> On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka 
>>> wrote:
>>>
 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 <
 kishant...@wso2.com> 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
> *
> Twitter - *http://twitter.com/kishanthan
> *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>>

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Samisa Abeysinghe]

So we have both of:
- a tenant having specific bundles only available to that tenant
- a bundle available for multiple tenants, where the respective
tenant's use of the bundle is tenant aware

am I right?


Thanks,
Samisa...


Samisa Abeysinghe

Vice President Delivery

WSO2 Inc.
http://wso2.com



On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah  wrote:

>
>
>
> On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:
>
>> Hi Kishanthan,
>>
>> A useful feature indeed, does this mean a tenant can install bundle for
>> his own space ?
>>
>
> Yes, each tenant will have a separate space (Region) and they can install
> bundles on to it. Other tenants will not be aware of this (bundle and
> service life-cycle events will be filtered) and cannot access those bundles
> (import package requirements will be filtered) .
>
> Also a bundle, with same symbolic name and version, can be installed on
> multiple tenant regions. This is handled using the BundleCollsionHook.
>
>>
>> Regards,
>> /Nuwan
>>
>>
>> On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka 
>> wrote:
>>
>>> 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 <
>>> kishant...@wso2.com> 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
 *
 Twitter - *http://twitter.com/kishanthan
 *

 ___
 Architecture mailing list
 Architecture@wso2.org
 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
>>> Mobi

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Kishanthan Thangarajah]

Hi Srinath,

Shall we have a review on this next week?

Thanks,
Kishanthan.


On Tue, May 13, 2014 at 10:24 AM, Srinath Perera  wrote:

> Ok, let me know when ready
>
>
> On Sat, May 10, 2014 at 12:25 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>> On Fri, May 9, 2014 at 10:46 AM, Srinath Perera  wrote:
>>
>>> Do we need a review?
>>>
>>
>> Yes, we need. I'm currently doing a POC for the above (with all the
>> framework hooks). So let's have a review once its done.
>>
>> Thanks,
>> Kishanthan.
>>
>>>
>>>
>>> On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>



 On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:

> Hi Kishanthan,
>
> A useful feature indeed, does this mean a tenant can install bundle
> for his own space ?
>

 Yes, each tenant will have a separate space (Region) and they can
 install bundles on to it. Other tenants will not be aware of this (bundle
 and service life-cycle events will be filtered) and cannot access those
 bundles (import package requirements will be filtered) .

 Also a bundle, with same symbolic name and version, can be installed on
 multiple tenant regions. This is handled using the BundleCollsionHook.

>
> Regards,
> /Nuwan
>
>
> On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka 
> wrote:
>
>> 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 <
>> kishant...@wso2.com> 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://ki

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Srinath Perera]

Ok, let me know when ready


On Sat, May 10, 2014 at 12:25 AM, Kishanthan Thangarajah <
kishant...@wso2.com> wrote:

>
>
> On Fri, May 9, 2014 at 10:46 AM, Srinath Perera  wrote:
>
>> Do we need a review?
>>
>
> Yes, we need. I'm currently doing a POC for the above (with all the
> framework hooks). So let's have a review once its done.
>
> Thanks,
> Kishanthan.
>
>>
>>
>> On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>>
>>> On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:
>>>
 Hi Kishanthan,

 A useful feature indeed, does this mean a tenant can install bundle for
 his own space ?

>>>
>>> Yes, each tenant will have a separate space (Region) and they can
>>> install bundles on to it. Other tenants will not be aware of this (bundle
>>> and service life-cycle events will be filtered) and cannot access those
>>> bundles (import package requirements will be filtered) .
>>>
>>> Also a bundle, with same symbolic name and version, can be installed on
>>> multiple tenant regions. This is handled using the BundleCollsionHook.
>>>

 Regards,
 /Nuwan


 On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka wrote:

> 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 <
> kishant...@wso2.com> 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
>> *
>> Twitter - *http://twitter.com/kishanthan
>> *
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Kishanthan Thangarajah]

On Fri, May 9, 2014 at 10:46 AM, Srinath Perera  wrote:

> Do we need a review?
>

Yes, we need. I'm currently doing a POC for the above (with all the
framework hooks). So let's have a review once its done.

Thanks,
Kishanthan.

>
>
> On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>>
>> On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:
>>
>>> Hi Kishanthan,
>>>
>>> A useful feature indeed, does this mean a tenant can install bundle for
>>> his own space ?
>>>
>>
>> Yes, each tenant will have a separate space (Region) and they can install
>> bundles on to it. Other tenants will not be aware of this (bundle and
>> service life-cycle events will be filtered) and cannot access those bundles
>> (import package requirements will be filtered) .
>>
>> Also a bundle, with same symbolic name and version, can be installed on
>> multiple tenant regions. This is handled using the BundleCollsionHook.
>>
>>>
>>> Regards,
>>> /Nuwan
>>>
>>>
>>> On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka wrote:
>>>
 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 <
 kishant...@wso2.com> 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
> *
> Twitter - *http://twitter.com/kishanthan
> *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> 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 : h

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Srinath Perera]

Do we need a review?


On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah  wrote:

>
>
>
> On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:
>
>> Hi Kishanthan,
>>
>> A useful feature indeed, does this mean a tenant can install bundle for
>> his own space ?
>>
>
> Yes, each tenant will have a separate space (Region) and they can install
> bundles on to it. Other tenants will not be aware of this (bundle and
> service life-cycle events will be filtered) and cannot access those bundles
> (import package requirements will be filtered) .
>
> Also a bundle, with same symbolic name and version, can be installed on
> multiple tenant regions. This is handled using the BundleCollsionHook.
>
>>
>> Regards,
>> /Nuwan
>>
>>
>> On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka wrote:
>>
>>> 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 <
>>> kishant...@wso2.com> 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
 *
 Twitter - *http://twitter.com/kishanthan
 *

 ___
 Architecture mailing list
 Architecture@wso2.org
 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
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>>
>> *Thanks & Regards,*
>> * Nuwan Bandara 

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Kishanthan Thangarajah]

On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara  wrote:

> Hi Kishanthan,
>
> A useful feature indeed, does this mean a tenant can install bundle for
> his own space ?
>

Yes, each tenant will have a separate space (Region) and they can install
bundles on to it. Other tenants will not be aware of this (bundle and
service life-cycle events will be filtered) and cannot access those bundles
(import package requirements will be filtered) .

Also a bundle, with same symbolic name and version, can be installed on
multiple tenant regions. This is handled using the BundleCollsionHook.

>
> Regards,
> /Nuwan
>
>
> On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka  wrote:
>
>> 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 <
>> kishant...@wso2.com> 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
>>> *
>>> Twitter - *http://twitter.com/kishanthan
>>> *
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> 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
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
>
> *Thanks & Regards,*
> * Nuwan Bandara | Senior Technical Lead - Solutions Architecture,  WSO2
> Inc.+1 812.606.7390 <%2B1%20812.606.7390> | +1 650.745.4499 Ext 4210
> <%2B1%20650.745.4499%20Ext%204210> | http://nuwanbando.com
>   * 

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Kishanthan Thangarajah]

On Thu, May 8, 2014 at 3:05 PM, Suresh Attanayaka  wrote:

> 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 ?
>

Kernel region will consist of collection of kernel (core) bundles. We may
decide and expose some core services from this region for usage in tenant
regions. So in this context, we can think Realm or Registry services as
OSGi services exposed from kernel region.

>
> 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 ?
>

This is where the usage of CarbonContext comes in. When a tenant is trying
to access a resource, the access context should be of the tenant who is
trying to access it. This will make sure that we return the correct
resource for the tenant.


>
> Thanks,
> -Suresh
>
>
> On Thu, May 8, 2014 at 2:45 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> 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
>> *
>> Twitter - *http://twitter.com/kishanthan *
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Kishanthan Thangarajah*
Senior Software Engineer,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com *
Twitter - *http://twitter.com/kishanthan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Nuwan Bandara]

Hi Kishanthan,

A useful feature indeed, does this mean a tenant can install bundle for his
own space ?

Regards,
/Nuwan


On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka  wrote:

> 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 <
> kishant...@wso2.com> 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
>> *
>> Twitter - *http://twitter.com/kishanthan *
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 


*Thanks & Regards,*
* Nuwan Bandara | Senior Technical Lead - Solutions Architecture,  WSO2
Inc.+1 812.606.7390 | +1 650.745.4499 Ext 4210 | http://nuwanbando.com
 * 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] OSGi Multi-Tenancy

[Suresh Attanayaka]

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
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 *
> Twitter - *http://twitter.com/kishanthan *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [C5] OSGi Multi-Tenancy

[Kishanthan Thangarajah]

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 *
Twitter - *http://twitter.com/kishanthan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture