Java 2, Enterprise Edition (J2EE)

Overview

The advent of J2EE marked an important evolutionary shift in Java, a shift from treating the language as a series of APIs to representing it as a development framework. Conceptually, that's exactly what J2EE is—an architectural framework used to create enterprise applications.

Since the release of JDK 1.1, distributed programming technologies have been a special strength for Java. Sockets, JDBC, RMI, CORBA—all have offered programmers ways to develop multitier distributed applications.

With the introduction of J2EE, however, the application of these technologies underwent a dramatic metamorphosis. J2EE went beyond providing APIs for a single form of distributed communication; it defined an entire model intended to support distributed architectures.

As its name implies, J2EE is substantially more than a single technology. As an “edition,” J2EE represents a collection of Java technologies that can be used together to implement an architectural model. In this case, the model is intended to support the development and deployment of large-scale distributed applications.

Core J2EE Concepts

This section covers the core J2EE concepts, after which specific J2EE technologies will be covered.

J2EE Tiers

Fundamentally, the J2EE model is based on four logical units, or tiers, for an enterprise application:

Client tier – Provides a user interface. The client tier can be written in Java, or it can be designed using some other programming language. In J2EE, the client tier usually communicates with the Web tier using HTTP. In some J2EE applications, the client tier interacts directly with the EJB or database tiers.

Web tier – Represented by a Web browser or standalone client application, provides enterprise functionality to an end user. The web tier hosts the Web application, which provides application functionality to clients in the form of a related set of HTTP-transported content. This is typically scripted documents using technologies like HTML or XML.

EJB tier (or application server tier) – Acts as host to the object-oriented business model, representing the application in terms of a related set of objects relating to the problem domain.

The database, or persistence, tier (also known as the Enterprise Information Service tier) – Represents all enterprise resources for the application, such as databases, legacy applications, or collaborating enterprise systems.

Of the four tiers, the ones most strongly associated with Java technology are the web tier and application server tier. Although the other two tiers of the system can potentially leverage Java technology, there is an implicit assumption that the web server and application server use Java technology if they're part of a J2EE solution.

Core Technical Concepts

Central to the J2EE model are three related technical concepts: components, containers, and connectors. The component is the basic program unit in J2EE. J2EE advocates the creation of enterprise architectures as a set of collaborating Java components. There are a few motivations for this:

Components tend to make enterprise systems more flexible and extensible – All other things being equal, it is much easier to modify a system composed of a set of components than to modify a monolithic architecture.

Components can be standardized – It is easier to enforce a standard coding convention for a specific kind of component than for a monolithic application, code library, or framework. Doing this makes it easier to develop components that can plug into other systems, frameworks, and application models. This opens the door for reuse of parts of an enterprise architecture.

Components can be service-based – We tend to describe applications in terms of what they can do for us. Moving to object-oriented development, it is natural to refine behavioral characteristics into a set of services to be

210

provided. It is much easier to develop an application when its basic building blocks naturally support the concept of a service.

Core Component Technologies

J2EE is based around three central component technologies:

Enterprise JavaBeans (EJBs), which are used for the Application Server tier.

JavaServer Pages (JSPs) and servlets, which are Web tier technologies.

The Java components, by definition, require something to act as a host for them, something to control when they're created and how their methods are called—something to regulate their life within a system. This is the task of the container.

A container provides the services that a J2EE component requires in order to do its job. Naturally, these services are different depending on what kind of component technology we’re talking about. For the Web tier, for instance, a fundamental task of the container is translating between Web communications (HTTP requests) and methods calls on the Java components. For the Application Server, on the other hand, the container manages communication with EJBs through some protocol layer on top of RMI-IIOP.

Containers provide required services to enterprise components, but they also provide necessary services for the enterprise application itself. One of the main motivations to develop enterprise systems based on existing software products like Web servers, application server and databases is to leverage hard-to-code capabilities like persistence management, security and transaction support. In today's world, there usually isn't enough time to code these services—by the time a development wrote them, the system would already be obsolete.

J2EE-compliant products provide these services to a J2EE application in a configurable way. Better still, they separate the services and their use from the components themselves—ultimately improving the reusability of components in a wider range of application environments. J2EE manages the configuration of the container-based services through XML documents. The documents provide a way to specify how the containers should handle

Of course, each technology tends to have its own communication standard, its own way of interacting with the world. For a given kind of technology, there are often different standard communication methods, in fact. Within the database arena, for example, nearly every RDBMS tends to have its own API. Historically, this has caused major integration problems for enterprise systems —a large amount of effort has to be spent just getting everything to talk together.

The way that J2EE solved the problem was to create generic communication technologies: the connector technologies. Conceptually, connectors are Java APIs that buffer J2EE applications from the differences between specific communication models. Java developers write their code to the API specification, which in turn is used to link to some underlying communication layer. Often, this means that the APIs connect to an adaptor module which in turn communicates with another application, system or service.

At a minimum, this approach can standardize communication within a technology category – JavaMail for e-mail services or JDBC for relational database communication. Using this approach, J2EE developers can use the same Java coding techniques when they write database code, developing implementation-neutral JDBC code. The exact way that JDBC communicates with an associated RDBMS is handled by the JDBC driver; the API will be the same for developer regardless of what lies beneath.

Main J2EE Resources

TEAM FLY PRESENTS resources that comprise what you think of as J2EE:

211