Before sketching the Java EE architecture, let's take a quick look at the process through which the standard is created.

Java EE is a standard designed for building enterprise applications with the Java programming language. It contains a number of specifications, which define functionalities required by implementations of the standard.

Specifications that constitute Java EE are developed in an open, community-based process. Both organizations and individual users can join it and take part in the development.

As a standard, Java EE may possess multiple implementations. A vendor who is willing to create a product that is Java EE-certified has to pass a technology compliance test, which guarantees that the product is in alignment with the standard.

The standard provides the contract between enterprise application developers and the vendors of standard implementations. An application developer can be sure that their application will be supported and portable, as there are a number of standard implementations; they are not dependent on one vendor. Application developers are free to migrate their applications between different standard implementations.

It is also important to note that the standard does not determine the details of server implementation. As a result, vendors have to compete to provide the most efficient, robust, and easy-to-use implementation.

To sum up, the Java EE standard provides enterprise application developers with an ability to write supported and portable applications. Furthermore, the community-based specification development process and competition between vendors help the standard to evolve and allows users to choose the best implementation for their needs.

On the flip side, the fact that Java EE is a standard implementation result in a slower evolution and decision-making process than alternative frameworks. In a world in which technology is being developed rapidly, this becomes a bigger problem. As a result, recently, an effort has been made to refactor the way in which standards and specifications are created. Java EE is currently transforming into EE4J, a standard developed under Eclipse Foundation's governance. We will return to this topic in the final Chapter 12: Future Directions.

Java EE applications are written in the Java language and run on Java virtual machine (JVM). On top of the standard Java SE functionality, the Java EE implementation provider implements a number of services, which can be used by those applications. Examples of such services may be security, transactions, or dependency injection.

Applications don't interact with enterprise services directly. Instead, the specifications define the component and containers concepts. Components are software units written in the Java language and configured and built in a similar way to standard Java classes. The difference is that metatada provided with the component allows it to be run using a runtime provided by the Java EE implementation. Such a runtime, which may differ for the different types of component, is called a container. The container is responsible for providing access to all enterprise services required by the component.

As an example, let's take a look at the following component:

package org.tadamski.examples.javaee;

import org.tadamski.examples.java.ee.model.Foo;

import javax.ejb.Stateless;
import javax.enterprise.event.Event;
import javax.inject.Inject;
import javax.persistence.EntityManager;

//1
@Stateless
public class FooDaoBean implements FooDao {

    //2
    @Inject
    private EntityManager em;


    public void save(Foo foo) throws Exception {
        //3
        em.persist(foo);
    }
}

The preceding script presents an ejb component (1), that is, FooDaoBean, which is responsible for saving objects of the Foo type into the database.

The ejb container in which this component will run will be responsible for pooling instances of this component and managing the lifecycle for all of them. Furthermore, this concrete component takes advantage of the number of enterprise services: dependency injection (2), ORM persistence (3), and transactions (the default for this kind of component).

In general, the goal of the Java EE runtime is to take care of all technical aspects of enterprise applications so that the application developer can concentrate on writing business code. The preceding example demonstrates how it is realized in Java EE: the application developer writes their code using POJOs with minimal configuration (provided mostly by annotations). The code written by an application developer implements business functionalities declaratively, informing middleware about its technical requirements.

Traditionally, business applications written in the Java EE technology were based on a three-tier architectures, web, business, and enterprise information system tier:

Application server implements web and business tiers. It can be accessed by various types of clients

Web components, such as Servlets, JSPs, or JAX-RS, allow for the implementation of the web layer. They are able to respond to the HTTP requests from different kinds of clients. For example, JSF may be used to create web user interfaces in a convenient way, whereas the JAX-RS API allows for the implementation of RESTful services.

The business layer is implemented by EJBs, pooled POJO-based components that allow for the easy implementation of transactional operations and that can provide a wide array of capabilities such as security, database, external system integration, remote access, or dependency injection.

Although the bird's-eye view architecture is quite straightforward, it is very elastic and allows for the implementation of a wide array of enterprise applications. Moreover, the standard has evolved throughout the years, providing tools for a wide array enterprise usage.

If you take a look at Java EE specification (Further Reading, link 1) you will be able to see all the specifications that are part of the standard. The shared amount of them may be intimidating at first slight. It should be noted that, in most cases, you will have to deal with only a subset of those. On the other hand, when your applications require any kind of enterprise functionality, it is highly probable that the needed tool is already there for you—integrated with the whole platform and easy to use.

Java EE standard implementations are runtimes that allow us to run the components and provide them with the services specified in the Java EE standard. Such runtimes are called application servers.

Application developers create components based on the specification. Those components are assembled into archives, which can be deployed on application servers.

Application servers allow for the deployment of a number of applications. Furthermore, as hinted at the beginning of this chapter, an application can change the server implementation and deploy archives using the application server from the other vendor:

The way applications are developed evolves over time. Let's sketch concepts that have had a big impact on software development in recent years: cloud computing and microservices.

Cloud computing is an infrastructure that makes it possible to automatically provision computing resources on demand. The types of resource provided depend on the contract between the cloud provider and the customer—the cloud provider can provide software services, such as email or disk storage, platforms for software development, access to virtual machines, or infrastructure for running software applications.

The resources are provided dynamically and rapidly using the internet, and, as a result, the customer is able to use (and pay) for resources that they currently use. The cloud provider, on the other hand, can take advantage of economies of scale: specialization and optimal resource usage will result in quality improvements and cost optimization.

So, how does interaction with cloud computing infrastructures look from the developer's point of view? During the development, the cloud provider provides a platform that contains a number of tools: it enables developers to run multiple application frameworks, standalone services, and databases among others. It provides functionalities and tools needed by those applications: scaling, networking, security, and communication. Furthermore, as hinted earlier, a user pays only for the resources used; cloud infrastructure will adjust the resources provided based on the load used by your application.

The preceding description sounds promising, but it immediately raises a number of questions, such as how are the resources provisioned and scaled, what kinds of tools can I use, and what are the APIs for the tools provided.

One of the goals of this book is to provide you with all this information throughout. For the purpose of this introductory chapter, it is enough to acknowledge the most important information: cloud computing infrastructures will enable us to develop and deploy with a wide array of tools using computing resources provided on demand.

Microservices architecture is a software development methodology that advocates creating an application from loosely coupled services that cooperate together.

Such an architecture was researched and advertised for a long period of time: Some time ago, a lot of attention was given to Service-Oriented Architecture (SOA). Even earlier, CORBA, the standard for distributed computing, was designed. Furthermore, building your applications with loosely coupled, highly cohesive services is a good software practice, and it can (and should) also be applied in a traditional monolithic application. Why has the new concept been created then, and what distinguishes it?

In recent years, a number of companies building large distributed systems have found it harder to build and maintain their systems using the traditional monolithic software architectures and decided to refactor their systems to loosely coupled modular distributed systems. Looking at the experience of those companies that succeeded in doing so, we were able to gather common architectural patterns in the systems that they built. This gave birth to the microservice architecture concept. Put in another way, microservices can be thought of as a software architecture that is another iteration of distributed computing systems, whose characteristics were derived from practical experience. As a result, instead of providing a definition of microservice architectures to which all aspiring implementors have to adhere, it is easier to provide a common set of characteristics that microservice systems share (Further Reading, link 2). Let's do it now.

Microservices are built as standalone services that are independently deployable. From the technical point of view, it means that they run in different processes and communicate through the network using their APIs. Each of the services can be started, stopped, and updated independently. Each service is responsible for its own data and can modify the data of other services using only their API.

The system is decomposed into microservices around business functionalities. Each microservices is built by one, small team that consists of all necessary technical specialists. For example, in a store application, there may be a review service. The review service team may consist of programmers, database engineers, testers, and domain experts. The team is responsible for every aspect of this service—from getting customer feedback to database administration.

As you can see, instead of advertising a set of recommended characteristics that the applications should adhere to, successful microservice practitioners have created a technological environment that enforces modularity and loose coupling.

So, if you successfully implement a microservice architecture, what benefits will you obtain?

The first thing that is straightforward but should be emphasized is that if you successfully create a system whose architectural characteristics-force modularity and loose coupling, you will obtain a highly modular system as ad hoc fixes and extensions won't compromise and effectively abandon the boundaries between services throughout the development process.

Because of the modular characteristics of developed applications, components that constitute them may be developed more effectively: As there is a small, cross-sectional team working on each service, its members can concentrate on their own area of work relatively independently of other teams. As the practice suggests, as the team grows communication starts to inhibit work more and more. The small, focused team knows the domain well, and they also know each other well, can communicate immediately, and move the work forward.

Also, crucial is the fact that the service can be deployed independently of other services. A successful microservices architecture does not have the concept of big system release in which all teams gather their recent updates together and create a major release of the whole system. Instead, all teams are able to release and deploy their new functionalities independently of other services. There is no synchronization between the teams, and if there is a new version of a service that can be released, the service's team can just independently design to do it. Such a characteristic is a catalyst for Continous Integration. The team is able to build the pipeline so that each code triggers a test, review, and deploy process.

The characteristics described in the preceding paragraph—small, focused teams and independent and automated build and deployment processess—lead to very important characteristics of the successful microservices-based system: an ability to implement required changes very fast. This is crucial, as it allows for immediate responses to customer needs. This tightens the feedback loop between the customer and developer and allows the system to quickly evolve to meet the customer needs.

Last but not least, we should mention the direct technical consequences. Microservices can be scaled more effectively: When scaling a traditional monolith application, we need to replicate a number of application servers effectively, replicating all the functionalities implemented in the application. Scaling microservices can be more fine-grained; we are able to replicate only the services that need more instances across different servers.

Furthermore, microservices architecture tends to improve the availability: if a review service is down, the rest of the store can work regardless of it. Such a situation is obviously far from ideal but way better than a shutdown of the whole system.

In the preceding paragraph, we mentioned that the preceding characteristics apply to successful microservices implementation. As it turns out, creating such systems is not simple. Let's learn why.

The challenges that encompass implementing microservice architecture can be summarized in one phrase: distributed system.

Is the functionality that you will implement will use a bunch of services throughout a network. You will have to deal with network delays and failures. What if the response is not immediate? Is the target service down or busy? How should we find out, and what we should do about it?

Should the data belong to one microservice? Easier said than done. We can make the database underlying the service consistent, but how do we propagate this information to other services that rely on this data?

Also, it is nice that each team can work independently, but what if we really need to implement cross-service functionality? That can become a pain: a cross-team endeavor that may introduce large architectural changes and substantially impact the whole architecture.

Let's assume that we managed to deal with the preceding problems and have a running system. What happens when an error occurs? We will have to analyze logs scattered around a number of services, also tracing network interactions between all of them.

So, how should you decide whether the microservice architecture is suitable for your application?

Microservices should primarily be considered for systems in which managing the traditional monolithic application has become too complex to develop and maintain. If you are developing a small application, additional complexity, described in the preceding paragraph, may outweigh the modularity benefits and inhibit, instead of amplifying, your development process.

It has been suggested (Further Reading, link 3) that microservices architecture should be an evolution of the monolith application. Most systems should start as a monolith, and the transition to microservices should only be considered when the system grows to the extent that it becomes too hard to develop and maintain.

Last but not least, if the system is badly designed, the transition to microservices won't magically solve its problems. To put it more bluntly, distributing a messy system will result in an even greater mess. As we have already mentioned, microservices should be considered as a solution when the complexity of the system requires imposing modularity and not as a magical fix for badly written software.

In order to implement a successful microservices architecture, we will need to automate as much of the infrastructure as possible. Eventually, we will be dealing with a system containing a large number of independent services running somewhere across the network. Maintaining such systems manually is virtually impossible.

We will like each service to be automatically built, tested, scaled, and monitored. The cloud infrastructure is a natural microservices environment, which allows you to achieve that. Each service can be run and scaled on resources provided on demand, and the tools available will allow us to build, test, and connect the services in a fault-tolerant way.

You will learn about all of those in this book.

It's time to look how Java EE can fit into the cloud-microservices picture.

As mentioned in The basic architecture of Java EE applications section, traditionally, in Java EE, you were creating JARs with your applications and deploying them on an application server. With microservices, we will like to transform the same kind of JARs into runnable services:

In a traditional scenario, the application server has to support all the APIs specified in the standard.

In a microservices scenario, we will like to transform each JAR, which is an implementation of a microservice, into a runnable JAR. This can be done by creating a runtime for the given microservice and assembling this runtime and the service's archive into a runnable JAR. Since the assembled runtime will be used by only one service, we don't have to include all the Java EE modules in it. The tool that builds your microservices will have to analyze your service's archive and create a runtime, which contains only those functionalities that are required by it.

We have already sketched how we can use Java EE as a base for microservices architecture, but what are the benefits that you will achieve by doing so? Firstly, you will be able to take advantage of proven technologies and your experience with them immediately. Moreover, there is a portability aspect. As we covered in the preceding section, you are encouraged to start with monolithic applications and refactor it microservices, if necessary. Owing to the common set of technologies used and the standard archive format that is used in both scenarios, you can easily migrate between the two, creating an elastic architecture that can be changed and refactored when necessary.

As you are going to learn in this book, you are able to use your existing Java EE knowledge to create microservices architecture. This knowledge will not be sufficient though, because, as we mentioned in the Microservices section, this kind of architecture introduces its own complexity, which has to be handled.

The goal of this book is to fill this knowledge gap by providing you with a practical, hands-on introduction to the development of microservice-based applications running on cloud infrastructures. This book makes an assumption that you are familiar with Java EE and the traditional way of developing Java EE applications. It will complement this knowledge with the information about a concrete set of tools that will allow you to immediately take advantage of both cloud computing and microservices.

We will like to emphasize that this book does not advertise any particular methodology, and, as we mentioned in the Microservices section, any architecture decision should be made with regard to the concrete project, taking into consideration all the advantages and disadvantages. Our goal is to provide you with a set of tools so that if you decide to make such a transition, you will immediately know what to do.

Throughout the book, we will develop a sample application, which will serve as a base for all our examples. Let's learn more about it now.

Computer programming books often start with the Hello World application. Similarly, books describing a framework often develop a pet store application. We will follow this tradition. The pet store that we will develop will be a simple application that will allow you to browse the catalog of pets, add some of them to your cart, and finalize the payment.

During the development of the application, we will be concentrating on cloud and microservice aspects. The service code is simple and uses basic Java EE technologies so that the reader can concentrate on what is being taught in this book: cloud integration and microservices development.

Let's take the bird's-eye view of the application:

The backend services (red), gateways (yellow), and security server (blue) are deployed in a cloud. The UI application (green) is deployed outside the cloud.

The gateway services are responsible for providing APIs for different users. The customer gateway provides an API for customers, which is used by petstore-ui—web-client implementing the store interface. The customer gateway orchestrates invocations to the underlying base services and is accessible from outside the cloud.

The security service is responsible for the authentication and authorization of access to different parts of the API. It is used by all other components. The security service is accessible from outside the cloud.

The core functionalities are implemented by backend services. Backend services are not accessible from the gateway service. Let's take a look at their functions:

• Catalog service: Provides information about pets available in the store
• Pricing service: Responsible for providing the price of a given pet
• Cart service: Responsible for keeping information about the cart of a given customer

We will develop the application step by step throughout the book. The application is attached to the book, and as a result, you could work with it immediately while learning various concepts described in the book.

We will convert our traditional Java EE JARs into runnable ones using WildFly Swarm—the tool that we will introduce in Chapter 2, Get Familiar with WildFly Swarm. WildFly Swarm is able to wrap our application into a JAR containing a minimal number of libraries needed for it, effectively creating microservices from a deployable JAR. We will cover how Swarm does it in Chapter 3, Right-Size Your Applications, and how to configure the created services in Chapter 4, Tuning the Configuration of Your Services.

After services are written, we have to write tests for them. We will use the Arquillian library to do it. We will discuss how to use it in Chapter 5, Testing Your Services with Arquillian.

We will deploy the created services in cloud using OpenShift. In Chapter 6, Deploying Applications on the Cloud with OpenShift, we will give you a theoretical introduction to the platform, the API, and tools that it provides. In Chapter 7, Configuring Persistent Storage for your Applications, we will discuss how to configure persistent storage for our applications on OpenShift and how to scale and connect our services.

Creating and deploying applications in cloud is not enough for them to be ready for production. We still need to secure them, monitor them, and take care of network failures.

To provide security, we will take advantage of the Keycloak server. In order to take care of network failures, we will use the Hystrix library. In order to provide monitoring.

This chapter was intended to give you an overview of what you can expect from reading this book.

We have recalled basic information about Java EE and the traditional way in which it was used to develop enterprise application. Later, we introduced modern trends in software development: cloud computing and microservices architecture.

Then, we introduced the pet store—the sample application that we are going to develop throughout the book.

Finally, we introduced all the technologies and tools used throughout the book, such as WildFly Swarm, OpenShift, Hystrix, Jenkins, and Keycloak.

1. http://www.oracle.com/technetwork/java/javaee/overview/index.html
2. https://www.youtube.com/watch?v=wgdBVIX9ifA
3. https://martinfowler.com/bliki/MonolithFirst.html