Hi Ivo, Good points, thanks. Please feel free to add things on the wiki. I'm on mobile atm so just two quicks notes:
I would not call the management server the provisioning server as provisioning is only part of its responsibilities. On the other hand I do like the notion of "provisioning a tenant onto a node"! The data sharing use case I would aproach as a data (web) service. Either owned by one or even 3rd party. This removes the data sharing at the platform level requirement, which I fear would be a swamp of complexity. At the same time it opens up the data for reuse for any consumer on the web, so its much more RESTfull. Enjoy the weekend! Regards, Bram On Dec 10, 2010 2:57 PM, "Ivo Ladage-van Doorn" < Ivo.Ladage-vanDoorn at gxsoftware.com> wrote: > Hi Bram, > > I think this is a good starting point for the multi-tenancy discussion. And of course I have some remarks/additions: > > Configuration, Management - I would think that the application should support configuration per tenant. For example, if one tenant decides to reduce the session timeout to 5 minutes, it should not affect the other tenants. Some configuration on the other hand might be shared among all tenants hosted by the same application and if so, should be read-only to them as changing it would affect other tenants. > Regarding management; I think tenant management should be separated from the Amdatu runtime and managed by the provisioning server. The provisioning server needs to be tenant aware, as it should decide what tenants run on what nodes and if tenants run in isolates OSGi containers and/or VMs (dependent on their contract for example; gold contract = isolated container and VM). As a consequence a Tenant in the Amdatu runtime is read-only; it is managed by the provisioning server (which may, and probably will, run on the Amdatu platform). > > Sharing information - Some tenants will want to share content. Think of big publishers with multiple magazines. Each magazine would be a tenant, but they still want to share articles with each other. There could even be authorization involved; one tenant adds articles while other tenants can only read them and incorporate them into their website, but not change them. > > Licensing - Multiple tenants hosted by the same application may have different licenses. Dependent on their license, some services/functionality/content will or will not be available to them. > > Logging - I think logging should be separated, as each tenant would want to see only log entries that are relevant to them. More importantly, log files may contain information that are absolutely forbidden to be seen by others (as we experienced with some customers; we were not even allowed to read log files at all, they first has to be censured) > > > Regards, Ivo > > -----Original Message----- > From: amdatu-developers-bounces at amdatu.org [mailto: amdatu-developers-bounces at amdatu.org] On Behalf Of Bram de Kruijff > Sent: vrijdag 10 december 2010 13:22 > To: amdatu-developers at amdatu.org > Subject: [Amdatu-developers] Multi-tenancy (and more) design > > Hi all, > > I just created a mechanisms section under architecture on the wiki and > have put down an initial analysis on multi-tenancy. IMHO we must > address these concerns asap and I would appreciate you feedback and > contributions :) > > Regards, > Bram > > ps. http://www.amdatu.org/confluence/display/Amdatu/Principle+Mechanisms > ps. Working on a proof of concept for embedded containers. In a > sandbox near you soon. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101210/da1efe77/attachment.html
