wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] Issue on mows metrics and other MOWS issues incurred by changes in MUWS
- From: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "Heather Kreger" <kreger@us.ibm.com>
- Date: Tue, 2 Nov 2004 12:18:54 -0500
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
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 |
|
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]