Message Services, JAX‐RPC, JAXR, and JAX‐WS. See Figure 2-2 for a complete rundown of the
technologies included in the web proi le.
CORE PRINCIPLES OF JAVA EE
The core principles of Java EE include a number of design paradigms and patterns that are essential
to the way you develop enterprise applications. At the center of Java EE is the design paradigm of
convention over coni guration: a way to simplify the development of enterprise applications without
losing l exibility and obscuring its code's purpose. It is not a new idea and has been a part of other
frameworks including Grails, Ruby on Rails, and Spring Boot for some time—in some cases for
nearly a decade. Thankfully, it has made its way into the heart of Java EE, where it helps others
write beautiful code.
Java EE makes good use of its component model, which includes the components Entities,
JavaBeans, EJBs, Managed Beans, Servlets, SOAP, and RESTful web services. All these components
can be “injectable” dependencies; the container manages, in some way, their life cycle (from
instantiation to destruction)—whether they are bound to a context or not—and their decoupling
from dependent components via dependency injection.
A loosely coupled application allows for extensibility: Old classes can be swapped with new ones
with no requirement to change the dependent class. Dependency injection decouples an object from
its dependencies, whereas interceptors decouple business concerns from technical and cross‐cutting
concerns. Such technological concerns would be performance and logging, and a cross‐cutting
concern would be security.
CONVENTION OVER CONFIGURATION
All class names should start with a capital letter as part of convention. It's not obligatory; the class
will still compile if it starts with a lowercase letter, but starting with a capital letter makes the code
easier to read and maintain. When setting up a project in an IDE, you only need to specify the type
of the project and its name for the most appropriate directory structure to be created; the most
common application programming interfaces (APIs) to be imported; and the default i les such as
web.xml, index.jsp, etc. to be created with appropriate default settings for ease of development. You
do all of this based on agreed convention.
The amount of work you have to do and the decisions you have to make as a developer are
substantially reduced when you rely on convention. You don't specify any coni guration that is
considered conventional; you are required to specify only the unconventional. This has a signii cant
effect. With just a few annotations on a POJO, you can do away with a lot of your ugly XML
deployment descriptors and application coni guration i les. As you have seen in Listing 2‐1, you need
to apply just three annotations to make a POJO into a singleton bean that will be instantiated and
initialized at start‐up and then managed by the container.
NOTE Convention over coni guration is also known as coding by convention.