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.
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 5, Migrating to OSGi and Chapter 6, Case study: Migrating the Form Tags sample application.
Prior to the release of the SpringSource dm Server, developing and deploying OSGi applications involved inherent complexity such as:
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.
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.
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:
Import-Package statements.
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.