Hi Marcel On Tue, Oct 4, 2011 at 2:40 PM, Marcel Offermans <[email protected]> wrote: > 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
yup > b) for now, we need to carefully plan a migration strategy I have no clue how to do this (make it optional) in a non multi-container model. Do you have an idea? On the bright side any code now using the mt adaptor pattern should work transparently in a multi-container as long as we make sure the correct (and only) Tenant service is published. grz Bram > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
