Java Application Architecture: Modularity Patterns with Examples Using OSGi
Buy it now
One Minute Bottom Line
|You should read this book because it teaches you how to design modular Java enterprise software.|
The traditional software enterprise projects are monolithics but now with the modularization of a software project is possible to split the whole project in modules interconnected with the objective that each module can be designed, tested, managed, maintenance, and reused easier.
The author explains in the book, the logical design of software versus the physical design of software. He says that many teams of software spend a lot of time in the logical design and not much in the physical design but the logical design is equal of important than the physical design. This book is about the physical design that is how the architects divide a software system into a group of modules. In the Java platform, the unit of modularity is the JAR file and the physical design of software is the design, behavior and relationship of the JAR files of a software system.
The book has 3 parts. Part I (chapters 1 to 7) defines and describes the characteristics of modularity, Part II (chapters 8 to 12) is a collection of 5 groups of modularity patterns, and part III (chapters 13 to 17) illustrates some examples of Java platform code with OSGi framework that provides support for modularity. Also there are examples of Java SE, Scala (a functional language) and Groovy (a dynamic language) with OSGi.
In the first part of the book, named The Case for Modularity, the author explains clearly some features of the software modules such as the definition, granularity, weight, tension and reuse. In the modularity, each module is a separate element that combine together to make a large structure of software. The result of using the modularity, is that each module of the large and complex software projects can be designed, tested, managed, maintenance and reused easily. Also, the author explain us the relation among the modularity, the software architecture, and SOA (Service-oriented architecture), and how the developers and the architects have an important role in this process. The author focuses the book on modular design and presents us an interesting sample system applying several modular techniques in 7 refactoring steps to observe the advantages of the modularity.
In the second part of the book, named The Patterns, the author presents a collection of 18 Patterns of Modular Architecture (POMA). The patterns are classified in 5 groups of patterns such as Base Patterns, Dependency Patterns, Usability Patterns, Extensibility Patterns and Utility Patterns. The author says that would be possible to add more patterns and he hopes that the developer community will add more patterns with the time to the collection of 18 Patterns of Modular Architecture (POMA). The author Kirk Knoernschild has a website with information of the book and the readers can consult information about the collection of patterns there.
In the third part of the book, named POMA and OSGi, the author describes us the OSGi framework, that is the dynamic module system for the Java Platform. There is a brief introduction of OSGi, where a module is known as a bundle, and the developers can use the OSGi framework to manage the bundles that are Java JAR files with a manifest file including metadata that explains the bundle and its dependencies to the OSGi framework.
OSGi technology is well known in the embedded systems and networked devices market but for the enterprise developer is a obscure technology. Today, OSGi is a dinamic module system for the Java platform and is emergin as a viable technology in the enterprise, although some developers argue that it is too complex. Nowadays, there are few enterprise software systems using OSGi, but some examples of the power of OSGi are Glassfish (Open source application server), Eclipse Equinox (Open source IDE), and WebSphere (IBM WebSphere Application Server) that have adopted OSGi to be more dynamic. Of course, they are 2 application servers and 1 IDE. In the case of enterprise software , the modularity is starting and this book has the objective to contribute to this process.
Also, this third part has a final version of an example with the runtime benefits of the modularity, using the patterns described in the book, and a chapter with information about the future of OSGi.
There are examples about how to use OSGi with Java SE, OSGi with a functional programming language like Scala and OSGi with a dynamic programming language like Groovy.The book has a good appendix named Solid Principles of Class Design, based in the object-oriented paradigm, and many of these principles first appeared in the book of Robert Martin named Agile Software Development: Principles, Patterns, and Practices, published in 2002.
I highly recommend this book for the software developers and architects with interest developing modular enterprise software design because you will learn the bases of the modularity, that are the foundation and the first bricks of a building called enterprise software design.
Currently Java SE itself does not have a modular system. Oracle is developing a modular system called Jigsaw, that was planned to be included in Java SE 7.0, but it has been postponed for different reasons to Java SE 9.0 (probably in 2015). The goal of the Jigsaw project is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. Anyway, the 18 patterns of modular architecture an the theory of this book are useful for OSGi and Jigsaw when it will be available.
The author explains us that developing modular software can be made with modular tools like OSGi, or Jigsaw (when it will be available). Using a modular tool to develop modular software, give to the developers and architects the runtime model and the development model, but it does not guaranty to design modular software. It require that the architects understand the weight and the granularity of each module of a system, and use the correct methods to interconnect the modules of the system. In other words, designing high quality modular software is the work of the developers and architect and this book explains how to design modular software.
As well, the author explains us the future of OSGi and he considers that few software systems have been designed with modularity and OSGi in mind, but the ecosystem that is the environment where is applied OSGi needs to be large to support its existence. If the OSGi ecosystem flourish with developers developing modules, OSGi will have success in the enterprise market.
Finally, I am learning too this subject. I feel that this book is excellent for the theory and the bases of the modularity but will be necessary other books to complement the knowledge about SOA and OSGi. Please, to the readers of this revision, your opinions and suggestions about other books concerning SOA, OSGi and some other topic to complement this subject are welcome.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)