The SpringSource Application Platform support three kinds of application architectures: regular WAR, WAR with shared libraries, and OSGi-based applications. Each of these styles improves upon the prior one and offers increasing number of advantages. In this section, we take a closer look at all these styles and discuss their suitability for a target application.
In this application style, you create a regular web application packaged as a WAR file. The SpringSource Application Platform can deploy it in a normal fashion. In this kind of deployment, the platform approximates the behavior to match that of Tomcat as well as enabling the following features:
- Spring-driven LTW (see Section 6.8.4, “Load-time weaving with AspectJ in the Spring Framework").
- Diagnostic information such as FFDC is provided.
The main benefit of this application style is familiarity--everyone knows how to create a WAR file! You can take advantages of the platform's capability without modifying the application. The application can also be deployed on other web- or application-servers.
You may choose this application style if the application is fairly simple and small. You may also prefer this style even for large and complex applications as a starting point and migrate to the other styles over time as discussed in Chapter 7, Migrating to OSGi.
In this application style, you create the web application as a WAR file. However, unlike the regular WAR file, you do not include dependent JARs. Instead, you specify the required packages and the platform will make the associated jars available to the application.
Compared to regular WAR application, this style offers reduced package size, since the WAR file no longer contains the required jars. However, the main benefit of this application style is to serve as a step in migrating a regular WAR application to the OSGi-styled application as we see next.
This application style takes full advantage of the application platform's capabilities. This style differs from the previous one in a few significant ways. Firstly, the application is composed of various OSGi bundles instead of one monolithic distribution. Secondly, each bundle exposes a set of types and services that other bundles may use, thus controlling the public interface to that bundle.
Most of the benefits of this style are due to the underlying OSGi infrastructure. The main benefits include:
- Fundamentally modularized applications: instead of relying on fuzzy boundaries between logical modules in a monolithic application, this style promotes physically separated modules in the form of OSGi bundles. Then each module may be developed separately, promoting parallel development and loose coupling.
- Robust versioning of various modules: the versioning capability offered by OSGi is much more comprehensive that any alternatives. Each module can specify a version range for each of its dependencies. Bundles are isolated from each other in such a way that multiple versions of a bundle may be used simultaneously in an application.
- Improved serviceability: each bundle may be deployed or undeployed in a running application. This allows modifying the existing application to fix bugs, improve performance, and even to add new features without having to restart the application.
![[Tip]](images/tip.gif) | OSGi != multiple JARs |
|---|---|
|
Note that while physically separated modules discussed earlier can, in theory,
be implemented simply using multiple jars with each
representing a module, complex versioning requirements often makes this impractical.
For example, consider a situation shown in the figure below,
where version 1.0.0 of bundle A depends on version 1.0.0 of bundle B and version 2.0.0 of
bundle C, while bundle B depends on 1.0.0 version of bundle C.
Suppose that version 1.0.0 and 2.0.0 of C are not
backward or forward compatible. Regular monolithic applications
cannot handle such situations: either bundle A or bundle B would need reworking
which undermines truly independent development.
OSGi's versioning scheme enables this scenario to be implemented in a
robust manner. If it is desirable to rework the application to share a single version of C,
then this can be planned in and is not forced.
|
