A Quick Look at JBoss Internals

A Quick Look at JBoss Internals

Since Version 3.0, JBoss has been built around a few very powerful concepts that allow users to customize and fine-tune their servers for specific needs, not limited to Java EE. This flexibility allows JBoss to be used in vastly different environments, ranging from embedded systems to very large server clusters. The next few sections comment briefly on some of these concepts.

Microkernel Architecture

JBoss is based on a microkernel design into which components can be plugged at runtime to extend its behavior.

This design fits particularly well with the Java EE platform, which is essentially a service-based platform. The platform contains services for persistence, transactions, security, naming, messaging, logging, and so on.

Other application servers are generally built as monolithic applications containing all services of the Java EE platform at all times. JBoss takes a radically different approach: each service is hot-deployed as a component running on top of a very compact core, called the JBoss Server Spine (see Figure W-4). Furthermore, users are encouraged to implement their own services to run on top of JBoss.

Consequently, the JBoss application server is not limited to Java EE applications and in fact, is frequently used to build any kind of application requiring a strong and reliable base. For this reason, the JBoss core is also known as the WebOS.

Figure W-4. JBoss Server Spine with some hot-deployed services

The JBoss Server Spine itself is based on Sun's Java Management eXtensions (JMX) specification, making any deployed component automatically manageable in a standard fashion. In the JMX terminology, a service deployed in JBoss is called a managed bean (MBean).

You can find more information about the JMX specification at the Sun web site, http://java.sun.com/products/JavaManagement.

Hot Deployment

Since Release 2.0, JBoss has been famous for being the first Java EE-based application server to support hot deployment and redeployment of applications (EJB-JAR, WAR, and EAR), while many application servers required a restart to update an application.

Thanks to its microkernel architecture and revolutionary Java class loader, JBoss 3.0 and later releases push this logic further. Not only can they hot-deploy and -redeploy applications, but they also can hot-(re)deploy any service and keep track of dependencies between services. These features make JBoss usable in very demanding environments, such as telecommunications systems.

Net Boot

JBoss is able to boot itself and your applications from any network location just by pointing the JBoss Server Spine to a simple URL. This allows you to manage the entire configuration of a cluster of JBoss nodes from one central web server. This impressive flexibility makes deployment of new servers very easy (see Figure W-5).

Figure W-5. A JBoss instance bootstrapping from three distinct netboot servers

JBoss' bootstrap code is approximately 50K, which makes it suitable for many embedded systems.

Detached Invokers

JBoss completely detaches the protocol handlers receiving invocations from the target service that eventually serves the requests. Consequently, when a new handler (called an invoker in JBoss) for a given protocol is deployed in JBoss, all existing services and applications can be reached automatically through this new invocation transport. Figure W-6 shows detached invokers.

JBoss 4.0 currently supports the following kinds of invokers:

Fast Socket

Fast Socket over HTTP (HTTP tunneling)

IIOP

JMS

SOAP

Figure W-6. Detached invokers