I was talking about RFC-138 which discusses Framework Hooks. There are several new hooks being proposed there. This is available as OSGi 4.3 early draft 2.
Why embedded containers are out? I have not been part of the spec discussions, but most likely they could not fulfill all requirements (in RFC-138) with that approach. >From experience, nested frameworks do work, but if anything in the parent >changes, you still need to restart all child containers. Furthermore, there is >very little in terms of tooling available for managing nested containers. We >tried the approach in ACE for a while, and did not continue with it because of >that last fact. Greetings, Marcel On 15 Dec 2010, at 11:09 , Bram de Kruijff wrote: > Hi again, > > I just had a look into the service hooks available in R4.2 > (http://www.osgi.org/javadoc/r4v42/org/osgi/framework/hooks/service/FindHook.html). > At this point I do not see how these could be used to solve our > problem. Most notably the FindHook provides a way of intercepting and > manipulting the results of a service lookup, but there is no way to > determine if it was a tenant aware service that initiated the > lookup... > > public class TenantAwareFindHook implements FindHook { > public void find(BundleContext bundleContext, String className, > String filter, boolean allServices, > Collection /* <? extends ServiceReference> */serviceReferences) { > // I know which BundleContext does the lookup, but I have no > way of determining whether > // there is a tenant associated with it. > } > } > > > @All any thoughts? > > @Marcel a while back you said that embedded containers where out and > hooks are in. Can you elaborate on why not to embed and what direction > the hooks are going. Are they working on new ones in the spec? Do you > have some links? > > Regards, > Bram > > On Tue, Dec 14, 2010 at 7:33 PM, Bram de Kruijff <bdekruijff at gmail.com> > wrote: >> Hi All, >> >> just wanna report I committed a poc for the multi (nested) container >> scenario into my sandbox. The poc (see readme below) shows a tenant >> aware useradmin (with multitenant storage) at the platform level. The >> tenantmanager (also a tenant aware) spawns a nested container for each >> tenant and publishes only(!) the relevant useradmin for that admin >> into this container along with a global logservice and some bundles >> that are 'tenant specific'. >> >> Pros: >> * relatively easy as-full-as-you-want isolation a tenants >> * a nice 'tenant lifecycle' and layer of indirection for manageability >> * tenant aware code only at platform layer. app developer need not worry >> * ...? >> >> Cons: >> * heavy(?) I got OOM at 500 tenant with 256M memory in poc setup >> * portable to other OSGi impl (?) Should be but needs factory. >> * ...? >> >> Obviously this is just a first poc and needs a lot more testing but in >> the meanwhile I'd like to hear your thoughts, pros and cons. I'd >> also like to create a poc using framework hooks to so we can properly >> evaluate the two solutions. >> >> >> Regards, >> Bram >> >> >> -------------------------------- >> PoC for nested Tenant Management >> -------------------------------- >> >> basic design: >> >> >> * TenantManager is a tenant aware service that >> 1) spawns a new osgi container for each tenant registered >> 2) delegates platform packages to the tenant container >> 3) proxies (only relevant!) services (log/useradmin) to the tenant >> 4) monitors container to take action (eg refresh) >> 5) TODO: publishes tenant services in parent container (eg a REST >> service?) >> >> * This UserAdmin FS storage is now tenant aware that >> 1) create a storage dir per tenant (based on id) >> 2) leverages PAX user admin through extender pattern >> >> -> useradmin per tenant >> -> application dev model in tact >> >> >> >> implementation notes/todos: >> >> * set of delegated packages is static (should be extendable) >> * list proxied services is static (should be extendable) >> * currently deploys four bundles into each tenant container >> - Apache Felix Dependency Manager; >> - Apache Felix Dependency Manager Shell >> - Apache Felix Shell Service >> - Apache Felix Remote Shell >> - Amdatu UserAdmin Commands >> * currently proxies global logservice into each tenant container >> * currently proxies relevant useradmin into tenant container >> * JVM with Xmx=256 went OOM at about 500 tenants >> >> >> 1) Starting this up: >> * Copy the amdatu-tm folder into devserver layout >> * Copy startup from this folder to devserver root >> * startup >> >> >> 2) inside parent container >> >> -> tmcreate 245 >> tmcreate <tenantId> <tenantName> >> -> tmcreate 245 jan >> -> tmlist >> '123' - 11 >> '245' - jan >> -> tmdelete 123 >> Tenant deleted: 123 >> >> note: use integers for tenantid as it is used to register a remote >> shell on that port >> note: refresh in the parent container will restart all tenants >> >> 3) Inside tenant container >> >> * telnet 127.0.0.1 245 >> >> Felix Remote Shell Console: >> ============================ >> >> -> ps >> START LEVEL 1 >> ID State Level Name >> [ 0] [Active ] [ 0] System Bundle (3.0.6) >> [ 1] [Resolved ] [ 1] Apache Felix Dependency Manager >> (3.0.0.SNAPSHOT) >> [ 2] [Active ] [ 1] Apache Felix Dependency Manager Shell >> (3.0.0.SNAPSHOT) >> [ 3] [Active ] [ 1] Apache Felix Shell Service (1.4.2) >> [ 4] [Active ] [ 1] Apache Felix Remote Shell (1.1.2) >> [ 5] [Active ] [ 1] Amdatu UserAdmin Commands (0.1.0.SNAPSHOT) >> >> -> uacreate 123 >> User created: 123 >> -> ualist >> '123 >> -> uadelete 123 >> User deleted: 123 >> -> >> >> >> >> On Fri, Dec 10, 2010 at 3:25 PM, Bram de Kruijff <bdekruijff at gmail.com> >> wrote: >>> Hi Ivo, >>> >>> Good points, thanks. Please feel free to add things on the wiki. I'm on >>> mobile atm so just two quicks notes: >>> >>> I would not call the management server the provisioning server as >>> provisioning is only part of its responsibilities. On the other hand I do >>> like the notion of "provisioning a tenant onto a node"! >>> >>> The data sharing use case I would aproach as a data (web) service. Either >>> owned by one or even 3rd party. This removes the data sharing at the >>> platform level requirement, which I fear would be a swamp of complexity. At >>> the same time it opens up the data for reuse for any consumer on the web, so >>> its much more RESTfull. >>> >>> Enjoy the weekend! >>> Regards, >>> Bram >>> >>> On Dec 10, 2010 2:57 PM, "Ivo Ladage-van Doorn" >>> <Ivo.Ladage-vanDoorn at gxsoftware.com> wrote: >>>> Hi Bram, >>>> >>>> I think this is a good starting point for the multi-tenancy discussion. >>>> And of course I have some remarks/additions: >>>> >>>> Configuration, Management - I would think that the application should >>>> support configuration per tenant. For example, if one tenant decides to >>>> reduce the session timeout to 5 minutes, it should not affect the other >>>> tenants. Some configuration on the other hand might be shared among all >>>> tenants hosted by the same application and if so, should be read-only to >>>> them as changing it would affect other tenants. >>>> Regarding management; I think tenant management should be separated from >>>> the Amdatu runtime and managed by the provisioning server. The provisioning >>>> server needs to be tenant aware, as it should decide what tenants run on >>>> what nodes and if tenants run in isolates OSGi containers and/or VMs >>>> (dependent on their contract for example; gold contract = isolated >>>> container >>>> and VM). As a consequence a Tenant in the Amdatu runtime is read-only; it >>>> is >>>> managed by the provisioning server (which may, and probably will, run on >>>> the >>>> Amdatu platform). >>>> >>>> Sharing information - Some tenants will want to share content. Think of >>>> big publishers with multiple magazines. Each magazine would be a tenant, >>>> but >>>> they still want to share articles with each other. There could even be >>>> authorization involved; one tenant adds articles while other tenants can >>>> only read them and incorporate them into their website, but not change >>>> them. >>>> >>>> Licensing - Multiple tenants hosted by the same application may have >>>> different licenses. Dependent on their license, some >>>> services/functionality/content will or will not be available to them. >>>> >>>> Logging - I think logging should be separated, as each tenant would want >>>> to see only log entries that are relevant to them. More importantly, log >>>> files may contain information that are absolutely forbidden to be seen by >>>> others (as we experienced with some customers; we were not even allowed to >>>> read log files at all, they first has to be censured) >>>> >>>> >>>> Regards, Ivo >>>> >>>> -----Original Message----- >>>> From: amdatu-developers-bounces at amdatu.org >>>> [mailto:amdatu-developers-bounces at amdatu.org] On Behalf Of Bram de >>>> Kruijff >>>> Sent: vrijdag 10 december 2010 13:22 >>>> To: amdatu-developers at amdatu.org >>>> Subject: [Amdatu-developers] Multi-tenancy (and more) design >>>> >>>> Hi all, >>>> >>>> I just created a mechanisms section under architecture on the wiki and >>>> have put down an initial analysis on multi-tenancy. IMHO we must >>>> address these concerns asap and I would appreciate you feedback and >>>> contributions :) >>>> >>>> Regards, >>>> Bram >>>> >>>> ps. http://www.amdatu.org/confluence/display/Amdatu/Principle+Mechanisms >>>> ps. Working on a proof of concept for embedded containers. In a >>>> sandbox near you soon. >>>> _______________________________________________ >>>> Amdatu-developers mailing list >>>> Amdatu-developers at amdatu.org >>>> http://lists.amdatu.org/mailman/listinfo/amdatu-developers >>>> >>>> _______________________________________________ >>>> Amdatu-developers mailing list >>>> Amdatu-developers at amdatu.org >>>> http://lists.amdatu.org/mailman/listinfo/amdatu-developers >>> >> > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers >
