| <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.0.M05 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> |