Introduction to Java EE

Today we’ll talk about what it is - Java EE: what it consists of, what are the features of the architecture of Java EE applications, and we will provide descriptions of the various technologies of this platform. The topic itself is extensive, but we will not stop at the basics. At the end, we will make a small comparison of Java EE with the Spring Framework and answer the question: “what is better to learn” (spoiler: of course, you need to learn everything =) ) Let's start with the basics.

Java EE - what is it?

Java EE is a platform built on top of Java SE that provides an API and runtime environment for developing and running large-scale, multi-tier, scalable, reliable, and secure network applications. Such applications are called enterprise applications because they solve problems faced by large businesses. However, it's not just large corporations and government agencies that can benefit from these types of applications and the benefits that Java EE provides. The solutions that the Java EE platform offers are useful, and sometimes simply necessary, for individual developers and small organizations.

Java EE development

Java EE is developed through the Java Community Process (JCP), formed in 1998. It allows interested parties to participate in shaping future versions of the Java language platform specifications. The basis of this process is the JSR (Java Specification Request), formal documents describing the specifications and technologies that are proposed to be added to the Java platform. Such requests are made by community members - ordinary developers and companies. The latter include Oracle, Red Hat, IBM, Apache and many others. Those. the guys propose new features and goodies for consideration that they would like to include in Java. And then they hold a vote, on the basis of which a decision is made on what to include in the next version. The Java EE version history looks like this:

• J2EE 1.2 (December 1999)
• J2EE 1.3 (September 2001)
• J2EE 1.4 (November 2003)
• Java EE 5 (May 2006)
• Java EE 6 (December 2009)
• Java EE 7 (May)
• Java EE 8 (August 2017)
• Jakarta EE 8 (September 2019)

In 2017, a new milestone in the development of the platform occurred: Oracle transferred control over the development of Java EE to the Eclipse Foundation. And in April 2018, Java EE was renamed Jakarta EE, which is fully compatible with Java EE 8.

Java EE Application Architecture

A short introduction. To make it easier to understand, let's talk about the structure of Java EE applications and some of the terms that we will use further. Java EE applications have a structure that has two key qualities:

• Firstly, multi-level. Java EE applications are multi-tiered, and we will talk about this in more detail;
• secondly, nesting. There is a Java EE server (or application server), with component containers located inside it. These containers house (bingo!) components.

To explain the architecture of Java EE applications, let's first talk about layers. What are the levels? What Java EE technologies are used at different levels? Next, we will discuss how application servers, component containers, and the components themselves are interconnected. But keep in mind that all of these are views from different angles at the same thing, and the order is not so important here.

Application levels

Multi-tier applications are applications that are divided according to functional principles into isolated modules (levels, layers). Typically (including in the context of Java EE development), enterprise applications are divided into three levels:

• client;
• average level;
• data access level.

1. The client layer is an application that requests data from the Java EE server (middle layer). The server, in turn, processes the client's request and returns a response to it. The client application can be a browser, a standalone application (mobile or desktop), or other server applications without a graphical interface.

2. The middle level is divided, in turn, into the web level and the business logic level.

   1. The web layer consists of some components that provide interaction between clients and the business logic layer.

      The following Java EE technologies are used at the web level:

      • JavaServer Faces technology (JSF);
      • Java Server Pages (JSP);
      • Expression Language (EL);
      • Servlets;
      • Contexts and Dependency Injection for Java EE (CDI).

   2. The business logic layer consists of components that implement all the business logic of the application. Business logic is code that provides functionality that covers the needs of some specific business area (financial industry, banking, e-commerce). This level can be considered the core of the entire system.

      Technologies that are involved at this level:

      • Enterprise JavaBeans (EJB);
      • JAX-RS RESTful web services;
      • Java Persistence API entities;
      • Java Message Service.

3. Data access level. This level is sometimes called the level of enterprise information systems (EIS). EIS consists of various database servers, ERP (Enterprise Resource Planning) enterprise resource planning systems and other data sources. The business logic layer accesses this layer for data.

   At this level you can find technologies such as:

   • Java Database Connectivity API (JDBC);
   • Java Persistence API;
   • Java EE Connector Architecture;
   • Java Transaction API (JTA).

Application servers, containers, components

Let's take a look at the definition of Java EE from Wikipedia. Java EE is a set of specifications and related documentation for the Java language, describing the architecture of the server platform for the tasks of medium and large enterprises. To better understand what a “set of specifications” means in this context, let’s draw an analogy with a Java interface. The Java interface itself is devoid of functionality. It simply defines some contract according to which some functionality is implemented. But other classes implement the interface. Moreover, one interface can have several implementations, each of which may differ from each other in some details. The specification is exactly the same. Naked Java EE is just a set of specifications. These specifications are implemented by various Java EE servers. A Java EE server is a server application that implements the Java EE platform APIs and provides standard Java EE services. Java EE servers are sometimes called application servers. Server data can contain application components, each of which corresponds to its own level in a multi-level hierarchy. The Java EE server provides various services to these components in the form of a container. Containers are the interface between the components they host and the low-level platform-independent functionality that supports the component. Containers provide specific services to the components they host. For example, development lifecycle management, dependency injection, concurrency, etc. Containers hide technical complexity and increase portability. There are four different types of containers in Java EE :

1. Applet containers are implemented by most browsers. When developing applets, you can concentrate on the visual side of the application, while the container provides a secure environment.

2. The Application Client Container (ACC) contains a set of Java classes, libraries, and other files needed to implement features such as injection, security management, and naming services in Java SE applications.

3. The web container provides the core services for managing and executing web components (servlets, EJB Lite components, JSP pages, filters, listeners, JSF pages, and web services). It is responsible for instantiating, initializing and invoking servlets, and supporting the HTTP and HTTPS protocols. This container is used to serve web pages to client browsers.

4. The EJB (Enterprise Java Bean) container is responsible for managing and executing the EJB model components that contain the application's business logic layer. It creates new EJB bean entities, manages their lifecycle, and provides services such as transaction, security, concurrency, distribution, naming, or asynchronous invocation capabilities.

Also in Java EE there are four types of components that an implementation of the Java EE specification must support:

1. Applets are graphical user interface (GUI) applications that run in a browser. They leverage the rich Swing API to produce powerful user interfaces.

2. Applications are programs that run on the client side. They are typically graphical user interface (GUI) and used for batch processing.

3. Web applications (consisting of servlets and their filters, web event listeners, JSP and JSF pages) - run in a web container and respond to HTTP requests from web clients. Servlets also support SOAP and RESTful web service endpoints.

4. Enterprise applications (built with Enterprise Java Beans, Java Message Service, Java Transaction API, Asynchronous Calls, Time Services) run in an EJB container. Container-managed EJBs handle transactional business logic. They can be accessed either locally or remotely via RMI (or HTTP for SOAP and RESTful web services).

The diagram below shows a typical Java EE application architecture:

Technologies

So, we've sorted out the architecture. The overall structure should be clear. In the process of describing the architectural components, we touched on some Java EE technologies such as EJB, JSP, etc. Let's take a closer look at them. The table below shows the technologies that are used mainly at the client level: The table below shows the technologies used at the business logic level: The table below shows the technologies used at the data access layer:

Java EE vs Spring

The Spring Framework is considered a competitor to Java EE. If you look at the development of these two platforms, an interesting picture emerges. The first versions of Java EE were created with the participation of IBM. They turned out to be cool, but clumsy, heavy, and inconvenient to use. Developers struggled because of the need to maintain a large number of configuration files and other reasons that complicate development. At the same time, Spring IoC was born. It was a small, beautiful and easy-to-use library. It also used a configuration file, but unlike Java EE, there was only one. The simplicity of Spring has led to the fact that almost everyone began to use this framework in their projects. And then Spring and Java EE began their path to the same thing, but from different ends. Pivotal Software, the developer of Spring, began to release project after project to cover all possible and impossible needs of Java developers. Gradually, what was previously called Spring first became one of the projects, and then completely merged with several other projects in Spring Core. All this led to the inevitable complication of Spring compared to what it was originally. Over time, it became very difficult to keep track of the entire tangle of Spring dependencies, and the need arose for a separate library that would load and run everything itself (now the beloved Spring Boot has hiccupped somewhere). All this time, JCP has been working on one thing - to achieve the maximum simplification of everything that is possible inside Java EE. As a result, in a modern EJB, to describe a bean, it is enough to specify one annotation above the class, which gives the developer access to the full power of Enterprise Java Beans technology. And similar simplifications have affected every specification within Java EE. As a result, Spring and Java EE are roughly parity in terms of functionality. Some things are better, some things are worse, but if you look globally, there are no big differences. The same goes for the complexity of the job. Both Spring and Java EE are excellent tools. Perhaps the best that currently exists for building enterprise network applications in Java. However, Java EE can generally work only within the Enterprise Application Server (Tomcat is not one), and an application on the Spring stack can run on anything (on the same Tomcat), and even without a server at all (since it will run it within itself independently). This makes Spring an ideal tool for developing small front-end GUI applications or microservice architectures. But eliminating the dependence on application servers had a negative impact on the scalability of Spring applications. And Java EE is well suited for implementing a scalable monolithic cluster application. Developers familiar with the Spring Framework are currently in greater demand on the labor market. This is how it happened historically: at a time when Java EE was overly complicated, Spring “gained a customer base.” And yet, there is no clear answer to the question of what to learn Spring or Java EE. A beginner can be given the following advice. Get acquainted (at least superficially) with both platforms. Write a small home project in both Java EE and Spring. And then delve deeper into the framework that will be needed at work. As a result, switching between Spring and Java EE will not be difficult.

Results

A large-scale topic, of course, cannot be covered in one article! After a ton of new terms, you probably want to “apply” this knowledge to a real-life example. Therefore, we will continue to study Java EE: you will find practical lessons on setting up a local environment for Java EE development in the next article.