Enterprise Java Microservices

Kenneth Finnigan

• Editorial: Manning
• Año: 2018
• ISBN:
  9781638355960
• Categoría: Ciencia de la computación
• Categoría: Programación en Java

Summary Enterprise Java Microservices is an example-rich tutorial that shows how to design and manage large-scale Java applications as a collection of microservices.Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the Technology Large applications are easier to develop and maintain when you build them from small, simple components. Java developers now enjoy a wide range of tools that support microservices application development, including right-sized app servers, open source frameworks, and well-defined patterns. Best of all, you can build microservices applications using your existing Java skills. About the Book Enterprise Java Microservices teaches you to design and build JVM-based microservices applications. You'll start by learning how microservices designs compare to traditional Java EE applications. Always practical, author Ken Finnigan introduces big-picture concepts along with the tools and techniques you'll need to implement them. You'll discover ecosystem components like Netflix Hystrix for fault tolerance and master the Just enough Application Server (JeAS) approach. To ensure smooth operations, you'll also examine monitoring, security, testing, and deploying to the cloud. What's inside

• The microservices mental model
• Cloud-native development
• Strategies for fault tolerance and monitoring
• Securing your finished applications

About the Reader This book is for Java developers familiar with Java EE. About the Author Ken Finnigan leads the Thorntail project at Red Hat, which seeks to make developing microservices for the cloud with Java and Java EE as easy as possible. Table of Contents

PART 1 MICROSERVICES BASICS

• Enterprise Java microservices
• Developing a simple RESTful microservice
• Just enough Application Server for microservices
• Microservices testing
• Cloud native development

PART 2 - IMPLEMENTING ENTERPRISE JAVA MICROSERVICES

• Consuming microservices
• Discovering microservices for consumption
• Strategies for fault tolerance and monitoring
• Securing a microservice
• Architecting a microservice hybrid
• Data streaming with Apache Kafka

Part 1. Microservices basics

What are Microservices? A microservice consists of a single deployment executing within a single process. How do microservices differ from traditional Enterprise Java applications? In what situations is it appropriate to use microservices? These are just some of the questions that we’ll address in these first five chapters.

Part 1 also explores the runtime options available for Enterprise Java micro-services, before finishing with how to test microservices and deploy them to the cloud.

Chapter 1. Enterprise Java microservices

This chapter covers

• Enterprise Java history
• Microservices and distributed architecture
• Patterns for migration to microservices
• Enterprise Java microservices

Before you dive in, let’s step back and discuss what I hope you achieve during the course of this book. We all know that there’s no such thing as a free lunch, so I won’t pretend that microservices are easy. This chapter introduces microservices—their concepts, benefits, and drawbacks—to provide a basis on which you can build your technical knowledge. Chapters 2 and 3 provide an example of a RESTful endpoint microservice and cover some of your runtime and deployment options for Enterprise Java microservices.

So what is an Enterprise Java microservice? In a nutshell, it’s the result of applying Enterprise Java to the development of microservices. The latter part of this chapter and the remainder of the book explore in detail what that means.

After you’ve learned the basics of microservices, you’ll delve into tools and techniques for use in Enterprise Java to mitigate the drawbacks and complexity of micro-services. Being more familiar with microservices, you’ll then look at an existing Enterprise Java application and how it could be migrated to take advantage of micro-services. The last few chapters touch on more advanced microservice topics related to security and event streaming.

1.1. Enterprise Java—a short history

If you’re reading this book, you’re most likely already an experienced Enterprise Java developer. If you aren’t, I appreciate and applaud your desire to broaden your horizons into Enterprise Java!

1.1.1. What is Enterprise Java?

For those who are new to, or need a refresher in, Enterprise Java, what is it? Enterprise Java is a set of APIs, and their implementations, that can provide the entire stack of an application from the UI down to the database, communicate with external applications via web services, and integrate with internal legacy systems, to name a few, with the goal of supporting the business requirements of an enterprise. Though it’s possible to achieve such a result with Java on its own, rewriting all the low-level architecture required for an application would be tedious and error prone, and would significantly impact the ability of a business to deliver value in a timely manner.

It wasn’t long after Java was first released more than 20 years ago that various frameworks began to crop up to solve the low-level architecture concerns of developers. These frameworks allowed developers to focus on delivering business value with application-specific code.

Enterprise Java

Many frameworks have come and gone, but two have remained the most popular through the years: Java Platform, Enterprise Edition (Java EE), and Spring. These two frameworks account for most development by an enterprise with Enterprise Java.

Java EE incorporates many specifications, each with one or more implementations. Spring is a collection of libraries, some of which wrap Java EE specifications.

1.1.2. Typical Enterprise Java architecture

In the early days of Enterprise Java, our applications were all greenfield development, because no preexisting code was being extended.

Definition

Greenfield refers to the development of an entirely new application without any preexisting code that needs to be taken into consideration, excluding any common libraries that might be required.

Greenfield development presents the greatest opportunity to develop a clean layered architecture for an application. Typically, architects would devise an architecture similar to that shown in figure 1.1.

Figure 1.1. Typical Enterprise Java application architecture

Here you’ll likely recognize familiar pieces of architectures you’ve worked on in the past: a view layer, a controller, possibly using a reusable business service, and finally, the model that interacts with the database. You can also see the application packaged as a WAR, but many combinations of packaging for each layer could be applied, including JAR and EAR. Typically, the view and controller are packaged in a WAR. The business service and model are packaged in JARs, either inside a WAR or EAR.

As the years passed, we continued developing greenfield applications with Enterprise Java using such a pattern, but there reached a point where most enterprises were, for the most part, enhancing existing applications. From that day, many Enterprise Java applications became a legacy burden on enterprises by virtue of the maintenance work required—not because of a flaw or deficiency in Java, though there have been several, but because developers aren’t the best at architecting changes to existing applications and systems. This is complicated further for enterprises that have hundreds of architects and developers pass through their doors, each bringing their own preferences and patterns to extending existing applications.

Note

I’m not sitting in an ivory tower disparaging developers. Many times I’ve made decisions about how a feature should be implemented without fully grasping existing functionality—not through any intent or malice, but because those who wrote the code are no longer employed at the enterprise and therefore can’t be asked about the code, and because documentation may be lacking or nonintuitive. Such a situation means developers are left to make a judgment call as to whether or not they’ve understood the existing system sufficiently to make modifications. Throw in some deadline pressure from management, and such a situation becomes even more fraught with problems.

Over time, many Enterprise Java applications diverged from the clean architecture shown in figure 1.1 and became a mess of spaghetti more closely resembling figure 1.2. In figure 1.2 you can see how clear boundaries between functionality within a layer have become blurred, resulting in components in each layer no longer having a well-defined purpose.

This situation is where many enterprises find themselves today. Only a few applications of an enterprise may fit this mold, but this mess of spaghetti is a problem that must be solved in order for an application to foster future development without significant costs being incurred each time.

1.1.3. What is a monolith?

What defines an Enterprise Java application as a monolith? A monolith is an application that has all its components contained within a single depl...