Hi Marcel, On 10 nov 2010, at 09:07, Marcel Offermans <[email protected]> wrote:
> On 10 Nov 2010, at 7:42 , Felix Meschberger wrote: > >> Hi Peter, >> >> Am Mittwoch, den 10.11.2010, 06:23 +0200 schrieb Peter Lauri: >>> Hi, >>> >>> We have developed a few OSGI components that are publishing/consuming >>> services. However, we have one issue that we don't know the best design of. >>> >>> Bundle A is consuming a service that Bundle B is providing. The service of >>> B depends on configurations in a directory (xml files) and will be >>> registered when it gets a ManagedService.updated call. Assume we >>> reconfigure the system, that means new xml/modified files ends up in the >>> directory and we manually refresh the configuration bundle => >>> ManagedService.updated is called. Meanwhile this configuration changes are >>> read up, the service should not be usable. So there are two possibilities >>> as I see it (or are there more?): >>> >>> Option A: We keep the service registration, but make sure that calls to the >>> service cannot be performed meanwhile configurations are read up (internal >>> synchronization). >>> Option B: We unregister the service, read configuration, register the >>> service again. The consumer then need to track this removedService it self. >>> >>> What is the best pattern here? Any general recommendations? Is there any >>> good Option C? >> >> IMHO opinion both options are viable and the actual choice you take >> depends on how easy and stable one or the other option may be >> implemented. >> >> One point, though: Consumers of services must *always* be prepared that >> services go away, no matter what reason. So regardless of your choice of >> option, the consumer must correct track service unregistration. > > Completely agree. > > With option A you are probably internally using some kind of proxy that > delegates the call to the actual instance that is configured based on the XML > data and will be re-routing incoming service calls to a new instance whenever > the XML data changes. That way you would not actually make sure that calls > cannot be performed, but you would route them to the existing configured > service until the new one is available. > > With option B you would simply remove the service registration as soon as you > detect a changed XML configuration (through the updated() call) and publish a > new one as soon as you're ready. Consumers are tracking your service anyway, > so then it's up to them how they react. They could either abort any process > they are in the middle of if it needs this service, or they could shortly > block in the hope that it will only be away for a short while (only aborting > if, after some timeout, the service still has not come back). > > So option A is to deal with the dynamics in the service provider, completely > hiding it from the consumer. Option B is to deal with it in each consumer. My > preference for either A or B would largely depend on how important it is for > a consumer to be aware of the fact that the configuration has changed. If > it's completely irrelevant as it does not affect the behaviour of the service > (maybe the configuration just contains some settings that affect performance) > I would slightly prefer A. If the behaviour of the service is affected, I > would prefer B as it gives your consumers a better chance of deciding how to > handle this change in service. > > There is also an option C, if you decide to propagate the configuration via > the service properties. I cannot judge if that makes sense in your case, but > if it does, after re-reading the configuration you could use the service > registration to actually update those service properties. In that case, > clients will be notified that the existing service has changed and they can > still choose to react on that or not. If clients were tracking your service > with a filter and the properties change, they might actually see the service > go away on such a change. > > Greetings, Marcel > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev After reading your comprehensive answer (thanks), I will go for Option B as reconfiguration is of real importance and service should not be available during a reconfiguration. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
