Managing JBoss 7: A task oriented approach
10 Mar 2011
It’s been several weeks now, since we started working on the management web interface for JBoss 7. Time to outline some of the general ideas and concepts the console is build on. If you are not familiar with domain management approach that has been introduced in 7.0, you should make yourself familiar with it before reading any further.
Conceptually the domain model consists of three different levels, that we tried to reflect within the user interface: Configuration profiles, server groups and host specific settings.
If you think of these levels as being layered atop of each other, then Profiles would be the bottom most configuration level that acts as a blueprint for the layers atop of it. Profiles consist of subsystem specific settings (i.e. JCA, TX, etc) and are referenced by Server Groups.
Server Groups on the other hand specify configuration properties for a set of Servers that run on different Hosts.
A Host is the top most and most detailed level. It runs Server Instances that belong to a particular Server Group.
While there are numerous ways to organize the information accessible through the web interface, we used a few simple questions to guide our decisions:
- “What are the primary tasks?”
- “At what frequency to these task occur?”
- “What’s the impact on related configuration elements?”
The primary tasks already seem to be represented by the different levels described above: Changes to and requests of host specific information is something we expect to occur quiet regularly. This does cover use cases like starting server instances and requesting runtime state information (i.e. metrics).
Creation and modification of Server Groups will probably happen less often, except one specific use case, which is application deployment. Deployments are associated with server groups.
The least likely changes are going to happen on the profile level. I.e the modification of a thread pool size is something you probably wont do very often.
The outermost categorization looks as follows:
Now while this coarse grained organization nicely groups the primary tasks and allows you to focus on the goal you want to achieve, it doesn’t give you any clues which configuration properties are inherited from lower levels. Some elements can be specified on a lower and be replaced on higher level (i.e. System Properties in profiles and server groups).
This problem has two sides: On the one hand you need to know where an inherited property comes from in order to change it, on the other hand need to know what impact a modification might have on higher levels (Think of a JVM property on the profile level that impacts all server groups).
This problem isn’t solved yet. We are still working on visual distinction that allows you to clearly identify the source level of a configuration property and cross reference it accordingly. It might look like this:
Call for participation
There are plenty of other related topics that we can talk about, but that’s it for today. If you want to participate, I would suggest you take a look at the following resources and let us know to what degree the suggested categorization makes sense.
Stay tuned, we keep you posted.
