Could this be handled by the coordinator? This API provides an out of band scope which allows "coordination" of operations, which is largely what multi-tenancy is about, although coordination is most commonly associated with something like transactions, but the axis is pretty much the same.
- Ray On Mon, Jul 2, 2018 at 2:58 PM, Clément Delgrange via osgi-dev < osgi-dev@mail.osgi.org> wrote: > > > > Hi, > > Thanks for your reply. > > Reason why I’m saying that there is very little OSGi can do is because you > need to decide how tenant information gets into system and how requests (if > any) are matched with them. In our case we had bunch of http endpoints, > messaging queues and databases linked together. > One of places which worked quite stable was powered by chain of service > trackers. For every configured database connection which had tenant id set > we published new http endpoint (daos-> services -> http endpoint to be > precise) which was then called by 3rd party system. > > > Maybe OSGI could define a standard approach for this like it does for many > common patterns (event, configuration, dependency injection, ...)? > > In your chain daos-> *services* -> http an ideal case would be that *services > *should not be aware of the tenant context and free to use any component > life cycle they want. If tenant specific services such as "daos" can be > registered by a proxy instead of the real service that implements what > David does in its *services *layer (a map tenant -> daos and thread > context) the *services *providers could be "unconscious" of the tenant > context. > > Cheers, > Clément. > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On July 2, 2018 1:09 PM, Łukasz Dywicki luk...@dywicki.pl wrote: > > > Last year I been working for 6 months on a project to turn a system built > on top of osgi from single to multi tenant. > We used mixed approach and I can share what worked well and what caused > troubles. > First of all, there is very little OSGi itself can do for you in order to > support multi tenancy if your application is not handling this kind of > deployment scenario already. > I had a bunch of implicit and explicit correlations spread over codebase > which got documented and used properly over time. Main trouble is > connecting values set in configuration with data and authentication. > Remember that our system was a single tenant and idea to have multiple > entities accessing same system instance was first of all brave and second > of all tricky to handle properly. Additionally we were forced to keep a > single tenant behavior, meaning access to all data, for limited set of > power users. > Reason why I’m saying that there is very little OSGi can do is because you > need to decide how tenant information gets into system and how requests (if > any) are matched with them. In our case we had bunch of http endpoints, > messaging queues and databases linked together. > One of places which worked quite stable was powered by chain of service > trackers. For every configured database connection which had tenant id set > we published new http endpoint (daos-> services -> http endpoint to be > precise) which was then called by 3rd party system. > In other places we had a static http endpoints used by user interface > which, based on authentication information, was pushing this information > down the hill to lower layers of system. Parts of systems which were built > before multi tenancy got few changes in order to propagate user/tenant > context (thread local but not only). > Most difficult part was cache management which took us over a month to > stabilize. I think that from time perspective it would be much better to > write some parts of system from scratch and follow above scenario with db > connection because at some point we really got quite magic setup. > Depending on assembly/distribution we had a different set of persistence > and cache implementation bundles which were aware of tenant context. Thanks > to that we had a physical data separation. > Whole thing worked, and I believe it still works, but debugging and > maintenance of it become quite difficult. > Because amount of static endpoints was quite high - I think we reached > about 200 if not more different operations where some of them had several > hundred lines of code to join and analyze data before returning it to ui we > couldn’t manage them easily. We thought that pushing tenant context will > save us a time, but in the end it still requires a lot of work. Some > operations worked out of the box, quite many required tweaking. Some we had > to write from scratch using higher level apis instead of raw db access in > order to propagate tenant information to persistence layer. > Given past experiences I got in this field I would recommend you to select > dynamically a backend service for tenant as early as possible and dispatch > request to it. > Sadly OSGi service factories will not help much in this area because they > are linked with bundles. You can’t rely on find hooks alone because they > will require unique bundles for tenants and results of their calls are kept > over time. You can try to use them to inject tenant selection logic but it > will work only with prototype scope (service lookup upon each request). > Cheers, > Łukasz Dywicki > > On 1 Jul 2018, at 21:03, David Leangen via osgi-dev osgi-dev@mail.osgi.org > wrote: > Hi Clément, > We ended up doing this via ServiceFactory. > A service is either “tenant-aware” (meaning that the tenant logic is built > into the service), or more commonly “tenant-unaware” (meaning that it’s > like you write below: the service has no knowledge of the tenant). For > those that are tenant-aware, we only need one instance (assuming it is a > singleton). For those that are not tenant-aware, we need once instance per > tenant. All we need to do for a tenant-aware service is add the “factory” > property to the component. The FactoryService listens for both tenants and > tenant-aware services, and will instantiate a tenant-aware service as > required. This allows us to dynamically adapt if a new tenant is registered. > This approach has also allowed us to customize services for a specific > tenant as required, which was an unexpected bonus. > All services that can be shared are shared, which means that I think (have > not actually calculated) that we are using computing resources efficiently. > In any case, this has been working well for us so far. > Cheers, > =David > > On Jul 2, 2018, at 2:11, Clément Delgrange via osgi-dev > osgi-dev@mail.osgi.org wrote: > Hi, > What is the way to achieve multi-tenancy with OSGI service. I would like > to design my API without a tenant context per method to concentrate on the > functional part, but also have an OSGI instance which could be scaled up. I > was thinking to let the service implementation decides if the service can > be shared between multiple tenants or not, and in this later case rely on a > standard way to bound service instances specifically for a tenant. Does > configuration admin can help with this? > For example, a service could be configured with multiple PIDs, one for > shared configuration and one factory configuration for tenant specific > configuration and then filter references in component, does that could > work? Is there some good practice for multi tenancy in OSGI? > Thanks, > Clément. > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
