RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploade

All,

I have reviewed the Operation Metrics Proposal with the CA development staff. They have suggested the addition of 4 new properties that are relevant to operations:

MaxRequestSize (obviously modeled on MaxResponseTime)

MaxResponseSize

LastRequestSize

LastResponseSize.

Any objection to adding these as additional operational metrics? (Like service metrics, all operational metrics are optional.)

If necessary, we can discuss on Thurs. conf. callß HEATHER, please take note.

Kirk Wilson
Architect, Development

Office of the CTO

802 765-4337

-----Original Message-----
From: Fred Carter [mailto:fred.carter@amberpoint.com]
Sent: Monday, October 17, 2005 1:22 PM
To: wsdm@lists.oasis-open.org
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

wsdm message