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
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 WSAWG’s 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 s 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
Start Time
Number of Requests
Number of Responses
Number of Failure Responses
Average Response Time of Responses
Average Response Time of Failure Responses
Average Response Time of Successful Responses
Operations: lifecycle management for itself and the services running in it:
start environment
stop environment
deploy a service
remove a service
Notifications: There are also a number of notifications that the execution environment can send:
service invocation failed
security access denied
State 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, )
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)