2011/10/20 Marcel Offermans <[email protected]>: > Hi guys, > After doing some experiments earlier this week, I now committed a first > version of a new multi-tenancy bundle in my sandbox. This bundle implements > in-container multi-tenancy in a transparent way. I have added some pages to > the wiki so I could add some design documentation here: > http://www.amdatu.org/confluence/display/Amdatu/amdatu-core+tenant > I'm looking forward to your feedback as I think this would simplify our > programming model a lot!
After reading this I still think it's a pretty good idea and will certainly "check out" the sandbox code! After thinking about it some more here are a few random thoughts: 0) This is a pretty generic approach to managing service visibility. We call it multi-tenancy and use MF headers with that name, but one could argue this interceptor model could be applied to any meaningful discriminator. Hot to say that we should make it super generic, but how does this relate OSGi spec work going on. Is this reqiurements/capabilities at the service registry level? 1) I think we should explicitly test this approach against our mt criteria, because I think it's not only about restoring the development model. One could argue that enforcing service visibility also improves (the potential for) security and isolation. Also could we use these mechanisms to simply configuration management and resource/qos concerns? I think better then right now at the very least. 2) We might consider making the viability management even more potent. You write "we can intercept those to only return services that either have a tenant ID property that is identical to our tenant ID or that have no tenant ID property at all". But I think we at least need some way to say that a service is NOT to be found be an application. Eg. there are platform services that we do not wish to expose to application developers. 3) I do not see big issues due to the elegant point of interception BundleContext provides us... however we need to consider backward compatibility to current model as well as forward to multi container model. 4) What will break this? Singletons, code that makes assumptions on container implementation details, more? Anyway, cool stuff :) grz Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
