<html><head>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   <title>2.3&nbsp;Why the Virgo Server for Apache Tomcat?</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="ch02.html" title="2.&nbsp;Introduction to the Virgo Server for Apache Tomcat"><link rel="prev" href="ch02s02.html" title="2.2&nbsp;What is the Virgo Server for Apache Tomcat?"><link rel="next" href="ch03.html" title="3.&nbsp;Deployment Architecture"><!--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">2.3&nbsp;Why the Virgo Server for Apache Tomcat?</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s02.html">Prev</a>&nbsp;</td><th width="60%" align="center">2.&nbsp;Introduction to the Virgo Server for Apache Tomcat</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="ch03.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="introduction-why"></a>2.3&nbsp;Why the Virgo Server for Apache Tomcat?</h2></div></div></div><p>
			You could deploy a web application in a stand-alone servlet engine or application server.
			Or you could even deploy directly in an OSGi container such as Equinox. However,
			deploying in the Virgo Server for Apache Tomcat offers a number of key benefits that make it both more
			appealing and more suitable for enterprise application development.
		</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="introduction-unified-deployment"></a>Deployment Options and Migration Paths</h3></div></div></div><p>
				While many applications deployed in the Virgo Server for Apache Tomcat will take advantage
				of OSGi capabilities, not all applications need such sophistication.
				For example, development teams may initially choose to continue packaging
				existing web applications as standard WAR files and then gradually migrate
				toward a fully OSGi-based packaging and deployment model. The Virgo Server for Apache Tomcat
				makes such migrations easy for developers by supporting multiple packaging
				and deployment formats. These formats and migration strategies are discussed
				in greater detail in <a class="xref" href="ch05.html" title="5.&nbsp;Migrating to OSGi">Chapter&nbsp;5, <i>Migrating to OSGi</i></a> and
				<a class="xref" href="ch06.html" title="6.&nbsp;Case Study: Migrating the Form Tags Sample Application">Chapter&nbsp;6, <i>Case Study: Migrating the Form Tags Sample Application</i></a>. 
			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="introduction-simplified-deployment"></a>Simplified Development and Deployment of OSGi-based Applications</h3></div></div></div><p>
				Prior to the release of the Virgo Server for Apache Tomcat, developing and deploying OSGi
				applications involved inherent complexity such as:
			</p><div class="itemizedlist"><ul type="disc"><li><span class="emphasis"><em>Obtaining OSGi bundles for popular Java libraries:</em></span>
					For optimal benefits, every technology you use in an OSGi application must
					be packaged as OSGi bundles. Currently, this involves manually converting
					JAR files into bundles and making sure that any libraries needed by those
					bundles are also available as OSGi bundles. The SpringSource Enterprise Bundle Repository is a good source of
					popular pre-bundled libraries.
				</li><li><span class="emphasis"><em>Package management complexity:</em></span>
					OSGi bundles use other bundles through <code class="code">Import-Package</code> manifest headers.
					Many applications use a set of common technologies (e.g., an ORM solution,
					a web framework, etc.). Combining these two characteristics leads to duplicated
					configuration in the form of repeated and verbose <code class="code">Import-Package</code> statements.
				</li><li><span class="emphasis"><em>Lack of application-level isolation:</em></span>
					In OSGi everything is a bundle, and all bundles share the same OSGi Service Registry.
					To highlight how conflicts can arise between applications and their services in this
					shared service registry, consider the following scenarios.
					<div class="itemizedlist"><ul type="circle"><li>
							Application <code class="code">A</code> is comprised of bundles <code class="code">B</code> and <code class="code">C</code>. 
							In a standard OSGi environment, if you attempt to install two instances of the same
							version of application <code class="code">A</code> (i.e., two sets of bundles <code class="code">B</code> and
							<code class="code">C</code>), a clash will occur, because you cannot deploy multiple bundles with
							the same <code class="code">Bundle-SymbolicName</code> and <code class="code">Bundle-Version</code> combination.
						</li><li>
							Application <code class="code">A1</code> is comprised of bundles <code class="code">B1</code> and <code class="code">C1</code>. 
							Similarly, application <code class="code">A2</code> is comprised of bundles <code class="code">B2</code> and <code class="code">C2</code>.
							Each bundle has a unique combination of <code class="code">Bundle-SymbolicName</code> and <code class="code">Bundle-Version</code>.
							Bundles <code class="code">B1</code> and <code class="code">B2</code> both export service <code class="code">S</code> which
							is imported by both <code class="code">C1</code> and <code class="code">C2</code>. In contrast to the previous
							example, there is no conflict resulting from duplicate 
							<code class="code">Bundle-SymbolicName</code>/<code class="code">Bundle-Version</code> combinations; however,
							there is a clash for the exported service <code class="code">S</code>. 
							Which service <code class="code">S</code> will bundles <code class="code">C1</code> and <code class="code">C2</code> end up
							using once they are installed?
							Assuming bundles <code class="code">B1</code> and <code class="code">C1</code> are intended to work together, 
							you would not want bundle <code class="code">C1</code> to get a reference to service <code class="code">S</code>
							from bundle <code class="code">B2</code>, because it is installed in a different logical application.
							On the contrary, you typically want bundle <code class="code">C1</code> to get a reference to 
							service <code class="code">S</code> exported by bundle <code class="code">B1</code>, but in a standard OSGi environment
							this may not be the case.
						</li></ul></div></li></ul></div><p>
				Furthermore, since standard OSGi does not define a notion of an application as a set of bundles,
				you cannot deploy or undeploy an application and its constituent bundles as a single unit.
			</p><p>
				The Virgo Server for Apache Tomcat introduces a number of features to solve these issues:
			</p><div class="itemizedlist"><ul type="disc"><li>
					A full set of OSGi bundles for many popular Java libraries to get you
					started quickly with creating OSGi applications.
				</li><li>
					An OSGi library concept that obviates the need to
					duplicate verbose <code class="code">Import-Package</code> statements.
				</li><li>
					The PAR packaging format which offers
					application-level isolation and deployment.
				</li><li>
					The concept of a plan, which is an XML file that lists a collection of bundles that Virgo Server for Apache Tomcat should load together as a single application.  Conceptually, plans are very like PARs, except that a plan describes the contents of the application rather than a PAR that actually contains them.
				</li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="introduction-diagnostics"></a>Enhanced Diagnostics During Deployment and in Production</h3></div></div></div><p>
			    Identifying why an application won&#8217;t deploy or which particular library
			    dependencies are unsatisfied is the cause of many headaches!
			    Similarly, production time errors that don&#8217;t identify the root cause are
			    all too familiar to Java developers. The VTS was designed from the
			    ground up to enable tracing and First Failure Data Capture (FFDC) that
			    empower developers with precise information at the point of failure to
			    fix the problem quickly.
			</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="ch02s02.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="ch03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.2&nbsp;What is the Virgo Server for Apache Tomcat?&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">&nbsp;3.&nbsp;Deployment Architecture</td></tr></table></div></body></html>