<html><head> | |
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | |
<title>3. Deployment Architecture</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="index.html" title="Virgo Programmer Guide"><link rel="prev" href="ch02s03.html" title="2.3 Why the Virgo Server for Apache Tomcat?"><link rel="next" href="ch03s02.html" title="3.2 Dependency Types"><!--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">3. Deployment Architecture</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s03.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch03s02.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="architecture"></a>3. Deployment Architecture</h2></div></div></div><p> The Virgo Server for Apache Tomcat offers several choices when it comes to deploying applications. Each | |
choice offers certain advantages, and it is important to understand those in order to make | |
the right choice for your application. In this chapter, we take a closer look at the choices | |
offered, compare them, and provide guidelines in choosing the right one based on your | |
specific needs. </p><p> The VTS supports standard self-contained WAR files thus allowing you to | |
use the Virgo Server for Apache Tomcat as an enhanced web server. The VTS also supports the | |
<span class="emphasis"><em>Shared Libraries</em></span> WAR format which allows for slimmer WAR files that | |
depend on OSGi bundles instead of including JAR files inside the WAR. The <span class="emphasis"><em>Shared | |
Services</em></span> WAR format allows developers to further reduce the complexity of | |
standard WARs by deploying services and infrastructure bundles alongside the WAR. A shared | |
services WAR will then consume the services published by those bundles. To complete the | |
picture, the VTS supports the new OSGi-standard <span class="emphasis"><em>Web Application | |
Bundle</em></span> deployment format for web applications that builds on the benefits | |
provided by a shared services WAR. In addition to this, VTS provides | |
additional conveniences for developing and deploying Spring MVC-based web applications. </p><p>For applications consisting of multiple bundles and web applications, plans and the PAR | |
format are the primary deployment models that take advantage of OSGi capabilities. We will | |
explore all of these formats and their suitability later in this guide.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="architecture-deployment-formats"></a>3.1 Supported Deployment Formats</h2></div></div></div><p> The Virgo Server for Apache Tomcat supports applications packaged in the following formats: </p><div class="orderedlist"><ol type="1"><li><p><a class="link" href="ch03.html#architecture-raw-osgi-bundles" title="Raw OSGi Bundles">Raw OSGi Bundles</a></p></li><li><p><a class="link" href="ch03.html#architecture-wars" title="WAR Deployment Formats">Java EE WAR</a></p></li><li><p><a class="link" href="ch03.html#architecture-war-gemini" title="WARs and the Gemini Web Container">Web Application Bundles</a></p></li><li><p><a class="link" href="ch03.html#architecture-pars" title="PAR">PARs</a></p></li><li><p><a class="link" href="ch03.html#architecture-plans" title="Plans">Plans</a></p></li><li><p><a class="link" href="ch03.html#architecture-configurations" title="Configurations">Configurations</a></p></li></ol></div><p> When you deploy an application to the VTS, each deployment artifact | |
(e.g., a single bundle, WAR, PAR, or plan) passes through a deployment pipeline. This | |
deployment pipeline is responsible for processing applications of certain types (i.e., | |
application type). The 3.6.3.RELEASE release of the VTS natively | |
supports deployers analogous to each of the aforementioned packaging options. </p><p> Let’s take a closer look now at each of the supported deployment and packaging | |
options to explore which one is best suited to your application.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="architecture-raw-osgi-bundles"></a>Raw OSGi Bundles</h3></div></div></div><p> At its core, the Virgo Server for Apache Tomcat is an OSGi container. Thus any OSGi-compliant | |
bundle can be deployed directly on the VTS unmodified. You’ll | |
typically deploy an application as a single bundle or a set of stand-alone bundles | |
if you’d like to publish or consume services globally within the container via | |
the OSGi Service Registry. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="architecture-wars"></a>WAR Deployment Formats</h3></div></div></div><p> For Web Application Archives (WAR), the Virgo Server for Apache Tomcat provides support for the | |
following three formats. </p><div class="orderedlist"><ol type="1"><li><p><a class="link" href="ch03.html#architecture-standard-war" title="Standard WAR">Standard WAR</a></p></li><li><p><a class="link" href="ch03.html#architecture-shared-libraries-war" title="Shared Libraries WAR">Shared Libraries | |
WAR</a></p></li><li><p><a class="link" href="ch03.html#architecture-shared-services-war" title="Shared Services WAR">Shared Services | |
WAR</a></p></li></ol></div><p> Each of these formats plays a distinct role in the incremental migration path | |
from a standard Java EE WAR to an OSGi-ified web application.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="architecture-standard-war"></a>Standard WAR</h4></div></div></div><p> Standard WAR files are supported directly in the VTS. At | |
deployment time, the WAR file is transformed into an OSGi bundle and installed | |
into Tomcat. All the standard WAR contracts are honoured, and your existing WAR | |
files should just drop in and deploy without change. Support for standard, | |
unmodified WAR files allows you to try out the Virgo Server for Apache Tomcat on your existing | |
web applications and then gradually migrate toward the <span class="emphasis"><em>Shared | |
Libraries WAR</em></span> and <span class="emphasis"><em>Shared Services WAR</em></span> | |
formats. </p><p> In addition to the standard support for WARs that you would expect from | |
Tomcat, the VTS also enables the following features:</p><div class="orderedlist"><ol type="1"><li><p>Spring-driven load-time weaving (see Section 6.8.4, “Load-time weaving | |
with AspectJ in the Spring Framework").</p></li><li><p>Diagnostic information such as FFDC (first failure data | |
capture)</p></li></ol></div><p> The main benefit of this application style is familiarity -- developers know | |
how to create a WAR file! You can take advantage of the | |
VTS’s added feature set without modifying the | |
application. The application can also be deployed on other Servlet containers or | |
Java EE application servers.</p><p> You may choose this application style if the application is fairly simple and | |
small. You may also prefer this style even for large and complex applications as | |
a starting point and migrate to the other styles over time as discussed in <a class="xref" href="ch05.html" title="5. Migrating to OSGi">Chapter 5, <i>Migrating to OSGi</i></a> . </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="architecture-shared-libraries-war"></a>Shared Libraries WAR</h4></div></div></div><p> If you have experience with developing and packaging web applications using | |
the standard WAR format, you’re certainly familiar with the pains of | |
library bloat. So, unless you’re installing shared libraries in a common | |
library folder for your Servlet container, you have to pack all JARs required by | |
your web application in <code class="literal">/WEB-INF/lib</code>. Prior to the release of | |
the Virgo Server for Apache Tomcat, such library bloat has essentially been the norm for web | |
applications, but now there is a better solution! The Shared Libraries WAR | |
format reduces your application’s deployment footprint and eradicates | |
library bloat by allowing you to declare dependencies on libraries via standard | |
OSGi manifest headers such as <code class="literal">Import-Package</code> and <code class="literal">Require-Bundle</code> . The VTS provides additional | |
support for simplifying dependency management via the <code class="literal">Import-Library</code> and <code class="literal">Import-Bundle</code> manifest headers | |
which are essentially macros that get expanded into OSGi-compliant <code class="literal">Import-Package</code> statements. </p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="images/tip.gif"></td><th align="left">Tip</th></tr><tr><td align="left" valign="top"><p> For detailed information on which libraries are already available, check | |
out the <a class="ulink" href="http://www.springsource.com/repository" target="_top">SpringSource Enterprise Bundle Repository </a> . | |
</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="architecture-shared-services-war"></a>Shared Services WAR</h4></div></div></div><p> Once you’ve begun taking advantage of declarative dependency management | |
with a Shared Libraries WAR, you’ll likely find yourself wanting to take | |
the next step toward reaping further benefits of an OSGi container: sharing | |
services between your OSGi-compliant bundles and your web applications. By | |
building on the power and simplicity of Spring-DM, the <span class="emphasis"><em>Shared Services | |
WAR</em></span> format puts the OSGi Service Registry at your finger tips. As | |
a best practice you’ll typically publish services from your domain, | |
service, and infrastructure bundles via <code class="literal"><osgi:service ... | |
/></code> and then consume them in your web application’s | |
ApplicationContext via <code class="literal"><osgi:reference ... /></code>. Doing so | |
promotes programming to interfaces and allows you to completely decouple your | |
web-specific deployment artifacts from your domain model, service layer, etc., | |
and that’s certainly a step in the right direction. Of the three supported | |
WAR deployment formats, the Shared Services WAR is by far the most attractive in | |
terms of modularity and reduced overall footprint of your web applications. | |
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="architecture-war-gemini"></a>WARs and the Gemini Web Container</h4></div></div></div><p> | |
Virgo Server for Apache Tomcat fully supports the OSGi Web Applications standard. Using the | |
reference implementation from Gemini Web that was developed by SpringSource from | |
an offshoot of the original VTS codebase. This RI is now fully | |
integrated in VTS as the basis of the support for web | |
application deployment. | |
</p><p> | |
The OSGi Web Applications specification introduces the concept of a <span class="emphasis"><em>Web | |
Application Bundle</em></span>, which is a WAR that is also a bundle. The | |
specification defines how WAR files are transformed into bundles automatically | |
as needed. | |
</p><p> | |
You can find an introduction to the Web Container in blog entries written by | |
the Virgo team <a class="ulink" href="http://blog.springsource.com/2009/05/27/introduction-to-the-osgi-web-container/" target="_top">here</a> and <a class="ulink" href="http://blog.springsource.com/2009/06/01/what-the-osgi-web-container-means-for-dm-server/" target="_top">here</a>. </p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="architecture-war-gemini-extensions"></a>Extensions to the Web Container</h5></div></div></div><p> Virgo Server for Apache Tomcat provides a variety of extensions to the Web Container that | |
allow you to construct sophisticated applications. The table below | |
summarises the extensions that are available or in development. </p><div class="table"><a name="d0e576"></a><p class="title"><b>Table 3.1. </b></p><div class="table-contents"><table style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Feature</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Instrumentable ClassLoaders</td><td style="border-bottom: 1.0pt solid ; ">All web bundle ClassLoaders are instrumentable by | |
Spring’s load-time weaving infrastructure.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Support for exploded bundles/WARs</td><td style="border-bottom: 1.0pt solid ; ">Bundles/WARs in directory form can be deployed as Web | |
Application Bundles | |
</td></tr><tr><td style="border-right: 1.0pt solid ; ">Support for scanning TLDs in dependencies</td><td style="">As per the Web Application specification, all TLDs located | |
inside a web bundle are located using the rules defined in | |
the JSP 2.1 specification. In VTS, the | |
dependencies of a Web Application Bundle are also scanned for TLDs | |
following the rules outlined in JSP 2.1 | |
</td></tr></tbody></table></div></div><br class="table-break"></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="architecture-pars"></a>PAR</h3></div></div></div><p> A PAR is a standard JAR which contains all of the modules of your application | |
(e.g., service, domain, and infrastructure bundles as well as a WAR or web module | |
for web applications) in a single deployment unit. This allows you to deploy, | |
refresh, and undeploy your entire application as a single entity. If you are | |
familiar with Java EE, it is worth noting that a PAR can be considered a replacement | |
for an EAR (Enterprise Archive) within the context of an OSGi container. As an added | |
bonus, modules within a PAR can be refreshed independently and on-the-fly, for | |
example via the Virgo Eclipse IDE Tooling (see the Virgo Tools Guide). </p><p> Many of the benefits of the PAR format are due to the underlying OSGi | |
infrastructure, including: </p><div class="itemizedlist"><ul type="disc"><li><p> Fundamentally modularized applications: instead of relying on fuzzy | |
boundaries between logical modules in a monolithic application, this | |
style promotes physically separated modules in the form of OSGi bundles. | |
Then each module may be developed separately, promoting parallel | |
development and loose coupling.</p></li><li><p> Robust versioning of various modules: the versioning capability | |
offered by OSGi is much more comprehensive than alternatives. Each | |
module can specify a version range for each of its dependencies. Bundles | |
are isolated from each other in such a way that multiple versions of a | |
bundle may be used simultaneously in an application.</p></li><li><p> Improved manageability: each bundle may be deployed or undeployed in | |
a running application. This allows modifying the existing application to | |
fix bugs, improve performance, and even to add new features without | |
having to restart the application.</p></li></ul></div><p> Furthermore, PARs scope the bundles of your application within the | |
VTS. Scoping provides both a physical and logical application | |
boundary, effectively shielding the internals of your application from other PARs | |
deployed within the VTS. This means your application doesn’t | |
have to worry about clashing with other running applications (e.g., in the OSGi | |
Service Registry). You get support for load-time weaving, classpath scanning, | |
context class loading, etc., and the VTS does the heavy lifting for | |
you to make all this work seamlessly in an OSGi environment. If you want to take | |
full advantage of all that the Virgo Server for Apache Tomcat and OSGi have to offer, packaging and | |
deploying your applications as a PAR is a good choice, although plans are an even | |
better one, as described in the next section.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip: OSGi != multiple JARs"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="images/tip.gif"></td><th align="left">OSGi != multiple JARs</th></tr><tr><td align="left" valign="top"><p> Note that while physically separated modules can, in theory, be implemented | |
simply using multiple JARs, complex versioning requirements often make this | |
impractical. For example, consider the situation depicted in the diagram below. </p><div class="itemizedlist"><ul type="disc"><li><p>Bundle A depends on version 1.0.0 of bundle B and version 2.0.0 of | |
bundle C.</p></li><li><p>Bundle B depends on version 1.0.0 of bundle C.</p></li></ul></div><p> Suppose that versions 1.0.0 and 2.0.0 of bundle C are neither | |
backward nor forward compatible. Traditional monolithic applications cannot | |
handle such situations: either bundle A or bundle B would need reworking which | |
undermines truly independent development. OSGi’s versioning scheme enables | |
this scenario to be implemented in a robust manner. If it is desirable to rework | |
the application to share a single version of C, then this can be planned in and | |
is not forced. </p><div class="mediaobject"><img src="images/architecture-bundle-versioning.png"></div></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="architecture-plans"></a>Plans</h3></div></div></div><p> A plan is similar to a PAR in that it encapsulates all of the artifacts of your | |
application in a single deployment unit. The main difference, however, is that a | |
plan is simply an XML file that lists the artifacts of your application; a PAR, by | |
contrast, is an actual JAR file that physically contains the artifacts. Just like a | |
PAR, you deploy, refresh, and undeploy a plan as a single entity. We highly | |
recommends the use of plans for creating applications. </p><p> When you create a plan, you can specify that the included bundles and services | |
are in a scope that isolates them from the rest of Virgo Server for Apache Tomcat and its | |
deployments. This scoping ensures that the bundles wire to each other and see each | |
other’s services in preference to services from outside the scope. Scoping | |
also prevents application code from leaking into the global scope or scope of | |
another application. In addition, a plan can link the lifecycle of a group of | |
bundles together atomically, which ensures that start, stop, and uninstall | |
events on a single artifact in the plan are escalated to all artifacts in the plan. | |
You can, however, disable both of these features by simply setting an attribute in | |
the plan. </p><p> The general benefits of using plans are similar to those of using PARs; see <a class="link" href="ch03.html#architecture-pars" title="PAR">PAR</a> for details. Plans offer added benefits, | |
however, such as the ability to control the deployment order of your application: | |
the order in which you list artifacts in the plan’s XML file is the order in | |
which VTS deploys them. Additionally, because plans specify the | |
artifacts that make up an application by reference, it is easier to share artifacts | |
between plans as well as update individual parts of a plan without having to | |
physically repackage (re-JAR) it. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="architecture-configurations"></a>Configurations</h3></div></div></div><p>A Configuration is simply a Java properties file. When deployed it will be | |
recognised by the deployer and installed in to <span class="emphasis"><em>Configuration | |
Admin</em></span> for later use by your applications. VTS supports | |
both singleton (ManagedService) and factory (ManagedServiceFactory) configurations. | |
(see section 104.6 in the Compendium Specification) </p><p>For a singleton configuration the name that it will be installed under is its filename | |
minus the <code class="code">.properties</code> extension. Factory Configuration is supported by | |
specifying the <span class="emphasis"><em>service.factoryPid</em></span> property. In this case the actual PID will | |
be created by <span class="emphasis"><em>Configuration Admin</em></span> (see section 104.6 in the | |
Compendium Specification).</p><p>How to consume configuration data is discussed <a class="link" href="ch04s04.html" title="4.4 Creating and Using Configuration Artifacts">later</a>. </p></div></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="ch02s03.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch03s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2.3 Why the Virgo Server for Apache Tomcat? </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 3.2 Dependency Types</td></tr></table></div></body></html> |