Hello Bram, On Sep 29, 2011, at 11:13 AM, Bram de Kruijff wrote:
> 2 cents.. > > 2011/9/29 Marcel Offermans <[email protected]>: >> There are two issues related to multi-tenancy I want to discuss: >> 1) The current multi-tenancy development model is too invasive for >> developers. Everything must become a factory, and worse, it's impossible to >> use 99% of all existing OSGi services because they don't support this model. >> I think it ultimately hurts adoption of Amdatu, because you can't just use >> OSGi. > > I agree that the current model is too invasive and brittle. Ideally an > amdatu application developer should not be concerned with > multi-tenancy at all. In previous discussions and milestone > definitions I believe we have used "restoring the programming model". > There have bee mentions of smart base activators or dependency manager > constructs that could help out. However, such solution are still too > invasive for the second part your second point. How to manage "amdatu > unaware" implementations in a multi-tenant model... Agreed. >> 2) Multi-tenancy should be optional. That means that all services should >> operate as "normal" services when there are no tenants around and only start >> supporting tenants when the appropriate tenant bundles are installed. > > What s wrong with a "Default Tenant" approach? What's wrong with it is mainly the first point: the current model being too invasive, which means that most, if not all third party bundles need to be modified to work with it. > My concerns is all kinds of implementations popping up that can not handle > multi tenancy > and it will be choas. Well, you can also argue the other way round and say that if you don't want to use *this* multi tenancy model at all, why needlessly complicate your implementation by having to implement it anyway. > However, given a full solution to point 1 we > have no argument. The application developer and 3rd party code) should > be unaware and thus not care ;) To make this model less invasive we could at least consider implementing the bundles we have now in such a way that you can use an "unaware" version if you want and use some kind of wrapper or multi tenant aware one if you do want to use this model. >> I understand that the current model is used, so we cannot just "throw it >> away". It is probably a good model if you have a lot of tenants on a single >> machine (>100). By making it optional we ensure it's not in people's way if >> they don't need it. >> At the same time, I would like to add a second model that is based on >> separate OSGi containers, giving a more natural isolation and a model that >> is identical to "normal" OSGi application development. My gut feeling is > > In the end I think a multi container is the only way to properly > address point 1 (and more concerns) as we illustrated before in some > conceptual implementation models [2] a while back. Agreed, multiple separate containers where we can use some form of remoting to publish services that are to be shared between containers. >> that on average hardware this will still scale to about 100 instances per >> computer. > > Previous art [2] shows about 500 nested containers (with a few small > bundles each) on Xmx256M/default permgen with a 32bit java. Obviously, > the real measure will depend on the type of multi container model This makes me wonder why we don't move to this model completely. :) >> Before we go into technical details, I'd like your feedback on these ideas >> in general. > > +1 on the goals. Summarizing, I hope we can agree that: a) ultimately, a multi-container model is what we aim for b) for now, we need to carefully plan a migration strategy Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
