<html><head>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   <title>5.2&nbsp;Migrating to a Plan or a PAR</title><link rel="stylesheet" href="css/stylesheet.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="Virgo Programmer Guide"><link rel="up" href="ch05.html" title="5.&nbsp;Migrating to OSGi"><link rel="prev" href="ch05.html" title="5.&nbsp;Migrating to OSGi"><link rel="next" href="ch06.html" title="6.&nbsp;Case Study: Migrating the Form Tags Sample Application"><!--Begin Google Analytics code--><script type="text/javascript">
			var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
			document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
		</script><script type="text/javascript">
			var pageTracker = _gat._getTracker("UA-2728886-3");
			pageTracker._setDomainName("none");
			pageTracker._setAllowLinker(true);
			pageTracker._trackPageview();
		</script><!--End Google Analytics code--></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.2&nbsp;Migrating to a Plan or a PAR</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch05.html">Prev</a>&nbsp;</td><th width="60%" align="center">5.&nbsp;Migrating to OSGi</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="ch06.html">Next</a></td></tr></table><hr></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="migrating-to-osgi-par-plan"></a>5.2&nbsp;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?">the section called &#8220;Plan or PAR?&#8221;</a>.
		</p><div class="section" lang="en"><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="3.4&nbsp;A Guide to Forming Bundles">Section&nbsp;3.4, &#8220;A Guide to Forming Bundles&#8221;</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&#8217;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&#8217;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" lang="en"><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 type="disc"><li>Scoping</li><li>Atomicity, or the ability to deploy and control the bundles as a single unit</li><li>Versioning</li><li>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 type="disc"><li>Guaranteed order of deployment, based on the order in which they are listed in the plan&#8217;s XML file</li><li>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>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="4.3&nbsp;Creating Plans">Section&nbsp;4.3, &#8220;Creating Plans&#8221;</a> and <a class="xref" href="ch04s02.html" title="4.2&nbsp;Creating PARs and Web Applications">Section&nbsp;4.2, &#8220;Creating PARs and Web Applications&#8221;</a>, respectively.
		   </p></div></div><!--Begin LoopFuse code--><script src="http://loopfuse.net/webrecorder/js/listen.js" type="text/javascript"></script><script type="text/javascript">
			_lf_cid = "LF_48be82fa";
			_lf_remora();
		</script><!--End LoopFuse code--><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch05.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="ch05.html">Up</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="ch06.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.&nbsp;Migrating to OSGi&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">&nbsp;6.&nbsp;Case Study: Migrating the Form Tags Sample Application</td></tr></table></div></body></html>