1.4. Synchronous Communication

Synchronous communication between bundles in the OSGi container is realized by publishing a Java object as an OSGi service. Clients of the OSGi service can then invoke the methods of the published object.

An OSGi service is a plain Java object, which is published to make it accessible to other bundles deployed in the OSGi container. Other bundles then bind to the Java object and invoke its methods synchronously, using the normal Java syntax. OSGi services thus support a model of synchronous communication between bundles.

One of the strengths of this model is that the OSGi service is a perfectly ordinary Java object. The object is not required to inherit from specific interfaces nor is it required to have any annotations. In other words, your application code is not polluted by the OSGi deployment model.

To publish an OSGi service, you must register it in the OSGi registry. The OSGi specification defines a Java API for registering services, but the simplest way to publish an OSGi service is to exploit the special syntax provided by the blueprint framework. Use the blueprint service element to register a Java object in the OSGi registry. For example, to create a SavingsAccountImpl object and export it as an OSGi service (exposing it through the org.fusesource.example.Account Java interface)

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <bean id="savings" class="org.fusesource.example.SavingsAccountImpl"/>

 <service ref="savings" interface="org.fusesource.example.Account"/>

</blueprint>

Another bundle in the container can then bind to the published OSGi service, by defining a blueprint reference element that searches the OSGi registry for a service that supports the org.fusesource.example.Account interface.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  
  <reference id="savingsRef"
             interface="org.fusesource.example.Account"/>

  <bean id="client" class="org.fusesource.example.client.Client">
    <property name="savingsAccount" ref="savingsRef"/>
  </bean>

</blueprint>

For more details, see Section 13.1.2, “Defining a Service Bean”.

Another important feature of OSGi services is that they are tightly integrated with the bundle lifecycle. When a bundle is activated (for example, using the console command, osgi:start), its OSGi services are published to the OSGi registry. And when a bundle is de-activated (for example, using the console command, osgi:stop), its OSGi services are removed from the OSGi registry. Clients of a service can elect to receive notifications whenever a service is published to or removed from the OSGi registry.

Consequently, the presence or absence of an OSGi service in the registry can serve as a flag that signals to other bundles whether or not a particular bundle is available (active). With appropriate programming, clients can thus be implemented to respond flexibly as other bundles are uninstalled and re-installed in the container. For example, a client could be programmed to suspend certain kinds of processing until a bundle is re-activated, thus facilitating dynamic reconfiguration or updating of that dependent bundle.