Hi Marcel, 2011/10/25 Marcel Offermans <[email protected]>: > Now that we released Amdatu Platform, we should probably continue this > discussion. > I think the most important thing we need to do, is to figure out what our > Tenant interface should look like, and how we want to configure the tenants. > Looking at the current Tenant interface, each tenant has an "id" and "name". > That makes sense. It also has a set of properties, and methods to access and > modify them. I would propose that we remove the method to modify the > properties (putProperty) and I'm also not sure what the actual use of the > "matches" method is: if you have a method to access the Dictionary of > properties, then you can use the standard OSGi filter mechanism to do > matches (in a more flexible way even). > So I propose we move to this interface: > public interface Tenant { > String getId(); > > String getName(); > > Dictionary getProperties(); > }
Mostly agreed. Just a thought/question though... why is Tenant not (or does not extend) org.osgi.service.useradmin.User? Does it not make sense to regard tenants as users (of a specific type) at the platform level, and store them using a well know mechanism with standard interfaces? We could still publish them as Tenant extends User services or whatever to do compatibility. > Also, I propose we configure the tenants via ConfigurationAdmin, using a > ManagedServiceFactory, requiring at least an ID for each tenant, and > optionally the name. Any other properties will be exposed via > getProperties(). Think so yes. This mapping to ManagedServiceFactory will be trivial to map to Ace configuration files lateron right? grz Bram > Does that make sense? > Greetings, Marcel > > On Oct 20, 2011, at 11:05 AM, Marcel Offermans wrote: > > 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 > > > _______________________________________________ > 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
