JavaOne 2014 – Day 2 – What’s up with modularity tutorial

On Tuesday the technical meetings started with a tutorial on modularity from our Dutch colleagues of Luminus, Paul Bakker and Bert Eertman. Here’s a summary of their presentation.

We see applications changing, growing and over time becoming more and more complex. With the adoption of Agile software development, we don’t even know what the architecture would look like sprint after sprint. To be able to cope with this growing complexity in software and architecture, we need flexibility. Modularity to the rescue. Modularity comes from two concepts, that we’ve learned about early on in our education:

1. Prevent (tight) coupling
2. Promote cohesion

To illustrate, see the picture below. The boxes in this picture can be considered modules, in which coupling is allowed. But between boxes, it is not, instead cohesion on interfaces should be found.

To be able to introduce modularity we need the following mechanisms to work:

1. Module system
2. Service lookups

Modules can be implemented in JAR’s with public parts (API’s / interfaces) and private parts (implementation). This creates our module-system. Apart from this module-system, we need a service lookup, to inject instances of the implementation whenever we need them. This is comparable to Spring or other dependency injection frameworks.

Since modularity in Java (Jigsaw) will only be introduced in Java 9 (due in 2016), we currently have only one option for runtime modularity: OSGI.

To illustrate their approach, Paul and Bert created a chat-like application using chat-rooms and messages. They used Eclipse with the BndTools for OSGi plugin, which was all they needed. The technology stack included HTML5, AngularJS, JAX-RS, RabbitMQ and JPA running on the Apache Felix OSGi implementation. Each module was implemented in two separate packages, clearly separating the API part from the implementation. BndTools was then used to expose the API for use and encapsulate the implementation. The AngularJS UI was added as a separate module as well, integrated using REST services.

To illustrate the flexibility, Bert added an advertisement functionality to the chat-client.

With Amdatu and BndTools it is quite easy to create OSGI modules and getting them running. There are however some things you have to set up to make life a lot easier. For example, monitoring the status of your modules is done by using a subproject of Apache Felix, called Gogo. This is a command line tool that you can use to monitor, stop and start modules. Furthermore, you have to think about which classes to expose and which to keep private.

Some advantages using this combination of tools:

1. OSGI adds runtime deploying, which is very handy while developing code.
2. A Maven like repository can be used to get your libraries, but you can also just drag and drop your jar files in the local repository (within eclipse)
3. With BndTools you can create multiple modules inside a single project
4. Amdatu contains very useful annotation for supporting for example JPA (@Transactional annotation).

With an @ServiceDependency annotation you can add your service dependencies from modules. You can also make injections optional, resulting in an empty proxy when the dependency is not available.

Paul and Bert advised to create extra OSGI projects for running and integration testing the OSGI application.

Lastly, make sure you test your modular system using integration tests, because Unit-tests don’t proof that your modular system actually works. It only tells you the API’s can be called.

For more information go to www.amdatu.org