Context and Dependency Injection (CDI) is the central specification of Java EE. Its role is to manage the beans you define. It is directly linked to the pattern called Inversion of Control (IoC), which provides a way to obtain loose coupling between your classes. The goal is to be flexible on the way so that the current instances are linked together. It also controls the life cycle and the instantiation of instances.

Before exploring the CDI, let's use a very simple example (I would say, a handmade example) to illustrate what a bean container is.

We will use an application that has TimeService, which simply provides...

Even if JAX-RS is not fully bound to HTTP and is usable over JMS, WebSockets, and so on, we will just consider the HTTP case here and, more particularly, the case it runs on top of the servlet specification (which is the most common one).

The goal of JAX-RS is to provide a command pattern based on the API to implement the HTTP communications. In other words, it abstracts the I/O with Java modeling. You can see it as a HTTP Java object binding solution. This is what QuoteResource uses.

The role of JAX-RS is to provide all the necessary tooling to make servlet abstraction directly usable for most cases. For this purpose, it provides the following:

• A routing layer letting developers directly map the request based on its path
• A serialization layer allowing the conversion of Java objects into HTTP models and streams
• An exception handling layer enabling...

The Java Persistence API (JPA) is the link to the database (MySQL for our quote application we created in chapter 1). Its goal is to enable an application to map the database model to Java objects. The gain is that we can use the database as any object.

For instance, consider the following table, which matches our quote representation in the database:

The preceding table can be converted into the following object in Java, thanks to JPA annotations:

While the tables are flat, mapping them in JPA is pretty straightforward, but the more the model complexity will increase, the more you will realize the two opposed worlds: building a great Java model can lead to an awful database model or the opposite. Why? Because both don't share exactly the same philosophy and can lead to some anti-patterns.

For instance, in our model, we linked our Quote to...

The Java Transaction API (JTA) is the element responsible for providing the API responsible for ensuring the consistency of your data in the widest sense. In our quote manager, it is only applied to the database data but it can be applied to JMS messages, potentially files if you use connectors, and so on.

Without going through the details and protocol, the idea is to ensure, across multiple systems, that either all commits or all rollbacks but not something in between are done ensuring the consistency of the system (which is one common issue mixing NoSQL systems).

To do that, JTA uses what we call a two phases commit protocol:

• Ask all systems to prepare the commit which means the system must verify and ensure it will be able to commit in next phase
• Ask all systems to actually do the commit

A lot of transaction manager or servers are optimized for the...

At several layers, the server provides your application with some resources. In our quote manager we have our datasource injected into the persistence unit through its JNDI name:

<jta-data-source>java:app/jdbc/quote_manager</jta-data-source>

This datasource can also be injected anywhere else in the code:

@Resource(lookup = "java:app/jdbc/quote_manager")
private DataSource datasource;

But the server manages way more resources. Resources are important because they are provided and handled by the server but used from the application. In other words it is a way to control how the application behaves from the outside of it. It enables you to develop without having to care about the configuration and to tune it later or to adapt it depending on the environment you deploy your application to. The next table lists a subset of the most useful JavaEE...

As a reminder, this book is not about Java EE role, so we can't go through all the specifications and detail them all but it is important to understand what Java EE is and what its role is to be able to start working on Java EE performances serenely.

Very often, a small annotation or line of code can hide a lot of logic. The entity manager is a good example: most of the methods are hiding some SQL generation and execution which is not a trivial operation.

With the standardization of CDI in applications, a simple call to a method with a simple complexity can imply to:

• Validate the call (BeanValidation) which can be impacting if the object graph is huge
• Validate the logged in user and its permissions (Security API) which can sometimes contact external systems depending on the configuration and implementations
• An integration of multiple external systems...

In this chapter, you understood that the Java EE server's role is to make the development of the application easier and faster, providing out-of-the-box services and implementations. We browsed through some common examples, detailed their implications in terms of the code, and, therefore, the performance. We saw that the JPA handles statement creation automatically, securely, and correctly and that your code can imply some unoptimized queries if not designed close enough of the data. This is a good example showing that Java EE is here to enable you to build the best application as easily as possible even though you need to take care of some points (often related to design) in order to ensure you meet your performance requirements.

At this point, we have an application (Chapter 1, Money – The Quote Manager Application), we know what it does, and how the Java...