Running through the history of computing is a quest for modularity. We curse it when it doesn’t work; we take it for granted when it does. Long ago, software engineers began to seek the equivalent of Lego bits, software modules that could be swapped much like bus boards on a hardware backplane. It’s been a long strange trip.
Modularity has gone through various stages in the modern era, with objects, components and, then, services, coming to take the place of Lego pieces in the software world. But, even in one of their (somewhat) recent iterations – that is, the services-oriented OSGi Service Platform – the mechanics software module interaction is not easy for developers or architects to master.
“Java Application Architecture” (Prentice Hall, 2012) by Kirk Knoernschild is one of the more probing books you are likely to find on this subject. Before the year past is very far past, I would like to take some time to discuss the book , as it is one of the better ones I have read lately.
The book has a straightforward principle, which is to provide guidance for those who might set out to design modular software. In Knoernschild’s terms, it looks at ways you can “minimize dependencies between modules while maximizing a module’s potential reuse.” This is, one, a major goal of middleware; and two, a long-time holy grail of software development.
While much of the book portrays garden-variety java problems, a fair amount of “Java Application Architecture” which is subtitled ‘Modularity Patterns with Examples Using OSGi’ also has a helping of OSGi know-how.
A conversation with Knoernschild disclosed that the book arose from an initial interest in uncovering how to leverage different layers of abstraction – to reach a deeper understanding of software architecture, and gain ease of maintenance. Composition of “Java Application Architecture” happened over many years, and there were discoveries.
“Along the way, the book morphed based on me learning more about how to design large software systems based on the Java system, with JAR files as the principle unit of modularity. Then, in the 2006 time frame, I discovered OSGi,” said Knoernschild, “I started digging into OSGi.”
He said he found the ideas of OSGi meshed with his own ideas about Java modularity in general. OSGi, for example looks at JAR files as the main means of re-use, treating a JAR file as a first class citizen. In the book, he explains how to take a monolithic application, modularize it and eventually bring it under the control of OSGi.
At heart, the issues Knoernschild addresses in “Java Application Architecture” are about dealing with complexity. Like Fredrick Brooks’ work, you could say Knoernschild’s effort is to separate the accidental complexity from the essential complexity. His thoughtful look at Java modularity is more than just tools and tricks – it is a foundational framework for thinking about problems of software architecture.
“Designing software is hard. It’s hard because breaking up the systems is so difficult,” said Knoernschild. OSGi’s detractors still argue that it, in itself, in fact, is too difficult. But experience tells us things are hard for a reason, and while the general drive of software is to make things easier, it is a daily battle to effectively simplify the complex. Knoernschild’s book, fights the good fight, and could become a valued companion at many developers’ bench tops. All and all, it is a brilliant breakdown on modularity.