Management Task Force

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 EnvironmentNot 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

13
Example Data Web ServiceNo 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

14
Example DataDiscovery 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)