| <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 Web Server?"><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 Web Server | |
| 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 VWS supports standard self-contained WAR files thus allowing you to use the Virgo Web Server | |
| as an enhanced web server. The VWS 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 VWS supports the new OSGi-standard | |
| <span class="emphasis"><em>Web Bundle</em></span> | |
| deployment format for web applications that builds on the benefits provided by a shared services WAR. In addition | |
| to this VWS 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 Web Server | |
| 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 Bundles</a></p></li><li><p><a class="link" href="ch03.html#architecture-pars" title="PAR">PAR</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 VWS, 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 2.1.1.RELEASE release of the VWS 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 for your applications. | |
| </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 Web Server | |
| is an OSGi container. Thus any OSGi-compliant bundle can be deployed directly on the VWS 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 Web Server | |
| 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 VWS. At deployment time, the WAR file is | |
| transformed into an OSGi bundle and installed into Tomcat. All the standard WAR contracts are honored, 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 Web Server 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 VWS 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 -- everyone knows how to create a WAR file! You can | |
| take advantage of the VWS’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 Web Server, 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 VWS 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 Web Server 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 VWS codebase. This RI is now fully | |
| integrated in VWS as the basis of the support for web application deployment. | |
| </p><p> | |
| The Web Container 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 VWS 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 Web Server provides a variety of extensions to the Web Container that allow you to construct sophisticated applications. | |
| The table below, summarizes the extensions that are available or in development. | |
| </p><div class="table"><a name="d0e525"></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><th style="border-bottom: 1.0pt solid ; ">Notes</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Auto-import of system packages</td><td style="border-bottom: 1.0pt solid ; ">All packages exported by the system bundle are automatically imported by web bundles</td><td style="border-bottom: 1.0pt solid ; ">This feature is being discussed for inclusion in the specification</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Instrumentable ClassLoaders</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">All web bundle ClassLoaders are instrumentable by Spring’s load-time weaving infrastructure.</td><td style="border-bottom: 1.0pt solid ; "> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Support for exploded bundles/WARs</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Bundles/WARs in directory form can be deployed as web bundles</td><td style="border-bottom: 1.0pt solid ; "> </td></tr><tr><td style="border-right: 1.0pt solid ; ">Support for scanning TLDs in dependencies</td><td style="border-right: 1.0pt solid ; ">As per the Web Container specification, all TLDs located inside a web bundle are located using the rules | |
| defined in the JSP 2.1 specification. In VWS, the dependencies of a web bundle are also scanned | |
| for TLDs following the rules outlined in JSP 2.1</td><td class="auto-generated" style=""> </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-web-bundles"></a>Web Modules</h3></div></div></div><p> | |
| Web Modules have been removed in favour of war files and web bundles following the OSGi Web Applications specification. | |
| We believe our users will benefit more from a standard model than one that is VWS-specific. | |
| </p></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 Web Server Tool Suite (see <a class="xref" href="ch07.html" title="7. Tooling">Chapter 7, <i>Tooling</i></a>). | |
| </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 any 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 serviceability: 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> | |
| </p><p> Furthermore, PARs scope the modules of your application within the VWS. Scoping provides both a | |
| physical and logical application boundary, effectively shielding the internals of your application from other PARs deployed | |
| within the VWS. 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 VWS 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 Web Server 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 Web Server | |
| 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 install, | |
| 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 updating 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 VWS deploys them. | |
| Additionally, because plans specify the artifacts that make up an application by reference, it is easier to share content | |
| 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. The name that it will be installed under or PID | |
| (Persistent Identity) will be the name of the properties file less any extension. 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 Web Server? </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> |