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();
}
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().
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
