OSGi Service Management

In the traditional way, we can register the service through Bundlecontext.registerservice () in the bundle's activator (called when the bundle starts), through SERVICEREFERENCESR = Bundlecontext.getservicereference () and Bundlecontext.getservice (SR) are serviced in two steps. But there are many drawbacks to this approach:

1. Generate more Duplicate code

2, at startup to instantiate all the services to be published, affecting the startup time

3, some registered services will not be used during the operation, additional memory consumption

4. Increased coupling to the OSGI framework

OSGi addresses these issues using the Blueprint specification and declarative services.

First, Blueprint:

1. Service Release

<bean id= "Timeservice" class= "Com.star.test.TimeService" >

<osgi:service id= "Osgitimeservice" ref= "Timeservice" interface= "Com.star.test.ITimeService"/>

2. Service Reference

<osgi:referenceid= "Osgitimeservice" interface= "Com.star.test.ITimeService"/>

Blueprint is implemented by creating a proxy at the time of the service reference, called by a dynamic proxy when the service is invoked. In other words, the service can be published even if the dependency of the service is not met. When invoked, if the dependent service is currently unavailable, it will cause blocking until the dependency is met or timed out.

One benefit of the blueprint mechanism is the ability to deal with the impact of service cancellation and release on the framework during bundle updates. In addition, because the Blueprint method uses the proxy mechanism, the service must be published as an interface.

Ii. Declarative Services

<?xmlversion= "1.0" encoding= "UTF-8"?>

Build declarations and some of these properties
<scr:component xmlns:scr= "http://www.osgi.org/xmlns/scr/v1.1.0" immediate= "true" Name= "Timeservice.instance" >

Implementation class

<implementationclass= "Com.star.test.timeService"/>
Interface declaration

<service>

<provideinterface= "Com.star.test.ITimeService"/>
</service>

Depending on the service that initializes the service when the Bind method is called, when the service stops, the call unbind
<reference bind= "InitDataSource" cardinality= "1..1" interface= "Com.star.test.IInitDataSourceService" Name= "Initdatasource.instance" policy= "dynamic" unbind= "Destroydatasource"/>
<properties entry= "Osgi-inf/db.properties"/>
</scr:component>

Declarative services is a component model that simplifies the process of creating components that publish and use OSGi services. We need to define components and their dependencies declaratively, and the framework manages the lifecycle of components based on dependency satisfaction. This means that only when the component's dependencies are fully satisfied will it be in the active (activated) state, and the component will be deactivated (deactivated) Once the dependencies are missing. Therefore, the declarative service does not use a proxy, but it can guarantee that its internal dependencies are satisfied as long as the component is in an active state.