Web Services Distributed Management: Management Using Web Services (MUWS 1.1) Part 2
OASIS Committee Draft,
Document identifier:
wsdm-muws2-1.1-spec-cd-01
Location:
http://docs.oasis-open.org/wsdm/wsdm-muws2-1.1-spec-cd-01.pdf
Editor:
Vaughn Bullard,
AmberPoint, Inc. <vbullard@amberpoint.com>
William Vambenepe, Hewlett-Packard <vbp@hp.com>
Abstract:
There are two specifications produced by the Web services Distributed Management technical committee: Management Using Web services (MUWS) and Management Of Web services (MOWS, see [MOWS]). This document is part of MUWS.
MUWS defines how an Information Technology
resource connected to a network provides manageability interfaces such that the
IT resource can be managed locally or from remote locations using Web services
technologies.
MUWS is composed of two parts. This document
is MUWS part 2 and provides specific messaging formats used to enable the
interoperability of MUWS implementations. MUWS part 1 [MUWS Part 1] provides the fundamental concepts for management
using Web services. MUWS part 2 depends on MUWS part 1 while part 1 is
independent of part 2.
Status:
This document is an OASIS Committee Draft.
[This specification makes direct and indirect normative references to evolving specifications in OASIS and W3C. The WSDM TC intends to move to referencing the standard specifications as they become available.]
Committee members should send comments on
this specification to the wsdm@lists.oasis-open.org list.
Others should subscribe and send comments to the wsdm-comment@lists.oasis-open.org
list. To subscribe, send an email message to wsdm-comment-request@lists.oasis-open.org,
with the word “subscribe” as the body of the message.
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 WSDM TC web page (http://www.oasis-open.org/committees/wsdm/).
The errata document for this specification is
maintained at:
http://docs.oasis-open.org/wsdm/wsdm-muws2-1.1-errata.pdf
Table of Contents
2 Use of the
Web Services Platform
2.1 Use of
WS-Addressing and the WS-Resource concept
2.2 Use of
WS-Resource Properties
2.4.1 Metadata
applicable to all aspects of manageability capabilities
2.4.2 Metadata
applicable to properties
2.6 Representation
of Categorization Taxonomies in XML
3 Capabilities
applicable to manageable resources
3.2.3 Information
Markup Declarations
3.4.2 Information
Markup Declarations
4 Capabilities
applicable to management in general
4.1.2 Information
Markup Declarations
4.2 Relationship
Resource Capability
5.1 Discovery
using Relationships
5.2 Discovery
using Registries
Appendix F. Description of situation types
This document, MUWS Part 2, builds upon the foundation provided by [MUWS Part 1]. All of the normative text presented in MUWS Part 1 is considered normative text for MUWS Part 2. All informational text presented in MUWS Part 1 is relevant informational text for MUWS Part 2. Compliance with MUWS Part 1 is REQUIRED for every aspect of MUWS Part 2.
The text of this specification along with Appendix C (Schemas), Appendix D (WSDL Elements), Appendix E (Topics) and Appendix F (Description of Situation Types) is considered normative with the following exceptions: the abstract, the examples and any section explicitly marked as non-normative.
The terminology and notational conventions defined in [MUWS Part 1] apply to this document.
The following namespaces are used, unless specified otherwise.
Prefix |
Namespace |
muws1 |
http://docs.oasis-open.org/wsdm/muws1-2.xsd |
muws2 |
http://docs.oasis-open.org/wsdm/muws2-2.xsd |
muwsw |
http://docs.oasis-open.org/wsdm/muws-2.wsdl |
muwse |
http://docs.oasis-open.org/wsdm/muwse-2.xml |
wsnt |
http://docs.oasis-open.org/wsn/b-2.xsd |
wstop |
http://docs.oasis-open.org/wsn/t-1 |
wsrf-rp |
http://docs.oasis-open.org/wsrf/rp-2 |
wssg |
http://docs.oasis-open.org/wsrf/sgw-2.wsdl |
wsdl |
http://www.w3.org/2002/07/wsdl |
wsa |
http://www.w3.org/TR/ws-addr-core |
soap |
http://schemas.xmlsoap.org/soap/envelope/ or http://www.w3.org/2002/12/soap-envelope |
xs |
http://www.w3.org/2001/XMLSchema |
XML elements ([XML1.0 3rd Edition]]) and schema ([XML Schema Part 1] and [XML Schema Part 2]) types introduced in this section belong to the namespace mapped to “muws2”.
WSDL ([WSDL]) elements introduced in this section belong to the namespace mapped to “muws-2.wsdl”.
As a complement to the Web services platform described in [MUWS Part 1], MUWS Part 2 presents an additional set of specifications in order to achieve interoperability among disparate implementations of MUWS. This goal is achieved by the precise specification of the format for each management message.
MUWS Part 2 depends upon concepts presented in the Web Services Resources Framework (WSRF). A manageable resource is a refinement of a WSRF resource. A WS-Resource is defined as the actual composition of a resource and a web service from which the resource can be accessed. In addition, a reference to a manageability endpoint relies upon reference mechanisms as defined in the WSRF WS-Resource Specification [WS-Resource], and more specifically, leverages and refines the endpoint reference concept, as defined in WS-Addressing.
The MUWS specification does not currently define how to obtain an EPR. Currently, to obtain an EPR, there may be some out-of-band agreement between a service provider and a manageability consumer. Possibly, some future version of the MUWS specification might clarify and standardize an approach to obtain an EPR. This specification provides some guidelines on discovering EPRs for manageability endpoints and the WSDM Primers explain how to enable and use discovery.
In the specific case where a manageability endpoint corresponds to one and only one manageable resource, then either the endpoint reference concept defined in WS-Addressing can be used. If no endpoint reference exists, then the consumer can use a URL to identify the manageable resource. Following this reasoning, a manageability consumer without an endpoint reference for a manageable resource MAY try to invoke manageability operations without including an endpoint reference. If such an invocation succeeds, the manageability consumer can infer it is accessing a manageable resource through a manageability provider.
Management properties as defined in MUWS are represented as WSRF properties, and use the mechanisms defined in WS-ResourceProperties ([WS-RP]). In other words, each manageable resource exposes a resource properties document containing, as children of the document root, all the properties of the manageable resource. The manageable resource then makes this document available, as described in WS‑ResourceProperties.
Supporting WS-ResourceProperties means that any implementation of an interface that includes properties MUST include access methods to these properties as defined by WS‑ResourceProperties. Specifically, the interface MUST include the GetResourceProperty operation defined by [WS-RP] and MAY include the GetMultipleProperties, SetResourceProperties, GetResourcePropertiesDocument and QueryResourceProperties operations. If the QueryResourceProperties operation is provided, then the QueryResourceProperties operation SHOULD support the XPath 1.0 query expression dialect, represented by URI http://www.w3.org/TR/1999/REC-xpath-19991116.
MUWS uses the notification mechanism described by WS-BaseNotification ([WSN]). If a manageability capability includes an ability to offer events to a consumer, then the definition of the capability SHALL include topic space, as described in WS-Topics ([WST]). The topic space MUST contain an appropriate set of topics for the events offered by the capability. As described in MUWS Part 1, an event is defined by a topic QName and a content element. The topic is mapped to the topic of the event, as defined by [WST].
As specified by WS-BaseNotification, whether the event payload (of type muws1:ManagementEvent) is the first child of the SOAP ([SOAP]) body or whether it is wrapped in a wsnt:Notify element is determined based on whether the wsnt:UseNotify element in the subscription message is set to true or false.
Note that WS-BaseNotification does not currently support a
means to specify that only some of the information contained in the
notification message should be sent to the consumer. MUWS does not define a
means to specify this either. The manageability consumer and the implementer of
a manageability endpoint should be aware that there is a performance cost for
processing many, large notification messages.
MUWS defines a set of base schema for metadata elements. These metadata elements can be represented as XML Schema elements. The purpose of a metadata element is to supplement the information available in the WSDL [WSDL] and the WS-ResourceProperties [WS-RP] declaration for a manageability interface. A metadata element provides additional description relevant to the managed resource. In particular, a metadata element enables a tool or management application, to perform detailed reasoning and make specialized inferences about a manageable resource at runtime, and, during development, when no instance is available for a manageable resource.
If metadata is required, then an XML document containing metadata is defined and associated with a WS-ResourceProperties document and WSDL. Document processing, such as an XPath query, is used to extract all or part of the metadata. Currently, WSDM does not define the format of, how to associate, or, how to access document metadata content. Although some mechanism is necessary, this MUWS specification does not provide any mechanism for accessing metadata from an instance of a manageable resource.
This MUWS specification does not provide any description of how metadata is associated with a type of manageable resource, stored, or made available.
The MUWS specification defines a set of metadata elements that apply to the basic manageability of a manageable resource. The MUWS specification uses Global Element Declarations to represent a metadata element.
MUWS defines metadata elements applicable to all aspects of a manageability capability (operations, properties, events…). These elements are:
<muws2:Capability>xs:anyURI</muws2:Capability> *
muws2:Capability
metadata element SHOULD be provided for any MUWS aspect of a manageability
interface. This enables discovery of aspects of an interface associated with a
capability.This URI element
identifies which capability an aspect is associated with.
This metadata element indicates the classification of an aspect of an interface according to an intended capability, or capabilities. For example, an aspect may be classified as a metric, or, as a configuration property. A property may be relevant to more than one capability. For example, a configuration property of a computer system contains the IP address but this same property could also be used for identification purposes.
Some of the known capabilities are listed below for illustration. This is not an exhaustive list. For a detailed explanation, see the relevant MUWS manageability capability specification. Additional capabilities are expected to be added as extensions to MUWS.
·
http://docs.oasis-open.org/wsdm/muws/capabilities/Identity
Identity capability. See [MUWS Part 1].
·
http://docs.oasis-open.org/wsdm/muws/capabilities/Configuation
Configuration property. See section 3.5.
·
http://docs.oasis-open.org/wsdm/muws/capabilities/CorrelatableProperties
”Correlatable Properties” capability. See [MUWS Part 1].
·
http://docs.oasis-open.org/wsdm/muws/capabilities/State
State capability. See section 3.1.3.
·
http://docs.oasis-open.org/wsdm/muws/capabilities/Metrics
Metrics capability. See section 3.4.
·
User defined
A user defined capability
that extends, or, is different from, a standard capability defined in MUWS.
<muws2:ValidWhile Dialect=”xs:anyURI”> {any} * </muws2:ValidWhile>
muws2:ValidWhile contains a statement that, when true, asserts that the interface aspect to which this metadata element is related is valid. This is used, for example, to express the fact that an operation can only be invoked when certain properties have certain values.
muws2:ValidWhile/@muws2:Dialect identifies how the statement in muws2:ValidWhile is built and what rules govern its evaluation. MUWS defines one possible value for this element. Other values can also be defined.
The value defined by MUWS is http://www.w3.org/TR/1999/REC-xpath-19991116.
When this dialect is used, the content of muws2:ValidWhile
is an [XPath
1.0] expression. This expression is evaluated against the
resource properties document of the manageable resource. If the XPath
expression evaluates to a Boolean value of true,
or if it evaluates to a non-empty non-boolean value without any errors, then
the statement is considered true.
General purpose metadata that is not management specific is defined in the MUWS specification, but not specified in schema. General purpose metadata that can be defined for any property include:
· Mutability – indicates if the property value can change over time
· Modifiability – indicates if the property can be set directly (not as a side-effect)
· Valid Values –a set of valid values for the property
·
· Static Values – a set of permanent values for the property
· Notifiability – indicates if a notification is sent when there is a change to the value of the property
Schema to represent general purpose metadata should be composed from a metadata specification, for example, the WS-Resource Metadata Descriptor [WSRMD], as developed in the WS-RF OASIS technical committee. (**Special note: Although the WSRF Technical committee is currently working on the WSRMD, the WSDM committee will probably reference the WSRMD in a future release of the WSDM specification.)
In addition, MUWS defines a set of metadata related to management. Any property element may have the following manageability metadata element:
<muws2:Units>xs:string</muws2:Units>
muws2:Units indicates the default unit for this property as a string.
Other metadata elements, applicable for metric-type properties, are defined in section 3.4.3.
General purpose metadata, that is not management specific, is defined in the MUWS specification, but not specified in schema. General purpose metadata that can be defined for any operation includes:
· Idempotency – indicates if invoking the operation twice is equivalent to invoking it once
Schema to represent general purpose metadata should be composed from a metadata specification, for example, the WS-Resource Metadata Descriptor [WSRMD], as developed in the WS-RF OASIS technical committee.
In addition, MUWS defines metadata related to management. Any operation element may have the following manageability metadata element:
<muws2:PostCondition Dialect=”xs:anyURI”>
{any} *
</muws2:PostCondition>
muws2:PostCondition contains a statement that asserts "true" immediately after the corresponding operation is complete.
muws2:PostCondition/@muws2:Dialect is a URI identifying how the statement in muws2:PostCondition is built, and what rules govern its evaluation. MUWS defines one possible value for this element. Other values can be defined.
The value defined by MUWS is http://www.w3.org/TR/1999/REC-xpath-19991116.
When this dialect is used, the content of muws2:PostCondition
is an [XPath
1.0] expression. This expression is evaluated against the
resource properties document of the manageable resource. If the XPath
expression evaluates to a Boolean value of true,
or, if it evaluates to a non-empty non-boolean value without any errors, then
the statement is considered true.
[MUWS Part 1] defines the muws1:ManagementEvent Global Element Declaration as a container for management events. muws1:ManagementEvent allows information to be added via extensibility elements. The muws2:Situation element defined below MUST be present as a child of the muws1:ManagementEvent element in notifications.
As a result, the event format is flexible and extensible. At the same time, automated analysis is possible, as the event format provides a means to classify an event into one of a limited set of classifications and sub-classifications.
MUWS event classifications are based on a thorough analysis of event types, as produced by a wide range of IT equipment, and grouped according to the general nature of events. For example, virtually all manageable resources have a means of being started. However, almost all managed resources express a start event in some unique way. The basic knowledge that the resource has started is all that is necessary, even for fairly sophisticated, automated management.
To support event classifications, the MUWS specification defines the SituationCategoryType element, a specialization of a muws2:CategoryType. MUWS defines the top level of classifications. Extensions to these classifications enable a refined event classification. Through the use of the extensible muws2:CategoryType mechanism, WSDM event consumers can comprehend the situation for an event to a degree commensurate with their ability.
<muws2:Situation>
<muws2:SituationCategory>
muws2:SituationCategoryType
</muws2:SituationCategory>
<muws2:SuccessDisposition>
(Successful|Unsuccessful)
</muws2:SuccessDisposition> ?
<muws2:SituationTime>xs:dateTime</muws2:SituationTime> ?
<muws2:Priority>xs:short</muws2:Priority> ?
<muws2:Severity>xs:short</muws2:Severity> ?
<muws2:Message>muws:LangString</muws2:Message> ?
<muws2:SubstitutableMsg MsgId=”xs:string” MsgIdType=”xs:anyURI”>
<muws2:Value>xs:anySimpleType</muws2:Value>*
</muws2:SubstitutableMsg> ?
</muws2:Situation>
muws2:Situation/muws2:SituationCategory categorizes the type of the situation that caused the event report. The values, listed below, represent the names of elements in the muws2 namespace. The categories are listed in the order of precedence. In a case where there may be some ambiguity about which category to use, the higher precedent category SHOULD be used. The ordering of situation categories is based on empirical data showing relative importance of various types of events. The use of a higher precedent category permits more effective and timely correlation and analysis of events that may indicate the presence of a serious problem. Details and examples for use of the following values are documented in Appendix F. This element is REQUIRED.
· AvailabilitySituation
· CapabilitySituation
· ConfigureSituation
· StopSituation
· StopInitiated
· AbortInitiated
· PauseInitated
· StopCompleted
· StartSituation
· StartInitiated
· RestartInitiated
· StartCompleted
· RequestSituation
· RequestInitiated
· RequestCompleted
· DestroySituation
· CreateSituation
· DependencySituation
· ConnectSituation
· ReportSituation
· Performance
· Security
· Heartbeat
· Status
· Trace
· Debug
· Log
· OtherSituation
muws2:Situation/muws2:SuccessDisposition
in the case where this situation is triggered by a command, this value
specifies a successful disposition of the command causing
a report of this situation. This element is OPTIONAL and should not be included
if the situation is not the result of a command. The element is a restriction
of the type xs:string allowing the following
values:
·
Successful
·
Unsuccessful
muws2:Situation/muws2:SituationTime
represents the date and time an event is observed. If the value does not
include a time zone designation, or, if the value does not use ‘Z’ for UCT,
then the value MUST be interpreted as having a time zone of UCT. The value of
SituationTime MUST provide granularity as precise as supported by the
generating platform. This is a REQUIRED element and MUST be provided by the
component acting as the originator of an event.
muws2:Situation/muws2:Priority represents the importance of an event. This element supports management functions requiring an event to be associated with a priority. This is an OPTIONAL element. Values are constrained to a range from 0 through 100. The predefined priorities are:
· Low (10)
· Medium (50)
· High (70).
Other priorities MAY be used but MUST NOT be less than 0 or greater than 100.
muws2:Situation/muws2:Severity
represents the perceived severity of the status the event is describing with
respect to the application that reports the event. This element supports
management functions requiring an event to be associated with a severity. This
is an OPTIONAL element. Severity levels, based upon the DMTF CIM Alert
Indications Perceived Severity, are as follows:
·
6 (Fatal): a condition is unrecoverable and the
service is no longer available.
·
5 (Critical): a condition affecting the service has
occurred. Immediate corrective action is required.
·
4 (Major): a problem of relatively high severity has
occurred. It is likely that normal use of the service is impeded.
·
3 (Minor): a problem of relatively low severity has
occurred. It is unlikely that normal use of the service is impeded.
·
2 (Warning): a problem affecting the service may
occur. Diagnostic and corrective action is recommended.
·
1 (Information): a message output considered as normal
and expected. For example, a process begins, a process finishes, or status
information is displayed.
·
0 (Unknown): a severity level cannot be determined.
muws2:Situation/muws2:Message
represents the text accompanying an event. This is typically the resolved message string in a human-readable format,
as rendered for a specific locale, and is of type muws2:LangString which is an extension of xs:string requiring the xml:lang
attribute. This is an OPTIONAL property. While the string length for Message is unbounded, it is RECOMMENDED
that the string length for Message
does not exceed 1024 characters.
muws2:Situation/muws2:SubstitutableMsg
– represents the message data in a substitutable form. The attributes MsgId and MsgIdType
indentify the base message type and text. The element value contains the data
that will be formatted according to the formatting rules defined by the MsgId. This is an OPTIONAL element. However, if this element is used, it must
contain all the attributes and elements specified below.
muws2:Situation/muws2:SubstitutableMsg/@muws2:MsgId
specifies the message identifier of an event. This identifier SHOULD be a
unique value string, consisting of alphanumeric or numeric characters. The
value can be as simple as a string of numeric characters that identify a
message in a message catalog. As an
alternative, the value can be a multipart string of alphanumeric characters,
for example, DBT1234E. This is a REQUIRED attribute. The maximum string length
for MsgId MUST NOT exceed 256
characters. The MsgIdType attribute
indicates the formatting type of the MsgId.
muws2:Situation/muws2:SubstitutableMsg/@muws2:MsgIdType specifies the meaning and format of the MsgId. This is a REQUIRED attribute. The type of the MsgIdType attribute is a URI.
muws2:Situation/muws2:SubstitutableMsg/muws2:Value can be of any simple type. There are one or more occurrences of this element with each occurrence containing an xsi:type attribute defining the type of the contained data. This element is used to pass data values that are substituted as a message is formatted. This element is OPTIONAL. A MsgId and MsgIdType define rules to map parameters into a composed message, based upon the order of the Value elements.
As an example, a minimal SituationType report for the
initiation of a requested restart (at
<muws2:Situation>
<muws2:SituationCategory>
<foo:RestartInitiated>
<muws2:StartSituation/>
</foo:RestartInitiated>
</muws2:SituationCategory>
<muws2:SuccessDisposition>Succesful</muws2:SuccessDisposition>
<muws2:SituationTime>2004-11-11T18:06:00Z
</muws2:SituationTime>
<muws2:Message xml:lang=”en”>
Managed Thing XXX: restart processing begun
</muws2:Message>
</muws2:Situation>
Please note, as outlined in the description of muws2:CategoryType, the most general situation classification appears as the innermost element within the XML nest.
The sequenceNumber attribute allows multiple messages to be sent and processed in a logical order that could, owing to idiosyncrasies in the delivery, be different than the order in which they arrived at the consumer. The sequence number helps consumers to sort messages into a meaningful flow, as defined by the provider. The sequenceNumber is typically used only by event producers when the granularity of the event time stamp (the reportTime attribute) is not sufficient to properly sequence events. In other words, the sequenceNumber field is typically used to sequence events that have the same time stamp value.
It is REQUIRED that sequence numbers for succeeding events be monotonically increasing throughout at least a single value of timestamp.
This attribute is OPTIONAL. There is no default value.
<muws1:ManagementEvent ...
muws2:sequenceNumber=”xsd:ulong”? />
The optional EventCorrelationProperties element allows for the more efficient interpretation and lifecycle management of events. This element is OPTIONAL.
muws1:ManagementEvent/muws1:EventCorrelationProperties: The EventCorrelationProperties element for event correlation follows with the EventCorrelationPropertiesType subelements. These properties generally allow for more efficient interpretation and lifecycle management of events. This element is OPTIONAL.
muws1:ManagementEvent/muws1:EventCorrelationProperties/repeatCount: The repeatCount specifies the number of occurrences of identical events within a specified time interval. The time interval is specified by the elapsedTime property described next. The definition of “identical events” is application-specific and therefore is not defined by this specification.
This property is OPTIONAL and mutable. The repeatCount MAY be set by the component that reports the event or by the event consumer. There is no default value. A value of zero or no value indicates no repeated occurrences of the event.
muws1:ManagementEvent/muws1:EventCorrelationProperties/elapsedTime: The elapsedTime is the time interval during which a certain number of identical events occurred. The number of occurrences is specified by the value of repeatCount. The elapsedTime value indicates the duration of time within which the repeated events were observed.
The value of this property MUST be expressed in microsecond granularity.
This property is OPTIONAL and mutable; however, if the repeatCount is specified, then an elapsed time MUST be present. The elapsedTime MUST be set by the same component that sets the repeatCount. There is no default value for elapsedTime.
<muws1:EventCorrelationProperties …>
<muws1:repeatCount>xs:short</muws1:repeatCount> ?
<muws1:elapsedTime>xs:long</muws1:elapsedTime> ?
</muws1:EventCorrelationProperties> ?
Late binding of event message text is enabled via muws2:Situation/muws2:SubstitutableMsg
element described above but the ability to localize message text to a language compatible
with the consumer of events may require the ability to reference message
catalogs appropriate to the manageable resource reporting the event. The msgCatalogInformation element described
below provides this additional information.
The msgCatalogInformation element provides a means to define message catalog information that is to be used for internationalization of messages contained within the event. These properties enable the optional use of a message catalog for specifying messages.
This is an OPTIONAL property.
The elements within a msgCatalogInformation element are:
muws1:ManagementEvent/muws1:msgCatalogInformation/msgCatalog:
The msgCatalog element is the qualified URI
of the message catalog that contains the locale-dependent message template that
is indexed by the muws-p2-xs:Situation/SubstitutableMsg@MsgId
attribute. The format of the messages in msgCatalog
is specified by the msgCatalogType
element.
This element is
REQUIRED.
muws1:ManagementEvent/muws1:msgCatalogInformation/msgCatalogType:
The msgCatalogType
URI property specifies the format of the msgCatalog.
The format defines the substitution identifier syntax for the muws-p2-xs:Situation/SubstitutableMsg/Value (that is, the method used to insert runtime
information contained in the muws-p2-xs:Situation/SubstitutableMsg/Value
element into the message template that is retrieved from the message catalog to
form a completely translated message). The reserved
keywords for msgCatalogType are:
· Java - The message
catalog uses Java properties encoding. See http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
·
XPG -
The message catalog uses X/Open XPG specifications for providing
internationalization support. See http://www.unet.univie.ac.at/aix/aixprggd/genprogc/nls.htm
Other values may be used for other catalog types.
This element is OPTIONAL. Default value is nil and assumed to be
understood by the consumer of the event.
The schema for msgCatalogInformation is:
<muws2:MsgCatalogInformation>
<muws2:msgCatalog>xs:anyURI</muws2:msgCatalog>
<muws2:msgCatalogType>xs:anyURI</muws2:msgCatalogType> ?
</muws2:MsgCatalogInformation>
For each capability defined by MUWS, topics are defined that encompass every event related to that capability. For example, if a property related to capability “foo” changes, then a notification is sent to subscribers of the topic corresponding to a change event on this property, as described by [WS-RP]. Concurrently, since this property is associated with the “foo” capability, a notification is also sent to subscribers of the topic encompassing change events associated with capability “foo”.
Appendix E contains the XML description of all the topics defined in the MUWS specification. The sections of this document that define a capability also define the topic(s) associated with that capability. The following MUWS topics encompass every event associated with the capability defined in MUWS Part 1:
The muwse:IdentityCapability topic defined below is used for events related to the Identity capability.
<wstop:Topic name="IdentityCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
The muwse:ManageabilityCharacteristicsCapability topic defined below is used for events related to the ManageabilityCharacteristics capability.
<wstop:Topic name="ManageabilityCharacteristicsCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
The muwse:CorrelatablePropertiesCapability topic defined below is used for events related to the CorrelatableProperties capability.
<wstop:Topic name="CorrelatablePropertiesCapability"
messageTypes="muws1:ManagementEvent">
In the description of several manageability capabilities, categories of information are organized in taxonomies. This is for example the case for the categories of relationships between manageable resources, for operational states of resources, etc. In order to convey category information, including taxonomy lineage, to a manageability consumer, and, in order to represent XML information instances, the following convention is used:
MUWS defines an XML Schema complex type called CategoryType. The content of XML elements of this type is any XML element. When an element is defined of this type, it MUST obey the following rules:
· The element and each descendant has, at most, one child element.
· The top-level element and each descendant represent one category in a taxonomy.
· The top level element represents the most specialized category. Each element represents a more specialized category than the category represented by the element it contains, if any.
The CategoryType XML Schema type is declared as follows:
<xs:complexType name=”CategoryType”>
<xs:sequence>
<xs:any namespace=”##any” minOccurs="0" processContents=”lax”/>
</xs:sequence>
</xs:complexType>
The CategoryType type is used to declare an XML element containing instances of general, or unqualified, category information. The CategoryType type is also used to derive an XML Schema type representing a specific category, for example, a relationship among resources, or among operational states.
Category
information MUST be declared as follows:
· An XML element declaring which QName identifies the semantics of the category.
· The XML element declaring an XML Schema type which is a restriction of muws2:Category, or a specialized XML Schema type derived from some other refinement of muws2:Category, for example, muws2:RelationshipType.
· The contents of the XML element MUST be either:
· The one XML element corresponding to the generalization of the currently declared category
·
The
empty sequence. This case occurs if the
declared category does not have any generalizations. For example, the declared category might be
the top of a taxonomy.
For example, assume that information about a maintenance state is represented, using the approach described above. In this example, “off-for-maintenance” is a substate of “offline”, which is a substate of a resource being “unavailable”. The XML representation for this example follows:
<mydomain:Off-for-Maintenance>
<mydomain:Offline>
<anyresource:Unavailable/>
</mydomain:Offline>
</mydomain:Off-for-Maintenance>
By processing the XML information, a manageability consumer
may learn that a resource is in a state identified by the mydomain:Off-for-Maintenance element. However, at the same time, if
the manageability consumer is not aware of definitions and semantics associated
with the mydomain namespace, the
consumer may safely assume the resource is in the commonly known state
identified by anyresource:Unavailable.
Since the most specialized elements are first encountered, a consumer can
generally stop processing an element of type muws2:Category as soon as it reaches an element the semantic of
which it understands.
This section defines capabilities applicable to manageable resources. The capabilities defined in this section complement the capabilities defined in MUWS Part 1.
The
manageability capability URI for the description capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/Description
A manageable resource has a capability description. This description capability gives the manageable resource additional metadata about its capabilities. These attributes include zero or more caption attributes, zero or more description attributes as well as an optional version attribute.
This capability defines the following properties:
<muws2:Caption>muws2:LangString</muws2:Caption> *
muws2:Caption contains a descriptive name for the manageable resource. The Caption property is intended for human consumption. A Caption is expected to be short and is suitable for display next to a graphic icon. Caption is a read-write, optional property with a cardinality of 0 to many. Caption is of type muws2:LangType, which is a restriction of xs:string carrying an xml:lang attribute. This attribute contains a language identifier as defined by [RFC3066]. There can not be more than one Caption per language identifier.
Metadata for Caption:
It is Mutable
It is Modifiable
It
has the following Capability metadata
item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/Description
</muws2:Capability>
<muws2:Description>muws2:LangString</muws2:Description> *
muws2:Description is a string containing a description for the resource being managed. The Description property is intended for human consumption. A Description is expected to be longer and more detailed than a Caption. Description is a read-write optional property with a cardinality of 0 to many. Description is of type muws2:LangType, which is a restriction of xs:string carrying an xml:lang attribute. This attribute contains a language identifier as defined by [RFC3066]. There cannot be more than one Description per language identifier.
Metadata for Description:
It is Mutable
It is Modifiable
It has
the following Capability metadata
item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/Description
</muws2:Capability>
<muws2:Version>xs:string</muws2:Version> ?
muws2:Version is a string representing the version of the resource being managed. MUWS does not specify how this string is constructed. The Version string can be specified by any domain-specific specification that uses MUWS. Version is an optional property with a cardinality of 0 to1.
Metadata for Version:
It is Mutable
It is Modifiable
It has
the following Capability metadata
item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/Description
</muws2:Capability>
The muwse:DescriptionCapability topic defined below is used for events related to the Description capability.
<wstop:Topic name="DescriptionCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
The
manageability capability URI for the State capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/State
A resource may exhibit behavior according to one or more state models. Since a single definition of an operational state model is not sufficient for all types of resource, the State capability is a means to allow different state models to be used by different resources. The state capability provides a pattern for representing any type of state or state model that a manageable resource can expose. This section uses operational state as an example to illustrate the application of this pattern to a simple state model.
Although MUWS defines no state model, there should be a very limited and well defined set of states to facilitate interoperability. Each state is identified by a URI. This URI is exposed by a resource via some resource property.
This capability does not define any specific property, operation or event. A manageability endpoint is said to provide this capability if at least one property exposes state information and follows the pattern described in section 3.2.3.2.
Each state in a state-machine has a well-defined meaning. It is possible to reuse state definitions in different state machines. States are identified by an element with a particular QName, using the taxonomy scheme defined in section 2.6.
States in the state model may have duration. Transitions between states are considered to be instantaneous.
States can have sub-states that MUST be wholly contained within a higher-level state.
A state model may also define an operation that can be used to affect some transition in the model. Note that a transition may also occur as a result of some internal or external event on the resource.
Each state machine has an associated resource property element exposing a read-only view of the current state of the state machine. Therefore, a consumer cannot change a resource state by modifying a state resource property.
There may be more than one possible transition between two states in the state model. The individual transitions between states are identified by a URI. This identification allows, for example, a receiver of state transition notifications to discern which transition occurred.
Figure 1shows a simple state model that is used as an example in this section – it does not constitute the specification of a recommended state model.
Figure 1: Example Operational State Model
In this example, the state machine is identified by URI http://example.com/StateModels/SimpleOperationalState, bound to namespace prefix exns.
In this example, the state model has four states. Each state is represented by elements with a QName, as follows:
·
exns:Down
This QName corresponds to the “Down” state in the UML diagram. A resource in this state is unable to perform any of its functional tasks.
·
exns:Stopped
This QName corresponds to the “Stopped” sub-state of the “Down” state in the UML diagram. Since this state is a sub-state of the “Down” state, it follows that a resource in the "Stopped" sub-state is unable to perform any of its functional tasks. A manageable resource exposing this state model can be started from the "Stopped" sub-state.
·
exns:Failed
This QName corresponds to the “Failed”
sub-state of the Down state in the UML diagram.
Since this state is a sub-state of the “Down” state, it follows that a
resource in the "Failed" sub-state is unable to perform any of its
functional tasks. A manageable resource exposing this state model can not be
started directly from the “Failed” sub-state. Such a resource must first transition
to the “Stopped” sub-state.
·
exns:Up
This QName corresponds to
the “Up”
state in the UML diagram. A resource in this state is able to perform at least
some of its functional tasks.
A state, as represented in a state model, may be a top level state or a state that is nested within another state according to some defined taxonomy. MUWS defines a way to represent a state category and its taxonomy lineage, but an actual definition of any category is specific to a particular resource management model. Therefore MUWS defines no state model. In other words, MUWS specifies only the mechanism used to convey a state category in XML. The MUWS mechanism applied to the representation of states is defined as follows:
muws2:StateType XML Schema type is declared as follows
<xs:complexType name=”StateType”>
<xs:complexContent>
<xs:extension base=”muws2:CategoryType”/>
</xs:complexContent>
</xs:complexType>
The muws2:StateType type is used to declare an XML element containing an instance of state.
A
state MUST be declared as follows:
· An XML element declaring which QName identifies the semantics of the state.
· The XML element has an XML Schema type of muws2:StateType,, or a restriction of muws2:StateType.
· The contents of the XML element MUST be either:
· The one XML element that corresponds to the state containing this state. In other words, this state is a sub-state of another state.
·
The
empty sequence. This case occurs if this state is not a sub-state of another
state.
For example, the “Failed” state in the example above is a sub-state of the “Down” state. An instance of the “Failed” state may be represented, using the rules described above, by the following XML fragment:
<my:StateTypeInstanceElement xsi:type=”StateType”>
<exns:Failed>
<exns:Down/>
</exns:Failed>
</my:StateTypeInstanceElement>
MUWS defines the following Global Element Declaration (GED) to represent an instance of a state:
<muws2:State>muws2:StateType</muws2:State>
The State element provides a representation of the state of a manageable resource. The State element follows the convention for the muws2:CategoryType type described in section 2.6. This convention allows the rendering of a hierarchy of states and sub-states. State values are defined in the operational state model for the resource. This specification does not define the operational state model for any resource.
MUWS defines the following Global Element Declaration (GED) which contains an XML representation of a change of state in a state model.
<muws2:StateTransition Time“xs:dateTime”
TransitionIdentifier=” xs:anyURI”?>
<muws2:EnteredState>muws2:StateType</muws2:EnteredState>
<muws2:PreviousState>muws2:StateType</muws2:PreviousState>?
{any}
*
</muws2:StateTransition>
muws2:StateTransition is used for representing information about a state change.
muws2:StateTransition/@muws2:Time attribute indicates the time at which the transition occurred (transitions are assumed to be instantaneous). This attribute is REQUIRED.
muws2:StateTransition/@muws2:TransitionIdentifier attribute indicates the actual transition that occurred. This attribute is OPTIONAL and may be omitted where, for example, there is only one transition between the EnteredState and the PreviousState.
muws2:StateTransition/muws2:EnteredState element indicates which state has been entered during the transition. This element is REQUIRED.
This capability does not define any standard
property.
A capability defining a state model SHOULD define a resource property that exposes the state. It is RECOMMENDED that a state model also define a resource property that exposes the last state transition.
The property used to expose the state must either contain the muws2:State element or be of type muws2:StateType. The name of the property can be any name meaningful to the state model defined in the capability. There may be multiple state capabilities, and therefore multiple state properties for a resource. The metadata for this property SHOULD include the possible values. That is, the state model should provide a list of states in the state model.
The property to represent the last transition, if such a property is provided, must contain the element muws2:StateTransition. The name of the last transition property can be any name meaningful to the state model. There may be multiple state capabilities and multiple properties exposing the last transition.
Examples of resource properties for an operational state capability could be specified as follows:
<foo:OperationalState>
<muws2:State>...</muws2:State>
</foo:OperationalState>
<foo:LastOperationalStateTransition>
<muws2:StateTransition>...</muws2:StateTransition>
</foo:LastOperationalStateTransition>?
The following fragment provides an example from a resource properties instance document containing the properties defined in this example:
<foo:OperationalState>
<muws2:State>
<exns:Failed><exns:Down/></exns:Failed>
</muws2:State>
</foo:OperationalState>
<foo:LastOperationalStateTransition>
<muws2:StateTransition
Time=”2004-03-11T11:30:56Z”
TransitionIdentifier=”http://example.com/SimpleOperationalState/T/Failed”>
<muws2:EnteredState>
<exns:Failed><exns:Down/></exns:Failed>
</muws2:EnteredState>
<muws2:PreviousState>
<exns:Up/>
</muws2:PreviousState>
</muws2:StateTransition>
</foo:LastOperationalStateTransition>
In this example, the foo:OperationalState property contains the current operational state of the resource, using the muws2:State element defined in section 3.2.3.2 The foo:LastOperationalStateTransition property contains a description of the most recent operational state transition for the resource, using the muws2:StateTransition element as defined in section 3.2.3.2.
A
capability defining a state model usually defines any operations that can be
used to cause some of the transitions within the state model. These operations
are specific to the resource and its state model.
The muwse:StateCapability topic defined below is used for events related to the State capability.
<wstop:Topic name="StateCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
It is RECOMMENDED that resources send a notification on a transition between states. The topic defined for the State capability SHALL be used to publish such notifications. If a resource sends such a notification, then the notification message MUST contain at least the XML element representing a state transition (muws2:StateTransition).
To obtain events about a certain state transition, a subscriber can use a Selector, on the notification subscription, to select only those events containing the required muws2:TransitionIdentifier element in the notification content, or, a combination of muws2:EnteredState and muws2:PreviousState elements in the notification content. The Selector mechanism is described in [WSN].
To
filter for events about entry into a particular state or set of states, a
Selector expression based on the muws2:EnteredState
element can be used. To filter for events about exit from a particular state or
set of states a Selector expression
based on the muws2:PreviousState
element can be used.
The manageability capability URI for this
capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/OperationalStatus
The operational status capability defines a simple representation of the availability of a resource. This is expressed in terms defined by MUWS. These terms are independent of any specific state model, as defined by domain experts. An operational status property reflects whether the resource is available, unavailable, or degraded. Operational status does not conform to a specific state model. Rather, each value may correspond to more than one state in the operational state model, and conversely more than one operational status value may correspond to a single state in the operational state model. The manageable resource provides the appropriate mapping from state to status and sets the OperationalStatus property accordingly.
The operational status properties and elements are specified as follows:
<muws2:OperationalStatus>
(Available|PartiallyAvailable|Unavailable|Unknown)
</muws2:OperationalStatus>
The following fragment provides an example from a resource properties instance document containing this property:
<muws2:OperationalStatus>Available</muws2:OperationalStatus>
The muws2:OperationalStatus property is of type muws2:OperationStatusType. The type is a restriction of xs:string and provides a simple indication of the availability of the resource, independent of the potentially complex operational state model. This property has a cardinality of 1. The valid values are:
· Available: This value indicates that a manageable resource is operating normally within any configured operating parameters, and is able to perform all functional tasks.
· PartiallyAvailable: This value indicates that a manageable resource is operating, but outside of configured operating parameters. A manageable resource reporting this operational status is able to perform some, but not all, functional tasks. A manageable resource may, for example, be in the process of starting or a resource may be lacking some resource it needs to perform.
· Unavailable: This value indicates that a manageable resource is not operating, and is not able to perform any functional tasks. A manageable resource may have been stopped, or may have failed.
· Unknown: This value indicates that a manageable resource is unable to report status at this time.
Metadata for OperationalStatus:
It
is Mutable
It is not Modifiable
It has the following Capability metadata item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/OperationalStatus
</muws2:Capability>
The muwse:OperationalStatusCapability topic defined below is used for events related to the Operational Status capability.
<wstop:Topic name="OperationalStatusCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
No
specific event is defined, since the notification on property value change
provided by WS-ResourceProperties is sufficient, when applied to the muws2:OperationalStatus property.
The manageability
capability URI for this capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/Metrics
A metric is a specific type of property. A metric represents a collected value during a collection period. A common characteristic of metrics is that they change over time. This section defines how to represent metrics and the metadata necessary to correctly process and interpret a metric value.
As a simple example, to clarify what a metric is, consider a toll bridge with two properties, the length of the bridge and the number of cars that have passed over the bridge. The length of the bridge, while numeric is not a metric. Length represents a current configuration of the bridge. One can not reset the length of the bridge. By contrast, the number of cars that have passed over the bridge is a metric. It requires collecting, counting, or measuring the number of cars. Typically, a count occurs for some interval, or duration of time, such as the last hour, the last day, or, since the bridge was constructed. One might reset the number of cars, for example, at the start of a new interval.
The following sections define two (2) types of “metadata” used for metrics. The value modifiers provides context to the metric’s value, improving the consumer’s ability to interpret the value.
The definitional metadata describes the means by which the value of the metric is acquired.
It is important to keep the two distinct types of metadata or data modifiers in mind when reading the following sections as it is sometimes the case that there are two similar definitions, distinguished primarily by the entity (value or metric) that they describe.
Note: Future
revisions of this specification are likely to move this definitional metadata
into an external metadata component, since it is used to define the
configuration of the metric properties.
However, the value modifiers will remain associated with the metric
itself, as their values is directly pertinent to the interpretation of the
metric value.
The following schema fragment declares the (reusable) data type used to expose the metrics of a resource. All attributes defined in the muws2:MetricAttributes attribute group are OPTIONAL. The MetricAttributes group defines the value modifiers associated with the metric.
<xs:attributeGroup name="MetricAttributes">
<xs:attribute name="ResetAt" type="xs:dateTime"/>
<xs:attribute name="LastUpdated" type="xs:dateTime"/>
<xs:attribute
name="Duration" type="xs:duration"/>
</xs:attributeGroup>
(MetricAttributes) attribute group MUST be included in every metric type or metric type property element declaration.
(MetricAttributes)/ResetAt indicates the time when a metric value was reset. See the definition of muws2:TimeScope for information on when to provide this attribute If the attribute value does not include a time zone indication, or Z for UTC, then the value MUST be interpreted as UTC.
(MetricAttributes)/LastUpdated indicates the last update time of a metric value. If the value does not include a time zone indication, or Z for UTC, then the value MUST be interpreted as UTC.
(MetricAttributes)/Duration indicates the measurement period
relative to the value of the LastUpdated
metric attribute. This is the time over which a metric value was collected,
counted, or measured.
The Duration attribute is valid only for a metric that covers a time
interval. Therefore, the Duration attribute MUST be included for
a metric having a TimeScope of Interval. Similarly, it
MUST NOT be included for a metric having a TimeScope of PointInTime
or SinceReset, because these TimeScopes
imply their measurement period. For these TimeScopes,
an implementer should make use of ResetTime
and CurrentTime to calculate the
duration for the collection of a metric value.
The following metric type definition is an example of how a metric attribute is incorporated into a metric type. All metric types MUST incorporate the muws2:MetricAttributes attribute group.
<xs:complexType name="MyExampleIntegerMetricType">
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attributeGroup ref="muws2:MetricAttributes"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
The following fragment shows an example instance of the above metric type.
<MyIntegerMetric
LastUpdated=”2004-03-11T11:30:56Z”
Duration=”PT1H”>
12345
</MyIntegerMetric>
The following metadata is applicable to any property that is a metric:
It is Mutable
It is not Modifiable
It has
the following Capability metadata
item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/Metrics
</muws2:Capability>
In addition to the value modifiers, the following additional metadata items are defined for a property that is a metric. As opposed to the value modifiers described above, this metadata describes the metric itself, independent of the value at any particular time.
<muws2:ChangeType>(Counter|Gauge|Unknown)</muws2:ChangeType>
muws2:ChangeType is an enumeration indicating how a change to an
associated metric value should be interpreted by a consumer. A property
representing a metric MUST include a single instance of ChangeType in its metadata description. Each ChangeType value is interpreted as follows:
· Counter - the value of the metric is a monotonically increasing integer. Such a metric value increases by increments of “1” when a situational event occurs to the resource.
· Gauge – changes of the value of the metric are not constrained in the way changes to Counter metrics are constrained.
· Unknown - the change behavior for the value of the metric is not known or cannot be described.
<muws2:TimeScope>
(Interval|PointInTime|SinceReset)
</muws2:TimeScope>
muws2:TimeScope is an enumeration for indicating if there is
some interval, over which the data is collected, counted, or measured. A
property that is a metric MUST include a single instance of TimeScope in its metadata description. Each
TimeScope value is interpreted as
follows:
· Interval - the value of a metric is collected over some time interval. In this case a Duration attribute MUST be reported with a metric property. The value of a Duration attribute is the elapsed time, from the beginning of an interval, to the end of an interval. A Duration MAY change, but usually remains the same for every collection of a metric. The ResetAt attribute MAY also be reported with such a metric property and may have a value during the measurement period.
· PointInTime - the value of a metric is counted, collected, or measured at a single instant in time. In this case a Duration attribute MUST NOT be reported with a metric property. A metric defined with a TimeScope of PointInTime does not support a reset capability and MUST NOT include a ResetAt attribute.
· SinceReset - the value of the metric is collected since the last reset of a resource, or since the manageable resource started collecting data for a metric. . In this case a Duration attribute MUST NOT be reported with a metric property, and a ResetAt attribute MUST be reported.
<muws2:GatheringTime>
(OnChange|Periodic|OnDemand|Unknown)
</muws2:GatheringTime>
muws2:GatheringTime is an enumeration indicating under which circumstance
the value of a metric is updated. A property that is a metric MUST include a
single instance of muws2:GatheringTime
in its metadata description. Each muws2:GatheringTime
value is interpreted as follows:
· OnChange - the value of a metric is updated whenever a change occurs to the quantity measured.
· Periodic - the value of a metric is updated on a regularly scheduled basis.
· OnDemand - the value of a metric is updated when processing a request for the metric value.
· Unknown - it is unknown when the value of a metric is updated.
<muws2:CalculationInterval>xs:duration</muws2:CalculationInterval>
muws2:CalculationInterval represents the interval at which a value of a metric is gathered or calculated by a resource. The value of a metric is not updated during a calculation interval. Unlike Duration, which can change every time the metric is updated, the value of CalculationInterval is expected to change rarely. This is because CalculationInterval is used only for a value of a metric that is updated at regular intervals.
Note also that it is possible for a CalculationInterval to be different than the Duration. The former specifies the frequency of update while the latter specifies the period over which the data has been collected.
<muws2:MetricGroup>xs:anyURI</muws2:MetricGroup>
muws2:MetricGroup indicates that a metric property is a member of a group of metrics. A metric property MAY be a member of zero or more metric groups. A metric group is identified by a URI. Each metric property included in a metric group MUST have a muws2:MetricGroup element containing an identical URI. A metric property MAY include zero or more muws2:MetricGroup elements in its metadata description. Each muws2:MetricGroup element represents a membership of the metric property in a metric group.
To illustrate how the value modifiers and definitional metadata might work together, consider a metric that computes average request size over the previous hour. Such a metric might have the following description. (Note that this example uses human readable rather than XML data representations.)
Definitional Metadata |
|
ChangeType |
Gauge |
TimeScope |
Interval |
GatheringTime |
Periodic |
CalculationInterval |
1 Minute |
Value
Modifiers |
|
ResetAt |
|
Duration |
1 Hour |
LastUpdated |
|
(value) |
4800 |
These values
describe our average request size that is a gauge that is updated once a minute
to produce a sliding scale one hour in length.
This instance shows an average size of 4800 from
The following fragment provides the specification of a resource metrics property:
<muws2:CurrentTime>xs:dateTime</muws2:CurrentTime>
muws2:CurrentTime contains the current time, as known to a resource, when a property was retrieved from a manageable resource. This property is useful to a manageability consumer in the absence of a time synchronization mechanism when analyzing the time values received from a manageability endpoint. muws2:CurrentTime is a read-only mandatory property with a resource cardinality of 1.
The Metrics capability requires the muws2:CurrentTime property to be present in a resource property.
The muws2:CurrentTime property provides a reference point for
time-based attributes, as defined by metric data types. Note that muws2:CurrentTime is not a metric.
Rather, it is a property of type xs:dateTime
defined as part of the “Metrics” capability, consequently, any reset operations
has no effect on muws2:CurrentTime.
The muwse:MetricsCapability topic defined below is used for events related to the Metrics capability.
<wstop:Topic name="MetricsCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
WS-ResourceProperties specifies the ability to define optional topics for a resource property that can emit notifications when a value changes. These topics allow a consumer to request notifications on an update of a metric property.
The manageability capability URI for this capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/Configuration
A configuration property is any resource property exposing a value that, when changed, changes some operational behavior of the resource.
The value of a configuration property may be changed directly by a set operation, or, may be changed as a side effect of some other operation.
MUWS does not define any required property for the Configuration capability. Domain experts can define configuration properties which are then marked as associated with the configuration capability. The metadata for a configuration property MUST be:
It is Mutable
It is Modifiable only if the WS-ResourceProperties
SetResourceProperty operation can be
used to change the value of the property. It is not Modifiable if the property is changed only as a side effect.
It has the following Capability metadata item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/Configuration
</muws2:Capability>
WS- ResourceProperties
SetResourceProperty operation MAY be
used to change a configuration value.
The muwse:ConfigurationCapability topic defined below is used for events related to the Configuration capability.
<wstop:Topic name="ConfigurationCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
Section 3, "Capabilities applicable to manageable resources", when merged with the capabilities defined in [MUWS Part 1], provide the list of manageability capabilities defined by MUWS. This section provides management-related capabilities that are different from manageability capabilities.
A manageability capability is offered by a manageability representation and a manageability capability applies to a resource as represented by a manageability representation. In contrast, a management-related capability can be offered by any endpoint of a Web service, not just a manageability endpoint.
The function of a management-related capability is related to the management of a resource, but it is not necessarily offered directly by a manageability endpoint of a resource. For example, the capability to help a manageability consumer discover a new manageable resource can be provided by a registry instead of by a management representation of the resource. As another example, a manageable resource may provide information about relationships in which it participates. The information about a relationship may also provide valid information for another entity or resource that is not manageable, like a registry, maintaining and providing relationship information about a resource without the resource providing the relationship information directly.
The manageability
capability URI for this capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/Relationships
A relationship is an N-ary association between resources. A relationship may have properties, operations and other characteristics. One of these properties is a type that conveys the semantic of the relationship. The resources involved in the relationship are called participants. Each participant has a role in the relationship. The participants may or may not be manageable resources in the MUWS sense. The notion of “direction” of a relationship is a semantic interpretation based on role definitions. There could be many instances of relationships between many instances of resources.
Note that this capability is not limited to manageable resources and can be exposed by any resource that wants to expose relationships that it knows about.
A relationship may become
stale. The information about a relationship should be validated, either
manually or automatically, before it can be relied upon. Exposing the
information about a relationship should be considered a potential security risk
if a participating resource should not be visible for security reasons.
A relationship may be categorized as a certain type of relationship. A relationship type defines the semantics of the relationship. One relationship type may be a specialization or generalization of another type. This defines a taxonomy of relationship categories. MUWS defines a way to represent a type and its taxonomy lineage, but the actual definition of a relationship type is specific to a resource management model. Therefore, no relationship type is defined by MUWS. In other words, MUWS specifies only the mechanism to convey a relationship type, or category, in XML as follows.
RelationshipTypeType type is declared as follows
<xs:complexType name=”RelationshipTypeType”>
<xs:complexContent>
<xs:extension base=”muws2:CategoryType”/>
</xs:complexContent>
</xs:complexType>
The RelationshipTypeType type is used to declare an XML element containing instances of relationship type information.
The relationship type information MUST be
declared as follows:
· An XML element declaring which QName identifies the semantics of a relationship type.
· The XML element MUST be declared with an XML Schema type that is a restriction of RelationshipTypeType.
· The contents of the XML element MUST be either
· The only one XML element corresponding to the generalization of the currently declared relationship type.
·
The
empty sequence, if the currently declared relationship type does not have a
generalization, such as the top of a taxonomy.
For example, the “USB attached” relationship type may be generalized to the “Bus connected” type which, in turn, may be generalized to the “Generally linked” type. An instance of the “USB attached” relationship type information may be represented in the following XML fragment by using the rules described above:
<my:RelationshipTypeInstanceElement xsi:type=”RelationshipTypeType”>
<usb:Attached>
<bus:Connected>
<generally:Linked/>
<bus:Connected>
</usb:Attached>
</my:RelationshipTypeInstanceElement>
MUWS defines the following Global Element Declaration (GED) to represent an instance of a relationship.
<muws2:Relationship>
<muws2:Name>xs:string</muws2:Name>
?
<muws2:Type>muws2:RelationshipTypeType</muws2:Type>
<muws2:Participant>
<muws2:Self/> ?
<muws1:ManageabilityEndpointReference/>
*
<muws1:ResourceId/> ?
<muws2:Role>xs:anyURI</muws2:Role>
{any} *
</muws2:Participant>
<muws2:Participant/>+
<muws2:AccessEndpointReference>
wsa:EndpointReferenceType
</muws2:AccessEndpointReference>?
{any} *
</muws2:Relationship>
muws2:Relationship/muws2:Name is a human readable name for a
relationship. Name should not be used for machine reasoning about the
semantics of a relationship. Type should be used instead. This element is
OPTIONAL.
muws2:Relationship/muws2:Type is the relationship type this relationship belongs to. Examples of such types include linkage, containment, or dependency. MUWS does not define any specific relationship type. This is left to domain-specific models. MUWS only defines a way to convey the type as part of the representation of a relationship. In order to allow relationships to be defined as part of a taxonomy, the mechanism used by MUWS to represent relationship types leverages the muws2:CategoryType type defined in section 2.6. This element is REQUIRED.
muws2:Relationship/muws2:Participant contains information about a participant in the relationship. There MUST be at least two participants, but there MAY be more than two participants.
muws2:Relationship/muws2:Participant/muws2:Self: is an optional empty element that allows a participant to reference its self as the participant.
muws2:Relationship/muws2:Participant/muws1:ManageabilityEndpointReference is a reference to a WSDM manageability endpoint. This GED is defined in part 1. It MAY be included if a participant is a WSDM manageable resource and the provider wishes to expose this information. If more than one manageability endpoint is known, then more than one instance of this element MAY be present.
muws2:Relationship/muws2:Participant/muws1:ResourceId is a WSDM manageable resource identifier which MAY be reported by the provider of relationship information. This GED is defined in part 1. This information may be used to locate manageability endpoints for a participant, or may be used for other purposes. For example, a resource identifier SHOULD be used to express that the provider of relationship information is also a participant in a relationship by returning its own resource identifier as one of the participants. Obviously, in order for this assertion to work, the provider of relationship information must be a WSDM manageable resource.
muws2:Relationship/muws2:Participant/muws2:Role is a URI which identifies the role a participant plays in a relationship. A participant role MUST be unique within a given instance of the relationship. The set of valid roles is defined by a relationship type. This attribute is REQUIRED.
muws2:Relationship/muws2:Participant/{any}* is an XML extensibility content which MAY contain elements that further or otherwise describe a participant. For example, when a participant is an endpoint of a Web service, an EndpointReference element as defined by MOWS MAY be included in the extensibility content to reference a functional or operational endpoint of a Web service that participates in a relationship.
muws2:Relationship/muws2:AccessEndpoint is a reference to a Web service endpoint which provides access to this relationship (if available). The endpoint MUST implement the relationship resource capability (see section 4.2).
The following is an example of a relationship information instance. The relationship is a WSDM manageable network host myhost.myorg.org containing an attached SCSI disk. The SCSI disk is not manageable by itself, but is exposed as a functional or operational endpoint of a Web service (e.g. to read/write from the disk). The “containment” relationship is represented by the following XML instance fragment:
<muws2:Relationship>
<muws2:Name>SCSI disk attached to the host computer</muws2:Name>
<muws2:Type>
<scsi:Attached>
<bus:Connected>
<generally:Linked/>
</bus:Connected>
</scsi:Attached>
</muws2:Type>
<muws2:Participant>
<muws1:ManageabilityEndpointReference>
...EPR1...
</muws1:ManageabilityEndpointReference>
<muws1:ResourceID>urn:uuid:123</muws1:ResourceID>
<muws2:Role>urn:role:bus:host</muws2:Role>
<netop-xs:HostName>myhost.myorg.org</netop-xs:NostName>
</muws2:Participant>
<muws2:Participant>
<muws2:Self/>
<muws2:Role>urn:role:bus:device</muws2:Role>
<scsi-xs:Port>2</scsi-xs:Port>
<scsi-xs:CH>0</scsi-xs:CH>
<scsi-xs:BusID>5</scsi-xs:BusID>
<scsi-xs:LUN>0</scsi-xs:LUN>
<mows-xs:EndpointRefence>
...EPR2...
</mows-xs:EndpointReference>
</muws2:Participant>
</muws2:Relationship>
The Relationship capability defines the following property:
<muws2:Relationship/> *
muws2:Relationship is a representation of a relationship of which the provider of this capability is aware. See section 4.1.2.2 for the definition of the Relationship element. The provider of this capability is not necessarily a participant in any relationship represented by this property.
It is not recommended to request all values of the Relationship property with either wsrf-rp:GetResourceProperty or wsrf-rp:GetMultipleResourceProperties operations as there may be too many relationships. The use of the wsrf-rp:QueryResourceProperties operation is RECOMMENDED when retrieving the Relationships property. A provider of this manageability capability SHOULD, in general, support the wsrf-rp:QueryResourceProperties operation. However, if the provider of this capability knows of just a few relationships, it MAY choose not to support wsrf-rp:QueryResourceProperties operation.
For example, the following request may be sent to retrieve all “Bus connected” relationships which point to devices exposed as Web services.
<soap:Envelope ...>
<soap:Header>
...
</soap:Header>
<soap:Body>
<wsrf-rp:QueryResourceProperties>
<wsrf-rp:QueryExpression
Dialect=”http://www.w3.org/TR/1999/REC-xpath-19991116” >
boolean(/*/muws2:Relationship/muws2:Type/*/bus:Connected and /*/muws2:Relationship/muws2:Participant[Role=”urn:role:bus:device”]/mows-xs:EndpointReference)
</wsrf-rp:QueryExpression>
</wsrf-rp:QueryResourceProperties>
</soap:Body>
</soap:Envelope>
This capability defines the following message exchanges.
This operation is OPTIONAL. It is a shortcut to query relationships of the same type. The request to perform this operation has a payload as follows:
<muws2:QueryRelationshipsByType>
<muws2:RequestedType>xs:QName</muws2:RequestedType>
+
</muws2:QueryRelationshipsByType>
muws2:QueryRelationshipsByType is a Global Element Declaration (GED)
which identifies the operation requested.
muws2:QueryRelationshipsByType/muws2:RequestedType is a QName which identifies the requested type(s) of relationship(s). When processing this request, the manageability endpoint MUST return any available instance relationship that is of the requested type or of any type that is a specialization of the requested type. There can be more than one requested type, in which case any relationship instance corresponding to any requested type MUST be returned.
The response to the above request is either a fault (any fault) or the following message:
<muws2:QueryRelationshipsByTypeResponse>
<muws2:Relationship/> *
</muws2:QueryRelationshipsByTypeResponse>
muws2:QueryRelationshipsByTypeResponse is a GED which identifies a response to the requested operation.
muws2:QueryRelationshipsByTypeResponse/muws2:Relationship is a relationship representation matching a requested type. There is one such element for each relationship instance corresponding to at least one requested type.
This operation has the following Capability metadata item:
<muws2:Capability>
http://docs.oasis-open.org/wsdm/muws/capabilities/Relationships
</muws2:Capability>
To support notifications on a change in a relationship, the following notification topics are defined in the relationships capability:
<wstop:Topic name=”RelationshipCreated” messageTypes=”muws2:RelationshipCreatedNotification””>
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//muws1:ManagementEvent[count(muws2:RelationshipCreatedNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic name=”RelationshipDeleted” messageTypes=”muws2:RelationshipDeletedNotification”>
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//muws1:ManagementEvent[count(muws2:RelationshipDeletedNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
muwse:RelationshipCreated indicates the addition of a new relationship. It is RECOMMENDED that a consumer subscribe to this notification with an appropriate selector against the content of notification messages in order to reduce the volume of received messages. Each notification message contains at least the following information:
<RelationshipCreatedNotification>
<Relationship/>
</RelationshipCreatedNotification>
muwse:RelationshipDeleted indicates removal of an existing relationship. It is RECOMMENDED that a consumer subscribe to this notification with an appropriate selector against the content of notification messages in order to reduce the volume of received messages. Each notification message contains at least the following information:
<RelationshipDeletedNotification>
<Relationship/>
</RelationshipDeletedNotification>
The manageability
capability URI for this capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/RelationshipResource
A Web service endpoint, in addition to providing access to a relationship may also represent a relationship. Representing a relationship means that an endpoint is able to provide relationship information as described in section 4.1.2.2. In this case, a Web service endpoint MUST be a WS-Resource, as defined by the WSRF. One such WS-Resource provides information about one relationship instance. Representing a relationship as a WS-Resource is useful when a manageability model defines additional properties, operations or events for a relationship.
In order to represent a relationship as a WS-Resource, a set of properties is normatively required. The rest of the representation depends upon the relationship manageability model and discretion of the provider of a WS-Resource and relationship.
The Relationship Resource capability defines the following properties.
<muws2:Name>xs:string</muws2:Name> ?
muws2:Name is an element as defined by the Relationship/Name in section 4.1.2.2. It is OPTIONAL.
<muws2:Type>muws2:RelationshipTypeType</muws2:Type>
muws2:Type is an element as defined by the Relationship/Type in section 4.1.2.2. It is REQUIRED and can only appear once.
<muws2:Participant>
<muws1:ManageabilityEndpointReference/> *
<muws1:EndpointReference/>
*
<muws1:ResourceId/> ?
<muws2:Role>xs:anyURI</muws2:Role>
{any} *
</muws2:Participant>
muws2:Participant is an element as defined by the Relationship/Participant in section 4.1.2.2. This element MUST appear at least twice, and exactly once per participant in the relationship. Even though the optional Self element is still in the Participant element schema, the Self element should not be specified in participants of relationships when they are resources, as shown in the example above.
The muwse:RelationshipResourceCapability topic defined below is used for events related to the Relationship Resource capability.
<wstop:Topic name="RelationshipResourceCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
The manageability
capability URI for the Advertisement capability is
http://docs.oasis-open.org/wsdm/muws/capabilities/Advertisement
The Advertisement capability is exposed by a Web service that is able to provide a notification on the creation or the destruction of a manageable resource. Since a consumer cannot register for a notification on a resource before the resource is created, a creation event is reported for some other resource by the implementer of a “lifetime notification” capability.
Note that this capability may be implemented by a manageable resource or by some other service (see section 4 on the distinction between “manageability capability” and “management-related capability”. A service might offer a capability to notify on the creation or the destruction of a resource even though the service itself is not manageable. For example, if a system includes a registry, to which a resource is added as soon as it is created, and from which it is removed when it is destroyed, then this registry could expose the Advertisement capability and use it to share information about resource creation and destruction events with manageability consumers. Likewise, a resource factory might emit creation events for a resource it creates, yet the factory itself might not be manageable. Another example is a container, a J2EE server or a business process execution engine for example, that can send a notification when a contained resource is created.
This capability defines four topics used for notification but does not define any property or operation.
In addition to advertisement by sending notifications, as defined in this capability, another approach for advertisement is to register a manageable resource in a registry. A resource advertised in this way can be discovered using the mechanisms introduced in section 5.2.
The Advertisement capability defines four notification topics:
<wstop:Topic name=”ManageabilityEndpointCreation” messageTypes=”muws2:CreationNotification”>
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//muws1:ManagementEvent[count(muws2:CreationNotification)=1]
</wstop:MessagePattern>
<wstop:Topic name=”ManageableResourceCreation” messageTypes=”muws2:CreationNotification”>
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//muws1:ManagementEvent[count(muws2:CreationNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
<wstop:Topic name=”ManageabilityEndpointDestruction” messageTypes=”muws2:DestructionNotification”>
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//muws1:ManagementEvent[count(muws2:DestructionNotification)=1]
</wstop:MessagePattern>
<wstop:Topic name=”ManageableResourceDestruction” messageTypes=”muws2:DestructionNotification”/>
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//muws1:ManagementEvent[count(muws2:DestructionNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
The “muwse:ManageabilityEndpointCreation” topic corresponds to notification on the creation of a new manageability endpoint for a new or existing resource. A manageability endpoint may be created in conjunction with, or independent of, the creation of the manageable resource. A new manageability endpoint could be the first one for a resource or be an addition to others. An associated muws2:CreationNotification message contains the EPR of a newly created manageability endpoint.
The “muwse:ManageableResourceCreation” topic is a specialization of the “Manageability EndpointCreation” topic. This topic corresponds to the case where a resource itself is newly created. Note that if a resource is created that is not manageable (i.e. which does not have a manageability endpoint) no notification on this topic will be sent. If a resource and a manageability endpoint for the resource are created then a notification will be sent to a subscriber on this topic.
The “muwse:ManageabilityEndpointDestruction” topic corresponds to notification on the destruction of a manageability endpoint. It does not imply that the associated resource was destroyed. An associated muws2:DestructionNotification message contains the muws2:ResourceId that a newly destroyed manageability endpoint provided for the resource before its destruction.
The “muwse:ManageableResourceDestruction” topic is a specialization of the “ManageabilityEndpointDestruction” topic. This topic corresponds to the case where a resource itself is destroyed at the same time as the manageability endpoint. Note that if a resource is destroyed that is not manageable (i.e. which does not have a manageability endpoint) no notification on this topic will be sent. An associated muws2:DestructionNotification message contains the muws2:ResourceId that a newly destroyed manageability endpoint provided for the resource before its destruction.
The content element for these topics are described as follows:
<muws2:CreationNotification">
<muws1:ManageabilityEndpointReference"/> *
</muws2:CreationNotification">
muws2:CreationNotification/muws1:ManageabilityEndpointReference is a reference to the manageability endpoint of a newly created resource. There can be more than one such reference if there is more than one known manageability endpoint.
<muws2:DestructionNotification">
<muws1:ResourceId"/> ?
</muws2:DestructionNotification">
muws2:DestructionNotification/muws1:ResourceId is the ResourceId of a newly destroyed resource.
Many forms of discovery are supported by Web services. This specification does not prescribe a normative method for discovering manageability services. It is expected that discovery methods commonly used for Web services will be used as discovery methods for manageability services. The goal of discovery is to obtain the EPR of a manageability endpoint. The Advertisement capability (section 4.3), when supported, provides one way to facilitate discovery via events. This section also describes two other ways to discover manageable resources. These are just some of the discovery methods that can be used.
The only normative requirement relative to discovering manageability services is that a manageability service MUST provide the Identity capability as defined by MUWS. As a result of this requirement, a consumer can inspect the WSDL description for a Web service or attempt to use the Identity capability of a Web service to determine if a discovered service acts as a manageability service. If a discovered service provides at least the Identity capability as defined by MUWS, then it is a manageability service.
There are at least two scenarios in which a relationship can be used to discover a manageable resource.
The first scenario is when a manageable resource points to some other manageable resource through a relationship. A manageable resource that supports the Relationship capability enables discovery of an EPR for some other resource that participates in a relationship with the manageable resource. This is done by using the “Relationship” property defined in section 4.1.3 or invoking the operations defined in section 4.1.4. Any EPRs contained in such a response message may be used by the manageability consumer to disambiguate a manageable resource in an exchange of messages with a manageability endpoint.
The second scenario is when a consumer has access to a WS-Resource representing a relationship and the relationship has a manageable resource as a member. A consumer can then use the properties of the Relationship Resource capability to retrieve any EPRs of a manageable resource participating in the relationship.
In addition to emitting a notification on the creation and the destruction of a resource as defined by the Advertisement capability in section 4.3, a resource can be advertised to a registry by invoking an insertion interface of the registry. A consumer can then discover a manageable resource by invoking a query interface of the registry.
The WSRF WS-Service Group specification [WS-SG] defines a type of registry, along with the message exchanges used to interact with a registry of this type. It is RECOMMENDED that a registry used to discover a manageable resource conforms to the WS-Service Group specification and that the registry conform to the following additional constraints:
The service group SHOULD include as properties the following two elements:
<wssg:MembershipContentRule
MemberInterface=”muws1:Identity”
ContentElements=”muws1:ResourceId”>
<wssg:MembershipContentRule
MemberInterface=”muws1:ManageabilityCharacteristics”
ContentElements=”muws1:ManageabilityCapability”>
The service group MAY also have any other “MembershipContentRule”, including a rule with an empty value for both MemberInterface and ContentElements. In effect, this lifts any constraint on a member of the service group. The two membership content rules defined above are useful even in a service group with no effective constraint because they allow querying the service group on the “ResourceId” and “ManageabilityCapability” properties.
When adding a manageability endpoint for a resource to the membership of a service group using the “Add” operation, the requestor SHOULD include the muws1:ResourceId element of a manageable resource in a wssg:Add/wssg:Content element of a request, even if the service group supports additional membership content rules that would have permitted registration of a manageability endpoint in the service group without providing this content element. Similarly, if the manageable resource supports the Manageability Characteristics capability, then the consumer SHOULD include all the muws1:ManageabilityCapability elements of a manageable resource in a wssg:Add/wssg:Content element of a request, even if the service group supports additional membership content rules that would have permitted registration of the manageability endpoint in the service group without providing this content element.
Like any manageability endpoint, a manageability endpoint listed in a resource registry MUST implement the Identity capability defined in [MUWS Part 1]. In addition, in order to facilitate discovery, the manageability endpoint SHOULD implement the Manageability Characteristics capability as defined in [MUWS Part 1].
[MUWS Part 1]
Tim
Bray, et al., Extensible Markup Language (XML) 1.0 (Third Edition),
W3C Recommendation, February 2004, http://www.w3.org/TR/REC-xml
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/
[WSDL] Erik
Christensen, et al., Web services
Description Language (WSDL) 1.1, W3C Note, March 2001, http://www.w3.org/TR/wsdl
[WS-Resource] Steve
Graham, et al. Web Service Resource 1.2
(WS-Resource), OASIS Working Draft, October 2004, http://docs.oasis-open.org/wsrf/rw-2.wsdl
[WS-Addressing] Don Box, et al., Web services Addressing (WS-Addressing), W3C
Member Submission, August 2004, http://www.w3.org/TR/ws-addr-core
[WS-RP] Steve
Graham, et al., Web Services Resource
Properties 1.2 (WS-ResourceProperties), OASIS Working Draft, June 2004, http://docs.oasis-open.org/wsrf/rpw-2.wsdl
[XPath 1.0] James
Clark, et al., XML Path Language (XPath)
Version 1.0, W3C Recommendation, November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116
[WSN] Steve
Graham, et al., Web Services Base
Notification 1.2 (WS-BaseNotification), OASIS Working Draft, June 2004, http://docs.oasis-open.org/wsn/bw-2.wsdl
[WST] William
Vambenepe, Web Services Topics 1.2
(WS-Topics), OASIS Working Draft, Jully 2004, http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf
[RFC3066] IETF
(Internet Engineering Task Force). RFC 3066:
Tags for the Identification of Languages, ed. H. Alvestrand. 2001, http://www.ietf.org/rfc/rfc3066.txt
[WS-RL] Latha
Srinivasan, et al., Web Services Resource
Lifetime 1.2 (WS-ResourceLifetime), OASIS Working Draft, June 2004, http://docs.oasis-open.org/wsrf/rlw-2.wsdl
[WS-SG] Tom Maguire, et al., Web Services Service Group 1.2 (WS-ServiceGroup), OASIS Working Draft, June 2004, http://docs.oasis-open.org/wsrf/sgw-2.wsdl
[MOWS] Kirk Wilson, Web Services Distributed Management:Management of Web Services (WSDM-MOWS) 1.1, OASIS Committee Draft, February 2006, http://docs.oasis-open.org/wsdm/wsdm-mows-1.1-spec-cd-01.pdf
[SOAP] Don
Box, et al., Simple Object Access Protocol (SOAP) 1.1, W3C Note, May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[WS-RF] WSRF OASIS technical committee,
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf
[WSRMD] Steve
Graham, et al., Web Services Resource
Metadata 1.0 (WS-ResourceMetadataDescriptor), OASIS Working Draft, January
2006, http://www.oasis-open.org/
wsrf/wsrf-ws_resource_metadata_descriptor-1.0-spec-06.pdf
WSDM Management Using Web Services Part 2 Version 1.0 Acknowledgements
The following individuals were members of the committee when the WSDM MUWS Version 1.0 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.
In addition, the following non-member employees of member companies made contribution to the specification: Maryann Hondo, Ian Springer, John Gerken, David Melgar, Mitsunori Satomi.
WSDM Management Using Web Services Part 2 Version 1.1 Acknowledgements
The following people made contributions to the WSDM MUWS Version 1.1 specification: Vaughn Bullard, Fred Carter, David Cox, Zulah Eckert, Mark Ellison, Heather Kreger, Frederico Maciel, Bryan Murray, Richard Nikula, Mitsunori Satomi, Thomas Studwell, Kirk Wilson, Zhili Zhang with special thanks to Vaughn Bullard and Mark Ellison as editors.
The following individuals were members of the committee
while the WSDM MUWS Version 1.1 specification was developed and approved by the
technical committee: Guru Bhat, Jeff Bohren,
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 implementers 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/muws2-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://www.w3.org/2005/08/addressing"
schemaLocation="http://www.w3.org/2005/08/addressing/ws-addr.xsd"
/>
<xs:complexType
name="LangString">
<xs:simpleContent>
<xs:extension
base="xs:string">
<xs:attribute
ref="xml:lang" use="required" />
<xs:anyAttribute
namespace="##other" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!--
Begin properties for the Description capability -->
<xs:element
name="Caption" type="muws2:LangString" />
<xs:element
name="Description" type="muws2:LangString" />
<xs:element
name="Version" type="xs:string" />
<!--
End properties for the Description
capability -->
<xs:complexType
name="CategoryType">
<xs:sequence>
<xs:any
minOccurs="0" namespace="##any"
processContents="lax" />
</xs:sequence>
</xs:complexType>
<xs:complexType
name="StateType">
<xs:complexContent>
<xs:extension
base="muws2:CategoryType" />
</xs:complexContent>
</xs:complexType>
<xs:element
name="State" type="muws2:StateType" />
<xs:element
name="EnteredState" type="muws2:StateType" />
<xs:element
name="PreviousState" type="muws2:StateType" />
<xs:complexType
name="StateTransitionType">
<xs:sequence>
<xs:element
ref="muws2:EnteredState" />
<xs:element
ref="muws2:PreviousState" minOccurs="0" />
<xs:any
minOccurs="0" maxOccurs="unbounded"
namespace="##other" processContents="lax" />
</xs:sequence>
<xs:attribute
name="TransitionIdentifier" type="xs:anyURI" use="optional"
/>
<xs:attribute
name="Time" type="xs:dateTime" use="required"
/>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
<xs:element
name="StateTransition" type="muws2:StateTransitionType"
/>
<!--
Begin properties for the OperationalStatus capability -->
<xs:element
name="OperationalStatus">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="Available" />
<xs:enumeration
value="PartiallyAvailable" />
<xs:enumeration
value="Unavailable" />
<xs:enumeration
value="Unknown" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<!--
End properties for the
OperationalStatus capability -->
<xs:attributeGroup
name="MetricAttributes">
<xs:attribute
name="ResetAt" type="xs:dateTime" />
<xs:attribute
name="LastUpdated" type="xs:dateTime" />
<xs:attribute
name="Duration" type="xs:duration" />
</xs:attributeGroup>
<!--
Begin properties for the Metrics capability -->
<xs:element
name="CurrentTime" type="xs:dateTime" />
<!--
End properties for the Metrics
capability -->
<xs:complexType
name="RelationshipTypeType">
<xs:complexContent>
<xs:extension
base="muws2:CategoryType" />
</xs:complexContent>
</xs:complexType>
<xs:element
name="Self">
<xs:complexType
/>
</xs:element>
<xs:complexType
name="RelationshipParticipantType">
<xs:sequence>
<xs:element
ref="muws2:Self" minOccurs="0" />
<xs:element
ref="muws1:ManageabilityEndpointReference" minOccurs="0"
maxOccurs="unbounded" />
<xs:element
ref="muws1:EndpointReference" minOccurs="0"
maxOccurs="unbounded" />
<xs:element
ref="muws1:ResourceId" minOccurs="0" />
<xs:element
name="Role" type="xs:anyURI" />
<xs:any
minOccurs="0" maxOccurs="unbounded"
namespace="##other" processContents="lax" />
</xs:sequence>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
<!--
Begin properties for the RelationshipResource capability -->
<xs:element
name="Name" type="xs:string" />
<xs:element
name="Type" type="muws2:RelationshipTypeType" />
<xs:element
name="Participant" type="muws2:RelationshipParticipantType"
/>
<!--
End properties for the
RelationshipResource capability -->
<xs:complexType
name="RelationshipType">
<xs:sequence>
<xs:element
ref="muws2:Name" minOccurs="0" />
<xs:element
ref="muws2:Type" />
<xs:element
ref="muws2:Participant" minOccurs="2"
maxOccurs="unbounded" />
<xs:element
name="AccessEndpointReference"
type="wsa:EndpointReferenceType" minOccurs="0" />
<xs:any
minOccurs="0" maxOccurs="unbounded"
namespace="##other" processContents="lax" />
</xs:sequence>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
<!--
Begin properties for the Relationship capability -->
<xs:element
name="Relationship" type="muws2:RelationshipType" />
<!--
End properties for the Relationship
capability -->
<xs:element
name="RelationshipCreatedNotification">
<xs:complexType>
<xs:sequence>
<xs:element
ref="muws2:Relationship" />
<xs:any
minOccurs="0" maxOccurs="unbounded"
namespace="##other" processContents="lax" />
</xs:sequence>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
</xs:element>
<xs:element
name="RelationshipDeletedNotification">
<xs:complexType>
<xs:sequence>
<xs:element
ref="muws2:Relationship" />
<xs:any
minOccurs="0" maxOccurs="unbounded"
namespace="##other" processContents="lax" />
</xs:sequence>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
</xs:element>
<xs:element
name="QueryRelationshipsByType">
<xs:complexType>
<xs:sequence>
<xs:element
name="RequestedType" type="xs:QName" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="QueryRelationshipsByTypeResponse">
<xs:complexType>
<xs:sequence>
<xs:element
ref="muws2:Relationship" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="CreationNotification">
<xs:complexType>
<xs:sequence>
<xs:element
ref="muws1:ManageabilityEndpointReference" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
</xs:element>
<xs:element
name="DestructionNotification">
<xs:complexType>
<xs:sequence>
<xs:element
ref="muws1:ResourceId" minOccurs="0" />
</xs:sequence>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
</xs:element>
<xs:complexType
name="SituationCategoryType">
<xs:complexContent>
<xs:extension
base="muws2:CategoryType" />
</xs:complexContent>
</xs:complexType>
<xs:complexType
name="SubstitutableMsgType">
<xs:sequence>
<xs:element
name="Value" type="xs:anySimpleType"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute
name="MsgId" type="xs:string" use="required"
/>
<xs:attribute
name="MsgIdType" type="xs:anyURI" use="required"
/>
</xs:complexType>
<xs:complexType
name="SituationType">
<xs:sequence>
<xs:element
name="SituationCategory" type="muws2:SituationCategoryType"
/>
<xs:element
name="SuccessDisposition" minOccurs="0">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="Successful" />
<xs:enumeration
value="Unsuccessful" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element
name="SituationTime" type="xs:dateTime" />
<xs:element
name="Priority" type="xs:short" minOccurs="0"
/>
<xs:element
name="Severity" type="xs:short" minOccurs="0"
/>
<xs:element
name="Message" type="muws2:LangString"
minOccurs="0" />
<xs:element
name="SubstitutableMsg" type="muws2:SubstitutableMsgType"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:element
name="Situation" type="muws2:SituationType" />
<xs:complexType
name="EventCorrelationPropertiesType">
<xs:sequence>
<xs:element
name="repeatCount" minOccurs="0"
maxOccurs="1">
<xs:simpleType>
<xs:restriction
base="xs:short">
<xs:minInclusive
value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element
name="elapsedTime" minOccurs="0"
maxOccurs="1">
<xs:simpleType>
<xs:restriction
base="xs:long">
<xs:minInclusive
value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
<xs:attribute
name="sequenceNumber" type="xs:unsignedLong"/>
</xs:complexType>
<xs:element
name="EventCorrelationProperties"
type="muws2:EventCorrelationPropertiesType" />
<xs:complexType
name="MsgCatalogInformationType">
<xs:sequence>
<xs:element
name="msgCatalog" type="xs:anyURI" minOccurs="1"
/>
<xs:element
name="msgCatalogType" type="xs:anyURI"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:element
name="MsgCatalogInformation"
type="muws2:MsgCatalogInformationType" />
<!--
##### Metadata description
elements ##### -->
<xs:element
name="Capability" type="xs:anyURI" />
<xs:complexType
name="DialectableExpressionType" mixed="true">
<xs:sequence>
<xs:any
namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute
name="Dialect" type="xs:anyURI" use="required"
/>
<xs:anyAttribute
namespace="##other" />
</xs:complexType>
<xs:element
name="ValidWhile" type="muws2:DialectableExpressionType"
/>
<xs:element
name="Units" type="xs:string" />
<xs:element
name="ChangeType">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="Counter" />
<xs:enumeration
value="Gauge" />
<xs:enumeration
value="Unknown" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element
name="TimeScope">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="Interval" />
<xs:enumeration
value="PointInTime" />
<xs:enumeration
value="SinceReset" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element
name="GatheringTime">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="OnChange" />
<xs:enumeration
value="Periodic" />
<xs:enumeration
value="OnDemand" />
<xs:enumeration
value="Unknown" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element
name="CalculationInterval" type="xs:duration" />
<xs:element
name="MetricGroup" type="xs:anyURI" />
<xs:element
name="PostCondition" type="muws2:DialectableExpressionType"
/>
<!--
========= StartSituation ============
-->
<xs:element
name="StartSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="StartInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StartSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="RestartInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StartSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="StartCompleted">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StartSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= StopSituation ============
-->
<xs:element
name="StopSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="StopInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StopSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="AbortInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StopSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="PauseInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StopSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="StopCompleted">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:StopSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= RequestSituation ============
-->
<xs:element
name="RequestSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="RequestInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:RequestSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="RequestCompleted">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:RequestSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= DestroySituation ============
-->
<xs:element
name="DestroySituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="DestroyInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:DestroySituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="DestroyCompleted">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:DestroySituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= CreateSituation ============
-->
<xs:element
name="CreateSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="CreateInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:CreateSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="CreateCompleted">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:CreateSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= ConnectSituation ============
-->
<xs:element
name="ConnectSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="ConnectInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ConnectSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="ReconnectInitiated">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ConnectSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="ConnectCompleted">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ConnectSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= ReportSituation ============
-->
<xs:element
name="ReportSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="PerformanceReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="SecurityReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="HeartbeatReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="StatusReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="TraceReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="DebugReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element
name="LogReport">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType">
<xs:sequence>
<xs:element
ref="muws2:ReportSituation" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= AvailabilitySituation ============
-->
<xs:element
name="AvailabilitySituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= CapabilitySituation ============
-->
<xs:element
name="CapabilitySituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= ConfigureSituation ============
-->
<xs:element
name="ConfigureSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
========= OtherSituation ============
-->
<xs:element
name="OtherSituation">
<xs:complexType>
<xs:complexContent>
<xs:restriction
base="muws2:SituationCategoryType" />
</xs:complexContent>
</xs:complexType>
</xs:element>
<!--
SCHEMA
COPY Material
Copy and paste element references below
into the schema of a resource properties document.
These references insure that the
correct minOccurs/maxOccurs attributes are specified in a resource property
document schema.
NOTE: You must import the MUWS Part 2
schema namespace (MUWS2).
** Description Properties **
<xs:element
ref="muws2:Caption"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
ref="muws2:Description"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
ref="muws2:Version"
minOccurs="0"/>
** Operational Status **
<xs:element
ref="muws2:OperationalStatus"/>
** Metrics **
<xs:element
ref="muws2:CurrentTime"/>
** Relationship **
<xs:element
ref="muws2:Relationship"
minOccurs="0"
maxOccurs="unbounded"/>
** Relationship Resource **
<xs:element
ref="muws2:Name" minOccurs="0"/>
<xs:element ref="muws2:Type"/>
<xs:element
ref="muws2:Participant"
minOccurs="2"
maxOccurs="unbounded"/>
-->
</xs:schema>
<?xml
version="1.0" encoding="utf-8"?>
<definitions
targetNamespace="http://docs.oasis-open.org/wsdm/muws2-2.wsdl"
xmlns:muws-p2-wsdl="http://docs.oasis-open.org/wsdm/muws1-2.wsdl"
xmlns:muws2="http://docs.oasis-open.org/wsdm/muws2-2.xsd"
xmlns:muws1="http://docs.oasis-open.org/wsdm/muws1-2.xsd"
xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-1.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema
elementFormDefault="qualified"
targetNamespace="http://docs.oasis-open.org/wsdm/muws2-2.wsdl">
<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://docs.oasis-open.org/wsdm/muws1-2.xsd"
schemaLocation="http://docs.oasis-open.org/wsdm/muws1-2.xsd"/>
</xs:schema>
</types>
<message
name="QueryRelationshipsByTypeRequest">
<part name="body"
element="muws2:QueryRelationshipsByType"/>
</message>
<message
name="QueryRelationshipsByTypeResponse">
<part name="body"
element="muws2:QueryRelationshipsByTypeResponse"/>
</message>
</definitions>
<!--
WSDL
COPY Material
Copy and
paste the operation specification below into a portType definition of the WSDL
documents of a web service.
NOTE: You
must import the MUWS WSDL (wsdmmuws2-2).
<operation
name="QueryRelationshipsByType">
<input
name="QueryRelationshipsByTypeRequest"
message="muws-p2-wsdl:QueryRelationshipsByTypeRequest"/>
<output name="QueryRelationshipsByTypeResponse"
message="muws-p2-wsdl:QueryRelationshipsByTypeResponse"/>
</operation>
-->
<wstop:TopicSpace
name="MuwsNotificationTopics"
targetNamespace="http://docs.oasis-open.org/wsdm/muwse2-2.xml"
xmlns:muws1="http://docs.oasis-open.org/wsdm/muws1-2.xsd"
xmlns:muws2="http://docs.oasis-open.org/wsdm/muws2-2.xsd"
xmlns:wstop="http://docs.oasis-open.org/wsn/t-1.xsd"
xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-1.xsd">
<wstop:Topic
name="IdentityCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="ManageabilityCharacteristicsCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="CorrelatablePropertiesCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="DescriptionCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic name="StateCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="OperationalStatusCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="MetricsCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="ConfigurationCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="RelationshipsCapability"
messageTypes="muws1:ManagementEvent">
<wstop:Topic
name="RelationshipCreated"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[count(muws2:RelationshipCreatedNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
<wstop:Topic
name="RelationshipDeleted"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[count(muws2:RelationshipDeletedNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
<wstop:Topic
name="RelationshipResourceCapability"
messageTypes="muws1:ManagementEvent">
</wstop:Topic>
<wstop:Topic
name="ManageabilityEndpointCreation"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[count(muws2:CreationNotification)=1]
</wstop:MessagePattern>
<wstop:Topic
name="ManageableResourceCreation"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[count(muws2:CreationNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
<wstop:Topic
name="ManageabilityEndpointDestruction"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[count(muws2:DestructionNotification)=1]
</wstop:MessagePattern>
<wstop:Topic
name="ManageableResourceDestruction"
messageTypes="muws1:ManagementEvent">
<wstop:MessagePattern
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">
//muws1:ManagementEvent[count(muws2:DestructionNotification)=1]
</wstop:MessagePattern>
</wstop:Topic>
</wstop:Topic>
</wstop:TopicSpace>
This appendix defines in more details the situation types
introduced in section 2.5.1.
AvailabilitySituation
This category deals
with the situations reported from the component, regarding its operational
state and availability. This situation provides a context for operations that
can be performed by the component to establish if a product is installed,
operational and ready to process functional requests, or operational and ready
or not ready to process management requests.
Existing message include words like “now ready to take requests”,
“online”, and “offline”, for example::
·
“SOAP connector available at port 8888”
CapabilitySituation
This category is
specified when a change in capability of a resource occurs. For example, a
printer has an envelope tray attached to it so that the printer is now has
additional paper choices. The same
category would be used if the envelope tray is removed from the printer.
ConfigurationSituation
This category deals
with the components identifying configuration changes. Any changes that a
component makes to its configuration should be logged using this category.
Existing message include words like “port number is”, “address is”, and
“process id”, for example:
·
“File transfer configured with
host=’9.27.11.13’, port=’9090’, securityEnabled=’false’”
StopSituation
This category deals
with the shutdown process for a component. Messages that indicate that a
component has begun to stop, that it has stopped, or that the stopping process
has failed all fall into this category. Existing messages include words like
“stop”, “stopping”, “stopped”, “completed”, and “exiting”, for example:
·
“Application stopped: myApp.exe”
·
“An error occurred while stopping myApp.exe”
·
“Stopping the JMS provider”
StartSituation
This category deals
with the startup process for a component. Messages that indicate that a
component has begun the startup process, that it has finished the startup
process, or that it has aborted the startup process all fall into this
category. Existing messages include words like “starting”, “started”,
“initializing”, and “initialized”, for example:
·
“XYZ protocol support was successfully started”
·
“XYZ
protocol support failed to start”
·
“Starting
EJB: myEjb.jar”
RequestSituation
This category is
used in situations that a component uses to identify the completion
status of a request. Typically, these requests are complex management tasks or
transactions that a component undertakes on behalf of a requestor and not the
mainline simple requests or transactions. Existing messages are of the form “request
started” or “request completed” as in phrases like
“configuration synchronization started”, and “backup procedure complete”, for
example:
·
“Configuration synchronization completed”
Note that
events generated from requests that start up or stop a resource would be
categorized as StartSituation or StopSituation respectively because they
are higher precedent than RequestSituation.
DestroySituation
This category deals
with the situations occurring when an entity or component was removed or
destroyed. Messages telling that a document was destroyed or a file was deleted
all fall into this category. Existing messages include phrases like “was
destroyed”, “about to remove”, and “no longer exists”, for example:
·
“The connection pool was destroyed for data
source foo”
CreateSituation
This category deals
with the situations occurring when a component creates an entity. Messages
telling that a document was created, or a file was created, or an Enterprise
JavaBean (EJB) was created all fall into this category. Existing message
include words like was created, about to create, and now exists, for example:
·
“New log file was created”
DependencySituation
This category deals
with the situations where components cannot find some component or feature that
they require. This category includes messages about not finding the ”version”
of the component that was expected. Messages that say a resource was not found,
or that an application or subsystem that was unavailable, also fall into this
category. Existing messages include words like “could not find”, and “no such
component”, for example:
·
“Error encountered while deploying database
schema: no database found”
ConnectSituation
This category deals
with the situations related to aspects about a connection attempt from one
component to another component. Messages that say a connection failed, that a
connection was created, or that a connection was ended all fall into this
category. Existing messages include words like “connection reset”, “connection
failed”, and “failed to get a connection”, for example:
·
“Connection creation failed”
·
“Connection with http://foo.com created”
·
“Failed to close a connection”
ReportSituation
This
category deals with situations that occur as a result of some setting or
occurrence that causes the resource to asynchronously report various types of
data. Types of information that falls
into this category are:
·
Exception
related – some exception has occurred within the resource and it not
covered by any other category.
·
Performance
related – some event occurs, that does not fall into any other category,
that has affected performance in some way.
For example, weather conditions may be affected line quality and network
speeds are affected.
·
Security
related – some security issue has been detected, like the cabinet door to a
secure piece of equipment has been opened or an attack of some sort has been
detected.
·
Heartbeat
related – the resource has been configured to periodically report a ‘heartbeat’.
·
Status
related – some change of status that does not affect availability or
capability of the resource has been detected.
For example, printer ink cartridge is low.
·
Log
related – the resource has been configured to generate a log entry based on
some event or at a fixed interval. This
category identifies this event as a requested log entry.
·
Debug
related – the resource has been enabled to turn on diagnostic information
flow and will report the information within this category.
·
Trace related – the resource has been enabled to run
trace information and reports this information using this category
OtherSituation
This
category is for those events that do not fall into any other category. Note that this category is defined for
syntactic completeness but any events placed in this category will not be able
to be effectively correlated and its use is therefore discouraged unless
absolutely necessary.