7 Reasons to love JBoss AS7
Fast, fast, fast. Blazing fast. No doubt, that’s the main reason to love JBoss AS 7 but Dan Allen explores six more reasons why you should get behind JBoss Application Server 7
The year was 2002. JBoss was busy taking the Java 2 Platform, Enterprise Edition (J2EE) world by storm, boasting over two million downloads and earning a position as the de facto standard for deploying Java-based Web applications.
The secret to the success of JBoss 3 (the version at the time) was that it was borne out of the developer community and thus offered all of the things developers love: it was easy to download, quick to install and simple to run. It was designed around a small microkernel based on Java Management Extension (JMX) that required very little memory. It was relatively easy to use, yet endlessly extensible. It was stable. It had forward-thinking architecture. It was portable and standards-compliant, capable of competing with the big boys. It even won “Best Application Server” at the 2001 JavaWorld’s Editors’ Choice awards. And best of all, it was – and always has been – free.
There’s no denying, though, that in recent years, the JBoss Application Server was stuck in a compliance “no man’s land” between J2EE 1.4 and Java EE 6. Configuring the server meant diving deep into the internals of the bean wiring or selecting from one of several web-based admin console add-ons. It also wasn’t keeping up with modern requirements such as usability, embedded mode, an HTTP API, an interactive command-line and multi-server management, to name a few. The startup time was a minute or more depending on hardware, but was leapfrogged by Servlet containers like Tomcat and Jetty and even its OSS competitor from Sun/Oracle, GlassFish V3.
During the summer of 2010, JBoss Application Server underwent an aggressive transformation to return to its roots. The project was rebooted and set off on a new path towards JBoss Application Server 7. A new beginning.
The team built an entirely new, high performing and manageable core architecture. With some truly amazing engineering effort, they were able to go from a tiny prototype on github to the full blown Java EE 6 Web Profile certified container in a year’s time (and the Full Profile is coming soon in 7.1). Keep in mind they delivered JBoss Application Server 6 in parallel to provide JBoss users interim access to Java EE 6 technology.
With the JBoss Application Server 7 release, JBoss has its mojo back! There’s genuine excitement and optimism about this milestone at Red Hat, a feeling that permeates deep into the community as well, which brings us to the seven reasons why you’ll love JBoss Application Server 7.
1) Lightning fast
Fast, fast, fast. #@*%ing fast! No doubt, that’s the main reason to love JBoss Application Server 7. This release dispels a long-standing misconception that a Java EE application server is inherently slow. (Don’t worry, we checked and “slow” is not a requirement of the specification.)
JBoss Application Server 7 boasts a startup time that’s an order of magnitude (10x) quicker than previous versions, thanks to a highly optimized, parallel boot process. This speedy startup earned it the code name “Lightening.” A modern developer workstation using a tuned JVM can boot the server in as little as one second!* (A three second startup time is an indication that your machine is outdated). Join the competition if you’ve found a way to boot it faster. Not only does this startup time shatter the competition, it even gives Tomcat and Jetty a run for their money. When comparing JBoss Application Server 7 to Servlet containers, consider how much additional, yet essential, functionality you are getting out of the box, at a marginal cost. The benefits don’t end once the server starts. The deployment process has also received a speed boost. Small applications launch almost instantaneously, and medium to large applications can be deployed or restarted in seconds.
You may be wondering, “Why is it so fast?” The short answer is that JBoss Application Server 7 designed around Ahmdahl’s law (effective parallelization of work) as opposed to Moore’s law (a linear increase in clock speed over time). Almost every CPU inside desktops, laptops, and servers is now at least dual core, and the trend is rapidly expanding. It’s time to take advantage of it. Let’s briefly consider how.
Application servers are tasked with a core problem – managing services. Nearly all components in a modern application have some kind of life cycle, meaning there is some point at which the service must be started, and a later point at which it must be stopped. JBoss Application Server 7 starts and de- ploys all services in parallel and keeps non-critical services on ice until needed. The complex problem of managing these life cycles is solved by the new Modular Service Container (MSC). MSC is essentially an advanced concurrent state machine. It analyzes the dependencies between all services on the fly and attempts to start as many as it can at the same time, while still adhering to relationship requirements. This means that not only is startup lightening fast, you can also deploy multiple applications in parallel too. To complement parallel services, JBoss Application Server 7 also has modularity and concurrent classloading, which we’ll cover later.
Processing an individual deployment is also very efficient. A key optimization in JBoss Application Server 7 is indexing annotation information by quickly scanning a subset of the class file data. For even greater efficiency, it allows modules the ability to pregenerate a space efficient index which is designed to be loaded very quickly. Yet another deployment optimization is carefully caching and reusing reflection data, since the JVM is not very efficient at doing so. With these optimizations, you can expect that Application Server 7 will not get slower over time, no matter how many deployment cycles you throw at it.
The highly optimized startup and deployment processes saves unnecessary trips to the water cooler, which keeps you in the zone. It also has a very small memory footprint, which leaves more headroom for your application and avoids slowing down other running programs.
2) Exceptionally lightweight
We like to say that JBoss Application Server 7 lives on a memory diet. The JBoss Application Server 7 team is proudly “militant” about CPU and memory usage during the startup and deployment processes by taking an aggressive approach to memory management primarily to minimize garbage collector pauses. As they say, it’s all about making good choices starting at the design phase.
While garbage collection is a valuable feature of Java, it’s not particularly fast when given a lot of garbage to chew. A simple solution is to give it smaller bites. A couple of ways to accomplish that is only loading JAR files that are needed, using indexed metadata to lookup annotations, class structure (reflection information) and XML data rather than full scans and, finally, shutting down idle services. These optimizations enable JBoss Application Server 7 to run with stock JVM settings on even the smallest devices.
An interesting example from the memory diet is the moratorium on using JAXB (or any other introspection driven binder) to parse configuration that’s only read once. These frameworks often spend more time figuring out how to parse than to do the actual parsing and binding, which itself is time consuming. These calculations add up. Just the XML processing in JBoss Application Server 5 and JBoss Application Server 6 takes longer than the entire JBoss Application Server 7 boot time!
If you want to make the server even more lean beyond what the Java EE 6 Web Profile affords, you can define a custom server profile to prune unneeded capabilities. Profiles are easy to create, since they are defined as an alternative configuration file, as opposed to having to physically remove files and directory. Regardless, we’re confident most developers will be happy with the leanness of the default Web Profile stack.
Being fast and lightweight enhances developer productivity tremendously, until all those gains are thrown out the window trying to remedy a leaky classloader that’s exposing the wrong version of an XML parser. It’s jar hell! Proper modularity keeps the developer out of the weeds, and JBoss Application Server 7 delivers once again.
3) Core Modularity
Mark Reinhold, Chief Architect of the Java Platform Group at Oracle, famously stated at JavaOne 2009: “The classpath is dead.” Experience has taught us that hierarchical classloaders are problematic, often causing failed deployments and quirky behavior. They are the equivalent of a waterfall, where server implementation classes pour into the application’s classpath below. There’s no question the future of Java is a modular one. The time has come to say goodbye to the parent delegation model and find the path to modularity (i.e. sane class-loading). But first-class modularity in the JVM still remains on the horizon (planned for Java 8, a year away at least). Is it possible to build a modular server before then?
One way to achieve modularity is to build the server on top of OSGi, which offers both a module system and service platform. In fact, at least one Java EE implementation has taken this approach, GlassFish 3. In contrast, the Application Server 7 team believed, with minimal effort, they could intro- duce a solid, usable modularity standard that’s not burdened with the overhead and complexity of OSGi. They proved it with JBoss Modules.
A module system provides a way to package up classes and resources into modules, and establish a graph, at runtime, of classloaders such that all the expressed dependencies are satisfied. This organization is a contrast to the traditional method of running an application using the default classpath mechanism, which produces a single application classloader with all the resources in those jars concatenated together in one big blob. In other words, jar hell. Modules can greatly alleviate this problem. When all jars are bundled as modules, a JAR will never see a conflicting version of a dependency class, or pick up resources from other jar inadvertently. Also, a module which is never used will never be loaded which can improve startup time of large applications.
JBoss Modules, the core classloader in JBoss Application Server 7, provides this modular structure. As a result, it offers true application isolation, hiding server implementation classes and only loads the classes your application needs. Every application acts as a module. Modules, packaged as collections of classes, are peers that remain isolated unless explicitly defined as a dependency of another module. Visibility rules have sensible defaults, yet can be customized. The modular classloader keeps applications isolated, so you can use your own XML parser or Hibernate libraries without experiencing jar hell. Not only does JBoss Modules allow Application Server 7 to do classloading right, it’s also a key contributor to its lightning speed. It was designed for a high degree of concurrency. JBoss Modules can load only the classes you need and does so with extremely fast, O(1) resolution. In addition, classes can be loaded concurrently, making use of that multi-core processor once again. By segmenting classes into proper modules, the app server can naturally optimize access patterns, and only look in the spot that truly owns the classes. Also, since the visibility between modules is intentionally limited, searching is cheap.
From an engineering standpoint, we can say that JBoss Application Server 7 is very well designed. This follows a long tradition of JBoss Application Server being developer-friendly. But roles have changed since JBoss 3, as Java EE has been widely adopted by large organizations. That means develop- ers aren’t the only target audience. In addition to solving en- gineering challenges, the JBoss Application Server 7 team has focused on making administration elegant (to cater to managers, the more technically-oriented devops, while still giving plenty of tools to satisfy developers).
4) Elegant administration
Andiamo! That’s the name of the initiative focused on usability of the JBoss Enterprise Middleware portfolio. The first goal of this initiative has been to improve the out-of-the-box experience of JBoss Application Server by making it easier to setup, configure, manage and all-round easier to use. In short, equal attention is given to the experience of administrators, devops and developers. As always, “installing” JBoss Application Server 7 is just a matter of downloading the zip file, extracting it and running the startup command. You can also get it setup from Eclipse via the JBoss Tools plugin, available in the Eclipse Marketplace. The main improvement, though, comes in the configuration.
JBoss Application Server 7 is incredibly easy to configure, more so than any previous version of JBoss Application Server or its competition. Rather than sending you on a wild goose chase to change a setting in the application server, configuration in JBoss Application Server 7 is centralized, simple and user-focused. The primary configuration file is based on a straightforward domain model that you can easily comprehend. No internal wiring is exposed in this file. It also adheres to the DRY principle. Settings are given canonical names, so that values only have to be changed in a single location, at the point where the canonical name is assigned. As an example, you can set main interface, named public, in one location,
<interfaces> <interface name="public"> <inet-address value="127.0.0.1"/> </interface> </interfaces>
then change all the port numbers bound to that interface using a single attribute:
<socket-binding-group name="standard-sockets" default-interface= "public" port-offset="100"> <socket-binding name="http" port="8080"/> <socket-binding name="jndi" port="1099"/> </socket-binding-group>
JBoss Application Server 7 has consistent and powerful management available out of the box, including:
- a polished, user-friendly web console
- a command-line interface (CLI)
- a Java API
- IDE tooling (via JBoss Tools)
- an HTTP API
You’ll appreciate the fact that the web console provides a clear perspective into the server runtime, while the programmatic APIs can be leveraged by tools, scripts and geeks alike.
At the end of the day, all of the administrative interfaces pass through the HTTP API. What makes them especially useful is that changes are persistent, so you can freely switch between them and never have to fiddle with the configuration file directly.
Deployment remains as simple as it’s always been. Archives dropped in the deployment directory are picked up automatically, a feature known as the (hot) deployment scanning. For applications deployed as exploded archives, possibly using a flexible deployment structure, you can edit static resources without redeployment. What’s changed is that Application Server 7 appoints a dedicated directory for application deployments, rather than mixing application deployments with internal service archives, finally!
As a testiment to the usability improvements, Red Hat has made JBoss Application Server 7 available as a Platform-as-a-Service (PaaS) through the OpenShift Express and Flex offerings. OpenShift + JBoss Application Server 7 is the first PaaS based on the Java EE 6 standard (or any version of Java EE for that matter). And OpenShift makes it easy to deploy JBoss Application Server 7 applications to the cloud, and it’s free! The centralized configuration in JBoss Application Server 7 also unifies management. A single configuration file and an alternative startup script can be used to control multiple servers in the new domain mode.
5) Multi-server topology
One of the primary new features of JBoss Application Server 7 is the ability to manage multiple server instances from a single control point (without any special add-ons, such as Jopr). A collection of such servers is referred to as the members of a “domain” with a single Domain Controller process acting as the central management control point. All of the server instances in the domain share a common management policy, with the Domain Controller acting to ensure that each server is configured according to that policy. Domains can span multiple physical (or virtual) machines, with all server instances on a given host under the control of a special Host Controller process. One Host Controller instance is configured to act as the central Domain Controller. The Host Controller on each host interacts with the Domain Controller to control the life cycle of the application server instances running on its host and to assist the Domain Controller in managing them.
When you launch a JBoss Application Server 7 managed domain on a host, your intent is to launch a Host Controller and usually at least one server instance. On one of the hosts the Host Controller should be configured to act as the Domain Controller.
Each “Server” represents an actual application server instance. The server runs in a separate JVM process from the Host Controller. The Host Controller is re- sponsible for launching that process. (In a managed domain the end user cannot directly launch a server process from the command line.) The Host Controller synthesizes the server’s configuration by combining elements from the domain wide configuration (from domain.xml) and the host-specific con- figuration (from host.xml).
<servers> <server name="server-one" group="main-server-group"> <jvm name="default"/> </server> <server name="server-two" group="main-server-group" auto-start="true"> <socket-binding-group ref="standard-sockets" port-offset="150"/> <jvm name="default"> <heap size="64m" max-size="256m"/> </jvm> </server> <server name="server-three" group="other-server-group" auto-start="false"> <socket-binding-group ref="standard-sockets" port-offset="250"/> </server> </servers>
A managed domain is all about coordinated multi-server management–with it JBoss Application Server 7 provides a central point through which users can manage multiple servers, with rich capabilities to keep those servers’ configurations consistent and the ability to roll out configuration changes (including rolling deployments) to the servers in a coordinated fashion. For multi-server production environments, the choice of running a managed domain versus standalone servers comes down to whether you want to use the centralized management capabilities a managed domain provides. The means of management is orthogonal to HA functionality, which is available to both standalone and domain modes.
While Java EE servers have always been good at providing enterprise services, such as a component model, high availability and server management, testing applications that run in this environment has always been a challenge for developers. That is, until now.
6) Testable by design
From the very start, JBoss Application Server 7 has been designed with testability in mind. The secret to that fidelity is Arquillian – a component model for integration tests that execute inside the real runtime environment. Arquillian brings your test to the runtime rather than requiring you to manage the runtime from your test. This removes the plumbing (read: clutter) from your tests and handles deployment and test execution. Consequently, you can write tests for just about any use case your application encounters. We like to call those real tests. And thanks to the speed of JBoss Application Server 7, Arquillian tests run nearly as fast as unit tests. Since Arquillian was designed for testability, you can be sure it has been thoroughly tested itself, with very real and meaningful tests. JBoss Application Server 7 boasts an internal test suite based on Arquillian that achieves even more strict compliance to the portability expectations of our community of users. That means when JBoss Enterprise Application Platform is shipped, the team is not nervous that some blatant bug is going to be discovered in the first 24 hours, or even the first week or month.
Testability is not limited to the development of the server. It gives you another way to slash cycles from your development process; in other words, smarter application development. Using Arquillian for development gives you an extremely fast change, compile, test cycle for any component model. This strategy allows you to take Test Driven Development (TDD) further than ever before, all from the convenience of your IDE or build tool.
Arquillian is one of many first-class JBoss projects on which JBoss Application Server 7 is built.
7) First class components
The past few years have seen the JBoss community grow rapidly in many other directions. You’ll likely recognize this sampling of JBoss Community projects in JBoss Application Server 7 as first-class citizens in the Java middleware space: These projects have come into maturity in their own right. That’s one of the reasons the team was able to create
JBoss Application Server 7 from scratch so quickly. JBoss Application Server 7 brings these best of breed OSS projects together as a compliant platform with an elegant, centralized administration experience. JBoss Application Server 7 is also proving itself beyond the Java EE domain, offering a compliant OSGi runtime and the best Ruby server on the plant, TorqueBox.
The years between JBoss 3 and JBoss Application Server 7 did prove valuable to this effort. Once again, JBoss Application Server would grow out of the developer community, but this time drawing ideas from a much wider field of input, which included users and administrators in addition to developers. The team factored in lessons learned about application server architecture since the development of JBoss Application Server 3 and mixed in modern requirements such as cloud administration and deployment. The real key, though, is attributed to a new philosophy for development. The team recognized that software must adapt, both to tap into the power of the hardware of today and make use of what’s coming down the road. The result is a free, Java EE certified application server which is once again on top…way on top.
Download JBoss Application Server 7 or get started with OpenShift to launch your Java EE applications in a flash!
This article first appeared in Java Tech Journal – September 2011. To read more of that issue and others, register and download the PDF here for free.