RE: [wsdm] Issue on mows metrics

[Zhili Zhang <zhili@tibco.com>]

Separating metric definition from metric value and put definition into a metadata document is definitely a good idea to pursue in WSDM 1.0. If we decide not to use WS-RMD to describe metadata for 1.0, I propose the following for metric metadata in WSDM 1.0. Hope it is in consistent with how we handle metadata in other capabilities.

 

(1) Introduce a new type in MUWS called MetricDefinition, which has the following schema:
 <xs:complexType name = "MetricDefinition">
  <xs:sequence>
   <xs:element name = "ChangeType">
    <xs:simpleType>
     <xs:restriction base = "xs:string">
      <xs:enumeration value = "Counter"/>
      <xs:enumeration value = "Gauge"/>
      <xs:enumeration value = "Unknown"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:element>
   <xs:element name = "TimeScope">
    <xs:simpleType>
     <xs:restriction base = "xs:string">
      <xs:enumeration value = "Interval"/>
      <xs:enumeration value = "PointInTime"/>
      <xs:enumeration value = "SinceReset"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:element>
   <xs:element name = "GatheringTime">
    <xs:simpleType>
     <xs:restriction base = "xs:string">
      <xs:enumeration value = "OnChange"/>
      <xs:enumeration value = "Periodic"/>
      <xs:enumeration value = "OnDemand"/>
      <xs:enumeration value = "Unknown"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:element>
   <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"

processContents="lax"/>
  </xs:sequence>
 </xs:complexType>

Note: we can use attributesGroup and referenced in if we prefer.

 

(2) Rename muws-xs:MetricAttributes to muws-xs:MetricValueAttributes, and keep the same schema:
    <xs:attributeGroup name="MetricValueAttributes">
         <xs:attribute name="ResetAt" type="xs:dateTime"/>
         <xs:attribute name="LastUpdated" type="xs:dateTime"/>
         <xs:attribute name="Duration" type="xs:duration"/>
         <xs:anyAttribute namespace="##other" processContents="lax"/> 
    </xs:attributeGroup>

 

We can also keep "MyExampleIntegerMetric" type, which reference "MetricValueAttributes" instead.

 

(3) In MOWS, in addition to "EndpointMetricsPropertiesType" which is really about metric value, we introduce a property type for metric definition:

 

<xs:complexType name="EndpointMetricsDefinitionPropertiesType">
     <xs:sequence>
          <xs:element ref="mows-xs:NumberOfRequestsDefinition" minOccurs="0"/>
          <xs:element ref="mows-xs:NumberOfFailedRequestsDefinition" minOccurs="0"/>
          <xs:element ref="mows-xs:NumberOfSuccessfulRequestsDefinition" minOccurs="0"/>
          <xs:element ref="mows-xs:ServiceTimeDefinition" minOccurs="0"/>
      <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/>
     </xs:sequence>
</xs:complexType>
<xs:element name="EndpointMetricsDefinitionProperties" type="mows-xs:EndpointMetricsDefinitionPropertiesType"/>

 

Each of the referenced GED element is a type of muws-xs:MetricDefinition. For example:

 

<xs:element name="NumberOfRequestsDefinition" type="muws-xs:MetricDefinition"/>

 

(4) In a typical use case, manager or consumer will query the "EndpointMetricsDefinitionProperties" property document once and only once in the beginning of a metric collection process. The actual "EndpointMetricsProperties" values they poll or subscribed are about metric values only. 

 

Thanks
Zhili Zhang
TIBCO Software Inc.

 

 

 

 

 

 

-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Tuesday, November 02, 2004 9:19 AM
To: Heather Kreger
Cc: Fred Maciel; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Issue on mows metrics and other MOWS issues incurred by changes in MUWS

I'd like to discuss this issue on Thu, and in addition there are the following MOWS issues we need to close:

    1) Operational State -- do it in MOWS or MUWS will have it... I do not want to include it at all in MOWS 1.0 if we have Status

    2) Status -- does it have to mentioned in MOWS if MUWS defines it, do we map WSLC to status values

    3) Metadata -- how do we express it now

    4) Value of UML if Metadata is not captured there, is it actually helpful or just a page filler

 

On the metrics issue itself. I do not agree to ask implementers to parse any metadata documents for 1.0 implementations in the interop timeframe. Developers have enough to worry about trying to interop on WSRF and WSN only. I think we could express in MOWS values of metadata for the metrics and just bake it in the implementations for now.

 

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

 

---

From: Heather Kreger [mailto:kreger@us.ibm.com]
Sent: Tuesday, November 02, 2004 10:48 AM
To: Sedukhin, Igor S
Cc: Fred Maciel; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Issue on mows metrics

I agree we should resolve this before 1.0. Shall I add this to our agenda Thursday?

It only has to process the metadata document, which, unfortunately for WSDM 1.0, is a little vague for 1.0.

So lets look at the usage of this information ...

Managers or consumers of metrics typically poll for metrics they are processing. When they find metrics, or someone tells them the
metric name, they will need to look in the metadata document to understand metadata about the metric. They typically do this once for a metric that they are going to poll or subscribe to.

At runtime, when they get the value, on. they need to already understand the type information. They don't need all this type information on every request. There's been some experience (with WBEM) on scalability of implementations that pass around a lot of metadata with value data and I think we'd do well to learn from theirs.

We also need to be consistent in our approach for metadata, we really don't want to scatter it around... even though its tempting for 1.0 given the state of metadata.

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441) cell:919-496-9572

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

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

11/01/2004 06:53 PM

To	"Fred Maciel" <Fred.Maciel@hds.com>, <wsdm@lists.oasis-open.org>
cc
Subject	RE: [wsdm] Issue on mows metrics

Since such things are now metadata on the metrics, I don't even know how
to deal with them in MOWS. That is the implementer of a web service
endpoint is supposed to publish a metadata documnt which will include
such information.

And another point is that either of those counters could be SinceReset
or Interval. Implementation decides how to expose one.

I actually liked it when these were attributes of the element. I don't
even care that they have to be included with every response. It was easy
to implement and easy to use. Now, we can't even implement manageable
web services because we should look in fifty different places to
understand that the returned metric value is Interval or SinceReset...

So this is the issue we need to close before 1.0.


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


-----Original Message-----
From: Fred Maciel [mailto:Fred.Maciel@hds.com]
Sent: Monday, November 01, 2004 5:13 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Issue on mows metrics

Hi Igor (et al)

Everybody seems to agree that there are no Interval metrics in the
MOWS spec, however, the spec does not specify if the metrics are
Interval, PointInTime or SinceReset. (Igor: that's the issue I told you
about last week. Heather: could you add it to the issues list?).

Regards,

Fred Maciel.

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
p.php.



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.