Tuesday, June 28, 2011

The need for Modularity

The title of this blog is not new - it has been used by many other blogs and articles in the past, but Rod Johnson seems to think that Modularity not really needed any more so I decided to reuse the title and take a look at why we really need Modularity.

In this age of Cloud Computing where hardware utilization and energy consumption are being highly optimized you will find that more and more service providers are moving towards a multi-tenancy model where multiple deployments are co-located on a single platform. Whether these deployments are from different providers or from the same provider is the choice of the deployer, but the end-result is a situation where multiple deployments share a single platform. In such cases modularity is an absolute must as without it there is a reasonably big chance that the system won't work. This is because deployables might depend on incompatible versions of the same library, which means that in order to work, they need to be isolated from each other. Or, a deployable might depend on a library that also happens to be used by the platform provider, this is an even harder case which requires the platform itself to be developed in a modular fashion so that it's details don't bleed into the user-space.
Scenarios like this require modularity and in the case of Java this modularity is provided through OSGi and/or many application servers. Additionally, modularity can also be found in many non-appserver systems that allow plugins to be installed.

Further benefits of modularity relate to memory footprint and performance. A modular system can make intelligent decisions about its memory usage, where only modules that the end user actually needs are loaded. This makes it possible for a fully featured server to have a tiny runtime footprint if only a small portion of it is actually used. And all of these benefits have performance benefits too: you'll save a lot of time if you're only loading the modules you actually need rather than pre-loading the entire system as a single entity.

But even if you don't need modularity for side-by-side versioning, isolation or performance just yet, there are additional benefits associated with using a modular approach in your development. I think that even for small projects it's not a bad idea to start out by using Modularity. It's true - getting a modular project off the ground takes a larger initial effort compared to the 'traditional' approach. But that cost is quickly earned back once the project grows a little bigger. Once your project is structured to support modularity, it becomes much more maintainable, easier to understand and to extend while 'traditional' approaches tend to become much harder to maintain as they grow in size.
See the following diagram, adapted from a blog by Hal Hildebrand:
Cost of Software Maintenance
The investment in a Modular Architecture earns itself back quicker than you think.

Using a modular approach together with a service oriented architecture*) gives your system highly cohesive entities with a clear responsibility. This makes it easier to identify what parts are affected when a system needs to be enhanced or changed. Changes for a particular feature are often more localized to a specific set of modules, which enables better parallelization of development and will ultimately make your developers more productive.

So Modularity is highly desirable for a number of reasons and the best place to get modularity today is by taking an OSGi Framework, as OSGi has been providing Modularity as well as an excellent Services Framework to Java for over 12 years and is standardized in the OSGi specifications.

Part of the choice for a particular development architecture is always the consideration regarding tooling support. With OSGi the following tools are popular:
Additionally, Netbeans and IntelliJ have OSGi Support. While tools can always be improved the above toolsets are quite usable. Especially the Maven Bundle Plugin is very popular in the Open-Source world and many, many examples can be found that show its use.

To conclude, Rod Johnson says that especially on the server side, using a non-modular system is better for customers. This seems like a highly incorrect statement to me. Modularity is needed especially on the server side, as without it your deployments become fragile, especially if you have more than one deployment on that server...

*) Note that by saying 'service oriented architecture' I'm not implying a distributed SOA. Using services within a single process is highly valuable and works great in combination with modularity to avoid tight coupling. Yes, services open the door to distributing parts of your application, but that's really a different topic...

Tuesday, June 7, 2011

OSGi Enterprise Specification Early Access Draft available!

An early access draft for the upcoming OSGi Enterprise Specifications has just been made available. This is really interesting stuff and it shows what we've been working on in the Enterprise Expert Group over the last year or so. Although still work in progress, some of these specifications will be included in the next OSGi Enterprise Release which is currently planned to be released during the first half of 2012.

The main theme for the Enterprise Release is around Subsystem/Application support and OBR (the OSGi Bundle Repository). These are covered in RFC's 152 and 112. Together they greatly improve the way you can define and distribute, assemble and install OSGi applications and I'm really looking forward to the moment that these specs are finished and broadly implemented.

Additionally you can find in the draft: RFC 146 JCA support, two new Blueprint specifications and an update to the JMX specification (chapter 124 in the Enterprise Release 4.2).

Finally there is RFC 167. This is a new RFC that I've been working on. It intends to fix a small but quite annoying issue: the fact that java.util.ServiceLoader() and META-INF/services use generally don't work in OSGi. You can work around it, as I've blogged about in 2008, but it's ugly. Using RFC 167 this issue can be addressed so that any non-OSGi code that uses this pattern can work in OSGi without too much hassle. I've been working on an implementation of this in Apache Aries, if you're interested in trying it out.

Note that the specifications are not yet final so significant changes might still occur. Also, feedback is welcomed! You can leave comments here on my blog or write an email to the osgi-dev mailing list.

You can find the EA draft here: http://www.osgi.org/download/osgi-early-draft-2011-05.pdf