1.2 J2EE

This book expects that you know the fundamental Java language and have some basic familiarity with the J2EE APIs. A J2EE environment differs from a Java 2, Standard Edition (J2SE) environment in that it offers a wider range of services than a standalone application could expect to find. J2SE is geared towards providing core language features (I/O, text manipulation, variables, object semantics), standard utility classes that apply in a variety of settings (collections, mathematics), and features required for building client applications (GUIs, and some basic enterprise integration, including access to databases and naming services).

The J2EE application model is built on a division of labor into various tiers. The client presentation in a web browser, applet, or Java application is separated from server side logic in a JavaServer Page or Java Servlet and the business logic in a database or Enterprise JavaBeans. The J2EE APIs are focused on implementing the interactions between tiers. The interfaces to each tier are standardized, allowing programmers with an understanding of the core J2EE concepts to easily apply their skills to any J2EE-based project.

The core of a J2EE application deployment is a J2EE-compliant application server. The application server supports hosting business logic components and web components, providing access to the full range of J2EE capabilities. Note that the J2EE API doesn't say very much beyond the essentials about how these servers should be designed, or how deployment, maintenance, and general administration should be conducted. The focus of the J2EE API, instead, is on programmatic interfaces and runtime behavior. This specialization can make it difficult to transfer administration skills from, say, IBM WebSphere to BEA WebLogic. Code, however, should transfer transparently. Figure 1-1 shows the canonical J2EE application model.

Figure 1-1. Canonical J2EE application model

Each J2EE API itself is simply a wrapper for a service provided by the J2EE container or by an external component within the enterprise. A full-scale J2EE environment could include one or more J2EE application servers hosting servlets and Enterprise JavaBeans, as well as an external transaction manager, an Oracle or DB2 relational database, and a messaging middleware system. Full J2EE platforms implement the following APIs:

Java Servlet API

Allows a web server to process HTTP requests and return content to a client. The servlet code can make use of any other J2EE service in the process of fulfilling the request.

Java Server Pages

These text files include fragments of Java code and are stored on a web server. A typical JSP consists of HTML with embedded Java code to customize the display according to the application's requirements. When a client requests a JSP, the server compiles the JSP into a Java Servlet and, if it has not already done so, executes the JSP and returns the results. Since JSPs are easier to write and modify than a Servlet, they are often used to create the HTML user interface for a web-based application.

Enterprise JavaBeans

Allows the creation of server-managed distributed objects, representing the business data and logic behind an application. EJBs are divided into three categories: entity beans define the data structure for the application; session beans provide business methods that can manipulate entity beans and other resources; message-driven beans are similar to session beans, but they are triggered by the arrival of a message from a messaging middleware system. The EJB standard also includes full support for transactions. Managing EJBs is one of the main duties of a J2EE server.

JNDI (Java Naming and Directory Interface)

Provides generic support for accessing directory services. In addition to providing a frontend to enterprise directory servers, such as LDAP-based employee directories, JNDI is used within the context of a J2EE application to identify resources such as Enterprise JavaBeans and database connections. By accessing all external resources via JNDI lookups, an application can be easily relocated or distributed.

JavaMail API

Enables support for generic point-to-point electronic messages. For all practical purposes, this means Internet email. JavaMail uses a generic architecture to support pluggable message transport and retrieval systems. The default installation from Sun includes support for SMTP, IMAP, and POP, and support for other protocols is available from a variety of third parties. While J2EE environments must provide an implementation of JavaMail, they do not need to provide any of the infrastructure for a particular transport mechanism.

Java Message Service API

Allows J2EE applications to integrate with Message Oriented Middleware (MOM) packages, such as Sonic Software's SonicMQ or IBM MQSeries. MOM packages allow messages to be routed between applications, providing delivery and quality of service guarantees that simple email cannot provide.

Java Transaction API

Allows applications to manage their own transactions. The Java Transaction API allows multiple components on different tiers and different servers to participate in a single, distributed transaction.

The J2EE standard also has a few additional features and requirements. It mandates interoperability with CORBA-based distributed objects. In addition, it requires support for the full J2SE API set, which provides the JDBC API for database access. Finally, it provides a standard, XML-based system of deployment descriptors, which describe the structure of a J2EE application (particularly EJB components and web applications), enabling faster deployment.

For tutorials and reference information on the individual APIs that make up J2EE, we suggest (with some admitted bias) Java Enterprise in a Nutshell, by Jim Farley, William Crawford, and David Flanagan. There are also a variety of books in the O'Reilly Java Series (and elsewhere) that do an excellent job of explaining each API in much more detail than we could do here.

You don't need to use every last J2EE API to build a J2EE application. While there is occasionally some confusion, an application is technically "J2EE" if it uses even one of the J2EE APIs. It's common to associate J2EE with Enterprise JavaBeans. This is particularly the case because EJBs, despite the name, are probably the most conceptually difficult J2EE component for programmers who started out with J2SE.

We can say that applications that use the full J2EE application model from HTML presentation through to an EJB-based business layer are "J2EE applications," while others simply "use J2EE technology," but the difference isn't something to waste much time on. The important thing is that you can use the mix of J2EE technologies appropriate for your application. Later in the book, we'll describe patterns geared toward effectively balancing the J2EE application model and real-world requirements.