3.3 Why the SpringSource dm Server?

You could deploy a web application in a stand-alone servlet engine or application server. Or you could even deploy directly in an OSGi container such as Equinox. However, deploying in the SpringSource dm Server offers a number of key benefits that make it both more appealing and more suitable for enterprise application development.

3.3.1 Deployment options and migration paths

While many applications deployed in the SpringSource dm Server will take advantage of OSGi capabilities, not all applications need such sophistication. For example, development teams may initially choose to continue packaging existing web applications as standard WAR files and then gradually migrate toward a fully OSGi-based packaging and deployment model. The SpringSource dm Server makes such migrations easy for developers by supporting multiple packaging and deployment formats. These formats and migration strategies are discussed in greater detail in Chapter 6, Migrating to OSGi and Chapter 7, Case study: Migrating the Form Tags sample application..

3.3.2 Simplified development and deployment of OSGi-based applications

Prior to the release of the SpringSource dm Server, developing and deploying OSGi applications involved inherent complexity such as:

  • Obtaining OSGi bundles for popular Java libraries: For optimal benefits, every technology you use in an OSGi application must be packaged as OSGi bundles. Currently, this involves manually converting JAR files into bundles and making sure that any libraries needed by those bundles are also available as OSGi bundles.
  • Package management complexity: OSGi bundles use other bundles through Import-Package manifest headers. Many applications use a set of common technologies (e.g., an ORM solution, a web framework, etc.). Combining these two characteristics leads to duplicated configuration in the form of repeated and verbose Import-Package statements.
  • Lack of application-level isolation: In OSGi everything is a bundle, and all bundles share the same OSGi Service Registry. To highlight how conflicts can arise between applications and their services in this shared service registry, consider the following scenarios.
    • Application A is comprised of bundles B and C. In a standard OSGi environment, if you attempt to install two instances of the same version of application A (i.e., two sets of bundles B and C), a clash will occur, because you cannot deploy multiple bundles with the same Bundle-SymbolicName and Bundle-Version combination.
    • Application A1 is comprised of bundles B1 and C1. Similarly, application A2 is comprised of bundles B2 and C2. Each bundle has a unique combination of Bundle-SymbolicName and Bundle-Version. Bundles B1 and B2 both export service S which is imported by both C1 and C2. In contrast to the previous example, there is no conflict resulting from duplicate Bundle-SymbolicName/Bundle-Version combinations; however, there is a clash for the exported service S. Which service S will bundles C1 and C2 end up using once they are installed? Assuming bundles B1 and C1 are intended to work together, you would not want bundle C1 to get a reference to service S from bundle B2, because it is installed in a different logical application. On the contrary, you typically want bundle C1 to get a reference to service S exported by bundle B1, but in a standard OSGi environment this may not be the case.

Furthermore, since standard OSGi does not define a notion of an application as a set of bundles, you cannot deploy or undeploy an application and its constituent bundles as a single unit.

The SpringSource dm Server introduces a number of features to solve these issues:

  • It includes OSGi bundles for many popular Java libraries to get you started quickly with creating OSGi applications.
  • It introduces an OSGi library concept that obviates the need to duplicate verbose Import-Package statements.
  • It introduces the PAR packaging format which offers application-level isolation and deployment.

3.3.3 Enhanced diagnostics during deployment and in production

Identifying why an application won't deploy or which particular library dependencies are unsatisfied is the cause of many headaches! Similarly, production time errors that don't identify the root cause are all too familiar to Java developers. The dm Server was designed from the ground up to enable tracing and First Failure Data Capture (FFDC) that empower developers with precise information at the point of failure to fix the problem quickly.