PieroCampanelli.info

n this article I’ll explain how many benefits can be obtained using a component oriented approach for software development adopting the OSGi model as the enabling component model.

A lot of team practices from the software engineering community can be used to reduce and to ease software development. There is another set of practices that lies at the architectural level and can be also adopted successfully for daily software development. One of these practices is the adoption of a modular component-oriented approach to software development relying on a formal component model.

One interesting, complete and innovative component model is the OSGi (Open Service Gateway Initiative) service platform. It is lightweight in contrast with EJB, it supports the full software lifecycle: from development to deployment and it can be used as the basis component model for Java Development. There are several advantages that can be obtained through the adoption of OSGi

Enable truly component development. Building componentized software is a bizarre thing. It’s conceptually very simple, but in practice it is usually quite difficult. It requires forethought, discipline and consistency. This is certainly something that is more difficult to achieve in large systems. OSGi offers a component model that solves most of the basics problems related to components: dependency tracking, version tracking, service binding, …

Secure development across different teams. OSGi enforces a modular, microkernel, plugin-based approach. One critic problem in software development is the fact that teams are variegated in experience and skills. Most of the time team is made by poorly skilled/motivated people. Their work on the code can easily break working software creating frustration in the rest of the team. With OSGi adoption you are forced working in a microkernel-style where a bunch of skilled developers create the basic platform while other teams contribute with plugins, components and extensions which are isolated, secured and controlled from the rest of code. Clearly you can follow this pattern without OSGi but costs for designing upfront a component model are higher. Why is it necessary to reinvent the wheel when there is an existing modular platform that can be exploited ?

Standard management of all company’s projects. A dreaming vision is a code repository made of a large set of components, with formal declared dependencies. When you want to build something new, you assemble existing components writing the necessary glue code and using automated tools that help managing dependencies and versions. It’s worth to note that this is not an impossible vision. Eclipse foundation has embraced with success this kind of development. If you browse the Eclipse Foundation CVS repository you can quickly see what I am advocating:

Millions of lines of code are arranged as OSGi component (aka bundles) with automatic dependency management. For example if I pick a component of the Eclipse platform I can quickly discover its dependencies with a few clicks inside the IDE:

In this case component ‘org.eclipse.equinox.registry’ (which is the component that models the plugin model underlying eclipse) depends from several other components (‘org.eclipse.equinox.common’ and ‘org.eclipse.osgi’). Dependency tracking is automatically managed by OSGi.

Version tracking. When you develop using components and you integrate existing components coming from the opensource ecosystem you have a combinatorial explosion of issues related to version management. (“Can I integrate this library? Does it conflict with the other library from Y?”, “What are dependencies of X library?”). Again OSGi can easily and elegantly solve this problem as it supports a formal versioning system of components. In the MANIFEST.FM (which is the standard descriptor of your component) you declare your version requirements. In this example taken from org.eclipse.equinox.http.servlet component version requirements are declared as:

....
Export-Package:
org.eclipse.equinox.http.servlet;version="1.0.0"
Import-Package:
javax.servlet;version="2.3",
javax.servlet.http;version="2.3",
org.osgi.framework;version="1.3.0",
org.osgi.service.http;version="1.2.0"
....

(which means: this component needs someone who provides javax.servlet package at version 2.3, javax.servlet.http package at version 2.3, org.osgi.framework at version 1.3.0, org.osgi.service.http package at version 1.2.0 and it exports org.eclipse.equinox.http.servlet package at version 1.0)

Helps architect/designer evaluation. One of the daily routine of a project designer/leader is to check if someone has broken some dependency. With help of OSGi this task can be automated without relying on any reverse engineering tool.

According to my opinion software is becoming more and more complex (think for example on how many lines of code from private and open source are daily integrated respect the past) and the only approach to manage complexity is using a truly modular platform. OSGi is the only complete lightweight platform that can help in this direction.