2.3 Why the Virgo Tomcat Server?
Prev | 2. Introduction to the Virgo Tomcat Server | Next

## 2.3 Why the Virgo Tomcat Server?

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 Tomcat Server offers a number of key benefits that make it both more appealing and more suitable for enterprise application development.

### Deployment options and migration paths

While many applications deployed in the Virgo Tomcat Server 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 Tomcat Server makes such migrations easy for developers by supporting multiple packaging and deployment formats. These formats and migration strategies are discussed in greater detail in Chapter 5, Migrating to OSGi and Chapter 6, Case study: Migrating the Form Tags sample application.

### Simplified development and deployment of OSGi-based applications

Prior to the release of the Virgo Tomcat Server, developing and deploying OSGi applications involved inherent complexity such as:

- Obtaining OSGi bundles for popular Java libraries: 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.
- Package management complexity: OSGi bundles use other bundles through `Import-Package` 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 `Import-Package` statements.
- Lack of application-level isolation: 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.
  - Application `A` is comprised of bundles `B` and `C`. In a standard OSGi environment, if you attempt to install two instances of the same version of application `A` (i.e., two sets of bundles `B` and `C`), a clash will occur, because you cannot deploy multiple bundles with the same `Bundle-SymbolicName` and `Bundle-Version` combination.
  - Application `A1` is comprised of bundles `B1` and `C1`. Similarly, application `A2` is comprised of bundles `B2` and `C2`. Each bundle has a unique combination of `Bundle-SymbolicName` and `Bundle-Version`. Bundles `B1` and `B2` both export service `S` which is imported by both `C1` and `C2`. In contrast to the previous example, there is no conflict resulting from duplicate `Bundle-SymbolicName`/`Bundle-Version` combinations; however, there is a clash for the exported service `S`. Which service `S` will bundles `C1` and `C2` end up using once they are installed? Assuming bundles `B1` and `C1` are intended to work together, you would not want bundle `C1` to get a reference to service `S` from bundle `B2`, because it is installed in a different logical application. On the contrary, you typically want bundle `C1` to get a reference to service `S` exported by bundle `B1`, but in a standard OSGi environment this may not be the case.

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.

The Virgo Tomcat Server introduces a number of features to solve these issues:

- A full set of OSGi bundles for many popular Java libraries to get you started quickly with creating OSGi applications.
- An OSGi library concept that obviates the need to duplicate verbose `Import-Package` statements.
- The PAR packaging format which offers application-level isolation and deployment.
- The concept of a plan, which is an XML file that lists a collection of bundles that Virgo Tomcat Server 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.

### Enhanced diagnostics during deployment and in production

Identifying why an application won’t deploy or which particular library dependencies are unsatisfied is the cause of many headaches! Similarly, production time errors that don’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.

Prev | Up | Next
2.2 What is the Virgo Tomcat Server? | Home | 3. Deployment Architecture