The document was produced by the Web Services Architecture Working Group while working on the management aspect of the Web Services Architecture. It is provided here for archival purposes.
Contributors
Heather Kreger, IBM (kreger@us.ibm.com)
Mark Potts, Talking Blocks (mark.potts@talkingblocks.com)
Igor Sedukhin, Computer Associates (igor.sedukhin@ca.com)
Hao He, Thomson (hao.he@thomson.com.au)
Zulah Eckert, Hewlett Packard (zulah_eckert@hp.com)
Yin-Leng Husband, Hewlett Packard (Yin-Leng.Husband@hp.com)
Document History
February 12, 2003 – Heather Kreger, extracted this document from the MTF Working Draft
February 19, 2003 – Heather Kreger accepted all changes from MTF Editing calls 2/12-2/19.
February 26, 2003 – Heather Kreger, edited glossary based on MTF call.
February 28, 2003 – Heather Kreger, edited based on Igor Sedukhin’s edits.
Table of Contents
1.3.1 Management Capabilities Categories. 5
3.1 Management Capabilities for all elements. 6
3.1.1.4.1 Service State Change Events. 7
3.1.1.4.2 Request Processing Events. 7
3.1.1.6 Access Requirements. 8
3.1.1.7 Discovery Requirements. 8
3.2 Manageability Requirements for Web Service Architecture Elements. 8
3.2.1 Web Service Endpoint Manageability Requirements. 8
3.2.1.1 Identification Requirements. 8
3.2.1.2 Configuration Requirements. 9
3.2.1.4 Metrics Requirements. 9
3.2.1.4.1 For Service Endpoints. 10
3.2.1.5 Operations Requirements. 11
3.2.1.6 Events Requirements. 11
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:
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
D-AC018
The Web Services Architecture must enable the management and provisioning of Web Services
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.
The following management capabilities categories must be defined for each manageable entity:
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.
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.
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.
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.
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/ ).
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.
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.
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.
For a manageable element there are two classes of events: Service State Changed and Request Processing 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.
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.
‘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.
Management capabilities must be available in a manner conformant to Web Services architecture.
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.
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:
Identification information:
None
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.
Other measurements that can be calculated from the metrics include averaging and totaling counters per service, operation, and requester.
Operations to control service lifecycle
The following events should be noted for each service:
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