More productive modular working thanks to OSGi Blueprint

Although the OSGi modularization specification has been around for a few years, it is still in tune with the times. This is demonstrated not least by the fact that Oracle is planning a similar system called Jigsaw for Java 8. But while Jigsaw is still a dream of the future, OSGi already being used diligently at doubleSlash.

When familiarizing yourself with OSGi, you usually start with simple services that are registered and queried manually. This is a good way to get to know the system, but quickly gets out of hand in productive use. To make these elementary functions easier, it is worth taking a look at the OSGi enterprise specification.

The term "Blueprint" refers to a contemporary treatment of services: Dependency Injection!

The prerequisite for this is an executable implementation of the standard, e.g. Apache Aries. To register a new service, an XML file is first created under OSGI-INF/blueprint/ (example from aries.apache.org):

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   <service id="serviceOne" ref="account" interface="org.apache.aries.simple.AccountInterface" />
   <bean id="account" class="org.apache.aries.simple.Account"/>
</blueprint>

Blueprint now automatically ensures that this service is registered in the OSGi container.

To be able to use this in a Java class (in the example "AccountClient"), the following configuration is required:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   <bean id="accountClient" class="org.apache.aries.simple.AccountClient">
      <property name="account" ref="accountRef" />
   </bean>
   <reference id="accountRef" interface="org.apache.aries.simple.AccountInterface"/>
</blueprint>

This means that you already have everything you need to use the service. The code is streamlined and the testability of the application is significantly improved. Of course, Blueprint also offers a number of other features - for example, the handling of services that fail at short notice via proxies, which is a fundamental problem in such a dynamic environment.

Even if the wealth of possibilities can be somewhat overwhelming for beginners, you should not be afraid to venture an early insight beyond the core specifications. The reward is often a big increase in productivity. By modularizing the individual areas of software, these small parts automatically become more maintainable. Complexity and dependencies are reduced and, in the long term, so are the costs of a project.