“Tech Preview”: Undertow

The Internet of Things is a modern term of art for a relatively old concept (in technology time). The Internet of Things (IoT) is a way of virtualizing physical objects -- of making those physical objects under the control of software-based systems.

An IoT environment is predicated on a strong communication design. The various objects need a way to communicate with an end user and (depending on the object and the architecture) with a central system or with other objects. There are different potential mechanisms for that communication, but a very simple and well-vetted method is an embeddable web server.

Like the name implies, this is a web (HTTP) server that is embedded within an application, that the application can use to interact both with external clients (as a typical web service) and with the device itself.

Wilfred Nilson, writing for embedded, the systems development site, had a really great description of an embeddable web server: it is “webbing traditional design.”

And that leads us to JBoss Undertow. Undertow became the new web server for the Wiildfly project starting in version 8. Previous versions of Wildfly and JBoss used an offshoot of Tomcat, JBoss Web Server, as its  web server subsystems. But Tomcat is designed as a standalone server, with a fairly static architecture and high resource requirements. With Wildfly continuing in a more modular, use-only-what-you-need design, having a rigid and potentially over-designed web server wouldn’t work. Enter Undertow.

* Undertow embedded as a subsystem in Red Hat JBoss Enterprise Application Platform

Each possible action of a web server -- session handling, authentication, error pages, persistent connections, servlet management -- can be broken down into a subservice or component called a handler. These handlers are then chained together to create the precise workflow that is required for a given use case. Because Undertow is Java-based, it can also use servlets, and any servlets can be mixed with any handlers.

* Simple handler flow. Inspired by a diagram by Francesco Marchioni, Java Code Geeks, 2014.

What that means in a functional sense is that Undertow only requires the handlers that will actually be used. This potentially streamlines the server pretty significantly and can improve its ratio of performance to resource usage. (The Undertow package itself is less than 1 MB, and even at runtime, its heap size is around 4 MB. For comparison, a typical heap size for Tomcat  is anywhere from 64 to 128 MB.)

Undertow has more to it than just architectural changes. There are several other features that feed into its nimble nature:

• It supports HTTP upgrade -- something that allows it to switch between different HTTP protocols (including HTTP2) and even other Java-friendly protocols like EJBs over HTTP. This reduces the number of ports that you need to have available -- which is well-suited for cloud applications where ports may be limited.
• It can work as a reverse proxy for a cluster of web servers. As other Undertow servers are added, a cluster topology can be created and updated dynamically. WIthout requiring manual intervention or supporting servers like Apache.
• It supports both blocking and nonblocking IO. Blocking means that one request has to be completed before the server will begin to process the next request; nonblocking means that the server will process multiple, simultaneous request as long as they aren’t dependent on each other.
• Undertow introduces a buffer cache. What that means is that it stores data in RAM rather than writing it to physical storage; that means that the information is usually faster to retrieve.

That light weight has a purpose. As the embedded article noted, traditional actions are being performed in the web; traditional designs are being revised to make them work natively in web environments. That’s at the heart of a use case like an IoT environment, a web server which is light enough to be embedded within the same application it controls.