I think
there might be a processing
problem in the proposal as it current stands. When encountering a
<NumberOfRequests>
element, the client parser would have to check the attributes to
determine
whether the data is at the service level or the operation level. That
might
produce a backwards compatibility problem for current implementations.
I would
recommend that the OperationMetrics
properties also be prefaced with “Operation”, i.e.
<OperationNumberOfRequests>,
etc.
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
-----Original
Message-----
From: Fred Carter
[mailto:fred.carter@amberpoint.com]
Sent: Friday, October
14, 2005
2:27 PM
To: wsdm@lists.oasis-open.org
Subject: Re: [wsdm]
Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
Thus
quoth Wilson, Kirk D
(~ 10/14/2005 11:16 AM ~)...
I haven’t
had time
to read Fred’s proposal yet (weekend reading), but isn’t another
alternative just to handle OperationMetrics as an “empty”
capability (extension of MOWS metrics) and allow the designer to
specify GEDs
as part of an service specific extension for each metric property for
each
operation of interest within that service (a bit ugly and tedious)?
indeed
it is. That's
effectively, albeit with even fewer restrictions, the alternative
mentioned
below the query resource properties. It would require each new
manageable endpoint to specify their own schema, I think, or run
entirely
within the extensibility rules. Then, though, I think you need to
figure
out how to link them back to this capability... By type? By some
other, still-to-be-named attribute?
I thought about this. We could do it using, say, the operationName
attribute as a key meaning that this is an operation metric. Or use
the
mows:operation{integer,duration} type, I suppose. That would work
as well. Difference is that they caller will have to examine the
schema
to 1) figure out if there are op metrics, and 2) to figure out what
their names
are. In this case, the names are known, the operation's names come
from
the wsdl, but you either have to get the whole prop doc and mung or
rely on the
server to do it (its having implemented queryResourceProps). Unclear
to
me which is preferred...
Any thoughts
on
this? (Just as a conceptual possibility if not a practical one.)
Kirk
Wilson
Architect, Development
Office
of the CTO
802 765-4337
-----Original
Message-----
From: Tony Gullotta [mailto:tony.gullotta@soa.com]
Sent: Friday, October
14, 2005
1:59 PM
To: wsdm@lists.oasis-open.org
Subject: RE: [wsdm]
Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
I see.
So we have to use QueryResourceProperties because GetResourceProperty
won't be
able to distinguish between operations.
From: Fred Carter [mailto:fred.carter@amberpoint.com]
Sent: Friday, October
14, 2005
10:52 AM
To: Tony Gullotta
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm]
Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
Well,
it's just a
properties document. So whatever query mechanism for that would have
to
do -- that's a WSDM limit, I think. So this would use the
QueryResourceProperties optional call with a query expression (dialect
XPath)
of
*[namespace-uri()="this capability's namespace"
and ./@operationName="desiredOperation"]
(or something like that)
An alternative, where the query function isn't required, would be to
name the
operation metrics with the operation name. However, I think we'd have
a
hard time coming up with a schema then (we'd need a meta schema :-) ),
since we
wouldn't have the metric names at spec time (since the operations vary
quite a
bit, obviously).
At a higher level, the choice
at
some level, was either individual metrics or a more general property
document
element for the operation -- that would contain all the stuff about an
operation. This seemed counter to how we've done capabilities, so I
separated it this way.
The other choice involves a capability (or some combination thereof)
that
instituted a subdocument for operation properties. I wasn't quite sure
if
that was easily representable, so...
Thus quoth Tony Gullotta (~ 10/14/2005 10:34 AM ~)...
How would I request the NumberOfRequests metric for just one operation?
-----Original Message-----
From: fred.carter@amberpoint.com [mailto:fred.carter@amberpoint.com]
Sent: Friday, October 14, 2005 10:22 AM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc)
uploaded
This document proposes to extend the MUWS metrics capability, adding an
operation name &, optionally, portType, attributes to the current set of
MOWS metrics. As an example, we could report number of requests for the
sample operation as
<NumberOfRequests operationName="sample" ...>34</NumberOfRequests>
<NumberOfRequests operationName="anotherSample"
...>3</NumberOfRequests>
In this environment, any number of numberOfRequests is permitted, though
they must have different operationNames, or, if the same, different
portTypes, as these are the distinguishing characteristics.
Document current shows changes based on the MOWS Metrics capability
since it's pretty analogous.
It occurred to me that this is not all that hard, so we may be able to
fit it in (as was some folks recollection of the plan). My apologies to
Bryan as I think we were supposed to collaborate, but he's out of town
now, and I'll be out much of next week.
Feel free to shoot away on the list!
/fred
-- fred carter
The document named OperationMetricsProposal (MowsOpMetrics.doc) has been
submitted by fred carter to the OASIS Web Services Distributed
Management
(WSDM) TC document repository.
Document Description:
Operation Metrics Proposed Text
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsdm/document.php?document_
id=14904
Download Document:
http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/14904/Mow
sOpMetrics.doc
PLEASE NOTE: If the above links do not work for you, your email
application may be breaking the link into two pieces. You may be able
to copy and paste the entire link address into the address field of your
web browser.
-OASIS Open Administration
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301