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: "Murray, Bryan P." <bryan.murray@hp.com>
- To: "David E Cox" <decox@us.ibm.com>, <wsdm@lists.oasis-open.org>
- Date: Mon, 24 Oct 2005 12:58:18 -0700
I do not know what it means to have a Start resource, or a
Stop or Reset resource. To me, operations are the actions that can be done to a
resource, not resources in themselves. I do not know of other models that define
resources for the actions to be taken on a resource - CIM does
not.
To get back to the original subject, I agree with Kirk
about State and Status not really making sense on a per operation basis. A
resource is in a particular state. Some operations are designed to change that
state. Sometimes the state changes for some resource-specific reason. I don't
see State as inherently being different just because a certain operation is
being processed (except for those operations designed to change a
state).
We are defining metrics on a per operation basis, not
because metrics are inherently different for different operations, but to report
more detailed data than the resource-wide metrics are able to do. The
resource-wide metric incorporates all of the data that the individual per
operation metrics do as a summary, but sometimes a management application wants
to have more detailed information about some critical operation than is
available with the original set of metrics.
Bryan
Hi Kirk,
I agree that if the service is Unavailable, quite
likely all of the operations are unavailable. The reverse, however, may
not be true. The operations in a service may vary widely in what they
require in order to accomplish their function. For example, reading a
record may work whereas writing a record may not (due to locking issues, etc).
Another example is that some operations may be simple, self-contained
operations that always work, but other operations may call out to other web
services or non-web services dependencies (such as a database) that may or may
not be up. Operations that access one table in a databsae that has
performance problems or poor tuning may show a degraded or unacceptable response
time, while other operations work fine.
From that perspective, I would have to get out a great big can
opener and open a can of worms. Just about (but not quite) everything in
the MOWS spec can be different from one operation to the next within a web
service. The metrics, state, and status, plus the relationships can
certainly be different. Message processing state can be different.
Would it make sense to model operations as resources, rather than trying
to qualify most but not everything in MOWS with operation qualifiers? This
would be in addition to the model of a Web service as a whole, not a replacement
for it. Let's discuss first whether it might or might not make sense
academically, before we reject it out of hand because it seems "hard" or too
much trouble.
Regards,
David
E Cox
"Wilson, Kirk D"
<Kirk.Wilson@ca.com>
10/24/2005 03:02 PM
|
To
| David E
Cox/Raleigh/IBM@IBMUS, <fred.carter@amberpoint.com>
|
cc
| <wsdm@lists.oasis-open.org>
|
Subject
| RE: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc)
uploaded |
|
On second thought: I’m not sure what value
per-operation status and state will have. If the service is Available or
Unavailable, that would apply generally to the operations within the service.
Perhaps if the service is Partially Aavailable we might what to drill down
to see what operations are available or not—does anyone have any opinions on
this?? I believe that state model used for operational state is pretty
much defined for the service-level state.
On
the other hand, I think we should include the operationName/portTypeName
attributes that are part of the OperationMetric capability as part of the
RequestProcessingStateType so that notification consumer can know what process
is being talked about. (I assume what is meant by “operation” in the
OperationMetric is the same thing that is being talked about as a “request” in
the RequestProcessingState. If so, then we should probably use of
consistent vocabulary and talk about a RequestMetric and Request metric
properties. Opinions on this??)
Kirk
Wilson
Architect,
Development
Office of the
CTO
802 765-4337
-----Original Message-----
From: Wilson, Kirk D
Sent: Friday, October 21, 2005 4:59 PM
To: 'David E Cox';
fred.carter@amberpoint.com
Cc:
wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
Dave, yes I agree. I already brought up about an operation
processing state (and, correspondingly) notifications. I think the general
consensus was that it would be more difficult. I agree that this issue
should be revisited.
Kirk
Wilson
Architect,
Development
Office of the
CTO
802 765-4337
-----Original Message-----
From: David E Cox
[mailto:decox@us.ibm.com]
Sent: Friday, October 21, 2005 8:05
AM
To: fred.carter@amberpoint.com
Cc:
wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
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]