Spring Dynamic Modules in Action

Andy Piper, Arnaud Cogoluegnes, Thierry Templier

• Verlag: Manning
• Jahr: 2010
• ISBN:
  9781638351481
• Thema: Computer Science
• Thema: Programming in Java

Java EE developers increasingly want to utilize OSGi to develop modular applications for component and service-based architectures. But tools required for OSGi implementation have been slow to develop. Spring Dynamic Modules (Spring DM) is a framework that simplifies the creation of component and service-oriented architectures with OSGi, to build modular Java applications using the powerful Spring framework. Spring Dynamic Modules in Action presents the fundamental concepts of OSGi-basedapps and maps them to the familiar ideas of the Spring framework. Then, it teaches the techniques and concepts required to develop stable, flexible enterprise apps. Along the way, readers will learn to incorporate other topics including dependency injection and unit testing in an OSGi-based environment. Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book.

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