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 very specific needs, not limited to J2EE. This flexibility allows JBoss to be used in very different environments, ranging from embedded systems to very large server clusters. The next few sections comment on some of these concepts briefly.
JBoss is based on a microkernel design in which components can be plugged at runtime to extend its behavior.
This design fits particularly well with the J2EE 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 J2EE platform at all times. JBoss takes a radically different approach: each of the services is hot-deployed as a component running on top of a very compact core, called the JBoss Server Spine (Figure W-2). Furthermore, users are encouraged to implement their own services to run on top of JBoss.
Tip
Consequently, the JBoss application server is not limited to J2EE applications, and indeed 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 .
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 an a managed bean (MBean).
Tip
More information about the JMX specification can be found at the Sun web site, http://java.sun.com/products/JavaManagement/.
Since Release 2.0, JBoss has been famous for being the first J2EE-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 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.
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 (Figure 21-3).
JBoss completely detaches the protocol handlers on which invocations are received 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 automatically be reached through this new invocation transport. Figure 21-4 shows detached invokers.
JBoss 4.0 currently supports the following kinds of invokers:
