programmer-guide/src/migrating-to-osgi.xml - virgo/org.eclipse.virgo.documentation - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
 		"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
 <chapter id="migrating-to-osgi">
 	<title>Migrating to OSGi</title>
 	<para>
 		Taking on a new technology such as OSGi may seem a bit daunting at first,
 		but a proven set of migration steps can help ease the journey. Teams
 		wishing to migrate existing applications to run on the @tomcat.product.name@
 		will find that their applications typically fall into one of the following
 		categories.

 		<itemizedlist>
 			<listitem>
 				<para>
 					<emphasis role="bold">Web Application</emphasis>: for web applications,
 					this chapter provides an overview of the steps required to migrate
 					from a Standard WAR to a Shared Services WAR. Furthermore, the following
 					chapter provides a detailed case study involving the migration
 					of the Spring 3.0 Form Tags show case application.
 				</para>
 			</listitem>
 			<listitem>
 				<para>
 					<emphasis role="bold">Anything else</emphasis>: for any other type
 					of application, you will typically either deploy your application
 					as multiple individual bundles, as a single PAR file, or as a plan,
 					which is the recommended approach for deploying applications on
 					the @tomcat.product.name@. See <xref linkend="migrating-to-osgi-par-plan" /> for details.
 				</para>
 			</listitem>
 		</itemizedlist>

 	</para>

 	<section id="migrating-to-osgi-web">
 		<title>Migrating Web Applications</title>
 		<para>
 			Many applications may start with the standard WAR format for web applications and
 			gradually migrate to a more OSGi-oriented architecture. Since the @tomcat.product.name@
 			offers several benefits to all supported deployment formats, it provides a smooth
 			migration path. Of course, depending on your application&rsquo;s complexity and your
 			experience with OSGi, you may choose to start immediately with an OSGi-based
 			architecture.
 		</para>

 		<section id="migrating-to-osgi-web-standard-war">
 			<title>Standard WAR</title>
 			<para>
 				If you are not yet familiar with OSGi or simply want to deploy an existing web application on the @tomcat.product.name@,
 				you can deploy a standard WAR and leverage the @tomcat.product.name.short@ with a minimal learning curve. In fact reading the
 				<ulink url="../../virgo-user-guide/html/index.html">@tomcat.product.name@ User Guide</ulink>
 				is pretty much all that you need to do to get started. Furthermore, you will gain
 				familiarity with the @tomcat.product.name@, while preparing to take advantage of the other formats.
 			</para>
 		</section>
 		<section id="migrating-to-osgi-web-shared-libraries-war">
 			<title>Shared Libraries WAR</title>
 			<para>
 				The <emphasis>Shared Libraries WAR</emphasis>
 				format is the first step to reaping the benefits of OSGi. In this phase, you dip your toes into OSGi-based dependency
 				management by removing JAR files from the WAR and declaring dependencies on corresponding OSGi bundles.
 			</para>
 		</section>
 		<section id="migrating-to-osgi-web-shared-services-war">
 			<title>Shared Services WAR</title>
 			<para> In this phase, you take the next step toward a fully OSGi-based architecture by separating your web artifacts
 				(e.g., Servlets, Controllers, etc.) from the services they depend on.</para>
 		</section>
 		<section id="migrating-to-osgi-web-summary">
 			<title>Web Migration Summary</title>
 			<para>
 				The following diagram graphically depicts the migration path from a Standard WAR to a Shared Services WAR.
 				As you can see, the libraries (<emphasis>libs</emphasis>) move from within the deployment artifact
 				to the Bundle Repository.
 				Similarly, the services move from within the WAR to external bundles and are accessed via the
 				OSGi Service Registry. In addition, the overall footprint of the deployment artifact decreases
 				as you move towards a Shared Services WAR.
 				<mediaobject><imageobject><imagedata fileref="images/migration-path-war-to-shsrv.png" /></imageobject></mediaobject>
 			</para>
 		</section>

 	</section>

 <!-- ======================================================================= -->
 <!-- ======================================================================= -->

 	<section id="migrating-to-osgi-par-plan">
 		<title>Migrating to a Plan or a PAR</title>
 		<para>
 			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>Import-Package</code>, <code>Import-Library</code>, and <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 <xref linkend="migrating-to-osgi-parplan-decide" />.
 		</para>

 		<section id="migrating-to-osgi-parplan-bundles">
 		<title>Creating the Application Bundles</title>
 		<para>
 			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
 			<xref linkend="architecture-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.
 		</para>
 		<para>
 			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.
 		</para>
 		<para>
 			For example, the following diagram depicts a typical web application that has been refactored and
 			packaged as a PAR. The blue elements within the <emphasis>Application</emphasis> box constitute
 			the bundles of the application. Each of these bundles imports types from other bundles within
 			the PAR using <literal>Import-Package</literal>. The green elements in the left column represent
 			<emphasis>libraries</emphasis> installed on the @tomcat.product.name.short@. The PAR&rsquo;s bundles reference these
 			libraries using <literal>Import-Library</literal>. The purple element in the left column
 			represents a bundle within the @tomcat.product.name.short@&rsquo;s bundle repository which is imported by the DAO
 			bundle using <literal>Import-Bundle</literal>. 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 @tomcat.product.name@.
 			<mediaobject><imageobject><imagedata fileref="images/migrating-to-osgi-par-structure.png" /></imageobject></mediaobject>
 		</para>
 		</section>

 		<section id="migrating-to-osgi-parplan-decide">
 		   <title>Plan or PAR?</title>
 		   <para>
 			   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:
 		   </para>
 		   <itemizedlist>
 			<listitem>Scoping</listitem>
 			<listitem>Atomicity, or the ability to deploy and control the bundles as a single unit</listitem>
 			<listitem>Versioning</listitem>
 			<listitem>Improved serviceability</listitem>
 		   </itemizedlist>
 		   <para>
 			Plans, the method most recommended by us to create your application, has the following added benefits:
 		   </para>
 		   <itemizedlist>
 			<listitem>Guaranteed order of deployment, based on the order in which they are listed in the plan&rsquo;s XML file</listitem>
 			<listitem>Ease of sharing content between plans and updating individual plans without having to physically repackage, due to the artifacts being listed by reference.</listitem>
 			<listitem>Ability to disable scoping and atomicity, if desired.</listitem>
 		   </itemizedlist>
 		   <para>
 			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.
 		   </para>
 		   <para>
  		   	For details about creating plans and PARs, see <xref linkend="developing-applications-plans" /> and <xref linkend="developing-applications-packaging" />, respectively.
 		   </para>
 		</section>
 	</section>
 </chapter>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
	"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
	<chapter id="migrating-to-osgi">
	<title>Migrating to OSGi</title>
	<para>
	Taking on a new technology such as OSGi may seem a bit daunting at first,
	but a proven set of migration steps can help ease the journey. Teams
	wishing to migrate existing applications to run on the @tomcat.product.name@
	will find that their applications typically fall into one of the following
	categories.

	<itemizedlist>
	<listitem>
	<para>
	<emphasis role="bold">Web Application</emphasis>: for web applications,
	this chapter provides an overview of the steps required to migrate
	from a Standard WAR to a Shared Services WAR. Furthermore, the following
	chapter provides a detailed case study involving the migration
	of the Spring 3.0 Form Tags show case application.
	</para>
	</listitem>
	<listitem>
	<para>
	<emphasis role="bold">Anything else</emphasis>: for any other type
	of application, you will typically either deploy your application
	as multiple individual bundles, as a single PAR file, or as a plan,
	which is the recommended approach for deploying applications on
	the @tomcat.product.name@. See <xref linkend="migrating-to-osgi-par-plan" /> for details.
	</para>
	</listitem>
	</itemizedlist>

	</para>

	<section id="migrating-to-osgi-web">
	<title>Migrating Web Applications</title>
	<para>
	Many applications may start with the standard WAR format for web applications and
	gradually migrate to a more OSGi-oriented architecture. Since the @tomcat.product.name@
	offers several benefits to all supported deployment formats, it provides a smooth
	migration path. Of course, depending on your application’s complexity and your
	experience with OSGi, you may choose to start immediately with an OSGi-based
	architecture.
	</para>

	<section id="migrating-to-osgi-web-standard-war">
	<title>Standard WAR</title>
	<para>
	If you are not yet familiar with OSGi or simply want to deploy an existing web application on the @tomcat.product.name@,
	you can deploy a standard WAR and leverage the @tomcat.product.name.short@ with a minimal learning curve. In fact reading the
	<ulink url="../../virgo-user-guide/html/index.html">@tomcat.product.name@ User Guide</ulink>
	is pretty much all that you need to do to get started. Furthermore, you will gain
	familiarity with the @tomcat.product.name@, while preparing to take advantage of the other formats.
	</para>
	</section>
	<section id="migrating-to-osgi-web-shared-libraries-war">
	<title>Shared Libraries WAR</title>
	<para>
	The <emphasis>Shared Libraries WAR</emphasis>
	format is the first step to reaping the benefits of OSGi. In this phase, you dip your toes into OSGi-based dependency
	management by removing JAR files from the WAR and declaring dependencies on corresponding OSGi bundles.
	</para>
	</section>
	<section id="migrating-to-osgi-web-shared-services-war">
	<title>Shared Services WAR</title>
	<para> In this phase, you take the next step toward a fully OSGi-based architecture by separating your web artifacts
	(e.g., Servlets, Controllers, etc.) from the services they depend on.</para>
	</section>
	<section id="migrating-to-osgi-web-summary">
	<title>Web Migration Summary</title>
	<para>
	The following diagram graphically depicts the migration path from a Standard WAR to a Shared Services WAR.
	As you can see, the libraries (<emphasis>libs</emphasis>) move from within the deployment artifact
	to the Bundle Repository.
	Similarly, the services move from within the WAR to external bundles and are accessed via the
	OSGi Service Registry. In addition, the overall footprint of the deployment artifact decreases
	as you move towards a Shared Services WAR.
	<mediaobject><imageobject><imagedata fileref="images/migration-path-war-to-shsrv.png" /></imageobject></mediaobject>
	</para>
	</section>

	</section>

	<!-- ======================================================================= -->
	<!-- ======================================================================= -->

	<section id="migrating-to-osgi-par-plan">
	<title>Migrating to a Plan or a PAR</title>
	<para>
	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>Import-Package</code>, <code>Import-Library</code>, and <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 <xref linkend="migrating-to-osgi-parplan-decide" />.
	</para>

	<section id="migrating-to-osgi-parplan-bundles">
	<title>Creating the Application Bundles</title>
	<para>
	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
	<xref linkend="architecture-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.
	</para>
	<para>
	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.
	</para>
	<para>
	For example, the following diagram depicts a typical web application that has been refactored and
	packaged as a PAR. The blue elements within the <emphasis>Application</emphasis> box constitute
	the bundles of the application. Each of these bundles imports types from other bundles within
	the PAR using <literal>Import-Package</literal>. The green elements in the left column represent
	<emphasis>libraries</emphasis> installed on the @tomcat.product.name.short@. The PAR’s bundles reference these
	libraries using <literal>Import-Library</literal>. The purple element in the left column
	represents a bundle within the @tomcat.product.name.short@’s bundle repository which is imported by the DAO
	bundle using <literal>Import-Bundle</literal>. 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 @tomcat.product.name@.
	<mediaobject><imageobject><imagedata fileref="images/migrating-to-osgi-par-structure.png" /></imageobject></mediaobject>
	</para>
	</section>

	<section id="migrating-to-osgi-parplan-decide">
	<title>Plan or PAR?</title>
	<para>
	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:
	</para>
	<itemizedlist>
	<listitem>Scoping</listitem>
	<listitem>Atomicity, or the ability to deploy and control the bundles as a single unit</listitem>
	<listitem>Versioning</listitem>
	<listitem>Improved serviceability</listitem>
	</itemizedlist>
	<para>
	Plans, the method most recommended by us to create your application, has the following added benefits:
	</para>
	<itemizedlist>
	<listitem>Guaranteed order of deployment, based on the order in which they are listed in the plan’s XML file</listitem>
	<listitem>Ease of sharing content between plans and updating individual plans without having to physically repackage, due to the artifacts being listed by reference.</listitem>
	<listitem>Ability to disable scoping and atomicity, if desired.</listitem>
	</itemizedlist>
	<para>
	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.
	</para>
	<para>
	For details about creating plans and PARs, see <xref linkend="developing-applications-plans" /> and <xref linkend="developing-applications-packaging" />, respectively.
	</para>
	</section>
	</section>
	</chapter>