There are a number of common problems that a subsystem developer will run into. This document is an attempt to convey the best recommended practices and common conventions that other subsystems follow. Following these will make it easier for UI tools to be developed since everything works according to a similar set of rules.

Use Resources Over Complex Attributes

It is much easier for UI tools to handle a small set of simple operations (add/remove/write) with simple attributes than it is to handle a monolothic resource with complex nested attributes. It also offers more flexibility in runtime updates. For example, it may be possible to increase the max thread size of a pool without restarting and replacing the entire pool. The rule of thumb is to keep creating resources until you hit primitives.

There is of course exceptions. For example,If the configuration contains an ordered list of which there is no unique name, a resource does not fit well. In this case a complex list type is unavoidable. However in such a scenario a set of "helper" operations should be created (e.g. add-foo).  But in this case, write-attribute must still be made available for updating the entire list at once.

In some cases it may not be clear how to model a nested child as a resource because it does not have a key->value name which is required. When this happens, you will need to come up with a new naming convention that fits the key/value model yet is still based on the original notion. For example a subsystem that has a foo, and a foo-expanded can change those names to be something like foo=classic and foo=expanded.

Make All Attributes Writable

Anything that can be edited in an xml file MUST be writable at runtime. It is possible, however, that modifying such a value can not be done "hot" at runtime, in which case forcing the server to reload or restart is the appropriate action (See ReloadRequiredWriteAttributeHandler)

Make ADD Smart, Don't Expose "Activate" Operations

The common problem is that during boot, or during a composite operation, the parent ADD happens BEFORE a child node ADD. Therefore it's runtime handler is called first. The proper way to deal with this situation is to have the parent add operation add a new "step" runtime handler to make the actual changes. This step will automatically run after all of the ones before it (the children), and so it will be able to read the various child resources that are needed.

Use SimpleResourceDefinition and *AttributeDefinition

These automate a large portion of validation and description handling, which makes the subsystem less error prone and quicker to develop.

Learn from the EE, EJB, and Messaging Subsystems

These subsystems are considered "good" followers of the conventions. Keep in mind though that Messaging existed before SimpleResourceDefinition, and *AttributeDefinition, so many resources in Messaging have not been converted to using SimpleResourceDefinition. So prefer following EE and EJB. Messaging is, however, a great example for solving more advanced complexities in a large subsystem (e.g. dynamic runtime resources)