Part 1. Spring DM basics
Welcome to Spring Dynamic Modules in Action. Spring Dynamic Modulesâa synthesis of Spring and OSGi-is the technology that can help you write better, more beautiful,
programs. In these first three chapters, we are going to discuss the basics of all three technologiesâSpring, OSGi, and Spring
DMâand by the end you should have a good idea of why these technologies can help address the thorny problems associated with
unmodular applications.
In chapter 1, we cover the concepts of Java modularity in generalâsince Spring DM and OSGi are primarily technologies that enabled modularityâthe
specifics of the Spring Framework, and the features of OSGi. We then move on to show you where Spring DM fits in, and how
its approach and its features simplify the development of standard Java applications in an OSGi environment. The concepts
covered are reinforced in later chapters, so if you want to get the flavor of the whole book, chapter 1 is a good place to start.
Chapter 2 is an OSGi primer, focusing on how you can take advantage of OSGi technology within your Java applications. It introduces
the main building blocks of OSGi: bundles, wiring, and services.
At last, in chapter 3, we are ready to get down to the main business of Spring DM. There is a lot to learn and we introduce all of the main features
and concepts hereâdependency injection, extenders, writing bundles container provisioning, fragment configuration, and application
development using Maven.
In part 2 we delve deeper into the main features of core Spring DM, covering each in a good amount of detail.
In part 3 we look at some more advanced topics surrounding the use of Spring DM.
Chapter 1. Modular development with Spring and OSGi
This chapter covers
- Javaâs limitations regarding modularity
- How OSGi builds on Java for better modularity
- How OSGi and Spring are complementary solutions
Spring DMâor Spring Dynamic Modules for OSGi Service Platforms, as itâs more formally calledâis about using the Spring programming model in OSGi applications. If youâre a Java programmer, you have probably heard of, or used, Springâthe dependency injection framework for Java. But what about OSGi? This dynamic module system for Java may be less familiar; but no matter, Spring DM is about OSGi for the masses, providing OSGiâs modularity features in a neat Spring-shaped package. You donât need to get too involved in the nitty-gritty of OSGi to benefit from its features.
In this book, weâll describe what Spring DM is, how to use it, and more importantly how to benefit from it. Because Spring DM is not only about using modular Java systems to get things to workâitâs about getting them to work well. Weâll also look at some of the implementation challenges involved in using Spring DM, challenges that boil down to OSGiâs strict classloading model. For instance, using object/relational mapping (ORM) tools or creating web applications can seem daunting in an OSGi environment, but never fearâweâre here to help!
In this chapter, after having covered the concepts of modularity, the specifics of the Spring Framework, and the features of OSGi, weâll show you where Spring DM fits in, and how its approach and its features simplify the development of standard Java applications in an OSGi environment. If youâre already familiar with OSGi and Spring, you can skip the next few sections and go to section 1.4, which introduces Spring DM.
1.1. Java modularity
We all fall in love with abstraction sooner or later. Abstract data types, polymorphism, and encapsulationâthese are all ideas that appeal to the engineers in us and mesh neatly with the old adage of keeping it simple, stupid. No man is an island, however, and code is no different. No matter how beautiful your codeâand letâs face it, we all like to think we write beautiful codeâit eventually has to interact with other code.
In this book, youâll learn how Spring DM and its OSGi substrate can be used to address the problems caused by unmanageable spaghetti code. But before we get to the cool technology, itâs worth reviewing what we mean by modularity and the kind of problems modular software is designed to solve.
1.1.1. What is modularity and what is it good for?
A modular application is, in essence, one thatâs divided into several pieces with the connections between the pieces being controlled and well defined. Itâs this limit on connections that reduces the impact of change and markedly improves things like testability.
But what is a connection? What creates connections, and how do you reduce them? The answers are clearly contingent upon technology, which in our case is Java.
1.1.2. Javaâthe end and the beginning
Java is great. We would argue itâs the best general-purpose programming language ever developed, for it addresses many of the deficiencies of languages that went before it. The first step toward modularity lies in the object-oriented features that the Java language offers: splitting applications into classes and enforcing encapsulation with interfaces and visibility modifiers (private, protected, and so on). Thatâs a good step, but it isnât enough.
Java EE also acknowledged the need for composite applications by introducing several kinds of deployment units: the Java Archive (JAR), which is the most common, but also the Web Archive (WAR) and the Enterprise Archive (EAR). But these archives, particularly the web and the enterprise ones, only allow you to split your application into coarse-grained components; they do nothing to enforce the program architecture that you know is required. This is a good step, but, again, it isnât enough, especially for large, complex systems and systems that need to be extensible or that want to promote reusability.
Are we facing a hopeless situation? Weâve been using Java for years, telling ourselves weâre developing well-designed applications. Was that a lie, or were we just daydreaming?
1.1.3. Are your applications really modular?
Why should we care about real modularity? Isnât there enough modularity in plain Java? And what would be the value proposition of modularity in any shape or form?
At stake is building robust, maintainable systems. Anyone can write and maintain Hello World, but no system is as simple as Hello World, and many are at the opposite extreme in terms of complexity. The drive toward ever more complex systems is inevitable in the digitally connected world that we now live in, but that complexity is now not something any individual can handle. Just as there are really no ârenaissance menâ todayâthe world of science is simply too broad and deepâcomplete understanding of todayâs systems is beyond even the most talented.
So for the question, âAre your applications really modular?â you should already know the answerâit will be defined by the degree of pain you feel when trying to make changes, or the degree of slippage you experience when trying to develop new functionality. If you donât know, the answer is almost certainly âno.â That may not matter if youâre a lone developer or part of a small team, ...