[wildfly-dev] Core and subsystem capabilities and requirements

[Brian Stansberry]

As we continue with our work splitting the WildFly code base into a core 
repo and then separate repos related to sets of features that we need to 
solidify the contracts between the various features and between features 
and the core.

I've taken a crack at an initial design document on this: see [1]. We 
also need to do the practical work of identifying the various 
dependencies between our existing subsystems, see [2] for a start on that.

I'd love to get feedback on this thread regarding the proposed design, 
as well as get direct edits on the [2] doc to flesh out the existing 
relationships.

Short version:

A capability is a set of functionality that becomes available when a 
user triggers it by including some configuration resource or attribute 
in the management model.

We'll identify capabilities via two strings: the name of the providing 
subsystem and then a capability name. A null subsystem name means a core 
capability; a null capability name means the base capability of the 
subsystem.

Capabilities will also declare the identifiers of any other capabilities 
they require.

There are two use cases for this capability/requirement data: 
provisioning (hopefully) and runtime.

Hopefully this information can be used by provisioning tooling when 
building up a configuration document for the server/domain it is 
provisioning. So instead of always including a stock configuration for a 
subsystem, allow the user to tailor it a bit by declaring what 
capabilities are required.

At runtime, when the configuration model is updated in such a way that a 
capability is now required, the OSH that handles that update will 
register the capability with the management layer in the MODEL stage. At 
the end of the MODEL stage the management layer will resolve all 
provided and required capabilities, failing the op if anything required 
is unavailable.

Thereafter, in the RUNTIME stage an OSH that needs a capability from 
another subsystem or the core can request an object implementing the API 
for that capability from the OperationContext.

I've thought a lot more about the runtime use case than I have about the 
provisioning use case.

[1] https://community.jboss.org/docs/DOC-52712

[2] https://community.jboss.org/docs/DOC-52700

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat