> Regarding the context; if we do not store context information in a Thread > local variable and we do not want to pass around contextual properties in > each method invocation; how would you determine contextual information? I > discussed the Thread local stuff with Mark and Bram last week, but there just > isn't an alternative. Any BLOG you read about Thread locals being so evil > doesn't come with an alternative, or comes up with an alternative which in > the end still uses Thread locals in its heart. So what would you suggest?
This: >> If a service is tenant unaware but it has dependencies on tenant aware >> services, you have just made it tenant aware by definition. So if you start deploying multiple tenants in a single container, then there is no such thing as a service that is not tenant aware that has a dependency on a service that is. I do not understand what you mean. In the current implementation, I need to specifically define tenant service properties on the service dependency to get the proper tenant-aware service injected. If I don't, I will get any service injected; which one it will be is arbitrary. If I have two of such service dependencies, I might even get two services injected with two different tenants. How does that make my service tenant aware? Furthermore, this is not an alternative for context resolving. It could be a possible (partial) solution in the case of tenants, but the tenant is only a small piece of the actual context. A context will typically include the name of the (logged in) user that send the request for example. Services need this username for authorization checks or return user-dependent information. How would you resolve that? Introduce user-aware services? Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: maandag 3 januari 2011 13:24 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Multi-tenancy (and more) design On Jan 3, 2011, at 12:53 , Ivo Ladage-van Doorn wrote: > My biggest concern is that if we now choose that one OSGi container can only > host one tenant, there is no way back. I'm not saying that that is the only way. I'm just stating that for many of Amdatu's customers, that are developing OSGi applications without ever wanting to worry about multi tenancy, the programming model of one container per tenant will be a lot simpler. > If we follow that path we will not design Amdatu to be tenant aware in its > core, as there is always only one tenant hosted by the container. If for any > reason (including the ones we do not oversee right now) we come to the > conclusion that this was not a good choice later on, it will be quite a > challenge to fix it. If on the other hand we design Amdatu in its core to > deal with the fact that one container may host multiple tenants, we can have > it both ways. I'm fine with designing components to be multi tenant aware, if appropriate. > One of the use cases in which 1 tenant per container could be an issue is a > customer we developed a solution for last year. The customer I'm talking > about is an 'umbrella organization' for the catering industry. The > organization provides services to catering entrepreneurs. One of those > services is the hosting of their (basic and internal) website. Each > entrepreneur may request such a website and will be provided with logins for > he and his employees. The entrepreneur can provide a logo, add some text, > define open and close times, etc. > Such an entrepreneur is a good example of a tenant. Is it? A logo, some text and some logins sounds so simple that it's probably easier to just hardcode those differences into the implementation and indeed deploy it as a single application. However, I seriously wonder if Amdatu is targetted at applications this simple. > There would be a lot of overhead starting separate containers for each tenant > and remoting service calls as opposed to just one container with a few tenant > aware services. Also managing (provisioning, updating) 1 container instead of > 5000 seems much easier, faster and less error-prone to me. Provisioning and updating would be automated anyway, so that does not matter. If you deploy each tenant in its own container, I see no point at all in using remote services for this case. The logo's, texts and a few users are probably best deployed to each individual container instead of using for example a centralized User Admin service. > Regarding the context; if we do not store context information in a Thread > local variable and we do not want to pass around contextual properties in > each method invocation; how would you determine contextual information? I > discussed the Thread local stuff with Mark and Bram last week, but there just > isn't an alternative. Any BLOG you read about Thread locals being so evil > doesn't come with an alternative, or comes up with an alternative which in > the end still uses Thread locals in its heart. So what would you suggest? This: >> If a service is tenant unaware but it has dependencies on tenant aware >> services, you have just made it tenant aware by definition. So if you start deploying multiple tenants in a single container, then there is no such thing as a service that is not tenant aware that has a dependency on a service that is. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
