Hello Bram, On Oct 20, 2011, at 10:21 AM, Bram de Kruijff wrote:
> 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? I actually got the idea for this code while discussing an optimization I did to dramatically speed up service lookups in the dependency manager. It is very well possible to use this for other visibility constraints. We definitely try to achieve the same things through this mechanism as the various new hooks do. We should definitely review them when the spec becomes final, but one disadvantage of hooks is that you really need to install them before installing any other bundle. I'm not yet sure how that would work out in our provisioning model. Besides, I don't think there are hooks to influence the bundle's data area like I do now, so we'd probably need a hybrid solution then anyway. > 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. Enforcing visibility will definitely improve isolation and guard developers against using the wrong services by accident. Configuration management as far as configuration data is improved because if you make the ConfigurationAdmin multi-tenant, you will end up with a separate store for each tenant (showing up in the tenant specific subfolder of the bundle data area. Regarding QoS/resource concerns I don't think this mechanism adds a lot. Okay, you can now calculate the disk space requirements of stuff in the bundle data area per tentant, but lots of QoS concerns should be addressed by the JVM (theads deadlocking or using too much CPU, that type of stuff). > 2) We might consider making the visibility 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. As long as you can express this rule as a filter condition, you can do that. For example, we could simply mark platform services with a property and exclude all services that have that property for application bundles. Leaves us with the task of identifying what bundle actually is an application bundle, but that can be solved. So yes, we should probably explore that too! > 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. I think we're already backward compatible if we use the exact same Tenant service as the current model. For now on purpose I did not do that. I bumped the org.amdatu.core.tenant package to version 2.0 so none of the existing bundles will bind to it unless they're buggy and don't define their import ranges ;). So if we use the same Tenant service, we should be able to combine both. Also, when you mark a bundle with a "MultiTenant-Version: 1" manifest header you indicate to the InputStream wrapper that you don't want your bundle to be processed, so that will ensure a current multi-tenant aware bundle will not be "transformed". Forward compatibility to a multi container model should be excellent, as the model is currently transparent. Of course in a multi container model, there are no "shared" services by default until we start using some implementation of remote services (unless we resort to nesting containers and depoying the shared services in an outer container). > 4) What will break this? Singletons, code that makes assumptions on > container implementation details, more? Singletons and their related statics, and code that assumes that there will only ever be one instance of the BundleActivator class. Also code that obtains a bundle and its bundle context via the FrameworkUtil class, as I currently can't intercept that. Bugs in my current implementation (I might have forgotten some obscure paths to get to a bundle context). Also, any bundle that goes outside of its own data area might break, but you can argue that this is extremely bad practice anyway as you probably should not make assumptions about the world outside of your container. So using this will probably never be a 100% fool proof way of making third party bundles MT aware, but our own code can definitely take these limitations into account. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
