The Big Picture: J2EE

Chapter 1 - Apache and Jakarta Tomcat byVivek Chopra, Ben Galbraithet al. Wrox Press 2003 The Big Picture: J2EE As a servlet container, Tomcat is a key component of a larger set of standards collectively referred to as the Java 2 Platform, Enterprise Edition (J2EE). J2EE defines a group of Java-based code libraries (called APIs in the Java world) that are suited to creating web applications for the enterprise (that is, a large company). To be sure, companies of any size can take advantage of the J2EE technologies, but J2EE is especially designed to solve the problems associated with the creation of large software systems. Java developers can download all of the J2EE APIs in a single ZIP archive, which comes complete with binaries and documentation. Distributed Systems We saw in the previous section that J2EE is designed with the creation of large software systems in mind. You, the reader, may ask, "What is so different about large software systems versus small systems?" The answer lies in the notion of distributed systems. A distributed system is one in which the various components of the system are distributed across multiple different machines. For example, in a given web application, one server might handle receiving and responding to HTTP requests while another server handles all the business logic, and another server handles all the database I/O: So why create a distributed system? Large web applications and enterprise systems can have enormous demands placed upon them. Frequently, these demands are larger than a single server can meet. While one may be tempted to simply upgrade the server, adding more processors and more memory to it, these upgrades can only stretch the server's capacity so far. Every server, no matter how expandable and efficient it may be, will run up against limitations. In these situations, where a single server simply cannot meet the needs of a software system, a distributed system is ideal. Multiple servers can work together to meet demands that a single server could not. But, why bother creating a distributed system? Why not just copy the same application and deploy it on multiple servers? Surely load balancing - splitting up the requests amongst the different servers - can then handle the load? It turns out that by separating the different logical components of an application, system administrators are free to tune the various components of the distributed system according to their unique needs. For example, the servers that read and write to the database will require different optimizations than those servers which are communicating with web clients via HTTP over TCP. The J2EE APIs Creating the distributed systems that we've described in the preceding paragraphs is not an easy task. We mentioned a few paragraphs ago that J2EE is a collection of code libraries called APIs. The J2EE APIs are designed to work together to simplify the creation of robust and efficient distributed systems. Here is a list of some of the key J2EE technologies and a brief description of each: J2EE API Description Enterprise JavaBeans (EJB) EJB technology provides a simple mechanism for creating distributed business logic components. EJB authors follow a simple pattern to write business logic and the rest of the low-level details relating to lifecycle, distribution, persistence, and so on are handled automatically. Java Message Service (JMS) JMS provides asynchronous messaging capability to J2EE applications. Java Naming and Directory Service (JNDI) JNDI enables J2EE applications to communicate with registries and directories. A registry/directory is a centralized location for storing business information. JNDI supports the industry standard LDAP protocol and interfaces with many other popular registry standards. JNDI makes it possible to centralize the configuration of a distributed system. Servlets As explained earlier in this chapter, servlets work with special servers called servlet containers to process HTTP requests and send HTTP responses. Servlets often work directly with EJBs. JavaServer Pages (JSP) JSP technology is an alternative, HTML-like interface for creating servlets. At runtime, the servlet container converts a JSP into a servlet. Java Transaction API (JTA) JTA enables a web application to gracefully handle failures in one or more of its components by establishing transactions. During a transaction, multiple events can occur, and if any one of them fails, the state of the application can be rolled back to how it was before the transaction began. This technology provides the robustness of relational database transactional technology across an entire distributed application. CORBA CORBA technology in Java enables J2EE web applications to communicate with distributed components written in other languages that support the language-independent CORBA standard. JDBC JDBC enables Java programs to communicate with relational databases. Connector The Connector API enables Java programs to create an abstraction layer for connecting with legacy systems that don't implement other J2EE-supported technologies. JavaMail JavaMail provides the ability to send and receive e-mail via the industry standard POP/SMTP/IMAP protocols. Java XML Parser (JAXP) JAXP gives J2EE applications the ability to speak XML. Note that the J2EE APIs are not designed to help developers write their own server software. Rather, they are to designed to work with a special kind of server, called a J2EE application server (app server). J2EE app servers are available on many operating systems, including Windows, Linux, Solaris, and Mac OS X. To be considered an official J2EE app server, the app server vendor must show that the app server complies with the J2EE standards and then purchase a J2EE license. Such vendors are referred to as J2EE licensees. Agree On Standards, Compete On Implementation If developers follow the J2EE standards, they can use a compliant, licensed J2EE app server from any vendor and it is guaranteed to work with their application. This flexibility is intended to help companies avoid vendor lock-in problems, and thus they can enjoy the benefits of a competitive marketplace. The Java slogan along these lines is "Agree on standards, compete on implementation," meaning that the vendors all cooperate on establishing universal J2EE standards and then work hard to create the best app server that supports those standards. Pick and Choose However, not all developers want to create the kinds of distributed systems that the entire collection of J2EE APIs are designed to support. Fortunately, it is possible to pick and choose those APIs that are necessary for your projects. For example, if all you need to do is write a GUI LDAP client, the JNDI API is the only J2EE API you'll need to use. If you want to create a dynamic web site but don't need the additional J2EE APIs, the Servlet and JSP APIs may be all you'll want. As was mentioned earlier in this chapter, a servlet plugs in to a special server called a servlet container (and JSP is an alternative way of writing a servlet). The J2EE app server contains a servlet container, but if all you want to is write servlets/JSP, then you don't need the full app server - you just need a servlet container. Tomcat is just such a servlet container. As a servlet container, Tomcat is only required to implement the Servlet and JSP APIs, and thus is not considered a J2EE app server. However, as J2EE app servers must themselves contain a servlet container to support the servlet/JSP APIs, J2EE app servers can embed Tomcat into their code to provide support for the Servlet and JSP APIs. One example of just such an application server is the popular open source JBoss J2EE app server (http://www.jboss.org/). For more information on J2EE and its various APIs, visit http://java.sun.com/j2ee/.