Java EE (formerly called J2EE) is an umbrella specification embracing a standard set of technologies for server-side Java development. Java EE technologies include Java Servlet, JavaServer Pages (JSPs), JavaServer Faces (JSFs), Enterprise JavaBeans (EJB), Contexts and Dependency Injection (CDI), Java Messaging Service (JMS), Java Persistence API (JPA), Java API for XML Web Services (JAX-WS), and Java API for RESTful Web Services (JAX-RS), among others. The newest version of Java EE extends the range of available technologies even further by providing support for Batch Applications, Concurrency Utilities, JSON Processing (JSON-P) and WebSocket. Several commercial and open source application servers exist, which allow developers to run applications compliant with Java EE; WildFly (formerly known as JBoss AS) is the leading open source solution adopted by developers and, although this is difficult to measure in exact terms, it is likely to be the most widely used application server in the market.
As with all application servers compliant with Java EE, WildFly ships with all the required libraries to allow us to develop and deploy Java applications that are built on the Java EE platform.
WildFly and previous JBoss Application Servers were freely available for the community in the form of downloadable binary packages (for major releases) or buildable source code (for bug fixing releases). These versions are called community releases and are free to use for development and production.
JBoss also releases more stable and hardened versions of software of the community builds, which are called Enterprise Application Platform (EAP), a commercial product with support service from Red Hat. Red Hat calls this kind of relationship between projects as upstream/downstream. The community builds are the source of changes and innovations for the downstream, the code is downstream. The commercial version numeration differed from the community line, but it was an extended variant of the community releases (for example, EAP 6.1.0 was built on JBoss 7.2.0, which was available only on GitHub in the form of buildable source code; the same goes for EAP 6.2.0 and JBoss 7.3.0). EAP builds have a more complex licensing system; the usage terms depend on the maturity of the build and are as follows:
EAP Alpha is free for the developers and production use, as they are an equivalent of the standard community version with optional fixes included. The corresponding community binaries may not be available for download, as they would be similar to the EAP Alpha version.
EAP Beta is available to developers for free (after registration to a subscription program), but cannot be used in production.
EAP Final is also available to developers for free, but additionally, new security patches are available only in the paid subscription.
The distribution model proposed by JBoss allows the developers to work for free on the same version as the one used in production. This is a huge benefit, especially since the competitive solution from Oracle (Glassfish: the reference implementation of a Java EE compliant server) no longer has a version with commercial support.
Java EE 7 includes several improvements and additions to the existing version. The new version is focused on three themes: developer productivity, HTML5, and providing new features required by enterprise applications. The following sections list the major improvements to the specifications that are of interest to enterprise application developers.
If you are starting your adventure with Java EE, feel free to skip this section. The technologies described in the following sections will be covered in future chapters in more detail.
Java EE 7 includes a new version of the JSF specification, which is not so revolutionary as 2.0, but still provides some appealing additions for developers. The key features delivered by JSF 2.2 are as follows:
The HTML5 markup is now supported by the usage of pass-through elements and attributes. Earlier, custom attributes would have to be supported by an extended renderer for every component. The new constructs allow the developer to pass additional HTML attributes to the markup generated by JSF components.
The flow scope has been introduced with
@FlowScoped, which makes the creation of wizards (dialogs with multiple steps) easier.The Ajax-based file upload is now supported out of the box.
Also, stateless views have been presented as a way to improve performance.
Compared to EJB 3.1, the Version 3.2 is a minor update of the existing version. It concentrates mainly on marking some older features as obsolete (they are now optional, which means that not every Java EE 7-compliant application server will support them). The optional features are connected with persistence to web services based on EJB 2.1 and JAX-RPC. The main enhancements provided by the new specification are as follows:
Life cycle methods for stateful session beans can now be transactional.
The Timer Service API, now allows you to access all active timers in the current EJB module.
A new container provided role (
**) has been introduced. It can be used to indicate any authenticated user (without taking his or her actual roles into account).Passivation of stateful session beans can now be disabled.
Transactional parts of the EJB specification have been extracted and reused in other parts of the Java EE platform (the transaction support has been placed in the JTA 1.2 specification). For instance, the transactional behavior can now be used in CDI beans, thanks to the introduction of the @Transactional annotation.
JPA was introduced as a standard part of Java EE in Version 5 of the specification. JPA was intended to replace entity beans as the default object-relational mapping framework for Java EE. JPA adopted ideas from third-party object-relational frameworks, such as Hibernate and JDO, and made them a part of the standard version.
JPA 2.1 is an improvement over JPA 2.0 as it provides several facilities for developers, which are as follows:
It provides a standardized schema generation mechanism, thanks to an extended set of annotations and
persistence.xmlpropertiesIt adds support for type conversion, by the introduction of the
@ConverterannotationStored procedures are now supported by the Entity Manager API, so that the use of the SQL query mechanism for them is no longer required
Criteria API has been extended by bulk updates and deletes
Injection is possible into entity listener classes along with the usage of life cycle callback methods
Named queries can now be created during runtime
The JPA Query Language (JPQL) has been extended with new database functions
Additionally, Java EE 7-compliant containers must now support preconfigured data sources (along with other resources), which can be instantly used by JPA entities.
WildFly uses Hibernate as its JPA provider and is shipped with a ready-to-use H2 in-memory database. The default data source points to the H2 instance hosted inside of the application server.
Version 1.1 of Contexts and Dependency Injection (CDI) provides improvements for the issues identified in CDI after its introduction in Java EE 6. The process of simplifying the programming model started in Version 1.0 and is now being continued. The areas covered by the update are as follows:
CDI is now enabled by default (without the need to add the
bean.xmlfile to the deployment), with the possibility to specify the desired component scanning mode.More fine-grained control over the bean discovery mechanism is now available for the developer, thanks to the use of the
@Vetoedannotation and class or packages filters inbeans.xml. Interceptors, decorators, and alternatives can now be globally enabled for the whole application using the@Priorityannotation, instead of enabling every module.Event metadata can now be examined when a CDI event is handled.
Interceptors have been enhanced with the possibility to be executed around constructor invocation.
Finally, the new version contains a significant number of enhancements for the development of portable extensions.
Weld is the CDI implementation internally used in WildFly.
The new version of the Java Servlet API has a clear focus on new features. The most important of them is the HTTP upgrade mechanism, which allows the client and server to start a conversation in HTTP 1.1, and negotiate another protocol for subsequent requests. This feature was used to implement the WebSockets mechanism in Java EE 7. Other features of the new version of specification are as follows:
Non-blocking I/O API for Servlets has been provided to improve scalability of web applications
Multiple security improvements have been introduced; the most notable of them is the possibility to set the default security semantics for all HTTP methods
In Java EE 7, the JAX-RS specification has been enriched with some long-awaited features. The version has changed from 1.1 to 2.0 because of the major impact of the improvements that came with the new specification. The most important features are listed as follows:
The client API is now part of the specification, so the usage of third-party libraries is no longer needed. The implementation of the specification is required to provide a REST client that conforms to the common API.
Asynchronous requests are now supported so that the client does not have to passively wait for the completion of the task.
Filters and handlers have been introduced as a common mechanism to provide extension points for the developer. They can be used for cross-cutting concerns, such as auditing and security.
Bean Validation has been integrated into JAX-RS, making constraint annotations usable for request parameters.
WildFly comes bundled with RESTEasy, an implementation of JAX-RS 2.0.
The JSR 343 is the first update for the JMS specification in over a decade. Once more, the main theme of the update is the simplification of the API. The new API dramatically decreases the amount of boilerplate code that has to be written by the programmer while still maintaining backwards compatibility. Other new features are listed as follows:
Asynchronous message sending is now supported, so the application does not have to be blocked until an acknowledgment from the server is received
Messages can now be sent with a scheduled delay for the delivery
HornetQ is the JMS provider used and developed by JBoss. It is possible to use it outside of WildFly as a standalone message broker.
Concurrency utilities is a new feature pack to use multithreading in Java EE application components. The new specification provides ManagedExecutorService (a container-aware version of ExecutorService known from Java SE), which can be used to delegate the execution of tasks to a separate thread. These managed tasks could use most of the features that are available for application components (such as EJBs or Servlets). It is also possible to schedule cyclic or delayed tasks using new ManagedScheduledExecutorService. These new additions to the platform are filling a functional gap for Java EE, which was very hard to overcome within its architecture earlier on.
Batch jobs were another area of enterprise application development, which was not covered by earlier versions of Java EE. The new batch processing framework is used to provide a common solution to run tasks that are executed without user interaction. Java EE provides the developer with the following options:
Batch runtime for the execution of jobs
A job description language (based on XML)
The Java API for the implementation of the business logic for the batch tasks
jBeret, which is the batching framework used in WildFly
Java EE 7 now comes with out-of-the-box JSON processing, so the developer is no longer forced to use external libraries for this task. The new API allows JSON processing to use two approaches: object model (DOM based) and streaming (event-based).
To fully support the development of applications based on HTML5, Java EE 7 requires a standardized technology for two-way communication between the server and the user's browser. The WebSocket API allows the developer to define server-side endpoints, which will maintain a TCP connection for every client that will connect to them (using, for instance, a JavaScript API). Before the new specification, developers had to use vendor-specific libraries and not portable solutions to achieve the same goal.