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, ...