Work class types

Use either default work classes created during a system application installation or define our own. Default work classes and directories for system applications are created during profile augmentation to support the high availability deployment manager. Default and new application work classes are defined on a per application edition basis.

Default application work classes

Each default work class has membership that is equivalent to a wildcard expression for all the work of that protocol type for that application. This work class is matched to last, with any new user defined work classes taking precedence. Default work classes cannot have their membership altered manually nor can they be deleted. They are meant to define how any work directed toward the application that does not get classified into any user-defined work classes into a service policy definition. While the membership cannot be deleted, classification rules can be defined on the default work class. This is especially useful if the environment does not need to classify based on work class membership, but does need to classify on some advanced criteria such as group identification or host name.

The default matchAction on the default work classes for the application is to classify to the default transaction class of the default service policy. This can be changed to select an alternate transaction class/service policy pair.

(ZOS) Routing and service policies for work classes are not supported for IIOP or JMS for applications deployed to z/OS platforms. WebSphere Application Server z/OS provides IIOP and JMS service classification.

New application work classes

Each edition of the application has its own definitions on how it should be classified into service policies. After the on demand router determines which application edition should be routed to, its service policy work class definitions are evaluated to determine how its work should be classified. When a new edition of an application is installed, we can choose an edition of the application to clone or choose none at all. If an edition is chosen, all of its work classes are cloned with the defaults appropriately renamed with the new application edition name. If no edition is chosen, only the defaults are created.

Configuration placement location

The configuration placement location for work classes for applications is:

<context>
    <context-name>applications</context-name>
    <child-context-names>
        <child-context-name>deployments</child-context-name>
        <child-context-name>workclasses</child-context-name>
        </child-context-names>
</context>
<context>
    <context-name>deployments</context-name>
    <child-context-names>
        <child-context-name>workclasses</child-context-name>
    </child-context-names>
</context>
<context>
    <context-name>workclasses</context-name>
    <root-document-type>WorkClass</root-document-type>
    <child-document-names>
        <child-document-name>WorkClass</child-document-name>
    </child-document-names>
</context>

Default system application work classes

Default work classes and directories for system applications, such as the adminconsole.ear, are created during profile augmentation to support the high availability deployment manager. An xd directory under the cell context mimics the systemApps structure and contains the default work classes. The default work classes are created under the following contexts:

cells/<cellName>/xd/systemApps/<earName>/workclasses/<workclass>/cells/<cellName>/xd/systemApps/<earName>/xddeployments/<appName>/workclasses/<workclass>/

Intelligent Management listens for changes to the systemapps.xml file under the node context for any updates:

cells/<cellName>/nodes/nodeName/systemapps.xml

Middleware application work class location

The middleware application work classes location is:

    <context>
        <context-name>middlewareapps</context-name>
        <child-context-names>
            <child-context-name>middlewareappeditions</child-context-name>
            <child-context-name>workclasses</child-context-name>
            <child-context-name>preferences</child-context-name>
        </child-context-names>
    </context>
    <context>
        <context-name>middlewareappeditions</context-name>
        <child-context-names>
            <child-context-name>workclasses</child-context-name>
        </child-context-names>
    </context>

Intelligent Management listens for changes to the systemapps.xml file under the node context for any updates:

cells/<cellName>/nodes/nodeName/systemapps.xml

Related:

Routing policy action types

Define a service policy

Intelligent Management: routing and service policies