The Jira issue WFCORE-920 is for converting the management definitions in the model into a subsystem, this article is to explore how this could look.

With the introduction of Elytron many security services will now be provided from a subsystem rather than from the core model as is the situation today, this means management definitions will be depending on items from other subsystems.  In addition to this we also have subsystem support in the host controller now, previously there were no subsystems there so anything needed by a host controller needed to be in the main management model.

This article is capturing possible ideas, at this point it is not a final design proposal.

Backwards Compatibility

I would propose that for compatibility we allow the existing resources to remain, administrators can then decide if they want to use the legacy management model or the new subsystem.  We will then add constraints in the model to ensure only one or the other is selected.

If we take this approach then references to legacy resources such as security realms can be dropped as there is still an approach that can be used if administrators still want to use them.

The legacy items will be deprecated and at some point in the future will be removed entirely.

Management Interfaces

These are the entry point to the server for administration, they are also the connection used in domain mode by slave host controllers and also the connection used for individual app server instances to connect back to their local host controller.

Presently we have three different interface types: -

    <xs:complexType name="server-management-interfacesType">
        <xs:sequence>
            <xs:element name="native-remoting-interface" type="management-remoting-interfaceType" minOccurs="0"/>
            <xs:element name="native-interface" type="server-native-management-interfaceType" minOccurs="0"/>
            <xs:element name="http-interface" type="server-http-management-interfaceType" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>

native-remoting-interface is where the interface is going to be exposed by a connector in the Remoting subsystem, native-interface is where an Endpoint and connector is created for the sole purpose of exposing the management interface, http-interface is where a HTTP server is started to expose management over HTTP.  Also the http-interface definition contains an attribute 'http-upgrade-enabled', if set to true then the HTTP connection can be upgraded and switch to using a native / Remoting connection.

I would propose that for the interface definitions we shrink this down to just two definitions, one for native and one for http - these then contain configuration to define exactly how they are exposed.

<subsystem xmlns="urn:wildfly:domain:management:1.0">
    <interfaces>
       <native-interface sasl-authentication="...">
            <remoting />
           <direct socket-binding="..." />
           <http-upgrade use-http-interface="true|false" undertow-listener="..." />
        </native-interface>
       <http-interface http-authentication="...">
            <direct http-socket-binding="..." https-socket-binding="..." />
           <undertow-listener name="..." context="/management" />
        </http-interface>
    </interfaces>
</subsystem>