JBoss Application Server
In 1999, Marc Fleury started a small open source project called JBoss, which provide an implementation of the Enterprise Java Bean (EJB) portion of the J2EE specification. In 2002 JBoss AS 3 was release and become a fully fledged J2EE application server. In 2004 JBoss AS 4 was released and production support was offered, it was now more than a application server, in 2006 Red Hat brought JBoss and JBoss AS 5 was released which offered JBoss portal.
JBoss is a Java Enterprise Edition 5 (Java EE 5) compliant application server, it implements the full JEE stack of services
It also provides advanced features such as clustering, JMX, web services and Internet Inter-ORB Protocol (IIOP) integration.
Because JBoss code is licensed under the GNU lesser General Public License (LGPL) you can use it freely at no cost in a commercial environment, also Red Hat offer full support but at a cost.
A Java application server standardizes the application development architecture, it does this by defining server component models, standards that developers can use to develop components. These components can be deployed into an application server using a standard deployment model. When the components are running in the server, the server provides a set of services (see above for some of the services available) that are made available to the components. An application server is a place were your Java code can run, normally you use a main() method in your Java code to start the application, with an application server you write your code using a standard component model, package it into a standard archive format and then deploy it into the application server, which starts your application and all the services that your application needs to access, this is all transparent to the end user. You have to provide metadata which is normally in the form of annotations or Extensible Markup language (XML) to hook the services into your components, this can drastically reduce the amount of code and configuration that you would otherwise need.
JBoss AS is the core product in Red Hat's suite of Java middleware products that they call JBoss Enterprise Middleware Suite (JEMS), below is a list of these products, some of which I will be covering
| Product | Description |
| JBoss MicroContainer | The configuration framework used to wire together JBoss Services. |
| Hibernate | An object-relational mapping (ORM) tool used to implement the persistence portion of the EJB3 specification |
| JBoss SX | A role-based security service which is used by many JBoss services |
| JBoss Web Server | A fast native web server that also enables you to use servlets, JSP and JavaServer Faces (JSF) |
| EJB Server | An implementation of the EJB3 specification |
| JBoss Messaging | Compliant Java Messaging Service (JMS) messaging server. |
| JBoss Portal | Compliant portal server |
| JBoss Clustering | A clustering framework |
| JBoss cache | A transactional, distributed, in-memory cache used by many JBoss services |
| JBoss Transactions | A distributed transaction technology supporting JEE, COBRA, etc |
| JBoss Rules | Compliant rules engine (formally Drools) |
| jBPM | A fully-featured business process management engine |
| Red Hat Developer Studio | A set of plug-ins to extend Eclipse development tool |
| Seam | An application integration framework that can reduce boilerplate code used to write many web applications, this framework is the underpinning of the proposed WebBeans Java specification. |
| JBoss AOP | An aspect-oriented-programming framework |
At the heart of JBoss is the microcontainer, which is the foundation architecture into which you can plug only the services that your application needs, thus you can run as many or as few services that you want, which can reduce the footprint thus consuming less memory and resources, it also can help in reducing security risks.
JBoss uses a different approach in that each service is hot-deployed as a component running on top of a very compact core called JBoss Server Spine. The JBoss server spine itself is based on JMX specification, making any deployment component automatically manageable in a standard fashion. In the JMX terminology, a service deployed in JBoss is called a managed bean (MBean), I have already discussed JMX in my Tomcat section, which gives you an idea what JMX tries to achieve.
The JBoss microcontainer is a dependency injection framework (similar to Spring), with it you can do the following tasks
The microcontainer is evolving as it is trying to have all services directly running from the microcontainer, currently there are a number of services that use the JMX kernel (JNDI, JMS, etc). Eventually JBoss will be entirely microcontainer based and have a architecture similar to below
Current Architecture |
Future Architecture |
 |
 |
You can use bean configuration files in the server/xxx/conf directory to configure the microcontainer, most bean configuration files follow the pattern *-jboss-beans.xml, but the bean primary configuration files that are found in server/xxx/conf/ do not follow this pattern. The primary bean configuration file for the application server is server/xxx/conf/bootstrap.xml, this file includes other bean configuration files, which in turn define a series of POJO's or JavaBeans that provide the following
I have already have documented JMX in my Tomcat section, but I will touch on it again here. The JMX specification defined by the Java Specification Request 3 (JSR3) concerns managed JavaBeans or MBeans. To create a MBean all you have to do is implement the interface and it must be named XxxMBean and the class named Xxx, once an instance is created it can be registered by name with the MBean server. Once registered with the server any JMX client can access the MBean by name via the MBean server. The JMX client can request information about the MBean and can make requests to the MBean only via the server, but the client never directly accesses the MBean.
In the application server, the service deployer instantiates the MBeans based on the contents of the conf/jboss-service.xml file that accompanies the service or the various *-service.xml files that appear in the deploy directory. MBeans get registered by name, this name is in multiple parts which contain the following
When expressed as a string, the name starts with the domain, followed by a colon, followed by the key properties separated by commas
| MBean name | jboss.jca:service=ManagedConnectionPool,name=DefaultDS jboss.jca:name=DefaultDS,service=ManagedConnectionPool Note: the ordering of the key property is irrelevant |
The JMX primary descriptor file used to declare MBeans to the JMX kernel is server/xxx/conf/jboss-service.xml. This file declares a number if MBeans, which include the following
There is a tool called the "JMX Console", which is a web based application that can read, display and update MBeans.
To access the tool you point a browser at the application ( I am presuming that JBoss is installed on the localhost)
| JMX Console | http://localhost:8080/jmx-console |
The first page you get is the agent view, this lists all the registered MBeans, which are grouped by namespace. Each MBean is listed as a link when clicked on displays details about the MBean. Here you can change properties values, run certain operations (you can even supply values) which are supported by the MBean. However this is a powerful tool and there are number of MBeans which can affect the services in JBoss i.e shutdown the JBoss server, so becareful!.
One note to make is that any changes made by using the JMX console are not persistent, this means when JBoss is restarted all changes are lost, MBeans do not change the XML files.
For the commandline fans there is a tool that has the same power as JMX console by for the CLI, this tool is called "twiddle" and can be found in the bin directory, one of the benefits of twiddle is that you can use it in a script, but again the changes are not permanent.
| Twiddle | bin/twiddle --help-commands |
There are many MBeans within JBoss, I have listed some of the interesting ones below (the namespace is in bold)