[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded
|
My colleagues’ suggestion was just to add these properties as part of the OperationMetrics capability (and we didn’t think of adding the “Operation” prefix because if would be unnecessary if the properties occur only at the operational level).
But if you think that both service level and operational metrics are reasonable, I can do that.
Kirk Wilson Office of the CTO 802 765-4337
-----Original
Message-----
Are you suggesting adding the following properties:
EndpointMetrics capability: MaxRequestSize MaxResponseSize LastRequestSize LastResponseSize
OperationMetrics capability: OperationMaxRequestSize OperationMaxResponseSize OperationLastRequestSize OperationLastResponseSize
All of these properties are minOccurs="0". This seems OK to me. The min side is missing, but if we don't need it, I guess we don't need to define it.
These will all need descriptions, what the metrics attributes mean for these metrics, and how the metadata relates to them.
Bryan
From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com] 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 Office of the CTO 802 765-4337
-----Original
Message-----
Good catch.
Operation + ${metric} it is 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 Office of the CTO 802 765-4337
-----Original
Message-----
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?
Any thoughts on this? (Just as a conceptual possibility if not a practical one.)
Kirk
Wilson Office of the CTO 802 765-4337
-----Original
Message-----
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]
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 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 AMTo: wsdm@lists.oasis-open.orgSubject: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc)uploaded This document proposes to extend the MUWS metrics capability, adding anoperation name &, optionally, portType, attributes to the current set ofMOWS metrics. As an example, we could report number of requests for thesample operation as <NumberOfRequests operationName="sample" ...>34</NumberOfRequests> <NumberOfRequests operationName="anotherSample"...>3</NumberOfRequests> In this environment, any number of numberOfRequests is permitted, thoughthey must have different operationNames, or, if the same, differentportTypes, as these are the distinguishing characteristics. Document current shows changes based on the MOWS Metrics capabilitysince it's pretty analogous. It occurred to me that this is not all that hard, so we may be able tofit it in (as was some folks recollection of the plan). My apologies toBryan as I think we were supposed to collaborate, but he's out of townnow, 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 beensubmitted by fred carter to the OASIS Web Services DistributedManagement(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/MowsOpMetrics.doc PLEASE NOTE: If the above links do not work for you, your emailapplication may be breaking the link into two pieces. You may be ableto copy and paste the entire link address into the address field of yourweb browser. -OASIS Open Administration
-- Fred Carter / AmberPoint, Inc. mailto:fred.carter@amberpoint.comtel:+1.510.433.6525 fax:+1.510.663.6301
-- Fred Carter / AmberPoint, Inc. mailto:fred.carter@amberpoint.comtel:+1.510.433.6525 fax:+1.510.663.6301
-- Fred Carter / AmberPoint, Inc. mailto:fred.carter@amberpoint.comtel:+1.510.433.6525 fax:+1.510.663.6301 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]