wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded
- From: David E Cox <decox@us.ibm.com>
- To: fred.carter@amberpoint.com
- Date: Fri, 21 Oct 2005 08:05:19 -0400
I think this will be very useful, and
thanks for the Proposal, Fred. But metrics is only part of the story.
Are we going to do per-operation state and status? Are we going
to do per-operation message processing state and notifications? (The
last item may be possible already, if you specify the operation in your
xpath). I know those weren't explicitely in the action item, so I
am asking if we can add them to the action item, or write a new action
item.
Regards,
David E Cox
Fred Carter <fred.carter@amberpoint.com>
10/17/2005 01:21 PM
Please respond to
fred.carter |
|
To
| wsdm@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsdm] Groups - OperationMetricsProposal
(MowsOpMetrics.doc) uploaded |
|
Good catch. Operation + ${metric} it is
Thus quoth Wilson, Kirk D (~ 10/15/2005 11:24 AM ~)...
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
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]