1 / 9

MOWS @ WSDM F2F

MOWS @ WSDM F2F. 15 Apr 2004. Agenda. Metrics Service Lifecycle State Request Processing State Managing Operations. Metrics. An important metric is ResponseTime (used in SLAs, etc.) No way to reliably calculate it from the current MOWS Metrics.

ula
Download Presentation

MOWS @ WSDM F2F

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MOWS @ WSDM F2F 15 Apr 2004

  2. Agenda • Metrics • Service Lifecycle State • Request Processing State • Managing Operations

  3. Metrics • An important metric is ResponseTime (used in SLAs, etc.) • No way to reliably calculate it from the current MOWS Metrics. • No reason to monitor every request state change for this metric either • Suggestion is to add • mows-xs:MaxResponseTime which is a gauge, interval • mows-xs:LastResponseTime (Richard) • May be more • Writeup

  4. Metrics deficiency rateresponse 2 p/s<1s 2 p/s<1s or <2s 1 p/s<1s or <2s or <3s 2 4 5 #R 5 1 3 #S

  5. Service Lifecycle State • Need to complete mapping of the W3C Lifecycle State to the WSDM state model • Pending MUWS state model representation • Pending MUWS events against state model

  6. Request Processing State • Need to add a new capability to express the W3C Request Processing State • Define state representation (possibly following MUWS state model representation pattern) • Define events: names and information set • Define “triggers”/”conditions” • Define request data collection “filters” • Actual implementation/rendition would rely on our choice of notification mechanism • Pending WSN, writeup

  7. Managing Operations • Currently managing the endpoints irrespective of operations • metrics are aggregated • In many cases it makes sense to manage performance of individual operations (e.g. GetMapData vs. LogIn). • Using Request Processing State with “triggers” is very expensive for just the per-operation metrics • Do we need to manage per operation? • YES • Exact solution TBD • Separate capability • Optionality is implied • Alternatives • Property name based solution • Manageable op resource solution (EPRs) • Metadata on the metrics property solution • Metrics complex type (container) solution

  8. Managing Operations • A nicer solution is possible (a proposal) • Define manageable operation resource • MOWS.OperationIdentification • MOWS.OperationMetrics extends MOWS.EndpointMetrics • MOWS.OperationRequestProcessingState extends MOWS.EndpointRequetsProcessingState • Use WS-Resource pattern to work with various manageable operation resources via the endpoint resource’s manageability endpoint (same endpoint). • MOWS.EndpointManageableOperations capability lists EPRs of all manageable operations (this could also be done more generally via MUWS.Relationships at a later point)

  9. Managing Operations (discussion) Manageable operation resource EPR EPR Manageable endpoint resource EPR EPR Manageability endpoint WSDL or EPR

More Related