Capabilities taxonomy & a property

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

Title: Capabilities taxonomy & a property

In response to my AI from last F2F, here is the summary of my proposal for the "capabilities" discovery/identification.

We have had a number of discussions such as whether to use a Metrics capability category or Performance capability category. It seems that both have their own merit. One is useful for managers that want to display all available metrics irrespective what "kind" of metric that is and allow administrator to define policies or monitors against those. The other may be useful for a manager that is implemented to display a dashboard of performance characteristics and controls.

For one, such prolem could be solved by having metadata, however in WSDM case, a capability also includes operations and events, and therefore those would have to be "makred up" too. That would require a fairly complex metadata solution.

WSDM today has a good enough notion of manageability capabilities that group properties, operations and events that add up to a common semantics. Such capabilities could be the "leafs". The minumum inseparable set of what is needed to accomlish something.

The way to group the semantics to higher-level capabilities is by having a taxonomy (an acyclic graph).

For example,

One could define "leaf" MetricsEnumeration, then UserAccessMetrics and UserAccessConfiguration. Each would render 1-1 to a WSDL portType/interface.

Each higher-level combined capability is defined as a node in a graph. In other words it has an identity (e.g. a URI) and links to any other nodes and "leafs". For instance,

PerformamnceMetrics links to MetricsEnumeration and UserAccessMetrics
Metrics links to MetricsEnumeration
UserAccessManagement links to UserAccessMetrics and UserAccessConfiguration

By looking at the graph and a list of what a particular manageability endpoint supports one could figure out anything it wants about manageability. This also does not require WSDM to argue whether to use Metrics or Performamce as both could be accomodated.

Technically it could be supported by
        1) WSDM publishing a capabilities graph document and a formal markd up
        2) WSDM including a capability to list the supported "leaf" capabilities by the manageability endpoints (this could latter be replaced by WSDL 2.0 interface extensibility + use of WS-MetadataExchange)

For example,

<wsdm:Capability Identifier="uri:wsdm:capabilities:basic:MetricsEnumeration" Interface="wsdm-wsdl:MetricsEnumeration"/>
<wsdm:Capability Identifier="uri:wsdm:capabilities:basic:UserAccessMetrics" Interface="wsdm-wsdl:UserAceessMetrics"/>
<wsdm:Capability Identifier="uri:wsdm:capabilities:performance:metrics">
        <wsdm:Capability Identifier="uri:wsdm:capabilities:basic:MetricsEnumeration"/>
        <wsdm:Capability Identifier="uri:wsdm:capabilities:basic:UserAccessMetrics"/>
</wsdm:Capability>

And then

<GetResourceProperty>wsdm-xs:SupportedCapabilities</GetResourceProperty>

<GetResourcePropertyResponse>
<wsdm-xs:SupportedCapabilities>
<wsdm:Capability Identifier="uri:wsdm:capabilities:basic:MetricsEnumeration"/>
<wsdm:Capability Identifier="uri:wsdm:capabilities:basic:UserAccessMetrics"/>
<wsdm-xs:SupportedCapabilities>
</GetResourcePropertyResponse>

PS. I'm not at all sure that solving dynamic capabilities discovery is very necessary for WSDM 1.0. I think this could be postponed to the later time. I think we need to focus on defining "leaf" capabilities now. Those that can help us get some basic manageability prooven in action (e.g. MOWS).

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788