The buzz

“If you are currently using AS7, then you should really check out WildFly”

BernhardLwenstein
wildfly

WildFly project lead Jason Greene outlines the best reasons for switching to the server, what he likes about Java 8, and the road ahead for the server.

 

In this interview, WildFly project lead Jason
Greene takes us under the hood of the release taking former-Oracle
server fans by storm.

Löwenstein: The final version
of WildFly 8 was been released a few days ago (at time of going to
press) . Would you give us an overview of the latest features and
changes to the software?

Greene: Certainly. This is a
large release with many changes. The most significant feature is
that WildFly 8 is Java EE 7 certified, meeting both the full and
web profiles. Java EE 7 improves developer productivity and
provides a rich set of APIs and capabilities that make it easier
than ever to address the ever growing technical demands of
applications.

Another major change is that WildFly 8 includes
a new lightweight, highly performant and scalable web server called
Undertow. Undertow supports both non-blocking and blocking styles
of web development, as well as the latest standards, most notably
Web Sockets. It is also a highly customizable and flexible server
with the ability to handle everything from dynamic routing to
custom protocols. In addition, it can function as an efficient
reverse proxy or file server, removing the need to use a
traditional native web server in your environment.

WildFly 8 has also dramatically reduced the
number of ports it requires by multiplexing its various protocols
over HTTP using HTTP Upgrade. This is a major benefit to cloud
providers where ports are limited resources, due to the number of
server instances they run. Out of the box WildFly uses only two
HTTP ports, one for management, and one for applications. Having
two makes it easy to have separate firewall polices and/or
interface bindings, which is typically desired.

In addition, WildFly 8 also includes operational
improvements. The management API and administration console now
support role-based access control (RBAC), as well as auditing via a
new audit log facility. These capabilities enable an organization
to segment administrative and operational responsibilities across
different users and teams. Another noteworthy improvement in this
area is the infrastructure to support patching. Future releases of
WildFly will provide an additional patch option.

WildFly 8 fulfills the Java EE 7
specification, and passes both the full and web profiles of the
Java EE 7 TCK. What are the major improvements in this Java
edition?

There are a number of major updates to Java EE
7. One of the biggest improvements is support for modern web
application development. The addition of Web Sockets allows you to
develop custom full-duplex protocols, which are essential for
real-time applications. The new ability to create Non-Blocking
Servlets in Servlet 3.1 allows for applications to minimize
consumption of server resources. Finally, REST improvements in
JAX-RS 2 and the introduction of JSON-P, make it easier than ever
to build a rich data tier over the web.

Another major improvement is the introduction of
a concurrency library to Java EE. It allows you to execute tasks in
custom thread pools while still taking advantage of Java EE
features like security propagation, naming, and transactional
integration. This is very important in this age where CPUs are
primarily multi-core.

In addition, Java EE 7 now provides APIs for
batch processing. These APIs build on decades of experience in
batch processing. There are familiar concepts such as the ability
to define units of work in chunks, abstractions for reading and
writing data, and a specification language that allow tailoring the
job behavior to best fit the underlying execution
environment.

Also, a number of productivity improvements went
into the various API additions. JMS 2.0 eliminates a great deal of
boiler plate, now requiring a fraction of the code from before. JCA
resource adapters support a rich annotation model. Default data
sources are now provided under standard names by every Java EE
container. Finally, dependency injection using CDI has now been
improved and is enabled by default.

I am very satisfied with JBoss AS7 or EAP6.
Why should I upgrade to WildFly 8?

Well, first let me start off with an explanation
of our two different offerings, for those that aren’t familiar with
our model. WildFly, which was previously called “JBoss AS” is our
community project offering, and it provides a rapid lifecycle that
brings the latest cutting edge features. However, maintenance and
updates are only provided on the latest community major. EAP on the
other hand is our commercial offering that is a conservative fork
of the community project. It’s focus is on strict compatibility,
easy to consume updates, and 7-10 year maintenance life-cycles for
each major version.

If you are currently using AS7, then you should
really check out WildFly. It has many more features beyond what I
mentioned earlier, and also a very large number of bug fixes. If
you are an EAP 6 user, then you are most likely interested in a
move to EAP 6.2, which back-ported the operational features like
RBAC from WildFly 8. Although, looking at WildFly is always a great
way to get a feeling for some of the capabilities that will
eventually be coming to EAP.

Some statistical questions about the project
for you: How many developers worked on the WildFly 8 project? How
many man-years went into it?

It’s always difficult to produce statistics like
this because WildFly builds on a number of third-party open source
projects, as well as standalone components we have developed.
Undertow for example is an independent project, and so isn’t
counted. However, if we just look at the primary core source tree,
we have had over 150 contributors submit changes. That doesn’t
equate though to full time developers. We often get contributions
from those that make the occasional fix, perhaps something they ran
into.

As to the amount of work, according to git on
just the core codebase, since 7.1.1 we had: 14.509 commits, 1.320
files changed, 1.207.859 insertions (+), and 385.449 deletions
(-).

Which process model do you use at Red Hat for
the realization of such projects?

We have a pretty unique process model at Red
Hat. Since all of our work is open source, traditional process
methodologies don’t easily map. The closest resemblance would be
one of the iterative models like Agile.

The application server is a fundamental
component of each Platform-as-a-Service. When will WildFly 8 be
integrated in Red Hat’s OpenShift?

We just released a cartridge for OpenShift, so
you can use it now.

What enhancements are planned for the next
sub-release of WildFly?

Our current focus is on gathering feedback from
our users on 8, and fixing any issues they run into. We want to
make sure everyone has a positive experience, and gets the most out
of the new capabilities. After that we will start discussions with
the community on what the big goals for WildFly 9 will
be.

The role of the application server has changed
over years – from using one large, shared instance for all
applications to using one small, separate instance for each
application. What is the future of application
servers?

It certainly seems the direction is that the
separation between the application server and the application is
getting thinner over time. I expect, with cloud usage growing in
popularity, that application servers are going to become more
intelligent, and even more tailored to the application.

Do you agree with me that next editions of
Java Enterprise must/will standardize different topics regarding
clustering so that Java EE conform application servers will indeed
become distributed application platforms without
vendor-locking?

There is definitely a desire on the Java EE
Expert Group to standardize aspects that make developing on a Java
EE Platform-as-a-Service more portable. That does tend to include
certain aspects that were traditionally considered vender-specific
operational concerns. There has also been some movement in
standardizing aspects of clustering, such as JSR-107, and JSR-350.
So I do agree that the platforms will become more portable, but I
think there will always be vender-specific extensions and APIs that
are popular.

As a member of the Java EE expert group, can
you tell us what important features and changes are planned for
Java EE 8, and how will developers benefit from them?

A survey was recently sent out by the spec lead to ask the
broader community what challenges should be tackled in EE 8. Some
of the candidates included cloud-oriented features, application
configuration, security improvements, NoSQL, JavaScript support,
mobile features, REST-based monitoring, logging standardization,
application tracing, and more profiles. In addition to some of
these possibilities, I expect continued progress on developer
productivity and ease of use.

Author

BernhardLwenstein

All Posts by BernhardLwenstein

Comments
comments powered by Disqus