link to coordinator spec for reference https://osgi.org/specification/osgi.cmpn/7.0.0/service.coordinator.html
- Ray On Mon, Jul 2, 2018 at 3:33 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > 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) > -- *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
