If you are currently using AS7, then you should really check out 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.