Web Services Endpoint Management Architecture Requirements

1.1.1 Management Capabilities Categories

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

1. Identification - read only data that uniquely identifies the element. This data may include information that is not required for unique identification as well.
2. Status - information about operational state of a element
3. Configuration - a collection of properties which may be changed. A property may influence the behavior of an entity
4. 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
5. 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.
6. 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.1.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.1.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.

3.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.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.3.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.3.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.

4.1.1 Identification Requirements

Identification information:

1. identifier, mandatory - uri - a unique identifier for the Web service endpoint. This is the URI of the Port element in the WSDL document.
2. name, optional - readable name for the service. If provided should be the same as the Port name value in the WSDL document.
3. 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.
4. 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.
5. 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.
6. 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.

4.1.2 Configuration Requirements

None

4.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.

4.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.

4.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

4.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 [mtfLifeCycle]
• Processing state change - events for each process state transition

4.1.7 Access Requirements

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

4.1.8 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