1. Management Task Force W3C Face To Face 01/22/03

2. Management Task Force Goal: Draft architecture to satisfy management requirements Till next F2F Deliverables: –Basic Management Data –Access to Management Data –List of Outstanding To Dos and Timelines –Approach to coordinate with other Standards Bodies

3. Participants and Progress Participants –Currently interested parties: IBM – Heather Kreger Computer Associates – Igor Sedukhin HP – Zulah Eckert, Yin Leng Husband Thomson – Hao He Talking Blocks – Mark Potts WebMethods – Sandeep Kumar Sonic – Colleen Evans

4. W3C WSAWGs role These works need a Web Services Architecture –To give them context –To give them guidance –To keep deliverables consistent –To promote interoperability/cooperation I asked for 6 weeks for the W3C to make progress I will be reporting to the OASIS group next week

5. Outside Forces OASIS Management Protocol TC: Access to management data using Web Services Glad to accept and submit requirements Working on how to express manageability data for manageable resources as portTypes –Schema based –Base portTypes derived from CIM models DMTF App WG put modeling WS on hold till W3C WS Arch MTF is done

6. Manageable Components Web Service Execution Environment Hosted Service (?) Web Service Discovery Agency TBD after WSA defines: Intermediary, Gateway, proxy… TBD after MTF discussion: Client Environment, Client

7. Review For each component (reaching consensus on requirements in each category) –Information (Identification, etc) –Configuration –Metrics –Operations –Events Access to manageability –Accessible via WSA Discovery –Of manageable components and relationships via WSA –Of manageability capabilities of components via WSA –Of Relationships from manageable components

8. Progress Christmas with our families Read 600 emails from the Christmas mail blizzard Shifted focus to manageability requirements for each architectural element Made significant progress on Web service Requirements

9. Work in progress Need to continue the MTF till the next F2F Achieve consensus on: –Base operations, metrics, events Web Service Web Service Execution Environment Discovery Agency –Interaction representation –Client management discussions Factor client into the manageability requirements Not management of client as a requester

10. Deliverables Deliver –Proposal for base manageability requirements (All) Web Service (50% progress) Web Service Execution Environment Discovery Agency –Management primer (Mark,Igor) –Reviewable draft of manageability requirements (All) –Glossary terms (All) Do we need an ongoing charter to address additional architectural elements as they are defined?

11. Next Steps Finish requirements for the architectural elements Where should the specification based on these requirements be done? OASIS Management Protocol Technical Committee Defining access to management of ANY resource (which Web Services are ONE of) Will define portTypes for resources, and continue to own and host them. Other resources have existing CIM models to work from, Web Services needs a model, schema and portType developed A subgroup to develop the model in parallel to current work so ready to do portTypes when they are ready Web services community, Management community, DMTF, and GGF involvement

12. Example Data: Service Environment Not consensus on this yet Identification information: Identifier, product name, version, installation date Configuration information: –services deployed –log name –URL for runtime –Security settings for runtime Metrics should be provided that indicate the rate of work and responsiveness of the execution environment to them oStart Time oNumber of Requests oNumber of Responses oNumber of Failure Responses oAverage Response Time of Responses oAverage Response Time of Failure Responses oAverage Response Time of Successful Responses Operations: lifecycle management for itself and the services running in it: ostart environment ostop environment odeploy a service oremove a service Notifications: There are also a number of notifications that the execution environment can send: oservice invocation failed osecurity access denied oState changes

13. Example Data: Web Service No Consensus on this yet Identification information: –service identifier –service name –service description Configuration information: –access URL –WSDL description URL –security settings Metrics to help track usage of the service –Number of Service Requests, Responses, Failures –Average Service Response Time of Responses, Failures, Successful –Service Elapse Execution time –Number of Invocations, Failures Per Method –Average Response Time of Responses, Failures, Successes per Method –Total Elapsed Execution Time per Method Operations to control service lifecycle –stop –start Notifications: state changes, service not found, service timed out, start failed, security failure, service failure, service not deployed, service unavailable, service failed, service deployed, service access denied

14. Example Data:Discovery Agency Identification information: product name,version,install date,maintenance level, instance name for instance, URL Configuration information: configuration file, replication period, nodes Metrics: that will help operators gauge its responsiveness and usage (demarked with where the data must come from): –the rate of accesses, startTime –number of invokes per operation (get, find, publish, publish entity, publish relationship) –average response time per operation (get, find, publish etc) –percentage of request failure responses –summary metrics :# of businesses, services, relationships Operations: start, stop, smartPing, backup trace on/off, replicate (start, cancel, nodes, period), reset metrics, manageUser(find, manage, email) Events: Degraded, running out of space, failure for percentage of messages, overloaded runtime, about to fail, resource availability failure, has failed, resource failure, security access failures (decrypt, authentication, signature verification failures, authorization of users)