Jakarta EE for Java Developers

Build Cloud-Native and Enterprise Applications Using a High-Performance Enterprise Java Platform

Rhuan Rocha

• Publisher: BPB Publications
• Year: 2021
• eBook ISBN: 9789355510082
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Develop Enterprise Systems on Cloud Infrastructure Using a Rich Java Ecosystem.

Key Features
? Every chapter and concept is illustrated through the use of the Jakarta Project.
? Extensive hands-on demonstration of Jakarta EE specifications and capabilities.
? Practical examples of securing Java applications with Jakarta Security are provided.

Description
This book provides a practical introduction to Enterprise Java Edition, Jakarta EE, including detailed features and capabilities. Equipped with numerous projects, each chapter demonstrates Jakarta EE capabilities with clean coding.The book starts with an introduction to Jakarta EE and its architecture. This will help to create a project using the Jakarta Servlet and exposure of an HTTP endpoint. The CDI is then used to inject dependencies, work with events asynchronously, and interact with CDI interceptors. Then, in the RESTful style, it can help to create a Jakarta RESTful resource to expose HTTP endpoints. We then investigate the Jakarta Enterprise Bean, which teaches us how to manage transactions and schedule tasks. The Jakarta Persistence is then used to integrate an application into a relational database, and the Jakarta Message is used to create an application using the Message Oriented Middleware (MOM). In terms of security, we use Jakarta Security to secure the endpoint of a Jakarta application.By the end of this book, the reader will be able to set up a Jakarta project and write applications that expose HTTP endpoints, integrate with a database, and deal with authentication and authorization.

What you will learn
? Create and use Servlets to build applications.
? Get to know CDI and practice how to create the CDI Interceptor and Decorator.
? Learn to build RESTful services and make use of Jakarta Enterprise Bean in your application.
? Use Jakarta Servlet and Jakarta RESTful to expose HTTP endpoints.
? Create a relational database-integrated application.
? Use authentication and authorization to build a secure application.

Who this book is for
This book is for Java developers who want to learn how to create a Jakarta project, work with the Jakarta EE specifications, and use it in best practices.

Table of Contents
1. Introduction to Jakarta EE
2. Jakarta Servlet
3. Jakarta Context and Dependency Injection
4. Jakarta RESTful Web Service
5. Jakarta Enterprise Bean
6. Jakarta Persistence
7. Jakarta Messaging
8. Jakarta Security
9. Jakarta Bean Validation

CHAPTER 1

Introduction to Jakarta EE

Introduction

The Java ecosystem has been used in many companies for many years and has provided several kinds of solutions to any environment. One of these environments is the enterprise environment, which has its particular necessities and challenges to be overcome. Thus, the Java ecosystem, by Sun — after being acquired by Oracle — promoted a project called J2EE, which is a project to provide well-known solutions to the common enterprise problems. Over time, its name changed to Java EE, and now it is Jakarta EE, which is maintained by the Eclipse Foundation now. This chapter will show you what the Jakarta EE is and what are its goals. Throughout this chapter, we’ll walk through each main point of this project, analyzing the why for some changes and what can we expect from Jakarta EE. Besides that, we’ll show you what a server application is, what its importance to the Jakarta EE ecosystem is, and what we need to work with Jakarta EE.

Structure

In this chapter, we will discuss the following topics:

• Understanding what Jakarta EE is
• From Java EE to Jakarta EE
• Understanding the Jakarta EE tiers
• Jakarta EE profiles
• Server applications
• Requirements for working with Jakarta EE

Objectives

The main objectives of the chapter are to enable the readers to understand what Jakarta EE is, what its goals are, and what is needed to work with it.

Understanding what Jakarta EE is

Basically, Jakarta EE is an umbrella project with a set of technologies for the enterprise Java applications, with an aim to provide the technologies and APIs to facilitate the development of the enterprise Java applications to the cloud computing world. This project came from the Java EE project, which was migrated from Oracle to Eclipse Foundation, and is now evolving under the Jakarta EE brand. But to really understand what Jakarta EE is, we should take a look at their antecessors, Java EE and J2EE, and the current enterprise challenges. So, let’s go!

J2EE and Java EE

In 1999, the Sun Microsystem was releasing the J2EE starting in its 1.2 version and taking the first step to put Java in the web world. The main goal of J2EE was to create an umbrella project based on the specifications, where these specifications describe the details of how some sets of technologies to the enterprise systems would work. With this, many vendors can create an implementation of these specifications and the developer can develop the enterprise Java application decoupled of the vendor and choose any vendor that follows the J2EE specifications and change the vendor as well. Thus, the J2EE came as a good solution to create the Java applications for the enterprise world, providing a set of robust technologies and more security to the business — now companies can create robust solutions without creating a dependency on any vendor.

J2EE was focused on the enterprise world and it has four elements in its architecture, these are described in the order of importance as follows:

• J2EE Platform: It is a standard platform that follows the J2EE specifications and is the host to J2EE applications. It is known as an application server.
• J2EE Compatibility Test Suite: A set of tests to verify if an implementation of J2EE follows the J2EE specifications.
• J2EE Reference Implementation: Each specification should have a reference implementation to demonstrate how the specification works.
• Sun Blueprints Design Guidelines for J2EE: It describes the standard programming model for the development of the multi-tier applications.

The first J2EE version came with these specifications – Enterprise JavaBeans (EJB), Java Servlet, Java Naming and Directory Interface (JNDI), JavaServer Pages (JSP), Java Transaction (JTA) Java Database Connectivity (JDBC), and JavaMail. All these specifications exist and is part of Jakarta EE today, but with many improvements.

The J2EE had many evolutions in its versions J2EE 1.3 and J2EE 1.4, and then in 2006, its name was changed to Java EE starting with Java EE 5, after evolving to Java EE 6. Java EE 6 was the last version of Java EE under Sun Microsystem, because in 2010, Oracle bought Sun Microsystem and got the Java EE’s rights. Java EE 6 was very important because it came after many evolutions to EJB, making its use easier, and it came to the Context and Dependency Injection (CDI) that is the mechanism to dependencies control of Java EE. Java EE under the Oracle control had two versions released – Java EE 7 released in 2013 and Java EE 8 released in 2017.

As you can see, J2EE/Java EE is 20 years old and the enterprise world has evolved a lot in these years, and new challenges have emerged at the enterprise environment.

Cloud computing

The complexity of the enterprise world has grown very fast and new needs emerged with this. As the main necessities, we can quote the fault tolerance and elasticity of the business. In other words, the business needs to be able to respond effectively to the increasing demand, and it needs to do that with as smaller risks as possible. Today, the business innovation basis is the technology, and the technological world has been worked on to provide a set of models, approaches, and techniques to supply these needs. Cloud computing came as one of these solutions.

Cloud Computing is a set of techniques and approaches to serving a computational resource as a service with a better and easier way for the end-user. With cloud computing, we can have only a computational resource — such as memory, disk, CPU, node amount — that we really need and can scale up and down when needed. With this, the business can save money and generate a faster and more effective response to the increasing demand. Using cloud computing, we can have many types of services like Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Software as a Service (SaaS), Function as a Service (FaaS), and others.

Cloud computing provides many benefits to the business, which are as follows:

• Pay per use: The end-user pays only for the resources used. It can save a lot of money for the business.
• Resilience: The environment can recover after a failure.
• Self-service provisioning: The computational resource can be scaled up according to the demands in an easier and faster way, using an interface, eliminating the traditional need for the IT administrators to provision and manage to compute resources.
• Elasticity: The computational resource can be scaled up or down at any time.
• Fault Tolerance: As the environment can be run in many local areas, across many global regions, this environment has more fault tolerance.

Clearly, cloud computing comes with many benefits to the business world, but to take advantage of this, the application needs to be prepared to work in the cloud computing approach. But what does it mean?

The old approach used for a long time in the technological world has used a monolith architecture — all business domains or many business domains inside the same application — to develop the application. The result is a big application that has many responsibilities. Figure 1.1 illustrates this as follows:

Figure 1.1: Monoliths

The monolith architecture has worked very well and works very well today, but outside a cloud computing environment. The monolith is not adequate to take advantage of cloud computing, because if you need to scale up this application, you’ll scale all monolith, that is, you will scale all business domains inside monolith, and the benefit of pay only for the resources used will be lost. The resolution of this problem was rethinking how to architect the applications.

Microservice architecture

Rethinking about the architecture, the software engineers and architects noticed that to take advantage of cloud computing, he will have to break the monolith into the smallest parts with fine granularity to permit scaling only the part that really needs to be scaled. But how can it be broken? What are the metrics to define the boundaries of each part?

The microservice architecture breaks the monoliths into many small parts called microservice, which generally are broken according to the business domain, that is, each microservice has the responsibility to care about one business domain. Thus, the business domain is used to define the boundaries of the microservice. The use of the business domain as a base to define the microservices boundary is the approach widely used, but you can use another according to your scenario. But keep in mind that you should decompose to improve the ability to scale. Figure 1.2 illustrates this architecture as follows:

Figure 1.2: Microservice Architecture

In a microservice architecture, each microservice has low-coupling with each other, and they are independent and deployable. In other words, microservices are a small application that runs without the need for another microservice to do that. Those microservices integrate with each other when needed, to provide a response to the end-user. It is very good, but now the software engineers and architects have other problems. How will those microservices be managed and how will those applications be integrated with each other without becoming chaos? How to discover a new microservice when a new microservice service is born? How to load-balance those microservices and how will those microservices be scaled up and down without a side effect?

Twelve-factors

The twelve-factors (https://12factor.net) is a methodology that defines a set of steps (twelve steps) to building the software-as-a-service apps. Basically, when we create the microservices apps and run those in a cloud environment, we are creating a software-as-a-service because our software is exposed as a service to the end-user. An application totally compliant with the cloud is called a cloud-native application.

The twelve-factors is a guide to develop the applications capable to take advantage of cloud computing. In other words, when we follow all the steps of the twelve-factors guide, our applications or microservices are a cloud-native application and is totally compliant with the cloud computing approach. The following are the twelve factors:

1. Codebase: One codebase is tracked in the revision control, while many deploy.
2. Dependencies: Explicitly declare and isolate dependencies.
3. Config: Store config in the environment.
4. Backing services: Treat the backing services as attached resources.
5. Build, release, run: Strictly separate the build and run stages.
6. Processes: Execute the app as one or more stateless processes.
7. Port-binding: Export the services via port binding.
8. Concurrency: Scale-out via the process model.
9. Disposability: Maximize robustness with a fast startup and graceful shutdown.
10. Dev/prod parity: Keep development, staging, and production as similar as possible.
11. Logs: Treat logs as event streams.
12. Admin processes: Run admin/management tasks as one-off processes.

In this chapter’s stage, you can note that we had many changes about how to architect the software. The applications have needed to make communication with each other and improving their management. But, coming back to Java EE, how does Java EE behave in these new scenarios?

Java EE had many gaps with those changes, because although Java EE ha...

Table of contents

• Cover Page
• Title Page
• Copyright Page
• Dedication Page
• About the Author
• About the Reviewer
• Acknowledgement
• Preface
• Errata
• Table of Contents
• 1. Introduction to Jakarta EE
• 2. Jakarta Servlet
• 3. Jakarta Context and Dependency Injection
• 4. Jakarta RESTful Web Service
• 5. Jakarta Enterprise Bean
• 6. Jakarta Persistence
• 7. Jakarta Messaging
• 8. Jakarta Security
• 9. Jakarta Bean Validation
• Index