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