Hi List, some open questions to revive this topic as I forsee this will become quite relevant soon. I propose to have a discussion about it next wednesday:
1) At what service level do we want to support QoS, what kind of apsects and how could this be achieved? 2) What kind of level of isolation do we want to support? How could we enforce security and isolation within a container? 3) How aware should an application developer be of the multi tenancy constructs? Should it not be container managed? Regards, Bram 2010/11/11 Marcel Offermans <marcel.offermans at luminis.nl>: > Hello Koos, > On 10 Nov 2010, at 11:18 , Koos Gadellaa wrote: > > I definitely see the uses of those two points. > Regarding point two, this can already be realized. Say I've got a supercool > payed-per-use service, which is tenant-aware. The supercool service then by > itself can bill the tenant according to a payment plan which was chosen by > the tenant. > > Agreed, but regarding the "quality of service" we do not yet have mechanisms > to group tenants together that have similar qualities of service, isolating > ones with a higher one, etc. But, I agree, we probably have the mechanisms > in place to do that in the future. > > I haven't followed the tenant-discussion yet, but one thing did leave me > wondering: > How do we ensure security and proper tenant-use. > Assuming we have tenant A and tenant B, each having different applications, > and using different components. > 1) how do we ensure that tenant A only uses those components of Amdatu to > which he is privileged? (say he's not allowed to use the cassandrastore, or > some expensive service) > 2) how do we ensure that tenant A cannot access any of tenant B's > components? > 3) how do we ensure that tenant A doesn't write aspects on > platform-components which are used by other tenants? (say, tenant A writes > an aspect for the amdatu-login service. Tenant A has now access to all > user/password information which is passed to this service, from whichever > tenant. Or maybe he'd like to ensure that users who start with ING get login > errors) > > Right now, we do not use any form of security in our OSGi container, so we > "trust" all code that is running. However, there is no reason why we could > not enable OSGi security. This would help us solve some of the issues you > mention at the cost of increasing complexity (setting up security is not > really easy, it would take us considerable time). > > As an aside: Should tenant-code be written such that it is tenant-aware? Why > should it? > Ideally I'd like to write code which uses services, and has no idea if these > services are tenant-aware :) > > Well, you can definitely write your service implementations (POJOs) in such > a way that they're not tenant-aware [1], but something in the system should > be aware of tenants and the process of creating service dependencies would > be one of those things. > [1] You would need to setup your dependencies a bit different if you want to > do that because obviously you would not want your POJO to contain that > init() method it currently has to setup its own dependencies. There are > options however to move that specific piece of code to a "callback handler" > that receives callbacks for components and sets up their dependencies. I can > provide an example of that if you're interested. > Greetings, Marcel > > > Regards, > Koos > > > > On 9 nov 2010, at 10:20, Marcel Offermans wrote: > > I'm not quite sure if we're doing multi tenancy the right way yet. I'm still > considering a couple of alternatives here: > > 1) Running each tenant in its own OSGi container. This does not imply each > OSGi container actually runs in its own JVM, as it's easy to create a single > JVM that runs multiple, isolated containers. Advantages of this system would > be mostly a vastly simplified programming model as you don't need to worry > about tenants in your application. If services would need to be shared > between tenants, we could use remote services to "deploy them to each > container". > > 2) Using a notion of a tenant that is a bit more abstract, where each tenant > (or customer) gets not only simply isolation but also a specific quality of > service linked to that tenant. Paul Fremantle talks about this in his > ApacheCon presentation on "building cloud native software" (see > http://pzf.fremantle.org/2010/11/building-cloud-native-software.html) where > he discusses the merits of having "coach, business and private jet" service > levels. > > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > Beste, > > > Met vriendelijke groeten, > > Koos Gadellaa | Software Engineer > +31 6 317 658 01 > > My world is: ever expanding > > Luminis KIS B.V. > Prins Willem Alexanderlaan 715 > 7311 ST??Apeldoorn > +31 88 586 46 25 > > http://kis.luminis.eu > http://www.luminis.eu > > KvK (CoC) 09 14 31 09 > BTW (VAT) NL8135.18.556.B.01 > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > >
