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
