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