Thanks to Markus Eisele for giving me the opportunity to guest post on his very popular blog. Markus and I go way back to 2010 or so, but I've not yet had the pleasure of guest posting. Markus asked me to cover the Java EE 7 Web Tier. Since EE 7 is a mature release of a very mature
platform, much has already been published about it. Rather than rehash what has come before, I'm going to give my opinion about what I think are the important bits and a very high level overview of each.
If you're interested in learning more about this first-hand, please consider attending my full day training at JavaLand 2016. I'm giving the training with modern finance and HTML5 expert Oliver Szymanski. For details, please visit the javaland website.
First, a bit of historical perspective. Markus asked me to write about the Java EE 7 Web Tier. Let's take a look at that term, "web tier" or "presentation tier" as it is also called. If one is to believe the hype surrounding newer ideas such as microservices, the term itself is starting to sound a bit dated because it implies a three tier architecture, with the other two tiers being "business logic" and
"persistence". Surely three tiers is not micro enough, right? Well, the lines between these tiers are becoming more and more blurred over time as enterprises tinker with the allocation of responsibilities in pursuit of delivering the most business value with their software. In any case, Java EE has always been a well integrated collection of enterprise technologies for the Java platform, evolved using a consensus based open development practice (the Java Community Process or JCP) with material participation from leading stake holders. The "web tier" of this platform is really just the set of technologies that one might find useful when developing the "web tier" of your overall solution. This is a pretty big list:
WebSocket 1.0 JSR-356
JavaServer Faces 2.2 JSR-344
Servlet 3.1 JSR-340
JSON Processing 1.0 JSR-353
REST (JAX-RS) 2.0 JSR 339
Bean Validation 1.1 JSR-349
Contexts and Dependency Injection 1.1 JSR-346
Dependency Injection for Java 1.0 JSR-330
Concurrency Utilities for Java EE 1.0 JSR-236
Expression Language 3.0 JSR-341
For the purposes of this blog entry, let's take a look at the first five: WebSocket, JSF, Servlet, JSON, and JAX-RS. While the second five are surely essentail for a professional web tier, it is beyond the scope of this blog entry to look at them.
WebSocket
JSF and WebSocket are the only two Java EE 7 specs that have a direct connection to the W3C HTML5 specification. In the case of WebSocket, there are actually three different standards bodies in play. WebSocket, the network protocol, is specified by RFC-6455 from the IETF. WebSocket
the JavaScript API is specified as a sub-spec of HTML5 from the W3C. WebSocket the Java API is specified by JCP under JSR-356. In all aspects of WebSocket, the whole point is to provide a message based reliable full-duplex client-server connection.
JSR-356 lets you use WebSocket in both client and server capacities from your Java SE and EE applications.
On the server side, it allows you to expose a WebSocket endpoint such that browsers can connect to it using their existing support for the WebSocket JavaScript API and network protocol. You declare your endpoints to the system either by annotating some POJOS, or by imperatively calling bootstrapping APIs from java code, say from a ServletContextListener. Once the connection is established, the server can send and receieve messages from/to any number of clients that happen
to be connected at the same time. The runtime automatically handles connection setup and tear down.
The WebSocket java client API allows java SE applications to talk to WebSocket endpoints (Java or otherwise) by providing a Java analog to the W3C JavaScript WebSocket API.
Java Server Faces (JSF)
In JSF 2.2 we added many new features but I will only cover three of them here.
HTML5 Friendly Markup enables writing your JSF pages in almost pure HTML (must be well formed), without the need for the XML namespaces that some see as clumsy and difficult to understand. This is possible because the underlying HTML Basic JSF RenderKit (from JSF 1.0) provides all the necessary primitives to adopt mapping conventions from an arbitrary
piece of HTML markup to a corresponding JSF UIComponent. For example, this is a valid JSF form
<form jsf:id="form">
<input jsf:id="name" type="tel" jsf:value="#{complex.name}" />
<progress jsf:id="progress" max="3" value="#{complex.progress}" />
</form>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsf="http://xmlns.jcp.org/jsf">
and more. There are many conveniences provided thanks to the Flows feature being implemented on top of Contexts and Dependency Injection (CDI). Flows can be packaged as jar files and included in your web application, enabling modularization of sub-sections of your web app.
Just as Flows enable modularizing behavior, Resource Library Contracts (RLC) enable modularizing appearance. RLC provides a very flexible skinning system that builds on Facelets and lets you package skins in jar files, effectively allowing modularizing appearance.
Servlet
The most important new feature in Servlet 3.1 is the additional support for non-blocking IO. This builds on top of the major feature of Servlet 3.0 (from Java EE 6): async io. The rapid rise of reactive programming indicates that Java apps can no longer afford to block for IO, ever. The four concerns of reactive programming: responsiveness, elasticity, resiliency, and event basis are founded on this premise. Prior to non-blocking IO in Servlet 3.1, it was very difficult to avoid blocking in Servlet apps.
The basic idea is to allow the Servlet runtime to call your application back when IO can be done safely without blocking. This is accomplished by virtue of new listener interfaces, ReadListener and WriteListener, instances of which can be registered with methods on ServletInputStream and ServletOutputStream.
When you add this feature to the async-io feature added in Servlet 3.0, it is possible to write Servlet based apps that can proudly sport the "We Are Reactive" banner.
JSON
From the outside perspective, the ability to parse and generate JSON in Java is certainly nothing new. Even before Java EE 7, there were many solutions to this basic need. Hewing close to the principle that standards are not for innovation, but to confer special status upon existing ideas, the JSON support in Java EE 7 provides the capability to parse and generate JSON with a simple Java API. Reading can be done in a streaming fashion, with JsonParser, or in a bulk fashion using JsonReader. Writing can be done in a streaming fashion with JsonGenerator. Writing can be done in a bulk style with JsonBuilderFactory and JsonWriter.
JAX-RS
It is hard to overstate the importance of REST to the practice of modern enterprise software development for non-end-user facing software. I'd go so far as to say that gone are the days when people go to the javadoc (or JSDoc or appledoc etc) to learn how to use an API. Nowadays if your
enterprise API is not exposed as a RESTful web service, you probably will not even be considered. JAX-RS is how REST is done in Java. JAX-RS has been a part of Java EE since Java EE 6, but it received the 2.0 treatment in Java EE 7. The big ticket features in 2.0 include:
- Client support
In my opinion, the most useful application of this feature is in using JUnit to do automated testing of RESTful services without having to resort to curl from continuous integration. Of course, you could use it for service-to-service interaction as well. - Seamless integration with JSON
In most cases a simple @Produces("application/json") annotation on your HTTP method endpoint is sufficient to output JSON. Data arriving at your service in JSON format is also automatically made available to you in an easy to consume format from Java. - Asynchronous support (Reactive again)
This feature gives you the ability to hand off the processing required to generate a response to another Thread, allowing the original thread to return immediately so no blocking happens. The async thread is free to respond when it is ready.
Naturally, this only scratches the surface of the Java EE 7 web tier. For more details, a great place to start is the official Java EE 7 launch webinars.
I hope to see you at JavaLand!
Thank you Ed for taking the time to write this post. If you haven't now is the time to to play around with Java EE 7. Here are some resources to get you started with JBoss EAP 7 and WildFly:
