Java Application Architecture: Modularity Patterns with Examples using OSGi is Kirk Knoerschild's seminal book on how to design for modularity in application design, by providing a catalogue of eighteen patterns.
The first part of the book argues for the case for modularity, by talking about the runtime and development support for modules. It then builds on this showing how modularity can be used at design-time to facilitate architecture, and how this can integrate with service oriented architecture. At the end, there is a reference implementation that shows how the pieces fit together.
The second section of the book is the pattern catalogue, split into five different sections, which are listed on the site's pattern catalogue:
- Base Patterns
- Manage Relationships – Design module relationships
- Module Reuse – Emphasize reusability at the module level
- Cohesive Modules – Module behavior should serve a singular purpose
- Dependency Patterns
- Acyclic Relationships – Module relationships must be acyclic.
- Levelize Modules – Module relationships should be levelized.
- Physical Layers – Module relationships should not violate the conceptual layers.
- Container Independence – Modules should be independent of the runtime container.
- Independent Deployment – Modules should be independently deployable units.
- Usability Patterns
- Published Interface – Make a module's published interface well known.
- External Configuration – Modules should be externally configurable.
- Default Implementation – Provide modules with a default implementation.
- Module Façade – Create a facade serving as a coarse-grained entry point to to another fine-grained module's underlying implementation.
- Extensibility Patterns
- Abstract Modules – Depend upon the abstract elements of a module.
- Implementation Factory – Use factories to create a module's implementation classes.
- Separate Abstractions – Place abstractions and the classes that implement them in separate modules.
- Utility Patterns
- Collocate Exceptions – Exceptions should be close to the classes that throw them.
- Levelized Build – Execute the build in accordance with module levelization.
- Test Module – Each module should have a corresponding test module that validates it’s behavior and illustrates its usage.
The final part of the book covers the patterns application with OSGi as an example of a module system for Java. Although this section is OSGi specific, the patterns in the rest of the book apply to any module system in Java, including the up-coming Jigsaw project, and as a guide for those wanting to build modular software without a runtime module system.
InfoQ caught up with the Kirk, and asked for his thoughts on software and modularity, and started off by asking how software complexity has changed over the last few decades:
Kirk: There's no doubt that software has grown over the last several decades. More powerful hardware along with more expressive programming languages makes it easier to create more powerful software systems.
Today, most developers don't have to worry as much about dealing with severe memory constraints and limited processing power. For instance, a study conducted by the University of Jyväskylä showed that there were 120 billions lines of code in 1990 and that the number of lines more than doubled by 2000 to 250 billions lines of code. The study also claims that the number of lines of code doubles every seven years.
That's staggering, and put into perspective, it means we'll write more code over the next seven years than we've written since someone wrote the first line of code. In many ways, this growth in code isn't a bad thing. If software doesn't grow and evolve, it ultimately dies. People who use software naturally demand more from it, and so we churn out new versions and upgrades to support our users. But more code means more maintenance. And maintaining large systems is inherently more difficult than smaller systems.
InfoQ: What effect has that had with how software is designed and architected?
Kirk: Unfortunately, it hasn't had a significant affect yet. In many ways, we still design software the same way today that we did 15 or 20 years ago. But that's not sustainable and something needs to change.
It's no longer appropriate to develop monolithic software. SOA and services are a step in the right direction, but that only addresses part of the challenge. One of the most perplexing aspects of service design is determining service granularity. Too coarse-grained and the service does too much to be useful across a variety of different contexts (i.e., reusable), yet too fine-grained and the service doesn't do enough to be useful (i.e., usability).
As I discuss in the book, maximizing reuse complicates use. A single level of abstraction cannot solve this problem. Additional levels are necessary, and modularity is that next level. Modularity is the next step that will help you architect "all the way down."
The result is that you compose services at the right level of granularity using existing modules. Modules, which are at a different level of granularity than services, help you architect all the way down.
InfoQ: What is the future of modularity on the JVM?
Kirk: There is a lot going on with modularity on the JVM. OSGi is being baked into just about every major vendor product and is available for use within many organizations today.
Unfortunately, OSGi hasn't gained traction in the enterprise yet. Some argue that it's too complex, but what they're really saying is that designing modular software is difficult. For those of you familiar with Frederick Brooks, the problem centers around the essential complexity of software development. Architecture and design is very difficult.
Yet, resilient, malleable, flexible, and maintainable software is critical to success, especially in today's fast-paced enterprise environment, where the delivery demands on software development teams are greater than ever before. Of course, OSGi isn't the only module system. Oracle is also baking Jigsaw into Java SE, which will be available sometime in 2013. Modularity is coming to the Java platform, and it is going to change the way we design software systems.
InfoQ: What made you decide to write Java Application Architecture?
Kirk: About 10 years ago, I recognized a significant problem with software I was designing. We put all this effort into designing really good class structures and then we packaged everything into this huge single deployable unit, like an EAR or WAR file. It didn't feel right. All that effort went into creating flexible software, yet we weren't seeing significant benefits in terms of reuse, maintainability, or flexibility.
About that same time, I inked my second book deal and planned to write about software patterns. The perplexing issues I faced with my designs carried over into my writing; something was missing that made it impossible to realize the advantages I sought. I had always been a huge fan of Bob Martin's SOLID principles as well as the GOF patterns. I also began studying the works of Clemens Szyperski who is the author of "Component Software: Beyond Object-Oriented Programming" and John Lakos, who wrote "Large Scale C++ Software Design." I married all of these concepts and started changing how I designed software systems by focusing on the JAR file as the unit of modularity.
Over the next couple of years, I honed this approach. By using the JAR file as the unit of modularity, I was suddenly able to realize many of the advantages I sought. The patterns you see in the book are the result of what began about 10 years ago. Meanwhile, I had a book that was about 70% complete, but it didn't include many of the concepts I had applied over that same period. So I took some time away from the book, continued to prove the patterns, and about two or three years ago, reached out to a very patient publisher to let them know I was ready. Fortunately, they gave me another chance and the result is the modularity patterns. Maybe that explains more about how the book came to be rather than why I wrote it.
Ultimately, I wrote it because the patterns made a big difference in improving the systems I developed and I wanted to share them with the world.
InfoQ: Is the book OSGi specific?
Kirk: Absolutely not. It's not specific to any module framework. The patterns, and the entire book actually, are designed to be used with everything available in standard Java today. In fact, I didn't discover OSGi until about 2006, roughly four years after I had begun this journey.
My discovery of OSGi was actually somewhat of an epiphany. I found a community of like-minded folks and a framework that gave runtime support to many of the patterns. As I learned more about OSGi, I began to develop ideas about what it would take to migrate existing applications to OSGi.
The book provides some examples that demonstrate OSGi, but primarily to demonstrate the strengths of OSGi and give people a glimpse into what it takes to move a system from standard Java to OSGi.
InfoQ: Can modularity be applied even if you're not using OSGi or Jigsaw?
Kirk: Definitely. In Chapter 2, I talk about the two facets of modularity – the runtime model and the development model. The development model can be subdivided into the programming model and the design paradigm.
A module framework is going to give you a programming model and a runtime model. But no framework is going to help you design a good set of modules. That's left up to the developer and that's the focus of the book.
I like to draw an analogy with the object-oriented paradigm. Just because a language supports inheritance, polymorphism, encapsulation, and dynamic binding doesn't mean great object-oriented software is guaranteed. Design patterns help you with that.
The same is true with modularity. Even though you may be using a module framework, modular software isn't guaranteed. So the intent of the book is to first help you design modular software whether you're using OSGi, Jigsaw, or just standard Java. This way, you can start applying the concepts in the book right now without adopting any new frameworks or making any additional infrastructure investment.
Most of the code samples use standard Java to demonstrate the concepts. I added several additional code samples built using OSGi to illustrate the additional benefits you get from runtime support for modularity. So in addition to helping you design modular software today, the concepts in the book also prepare you for runtime support for modularity when it's available and when you're ready to start using it.
InfoQ: Is modularity only about reuse?
Kirk: Reuse is it interesting because reuse sells. By that I mean just about major technology trend of the past couple of decades touts reuse as its primary advantage. In the 90's it was object-oriented programming. Shortly thereafter it was component-based development. Then we moved onto service oriented architecture.
Ironically, each of them has failed to live up to expectations, and many development teams continue to struggle with reuse. Certainly reuse is an advantage of modularity, but it's not the panacea. Modularity fills a gap that other approaches can't, because modularity allows you to focus on design at a different level of abstraction and granularity. You'll see where that gap exists if you read Chapter 2 and Chapter 5 of the book, along with how modularity helps.
But modularity has several other advantages, too. These include better maintainability, dependency management, and simply increasing your ability to understand very complex software systems. Several chapters in Part 1 of the book discuss these ideas in detail.
InfoQ: Can modularity be applied to existing systems, or does it need to be designed in up-front? Can systems be refactored to become more modular?
Kirk: It's easier if you begin thinking about modularity at the same time you begin thinking about architecture and design. But if you've got an existing system, you can still modularize it, especially if you have a good class design. In fact, Chapter 8 in the book walks you through this exercise by taking an existing system that isn't very modular and applies several refactorings using the patterns. The result is a highly modular system. It's a pretty powerful example that demonstrates the benefits of modularity.
Something very interesting typically happens as you perform this exercise; you begin to uncover deficiencies in your class design you didn't know existed. For instance, just about every team tries to layer their software systems. Usually, this means they'll have presentation, domain, and data access layers. But these are logical layers. That is, they exist conceptually in the class structure but not physically among deployable units.
When you attempt to layer your software into modules, you start focusing on deployable units. As you do this, you typically discover that there were several violations of the logical layers you didn't know about. I talk more about this in the Physical Layers patterns.
InfoQ: What do you see as the future of modularity for Java?
Kirk: Modularity is going to change how we develop and deliver software systems on the Java platform. From a development perspective, it fills a gap left by other major design paradigms. For delivering software, it marks the end of the monolithic and static platform. It's going to enable more powerful ecosystems to emerge where developers are able to easily provision modules from a repository.
Perhaps, given the level of excitement surrounding application storefronts in the mobile ecosystem, this repository will resemble something like an "enterprise module store." Some of these modules may be free while others may be available for a fee. It'll allow you to piece together your runtime environment from several different sources. At some point, perhaps the environment will assemble itself based on the infrastructure requirements of your application.
A complete listing of the book's patterns can be found at the book's website, (along with a mobile optimised version). A sample of the book is available, and the code for the pattern samples is available on GitHub. The book is available for purchase from Amazon in printed form, as well as in Kindle and iBooks electronic format.
This Q&A is based on the book, 'Java Application Architecture: Modularity Patterns with Examples Using OSGi' by Kirk Knoernschild, published by Pearson/Prentice Hall Professional, March 2012, ISBN 0321247132 For more info please visit this website.
About the Book Author
Kirk Knoernschild is a software developer with a passion for building great software. He takes a keen interest in design, architecture, application development platforms, agile development, and the IT industry in general, especially as it relates to software development. His recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi, was published in 2012, and introduces 18 patterns that help you design modular software. You can visit his website here.
About the Reviewer
Dr Alex Blewitt works at an investment bank in London, but still finds the time to catch up with the latest OSGi and Eclipse news. Despite having previously been an editor for EclipseZone and a nominee for Eclipse Ambassador in 2007, his day-to-day role involves neither Eclipse nor Java. In what little time he has left over, he spends with his young family and has been known to take them flying if the weather's nice.