Cloud-Native Development and Migration to Jakarta EE E-Book

Ron Veen

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 230

Veröffentlichungsjahr: 2023

Beschreibung

Cloud-Native Development and Migration to Jakarta EE will help you unlock the secrets of Jakarta EE's evolution as you explore the migration and modernization of your applications. You’ll discover how to make your code compatible with the latest Jakarta EE version and how to leverage its modern features effectively.
First, you’ll navigate the realm of cloud-native development as you demystify containers and get introduced to the Eclipse MicroProfile, a powerful tool in your toolkit. Next, you’ll take the bold step of transitioning your applications from local hardware to the limitless possibilities of the cloud. By following the author’s expert guidance to deploy your Jakarta EE applications on Microsoft Azure, you’ll gain hands-on experience in managing cloud resources.
In the final leg of your journey, you’ll explore the world of serverless architecture. You’ll learn to design and run services that are truly serverless, harnessing the potential of the event-driven paradigm for scalability and cost-efficiency.
By the end of this book, you’ll have mastered Jakarta EE and become a proficient cloud-native developer. Join us on this exciting journey of transformation and innovation as you pave the way for the future of Jakarta EE and cloud-native development.

Leseprobe

Cloud-Native Development and Migration to Jakarta EE

Transform your legacy Java EE project into a cloud-native application

Ron Veen

David Vlijmincx

BIRMINGHAM—MUMBAI

Cloud-Native Development and Migration to Jakarta EE

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Gebin George

Publishing Product Manager: Kunal Sawant

Senior Editor: Nithya Sadanandan

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Hemangini Bari

Production Designer: Ponraj Dhandapani

Marketing Coordinator: Sonia Chauhan

Business Development Executive: Samriddhi Murarka

First published: November 2023

Production reference: 3231023

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1R.

ISBN 978-1-83763-962-5

www.packtpub.com

For my loved ones, whose sacrifices made it possible for me to work on this book.

– Ron Veen

For Mariska and my parents, Bernadette and Frits.

– David Vlijmincx

Contributors

About the authors

Ron Veen is a highly experienced software engineer, navigating the spectrum from Midrange Systems to Micro Services. Driven by his passion for software engineering and software architecture, he has amassed more than 15 years of experience working on the JVM and the Java ecosystem. Ron has seen all the frameworks and libraries from Apache to ZK and has worked with many versions of Java EE and later, Jakarta EE. An avid fan of alternative JVM languages like Groovy, Scala, Clojure, and his personal favorite Kotlin, Ron is also an Oracle Certified Java Programmer (OCP) and Sun Certified Business Component Developer (SCBCD/OCPBCD). Ron is also a regular speaker at international conferences.

David Vlijmincx is a software developer with 8 years of experience in the field. He has a strong background in software development, with a focus on building scalable, high-quality applications using the Java programming language. David’s expertise spans through a variety of projects, ranging from small, standalone applications to large, complex systems, which needed to be migrated to newer versions of the EE specification or the cloud. David is an Oracle Certified Java Programmer (OCP) and is an avid blogger and speaker at industry conferences.

About the reviewer

Edwin Derks, a distinguished Java Champion hailing from The Netherlands, excels in unraveling intricate and strategic IT challenges as a dedicated Consultant. He is passionate about gathering and sharing knowledge on various facets of the Java ecosystem, composable architectures, and cloud-driven development . He actively contributes to MicroProfile and Jakarta EE and often speaks at conferences, passionately sharing his knowledge and experience.

In his spare time, he is a loving husband and a father of three. He can often be found in the gym or having a good time at dance parties or heavy metal concerts.

Table of Contents

Preface

Part 1: History of Java EE and Jakarta EE

1

The History of Enterprise Java

What is Java EE, and why was it created?

Web servers versus application servers

Web servers

Application servers

Profiles to the rescue

Java EE 5, the first user-friendly version

The history of key features added in Java EE since version 5

Java EE 6

Java EE 7

Java EE 8

Summary

2

Introducing the Cargo Tracker Application

Technical requirements

What is the Cargo Tracker application?

Why we chose the Cargo Tracker application

Installing and running the Cargo Tracker application

Features of the Cargo Tracker application

Public Tracking Interface

Administration Interface

Mobile Event Logger

Java EE features used in the Cargo Tracker application

Enterprise Java Beans

Persistence (JPA)

Messaging (JMS)

Context and Dependency Injection

Java Service Faces (JSF)

JAX-RS

JSON binding

Transactions

Batch

Summary

Part 2:Modern Jakarta EE

3

Moving from Java EE to Jakarta EE

Technical requirements

It’s all about namespaces

Migrating strategies

Using an open source multiplatform editor

Sed

Using a specialized plugin for your IDE

Upgrading your pom.xml file

Migrating dependencies

Upgrading the project

Upgrading the Payara application server

Upgrading PrimeFaces

Red Hat MTA

Upgrading your application server

Summary

4

Modernizing Your Application with the Latest Features

Technical requirements

The most significant changes to Jakarta EE 10

Core Profile

Using UUIDs as keys

Multi-part form parameters

Pure Java Jakarta Faces views

Authenticating with OpenID

Improved concurrency

Adding the first cloud-native feature – resilience

Adding the second cloud-native feature – monitoring

Looking at the default metrics of a running system

Adding metrics to your system

Using Prometheus and Grafana to visualize the monitoring process

Setting up Prometheus

Setting up Docker Compose

Setting up the Prometheus settings

Setting up Grafana

Setting up docker-compose

Setting up the auto data source

Setting up the dashboard so that it loads automatically

Showing Grafana Docker

Showing the complete Docker file

Summary

5

Making Your Application Testable

Technical requirements

The impact of testing on your migration

Measuring code coverage of the project

A word about TDD

How to create unit tests

Tools and libraries required for unit testing

Creating a unit test

How to create integration tests

What are integration tests?

What is Testcontainers?

Setting up Testcontainers

Creating an integration test

Summary

Part 3:Embracing the Cloud

6

Introduction to Containers and Docker

Technical requirements

What are containers?

How are containers created?

A brief introduction to Docker

Installing Docker

Running a Docker container

Creating a Docker container

Building a container

Running a container

Running the container in detached mode

Stopping a running container

Using Docker Compose

Summary

7

Meet Kubernetes

Technical requirements

In the beginning

What is container orchestration?

Why would you need Kubernetes?

Self-healing

Load-balancing and networking

Persistent storage and volumes

General

Pods versus containers

Some Kubernetes lingo

Extending Kubernetes

Kubernetes architecture

Where to run Kubernetes

Use your own hardware

Using a hosted service

A simple example

Summary

8

What Is Cloud Native?

Technical requirements

What is cloud native?

Cloud-native principles

Microservices

Containers and orchestration

DevOps

CI/CD

Introducing the 12-factor app

Code base

Dependencies

Config

Backing services

Build, release, run

Processes

Port binding

Concurrency

Disposability

Dev/prod parity

Logs

Admin processes

How to start the transformation

Summary

9

Deploying Jakarta EE Applications in the Cloud

Technical requirements

Deploying to Azure

Creating a container registry

Uploading an image to the registry

Creating a container instance

Metrics of containers in the cloud

Summary

10

Introducing MicroProfile

Technical requirements

A brief history of MicroProfile

MicroProfile Config

MicroProfile Health

MicroProfile Fault Tolerance

@Asynchronous

@Retry

@Timeout

@Bulkhead

@CircuitBreaker

@Fallback

Final remarks

MicroProfile Metrics

@Counted

@Gauge

@Metric

@Timed

Telemetry Tracing

Automatic instrumentation

Manual instrumentation

Other specifications

OpenAPI

RestClient

JSON Web Token Authentication

Jakarta EE 10 Core Profile

Summary

Appendix A

Java EE to Jakarta EE names

Appendix B

As a Service

Index

Other Books You May Enjoy

Preface

Welcome to our comprehensive guide on Cloud-Native Development and Migration to Jakarta EE! In the pages of this book, you are about to embark on a transformative journey through the evolution of Jakarta EE, exploring its rich history and evolution.

Our aim is to unlock the complex world of Jakarta EE, guiding you through the migration and modernization of your existing applications. As you turn the pages, you will discover how to make your code compatible with the latest Jakarta EE version and leverage its modern features effectively.

The adventure doesn’t stop there. We’ll dive into the realm of cloud-native development as we demystify containers and introduce the Eclipse MicroProfile, a powerful tool in your toolkit. Together, we will transition your applications from local hardware to the limitless possibilities of the cloud. With our expert guidance, you will learn to deploy your Jakarta EE applications on Microsoft Azure, gaining hands-on experience in managing cloud resources.

But that’s not all; the final leg of your journey explores the world of serverless architecture. Here, you will learn to design and run services that are truly serverless, harnessing the potential of the event-driven paradigm for scalability and cost-efficiency.

By the end of this book, you will not only be a Jakarta EE expert, but also a proficient cloud-native developer. So, join us on this exciting journey of transformation and innovation as you pave the way for the future of Jakarta EE and cloud-native development.

Who this book is for

This book is tailored for developers seeking valuable insights into how to migrate their applications from Java EE to Jakarta EE and seamlessly integrate them into a cloud environment. Within these pages, developers will find guidance on every step required to transition their applications from Java EE to the latest Jakarta EE version.

This book equips developers with the knowledge to modernize their applications with the latest features and to get it up and running in a cloud environment.

What this book covers

Chapter 1, The History of Enterprise Java, introduces you to the history of Java EE and Jakarta EE.

Chapter 2, Introducing the Cargo Tracker Application, starts with an overview of the Cargo tracker application’s functionality. The second half takes a look at the Java EE features that are used in the project.

Chapter 3, Moving from Java EE to Jakarta EE, describes how to approach the migration from Java EE to Jakarta EE.

Chapter 4, Modernizing Your Application with the Latest Features, provides an overview of the significant changes made to Jakarta EE 10. The chapter will also show you how to implement cloud-native features like resilience and monitoring. Lastly, we will show you how to visualize the metrics coming from your application.

Chapter 5, Making Your Application Testable, provides an overview of why testing is important when migrating a software project and how to measure it. You will learn how to write unit tests and integration tests for modern applications to ensure the application keeps working as expected.

Chapter 6, Introduction to Containers and Docker, provides an overview of what containers are and why they are an important tool. You will learn what Docker is, how to install it, and how to create a Docker container based on the Cargo tracker application.

Chapter 7, Meet Kubernetes, introduces you to Kubernetes, the de facto standard for running containers.

Chapter 8, What is Cloud Native?, describes the principles of cloud-native computing.

Chapter 9, Deploying Jakarta EE Applications in the Cloud, provides an overview of deploying an application to the Azure cloud. You will learn how to create a container registry and how to create an instance from a container in the registry. This chapter also covers how you can see the metrics of the deployed instance.

Chapter 10, Introducing MicroProfile, introduces the most important specifications of the MicroProfile specification.

Appendix A, Java EE to Jakarta EE names, is a list of Java EE to Jakarta EE specifications.

Appendix B, As a Service, explains the different concepts of using the Internet for computing.

To get the most out of this book

For optimal learning, it is essential to have prior experience in developing Java applications using an enterprise framework like Java EE, Jakarta EE, or Spring.

Software/hardware covered in the book

Operating system requirements

Azure Cloud

Windows, macOS, or Linux

Java 17

Java EE 7

Jakarta EE 10

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Cloud-Native-Development-and-Migration-to-Jakarta-EE. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “The param-value tells PrimeFaces that we want to use the omega theme for the project.”

A block of code is set as follows:

<context-param>    <param-name>primefaces.THEME</param-name>    <param-value>saga</param-value> </context-param>

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

mvn compile

Any command-line input or output is written as follows:

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “If a quick fix can be applied, you can do so by right-clicking the incident and choosing Apply All Quickfixes.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Cloud-Native Development and Migration to Jakarta EE, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781837639625

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: History of Java EE and Jakarta EE

In this part, you will get an overview of the history of enterprise Java and the application we will be migrating throughout this book. The historical context will shed light on the transformation from Java EE and underscore the necessity of migrating to Jakarta EE 10. This will also include the changes that Jakarta EE made to make developing applications easier. The introduction of the Cargo tracker will help you familiarize yourself with the application, so you know what we are migrating and the challenges we’ll encounter.

This part has the following chapters:

Chapter 1, The History of Enterprise JavaChapter 2, Introducing the Cargo Tracker Application

1

The History of Enterprise Java

In this chapter, we will look at the history of Java EE and Jakarta EE. Since its inception, Java enterprise technology has had several names – starting as J2EE, then being rebranded as JEE, followed by Java EE, and finally, Jakarta EE.

In this chapter, we will cover the following topics:

What is Java EE, and why was it created?Web servers versus application serversJava EE 5, the first user-friendly versionThe history of key features added in Java EE since version 5

By the end of this chapter, you will have a better understanding of Java EE and Jakarta EE in a historical sense, and you will know some of the key features added to Java EE. Changes to Jakarta EE will be discussed in subsequent chapters.

What is Java EE, and why was it created?

The Java language was introduced to the world in 1996. It consisted of a compiler and a Java virtual machine. Both components are platform-dependent, meaning that you have different versions for Windows, Linux, macOS, and so on. This is called Java Standard Edition (Java SE).

The Java language is unique in that it does not compile to native machine code but, instead, to something called bytecode. This bytecode is platform-independent, meaning it can be transferred to any of the aforementioned platforms.

To execute the bytecode, you would need a Java Virtual Machine (JVM). The JVM translates the intermediate bytecode to machine code, specific to the platform it is executed on.

This principle of compiling to bytecode and being able to execute it on any platform was dubbed Write Once, Run Anywhere (WORA). This has proven to be the distinctive feature that has led to the success of Java in business environments.

Initially, Java was meant to run in browsers, inside so-called applets. These applets added a lot of functionality to the early browsers such as Microsoft’s Internet Explorer and Netscape’s Navigator.

Free versions of Java were supplied to several popular platforms, which aided in the rapid success of the language.

The JVM specification could be licensed by third parties, allowing them to build their own implementations of the compiler and the JVM. Several companies have done so, which means that there are now several vendors that offer their own implementation. The most common are (in alphabetical order) as follows:

Alibabi DragonwellAmazon CorettoAzul ZuluBellsoft LibericaEclipse Adoptium TemurinJ9Oracle Oracle JDK and OpenJDKRedhat OpenJDKSAP SapMachine

But soon, Java moved out of the realm of browsers into the business world. It became obvious that developing business applications required additional functionality that was not part of the language.

Instead of adding this functionality to the language itself, it was decided that it would better be provided by a separate set of APIs. To avoid confusion and distinguish between Java SE and these new APIs, they were called Java Enterprise Edition (Java EE).

Java EE added features such as transactions, security, scalability, management of components, and concurrency. It allowed you to create dynamic web applications and provided a robust platform for distributed transactions.

Web servers versus application servers

The terms web servers and application servers are often confused by people new to Java EE and used interchangeably, although this is not correct. In this section, we will highlight the differences between the two, as we believe that it is important to know the differences between them, as both are key components of Java EE, but each plays its own role.

Starting to understand the difference between them is best done by highlighting their goals.

Web servers

Web servers implement the Servlet API, which is a set of classes and interfaces defined in the specification that allow you to create dynamic web applications. Applications based on the Servlet API, called Servlets, run inside a web server and serve, possibly dynamic, content to their users.

There are a number of technologies developed over the years that support the Servlet API. Specifications such as Java Server Pages (JSP), Java Standard Tag Libraries (JSTL), Java Server Faces (JSF), and Bean Validations are the most notable. Later, Java API for XML Web Service (JAX-WS) and Java API for Restful Web services (JAX-RS) were added.

There are many popular, standalone implementations of the Servlet API, such as the following:

TomcatJettyNGINX

All these provide a Servlet container in which servlets can run.

It is good to understand that you can run multiple servlets inside one servlet container. In the early days, this was a common practice, as it allowed you to run more than one application on the same piece of hardware.

For good measure, it should be noted that a framework such as Spring Boot still uses the Servlet API. This means that at the core level, some implementation of the Servlet API is still running. In the case of Spring Boot, however, which servlet container implementation is being used is pluggable, meaning you choose it yourself.

Application servers

Conversely, application servers do have the requirement of supplying an implementation that supports the Servlet API, but they offer far more than that. Application servers offer a richer environment, more targeted at executing business logic. They offer Enterprise Java Beans (EJBs). EJBs come in three major flavors:

Session Beans (SBs)Entity Beans (EBs)Message-Driven Beans (MDBs)

Session beans can be further divided into Stateful Session Beans (SFSBs) and Stateless Session Beans (SLSBs). Session beans contain business logic.

Entity beans, which handle database operations, came as Container Managed Persistence (CMP) and Bean Managed Persistence (BMP) entity beans. In the former, the application server was responsible for handling the persistence and retrieval of the data, while in the latter, an application developer had to write the queries to select and update the database themselves.

We write this in the past tense, as entity beans were dropped altogether in version 3 of the EJB specification, delivered in Java EE 5, in favor of the Java Persistence API (JPA).

Furthermore, application servers provide APIs for declarative and programmatic transaction management. As with entity beans, the difference is that in the former, the container will start, commit, or roll back transactions automatically, while in the latter, this has to be done in code.

The Java Messaging Service (JMS) is another feature that is required for application servers. JMS allows you to asynchronously exchange messages between different applications or application components.

JMS offers one-to-one connections between two components via queues while offering a one-to-many message exchange via topics.

Furthermore, application servers allow the registration and discovery of components via the Java Naming and Directory Interface (JNDI). As an example, an EJB to send emails can be instantiated and successively registered in the JNDI registry. Another EJB, which requires the functionality of sending an email, is then able to look up this email service by its name in the registry and use it.

In addition to this, functionality such as declarative security, concurrency, and interceptors are provided by application servers.

Some very popular application servers are as follows:

IBM WebsphereJBoss ApplicationOracle GlassfishOracle WeblogicPayara Server Enterprise

Application servers had a tendency to be heavy, and startup times were awful. Taking 10–15 minutes to start up and bringing the deployed applications to an initialized state was quite common in the early days. However, nowadays, it is very common that they start within a few seconds.

Profiles to the rescue

In the early years of Java EE, there was one simple rule if you wanted to be a Java EE compatible server – you had to implement all the specifications. However, it soon became clear that not every application required a full-blown application server. Often, a web server was more than enough.

To make this distinction clearer, profiles were introduced. The first one was Web Profile, which made its first appearance in Java EE 6. It was made up of the Servlet, JSF, JSP, EJB, CDI, JTA, JPA, and Bean Validation specifications.

The full set of all specifications became known as the Full Platform Profile.

In Jakarta EE 10, the Core Profile was introduced. This contains an even smaller subset of specifications and targets microservices, edge-computing, and ahead-of-time compilation. In Chapter 2, we will dive deeper into these subjects.

The following diagram depicts the different profiles and the specifications they are required to implement. The image was taken from the Jakarta EE website (https://jakarta.ee/release/10/).

Figure 1.1 – The different Jakarta EE profiles and their specifications

Java EE 5, the first user-friendly version

This thing that hampered Java EE most of all was the sheer amount of configuration that you had to provide. All of these configurations had to be done in so-called XML deployment configuration files. We refer you to the documentation at https://docs.oracle.com/cd/E13211_01/wle/dd/ddref.htm, should you be interested in the content of the files.

For a container-managed entity bean, for instance, you had to specify each of the methods that were exported, its type parameters, and the return value.

It was not uncommon to have these configuration files being more than 300–400 lines of XML. This was called configuration hell, and this is where Java EE (back then still called J2EE) got its reputation in the developer community for being bloated.

Developers got so frustrated with this type of configuration that alternatives arose. The rise of the now very famous Spring Framework can be attributed to exactly these feelings. The Spring Framework itself required some XML configuration, but it wired up a lot of parts automatically for developers. Back then, what the Spring Framework did mostly, next to adding dependency injection, was wiring up the different components.

In 2005, version 5 of Java EE was released. This was the first time that J2EE was rebranded Java EE, but more importantly, it introduced annotations for the first time. Annotations allowed you to specify certain configuration options already in the code, thus providing a reasonable default setting. Now, it only was required to specify the situations where the configuration should divert from these default values. This is called convention over configuration, and it immensely reduces the amount of configuration required.

Another improvement was that you could now simply annotate a bean with, for instance, @Local, to define it as a local EJB. Again, dozens of lines of configuration were saved.

This was actually part of the introduction of the EJB3 specification. It was revolutionary in that sense that it deprecated the traditional entity beans in favor of the Java Persistence API(JPA).

JPA was heavily influenced by frameworks such as Hibernate, which provided an object-relational persistence approach. This meant that the mapping between database fields and Java fields was done by the framework now; no longer was application code required to achieve this mapping. This is known as Object-Relational Mapping (ORM).

With Java EE version 5, a very competitive and, maybe for the first time, very developer-friendly version of the specification became available. Suddenly, developing Java EE applications was not something just for very experienced developers anymore.

The history of key features added in Java EE since version 5

Let us now have a quick look at what changes have been introduced in Java EE after version 5.

Java EE 6

The most