Web Services Distributed Management: Management of Web Services (WSDM-MOWS) 1.1
OASIS Standard, 01 August 2006
Document identifier:
wsdm-mows-1.1-spec-os-01
Location:
http://docs.oasis-open.org/wsdm/wsdm-mows-1.1-spec-os-01.pdf
Technical Committee:
OASIS Web Services Distributed Management TC
Chair(s):
Heather Kreger, IBM, <kreger@us.ibm.com>
Editors:
Kirk Wilson, Computer Associates kirk.wilson@ca.com
Igor Sedukhin, Computer Associates.
Abstract:
The Web Services Distributed Management (WSDM) specifications, as declared in the committee charter, define A) how management of any resource can be accessed via Web services protocols – Management Using Web Services, or MUWS, and B) management of the Web services resources via the former – Management Of Web Services, or MOWS. This document is the WSDM specification defining MOWS.
Status:
This document was last revised or approved by the membership of OASIS on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this
specification to the Technical Committee’s email list. Others should send
comments to the Technical Committee by using the “Send A Comment” button on the
Technical Committee’s web page at www.oasis-open.org/committees/wsdm/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (www.oasis-open.org/committees/wsdm/ipr.php.
The non-normative errata page for this
specification is located at www.oasis-open.org/committees/wsdm.
Table of Contents
2.1 In-band and Out-of-band
Manageability
2.2 Application to Resources Exposed
as Web Services
3.1 Responsibilities of the
Implementations of the Manageability Endpoints
3.2 Manageability at the Web service
level
3.3 Using manageability of Web
services endpoints
4.1 Additional security
considerations when managing Web services
5 Web service manageability
capabilities
5.1 Common manageability capabilities
5.1.1 Manageability References
5.1.1.1.1 GetManageabilityReferences
5.2 Web service endpoint
manageability capabilities
5.2.3.1 Information markup declarations
5.2.5.1 Information markup declarations
5.2.7 Operation Operational Status
5.2.8 Request Processing State
5.2.8.1 Information markup declarations
5.2.8.2.1 RequestProcessingNotification message
5.2.8.2.2 Examples of events against the Web
service endpoint request processing state
Appendix F. Notification topic
spaces
Web services are an integral part of the IT landscape, and, as such, are vital resources to many organizations. Web services may interact with other Web services and are used in business processes. Interacting Web services form a logical network which may span enterprise boundaries. Managing such a logical network is critical for organizations that use Web services to automate and integrate various internal functions, and deal with partners and clients electronically. To manage the Web services network, one needs to manage the components that form the network – the Web services endpoints. This part of the WSDM specification addresses management of the Web services endpoints using Web services protocols [MOWS-Reqs].
The Management Of Web Services (MOWS) specification is based on the concepts and definitions expressed in the Management Using Web Services specification (MUWS) [MUWS]. It is recommended that the reader is aware of the MUWS specification contents.
Definitions and examples in this document are based on the following specifications. It is recommended that the reader is aware of their contents.
§ WS Architecture [WS-Arch]
§ XML [XML]
§ XML Namespaces [XNS]
§ XML Schema [XMLS]
§ SOAP [SOAP]
§ WSDL [WSDL]
§ WS-Addressing [WS-A]
§ WS-ResourceProperties [WS-RP]
§ WS-BaseNotification [WS-N]
§ WS-Topics [WS-T]
§ XML Path Language [XPath]
Section 5 and appendices D, E and F are normative specifications. The rest of the document is non-normative, and is provided as a background and explanatory material.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This specification is based on the terminology defined in the WSDM [MUWS] specifications. In addition, the following terms are defined.
Manageable Web service endpoint – is a Web service endpoint as a manageable resource.
1.2 Notational conventions
This specification uses an informal syntax to describe the
XML grammar of the messages, property instances and event information forming the manageability capability
interfaces. This syntax uses the following rules:
§ The syntax appears as an XML instance, but the values indicate the data types instead of values.
§ {any} is a placeholder for elements from some other namespace (like ##other in XML Schema).
§ Characters are appended to attributes, elements, and {any} to indicate the number of times they may occur as follows: ? (0 or 1), * (0 or more), + (1 or more). No character indicates exactly 1 occurrence. The characters [ and ] are used to indicate that contained items are to be treated as a group with respect to the ?, *, and + characters.
§ Attributes, elements, and values separated by | and grouped with ( and ) are meant to be syntactic alternatives.
§ ... is used in XML start elements to indicate that attributes from some other namespace are allowed.
§ The XML namespace prefixes are used to indicate the namespace of the element being defined
A full WSDL description of all interfaces and XML Schemas of all information elements are available in the appendices.
When describing instances of XML information, and in order to refer to elements and attributes, this specification uses a simplified XPath [XPath] notation which can be formally defined as follows.
§ Path = ‘/’? ([‘@’? (NCName | QName | ‘*’)] | [‘(‘ (NCName | QName | ‘*’] ‘)’) [‘/’ Path]?
§ NCName is an XML non-qualified name as defined by XML Schema [XMLS]. In this case the namespace is assumed to default to the namespace of this specification.
§ QName is an XML qualified name as defined by XML Schema [XMLS].
§ The symbol * denotes any name match.
§ The symbol / denotes a path delimiter. If it appears as the first element of the path, it denotes the root of the XML document.
§ The symbol @ denotes a reference to an XML attribute, otherwise NCName, QName or * refer to an XML element.
§ The symbols ( and ) denote a reference to an XML Schema type.
For example, /E1/E2/@A1 refers to an attribute A1 of an element E2 contained in element E1 which is a root of the XML document. E1/ns1:E2/E3 refers to an element E3 which is contained in the element E2 which is contained in the element E1 anywhere in the XML document. In this case element E2 belongs to the namespace mapped to the prefix ns1. (ns2:T1)/E1/ns1:E2/@A1 refers to an attribute A1 on an element E2 contained in the element E1 declared in the XML Schema type T1 which target namespace is mapped to the prefix ns2.
Management of Web services (MOWS) is an application of Management using Web services (MUWS) to the resources that are elements of the Web Services Architecture [WS-Arch]. This WSDM specification defines how the manageability of Web service endpoints and resources exposed as Web services can be accessed via Web services. In order to achieve this goal, MOWS is based on the MUWS specifications, and the architecture, definitions and dependencies thereof [MUWS].
Application of the WSDM architecture concepts (section 2 of the MUWS specification part 1) to the management of Web services could be described as follows (Figure 1). A manageability Web service endpoint (or, shortly, manageability endpoint) provides access to the manageable Web service endpoint resource (a manageable resource, in terms of MUWS). A manageable Web service endpoint (or, shortly, manageable endpoint) could be, for example, an endpoint of an order entry Web service for which received messages could be counted and reported to the manageability consumers. Following the WSDM concepts, the manageability consumer discovers the manageability endpoint and exchanges messages with it in order to request information, subscribe to events or control the manageable endpoint resource.
Figure 1. Management of Web services concepts
Refer to section 2 of the MUWS specification part 1 [MUWS] for more detailed explanation of discovery and message exchange between manageability consumers and manageability endpoints.
The following are important aspects of the WSDM architecture.. Please refer to the referenced sections of the MUWS specification [MUWS]
§ Focus on resources (section 2.1 of MUWS part 1) – focus on providing access to the manageable resources – a contract between a manageability consumer and a manageable resource with regards to discovery and message exchanges.
§ Composeability (section 2.2 of MUWS part 1) – allows a non-conflicting, incremental mix of Web services implementation aspects and manageability capabilities.
2.1 In-band and Out-of-band Manageability
A unique feature of the MOWS subject domain is that a manageability endpoint and a manageable endpoint are both Web services endpoints, and therefore could be the same endpoint or could be different endpoints. In other words, manageability consumers and regular Web service consumers could target their messages to the same or to different endpoints. Either of the approaches is allowed by the MOWS architecture and the implementation choices are transparent for manageability consumers (and Web service consumers, for that matter). The Figure 2 illustrates this.
Figure 2. In-band and out-of-band manageability
2.2 Application to Resources Exposed as Web Services
WSDM allows a resource and all of its services to be manageable in a standard and interoperable manner. A resource may support both manageability and functional capabilities. For example, a printer can obviously print, but the same printer may also be able to indicate if it is on-line and may be able to notify when the toner is running out. A manageable resource may allow access to its manageability capabilities and functional capabilities via Web services. Web services represent a composition of manageable and functional qualities of a given resource (Figure 3).
Manageability consumers might take advantage of a composition of manageability and functional capabilities: 1) management-oriented consumers gain visibility into functional aspects of a resource 2) business-oriented consumers gain visibility into management aspects of a resource. For example, a Web services-based business process may involve a selection of an on-line printer with sufficient amount of toner in order to print an urgent report for executives.
Composeability makes it easy for implementers of resource services to offer an appropriate set of functional capabilities along with an appropriate set of manageability capabilities guided by the appropriate model for authorization of these requests.
Figure 3. Application to resources exposed as Web services
2.3 Self-Management
The WSDM specifications define how to use Web services to expose manageable resources (MUWS), and in addition, define how to expose manageable Web service implementations (MOWS – this specification). Application of MOWS to MUWS gives an interesting combination of the manageable management. Using both specifications, it is possible to build reliable and accountable management systems (Figure 4).
Figure 4. Applying MOWS to MUWS
Using definitions expressed in WSDL 1.1 [WSDL] and WS-Addressing [WS-A] as guidelines, a Web service (described by a WSDL 1.1 service element) is an aggregate of endpoints (described by WSDL 1.1 port elements). An endpoint binds a Web service interface (described by a WSDL 1.1 portType element) to an address (URI). Each interface describes a set of messages that could be exchanged and their format. Properly formatted messages could be sent to the endpoint at the address in the way prescribed by the binding (described by a WSDL 1.1 binding element). A Web service description contains definitions of a combination of interfaces and services.
According to the section 2, management of Web services starts at an endpoint resource which, therefore, becomes a manageable resource, specifically called a manageable endpoint. The reason the Web service endpoint is the basic manageable resource is that (1) anything behind an endpoint is a concrete implementation (e.g. an application hosted on a server), and (2) an aggregate of endpoints is a logical construct, management of which has to be inferred from manageability of the constituent endpoints. This specification focuses on defining manageability capabilities of the Web service endpoints. Furthermore, (1) is in the realm of the applications/systems/networks management, and (2) should be done by the intelligent management systems. Aspects of (1) are further discussed in section 3.1. Aspects of (2) are further discussed in section 3.2.
This specification balances requirements of Web services management applications and the complexity of implementing manageability endpoints.
3.1 Responsibilities of the Implementations of the Manageability Endpoints
The system providing manageability capabilities for a Web service endpoint must be aware of the environment as experienced from the Web service caller's point of view. This experience may be dependent upon hardware or software configuration in which the Web service endpoint exists. Implementations of manageability endpoints may need to account for management requests made with respect to the Web service caller's point of view.
Consider two examples. The first case is that of a hardware routing configuration. A hardware device controls access to all messages sent to a particular URL such as http://external.example.com/theService. Upon receipt of messages for that URL, the device distributes the messages to Web service endpoints at the http://s1.example.com/theService, http://s1.example.com/theService, and http://s2.example.com/theService addresses.
If, say, a query regarding metrics were made regarding the Web service endpoint receiving messages at the http://external.example.com/theService address, it is the responsibility of the implementation of the manageability endpoint to aggregate the results from the three underlying Web service endpoints to provide a meaningful response.
A second example is one in which a single Web service endpoint is accessible at two distinct URLs due to DNS aliasing. Consider the Web service endpoint at http://services.example.com/creditCheck. External to the Example Company, this Web service endpoint is accessible at the http://ourservices.example.com/creditCheck address, while internally, this Web service endpoint is accessible at http://extservices.example.com/creditCheck. However, in both cases, the message processing is performed by the same machine, application, code, etc. The Web service endpoint implementation itself is aware of the means by which it is addressed (e.g. is using the URL header of the HTTP messages), and it adjusts message processing appropriately.
In this case, the implementation of the manageability endpoint must be similarly aware of how the Web service endpoint was accessed. Queries regarding the two URL aliases must be accounted for separately, even though the underlying Web service endpoint is the same.
3.2 Manageability at the Web service level
Management applications may want to manage Web services at the granularity level of the endpoint. For example, to find out when an endpoint goes down and how many messages a specific endpoint has processed. At the same time, there are many cases where the management applications may want to manage the Web service as a logical aggregate of all of its endpoints. For example, a business manager using a business dashboard doesn't care whether the purchase orders arrive via the HTTP or the SMTP binding of the order entry Web service, or whether orders arrive via the US server or its European mirror.
In recognition of these requirements, this specification defines manageability of endpoints as the base building block for managing Web services. The specification ensures that information is available to management applications in order to summarize to the Web service-level view. This includes allowing manageable endpoints to establish relationships linking them as part of the same Web service.
3.3 Using manageability of Web services endpoints
The following pattern may be used by the manageability consumers which intend to manage Web services endpoints.
1. Obtain an EPR to the manageability endpoint. One of the following ways may be used.
a. Discover manageable resources as described in the MUWS specifications [MUWS].
b. Exercise the Manageability References capability (section 5.1.1) on the functional Web services endpoint.
c. The functional Web services endpoint may also be the manageability endpoint (section 2.1). Determine that by detecting if the endpoint supports the MUWS Identity capability:
i. Either, obtain the WSDL document describing the manageability endpoint and look for a ResourceId element (see MUWS specification part 1 section 5.1) in the first level children of the resource properties document root [WS-RP].
ii. Or, request the value of the ManageabilityCapability property (see MUWS specification part 1 section 5.2) and look for the URI which identifies the MUWS Identity capability.
2. Using the EPR obtained in the previous step, and based on the manageability capabilities intended to be used, build Web services messages targeted at the manageable Web services endpoint.
a. Obtain the WSDL document describing the manageability endpoint and understand how operations defined by the manageability capabilities are bound.
b. Request the value of the ManageabilityCapability property (see MUWS specification part 1 section 5.2) and look for the URIs which identify the capabilities to be used.
c. To understand how to construct Web services messages for management of a Web services endpoint, consult the manageability capability definition sections in this specification or in the MUWS specification and any dependent specifications thereof.
It is RECOMMENDED that communication between a manageability consumer and a manageability endpoint be secured using the mechanisms described in WS-Security [WSS] and WS-I Basic Security Profile [BSP], including transport-level security such as HTTP over Secure Socket Layers (SSL). In order to properly secure messages, the body and all relevant headers may need to be signed and encrypted.
The following list summarizes common classes of attacks that apply generally to protocols and identifies mechanisms available to prevent/mitigate the attacks:
§ Message alteration – Alteration is prevented by including signatures of the message information using WS-Security.
§ Message disclosure – Confidentiality is preserved by encrypting sensitive data using WS-Security.
§ Key integrity – Key integrity is maintained by using the strongest algorithms possible.
§ Authentication – Authentication is established using the mechanisms described in WS-Security and other related specifications. Each message is authenticated using the mechanisms described in WS-Security.
§ Accountability – Accountability is a function of the type of and strength of the key and algorithms being used. In many cases, a strong symmetric key provides sufficient accountability. However, in some environments, strong PKI signatures are required.
§ Availability – All services are subject to a variety of availability attacks. Replay detection is a common attack and it is RECOMMENDED that this be addressed by the mechanisms described in WS-Security. Other attacks, such as network-level denial of service attacks are harder to avoid and are outside the scope of this specification. That said, care should be taken to ensure that minimal state is saved prior to any authenticating sequences.
The WS-I Basic Security Profile working group has produced a scenarios document which explores these threats in more detail and which identifies security requirements which are then addressed by subsequent profiles [BSP]. WSDM looks to the security domain experts to define the mechanisms to secure web services and looks to WS-I to define interoperability profiles that can be leveraged by WSDM implementers.
4.1 Additional security considerations when managing Web services
It is RECOMMENDED that the implementers of manageability endpoints and manageability consumers take into consideration the following security related concerns.
§ If a manageable Web services endpoint supports messages from both a consumer of a service and a manager of a service section 2.1, it may be important to identify a security model which allows for the appropriate level of granularity with regard to the message origin. For example, setting configuration options may be allowed by a manageability consumer but not an application consumer. When these composed services are deployed, it will be important to understand the authorization model for both management and functional use.
§ In order to make the management systems secure in addition to reliable and accountable (section 2.3), it will be important to follow a set of guidelines and best practices that detail how to compose MOWS with existing security implementations and emerging specifications for authorization and trust.
§ Implementers of this specification may need to give a particular attention to security when implementing the following manageability capabilities.
o Manageability References (section 5.1.1) – this capability allows access to the manageability endpoint references of a functional Web service endpoint. The concern is that visibility to these references may need to be protected differently than visibility of the functional Web service endpoint and its operations.
o Request Processing State (section 5.2.8) – this capability allows managers to subscribe to notifications against request processing by a functional Web service endpoint.
1. Not all managers should be allowed to subscribe to request processing notification because messages may contain protected information, and/or may be used to generate a DoS attack.
2. The request messages may be encrypted and signed. Therefore, managers may need to possess information that allows them to deal with such encrypted and signed messages.
3. Notification messages which contain information about request messages SHOULD be encrypted to avoid spoofing of this information by intercepting notification messages.
4. The request processing notification message provides sufficient flexibility with respect to its content to avoid inclusion of information which needs to be highly protected and therefore not relayed to managers.
The following sections define manageability capabilities for Web services and resources exposed as Web services (see 2.2).
Each capability is described in a UML summary diagram. Metadata is defined for properties, operations and events according to MUWS specification part 1 section 3.4 and part 2 section 2.4 [MUWS].
The definitions of the Web service manageability capabilities are rendered into WSDL elements (interfaces/portTypes) and supporting XML Schemas in Appendix D, and Appendix E, and Appendix F contains renditions of the notification topic spaces for the events defined by the capability specifications.
Following namespace prefixes are used in this document when referring to XML elements and XML schemas. The table below describes what prefix corresponds to which namespace URI.
|
Prefix |
Namespace |
|
muws1 |
http://docs.oasis-open.org/wsdm/muws1-2.xsd |
|
muws2 |
http://docs.oasis-open.org/wsdm/muws2-2.xsd |
|
mows |
http://docs.oasis-open.org/wsdm/mows-2.xsd |
|
mowsw |
http://docs.oasis-open.org/wsdm/mows-2.wsdl |
|
mowse |
http://docs.oasis-open.org/wsdm/mowse-2.xml |
|
wsa |
http://www.w3.org/2005/08/addressing
|
|
wsdl |
http://www.w3.org/2002/07/wsdl
|
|
S |
http://schemas.xmlsoap.org/soap/envelope/
or http://www.w3.org/2002/12/soap-envelope |
|
xs |
http://www.w3.org/2001/XMLSchema |
|
wsrf-rp |
http://docs.oasis-open.org/wsrf/rp-2 |
|
wstop |
http://docs.oasis-open.org/wsn/t-1 |
Unless otherwise specified, XML elements and XML schema types introduced in this specification belong to the namespace mapped to the mows prefix.
5.1 Common manageability capabilities
The following sections define manageability capabilities applicable to Web services and resources exposed as Web services.
5.1.1 Manageability References
This capability is
identified by the following URI:
http://docs.oasis-open.org/mows2/capabilities/ManageabilityReferences
This capability allows a functional/operational Web service or a resource exposed as a Web service (section 2.2) (the service) to provide references to its manageability endpoints. This capability is intended for implementations of functional/operational Web services endpoints. The consumer may exchange messages with the service in order to request references to the manageability endpoints. Using obtained references, the consumer may exchange messages with the manageability endpoints in order to perform management activities to the service.
For example (Figure 5), an application user accesses a Web service endpoint A. The application user then gives the endpoint A reference to the application manager which accesses the Web service endpoint A in order to obtain a reference to the application manageability implementation accessible at the Web service endpoint B. The application manager may now manage the application by exchanging management related messages with endpoint B.
Figure 5. Use of Manageability References capability
The name of this capability identifies its semantics of providing references to manageability endpoints of the service that supports this capability. Within this specification, this capability consists of one operation:
· GetManageabilityReferences.
but applications may associate further operations with this capability.
5.1.1.1 Operations
The following is the specification of the Manageability References capability operations.
5.1.1.1.1 GetManageabilityReferences
This operation is mandatory for implementations of this capability and is defined as the following message exchange.
The request to perform this operation is a message containing the following XML element.
<GetManageabilityReferences/>
GetManageabilityReferences is a Global Element Declaration (GED) which identifies the request of the GetManageabilityReferences operation.
The
wsa:Action MUST contain the URI
http://docs.oasis-open.org/wsdm/mows/GetManageabilityReferences.
The response to the above request is either a fault (any fault) or a message containing the following XML element.
<GetManageabilityReferencesResponse>
<muws1:ManageabilityEndpointReference>
<!-- see [MUWS] -->
</muws1:ManageabilityEndpointReference>+
</GetManageabilityReferencesResponse>
The
wsa:Action MUST contain the URI
http://docs.oasis-open.org/wsdm/mows/GetManageabilityReferencesResponse.
GetManageabilityReferencesResponse is a GED which identifies the response to the requested GetManageabilityReferences operation.
GetManageabilityReferencesResponse/muws1:ManageabilityEndpointReference is a reference to the Web service endpoint which provides access to the management of the functional/operational Web service endpoint or the Web service-enabled resource which responded to the GetManageabilityReferences operation request message.
5.2 Web service endpoint manageability capabilities
The following sections define manageability capabilities applicable to Web service endpoints.
5.2.1 Identity
A WSDM manageable endpoint MUST support the MUWS Identity manageability capability (section 5.1 of the [MUWS] part 1). There are no extensions to the MUWS definition of this capability.
5.2.2 Identification
This capability is identified by the following URI:
http://docs.oasis-open.org/mows-2/capabilities/Identification
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/mows-2/capabilities/Identification</muws2:Capability>
The Web service endpoint's manageable identification capability is represented by the Identification UML model class. The name of this capability identifies its semantics. This capability name and semantics are consistent with the following definition (from the Webster dictionary).
identification: 1 a : an act of identifying : the state of being identified b : evidence of identity
Note that, in contrast, the MUWS Identity capability and semantics are consistent with the following definition (from the Webster dictionary).
identity: 1 a : sameness of essential or generic character in different instances b : sameness in all that constitutes the objective reality of a thing : ONENESS
The identification capability is used to help establish the Web service endpoint being managed. The identity capability may be used to determine if two manageability endpoints provide manageability of the same resource or not.
This capability consists of two properties:
· EndpointReference (mandatory)
· EndpointDescriptions (optional)
· Description (zero to many)
and defines one event: IdentificationCapability,
but applications may associate further properties and events with this capability.
5.2.2.1 Properties
The following is the specification of the Web service endpoint identification properties (i.e. XML elements which represent properties).
<EndpointReference>wsa:EndpointReferenceType</EndpointReference>
<EndpointDescriptions><description>xs:anyURI</description>*</EndpointDescriptions>?
EndpointReference is a reference to the Web service endpoint being managed. A reference must be resolvable to the actual useable endpoint. This property represents one way to access the endpoint resource but doesn't preclude the existence of multiple descriptions of the same endpoint resource. Metadata about this property is as follows.
§ Is not Mutable
§ Is not Modifiable
EndpointDescriptions is a list of URIs pointing to description documents of the Web service endpoint resource. The different description documents can be of the same or of different types (e.g. WSDL1.1, WSDL2.0, UDDI tModel, etc.). Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
5.2.2.2 Events
The following specification defines this capability notification topics in the namespace mapped to the mowse prefix.
<wstop:Topic name="IdentificationCapability" messageTypes="muws1:ManagementEvent"/>
mowse:IdentificationCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
Property change events MUST be wrapped in Management events and published on topics defined in this section.
5.2.3 Metrics
This capability is identified by the following URI:
http://docs.oasis-open.org/mows-2/capabilities/Metrics
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/mows-2/capabilities/Metrics</muws2:Capability>
The name of this capability identifies its semantics of providing properties that are useful in measuring the use and performance of Web services. This capability consists of ten properties:
· NumberOfRequests (optional)
· NumberOfFailedRequests (optional)
· NumberOfSuccessfulRequests (optional)
· ServiceTime (optional)
· MaxResponseTime (optional)
· LastResponseTime (optional)
· MaxRequestSize (optional)
· LastRequestSize (optional)
· MaxResponseSize (optional)
· LastResponseSize (optional)
and defines one event: MetricsCapability,
but applications may associate further properties and events with this capability.
This capability extends the definition of the MUWS Metrics capability. WSDM manageable endpoints that intend to support the MOWS Metrics capability MUST support the MUWS Metrics capability (section 3.4 of the [MUWS] part 2) as well.
It is recommended that for adequate calculations, the Web service endpoint metric properties (one or all) are retrieved together with the muws2:CurrentTime property (e.g., using one request to retrieve multiple properties).
Metrics and request processing states are related. The request processing state change boundaries are the points where metric counters are incremented. These states are defined below, in section 5.2.8.
5.2.3.1 Information markup declarations
The following two XML Schema complex types are defined for metrics that represent integers and durations of time.
<xs:complexType name="IntegerCounter">
<xs:simpleContent>
<xs:extension base="xs:nonNegativeInteger">
<xs:attributeGroup ref="muws2:MetricAttributes"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
(IntegerCounter) type declares an xs:nonNegativeInteger counter metric.
<xs:complexType name="DurationMetric">
<xs:simpleContent>
<xs:extension base="xs:duration">
<xs:attributeGroup ref="muws2:MetricAttributes"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
(DurationMetric) type declares an xs:duration metric.
5.2.3.2 Properties
The following is the specification of the Web service endpoint metrics properties (i.e. XML elements which represent properties).
<NumberOfRequests>IntegerCounter</NumberOfRequests>?
<NumberOfFailedRequests>IntegerCounter</NumberOfFailedRequests>?
<NumberOfSuccessfulRequests>IntegerCounter</NumberOfSuccessfulRequests>?
<ServiceTime>DurationMetric</ServiceTime>?
<MaxResponseTime>DurationMetric</MaxResponseTime>?
<LastResponseTime>DurationMetric</LastResponseTime>?
<MaxRequestSize>IntegerCounter</MaxRequestSize>?
<LastRequestSize>IntegerCounter</LastRequestSize>?
<MaxResponseSize>IntegerCounter</MaxResponseSize>?
<LastResponseSize>IntegerCounter</LastResponseSize>?
NumberOfRequests is a counter of the number of request messages that the Web service endpoint has received. This counter is incremented by 1 whenever a request reaches the Received state according to the Request Processing Model (Figure 6). Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:ChangeType>Counter</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
NumberOfFailedRequests is a counter of the number of request messages that the Web service endpoint has received, and a (SOAP) fault was sent in reply. This counter is incremented by 1 whenever a request reaches the Failed state according to the Request Processing Model (Figure 6). Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:ChangeType>Counter</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
NumberOfSuccessfulRequests is a counter of the number of request messages that the Web service endpoint has received, and anything but a (SOAP) fault was sent in reply. This counter is incremented by 1 whenever a request reaches the Completed state according to the Request Processing Model (Figure 6). Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:ChangeType>Counter</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
Note that NumberOfSuccessfulRequests + NumberOfFailedRequests ≤ NumberOfRequests as there could possibly be some requests that were received, but lost or still being processed.
ServiceTime is a counter of the total elapsed time that the Web service endpoint has taken to process all requests (successfully or not). Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:ChangeType>Counter</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
MaxResponseTime is a gauge indicating the maximum time duration between all requests received and their completion or failure. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:ChangeType>Gauge</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
LastResponseTime is a gauge indicating the last recorded time duration between the last request received and its completion or failure. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:ChangeType>Gauge</muws2:ChangeType>
§ <muws2:TimeScope>PointInTime</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
MaxRequestSize is a gauge indicating the maximum size in bytes for all requests received regardless of their completion or failure. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:Units>byte</muws:Units>
§ <muws2:ChangeType>Gauge</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
LastRequestSize is a gauge indicating the last request size in bytes for the last request received regardless of the completion or failure of the request. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:Units>byte</muws:Units>
§ <muws2:ChangeType>Gauge</muws2:ChangeType>
§ <muws2:TimeScope>PointInTime</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
MaxResponseSize is a gauge indicating the maximum response size in bytes for all responses sent regardless of their completion or failure. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:Units>byte</muws:Units>
§ <muws2:ChangeType>Gauge</muws2:ChangeType>
§ <muws2:TimeScope>SinceReset</muws2:TimeScope> or <muws2:TimeScope>Interval</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
LastResponseSize is a gauge indicating the size of the last response in bytes sent regardless of the completion or failure of the request. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
§ <muws2:Units>byte</muws:Units>
§ <muws2:ChangeType>Gauge</muws2:ChangeType>
§ <muws2:TimeScope>PointInTime</muws2:TimeScope>
§ <muws2:GatheringTime>OnChange</muws2:GatheringTime>
Note that if a metric property has a <muws2:TimeScope>SinceReset</muws2:TimeScope> metadata value, the muws2:ResetAt attribute MUST be reported on the property element and the muws2:Duration attribute MUST NOT be reported. If a metric property has a <muws2:TimeScope>Interval</muws2:TimeScope> metadata value, the muws2:ResetAt attribute MAY be reported on the property element and the muws2:Duration attribute MUST be reported.
Also note that in this specification, counters are not just monotonically increasing variables, but also represent a cumulative metric of some kind e.g. number of requests over time. Gauges, on the other hand, do not represent a cumulative metric, but rather discrete values of some kind at a particular time (e.g. response time).
5.2.3.3 Events
The following specification defines this capability notification topics in the namespace mapped to the mowse prefix.
<wstop:Topic name="MetricsCapability" messageTypes="muws1:ManagementEvent"/>
mowse:MetricsCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
Property change events MUST be wrapped in Management events and published on topics defined in this section.
5.2.4 Operation Metrics
This capability is
identified by the following URI:
http://docs.oasis-open.org/wsdm/mows-2/capabilities/OperationMetrics
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/wsdm/mows-2/capabilities/OperationMetrics</muws2:Capability>
The name of this capability identifies its semantics of providing MOWS metrics at an operational level. This capability applies MOWS metrics to operations within the managed Web service. It consists of multiply occurring complex properties, each complex property represents an operation of the service that may be characterized with MOWS metrics (see section 5.2.3.2):
· OperationMetrics (many)
· NumberOfRequests (optional)
· NumberOfFailedRequests (optional)
· NumberOfSuccessfulRequests (optional)
· ServiceTime (optional)
· MaxResponseTime (optional)
· LastResponseTime (optional)
· MaxRequestSize (optional)
· LastRequestSize (optional)
· MaxResponseSize (optional)
· LastResponseSize (optional)
and defines one event: OperationMetricsCapability,
but applications may associate further properties and events with this capability.
WSDM manageable endpoints that intend to support the MOWS Operation Metrics capability MUST support the MUWS Metrics capability (section 3.4 of the [MUWS] part 2) as well. It is expected that support of the Operation Metrics capability will usually be done in addition to the MOWS Metrics capability, but this is not a requirement.
It is recommended that for adequate calculations, the Web service operation metric properties (one or all) are retrieved together with the muws2:CurrentTime property.
5.2.4.1 Properties
The following is the specification of the Web service endpoint operation metrics complex property (i.e. XML element that represents the metrics of an operation).
<OperationMetrics operationName="xs:NCName", portType="xs:QName"? …>*
<NumberOfRequests>IntegerCounter</NumberOfRequests>?
<NumberOfFailedRequests>IntegerCounter</NumberOfFailedRequests>?
<NumberOfSuccessfulRequests>IntegerCounter</NumberOfSuccessfulRequests>?
<ServiceTime>DurationMetric</ServiceTime>?
<MaxResponseTime>DurationMetric</MaxResponseTime>?
<LastResponseTime>DurationMetric</LastResponseTime> ?
<MaxRequestSize>IntegerCounter</MaxRequestSize>?
<LastRequestSize>IntegerCounter</LastRequestSize>?
<MaxResponseSize>IntegerCounter</MaxResponseSize>?
<LastResponseSize>IntegerCounter</LastResponseSize>?
{any} *
</OperationMetrics>
OperationMetrics is the group property that contains the metrics for one operation within the managed Web service. The operation to which the metrics apply is identified by the attributes of this element.
OperationMetrics/@operationName is the name of operation to which the metrics apply. This is a required attribute. The value of this attribute is the name of the operation as it is specified in the portType of the Web service
OperationMetrics/@portType is the QName of the portType in which the operation occurs. This is an optional attribute. The value of this attribute is the QName of the portType as it is specified in the WSDL of the Web service.
The metrics contained within the OperationMetrics complex property are the MOWS metrics defined in section 5.2.3.2.
5.2.4.2 Events
The following specification defines the capability notification topics in the namespace mapped to the mowse prefix.
<wstop:Topic name="OperationMetricsCapability" messageTypes="muws1:ManagementEvent"/>
mowse:OperationMetricsCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
5.2.5 Operational State
This capability is identified by the following URI:
http://docs.oasis-open.org/mows-2/capabilities/OperationalState
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/mows-2/capabilities/OperationalState</muws2:Capability>
The name of this capability identifies its semantics of providing information on the operational state of a managed Web service. This capability consists of two properties:
· CurrentOperationalState (mandatory)
· LastOperationStateTransition (zero to many)
and defines one event: OperationalStateCapability,
but applications may associate further properties and events with this capability.
The operational state model of a Web service endpoint used in this specification is the Web service lifecycle (WSLC) state model as defined by the W3C Web Services Architecture Management Task Force [WSLC]. Definition of the operational state in this specification uses the transition paths for the service itself defined by the WSLC.
5.2.5.1 Information markup declarations
Each state MUST be identified by a QName and represented by a corresponding XML element. Following is a list of elements corresponding to the operational states of the Web service endpoint operation according to the WSLC state model [WSLC].
§
UpState
This element corresponds to the
WSLC UP top-level state which means that the Web service endpoint operation is capable of accepting new requests.
This state is the parent state of the BUSY and IDLE substates, as defined
below.
§
DownState
This element corresponds to the
WSLC DOWN top-level state which means that the Web service endpoint operation is not capable of accepting new
requests. This state is the parent state of the STOPPED, CRASHED, and SATURATED
substates, as defined below.
§
BusyState
This element corresponds to the
WSLC BUSY substate of UP which means that the Web service endpoint operation is capable of accepting new requests
during processing of other requests. This element MUST contain the UpState
element.
§
IdleState
This element corresponds to the
WSLC IDLE substate of UP which means that the Web service endpoint operation is capable of accepting new requests and
is not processing any other requests. This element MUST contain the UpState
element.
§
StoppedState
This element corresponds to the
WSLC STOPPED substate of DOWN which means that the Web service endpoint operation is not capable of accepting new requests
and was intentionally stopped by an administrator. This element MUST contain
the DownState element.
§
CrashedState
This element corresponds to the
WSLC CRASHED substate of DOWN which means that the Web service endpoint operation is not capable of accepting new requests
as a result of some internal failure. This element MUST contain the DownState
element
§
SaturatedState
This element corresponds to the
WSLC SATURATED substate of DOWN which means that the Web service endpoint operation is not capable
of accepting new requests due to lack of resources. This element MUST contain
the DownState element.
It is possible to extend the above state model. Substates MAY be introduced and MUST be identified by QNames, however, new top-level operational states MUST NOT be defined. In order to represent the taxonomy lineage of substates in XML, the MUWS approach is used (section 3.2 in the [MUWS] part 2).
The OperationalStateType XML Schema type is declared as follows.
<xs:complexType name=”OperationalStateType”>
<xs:complexContent>
<xs:extension base=”muws2:StateType”/>
</xs:complexContent>
</xs:complexType>
The OperationalStateType is used to declare elements which contain any valid elements designating an operational state of a Web service endpoint.
§ A substate of the operational state MUST be declared according to the following rules.
o An XML element is declared with a QName which identifies the desired substate semantics, for example my-app:DatabaseCleanupState
o The contents of the XML element MUST be the only element which corresponds to the generalized state, for example mows:StoppedState
An instance of the request processing state information represented in XML may look as shown in the following example,
<my:OperationalStateInformationElement xsi:type=”mows:OperationalStateType”>
<my-app:DatabaseCleanupState>
<mows:StoppedState>
<mows:DownState/>
</mows:StoppedState>
</my-app:DatabaseCleanupState>
</my:RequestProcessingStateInformationElement>
5.2.5.2 Properties
The following is the specification of the Web service endpoint operational state properties (i.e. the XML elements which represent the state properties).
<CurrentOperationalState>mows:OperationalStateType</CurrentOperationalState>
<LastOperationalStateTransition>
muws2:StateTransitionType
</LastOperationalStateTransition> ?
CurrentOperationalState is the current operational state of the Web service endpoint being managed. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
LastOperationalStateTransition contains information about last operational state transition which occurred at the Web service endpoint being managed. Metadata about this property is as follows.
§ Is Mutable
§ Is not Modifiable
5.2.5.3 Events
The following specification defines this capability notification topics in the namespace mapped to the mowse prefix.
<wstop:Topic name="OperationalStateCapability" messageTypes="muws1:ManagementEvent"/>
mowse:OperationalStateCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
For information about changes of the operational state, a consumer MUST subscribe to notifications on the changes of the CurrentOperationalState property (assuming that the manageability endpoint implementation supports notifications about changes of this property). Refer to [WS-RP] for information on how to subscribe to the property change notifications.
5.2.6 Operational Status
This capability is identified by the following URI:
http://docs.oasis-open.org/mows-2/capabilities/OperationalStatus
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/mows-2/capabilities/OperationalStatus</muws2:Capability>
The name of this capability indicates its semantics of indicating the operational status of a managed Web Service. This capability consists of one property:
· OperationalStatus (mandatory), as defined in the MUWS part 2 OperationalStatus capability
and defines one event: OperationalStatusCapability,
but applications may associate further properties and events with this capability.
WSDM manageable endpoints that intend to support the MUWS Operational Status manageability capability (section 3.3 in the [MUWS] part 2) MUST abide by the following mapping rules. When this capability support is indicated for a manageable endpoint, the mappings are in effect.
The Web service lifecycle (WSLC) states defined by the W3C Web Services Architecture Management Task Force [WSLC] map to the MUWS status values as follows:
§ The WSLC UP state MUST be reported as the Available contents of the muws2:OperationalStatus property. Any sub-state of WSLC UP MUST be reported as Available.
§ The WSLC DOWN state MUST be reported as the Unavailable contents of the muws2:OperationalStatus property. Any sub-state of WSLC DOWN SHOULD be reported as Unavailable. The STOPPED and CRASHED substates of WSLC DOWN MUST be reported as Unavailable.
§ The WSLC SATURATED sub-state of DOWN MAY be reported as the PartiallyAvailable contents of the muws2:OperationalStatus property.
5.2.6.1 Events
The following specification defines this capability notification topics in the namespace mapped to the mowse prefix.
<wstop:Topic name="OperationalStatusCapability" messageTypes="muws1:ManagementEvent"/>
mowse:OperationalStatusCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
Property change events MUST be wrapped in Management events and published on topics defined in this section.
5.2.7 Operation Operational Status
This capability is identified by the following URI:
http://docs.oasis-open.org/wsdm/mows-2/capabilities/OperationOperationalStatus
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/wsdm/mows-2/capabilities/OperationOperationalStatus</muws2:Capability>
An operation operational status property reflects whether a named operation is available, unavailable, or degraded. Operation operational status does not conform to a specific state model. Operation operational status is related to the Request Processing Model of the [WSLC], see Figure 6, but does not directly map to request processing states. The manageable resource provides the appropriate mapping from request states to the status of an operation and sets the OperationOperationalStatus property accordingly (see below).
The name of this capability identifies its semantics indicating the operational status of an operation within a managed Web service. For each operation, there is one complex property that provides the OperationStatus of that operation:
· OperationOperationalStatus (many)
· OperationStatus, as defined in section 5.2.6
and the capability defines one event: OperationOperationalStatusCapability
but applications may associate further properties and events with this capability.
5.2.7.1 Properties
The following is the specification of the Web service endpoint operation operational status complex property (i.e. XML element that represents the operational status of an operation).
<OperationOperationalStatus operationName="xs:NCName", portType="xs:QName"? …>*
<muws2:OperationalStatus>
(Available|PartiallyAvailable|Unavailable|Unknown)
</muws2:OperationalStatus>
{any} *
</OperationOperationStatus>
OperationOperationalStatus is the complex property representing each operation for which operational status information can be provided.
OperationOperationalStatus/@operationName is the name of operation to which the operational status applies. This is a required attribute. The value of this attribute is the name of the operation as it is specified in the portType of the Web service
OperationOperationalStatus/@portType is the QName of the portType in which the operation occurs. This is an optional attribute. The value of this attribute is the name of the portType as it is specified in the WSDL of the Web service.
OperationOperationalStatus/muws2:OperationalStatus is the operational status property that is defined in MUWS Part 2 and used as well in the MOWS OperationStatus capability; see section 5.2.6. The valid values of this property with their intended interpretation in this context are:
· Available: This value indicates that the named operation is operating normally within any configured operating parameters, and is able to perform its function. It is capable or receiving requests and completing processing.
· PartiallyAvailable: This value indicates that the named operation is operating, but outside of configured operating parameters. An operation reporting this operation operational status is able to complete some requests but may fail others. For example, an operation may be failing only for a subset of requests because of database table required by only that subset is locked.
· Unavailable: This value indicates that the named operation is not operating, and is not able to perform any functional tasks. The operation may be unable to received requests and it may be failing all requests.
· Unknown: This value indicates that the named operation is unable to report status at this time.
5.2.7.2 Events
The following specification defines this capability notification topics in the namespace mapped to the mowse prefix.
<wstop:Topic name="OperationOperationalStatusCapability" messageTypes="muws1:ManagementEvent"/>
mowse:OperationOperationalStatusCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
Property change events MUST be wrapped in Management events and published on topics defined in this section.
5.2.8 Request Processing State
This capability is identified by the following URI:
http://docs.oasis-open.org/mows-2/capabilities/RequestProcessingState
All properties, operations and events defined for this capability have the following metadata:
§ <muws2:Capability>http://docs.oasis-open.org/mows-2/capabilities/RequestProcessingState</muws2:Capability>
The name of this capability identifies its semantics of providing information on the processing state of a request to a managed Web service. This capability consists of no properties but defines 12 events:
· RequestProcessingObservations
· RequestProcessingObservations/RequestReceived
· RequestProcessingObservations/RequestProcessing
· RequestProcessingObservations/RequestComplete
· RequestProcessingObservations/RequestFailed
· RequestProcessingObservations/Digest
· RequestProcessingObservationsWithAttachments
· RequestProcessingObservationsWithAttachments/RequestReceived
· RequestProcessingObservationsWithAttachments/RequestProcessing
· RequestProcessingObservationsWithAttachments/RequestComplete
· RequestProcessingObservationsWithAttachments/RequestFailed
· RequestProcessingObservationsWithAttachment/Digest
but applications may associate further properties and events with this capability.
By the definition, a Web service endpoint accepts and processes messages targeted at it – requests. Every request goes through a number of states (e.g. received, processing, completed or failed) as defined by the [WSLC] and extended here.
Figure 6. Request processing states
The state diagram represents a model in which states MAY have duration and transitions are instantaneous. When extending this model one MUST extend only the Processing compound state.
5.2.8.1 Information markup declarations
Each state MUST be identified by a QName and represented by a corresponding XML element. Following is a list of elements corresponding to the top-level states of the request processing state model (Figure 6).
§
RequestReceivedState
This element corresponds to the Received top-level state which means that the Web service endpoint has accepted a request to perform one of the service's functional responsibilities. This state represents the earliest point at which the manageability provider knows that the request was dispatched to the Web service endpoint being managed.
§
RequestProcessingState
This element corresponds to the Processing top-level state which means that the Web service endpoint is doing some internal processing/execution to fulfill the requested function. This state represents the earliest point at which the application module or business logic begins processing the request. For example, if the application server queues the request before dispatching it to the business logic, the time difference between “request received” and “processing” will include the duration the request was queued.
§
RequestCompletedState
This element corresponds to the Completed top-level state which means that the Web service endpoint successfully completed requested function returning results to the requester.
§
RequestFailedState
This element corresponds to the Failed top-level state which means that the Web service endpoint encountered an error and didn't complete the requested function, returning error/fault to the requester.
It is possible to extend the above state model. Substates of the Processing top-level state MAY be introduced and MUST be identified by QNames, however, new top-level request processing states MUST NOT be defined. In order to represent the taxonomy lineage of substates in XML, the MUWS approach is used (section 3.2 in the [MUWS] part 2).
The RequestProcessingStateType XML Schema type is declared as follows.
<xs:complexType name=”RequestProcessingStateType”>
<xs:complexContent>
<xs:extension base=”muws2:StateType”/>
</xs:complexContent>
</xs:complexType>
The RequestProcessingStateType is used to declare elements which designate a request processing state – top-level or substates of the Processing.
A substate of the Processing compound state MUST be declared according to the following rules.
An XML element is declared with a QName which identifies the desired substate semantics, for example my-soap:SerializationState
The contents of the XML element MUST be the only element which corresponds to the generalized state, for example muws2:RequestProcessingState
An instance of the request processing state information represented in XML may appear as shown in the following example,
<my:RequestProcessingStateInformationElement xsi:type=”mows:RequestProcessingStateType”>
<my-soap:SerializationState>
<mows:RequestProcessingState/>
</my-soap:SerializationState>
</my:RequestProcessingStateInformationElement>
5.2.8.2 Events
Notifications are emitted when requests enter one of the request processing states (Figure 6).
Property change events MUST be wrapped in Management events and published on topics defined in this section.
The following specification defines the Web service endpoint request processing state notification topics in the namespace mapped to the mowse prefix. The message patterns’ expression and dialect MUST match precisely what is declared below.
<wstop:Topic name="RequestProcessingStateCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="RequestProcessingObservations"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
<wstop:Topic name="RequestReceived"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestProcessing"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestCompleted"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestFailed"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="Digest"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
<wstop:Topic name="RequestProcessingObservationsWithAttachments"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
<wstop:Topic name="RequestReceived"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestProcessing"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestCompleted"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestFailed"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="Digest"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
mowse:RequestProcessingStateCapability is a topic on which management events related to this manageability capability SHOULD be emitted.
mowse:ManageableEndpoint/mowse:RequestProcessingObservations indicates availability of any information about the processing of any request by the Web service endpoint (Figure 6) as observed by the implementation of a manageable Web service.
The notification message for this topic MUST contain at most one RequestProcessingNotification element (defined in section 5.2.8.2.1). The MUWS management event MUST also declare the event situation category with the muws2:ReportSituation element and the severity value “1” (Informational). It is recommended to subscribe to these topics with proper preconditions and selectors using expressions against the contents of the RequestProcessingNotification element.
mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:RequestReceived indicates that a request was received by the Web service endpoint being managed (Received state in Figure 6). The notification message format for this topic is the same as the notification message format for the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic. This is a state change event and therefore notification messages MUST contain exactly one muws2:StateTransition element inside of the RequestProcessingNotification/StateInformation element.
mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:RequestProcessing indicates that a request is being processed by the Web service endpoint being managed (Processing state in Figure 6). The notification message format for this topic is the same as the notification message format for the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic. This is a state change event and therefore notification messages MUST contain exactly one muws2:StateTransition element inside of the RequestProcessingNotification/StateInformation element.
mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:RequestCompleted indicates that a request was successfully completed by the Web service endpoint being managed (Completed state in Figure 6). The notification message format for this topic is the same as the notification message format for the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic. This is a state change event and therefore notification messages MUST contain exactly one muws2:StateTransition element inside of the RequestProcessingNotification/StateInformation element.
mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:RequestFailed indicates that a request was failed (not successfully completed) by the Web service endpoint being managed (Failed state in Figure 6). The notification message format for this topic is the same as the notification message format for the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic. This is a state change event and therefore notification messages MUST contain exactly one muws2:StateTransition element inside of the RequestProcessingNotification/StateInformation element.
mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:Digest indicates availability of summary information about a request processed by the Web service endpoint being managed. The notification message format for this topic is the same as the notification message format for the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic. This is a digest event and therefore notification messages MUST contain one or more muws2:StateTransition elements inside of the RequestProcessingNotification/StateInformation element. Each muws2:StateTransition element describes a state transition which occurred with that one request which this summary notification is informing about. Each state transition information element carries an attribute indicating the time when that particular transition occurred. Using this information the manageability consumer can reconstruct the sequence of events with regards to the request.
mowse:ManageableEndpoint/mowse:RequestProcessingObservationsWithAttachments topic and all of its subtopics are defined exactly as the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic and its respective subtopics, except that the notification messages MUST include attachments (if any) of the request and reply messages sent to/from the Web service endpoint being managed.
The notification message format for this topic and all of its subtopics is the same as the notification message format for the mowse:ManageableEndpoint/mowse:RequestProcessingObservations topic, except that attachments may be sent along with the message. The precise mechanism of sending the attachment is dependent on 1) the binding of the notification consumer Web service endpoint [WS-N] and 2) the binding of the Web service endpoint being managed.
The
mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:
RequestProcessing topic MAY be extended with custom subtopics in order to
represent custom request processing substates of the Processing compound state
(Figure 6).
Note that the result of the message pattern XPath expressions in the topic declarations above is the XML nodeset [XPath] of the notification messages that are sent inside of the S:Body element or the wsnt:Notify element [WS-N].
Note that for the XPath expressions defined here the prefix-to-namespace mapping context MUST include all prefixes which appear in the XPath expression and mapped according to the table in the section 5.
5.2.8.2.1 RequestProcessingNotification message
The RequestProcessingNotification message format is defined as follows.
<RequestProcessingNotification CurrentTime=”xs:dateTime” …>
<Request …>
<TransportInformation …> {any}* </TransportInformation> ?
<Message …>
<Size Unit=(“bit” | “byte” | “word” | “dword” | “qword”)
…>xs:positiveInteger</Size> ?
(
<NotIncluded/> |
<Text>xs:string</Text> |
<Binary>xs:base64Binary</Binary> |
<Xml>{any}*</Xml>
)
{any}*
</Message>
{any}*
</Request> ?
<Reply …>
<!-- … see contents of the Request element above … -->
</Reply> ?
<StateInformation>
<muws2:StateTransition> <!-- …see [MUWS]… --> </muws2:StateTransition> +
</StateInformation>
{any}*
</RequestProcessingNotification>
RequestProcessingNotification is a container element of the information about a request going through the request processing states (Figure 6).
RequestProcessingNotification/@CurrentTime indicates current time measured at the manageability endpoint. All time/date values in this notification information are synchronized with this time indication.
RequestProcessingNotification/Request element contains information about the request itself. Note that the request is not necessarily serialized as a SOAP message. Therefore, the contents allow information about requests in general, however the information has to be serializeable in XML [XML]. The presence of this element in the notification MUST indicate presence of the actual request message sent to the Web service endpoint being managed. The contents may vary depending on what the implementation of the manageability endpoint can or intends to provide. For example, for security reasons the actual contents of the message may be omitted. However, in order to indicate that the request message exists, this element has to be included in the notification.
RequestProcessingNotification/Request/TransportInformation element contains information about the transport by which the request was received. The content of this element is open, but WSDM defines the following elements useable for TCP/IP transports.
<TcpIpInfo
Direction=(“from” | “to”)
Port=”xs:positiveInteger”
Protocol=(“TCP” | “UDP”) …>
(
<IPV4Address>
xs:hexBinary[xs:length[@value=”8” and @fixed=”true”]]
</IPV4Address> |
<IPV6Address>
xs:hexBinary[xs:length[@value=”32” and
@fixed=”true”]]
</IPV6Address>
)
{any}*
</TcpIpInfo>
TcpIpInfo contains information about a communication to or from an IP addressable network device.
TcpIpInfo/@Direction indicates communication to or from the IP addressable network device.
TcpIpInfo/@Port is a TCP/IP network port number used on the IP addressable network device.
TcpIpInfo/@Protocol indicates if the TCP or UDP protocol is used.
TcpIpInfo/IPV4Address contains hexadecimal representation of the IP address version 4. The value MUST represent 32 bits.
TcpIpInfo/IPV6Address contains hexadecimal representation of the IP address version 6. The value MUST represent 128 bits.
RequestProcessingNotification/Request/Message element contains the message observed by the Web service endpoint being managed.
RequestProcessingNotification/Request/Message/Size indicates size of the message. When subscribed to observations with attachments, this value includes the size of the message payload plus all the attachments. Otherwise, just the payload of the message (i.e. size of the contents of the RequestProcessingNotification/Request/Message element) is reported. Note that the actual message contents may not be reported for security reasons, however size may be reported.
RequestProcessingNotification/Request/Message/Size/@Unit indicates what units were used to calculate the size of the message. The valid values of this attribute are:
bit – size indicates number of bits in the message.
byte – size indicates number of bytes (8 bit sets) in the message
word – size indicates number of double bytes (16 bit sets) in the message.
dword – size indicates number of double words (32 bit sets) in the message.
qword – size indicates number of quad words (64 bit sets) in the message.
RequestProcessingNotification/Request/Message/NotIncluded element indicates that the message content is intentionally not provided by the implementation of the Web service endpoint manageability.
RequestProcessingNotification/Request/Message/Text element contains the observed message’s text representation. For example, a non-well formed XML message should be represented as text. It is recommended that text data is wrapped in an XML CDATA section [XML].
RequestProcessingNotification/Request/Message/Binary element contains the binary representation of the observed message. If a message cannot be represented as either well-formed XML nor as text, it should be binary encoded.
RequestProcessingNotification/Request/Message/Xml element contains the observed message’s XML representation. For example, a SOAP message envelope element (S:Envelope) may appear in the contents.
RequestProcessingNotification/Request/{any} is an extensibility element where additional information about the request MAY appear. The form of the information representation in XML is manageability endpoint implementation specific. In other words, vendor extensions may appear here.
The RequestProcessingNotification/Reply element contains information about the reply (if any) for the request. Note that fault is also a valid reply element. The content of this element has the same format as the RequestProcessingNotification/Request element.
RequestProcessingNotification/StateInformation element contains information about the request processing state.
RequestProcessingNotification/StateInformation/muws2:StateTransition element contains information about a state transition. There MUST be exactly one such element for each state change event. There MUST be one or more such elements for the digest event.
RequestProcessingNotification/StateInformation/muws2:StateTransition/@muws2:Time indicates time when the described transition occurred. Note that according to the request processing state model (Figure 6), all transitions are instantaneous. Time is measured at the implementation of the manageability endpoint and is synchronized with the RequestProcessingNotification/@CurrentTime value reading.
RequestProcessingNotification/StateInformation/muws2:StateTransition/muws2:EnteredState indicates which request processing state was entered.
RequestProcessingNotification/StateInformation/muws2:StateTransition/muws2:PreviousState indicates which request processing state was exited.
RequestProcessingNotification/{any} is an extensibility element where additional information about this request processing notification MAY appear. The form of the information representation in XML is manageability endpoint implementation specific. In other words, vendor extensions may appear here.
The contents of the RequestProcessingNotification element SHOULD be used to specify selectors [WS-N] when subscribing to notification messages containing this element.
5.2.8.2.2 Examples of events against the Web service endpoint request processing state
Consider the following message exchange with a fictitious order-entry Web service endpoint.
Request:
<S:Envelope xmlns:x=”…” … >
. . .
<S:Body>
<x:Order>
<x:Item>…</x:Item>
<x:Quantity>…</x:Quantity>
</x:Order>
</S:Body>
</S:Envelope>
Reply:
<S:Envelope xmlns:x=”…” … >
. . .
<S:Body>
<x:Shipped>
<x:Item>…</x:Item>
<x:Quantity>…</x:Quantity>
</x:Shipped>
</S:Body>
</S:Envelope>
To be notified of a particular item shortage when the order request is processed and the shipped quantity is less than the ordered quantity, the following XPath selector should be specified when subscribing to the mowse:ManageableEndpoint/mowse:RequestProcessingObservations/mowse:RequestCompleted topic.
Selector:
boolean(//mows:RequestProcessingNotification[mows:Request/mows:Message/mows:Xml//x:Order/x:Quantity < mows:Reply/mows:Message/mows:Xml//x:Shipped/x:Quantity)
This way, when the condition is met, the manageable Web service endpoint will emit the notification message containing the RequestProcessingNotification element with the following contents.
<RequestProcessingNotification CurrentTime=”…”>
<Request>
<TransportInformation>
<TcpIpInfo Direction=”from” Port=”2840” Protocol=”TCP”>
<IPV4Address>C0A80002</IPV4Address>
</TcpIpInfo>
<TcpIpInfo Direction=”to” Port=”80” Protocol=”TCP”>
<IPV4Address>C0A80003</IPV4Address>
</TcpIpInfo>
</TransportInformation>
<Message>
<Size Unit=”byte”>257</Size>
<Xml>
<S:Envelope xmlns:S=”…” xmlns:x=”…” …>
. . .
<S:Body>
<x:Order>
<x:Item>123</x:Item>
<x:Quantity>10</x:Quantity>
</x:Order>
</S:Body>
</S:Envelope>
</Xml>
</Message>
</Request>
<Reply>
<TransportInformation>
<TcpIpInfo Direction=”to” Port=”2840” Protocol=”TCP”>
<IPV4Address>C0A80002</IPV4Address>
</TcpIpInfo>
<TcpIpInfo Direction=”from” Port=”80” Protocol=”TCP”>
<IPV4Address>C0A80003</IPV4Address>
</TcpIpInfo>
</TransportInformation>
<Message>
<Size Unit=”byte”>232</Size>
<Xml>
<S:Envelope xmlns:S=”…” xmlns:x=”…” …>
. . .
<S:Body>
<x:Shipped>
<x:Item>123</x:Item>
<x:Quantity>2</x:Quantity>
</x:Shipped>
</S:Body>
</S:Envelope>
</Xml>
</Message>
</Reply>
<muws2:StateTransition Time=”…”>
<muws2:EnteredState/><RequestCompletedState/></muws2:EnteredState>
<muws2:PreviousState><RequestProcessingState/></muws2:PreviousState>
</muws2:StateTransition>
. . .
</RequestProcessingNotification>
6.1 Normative
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[MUWS] V.
Bullard, et al., Web Services Distributed Management:Management using Web
Services (MUWS 1.1) Part 1, http://docs.oasis-open.org/wsdm/wsdm-muws1-1.1-os-01.pdf
V. Bullard, et al., Web Services Distributed Management:Management using Web
Services (MUWS 1.1) Part 2, http://docs.oasis-open.org/wsdm/wsdm-muws2-1.1-os-01.pdf
[WS-A] Don Box, et al., Web services Addressing (WS-Addressing), http://www.w3.org/TR/ws-addr-core
[WS-RP] Steve Graham, et al., Web Services Resource Properties 1.2 (WS-ResourceProperties), http://docs.oasis-open.org/wsrf/wsrf-ws_resource_properties-1.2-spec-os-01.pdf
[WS-N] Steve Graham, et al., Web Services Base Notification 1.2
(WS-BaseNotification), http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-pr-03.pdf
[WS-T] William Vambenepe, Web Services Topics 1.2 (WS-Topics), http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-pr-02.pdf
[WSDL] Erik Christensen, et al., Web services Description Language (WSDL) 1.1, W3C Note, March 2001, http://www.w3.org/TR/wsdl
[SOAP] Don Box, et al., Simple Object Access Protocol 1.1, W3C Note, May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[XMLS] Henry S. Thompson, et al. XML
Schema Part 1: Structures, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/
Paul V. Biron, et al. XML
Schema Part 2: Datatypes, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-2/
[XML] Tim Bray, et al., Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, February 2004, http://www.w3.org/TR/REC-xml
[XNS] Tim Bray, et al., Namespaces in XML, W3C Recommendation, January 1999, http://www.w3.org/TR/REC-xml-names/
[XPath] James Clark, et
al., XML Path Language (XPath) Version 1.0, W3C Recommendation, November
1999, http://www.w3.org/TR/1999/REC-xpath-19991116
6.2 Non-normative
[MOWS-Reqs] Mark Potts, et al., WSDM Management of Web Services Requirements, October 2003, http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/3887/WSDM-MOWS-Requirements.20031008.doc
[WS-Arch] David Booth, et al. Web Services Architecture, W3C Working Group Note, February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
[WSLC] Hao He, et al., Web Service Management: Service Lifecycle, W3C Note, February 2004, http://www.w3.org/TR/2004/NOTE-wslc-20040211/
[WSS] Anthony
Nadalin, et al., Web Services Security: SOAP Message Security 1.0
(WS-Security 2004), March 2004, OASIS Standard, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[BSP] Abbie
Barbir, et al., Basic Security Profile Version 1.0, WS-I Working Group
Draft, May 2004, http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html
The following people made contributions to the WSDM MOWS Version 1.1 specification: Brian Carroll, Fred Carter, John DeCarlo, Andreas Dharmawan, Maryann Hondo, Heather Kreger, Bryan Murray, Michael Perks, Igor Sedukhin, William Vambenepe, Andrea Westerinen.
The following individuals were members of the committee when the specification 1.0 version was approved by the technical committee: Guru Bhat, Jeff Bohren, Winston Bumpus, Nick Butler, Brian Carroll, Fred Carter, Michael Clements, David Cox, John DeCarlo, Andreas Dharmawan, Mark Ellison, John Fuller, Paul Lipton, Heather Kreger, Hal Lockhart, Frederico Maciel, Tom Maguire, Bryan Murray, Richard Nikula, Mark Peel, Richard Pelavin, Homayoun Pourheidari, Warren Roberts, Karl Schopmeyer, Igor Sedukhin, David Snelling, Thomas Studwell, William Vambenepe, Andrea Westerinen, Jim Willits, Zhili Zhang.
The following people made contributions to the WSDM MOWS Version 1.1 specification: Barry Atkins, Vaughn Bullard, Fred Carter, David Cox, Mark Ellison, Heather Kreger, Fred Maciel, Bryan Murray, Kirk Wilson with special thanks to Kirk Wilson and Mark Ellison as editors.
The following individuals were members of the committee while the specification 1.1 version was developed and approved by the technical committee: Guru Bhat, Jeff Bohren, Vaughn Bullard, Winston Bumpus, Fred Carter, Michael Clements, David Cox, Zulah Eckert, Mark Ellison, John Fuller, Tony Gullotta, Heather Kreger, Richard Landau, Frederico Maciel, Tom Maguire, David Melgar, Bryan Murray, Richard Nikula, Mark Peel, Mitsunori Satomi, Thomas Studwell, William Vambenepe, Kirk Wilson, Zhili Zhang.
|
Rev |
Date |
By Whom |
|
|
wd |
2003-10-31 |
Igor Sedukhin |
|
|
wd |
2003-11-14 |
Igor Sedukhin |
|
|
wd |
2003-12-02 |
Igor Sedukhin |
|
|
wd |
2004-01-26 |
Igor Sedukhin |
|
|
wd |
2004-02-17 |
Igor Sedukhin |
|
|
wd |
2004-03-01 |
Igor Sedukhin |
|
|
wd |
2004-03-18 |
Igor Sedukhin |
|
|
wd |
2004-03-19 |
Igor Sedukhin |
|
|
wd |
2004-03-24 |
Igor Sedukhin |
|
|
wd |
2004-03-24 |
Igor Sedukhin |
|
|
cd |
2004-04-02 |
Igor Sedukhin |
|
|
wd |
2004-07-21 |
Igor Sedukhin |
|
|
wd |
2004-09-11 |
Igor Sedukhin |
|
|
wd |
2004-10-11 |
Igor Sedukhin |
|
|
wd |
2004-10-24 |
Igor Sedukhin |
|
|
wd |
2004-11-04 |
Igor Sedukhin |
|
|
wd |
2004-11-15 |
Igor Sedukhin |
|
|
wd |
2004-11-19 |
Igor Sedukhin |
|
|
wd |
2004-11-23 |
Igor Sedukhin |
|
|
wd |
2004-12-03 |
Igor Sedukhin |
|
|
cd |
2004-12-10 |
Igor Sedukhin |
|
|
standard |
2005-03-09 |
Igor Sedukhin |
|
|
wd v 1.1 |
2005-10-27 |
Kirk Wilson |
Addition of new capability: OperationMetric Creation of Appendix A |
|
wd v 1.1 # 3 |
2005-11-03 |
Kirk Wilson |
Addition of new Metric properties Version 1.1 namespace and file names added |
|
wd v 1.1 #4 |
2005-11-04 |
Kirk Wilson |
Addition of new capability: OperationOperationalStatus |
|
wd v 1.1 #5 |
2005-11-16 |
Kirk Wilson |
Restructure treatment of OperationMetrics and OperationOperationalStatus Remove pseudo-UML diagrams Editorial corrections (result of F2F review) |
|
wd v 1.1 #6 |
2005-11-28 |
Kirk Wilson |
Additional editorial corrections Delete section 2.4 (UML “mind-map”) |
|
wd v 1.1 #7 |
2006-01-27 |
Kirk Wilson |
Schema syntax check. Added acknowledgements |
|
Final wd |
2006-01-27 |
Kirk Wilson |
Prepare final WD for TC vote |
|
cd v 1.1 #1 |
2006-02-23 |
Kirk Wilson |
Committee Draft candidate |
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2003-2006. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://docs.oasis-open.org/wsdm/mows-2.xsd"
xmlns:mows="http://docs.oasis-open.org/wsdm/mows-2.xsd"
xmlns:muws2="http://docs.oasis-open.org/wsdm/muws2-2.xsd"
xmlns:muws1="http://docs.oasis-open.org/wsdm/muws1-2.xsd"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://docs.oasis-open.org/wsdm/muws1-2.xsd" schemaLocation="http://docs.oasis-open.org/wsdm/muws1-2.xsd"/>
<xs:import namespace="http://docs.oasis-open.org/wsdm/muws2-2.xsd" schemaLocation="http://docs.oasis-open.org/wsdm/muws2-2.xsd"/>
<xs:import namespace="http://www.w3.org/2005/08/addressing" schemaLocation="http://www.w3.org/2005/08/addressing/ws-addr.xsd"/>
<!-- MOWS::ManageabilityReferences -->
<xs:element name="GetManageabilityReferences"/>
<xs:element name="GetManageabilityReferencesResponse">
<xs:complexType>
<xs:sequence>
<xs:element ref="muws1:ManageabilityEndpointReference"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- MOWS::Identification -->
<xs:element name="EndpointReference" type="wsa:EndpointReferenceType"/>
<xs:element name="EndpointDescriptions">
<xs:complexType>
<xs:sequence>
<xs:element name="description" type="xs:anyURI"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:element>
<!-- Operation Properties Attribute Group -->
<xs:attributeGroup name=”OperationNameGroup”>
<xs:attribute name="operationName" type=”xs:NCName” use=”required”/>
<xs:attribute name=”portType” type=”xs:QName” use=”optional”/>
</xs:attributeGroup>
<!-- MOWS Operation Operation Status Type -->
<xs:complexType name="OperationOperationalStatusType">
<xs:sequence>
<xs:element ref="muws2:OperationalStatus" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref=”OperationNameGroup”/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:element name="OperationOperationalStatus"
type="OperationOperationalStatusType" />
<!-- MOWS::Metrics -->
<xs:complexType name="IntegerCounter">
<xs:simpleContent>
<xs:extension base="xs:nonNegativeInteger">
<xs:attributeGroup ref="muws2:MetricAttributes"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="DurationMetric">
<xs:simpleContent>
<xs:extension base="xs:duration">
<xs:attributeGroup ref="muws2:MetricAttributes"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="OperationIntegerCounter">
<xs:simpleContent>
<xs:extension base="mows:IntegerCounter">
<xs:attributeGroup ref=”OperationNameGroup”/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="OperationDurationMetric">
<xs:simpleContent>
<xs:extension base="mows:DurationMetric">
<xs:attributeGroup ref=”OperationNameGroup”/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="NumberOfRequests" type="mows:IntegerCounter"/>
<xs:element name="NumberOfSuccessfulRequests" type="mows:IntegerCounter"/>
<xs:element name="NumberOfFailedRequests" type="mows:IntegerCounter"/>
<xs:element name="ServiceTime" type="mows:DurationMetric"/>
<xs:element name="MaxResponseTime" type="mows:DurationMetric"/>
<xs:element name="LastResponseTime" type="mows:DurationMetric"/>
<xs:element name="MaxRequestSize" type="mows:IntegerCounter"/>
<xs:element name="LastRequestSize" type="mows:IntegerCounter"/>
<xs:element name="MaxReponseSize" type="mows:IntegerCounter"/>
<xs:element name="LastReponseSize" type="mows:IntegerCounter"/>
<!-- MOWS::Operation Metrics -->
<xs:complexType name="OperationMetricType">
<xs:sequence>
<xs:element ref="NumberOfRequests" minOccurs="0"/>
<xs:element ref="NumberOfSuccessfulRequests"
minOccurs="0"/>
<xs:element ref="NumberofFailedRequests" minOccurs="0"/>
<xs:element ref="ServiceTime" minOccurs="0"/>
<xs:element ref="MaxResponseTime" minOccurs="0"/>
<xs:element ref=”LastResponseTime” minOccurs="0"/>
<xs:element ref="MaxRequestSize" minOccurs="0"/>
<xs:element ref="LastRequestSize" minOccurs="0"/>
<xs:element ref="MaxResponseSize" minOccurs="0"/>
<xs:element ref="LastResponseSize" minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="OperationNameGroup" />
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:element name="OperationMetrics" type="OperationMetricType"/>
<!-- MOWS::OperationalState -->
<xs:complexType name="OperationalStateType">
<xs:complexContent>
<xs:extension base="muws2:StateType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="UpState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="IdleState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType">
<xs:sequence>
<xs:element ref="mows:UpState"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="BusyState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType">
<xs:sequence>
<xs:element ref="mows:UpState"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="DownState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="StoppedState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType">
<xs:sequence>
<xs:element ref="mows:DownState"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="CrashedState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType">
<xs:sequence>
<xs:element ref="mows:DownState"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="SaturatedState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:OperationalStateType">
<xs:sequence>
<xs:element ref="mows:DownState"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="CurrentOperationalState" type="mows:OperationalStateType"/>
<xs:element name="LastOperationalStateTransition"
type="muws2:StateTransitionType"/>
<!-- MOWS::RequestProcessingState -->
<xs:complexType name="RequestProcessingStateType">
<xs:complexContent>
<xs:extension base="muws2:StateType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="RequestReceivedState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:RequestProcessingStateType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="RequestProcessingState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:RequestProcessingStateType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="RequestCompletedState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:RequestProcessingStateType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="RequestFailedState">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="mows:RequestProcessingStateType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="MessageContentNotIncludedFlag"/>
<xs:simpleType name="MessageSizeUnitType">
<xs:restriction base="xs:string">
<xs:enumeration value="bit"/>
<xs:enumeration value="byte"/>
<xs:enumeration value="word"/>
<xs:enumeration value="dword"/>
<xs:enumeration value="qword"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="MessageContentSizeType">
<xs:simpleContent>
<xs:extension base="xs:positiveInteger">
<xs:attribute name="Unit"
type="mows:MessageSizeUnitType" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="MessageContentType">
<xs:sequence>
<xs:element name="Size"
type="mows:MessageContentSizeType" minOccurs="0"/>
<xs:choice>
<xs:element name="NotIncluded"
type="mows:MessageContentNotIncludedFlag"/>
<xs:element name="Text" type="xs:string"/>
<xs:element name="Binary" type="xs:base64Binary"/>
<xs:element name="Xml"
type="mows:AnyXmlContentsType"/>
</xs:choice>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="AnyXmlContentsType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="MessageInformationType">
<xs:sequence>
<xs:element name="TransportInformation"
type="mows:AnyXmlContentsType" minOccurs="0"/>
<xs:element name="Message" type="mows:MessageContentType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="RequestProcessingStateInformationType">
<xs:sequence>
<xs:element ref="muws2:StateTransition" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="RequestProcessingNotification">
<xs:complexType>
<xs:sequence>
<xs:element name="Request"
type="mows:MessageInformationType"
minOccurs="0"/>
<xs:element name="Reply"
type="mows:MessageInformationType"
minOccurs="0"/>
<xs:element name="StateInformation"
type="mows:RequestProcessingStateInformationType"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="CurrentTime" type="xs:dateTime" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="IPV4AddressType">
<xs:restriction base="xs:hexBinary">
<xs:length value="8" fixed="true"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="IPV4Address" type="mows:IPV4AddressType"/>
<xs:simpleType name="IPV6AddressType">
<xs:restriction base="xs:hexBinary">
<xs:length value="32" fixed="true"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="IPV6Address" type="mows:IPV6AddressType"/>
<xs:simpleType name="TcpIpDirectionType">
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="from"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TcpIpProtocolType">
<xs:restriction base="xs:string">
<xs:enumeration value="TCP"/>
<xs:enumeration value="UDP"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="TcpIpInfo">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element ref="mows:IPV4Address"/>
<xs:element ref="mows:IPV6Address"/>
</xs:choice>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Direction" type="mows:TcpIpDirectionType"
use="required"/>
<xs:attribute name="Port" type="xs:positiveInteger" use="required"/>
<xs:attribute name="Protocol" type="mows:TcpIpProtocolType"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
</xs:schema>
<!--
SCHEMA COPY Material
Copy and paste element references below into the schema of a resource properties document.
These references are provide to insure that the correct minOccurs/maxOccurs attributes are specified in a resource property document schema.
NOTE: You must import the MOWS schema namespace (mows).
** Endpoint Identification Properties **
<xs:element ref="mows:EndpointReference"/>
<xs:element ref="mows:EndpointDescriptions" minOccurs="0"/>
** MOWS Metric Properties **
<xs:element ref="mows:NumberOfRequests" minOccurs="0"/>
<xs:element ref="mows:NumberOfFailedRequests" minOccurs="0"/>
<xs:element ref="mows:NumberOfSuccessfulRequests" minOccurs="0"/>
<xs:element ref="mows:ServiceTime" minOccurs="0"/>
<xs:element ref="mows:MaxResponseTime" minOccurs="0"/>
<xs:element ref="mows:LastResponseTime" minOccurs="0"/>
<xs:element ref="mows:MaxRequestSize" minOccurs="0"/>
<xs:element ref="mows:LastRequestSize" minOccurs="0"/>
<xs:element ref="mows:MaxResponseSize" minOccurs="0"/>
<xs:element ref="mows:LastResponseSize" minOccurs="0"/>
**- MOWS Operation Metric Property **
<xs:element ref="mows:OperationMetrics" minOccurs="0" maxOccurs="unbounded"/>
** MOWS Operation Operational Status Property **
<xs:element ref="mows:OperationOperationalStatus"
minOccurs="0" maxOccurs="unbounded"/>
** Operational State Properties **
<xs:element ref="mows:CurrentOperationalState"/>
<xs:element ref="mows:LastOperationalStateTransition" minOccurs="0"/>
-->
<?xml version="1.0" encoding="utf-8"?>
<w:definitions xmlns:w="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-2"
xmlns:mows="http://docs.oasis-open.org/wsdm/mows-2.xsd"
xmlns:mowsw="http://docs.oasis-open.org/wsdm/mows-2.wsdl"
targetNamespace="http://docs.oasis-open.org/wsdm/mows-2.wsdl">
<w:types>
<xs:import namespace="http://docs.oasis-open.org/wsdm/mows-2.xsd" schemaLocation="http://docs.oasis-open.org/wsdm/mows-2.xsd"/>
</w:types>
<w:message name="GetManageabilityReferencesRequest">
<w:part name="body" element="mows:GetManageabilityReferences"/>
</w:message>
<w:message name="GetManageabilityReferencesResponse">
<w:part name="body"
element="mows:GetManageabilityReferencesResponse"/>
</w:message>
</w:definitions>
<!--
WSDL COPY Material
Cut and Paste the operation specification below into a portType definition of the WSDL documents of a web service.
NOTE: You must import the MOWS WSDL (mowsw).
<operation name="GetManageabilityReferences">
<input name="GetManageabilityReferencesRequest"
message="mowsw:GetManageabilityReferencesRequest"/>
<output name="GetManageabilityReferencesResponse"
message="mowsw:GetManageabilityReferencesResponse"/>
</operation>
-->
<?xml version="1.0" encoding="utf-8"?>
<wstop:TopicSpace name="MOWS"
targetNamespace="http://docs.oasis-open.org/wsdm/mowse-2.xml"
xmlns:muws2="http://docs.oasis-open.org/wsdm/muws2-2.xsd"
xmlns:muws1="http://docs.oasis-open.org/wsdm/muws1-2.xsd"
xmlns:mows="http://docs.oasis-open.org/wsdm/mows-2.xsd"
xmlns:wstop="http://docs.oasis-open.org/wsn/t-1">
<wstop:Topic name="IdentificationCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="MetricsCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="OperationMetricsCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="OperationalStateCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="OperationalStatusCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="OperationOperationalStatusCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="RequestProcessingStateCapability" messageTypes="muws1:ManagementEvent"/>
<wstop:Topic name="RequestProcessingObservations"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
<wstop:Topic name="RequestReceived"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestProcessing"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestCompleted"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestFailed"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="Digest"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
<wstop:Topic name="RequestProcessingObservationsWithAttachments"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
<wstop:Topic name="RequestReceived"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestProcessing"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestCompleted"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="RequestFailed"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name="Digest"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[muws2:Situation/muws2:SituationCategory//muws2:ReportSituation and muws2:Severity="1" and count(mows:RequestProcessingNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
</wstop:TopicSpace>