The next generation application server
The major innovations in the AS 5.0 converge into the following four areas:
- The introduction of the new Microcontainer kernel
- The new library configuration
- The addition of new server configurations
- The introduction of the virtual file system and the
deployersfolder
Let's see them all in detail.
From JMX to the Microcontainer
Change is the law of life. And those who look only to the past or present are certain to miss the future.—J.F.Kennedy.
Before the 5.0 release, the backbone of the JBoss AS was the JMX API, which provided a modular way to integrate components, containers, and plugins. In order to provide a new service, you had to declare the service as an MBean service, provide some configuration, and then load it into JBoss. The JMX components might subsequently be administered using the JMX API or some utilities such as twiddle or a web application named jmx-console.
This approach was an important milestone in the JBoss project; however, it suffers from a major drawback: actually services deployed to the JMX kernel are tightly coupled with the application server and can hardly be tested outside of the container.
The answer to this issue is in the JBoss Microcontainer kernel that allows the services to be created using Plain Old Java Objects (POJOs), which can be deployed into a Java Platform, Standard Edition (Java SE) runtime environment in a controlled manner to create a customized environment for your applications. These services, as well as MBean services, are fully managed to ensure that new services cannot be deployed until the services they depend on have first been deployed. Also, undeploying a service causes all dependent services to be undeployed first in order to maintain the integrity of the system.
One great advantage of the Microcontainer approach is that you can build every Java service on top of it (and of course remove the unwanted services). These services, being POJO, can be moved onto any other environment such as Tomcat or Glassfish without hassle.
In common with other lightweight containers, JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML, depending on where the information is best located. Finally, unit testing is made extremely simple, thanks to a helper class that extends JUnit to set up the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.
The release 5.0 of the application server introduces some important changes in the location of the client and server libraries. Starting from the client libraries, the jbossall-client.jar library that used to bundle the core JBoss client libraries is now an empty archive that references the client libraries through the Class-Path entry in the manifest file. This allows swapping included libraries (for example, jboss-javaee.jar) without having to repackage jbossall-client.jar.
The downside of this new configuration is that most IDEs don't scan the libraries indicated in the manifest entry, so you have to manually insert all the JARs needed.
Tip
Which are the libraries used by my project?
This issue has been a headache for most developers, and it is generally solved empirically by adding the required libraries to your project at every ClassNotFoundException. If you want to save time and health, then consider downloading the JBoss Tattletale tool(http://www.jboss.org/tattletale), which is a simple web application that identifies dependencies of any application along with many other features.
However, the most important change to the application server structure is the introduction of a common repository for the server configuration. This repository is located in the common/lib folder of your JBOSS_HOME directory.
Copying a library into the common/lib folder will make it available to all server configurations (except for the "minimal" configuration). This prevents your JBoss AS installation from inflating your hard disk with duplicate libraries for each server configuration.
The earlier location of libraries, server/xxx/lib, can still be used, but it is advised to use it only for libraries that are specific for a server configuration.
Moving to the JBOSS_HOME/lib folder, which hosts the bootstrap classes, we notice some changes here. This directory contains the classes needed to start the new kernel of JBoss with the introduction of the Microcontainer. As you can see from the libraries in this folder, JBoss AS 5 relies heavily on the AOP model. Along with the new kernel, the common libraries used by the kernel have also swapped from jboss-common.jar to jboss-common-core.jar.
The following screenshot summarizes the new library configuration:
JBoss AS 5 server configurations
JBoss AS 5 contains five different out of the box server configurations: minimal, default, all, standard, and web. Out of these, the standard and web configurations have been introduced with the new release of the application server, so we will first have a look at them and then we will briefly recap the preexisting server configurations.
The "standard" configuration
The standard folder hosts the configuration that has been tested for Java EE 5.0 compliance. The major differences with the other server configurations is that call by value and deployment isolation are enabled by default, along with support for RMI-IIOP and jUDDI.
Note
If you feel confused by all these weird words, here's a quick drill:
Call by value: It is a requirement of the EJB specification that parameters passed during the method call be passed by value, so that the EJB receives a copy of any object parameters (and the caller receives a copy of the return object, if applicable).
The use of call by value, however, is very inefficient. With call by value, each method invocation is marshalled—the parameters are turned into ObjectStream. Once the invocation reaches the EJB container, the result is unmarshalled and the return value is turned back into ObjectStream.
In terms of percentage, it typically means that method invocations take 10 times more cpu than call by reference.
RMI-IIOP: This is a protocol developed by Sun and IBM to deliver CORBA distributed computing to the Java platform. The middleware that promotes communication between systems by transforming data structures from and to byte sequences is called an object request broker (ORB). JBoss AS ships with a free implementation of CORBA standard named JacORB.
jUDDI: This is an XML-based registry for publishing and discovering services or software applications over the Internet. A web application is built-in with the standard configuration for testing, publishing, and inquiring of Web Services. You can have a look at it by pointing your browser to: http://localhost:8080/juddi.
The changes related to RMI-IIOP and jUDDI support are reflected in the following files:
conf/jndi.propertiesIn the default server configuration this file references the
NamingContextFactory, which is a factory implementation for connecting to the JNDI service. When using Sun's CORBA services it is necessary to set the global context factory toorg.jboss.iiop.naming.ORBInitialContextFactory, which sets the ORB to JBoss's ORB.conf/jacorb.propertiesThis file contains the JacORB configuration file.
lib/jacorb.jarThese are the libraries needed for JacORB applications.
deploy/iiop-service.xmlThis service provides IIOP invocation support.
lib/avalon-framework.jarThese Avalon libraries are a required dependency, so they are added in the
libfolder.
The web configuration is a new experimental lightweight configuration created around JBoss Web that will follow the developments of the Java EE 6 web profile. Besides being a servlet/JSP container (and this is the most relevant difference with a pure Tomcat Web Server), it provides support for JPA and JTA/JCA.
Therefore, with this configuration you are now able to deploy your persistence layer and access it from the web container.
The major limitation of this configuration is that its applications can be accessed only through the HTTP channel. Bear in mind that this configuration is not Java EE certified and will most likely change in the following releases.
The other configurations were introduced in the early releases of JBoss, so they should be known to majority of developers. Let's again take a glimpse at the server directory:
As shown in the screenshot, the pre-existing server configurations are as follows:
- minimal: This is the minimal configuration—the bare minimum services required to start JBoss. It starts the logging service, a JNDI server, and a URL deployment scanner to find new deployments. This is what you would use if you want to use JBoss to start your own services without any other Java EE technologies. This is just the bare server. There is no web container, no EJB or JMS support. This is not a Java EE-compatible configuration.
- default: This is the basic JBoss configuration containing a default set of services. It has the most frequently used services required to deploy a Java EE application. It does not include the Java API for XML Registries (JAXR) service, the Internet Inter-ORB Protocol (IIOP) service, or any of the clustering services.
- all: This configuration is a full Java EE server profile with Enterprise extensions, such as clustering and RMI-IIOP.