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 3 of 4

Java EE application scenarios

In a typical Java EE Web application, an HTML client posts a request to a server where the request is handled by the Web container of the application server. The Web container invokes the servlet that is configured to handle the specific context of the request.

The initial HTML client request is illustrated in Figure 3.

Figure 3. Initial HTML client request

Once the servlet has received the initial request, some form of request dispatching ensues in order to perform the necessary business logic for completing the request.

One or more business services or components are then invoked to perform business logic, as illustrated in Figure 4.

Figure 4. Business services or components in the JEE architecture

Most business services or components require access to some form of data storage or information system. Oftentimes an abstraction layer between the business service and the data store is provided in order to protect against future changes in the data store. DAOs (data access objects) are often employed as data abstraction components in this situation, as shown in Figure 5.

Figure 5. DAOs are invoked to perform business logic (click to enlarge)

When the DAO invocation step is complete, the response data is passed back up the chain of command, usually as one or more Java beans. The Java beans are then passed to some type of state machine and/or view manager in order to organize and format the markup response.

When processing is complete for a given request, a formatted response is passed back to the HTML client, as illustrated in Figure 6.

Figure 6. A response is passed back to the HTML client (click to enlarge)

The scenario depicted in Figure 6 can be implemented using a very limited set of Java EE technologies, including servlets, JDBC, and JSP or another view technology. Tomcat or any Web server providing a servlet engine and JSP engine could be used as the app server in this scenario.

Scaling into complexity

Now, suppose we add a requirement to the application for asynchronous messaging between business service components. In a Java-based system, this would typically be handled using the Java Message Service (JMS), as shown in Figure 7.

Figure 7. JMS handles asynchronous messaging between business service components (click to enlarge)

Most Web servers do not offer JMS as a standard feature, but it is simple enough to add a JMS implementation to a Web server environment. So, once again, the application scenario depicted in Figure 7 could be handled quite easily with just a Web server providing a servlet engine and JSP engine.

Next, suppose we add the requirement for connectivity between business services and disparate enterprise information systems. Java EE offers the Java Connector Architecture as a common standard to meet this challenge. Using the Java Connector Architecture, the application architecture evolves to something similar to what you see in Figure 8.

Figure 8. JCA handles connectivity between business services and EISs (click to enlarge)

The architecture is now approaching a complexity that is arguably better suited for a Java EE application server. A Web server such as Tomcat could possibly be used in combination with other frameworks to meet the requirements, but system management and monitoring complications might make the server/framework mix impractical.

Finally, Figure 9 presents a moderately complex, Java-based, service-oriented architecture employing all of the technologies discussed so far, along with communication between multiple WAR deployments, EJBs, and Web services.

Figure 9. A moderately complex service-oriented architecture (click to enlarge)

The architecture in Figure 9 has entered the realm of complexity that requires a tested, scalable, manageable Java EE enterprise application server. Once again, a development team with the proper skill level could use Tomcat for the Web tier and piece together technologies and frameworks to support the business and data tiers. Whether that effort would be well spent is questionable, particularly given the option to use a full-fledged application server.