JEE

JEE is a collection of many of the Java Community Process (https://www.jcp.org) programs. Currently, JEE is in Version 8. However, different specifications of JEE are at their own different versions.

JEE specifications can be broadly classified into the following groups:

• Presentation layer
• Business layer
• Enterprise integration layer

Note that JEE specification does not necessarily classify APIs in the preceding broad groups, but such classification could help in better understanding the purpose of the different specifications and APIs in JEE.

Before we see APIs in each of these categories, let's understand a typical JEE web application flow, as shown in the following diagram, and where each of the preceding layers fits in:

Figure 1.1: A typical JEE web application flow

Requests start from the clients. A client can be any application requesting services from a remote application—for example, it could be the browser or a desktop application. The request is first received by the web server at the destination. Examples of web servers include Apache web server, IIS, and nginx. If it is a request for static content, then it is served by the web server(s). However, a dynamic request typically requires an application server to process. JEE servers are such application servers that handle dynamic requests. Most JEE specification APIs execute in the application server. Examples of JEE application servers are WebSphere, GlassFish, and WildFly.

Most non-trivial JEE applications access external systems, such as a database or Enterprise Integration Server (EIS), for accessing data and process it. A response is returned from the application server to the web server and then to the clients.

The following sections provide a brief description of each of the JEE specifications in different layers. We will see how to use these specifications and their APIs in more detail in subsequent chapters. However, note that the following is not the exhaustive list of all the specifications in JEE. We will see the most commonly used specifications here. For the exhaustive list, please visit http://www.oracle.com/technetwork/java/javaee/tech/index.html.

The presentation layer

JEE specifications or technologies in this layer receive requests from the web server and send back the response, typically in HTML format. However, it is also possible to return only data from the presentation layer, for example in JavaScript Object Notation (JSON) or eXtensible Markup Language (XML) format, which could be consumed by Asynchronous JavaScript and XML (AJAX) calls to update only part of the page, instead of rendering the entire HTML page. Classes in the presentation layer are mostly executed in the web container—it is a part of the application server that handles web requests. Tomcat is an example of a popular web container.

Now let's take a look at some of the specifications in this layer.

Java Servlets

Java Servlets are server-side modules, typically used to process requests and send back responses in web applications. Servlets are useful for handling requests that do not generate large HTML markup responses. They are typically used as controllers in Model View Controller (MVC) frameworks, for forwarding/redirecting requests, or for generating non-HTML responses, such as PDFs. To generate HTML response from the servlet, you need to embed HTML code (as a Java String) in Java code. Therefore, it is not the most convenient option for generating large HTML responses. JEE 8 contains servlet API 4.0.

JavaServer Pages

Like servlets, JavaServer Pages (JSPs) are also server-side modules used for processing web requests. JSPs are great for handling requests that generate large HTML markup responses. In JSP pages, Java code or JSP tags can be mixed with other HTML code, such as HTML tags, JavaScript, and CSS. Since Java code is embedded in the larger HTML code, it is easier (than servlets) to generate an HTML response from the JSP pages. JSP specification 2.3 is included in JEE 8.

JavaServer Faces

JavaServer Faces (JSFs) make creating a user interface on the server side modular by incorporating the MVC design pattern in its implementation. It also provides easy-to-use tags for common user interface controls that can save states across multiple request-response exchanges between client and server. For example, if you have a page that posts form data from a browser, you can have a JSF save that data in a Java bean so that it can be used subsequently in the response to the same or different request. JSFs also make it easier to handle UI events on the server side and specify page navigation in an application.

You write the JSF code in JSP, using custom JSP tags created for JSF. JavaServer Faces API 2.3 is part of JEE 8.

The business layer

The business layer is where you typically write code to handle the business logic of your application. Requests to this layer could come from the presentation layer, directly from the client application, or from the middle layer consisting of, but not limited to, web services. Classes in this layer are executed in the application container part of JEE server. GlassFish and WebSphere are examples of web container plus application container.

Let us take a tour of some of the specifications in this group.

Enterprise JavaBeans

Enterprise JavaBeans (EJBs) are the Java classes where you can write your business logic. Though it is not a strict requirement to use EJBs to write business logic, they do provide many of the services that are essential in enterprise applications. These services are security, transaction management, component lookup, object pooling, and so on.

You can have EJBs distributed across multiple servers and let the application container (also called the EJB container) take care of component lookup (searching component) and component pooling (useful for scalability). This can improve the scalability of the application.

EJBs are of two types:

• Session beans: Session beans are called directly by clients or middle-tier objects
• Message-driven beans: Message-driven beans are called in response to Java Messaging Service (JMS) events

JMS and message-driven beans can be used for handling asynchronous requests. In a typical asynchronous request processing scenario, the client puts a request in a messaging queue or a topic and does not wait for immediate response. An application on the server side gets the request message, either directly using JMS APIs or by using MDBs. It processes the request and may put the response in a different queue or topic, to which the client would listen and get the response.

Java EE 8 contains EJB specification 3.2 and JMS specification 2.0.

The enterprise integration layer

APIs in this layer are used for interacting with external (to the JEE application) systems in the enterprise. Most applications would need to access a database, and APIs to access that fall in this group.

Java Database Connectivity 

Java Database Connectivity (JDBC) is a specification to access a relational database in a common and consistent way. Using JDBC, you can execute SQL statements and get results on different databases using common APIs. A database-specific driver sits between the JDBC call and the database, and it translates JDBC calls to database-vendor-specific API calls. JDBC can be used in both the presentation and business layers directly, but it is recommended to separate the database calls from both the UI and the business code. Typically, this is done by creating Data Access Objects (DAOs) that encapsulate the logic to access the database. JDBC is actually a part of Java Standard Edition. Java SE 8 contains JDBC 4.2.

The Java Persistence API

One of the problems of using JDBC APIs directly is that you have to constantly map the data between Java objects and the data in columns or rows in the relational database. Frameworks such as Hibernate and Spring have made this process simpler by using a concept known as Object Relational Mapping (ORM). ORM is incorporated in JEE in the form of the Java Persistence API (JPA).

JPA gives you the flexibility to map objects to tables in the relational database and execute queries with or without using Structured Query Language (SQL). When used in the content of JPA, the query language is called Java Persistence Query Language. JPA specification 2.2 is a part of JEE8.

Java Connector Architecture

Java Connector Architecture (JCA) APIs can be used in JEE applications for communicating with enterprise integration systems (EISes), such as SAP, and Salesforce. Just like you have database drivers to broker communication between JDBC APIs and relational databases, you have JCA adapters between JCA calls and EISes. Most EIS applications now provide REST APIs, which are lightweight and easy to use, so REST could replace JCA in some cases. However, if you use JCA, you get transaction and pooling support from the JEE application server.

Web services

Web services are remote application components and expose self-contained APIs. Web services can be broadly classified based on following two standards:

• Simple Object Access Protocol (SOAP)
• Representational State Transfer (REST)

Web services can play a major role in integrating disparate applications, because they are standard-based and platform-independent.

JEE provides many specifications to simplify development and consumption of both types of web services, for example, JAX-WS (Java API for XML—web services) and JAX-RS (Java API for RESTful web services).

The preceding are just some of the specifications that are part of JEE. There are many other independent specifications and many enabling specifications, such as dependency injection and concurrency utilities, which we will see in subsequent chapters.

Eclipse IDE

A good IDE is essential for better productivity while coding. Eclipse is one such IDE, which has great editor features and many integration points with JEE technologies. The primary purpose of this book is to show you how to develop JEE applications using Eclipse. So the following is a quick introduction to Eclipse, if you are not already familiar with it.

Eclipse is an open source IDE for developing applications in many different programming languages. It is quite popular for developing many different types of Java applications. Its architecture is pluggable—there is a core IDE component and many different plugins can be added to it. In fact, support for many languages is added as Eclipse plugins, including support for Java.

Along with editor support, Eclipse has plugins to interact with many of the external systems used during development. Examples include source control systems such as SVN and Git, build tools such as Apache Ant and Maven, file explorers for remote systems using FTP, managing servers such as Tomcat and GlassFish, database explorers, memory and CPU profilers. We will see many of these features in the subsequent chapters. The following screenshot shows the default view of Eclipse for JEE application development:

Figure 1.2: Default Eclipse view

When working with Eclipse, it is good to understand the following terms.

Workspace

The Eclipse workspace is a collection of projects, settings, and preferences. It is a folder where Eclipse stores this information. You must create a workspace to start using Eclipse. You can create multiple workspaces, but only one can be opened at a time by one running instance of Eclipse. However, you can launch multiple instances of Eclipse with different workspaces.

Plugin

Eclipse has pluggable architecture. Many of the features of Eclipse are implemented as plugins, for example, editor plugins for Java and many other languages, plugins for SVN and Git, and many more. The default installation of Eclipse comes with many built-in plugins and you can add more plugins for the features you want later.

Editors and views

Most windows in Eclipse can be classified either as an editor or a view. An editor is something where you can change the information displayed in it. A view just displays the information and does not allow you to change it. An example of an editor is the Java editor where you write code. An example of a view is the outline view that displays the hierarchical structure of the code you are editing (in the case of a Java editor, it shows classes and methods in the file being edited).

To see all views in a given Eclipse installation, open the Window | Show View | Other menu:

Figure 1.3: Show all Eclipse views

Perspective

Perspective is a collection of editors and views, and how they are laid out or arranged in the main Eclipse window. At different stages of development, you need different views to be displayed. For example, when you are editing the code, you need to see Project Explorer and Task views, but when you are debugging an application, you don't need those views, but instead want to see variable and breakpoint views. So, the editing perspective displays, among other views and editors, Project Explorer and Task views, and the Debug perspective displays views and editors relevant to the debugging activities. You can change the default perspectives to suit your purposes.

Eclipse preferences

The Eclipse Preferences window (Figure 1.4) is where you customize many plugins/features. Preferences are available from the Window menu in the Windows and Linux installations of Eclipse, and from the Eclipse menu in Mac:

Figure 1.4: Eclipse preferences