The first steps to migrating an existing application to a plan or a PAR are the same: deciding on the bundles that make up the application and ensuring that their Import-Package, Import-Library, and Import-Bundle manifest headers are correct. Once you have the list of bundles that make up your application, you then decide whether you want to JAR them all into a single application file (PAR) or create a plan that simply lists the bundles by reference. Creating a plan is the recommend way to create an application, although PARs also have benefits that might suit your needs better, as described in the section called “Plan or PAR?”.
When migrating an existing application to the PAR packaging and deployment format or a plan, you consider modularity as the prime objective. Following the ideas discussed in Section 3.3, “A guide to forming bundles”, you refactor the application into multiple bundles. You may start conservatively with a small number of bundles and then further refactor those bundles.
If the original code is crafted following good software practices such as separation of concerns and use of well-defined interfaces, migration may involve modifying only configuration and packaging. In other words, your Java sources will remain unchanged. Even configuration is likely to change only slightly.
For example, the following diagram depicts a typical web application that has been refactored and
packaged as a PAR. The blue elements within the Application box constitute
the bundles of the application. Each of these bundles imports types from other bundles within
the PAR using Import-Package. The green elements in the left column represent
libraries installed on the dm Server. The PAR’s bundles reference these
libraries using Import-Library. The purple element in the left column
represents a bundle within the dm Server’s bundle repository which is imported by the DAO
bundle using Import-Bundle. In contrast to a traditional, monolithic
WAR deployment, the PAR format provides both a logical and physical application boundary
and simultaneously allows the application to benefit from both the OSGi container and the SpringSource dm Server.
Once you have refactored your existing application into separate OSGi bundles, you then must decide whether to package the bundles into a single PAR file or create a plan that lists the bundles by reference. As described in more detail in preceding sections of this guides, PARs and plans have similar benefits, such as:
- Scoping
- Atomicity, or the ability to deploy and control the bundles as a single unit
- Versioning
- Improved serviceability
Plans, the method most recommended by SpringSource to create your application, has the following added benefits:
- Guaranteed order of deployment, based on the order in which they are listed in the plan’s XML file
- Ease of sharing content between plans and updating individual plans without having to physically repackage, due to the artifacts being listed by reference.
- Ability to disable scoping and atomicity, if desired.
The main benefit of PARS is that, because they physically contain all the required artifacts, you know exactly what bundles are deployed when you deploy the PAR file, in contrast to plans that allow content to be substituted or lost.
For details about creating plans and PARs, see Section 4.3, “Creating Plans” and Section 4.2, “Creating PARs and WARs”, respectively.