I.2.1 The Components of the Web Layer

Java servlets technology was the first Java API for implementing Web clients. A servlet is a Java class that supports request-response protocols – HTTP in particular – within the application server.

Unfortunately, the creation of web pages using Java servlets can easily result in a tangling of presentation and logic. More recent Web technologies are based conceptually on the Model-View-Controller pattern (MVC pattern). Although, in principle, it is possible to implement the MVC pattern with Java servlets, a clean separation of presentation (view) and logic (controller) is not easy to achieve. While, for this reason, Java servlets are no longer directly used for the production of web pages, they frequently serve as intermediaries in web frameworks between the requesting Web clients and the components responsible for the generation of the response.

In time, the use of Java Servlet technology meant that web components began to be created at a higher level of abstraction. JavaServer Pages (JSP) and JavaServer Faces (JSF) were used to do this.

While a Java servlet is a Java class, JSP and JSF components consist of a text-based page definition and of classes that implement the controller logic in the background. The description of the view is accomplished with a View Declaration Language (VDL for short); depending on the technology, this is based on either HTML or XHTML.

Models are implemented as classes; however, because they are needed in all layers of the application, they are not counted strictly amongst the web components. The objects of the model classes are therefore also referred to as transfer objects, since they are frequently passed from the client layer up to the persistence layer and vice versa. The terms POJO and JavaBean are often heard in this context.

JavaServer Pages

JavaServer Pages enable the development of a view with a view declaration language based on HTML. It is possible, for the purpose of implementing the controller logic, to embed Java declarations, Java code and Java statements in the page using a special syntax. JavaBeans can also be published via directives, and their properties accessed. The JavaServer Pages Standard Tag Library (JSTL) is an extension of the JSP technology and is designed to enable the adding of special tags for frequently required tasks and UI components. The use of JSTL simplifies and standardizes the creation of JSP views. JSP is no longer the preferred view technology for the Java EE standard, so we will refrain from discussing it further here.

JavaServer Faces

In earlier versions of JSF, JSP served as a view declaration language. In version 2.0, JSF introduced its own view technology, Facelets, which was based on XHTML. Facelets offer several advantages over JSP, including the template system explained in section 4.4. In addition to the MVC pattern, JSF supplies a UI component model, including event handling, that functions analogously to the UI libraries for desktop applications (e.g. JavaFX). The UI components are made available in Facelets using tags and JSF has its own extensive tag libraries.

The UI components of a view that are coded using Facelet tags are represented at runtime on the application server by instances of JSF API classes. The view corresponds to a component tree as a whole, i.e., the network of instances is represented by a tree structure. The component tree is created from the Facelet when the Web client first accesses a view and is used thereafter as the basis for the processing of further requests to the view by Web clients.

In the browser, the user has only a representation of the component tree in HTML/JavaScript to work with. This communicates with the server using HTTP. The objective of JSF implementation is to process Web client requests to the view and to generate the representation of a new view (when navigating to another page) or a modified version of the original view (as a result of action taken) and return it as a response. To do this, JSF implements a complex processing model consisting of six phases, which begins with the restoration of the component tree for the view and ends with the rendering of the response.

In the intermediate stages, request parameters can be acquired, converted and validated and attributes of the models bound to UI components can be updated; such attributes can also be called up for the event handlers of UI components. In each stage, events can occur (e.g. validation errors) that result in a direct jump to the last phase of the model to generate a response (e.g. in the case of a page with error messages). Fig. I-2 is a schematic representation of a JSF request (Faces request) within the context of the execution environment.

Fig. I-2     Schematic representation of the handling of a JavaServer Faces request by the server

In the case of JSF, either JSF managed beans or CDI Beans can be used as the controller. Both types of beans can be embedded in the view by using expression language (EL) in the page definition. This book will use CDI beans for this purpose, since they offer better opportunities for implementing a flexible software architecture.

Tab. I-1 briefly summarizes the different web technologies of the Java EE standard.

Tab. I-1     Web technologies of the Java EE standard

I.2.2 CDI – A Component Type with Plenty of Potential

CDI Beans are a relatively new type of bean that first appeared in Java EE version 6. Given the situation at the time CDI was introduced, one might wonder why it really was needed at all. Didn’t everything we need for successful development already exist? With JSF Facelets and JSF managed beans (for the view and controller), POJO (for the model) and EJB (for the business logic), we were able to program a multi-tier business application without problems – weren’t we?

Why, then, did the creators of the Java EE standard choose to supply programmers with another component technology, Contexts and Dependency Injection (CDI)?

On one hand, CDI is a technology that links to the Web layer and the transactional business layer in the same way as JSF managed beans: CDI beans can also be accessed in Facelets using the Expression Language (EL). On another hand, the concept of CDI goes far beyond JSF managed beans in terms of its complexity: it is a technology that links beans at runtime through dependency injection (DI). Beans are not generated, but are requested by means of declaration and annotation (@Inject) at certain points in the process. The container ensures the availability of the beans at runtime. CDI beans are aimed at increasing the maintainability of applications and improving their extensibility and testability. This is achieved through the consistent application of DI and other complementary approaches (e.g. application-wide messages) to components as well as through the clear specification of visibility sections (contexts).

CDI is a general, layer-independent container technology. CDI is extensible, which enables it to take on layer-specific tasks. The framework Seam 3, for example, offers a number of extensions, including one for transactions, which are usually the domain of Enterprise Java Beans (EJBs). CDI is more general than other purpose-built bean technologies. The CDI container can be embedded both in Java EE environments and in others; in J2SE applications, for example. We will learn more about CDI and the ways in which it differs from other component technologies in our Cloud Tutorial CDI in a Day (coming soon).

I.2.3 Enterprise Java Beans

Enterprise JavaBeans (EJBs) are components that implement business logic and thus belong to the business layer of a multi-layer application. They are managed by the application server’s EJB container. The container gives the EJBs access to key business application services such as transaction control and security mechanisms. The EJBs can be considered the internal “service beans” of Java EE applications. EJBs are the first choice whenever business logic is required alongside transactional behavior, since they incorporate this behavior by default.

It is not only Web-tier components that have evolved over the years; there have also been changes in the EJBs, of which there initially existed three types. Two of them, session beans and message-driven beans, still exist today – though the amount of programming effort required to create them has been significantly reduced since Java EE 5. Entity beans, which were designed as persistent domain classes, were later abolished and the Java-wide unified Java Persistence API (JPA) introduced instead.

While JSF managed beans and CDI are primarily used as controllers in the Web application, the “heavyweight” transactional business logic is implemented with EJBs. EJBs are only involved in a view via the respective controller, never directly. Just as in CDI, Java EE 7 makes EJBs available within the controller classes via the simple use of dependency injection with annotations. The same mechanism can be used when EJBs are used in combination with each other.

I.2.4 Java Persistence API (JPA)

JPA is not a Java EE component technology; rather, it is a Java-wide technology for mapping object meshes to the relational structures of a database. This means that object-relational mapping can be defined for any application, from those suited for personal desktop use to distributed, multi-layered business applications. JPA makes it appear as though an object-oriented database is available to the Java classes, although a relational database system is actually used.

Prior to determining the mapping, it’s essential to consider which objects should actually be persisted. Usually, these are clearly identifiable information objects. A bank application, for example, would contain appropriate domain classes for storing customer and account data.

Objects are uniquely allocated using a unique key for the class. Domain classes with a unique key are also known as entities. It does not always make sense to map an entity to exactly one table; however, JPA allows for plenty of variation in this regard.

The mapping of a class and its attributes to a relational database is defined using annotations. The annotation @Entity, for example, identifies a class as an entity, while @Id can be used to define an attribute of the class as a key and @Table can be used to assign a table name in the database explicitly to the entity.

Thus the schema of the target database can be created using the metadata of the entities during deployment (or an existing schema can be verified for use). In addition, data can be stored correctly in the database tables at runtime with the help of metadata. This task is undertaken by JPA classes (e.g. javax.persistence.EntityManager).

In Java EE applications, JPA classes are used within EJBs that provide controllers of the Web tier with transactional methods for the persistence of entities. Fig. I-3 is a visual representation of the object-relational mapping concept. The diagram shows an entity “Donation”, whose attributes are mapped to a “Donation” table in a relational database.

Fig. I-3     Object-relational mapping of an instance of the entity “Donation” to a table “Donation” in a relational database

I.2.5 The Java EE Profile

The introduction of the Java EE web profile in Java EE version 6 heralded the arrival of a completely new approach involving customized Java application servers for application domains. Despite its numerous simplifications, the complete Java EE standard is very extensive and complex. The Java EE profiles take account of the fact that not all projects require the complete range of Java EE features and capabilities.

A profile corresponds to a standardized partial stack of the Java EE standard; that is, a profile defines exactly which of the Java EE standard APIs are included. The aim is not only to define custom-tailored API packages for developers to use for a specific purpose, but also to allow for highly specialized servers. Discounting the full profile, the Web Profile that arrived with version 6 is the first and to date only Java EE profile to have been released. As the name suggests, it has been tailored specifically for web projects, so we have afforded it special attention in this book. Java EE 7 did not introduce any further profiles, but instead focused on extending the Web Profile. Tab. I-2 lists the most important technologies. A complete overview can be found in the Java EE 7 specification.

Tab. I-2     The main technologies of the Java EE 7 Web Profile

In this book, we will familiarize ourselves with these technologies on a step-by-step basis. This will allow us to gain a foothold in the world of Java EE. At certain points, however, we will also find ourselves needing technologies that are not included in the Web Profile if a technology we need is not contained in the Web Profile. Until then, it can be assumed that all APIs used are included in the Web Profile.

We have now gained an overview of the various components of Java EE 7 and the building of a Java EE application. Next, we want to look at how we can make a Java EE application available on an application server.

I.2.6 Time to Get Started With the Application Server!

In Java EE applications – as in ordinary Java desktop applications – Java archives are used for packaging types (classes, interfaces or enumerated types), Facelets and all other resources (e.g. JavaScript, CSS, property or configuration files and images). However, there are different types of archives. The folder structure within the archives is complex, and is determined by the specification. In particular, the specification defines the types Enterprise Archive (EAR) and Web Archive (WAR) (see Fig. I-4). The former is used for the packaging of Java EE applications that require the entire scope of Java EE capabilities (full profile), the latter is intended for Java EE applications using only the web profile.

Due to the complexity of the archives and the configurations that are partially dependent on application servers, tool support of the archive preparation is highly recommended. The compilation of classes and the packaging of all Java EE application artifacts is referred to as the build. The archive files created in the process can then be passed on to an application server. This is likewise accomplished by tools of the development environment or application servers. The process is called deployment and covers the installation, configuration and deployment of the application in the application server. Following deployment, the application is ready to be used.

Fig. I-4     Outline of the basic structure of a Java EE 7 web archive (WAR). Directories within the archive are shown with a double border, files with a single one. Directories other than those illustrated can exist for special properties of the application (e.g. for the template system, the Resource Library Contracts or the Faces Flows of JSF).

As part of the deployment process, the application server processes the archive files and makes the components contained within them available in the different containers (CDI, Web, EJB) (see Fig. I-5). From this point onwards, the life-cycle of the components is controlled by the containers. The containers also provide interfaces to the application server’s common services and data.

One of the most important services provided by the application server is the naming and directory service. Through it, clients can reference components (such as remotely available EJBs) or other objects and data by specifying their unique names. Access to the naming and directory service is standardized via the Java Naming and Directory Interface (JNDI) API.

Fig. I-5     Deployment process of a Java EE application

In the last section of this chapter, we will outline a typical software architecture for Java EE applications and describe exactly which components and technologies are used. The application to be developed in this book will be based on this architecture.

Discussion

Use the message board below to give the authors your feedback or to discuss this page’s topic with other readers (in English please!). Please don’t expect the authors to answer directly, but they might update the content of this site according to your feedback.