Comments on: OSGi Service Locator http://basepatterns.org/2009/09/osgi-service-locator/ Trends in software design Tue, 06 Oct 2009 22:37:18 +1100 hourly 1 By: fortuna http://basepatterns.org/2009/09/osgi-service-locator/comment-page-1/#comment-27 fortuna Tue, 06 Oct 2009 22:37:18 +0000 http://basepatterns.org/?p=74#comment-27 <a href="#comment-21" rel="nofollow">@Costin Leau</a> Hi Costin, Thanks I probably should have made the point that the <em>Service Locator</em> pattern is possibly the least desirable mechanism for retrieving service references in an OSGi context, due to the dynamic nature of service availability that you mention. Sometimes however (particularly when dealing with legacy code and third-party libraries), approaches such as the <a href="http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf" rel="nofollow">whiteboard pattern</a> and/or <em>Dependency Injection</em> may not be applicable. In such cases a Service Locator may be considered (albeit with caution!). regards, ben @Costin Leau

Hi Costin,

Thanks I probably should have made the point that the Service Locator pattern is possibly the least desirable mechanism for retrieving service references in an OSGi context, due to the dynamic nature of service availability that you mention.

Sometimes however (particularly when dealing with legacy code and third-party libraries), approaches such as the whiteboard pattern and/or Dependency Injection may not be applicable. In such cases a Service Locator may be considered (albeit with caution!).

regards,
ben

]]> By: Costin Leau http://basepatterns.org/2009/09/osgi-service-locator/comment-page-1/#comment-21 Costin Leau Wed, 30 Sep 2009 17:03:12 +0000 http://basepatterns.org/?p=74#comment-21 One thing to add - one must not forget about the OSGi dynamics: a service can be unregistered at any time so ideally, on each call, the client would locate the service, invoke the methods needed and then discard the instance. Otherwise, if the service gets unregistered, any further invocations will lead to unpredictable behaviour. There are frameworks that handle this case (among other features) in a non invasive fashion (using dependency injection) - I'll mention the ones I know best, namely Spring DM and OSGi Blueprint Services. Cheers, Costin Leau Lead, Spring Dynamic Modules One thing to add – one must not forget about the OSGi dynamics: a service can be unregistered at any time so ideally, on each call, the client would locate the service, invoke the methods needed and then discard the instance.
Otherwise, if the service gets unregistered, any further invocations will lead to unpredictable behaviour.

There are frameworks that handle this case (among other features) in a non invasive fashion (using dependency injection) – I’ll mention the ones I know best, namely Spring DM and OSGi Blueprint Services.

Cheers,
Costin Leau
Lead, Spring Dynamic Modules

]]>