Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Tomcat in the enterprise

Learn where Tomcat fits, and doesn't, in your enterprise application stack

By Jeff Hanson, JavaWorld.com, 01/22/08

Page 2 of 4

EARs, WARs, JARs, and Java EE

A Java EE application may contain one or more Java EE components such as EJBs, Web modules, resource adapters, or J2EE application client modules. Each Java EE component can have an associated deployment descriptor -- an XML file that describes the component. Java enterprise components are deployed using the Java Archive (JAR) file format, which branches into additional formats to handle various component types.

The Java Archive (JAR) file format is based on the ZIP file format and enables you to bundle multiple Java EE components into a single file. A JAR file can contain Java class files, XML descriptor files, auxiliary resources, static HTML files, and other files associated with each Java EE component. A standard Java Web application is deployed in a Web Application Archive (WAR) file, which is a JAR file with the extension of .war. A standard Java EE application is deployed in an Enterprise Application Archive (EAR) file, which is a JAR file with an extension of .ear.

A WAR file is a specialized JAR file containing Web application components such as servlets, JSP files, HTML files, deployment descriptors, utility JAR files, etc. A WAR file can be deployed to a Web server such as Tomcat.

An EAR file is a specialized JAR file containing Java EE application components such as Web applications (WAR files), EJBs, resource adapters, etc. An EAR file can be deployed to a Java EE application server such as JBoss, WebLogic, or WebSphere. Java EE application servers load EAR files at runtime and deploy the components found within each file as Web applications, resource adapters, EJBs, and so on, based on the instructions found in each component's deployment descriptor.

Figure 2 illustrates the components found in many typical Java EE application server deployments.

Figure 2. Components of a typical Java EE application server deployment

An EAR file can contain multiple Web applications along with other resources and auxiliary components. Deploying an application as an EAR file within the structure of a Java EE application server environment enables the app server to isolate each Web application within a separate class-loading and resource-loading context. Web applications in the Java EE app server environment can share resources in common, such as utility class files.

In a Java EE environment, specialized containers are designated to handle component isolation and resource sharing. These containers are, in turn, managed by the application server. Containers provide an isolated context wherein Java EE components are deployed and execute. Containers provide an abstraction layer between the components, ensuring that they seldom interact directly. Instead, components can use the protocols and APIs of the container to interface with each other and with other application services. This layer of abstraction enables containers to provide ancillary services required by the component, such as pooling, transaction management, and state management.

Web applications vs. enterprise applications

For some, the confusion over Tomcat's definition points to the deeper question of what differentiates an enterprise application from a Web application. Traditionally, a Java enterprise application is defined as a combination of the following components and technologies:

• EAR files
• Java Servlets
• JavaServer Pages or JavaServer Faces
• Enterprise JavaBeans (EJB)
• Java Authentication and Authorization Service (JAAS)
• J2EE Connector Architecture
• JavaBeans Activation Framework (JAF)
• JavaMail
• Java Message Service (JMS)
• Java Persistence API (JPA)
• Java Transaction API (JTA)
• The Java Management Extensions (JMX) API
• Java API for XML Processing (JAXP)
• The Java API for XML-based RPC (JAX-RPC)
• The Java Architecture for XML Binding (JAXB)
• The SOAP with Attachments API for Java (SAAJ)
• Java Database Connectivity (JDBC) framework

A Java Web application, meanwhile, is said to combine a subset of Java enterprise application components and technologies, namely:

• WAR files
• Java Servlets
• JavaServer Faces or JavaServer Pages
• Java Database Connectivity (JDBC) framework

Popular frameworks such as Apache Struts, Spring, Hibernate, and others have obscured the traditional distinctions between Java enterprise and Java Web applications. Each new framework offers a slightly different view of how to accomplish the same tasks. Each framework attempts to solve a given set of challenges in a more efficient manner, possibly using a different set of underlying technologies.

Perhaps, this obscurity might be cleared up by observing the behavior of components deployed within different scenarios for a typical Java-based enterprise/Web application. These scenarios are discussed next.