tl;dr -> I agree with the current implementation, necessary only when we run in a multi tenant container
First of all, thanks Bram for extending the documentation at http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant. After reading it, I have some concerns about visibility that I wanted to discuss. Let me start with the requirements. I agree with FREQ1 to 4, I'm not too sure about including 5 here. To me, management and monitoring is an "aspect" that you can enable for the whole platform (or not) if you need it. On the one hand, you could therefore argue that FREQ5 should be mentioned here, on the other hand, by using OSGi services and Configuration Admin, making multi-tenancy "manageable" can implicitly always be done. Therefore, I would argue that we do not explicitly mention this as a functional requirement for every project that we do, but instead cover this when designing our management and monitoring subproject. Similarly, NFREQ1 and 5 to me are "global requirements" that apply to our whole platform (and subprojects). We should probably put them on a separate page. Back to visibility. First the part that I agree about: scoping visibility of tenant specific services to just that tenant. That makes sense, you don't want tenant A to invoke a service that was scoped to tenant B. I'm a bit hesitant about platform vs application scope and the VUC1 to 5 use cases: Let's take the ConfigurationAdmin example you start with in VUC1: In the "normal" (no tenants) OSGi scenario, having only one single ConfigurationAdmin is just fine. By design, it has different configurations for different service.pid's, which nicely scopes each configuration to its own managed service. More in general, I am very hesitant to introduce any form of scoping in this scenario, because I don't think it's needed. In the "tenant" scenario, we of course do have a ConfigurationAdmin per tenant, and here we run into a visibility issue if we also want to have a "platform" CA because: 1) With the filters we have now (show all services that have a tenant id that matches mine PLUS all services that do not have a tenant id at all) that would expose two CAs to a tenant (this is VUC1, right?). 2) Also, for other platform services, unaware of tenants, that would expose ALL CAs (this comes close to what you describe in VUC2). The scenario in VUC4 has two variations: 1) The application uses another LogService implementation, therefore a different bundle, which means we can "adapt" that bundle to be tenant aware. 2) The application uses a single LogService implementation, which means this bundle should provide separate services for both the tentants and the platform. With VUC5 do you mean a LogService that uses the tenant aware bundle activator to ensure that each tenant has its own LogService? By default, such services should only be visible to the tenant they belong to. You run into the issue that if you have a "platform" service that is not aware of tenants, that it will see all LogServices (like explained above in tenant scenario, option 2). Is that what you mean here? My summary so far: If we do not have tenants, we do not need any special scoping. If we do have tenants, we might want to introduce some kind of notion of a "platform" scope. Actually, at this point I am looking at the latest code changes, and see that you pretty much implemented this by allowing three different scopes for a tenant aware bundle: 1) "platform", implemented as a "special" tenant (similarly to how the framework is a special bundle in OSGi) 2) "tenant", meaning a bundle produces and consumes services that are tenant aware 3) "both", or 1+2, meaning you get services for all tenants, PLUS a special "platform" one. As far as I can see, this addresses all issues mentioned above, so I don't think I have any concerns with the current implementation (and we maybe only need to clarify when to and when not to use scoping). Greetings, Marcel
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
