Mark Newton presents JBoss application server 5.0 What's New
at the JUG Switzerland.
History of JBoss AS
119 days average release cycle, 9 releases of JBoss 3.2.x, J2EE 1.3 certification, JDK 1.3.
126 days average release cycle, 6 releases of JBoss 4.0.x, J2EE 1.4 certification, JDK 1.4.
55 days average release cycle, 3 releases of JBoss 4.2.x, JEE 5.0 compatible implementation, not certification, does 95% of it and requires JDK 5.0.
For JBoss AS 5.0.x new standalone implementations:
- JBoss Messaging (replaces old JBoss MQ)
- JBoss Security
- JBoss Federated SSO
New kernel is JBoss Microcontainer 2.0 and a profile service which is responsible for managing the POJOs that now bind the services together. Aiming for a Q1 2008 final release date and a CR in 2007.
JBoss Messaging 1.4
The new JMS 1.1 compatible messaging implementation supports distributed queues and topics as well as transparent failover and load distribution - internally it uses JGroups as transport.
Clustering
New major revision of JBoss Cache (2.1) with a much simpler API and a greater emphasis on usage outside of JBoss AS.
JBoss AOP 2.0
Integrated with the microcontainer: If you add behavior to a POJO using AOP, and you deploy it, you get dependency management - you can't call a POJO without the aspect, it won't be deployed before the aspect is available. And vice versa, aspects are not deployed if the POJOs they depend on are not deployed so far. Aspects can be bound to POJO lifecycle, e.g an aspect that binds a proxy into JNDI when the POJO enters the deployed
state. It also has some new plain AOP features: Before, Afer, Throwing, Finally flows
for interception.
What does the kernel do?
A microkernel needs to support dynamic loading and unloading of services. For that we need:
- a way to deploy new services
- a bus so that the client does not communicate with a service directly, clients are decoupled from services
How was this done in JBoss 3.x and 4.x? We used an MBeanServer to provide the bus and deployers that load services into the kernel together with a simple dependency injection mechanism. MBeans were used to implement services and configured with XML descriptors which injected attribute values into the MBeans at deployment. XMBean are special MBeans that allow you to add method interception to an MBean. Calls pass through the bus and interceptors with a level of indirection through a generic invoke(method, arguments, argumentTypes) operation.
For performance reasons the bus wasn't actually used much: A reference to a services would be looked up directly in the registry. So the interceptors were not used.
What was bad about the JBoss JMX microkernel:
- JMX is restrictive, lifecycle and classloading were a problem
- You can't run JMX on Java ME
- You actually need to know how to implement MBeans
- If you access services directly through a reference, interceptors are not applied
Design objectives for JBoss AS 5.x
Services should be POJOs and behavior should be added through AOP - effectively reproducing all the features of the JMX microkernel. Much improved dependency injection and classloading. Layered and easily extensible design (no references to JBoss classes), should be usable without JBoss AS.
The new name for this kernel is Microcontainer.
The core of the microcontainer is Container, Kernel, Dependency. Behavior is added with JBoss AOP.
Kernel: Provides the bus and registry, and an event manager.
Container: Wrapper for POJOs, AOP jointpoints and reflection on the actual service implementation POJO.
Dependency: Basically an abstract state machine that manages service dependencies.
Some optional packages on top of the core: OSGI integration, Guice integration.
Creating a service
Define the POJO with <bean> and <property> declarations in jboss-beans.xml (replaces the old jboss-service.xml). Beans have a name and a class, properties support injection with references to (other) bean names.
Add behavior using the <aop:aspect> namespace and elements and pointcut expressions. You can also extract the aspect/pointcut to a separate file.
Profile service
Management system for POJOs instead of the old JMX based administration which was based on editing XML files. People would manage configurations by keeping these files in CVS. The web console only supported changing the runtime values in memory, didn't write back into the files.
What we want:
- Centralized maintenance as profiles, e.g. all, minimal, default, ...
- Persistence of changes made to a profile across server restarts
- Propagation of profile changes across a cluster
- Versioning of profiles
Implementation similar to JDK 6 Open MBeans specification: A deployment has a collection of ManagedObjects, you define them with annotations in your service, e.g. @ManagedOperation(description="A setting you can change")
Summary
- JBoss AS 5.0 has a completely new architecture based on the microcontainer with POJOs and AOP
- Management improved with the addition of profile service
- Clustering and security is much enhanced
- It will be fully Java EE 5.0 compliant
