The W3C Web Services Architecture Working Group has been formed to document the Web Services Architecture. Enough members of the Working Group felt that it was very important to define the manageability characteristics of the architecture along side the architecture itself. To that end, the following Goals, Requirements, and Critical Success factors were added to the Web Services Architecture Requirements document.

This paper is a draft of the architectural satisfaction of those requirements. The contents of this document should be folded into the main Web Services Architecture draft (http://www.w3.org/TR/ws-arch/ ). This draft not intended to ‘stand alone’ and independent of the Web Services Architecture document.

We would like this proposal to be included as a subsection in the Management Properties section of the Web Services Architecture.

For convenience, the Manageability Goals from the Requirements document (http://www.w3.org/TR/wsa-reqs ) are reiterated here:

1.1 From the Goals:

D-AG007 Management and Provisioning

The standard reference architecture for Web Services must provide for a manageable, accountable and organized environment for Web Services operations..

Critical success factors and requirements for this goal:

D-AC018 The Web Services Architecture must enable the management and provisioning of Web Services

1.2 From the Requirements:

D-AC018

The Web Services Architecture must enable the management and provisioning of Web Services

o AC018.1 Ensure that implementations of the Web Services Architecture are manageable.

§ AR018.1.1 Define a base set of standard metrics for architectural components and their interactions accompanied by guidelines for measurement.

§ AR018.1.2 Define a base set of standard management operations for Web Services Architecture implementations. Management operations includes, but is not limited to, support for configuration control and lifecycle control.

§ AR018.1.3 Define a base set of management events to be issued by the Web Services Architecture implementation.

§ AR018.1.4 Define a standard methodology for accessing management capabilities from the Web Services Architecture implementation.

o AC018.2 Ensure that implementations of the Web Service instances are manageable.

§ AR018.2.1 Define how a web service should expose web service specific metrics, configuration, operations, and events.

§ AR018.2.2 Support the discovery of web service management capabilities.

§ AR018.2.3 Define a standard methodology for accessing management capabilities of a Web Service through the Web Services Architecture implementation.

o AC018.3 Ensure that at least the following types of management aspects are supported: Resource Accounting, Usage Auditing and Tracking, Performance Monitoring, Availability, Configuration, Control, Security Auditing and Administration, and Service Level Agreements.

1.3 Scope

As a result of these Goals and Requirements, we have identified the scope of this work to be defining the architecture necessary to make a Web service architecture implementation and a Web service implementation manageable. In order for the Web service architecture to be manageable, each of the elements of the architecture must be manageable. This submission defines only the requirements for the Web service endpoint.

The management architecture must define the requirements for the minimum, basic information, operations, events, and behaviors that a Web services architectural element must support in order to be called manageable. Not all elements may be explicitly manageable. Not all implementations of Web services architectural elements must be manageable. Support of this manageable Web services architecture by implementations of the Web services architecture is highly recommended, but not required.

Security administration and security management are important aspects of management. These aspects are being addressed by other standards groups and will not be addressed by this draft. The exception to this is the requirement to support association of security administration WSDL with the functional service WSDL.

This architecture applies to the instrumentation of manageable Web Services. It does not prescribe how the management capabilites are used by management systems. For example, policies could be defined an implemented via management capabilities of Web services, although this architecture does not prescribe how to define and enforce those policies.

1.3.1 Management Capabilities Categories

The following management capabilities categories must be defined for each manageable entity:

Identification – read only data that uniquely identifies the element. This data may include information that is not required for unique identification as well.
Status – information about operational state of a element
Configuration – a collection of properties which may be changed. A property may influence the behavior of an entity
Metrics – raw atomic, unambiguous information. For manageability metrics, the information is for managmement purposes. The value of the metric captures the information at a point in time. Generally these values are numeric, but may be strings as well
Operations – methods that control or help manage the entity. Operations are distinct from configuration changes in that configuration changes are generally persistent over iterations/instances of the entity.
Events – changes in the state of the entity. Event descriptions are messages that indicate a problem, a lifecycle state change, or a state change.

1.3.2 Access

In addition to defining the information to be exposed by a manageable element, this architecture must define a standard means to access the management capabilities of the manageable element.

1.3.3 Discovery

Finally, it must be possible for the manageability capabilities and access to those capabilities to be discovered. Hence we need to define discovery of managable elements, manageability capabilities, and relationships.

1.4 Not in Scope

Management Systems – This architecture will not define what management systems should be defined to manage the Web services. Nor will it define how they should be implemented nor the way they will use the management capabilities. However, this specification may mention such systems as part of a scenario or use case.

Service distribution/installation/deployment – This architecture will not define how Web service component implementations are distributed, installed or deployed into any system or set of systems.

Access rights and control – This architecture will not define the policies (access control, trust, etc.) that govern management information flow.

Mapping of requirements to an XML Schema or WSDL portType – This architecture will not define an explicit XML Schema or portTypes to represent the informational requirements.

2 Management Concepts

We are defining the sufficient set of management capabilities for the architectural element Web services endpoint.

Manageability implies the existence of a sufficient set of management capabilities such that an entity is manageable

Manageable implies that an entity can be managed by a management system

Management capabilities includes identification, configuration, metrics, status, operations, and events offered by manageable entities for management purposes

Management is the utilization of the management capabilities by the management system.

Managed implies that an entity is actively being managed by a management system

Manageability Interface is that interface through which management capabilities are offered.

Management endpoint is the Web services endpoint offering the manageability interface for management purposes.

3 Manageable Components

3.1 Management Capabilities for all elements

This section defines the basic management capabilities, access, and discovery requirements. Management capabilities includes: identification, status, configuration, metrics, operations, and events.

All of the management capabilities must be expressible using the XML Information set (http://www.w3.org/TR/xml-infoset/ ).

3.1.1.1 Identification

Manageable elements of the Web services Architecture are identifiable by a URI.

The description of the management capabilities for a manageable element is identifiable by a URI.

3.1.1.2 Configuration

Configuration mechanisms that are common for each type of manageable element [e.g. Web service endpoint] should conform to the Web services architecture [e.g. description and interaction]. Configuration for a manageable element, beyond the common configuration, should be defined by an administrative interface. Other mechanisms to configure elements of the Web services architecture exist, but are not in scope of this document.

3.1.1.3 Status

Lifecycle and state diagrams are defined by the Web Services Architecture based on the submission from the Management Task Force: http://www.w3.org/2002/ws/arch/2/11/W3C.MTF.ServiceLifecycle.20021111_clean.htm. Status is information about the current state of the managed element.

The status of a managed element must be available through a manageability interface.

3.1.1.4 Events

For a manageable element there are two classes of events: Service State Changed and Request Processing events.

3.1.1.4.1 Service State Change Events

Service state change events occur whenever lifecycle state transitions happen as defined by the WSA draft. The service state change event description should include the previous state and the transition time. Optionally there may be events from the start of a transition.

3.1.1.4.2 Request Processing Events

Request Processing Event descriptions provide information for management systems and can be used to calculate many of the metrics. However, manageable components are not required to use these events to calculate metrics or unconditionally disseminate them to management systems. In busy environments, these kinds of events can create a significant amount of overhead and implementations should take that into consideration.

A request processing event description indicates that the state of a request has been changed and should include the previous state and the transition time. The event may also include any context associated with the request, reply, or failure message and any part or the complete content of these messages.

A managed element should be capable of producing notifications (deliverable descriptions of these events) such that they are available to a management system.

3.1.1.5 Metrics

‘Metrics’ are raw atomic, unambiguous, information, e.g. number of invocations. This can be contrasted with ‘Measurements’ that are calculated with a formula based on metrics, e.g. Average response time during the last hour of execution.

The metrics requirements do not enforce any implementation pattern. A managed element should allow any available metrics and measurements to be reported according to configurable time intervals, such as cumulative, sliding window, and interval. A managed element must declare which interval types are supported.

3.1.1.6 Access Requirements

Management capabilities must be available in a manner conformant to Web Services architecture.

3.1.1.7 Discovery Requirements

Discovery has three requirements to be satisfied, discovery of the manageable element, and discovery of the management capabilities for a manageable element, and discovery of relationships.

Discovery of the manageable Web service architecture element must use standard WSA Discovery mechanisms and use relationships provided directly by a manageable element
Discovery of the management capabilities of the Web service architecture element must allow determining if an element is manageable and the details of each management capability supported
Discovery of relationships via WSA discovery mechanism or directly from the manageable element

3.2 Manageability Requirements for Web Service Architecture Elements

3.2.1 Web Service Endpoint Manageability Requirements

This section defines the Management capabilities for a Web service endpoint, which is described in WSDL by a port element. Web service endpoint is defined in the W3C Web Services Architecture Glossary (http://www.w3.org/TR/ws-gloss/ ) as

“An association between a Binding and a network address, specified by a URI, that may be used to communicate with an instance of a Service. A Port indicates a specific location for accessing a Service using a specific protocol and data format. [WSD Reqs] “

A manageable web service endpoint needs to have associated administration and management interface descriptions.

Precise names and organization of the capabilities required to be manageable, where they comes from, how they are implemented and the information format is to be decided by the development a detailed specification.

If a capability is marked as mandatory then every Web service that is manageable must provide it. If a capability is marked as optional then it does not have to be provided, but if it is it should use the defined convention.

The following management capabilities should be available for each Web service endpoint:

3.2.1.1 Identification Requirements

Identification information:

identifier, mandatory – uri – a unique identifier for the Web service endpoint. This is the URI of the Port element in the WSDL document.
name, optional – readable name for the service. If provided should be the same as the Port name value in the WSDL document.
description, optional – readable description of the purpose of the service. This could be a catcher for taxonomy. If the description is provided in the WSDL document, then it should be the same as the WSDL description.
version, mandatory – the version of the Web service endpoint, this information may ALSO be in WSDL, although at this time there is no standard way to define it. We will need to define a standard WSDL extension for this at a later time.
WSDL Reference, mandatory – the reference to for the WSDL document for the service endpoint to be managed. It allows the management system to get a copy of or access to the WSDL document.
Semantics URI, optional – target name space of the WSDL document. It identifies the semantics and should use an identifier to refer to the semantics or it could use the URL to get a document that describes the semantics of the service, however, what is returned will depend on the mime type. It could be a human readable document, or an RDF document. The value could be the URL of a document, but it is not required to be a URL.

3.2.1.2 Configuration Requirements

None

3.2.1.3 Associations

Admin WSDL Reference, optional - Reference to access the WSDL that describes the administrative interface of the functional service. Typically this will be specific to the service’s requirements.
Security WSDL Reference, optional - Reference to access the WSDL that describes the security provisioning and/or security configuration interface for the service endpoint.
Management WSDL Reference, optional – Reference to access the WSDL that describes the management interface of the service endpoint.
WS Admin Access Port URI, optional - this would be the same as the URL in the location element in the administrative port referring to this service.
WS Security Access Port URI, optional - this would be the same as the URL in the location element in the security port referring to this service.
WS Management Access Port URI, optional - this would be the same as the URL in the location element in the management port referring to this service.

3.2.1.4 Metrics Requirements

Metrics help track usage, performance, and availability of the Web service endpoint. All the following metrics need to be collected and measured across a configurable time period.

The architecture should support that the following metrics be collected, but does not define how they are collected or their explicit definition. Follow on specifications need to provide these definitions, for example. what is a ‘successful response’ and how they are collected.

We are making the assumption that the requests identify the requester such that the following metrics can be provided per requester.

No consideration for the volume of data to be collected and maintained has been given. It would be a matter of implementation details of the specifications to satisfy these requirements and management system design.

3.2.1.4.1 For Service Endpoints

Current State – current status of the service endpoint, state and substate as described in the service life diagrams submitted by the MTF for the WSA draft..
Availability timestamp – point in time when the service endpoint becomes capable of accepting requests
Unavailability timestamp – point in time when the service endpoint is not accepting requests
Number of Requests – total number of requests having been accepted by the service endpoint.
Number of Successful Requests – total number of requests successfully completed by this service endpoint
Number of Failed Requests – total number of requests not completed successfully by this service endpoint. This could be optional because it can be calculated as a measurement from Number Of Requests and Number of Successful Requests.
Per Request Processing Time – time spent processing each individual request of the service endpoint. This may be a historical collection of request times.
Total Request Processing Time – the time spent processing in the service endpoint for all requests

3.2.1.4.2 For Operations

Number of Requests per Operation– total number of requests having been accepted by the service.
Number of Successful Requests per Operation– total number of requests successfully completed by this service
Number of Failed Requests per Operation– total number of requests not completed successfully by this service. This could be optional because it can be calculated as a measurement from Number Of Requests and Number of Successful Requests.
Per Request Processing Time per Operation– time spent processing each individual request of the operation in the service. This may be a historical collection of request times.
Total Request Processing Time per Operation – the time spent processing in the web service for all requests.

Other measurements that can be calculated from the metrics include averaging and totaling counters per service, operation, and requester.

Average Response Time of Responses – the average response time for all responses from this service. The timestamp should be taken as soon as it enters the service and again just as it responds. It will be the aggregate of the time spent in the service itself.

· Average Response Time of Failure Responses - the average response time for all failure responses this service. The timestamp should be taken as soon as it enters the service and again just as it sends the response. It will be the aggregate of the time spent in the service itself.

Average Response Time of Successful Responses - the average response time for all successful responses for this service. The timestamp should be taken as soon as it enters the service and again just as it sends the response. It will be the aggregate of the time spent in the service itself.
Average Response Time of Responses per Operation - the average response time for all responses for each method. The timestamp should be taken as soon as it enters the method and again just as it exits the method. It will be the aggregate of the time spent in each method.
Average Response Time of Failure Responses per Operation - the average response time for all failure responses for each method. The timestamp should be taken as soon as it enters the method and again just as it exits the method. It will be the aggregate of the time spent in each method.
Average Response Time of Successful Responses per Operation - the average response time for all successful responses for each method. The timestamp should be taken as soon as it enters the method and again just as it exits the method. It will be the aggregate of the time spent in each method.
High/Low water marks for processing time for requests (from processing time per request metric)
Rate of invocation for service
High/Low water marks for processing time for requests per operation
Rate of invocation for operation

3.2.1.5 Operations Requirements

Operations to control service lifecycle

Enable – allow this service to accept requests
Disable – disallow this service to accept requests
Reset Metrics – reset all counter metrics to 0
Test – tests service for operability, like a ‘deep’ ping

3.2.1.6 Events Requirements

The following events should be noted for each service:

· Lifecycle state change - events for each state and substate transition according to the lifecycle diagrams for the Web service (http://www.w3.org/2002/ws/arch/2/11/W3C.MTF.ServiceLifecycle.20021111_clean.htm)

· Processing state change - events for each process state transition

4 Appendix: Glossary

The following terms are submitted for consideration for inclusion into the WSA Glossary (http://www.w3.org/TR/ws-gloss/).

Note: The terms highlighted in yellow italics are still being finalized by the MTF and are subject to change.

Manageability - the property whereby the possessor of the property provides a sufficient set of management capabilities such that it is manageable.

Management capabilities - capabilities in either providing information or performing actions for management purposes. Management capabilities include providing identification, configuration, metrics, status, notifications of events, and performing operations for management purposes

Management - the utilization of the management capabilities by the management system. A management system may perform monitoring (of values), tracking (of states) and control of entities in order to produce and maintain a stable operational environment.

Manageable - capable of being managed by a management system

Managed -being actively managed by a management system.

Manageability Interface -the interface through which management capabilities are offered.

Management endpoint is the endpoint for management purposes.

Management operation - an operation that performs management.

Administration - configuring and/or securing entities

Administration Interface – the interface through which administration capabilities are offered.

Available service - being able to respond to a new request for service.

Availability – the property that a service offered by a service provider can be consumed by a service consumer. The service is said to be ‘available’ to the consumer.

Configuration - a collection of properties which may be changed. A property may influence the behavior of an entity.

Control - to cause a desired change in state. Management systems may control the lifecycle of entities or information flow such as messages.

Performance Monitoring - the monitoring of the entity to ascertain its operational speed, utilization, and efficiency.

Resource Accounting - the monitoring and tracking of resources used by the running entity.

Security Administration - configuring, securing and/or deploying of systems or applications enabling a security domain.

Combined with the following definition from the WSA Glossary

security domain

An environment or context that is defined by security models and a security architecture, including a set of resources and set of system entities that are authorized to access the resources. One or more security domains may reside in a single administrative domain. The traits defining a given security domain typically evolve over time.

Security Auditing - a service that reliably and securely records security-related events producing an audit trail enabling the reconstruction and examination of a sequence of events. Security events could include authentication events, policy enforcement decisions, and others. The resulting audit trail may be used to detect attacks, confirm compliance with policy, deter abuse, or other purposes.

Usage Auditing - a service that reliably and securely records usage-related events producing an audit trail enabling the reconstruction and examination of a sequence of events. Usage events could include resource allocation events and resource freeing events.

Usage Tracking - the tracking of the usage of a specific resource.

Service Level Agreement - an agreement between the service provider and the service consumer concerning quality and usage of service provided.

Lifecycle - the set of stages between creation and demise.

Event - a change in state.

State - a set of attributes representing the properties of a component at some point in time.

Metrics - raw atomic, unambiguous, information, e.g. number of invocations.

Measurements - values calculated with a formula based on metrics, e.g. Average response time during the last hour of execution.

Event description – messages that indicate a problem, a lifecycle state change or a state change.

Cumulative – a measurement interval type such that a measurement is calculated relative to the last time the service status was changed to ‘Up’.

Sliding Windows - a measurement interval type such that a measurement is calculated for a time interval relative to now, i.e. the last 10 minutes, the last hour.

Time Intervals - a measurement interval type such that a measurement is calculated for a time interval between two time stamps.

Identification – read only data that uniquely identifies the element. This data may include information that is not required for unique identification as well.

Status – information about the operational state of an element