OSGi Complexity?

Functional decomposition and modularization of applications is a popular topic. Instead of building singular, monolithic applications, we can build little Bundles or Modules that represent business functions and put them together Jigsaw Puzzle style.

The idea is that any overhead of such an approach is greatly offset by the benefits of encapulations - from software development to enterprise function placement.

For example, an application can "Shake bread crumbs with some chicken" and "Bake dinner", these two concerns are agnostic of each other, but can be composed into business flow "Shake 'N Bake". Or other business flows can be "Shake 'N Freez" or "Defrost 'N Bake".

Anytime we need to add/remove/change anything in the application we know exactly the place where the logic lives - as opposed to hunting throughout large codebases of potentially manyy application. It works great for testability, enables effective refactoring and short iterations.

OSGi has done a terrific job in championing of the modular concerns. But OSGi implementation can get quite complicated, for a reason that is not part of its core value proposition ...

Large portion of OSGi complexity comes from the assumption that the whole system is highly dynamic - OSGi bundles can come and go during the runtime and the system needs to constantly adapt. That is great and usefull for certain applications - I imagine telco world is a great example, but for most applications, this ability introduces too much complexity. Take the stallwart of OSGi examples Eclipse - the dynamic bundle update (called Plugins) is not used everyday and most new bundles force restart of the application after update, anyway.

Here's a solution: As soon as I replace "highly dynamic" with "fairly static" environment assumptions, it gets much simpler. I know that my application will either "shake" or "bake" sometime during application's runtime, anyway. I can live without introducing brand new business functions (say brand new operation "DeepFry") while the application is running. Now I could concentrate on the real issue at hand - modularity and functional decomposition, which is the core reason I arrived at OSGi gates.

Most of the OSGi complexity goes away with this change. It is a simple change, but it has far reaching impact. Bundles still have dynamic lifecycle, the major change is that all the Bundles are present from the start of the application and the application doesn't have to deal with Bundles exiting or brand new Bundles entering the application on a whim. Maybe this could be called SimpleOSGi.

Thanks to Ricky Bobby and Cal Naugton Jr. for inspiration in naming business functions examples. Dear Kraft Foods, please do not sue me.

Name Things Right

In Object Oriented languages, Class represents a definition of what will become an Object at runtime. In some languages (Smalltalk, Ruby) Class can be a runtime Object as well, in others it is more static formula (Java, C#). It always contains the prescription, the recipe. A Class may say: Add two arms, body, head and two legs to create a Person. It can also say that Person can speak.

When software runs, two instances of Person Object are created and they can speak with each other.We try to model the problem domain which is the target of our software as collection of Objects that can interact with each other (i.e. two Persons can speak with each other). This added level of abstraction helps us understand the domain better – we do not primarily focus on the details of sound wave exchange that is human speech, we primarily focus on the fact that two Persons can speak with each other. This way we do not get lost in details from the start, we find a place to put appropriate logic and move on.

The trick to software modeling is the ability to “Name Things Right”. If I can give names to all the actors in my domain I have created all the Classes. Then I decide what the actors (now Classes) can do in form of methods and I’m done creating my domain model. If I can not name my actors, I do not understand the problem domain enough to try to solve it with software. I have to go back and get more information, remodel and refactor. It takes several iterations before the problem domain is solved.

When “Utility Classes” rear their ugly heads: Utility Classes are convenient holder of unrelated methods, often accessed statically. I’m convinced that proliferation of Utility Classes is evil in Object Oriented software. It is clear indication that we have failed to model our domain correctly and started to put methods into one size fits all bag. Strobe lights should go off and sirens should sound every time this happens – just to attract attention. “Name Things Right” and your design will be conducive for beautiful code to happen.

Hat tip to Derek Zoolander for “Name Things Right” inspiration.