| <html><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Migrating to a Plan or a PAR</title><meta content="DocBook XSL Stylesheets V1.76.0" name="generator"><link rel="home" href="index.html" title="Virgo Programmer Guide"><link rel="up" href="ch05.html" title="Chapter 5. Migrating to OSGi"><link rel="prev" href="ch05.html" title="Chapter 5. Migrating to OSGi"><link rel="next" href="ch06.html" title="Chapter 6. Case Study: Migrating the Form Tags Sample Application"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><td align="left" width="20%"><a accesskey="p" href="ch05.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch06.html">Next</a></td></tr></table><hr></div><div class="section" title="Migrating to a Plan or a PAR"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="migrating-to-osgi-par-plan"></a>Migrating to a Plan or a PAR</h2></div></div></div><p> | |
| 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 <code class="code">Import-Package</code>, <code class="code">Import-Library</code>, and <code class="code">Import-Bundle</code> 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 <a class="xref" href="ch05s02.html#migrating-to-osgi-parplan-decide" title="Plan or PAR?">Plan or PAR?</a>. | |
| </p><div class="section" title="Creating the Application Bundles"><div class="titlepage"><div><div><h3 class="title"><a name="migrating-to-osgi-parplan-bundles"></a>Creating the Application Bundles</h3></div></div></div><p> | |
| 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 | |
| <a class="xref" href="ch03s04.html" title="A Guide to Forming Bundles">A Guide to Forming Bundles</a>, you refactor the application into multiple bundles. | |
| You may start conservatively with a small number of bundles and then further refactor those bundles. | |
| </p><p> | |
| 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. | |
| </p><p> | |
| For example, the following diagram depicts a typical web application that has been refactored and | |
| packaged as a PAR. The blue elements within the <span class="emphasis"><em>Application</em></span> box constitute | |
| the bundles of the application. Each of these bundles imports types from other bundles within | |
| the PAR using <code class="literal">Import-Package</code>. The green elements in the left column represent | |
| <span class="emphasis"><em>libraries</em></span> installed on the VTS. The PAR’s bundles reference these | |
| libraries using <code class="literal">Import-Library</code>. The purple element in the left column | |
| represents a bundle within the VTS’s bundle repository which is imported by the DAO | |
| bundle using <code class="literal">Import-Bundle</code>. 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 Virgo Server for Apache Tomcat. | |
| </p><div class="mediaobject"><img src="images/migrating-to-osgi-par-structure.png"></div><p> | |
| </p></div><div class="section" title="Plan or PAR?"><div class="titlepage"><div><div><h3 class="title"><a name="migrating-to-osgi-parplan-decide"></a>Plan or PAR?</h3></div></div></div><p> | |
| 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: | |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Scoping</li><li class="listitem">Atomicity, or the ability to deploy and control the bundles as a single unit</li><li class="listitem">Versioning</li><li class="listitem">Improved serviceability</li></ul></div><p> | |
| Plans, the method most recommended by us to create your application, has the following added benefits: | |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Guaranteed order of deployment, based on the order in which they are listed in the plan’s XML file</li><li class="listitem">Ease of sharing content between plans and updating individual plans without having to physically repackage, due to the artifacts being listed by reference.</li><li class="listitem">Ability to disable scoping and atomicity, if desired.</li></ul></div><p> | |
| 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. | |
| </p><p> | |
| For details about creating plans and PARs, see <a class="xref" href="ch04s03.html" title="Creating Plans">Creating Plans</a> and <a class="xref" href="ch04s02.html" title="Creating PARs and Web Applications">Creating PARs and Web Applications</a>, respectively. | |
| </p></div></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ch05.html">Prev</a> </td><td align="center" width="20%"><a accesskey="u" href="ch05.html">Up</a></td><td align="right" width="40%"> <a accesskey="n" href="ch06.html">Next</a></td></tr><tr><td valign="top" align="left" width="40%"> </td><td align="center" width="20%"><a accesskey="h" href="index.html">Home</a></td><td valign="top" align="right" width="40%"> </td></tr></table></div></body></html> |