MUWS specification v0.5 · Web viewTo subscribe, send an email message to [email protected] with the word “subscribe” as the body of the message. For

Web Services Distributed Management: Management Using Web Services (MUWS 0.5)

Committee Draft, 1 April 2004

Document identifier:cd-wsdm-muws-0.5-20040401

Location:http://docs.oasis-open.org/wsdm/2004/04/muws-0.5

Editors:Andreas Dharmawan, Westbridge Technology <[email protected]>William Vambenepe, Hewlett-Packard <[email protected]>

Abstract:There are two parts of Web services Distributed Management: Management Using Web services and Management of Web services. This specification defines the former. Management Using Web services defines how an Information Technology resource connected to a network provides the manageability interfaces such that it can be managed remotely using Web services technologies.

Status:This document is a committee draft approved by the WSDM TC. It is not intended to become an OASIS standard. There is no guarantee that any part of its content will appear in the final release specification, MUWS 1.0.Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to [email protected] 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 at:http://docs.oasis-open.org/wsdm/2004/04/muws-0.5-errata

wd-wsdm-muws-05 Created on 3/31/2004 11:48 AM3/26/2004 10:26 AMCopyright © OASIS Open 2003. All Rights Reserved. Page 1 of 41

1

2

3

4

5

67

89

101112

131415161718

192021222324252627282930313233

34

12

3

http://docs.oasis-open.org/wsdm/2004/04/muws-0.5-errata

http://docs.oasis-open.org/wsdm/2004/04/muws-0.5

Table of Contents

1 Introduction........................................................................................................................ 4

1.1 Terminology...............................................................................................................4

1.2 Notational conventions...............................................................................................4

2 Architecture........................................................................................................................ 6

2.1 Context......................................................................................................................6

2.2 Conceptual Model......................................................................................................7

2.3 Logical Model.............................................................................................................8

2.3.1 Role Definitions......................................................................................................9

2.4 Composability..........................................................................................................10

2.5 Processing Model.....................................................................................................11

2.5.1 Prerequisites........................................................................................................11

2.5.2 Discovery.............................................................................................................11

2.5.3 Interaction............................................................................................................11

3 Support from Web Services Platform................................................................................13

4 Manageability Capabilities................................................................................................14

4.1 Identity..................................................................................................................... 15

4.1.1 Definition.............................................................................................................15

4.1.2 Data Types..........................................................................................................16

4.1.3 Properties............................................................................................................16

4.2 State........................................................................................................................ 17

4.2.1 Definition.............................................................................................................17

4.2.2 Description of State Model...................................................................................18

4.2.3 Data Types..........................................................................................................19

4.2.4 Properties............................................................................................................19

4.2.5 Operations...........................................................................................................20

4.3 Metrics..................................................................................................................... 21

4.3.1 Definition.............................................................................................................21

4.3.2 Data Types..........................................................................................................22

4.3.3 Properties............................................................................................................23

4.3.4 Operations...........................................................................................................23

5 Discovery and Introspection..............................................................................................25

6 Defining a Manageability Interface....................................................................................26

7 References....................................................................................................................... 27

7.1 Normative................................................................................................................27wd-wsdm-muws-05 Created on 3/31/2004 11:48 AM3/26/2004 10:26 AMCopyright © OASIS Open 2003. All Rights Reserved. Page 2 of 41

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

6945

6

7.2 Non-normative.........................................................................................................28

Appendix A. Acknowledgements..........................................................................................29

Appendix B. Notices............................................................................................................31

Appendix C. Schemas (Normative)......................................................................................32

Appendix D. WSDL elements (Normative)............................................................................34

Appendix E. Web Services Platform....................................................................................36

Initial Focus.......................................................................................................................... 36

Properties........................................................................................................................ 36

Meta Data........................................................................................................................ 36

Addressing....................................................................................................................... 37

Notification....................................................................................................................... 37

Versioning........................................................................................................................ 37

Security............................................................................................................................ 38

Registration and Discovery...............................................................................................38

Future Focus........................................................................................................................ 38

Policy............................................................................................................................... 38

Name Resolution..............................................................................................................39

Transaction...................................................................................................................... 39

Flow................................................................................................................................. 39

Negotiation....................................................................................................................... 40


70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

78

9

1 IntroductionManagement Using Web Services (MUWS) enables management of distributed IT resources using Web services. Many different distributed complex IT resources have use different management interfaces. By leveraging the Web service technology, MUWS enables easier and more efficient IT management systems through by providing a flexible common framework for manageability interfaces that benefits from the features of Web services protocols. Universal management interoperability among across the many different varieties of distributed IT resources can be achieved using MUWS.

The types of management capabilities that exposed by MUWS allows to expose are the management capabilities generally expected in distributed IT management systems. Examples of manageability functions that can be performed via MUWS are include:

monitoring quality of services monitoring,

enforcing service level agreements enforcement

, task controlling tasks

, managing resource life-cycles, and so on.

MUWS is designed to meet the requirements defined in the MUWS Requirements document [MUWS REQS]. Whenever possible, MUWS leverages existing Web services specifications to ensure interoperability, adoptability, and extensibility.

There is a minimum set of manageability capabilities that the manageability provider must support in order to participate in MUWS. This minimum set of manageability capabilities is defined in this specification.

Additionally, this specification discusses the methods and mechanisms provided by MUWS to for discovering the manageability interfaces of the manageable IT resource is discussed in this specification..

Finally, the manageability interface itself also is defined in this specification.

To understand the various topics discussed in this specification, the reader should be familiar with the IT management concepts. In addition, the following assumptions are made:

The reader is familiar with the Web Services Architecture [WSA]

The reader is familiar with XML [XML1.0 3rd Edition] , XML Schema [XML Schema Part 1] [XML Schema Part 2], and XML Namespace [XNS]

The reader is familiar with WSDL [WSDL1.1], SOAP [SOAP1.1] , UDDI [UDDI]

The reader is familiar with WS-ResourceProperties [WS-ResourceProperties], WS-Addressing [WS-Addressing]

Section 3, 4, 5, 6 and appendices C (schemas) and D (WSDL elements) are normative specifications with the following exception: UML illustrations found in section 4 are non-normative. The rest of the document is a non-normative, explanatory material intended to ease the understanding...


91

92939495969798

99100101

102

103

104

105

106

107108109

110111112

113114115

116

117118

119

120121

122

123124

125126127128

1011

12

1.1 TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.2 Notational conventionsThis specification uses an informal syntax to describe the XML grammar of the messages making up the management interfaces. This syntax uses the following rules:

The syntax appears as an XML instance, but the values indicate the data types appear instead of values.

{any} is a placeholder for elements from some other namespace (like ##other in the XML Schema).

Characters are appended to attributes, elements, and {any} to indicate the The Cardinality of an attribute, element, or {any}, is indicated by appending characters to the item as follows:

? none,or one

* none, or more

+ one, or more

No character exactly one

Items contained within the square brackets, [ and ], are treated as a group.

Items separated by | and grouped within parentheses, ( and ), indicate syntactic alternatives.

Three consecutive periods, ... is are used in XML start elements to indicate that attributes from some other namespace are allowed.

The XML namespace prefixes, (defined below,) are used to indicate the namespace of the element being definedItem.

When defining operations, this specification uses pseudo-schema to describe the input and, (if appropriate,) output messages. A full WSDL description of all operations is available in the appendix of this specification.


129

130131132

133

134135

136137

138139

140141142

143

144

145

146

147

148149

150151

152153

154155156

157

1314

15

2 Architecture

2.1 ContextThis section provides a context for the WSDM MUWS Architecture. The MUWS Architecture makes use of the Web services Services Architecture (WSA).

WSA provides a common definition of a Web service, as well as a conceptual model and a context for understanding Web services and the relationships between its Web service components. It WSA describes the characteristics that are common to all Web services and describes some characteristics that are needed by many, but not all, Web services. Additionally, it is interoperability architecture.: Byit identifyingies those global elements of the global Web services network that are required in order to ensure interoperationbility between among Web services, WSA provides an architecture of interoperability for MUWS.

Since the Web services architectureWSA defines how to specify information and operations through WSDL interfaces, access through bindings, and discovery through endpoints. Therefore, it is consistent to use the Web services architectureWSA to describe,- as well as provide access to, and discoverability- of, the manageable components of the Web services architectureWSA itself. In fact, the this paradigm can be extended to by providinge the access to, and discoverability of, any manageable resource in the IT infrastructure.

The management interface of a resource can be exposed through a Web service interface in the same way as the functional interface. This is true even if Web services are not used to provide access to the functionality of the resource.

Figure 2.1-1 illustrates two possible methods a manageable Web service may use to fulfill management requests on an exposed resource.


158

159

160161

162163164165166167168

169170171172173174

175176177

178179

180

1811617

18

Figure 2.1-1, MUWS on IT Resource

With the first method, a manageability service interacts directly with an exposed resource through a supported management interface. For example, the manageability service may interact with an exposed resource supporting Java’s JMX facility, or interact with an exposed resource supporting a proprietary C API.

With the second method, the manageability service interacts indirectly with an exposed resource through a management agent acting as an intermediary. This management agent interacts either directly or indirectly with the exposed resource.

This second method enables existing management instrumentation of a resource to be exported through Web services to a management consumer.

Whether the manageability service uses the direct method or the indirect method, the management consumer is provided a consistent view of the management instrumentation of the exposed resource. The management consumer remains unaware of any legacy management agent, facillity or API utilized by the manageability service.

Using Web services to describe and provide access to a manageability interface for an exposed resource creates a consistent, cross platform, cross vendor, and potentially cross enterprise interaction model for consumers and producers of management information.

Creating a Web services to access manageability information of an exposed resource does not preclude alternate means to access this information. For example, a management consumer is able to use any and all of WSDM MUWS, SNMP or CIM/WBEM to access manageability information for an exposed resource.

2.2 Conceptual ModelThis MUWS specification defines how manageability of an arbitrary IT resource can be accessed via Web services. Manageability is one possible quality of a resource. Manageability is composed of a number of capabilities. Each capability has its own distinct semantics. Therefore, a manageable resource composes a set of manageability capabilities. Figure 2.3-1, relates the concepts necessary for management using Web servicesMUWS.

According to the concepts in the WSDL specification, a Web service is an aggregate of endpoints. Each endpoint each offering offers the Web service at an address and that is accessible according to a binding. A Web service has a some number of interfaces that are realized by all of its endpoints.

Each interface describes a set of named messages, that could be exchanged and their formats, that can be exchanged. Properly formatted messages could can be sent to the address of an endpoint’s address in a way prescribed by the binding. A description, either as (a document, or an artifact,) is composed of with definitions of interfaces and services. A description may contain definitions of interfaces, or definitions of services, or definitions of both. or either of the definitions.

In accordance with the Web services concepts expressed above, access to the manageability for a resource must be provided by an endpoint. We call such an endpoint a manageability endpoint. Implicitly, a manageability endpoint belongs to a manageability service, which has a number of manageability interfaces that are realized by manageability endpoints.

Thus, a single manageability interface represents all or part of a manageability capability. Similarly, a single manageability capability may be represented in by one or more interfaces. The semantics of a particular interface includes the description of a the set of possible message exchanges. The exchanges are which is rendered in as message formats grouped into one or more interfaces.wd-wsdm-muws-05 Created on 3/31/2004 11:48 AM3/26/2004 10:26 AMCopyright © OASIS Open 2003. All Rights Reserved. Page 7 of 41

182

183184185186

187188189

190191

192193194195

196197198

199200201202

203

204205206207208

209210211212

213214215216217218

219220221222

223224225226227

1920

21

For example, the ability to offer metrics could be captured in a “Metrics” UML model which is an instance of the manageability capability concept. The semantics of offering metrics could be rendered from the UML model into a WSDL interface description defined within a the “http://www.docs.oasis-open.org/wsdm/2004/04/manageability/metrics” namespace. That Such a rendering would be an instance of the manageability interface concept.

This specification defines the base set of manageability capabilities that could can be composed into a manageable resource or combined into aggregate capabilities. For example, a TotallyManagableResource uber-capability could be defined that includes all of the base manageability capabilities defined in this specification. Such an aggregate manageability capability could also be composed into a manageable resource, and in that sense, an aggregate manageability capability is conceptually the same as any other capability. However, this specification does not currently attempt to define (define or identify) the aggregate capabilities. Rather, this specification and focuses on the definition of the base set manageability capabilities.

Figure 2.3-1, MUWS Concepts

2.3 Logical ModelA manageability provider may provide the manageability quality capabilities for many resources. In other words a manageability provider may enable expose many resources become as manageable resources., instances of which belong to one instance of the Provider.

To accomplish this, a manageability provider maintains manageability endpoints. which A manageability endpoint provides a means to access to the one or more manageable resources. According to the our concepts conceptual definition, a manageable resource is a resource composed with any number of manageability capabilities composed into it. In order to compose capabilities into the manageable resource, a manageability provider supports the manageability capabilities that are are offered by the its manageability endpoints.

For example, a manageability provider could embed a piece of code into a resource to supporting the manageability capabilities into a of the resource, thus making a the resource manageable. A manageability Pprovider may could also support the manageability capabilities by deploying resources within a container that could add supports manageability quality capabilities to for all its resources.

The manageability consumer manages manageable resources. To manage in this context means to exert control and to obtain and interpret the information about the manageable resource. In


228229230231232

233234235236237238239240

241242

243

244

245246247

248249250251252253

254255256257258

259260

2223

24

Mark Ellison, 04/01/04,

my best guess on this one....

order to manage the manageable resource, the consumer accesses manageability endpoints and exercises the offered manageability capabilities offered by the endpoint.

To exercise in this context means to make use of the distinct semantics defined byof a given manageability capability. Essentially, the consumer exercises the an understanding of the semantics defined by a manageability capability, but exercises it this understanding on the an actual manageable resource. In a tTechnically sense, to exercise offered manageability capabilities it translates into being able to usinge a distinct group of properties, operations, events and metadata by exchanging messages with the manageability endpoint.

For example, consider a server with several disk drives. The manageability provider could be a piece of software process running on the machineserver. This manageability provider could allow each disk drive to become a manageable resource by providing a manageability endpoint for each disk drive a manageability endpoint. The implementation of these endpoints by the provider could use OS calls to access the disk drives. This pattern could be used to provide and expose (through the manageability endpoints) manageability capabilities exposed through manageability endpoints,, such as retrieving the amount of disk space available in each disk drive.

An IT management console, acting as a manageability consumer, could then exercise this manageability property by connecting to the manageability endpoints provided by the manageability provider. In Using this example, the management console could retrieve the amount of disk space available in on each disk drive.

Figure 2.4-1, MUWS Logical Model

2.3.1 Role DefinitionsThis section documents defines the roles and interactions that of the major components of the MUWS Architecture, as well asand related components, within the MUWS Architecture., will have during Management Using Web services. It This section is not intended to constrain the locus of implementation., but insteadRather, this section is intended to documents the required components, their roles, and how they interact. wd-wsdm-muws-05 Created on 3/31/2004 11:48 AM3/26/2004 10:26 AMCopyright © OASIS Open 2003. All Rights Reserved. Page 9 of 41

261262

263264265266267268

269270271272273274275

276277278279

280281

282

283284285286287

2526

27

NOTE: One application implementation may have be a single component with many roles or while another implementaion a full role may be implemented by a combinationcomposed of many different applicationsseveral components, each with an assigned role.

The major roles are the manageability consumer, the manageability provider, and the manageability resource. These roles are represented by the shaded boxes in the MUWS Logical Model (Figure 2.4.-1).

2.3.1.1 Manageability Consumer

The manageability consumer: does the following:

Consumes managementability information. about the resource

Manages, monitors, configures the resource (monitor, configure, etc).

Understands the manageability capabilities of the resource.

2.3.1.2 Manageability Provider

The manageability provider does the following:

Provides the manageability quality for a manageable resource, enabling a resource to become a manageable resource.

Provides management information for consumers (according to the manageability capabilities of the resource).

NOTE: The manageability Pprovider may be implemented in the manageable resource or it may not. The manageability provider may supply provide the manageability quality for more than one manageable resource. In other words, thisThus, the role of manageability provider is not intended to constrain the locus of implementation.

2.3.1.3 Manageable Resource

The Manageable Resource is an IT resource that can beis manageabled by via a WSDM MUWS based infrastructure. Because there are no restrictions on the locus of implementation, the manageable resource may, or may not, implement the role of manageability Pprovider of for the manageability service.

For An example, of a disk drive could beas a manageable resource was explained described in the example in section 2.4. The

A manageable resources does not have to be fine-grained. For exampleTo illustrate this point, a complete server could be a manageable resource. (and tThe manageability provider providing offering the manageability endpoint for theat “server” resource could can run either on the server, being made manageable or on another some other machine). At an even higher level of granularity, a server farm could be exposed as a single one manageable resource. For exampleTo illustrate this point, an IT management software package could act as a manageability provider and provideoffering a manageability endpoints for a the server farm, and exposing manageability capabilities. Examples of manageability capabilities might be such retrieving the cumulative aggregate available disk space available in for all the servers in on the farm, or, bringing up or down the all the servers in on the farm. This Such a manageability provider for the server farm could be implemented using a set of proprietary interfaces to for the servers composing on the farm. or, Alternatively, (if the servers are manageable resources,) by such a manageability provider could acting as a manageability consumer by accessing and aggregating the manageability capabilities of the servers on the farmand aggregating them.wd-wsdm-muws-05 Created on 3/31/2004 11:48 AM3/26/2004 10:26 AMCopyright © OASIS Open 2003. All Rights Reserved. Page 10 of 41

288289290

291292293

294

295

296

297

298

299

300

301302

303304

305306307308

309

310311312313

314315

316317318319320321322323324325326327328329

2829

30

2.4 ComposabilityMUWS specification allows the resource and its service to be manageable in a standard and interoperable manner. This is achieved by defining the manageability capabilities and interfaces of a resource. A resource may support both the manageability capabilities and functional capabilities. In which this case, it the resource may chose to allow managmanageability consumersers access to appropriate functional capabilities along with the manageability capabilities. Managers could discover such composition by inspecting the service description.

Managers could take advantage of the composition of manageability with functional capabilities by, for example, querying for free disk space using a disk manageability capability and along with thatthen reading disk sectors from the disk serviceusing a disk functional capability. This Composability makes it easy for implementers of the a resource services to offer an appropriate subset of functional capabilities along with its proper set of manageability capabilities.

2.5 Processing ModelThe cCompliant implementations of the roles as defined in section 2.3, the logical model, act according to the following basic processing rules.

2.5.1 PrerequisitesA manageability consumer and a manageability provider have toMUST understand the information model with in which the semantics of a manageability capability are described. For example, it could be a UML model that could expresses a group of properties, operations, events and metadata. The meaning of what the model defines has tomust be equally understood by both parties, provider and consumer. The bBase capabilities defined in MUWS, as well as those the capabilities defined in domain-specific specifications that builtd on top of MUWS, are the means to achievinge such an understanding.

A manageability consumer and a manageability provider both have to equallyMUST understand how to establish identify which manageability interface corresponds to which with a manageability capability, and vice versa. The base capabilities described Specification ofin WSDM MUWS manageability capabilities clearly indicates thatare the means to achieving such and understanding.

A manageability consumer has toMUST be able to obtain the description of the manageability service, its endpoints and necessary manageability interfaces. The manageability provider (,or another party on behalf of the provider,) makes such descriptions available to the consumer.

A manageability provider has toMUST be able to obtain the description of the manageability interfaces for the capabilities it wants to support. MUWS includes in-line descriptions, (usually as appendices,) of XML Schemas and WSDL elements for all of the manageability capabilities. It MUWS also indicates URL locations of such XML schema documents and WSDL documents hosted on the OASIS Web site.

2.5.2 DiscoveryA manageability consumer discovers the necessary manageable resources by discovering the manageable endpoints, reading their descriptions and exchanging messages as required. MUWS indicates which manageability capabilities can be used to discover other Web services endpoints and/or other manageability endpoints.

To discover manageable endpoints in the first place, the consumer uses the same discovery techniques in discoveringas used for any other Web service endpoints. For example, it the wd-wsdm-muws-05 Created on 3/31/2004 11:48 AM3/26/2004 10:26 AMCopyright © OASIS Open 2003. All Rights Reserved. Page 11 of 41

330

331332333334335336

337338339340341

342

343344

345

346347348349350351352

353354355356357

358359360

361362363364365

366

367368369370

371372

3132

33

consumer may be provided with a URL to referencing a WSDL document that describinges a the manageability service.

A manageability provider advertises, /registers, and /publishes available manageability endpoints just like any other Web service endpoints.

A manageability consumer establishes which capabilities are supported by the manageable resource either from the description of the manageability service or by exchanging messages with the manageability endpoint. For example, a consumer may inspect a WSDL document looking for manageability operations it is interested in. MUWS and the specifications that build on top of it clearly indicate which message Qnames correspond to which operations and which capabilities they participate in.

2.5.3 InteractionA manageability consumer exerts control over, and obtains information about, the manageable resource by exchanging messages with one or more manageability endpoints that providinge access to the manageable resource. Message exchanges must match theat format and sequence which isas prescribed by the binding description of the endpoint. This interaction is not any different than exchanging messages with any otherfunctional Web service endpoints.

Figure 2.5.3-1 captures the main principles of the processing model as described above. In this context, to interact means to exchange messages.

Figure 2.5.3-1, MUWS Basic Processing Model


373374

375376

377378379380381382

383

384385386387388

389390

391

392393

3435

36

3 Support from Web Services PlatformManagement Using Web Services (MUWS) is a foundation for management of all IT resource domains. It accomplishes thisat goal by using Web services features and standards to provide a flexible, scalable, distributed, and collaborative management framework. An overview of the features of this framework is provided in Appendix EF, "Web Services Platform." Furthermore, itAppendix E also provides details about these Web service features., theand motivatingion factors behind for using them Web services features in MUWS, and provides a non-normative analysis of what standards or capabilities should be leveraged to support themthese features.

MUWS leverages the Web Services Resources Framework ([WSRF]), in which, the MUWS manageable resources are represented by Web services as “resources”, (in the WSRF sense of the term). This implies that references to manageability endpoints in MUWS use the mechanism defined by WSRF, leveraging endpoint references (EPR) as defined by WS-Addressing.

If the manageability endpoint corresponds to a variable number (zero or more) of manageable resources, then the WSRF Implied Resource Pattern MUST be followed. This means that the element(s) listed in the ReferenceProperties of a WS-Resource qualified EPR must be included in the header of messages sent to such manageability endpoints. This specification does not currently define how to obtain the EPR. There may be an out-of-band agreement between provider and consumer on how to obtain EPRs or future versions of this specification would clarify this subject.

In the specific case where the a manageability endpoint corresponds to one and only one manageable resource, then, either the WSRF Implied Resource Pattern, (as above,) or the singleton WS-Resource implied pattern MUST be used. If the singleton WS-Resource implied pattern is used, this means that the manageability endpoint doesn't does not expect to receive the elements listed, indicating which resource is being managed, in the ReferenceProperties section of WS-Resource qualified EPRs in the message headers. to indicate which resource is being managed. A manageability consumer who does not have an EPR for a manageability endpoint MAY try to invoke manageability operations without including reference properties information. If this such an invocation succeeds, the manageability consumer knows that it is talking about a manageable resource through a manageability provider.

Furthermore, management properties defined in MUWS are represented as “properties”, (in the WSRF sense of the term), using the mechanisms defined in WS-ResourceProperties ([WS-ResourceProperties]). This means that each manageable resource exposes a resource properties document and makes it this document available as specified in WS-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-WS-ResourceProperties. More sSpecifically, this means the interface MUST include the GetResourceProperty operation defined by WS-ResourceProperties and MAY include the GetMultipleProperties, SetResourceProperties and QueryResourceProperties operations. If the QueryResourceProperties operation is provided, it SHOULD support the XPath 1.0 query expression dialect, represented by URI http://www.w3.org/TR/1999/REC-xpath-19991116.

For security, MUWS relies on generic Web services security mechanisms, including transport--level security and WSS SOAP Message SecuritySecurity as standardized by OASIS. MUWS 1.0 will include a more detailed “security considerations” section and will include corresponding supporting operations.


394

395396397398399400401

402403404405

406407408409410411412

413414415416417418419420421422

423424425426427

428429430431432433434

435436437438

3738

39

Events are not supported in MUWS 0.5 but will be supported in MUWS 1.0. To do so, MUWS 1.0 will leverage a Web services eventing mechanism.


439440

4041

42

4 Manageability CapabilitiesThere is a minimum set of manageability capabilities that the manageability provider must support in order to implement the MUWS specification.

Manageability capabilities define resource specific properties, operations and events. Details of these manageability capabilities are exposed by the manageable resource.

A manageable resource MAY also define new resource-specific manageability capabilities.

A manageable resource SHOULD extend a MUWS manageability capability when defining a resource-specific manageability capability that uses similar semantics. A manageable resource is not required to extend a MUWS manageability capability when defining a resource-specific manageability capability that uses conflicting semantics.

Each capability is formally expressed in a UML diagram using the following approach. Figure 4-1 expresses that a ManageableXSampleCapabilityY is a concept X manageability capability, which is also a manageability capability in a general, conceptual, sense. The name of the capability identifies the distinct semantics that the capability bears. Semantics is are then expressed in as properties, operations, events and metadata contained in the capability model representation (UML class).

Figure 4-1 Manageability Capability UML Sample

Properties and operations are expressed as regular UML properties and operations. The meaning of properties and operations is expressed in the text. Properties are defined with, and operations act upon, the information types that are captured by UML classes. SamplePropertyType1 is an example of such an information type. Simple information types may also be used directly when defining properties and operations. For example, xsd:int is an example of a simple information type that belongs to XML Schema Data Types UML package.

For As a simplification, of the look of the UML diagrams this document uses a convention that all simple information types having a name which name starts from with xsd: belong to that package. XML Schema simple information types, or (data types) , are defined by the W3C specification at http://www.w3.org/TR/xmlschema-2/.

Events are expressed as UML properties with an <<event>> strereotype. Name The name of the property is the name of the event. The text describes why and when an event occurs and the specific information that is generated or (captured) when it the event occurs. The information type of an event is captured in a UML class which contains proper information element definitions. SampleEventInformationType1 is an example of an event information type.


441

442443

444445

446

447448449450

451452453454455456

457458

459460461462463464

465466467468

469470471472473

4344

45

Optionality of properties and events is indicated by multiplicity of the corresponding model elements: [1] indicates that an element is mandatory, [0..1] indicates that an element is optional. For array properties, [0..*] indicates optional and [1..*] indicates mandatory.

The metadata about various model elements is captured as UML constrains. For example, sampleReadOnlyProperty has an {ro} constraint. This document uses the following common constraints in the models.

ro – means read only, applicable to properties,

rw – means read/write, applicable to properties.

const – means constant, does not change during runtime, applicable to properties.

In this section the following namespaces will be used unless specified otherwise. Table 4-1 describes what prefix corresponds to which namespace URI.

Prefix Namespace

muws-xs http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema

muws-wsdl http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/wsdl

wsdl http://www.w3.org/2002/07/wsdl

soap http://schemas.xmlsoap.org/wsdl/soap/

xs http://www.w3.org/2001/XMLSchema

Table 4-1 Manageability Capability Namespaces

XML elements and schema types introduced in this section belong to the muws-xs namespace.

WSDL elements introduced in this section belong to the muws-wsdl namespace.

4.1 Identity

4.1.1 DefinitionThe goal of Identity is to establish whether two entities are the same. This is a required capability and it MUST therefore be provided by every manageability service.s (Observe that this requirement doesn’t does not preclude the manageability service to haveusing a security policy that preventsing some requester to from accessing this a capability).

In addition, this interface is used as a “marker” interface to allow a consumer to know that the service that implements it is a manageability service. See section 2.5.2, “dDiscovery,” section for more additional information.

Figure 4.1.1-1 shows the UML representation of MUWS Identity.


474475476

477478479

480

481

482

483

484485

486

487

488

489

490

491492493494

495496497

498

499

4647

48

http://schemas/

http://www/

Figure 4.1.1-1 MUWS Identity

4.1.2 Data TypesThis specification does not define any data type to represent Identity.

4.1.3 PropertiesFollowing is the specification of the resource Identity properties (elements).

<ResourceId>xsd:anyURI</ResourceId><Name>xsd:string</Name>?<Version>xsd:string</Version>?

Following is an example excerpt from a resource properties instance document that contains these properties.

<ResourceId>http://example.com/resource/diskDrive/9F34AD35B</ResourceId><Name>The disk drive in Bob’s laptop</Name><Version>1.0</Version>

ResourceId is an opaque identifier of the resource managed through the manageability endpoint. It is a read-only mandatory property that has a cardinality of 1.

The following constraints are applicable to ResourceId:

Globally unique: A manageability endpoint MUST create the ResourceId URI in a way that ensures that the ResourceId is unique to the resource managed through the manageability endpoint and globally unique.. This specification does not prescribe the means by which global uniqueness is achieved.

Uniqueness in time: A given ResourceId MUST NOT be reused by any manageability endpoint for another resource, even after the original resource no longer exists.it was attached to has stopped existing.

Consistency across endpoints: A manageability provider SHOULD use the ResourceId that is suggested by the characteristics of the resource to identify the resource. The cases where Tthis is possible include when the ResourceId can be retrieved from the


500501

502

503

504

505

506

507508509

510

511512

513514515516

517

518519

520

521522523524

525526527

528529530

4950

51

resource by the manageability endpoint or when an application of MUWS to a given domain specifies a method to build the ResourceId based on characteristics of the resources within theat domain. It is not guaranteed that different manageability endpoints attached to the same resource will, in all cases. return the same ResourceId in all cases

Consistency within an endpoint: A manageability provider that exposes several manageability endpoints for the same resource SHOULD use the same ResourceId for all the manageability endpoints.

Persistence: A manageability endpoint SHOULD return the same ResourceId during the entire lifetime of the manageability endpoint, including across power cycles of the manageability endpoint. Resources which are not able to persist the ResourceId across power cycles of the manageability endpoint should SHOULD try to provide a consistent ResourceId via predictable identifier generation or delegation of Identity assignment. Managers may not be able to determine that if a resources which does cannot return provide the same ResourceId are the same resource and the a single resource may be treated as many resources.

Equality: If the ResourceIds are equal then the consumer MUST assume that the two manageability endpoints represent the same resource. However, a manageability consumer MUST NOT assume that two manageability endpoints are representing two different resources solely because the ResourceId is different. Two different ID’s could conceivably reference the same resource. It is strongly recommended that this condition be deliberately avoided in a conscious and deliberate manner, as some managers may not be able to ascertain distinguish that the two identifiers are, in fact, for attached to the same resource. and Thus, the managers may would be forced to treat every identifier as an attachment to an unique resource.

Since the ResourceId is defined as opaque, this specification does not allow the consumer to infer any characteristic of the resource by examining the ResourceId, other than comparing the ResourceId to another ResourceId as one way to establish oneness. For example, one possible way to construct the ResourceId and ensure its uniqueness is to use a UUID wrapped in a URI.

Note that this specification does not define equivalence of URIs and the consumer should decide which level of the comparison ladder defined in section 6 of [RFC2396bis] is appropriate to use for this comparison.

The following paragraph is a describesption of a mechanism, intended to be introduced in MUWS 1.0, called “correlatable names”. Thise mechanism is not available in MUWS 0.5.

The correlatable names mechanism is one of several possible mechanisms that can be used to solve the case wherewhen the ResourceId mechanism cannot provide certainty about the oneness of two resources. but not necessarily the only such mechanism. The correlate management capability can be used by the a resource manager to discern determine whether theif two different resouceIds, produced at different times, by the same manageability provider for the one an endpoint, represents the same endpoint.

The basic idea is to provide a list of properties that, if all are equal between two manageability endpoints, guarantees that the resource(s) behind the manageability endpoints are one. In the case where two ResourceIds match but the correlatable names doesn’t do not, a (this case that is not allowed, but can’t can not be guaranteed that it will never to happen), the resource is considered to be the same. This is because the ResourceId has the precedence over the correlatable name.

Name is a string containing a descriptive name for the resource being managed. The Name is intended for human consumption. It is a read-write optional property that has a cardinality of 0..1.


531532533534

535536537

538539540541542543544545

546547548549550551552553554

555556557558559

560561562

563564

565566567568569570

571572573574575576

577578

5253

54

Version is a string representing the version of the resource being managed. MUWS doesn’t does not specify how this string is constructed. This The version string can be specified by any domain-specific specifications that use MUWS. It Version is a read-write optional property that haswith a cardinality of 0..1.

4.2 State

4.2.1 DefinitionThe goal of this section is to define a state model for any IT resource and state management capabilities through Web services. The state model must MUST support the state change capabilities and the events for lifecycle and/or status changes. Additionally, the state model must MUST be extensible.

Figure 4.2.1-1 shows the resource state model without any sub-states.

Figure 4.2.1-1 Resource State Model

Figure 4.2.1-2 shows the UML representation of MUWS State.

Figure 4.2.1-2 MUWS State

4.2.2 Description of State ModelThe following are the identifiers of the valid top-level resource states.


579580581582

583

584

585586587588

589

590591

592

593594

595

596

5975556

57

http://docs.oasis-open.org/wsdm/2004/04/muws/state/availableThis corresponds to the Available state in the UML diagram. In this state, the resource is able to perform all functional tasks it is designed to perform.

http://docs.oasis-open.org/wsdm/2004/04/muws/state/degradedThis corresponds to the Degraded state in the UML diagram. In this state, the resource is able to perform some but not all functional tasks it is designed to perform.

http://docs.oasis-open.org/wsdm/2004/04/muws/state/unavailableThis corresponds to the Unavailable state in the UML diagram. In this state, the resource is not able to perform any of the functional tasks it is designed to perform.

The states defined by this specification are intended to be generic states that are relevant for any type of resource. Implementers SHOULD reuse existing states if they are appropriate for their resources. Implementers are sole judges in deciding what states are appropriate and it is expected that new states will be defined (and therefore new URIs created to represent them), for example if the existing states do not cover the intended meaning or if the existing states are too general and the implementer wishes to expose a more specific state description. Just like they MAY create new states, implementers MAY create new transitions between any two states (the two states don't need to have been defined by the same people). Note that until MUWS defines a way to represent the state model for a resource, "creating a new transition" just means writing some text to explain that a resource's state can change from one state to another. Finally, it is expected that MUWS 1.0 will define a way for states to be defined as sub-states of another state, at which point the specification will have specifications and recommendations on using this mechanism.

The following table lists the valid transitions between the top-level resource states.

Start State End State

Available Degraded

Available Unavailable

Degraded Available

Degraded Unavailable

Unavailable Available

4.2.3 Data TypesFollowing is the schema fragment that declares the (reusable) data types used to manage the resource state.

<xs:complexType name="StateInformation"><xs:sequence>

<xs:element name="State" type="xs:anyURI"/><xs:element name="TimeEntered" type="xs:dateTime"/>


598599600

601602603604

605606607608609610611612613614615616617618619620621622

623

624

625

626

627628

629

630631632633

5859

60

</xs:sequence></xs:complexType>

(StateInformation) type contains information about a resource state.

(StateInformation)/State is an identifier of a resource state.

(StateInformation)/TimeEntered is time at which the resource entered the identified state.

4.2.4 PropertiesFollowing is the specification of the resource state properties (elements).

<ResourceState>StateInformation</ResourceState>

Following is an example excerpt from a resource properties instance document that contains this property.

<ResourceState><State> http://docs.oasis-open.org/wsdm/2004/04/muws/state/available</State><TimeEntered>2004-03-11T11:30:56Z</TimeEntered>

</ResourceState>

ResourceState contains information about the current state of the resource (current at the moment of retrieving this property). It is a read-only mandatory property that has a cardinality of 1.

4.2.5 OperationsFollowing are the definitions of the messages that can be exchanged to perform operations on the resource state.

4.2.5.1 Start

Request:

<Start/>

Reply:

<StartOK/>

Upon receiving a request for a Start operation, manageability provider attempts to change the resource state from Unavailable state to Available state according to the UML diagram. If the transition completes, this operation completes successfully. If the resource is already in the Available state, this operation completes successfully.


634635

636

637

638

639

640

641

642

643

644645

646647648649650651

652

653654655

656

657658

659

660

661

662

663

664

665

666667668669

6162

63

http://www.docs.oasis-open.org/wsdm/2004/04/muws/state/available

4.2.5.2 Stop

Request:

<Stop/>

Reply:

<StopOK/>

Upon receiving a request for a Stop operation, manageability provider attempts to change the resource state from Available or Degraded state to Unavailable state according to the UML diagram. If the proper transition completes, this operation completes successfully. If the resource is already in the Unavailable state, this operation completes successfully.

4.3 Metrics

4.3.1 DefinitionMetrics are a specific type of property. Metrics represent collected values and have a related collection period.

The goal of this section is to describe the characteristics of a typical property used to represent collected numerical, called Metrics. A common characteristic of metrics is that they change overtime and can be reset.

Figure 4.3.1-1 presents the Metrics capability in context.

Figure 4.3.1-1 MUWS Metrics

As a simple example, consider a toll bridge and 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; it represents the current configuration of the bridge. You 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 collection (counting) the number of cars, which is typically done over some duration, such as the last hour, the last day or even since the bridge was constructed. You can reset the number of cars, for example at the start of a new interval.


670

671

672

673

674

675

676

677678679680

681

682

683

684685

686687688

689

690

691692

693694695696697698699

6465

66

When accessing metrics, the time represented by the metric is typically required. In the example, above would be useful to know that a number of 500 represented the number of cars that have passed over the bridge in the last 3 minutes. Similarly, if data is posted periodically, there are cases when it is useful to know the last time the data was updated. For this reason, the standard data type for Metrics allows for both reset time and updated time attributes. However, both are optional.

When looking at a value, it is important to have a notion of how changes to that metric are to be interpreted. That notion is defined as a change type. Metrics have two (2) change types:

Counter, increments with usage

Gauge, moves between a range of values

Metrics can be reset either periodically, such as 'once a day', or on demand. The meaning of resetting a metric varies with each metric and should be clarified, if needed, in the description of a metric. Often, resetting a metric means setting its base or initial value, which is typically zero, but this is not mandatory. (Note that this specification provides no specific means for the scheduling of reset operations.)

4.3.2 Data TypesFollowing is the schema fragment that declares the (reusable) data types used to manage the resource metrics. All attributes defined in the MetricAttributes attribute group are optional.

<xs:attributeGroup name="MetricAttributes"><xs:attribute name="ResetAt" type="xs:dateTime"/><xs:attribute name="LastUpdated" type="xs:dateTime"/><xs:attribute name="ChangeType">

<xs:simpleType><xs:restriction base="xs:string">

<xs:enumeration value="Counter"/><xs:enumeration value="Gauge"/>

</xs:restriction></xs:simpleType>

</xs:attribute><xs:attribute name="TimeScope">


<xs:enumeration value="Interval"/><xs:enumeration value="PointInTime"/><xs:enumeration value="SinceReset"/>


</xs:attribute><xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:attributeGroup>

(MetricAttributes) attribute group has to be included in every metric type or metric property element declaration.

(MetricAttributes)/ResetAt indicates time when a particular metric has been reset. UTC or Z-coded!

(MetricAttributes)/LastUpdated indicates time when a particular metric value was last updated.


700701702703704705

706707

708

709

710711712713714

715

716717

718

719720721722723724725726727728729730731732733734735736737738739740

741

742743

744745

746

6768

69

(MetricAttributes)/ChangeType indicates a type of change pattern supported by a particular metric.

Counter declares an incrementally increasing metric value. Gauge declares a metric value that can increase and decrease.

(MetricAttributes)/TimeScope indicates a time interval which is used to calculate a particular metric.

Interval declares that a metric value is calculated within a certain time interval. Usually the interval would be defined by the metric property specification. For example, a RequestsPerSecond is an interval metric.

PointInTime declares that a metric value is calculated for the moment of retrieving a metric property. For example, CurrentTemperature is a point-in-time metric.

SinceReset declares that a metric value is calculated since ResetAt time mark.The following three types are defined for metrics that are integers, durations or times. Specifications that use MUWS to create manageability properties applicable to specific domains are free to use these types or to create new metric types by including the MetricAttributes attribute group in their types.

<xs:complexType name="IntegerMetric"><xs:simpleContent>

<xs:extension base="xs:integer"><xs:attributeGroup ref="muws-xs:MetricAttributes"/><xs:anyAttribute namespace="##other"

processContents="lax"/></xs:extension>

</xs:simpleContent> </xs:complexType>

(IntegerMetric) type declares an xsd:integer metric.

<xs:complexType name="DurationMetric"><xs:simpleContent>

<xs:extension base="xs:duration"><xs:attributeGroup ref="muws-xs:MetricAttributes"/><xs:anyAttribute namespace="##other"

processContents="lax"/></xs:extension>

</xs:simpleContent> </xs:complexType>

(DurationMetric) type declares an xs:duration metric.

4.3.3 PropertiesFollowing is the specification of the resource metrics properties (elements).

<CurrentTime>xs:dateTime</CurrentTime>


747748749750751752753754755756757758759760761762

763764765766767768769770771

772

773

774

775776777778779780781782783

784785

786

787

788

789

790

791

7071

72

Following is an example excerpt from a resource properties instance document that contains this property.

<CurrentTime>2004-03-11T11:30:56Z</CurrentTime>

CurrentTime contains information about the current time at the manageability provider (current at the moment of retrieving this property). This property is meant to help manageability consumers interpret times received from the manageability endpoint in the absence of a time synchronization mechanism. It is a read-only mandatory property that has a cardinality of 1.

The Metrics capability requires that the CurrentTime property be present, providing a reference point for the time-based attributes defined for the metric data types. (Note that CurrentTime is not a metric, it is a property of type xsd:dateTime that is defined as part of the “Metrics” capability, consequently, the ResetAll() operation has no effect on it.)

4.3.4 OperationsFollowing are the definitions of the messages that can be exchanged to perform operations on the resource metrics.

4.3.4.1 ResetAll

Request:<ResetAll/>

Reply:<ResetAllOK/>

Upon receiving a request for a ResetAll operation, manageability provider resets values of all metrics that it is collecting. Metrics may be grouped into logical groups that can be reset individually through some other mechanisms. However, this action indicates that all metrics be reset. A manageability consumer MUST NOT assume that different metrics are reset at the same time, even if they are provided by the same manageability endpoint.


792793

794

795

796

797798799800

801802803804

805

806807

808

809810

811

812813

814

815816817818819

7374

75

5 Discovery and IntrospectionMany forms of discovery are supported by Web services. This specification does not normatively prescribe specific ways of discovering manageability services. It is expected that the discovery methods commonly used for Web services will be used for manageability Web services.

The only normative requirement in this specification that applies to discovery is the need for a manageability service to provide the Identity capability, through the corresponding WSDL interface defined by this specification. As a result, when a consumer discovers a WSDL description for a Web service (through any discovery mean), it is able to determine whether or not the service acts as a manageability service by checking whether the service implements the Identity interface defined by MUWS.


820

821822823

824825826827828829

7677

78

6 Defining a Manageability InterfaceThe following are normative statements for MUWS representation.

WSDL 1.1 must be used.

Additionally, WSDM defines portTypes which have to be manually put together into a custom portType operation by operation according to the WSDL specification.

Document/literal binding must be used.

WSDM defines property elements which have to be manually put together into a custom properties document according to WS-ResourceProperties specification


830

831

832

833834

835

836837

838

7980

81

7 References

7.1 Normative[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[XML Schema Part 1]Henry S. Thompson, et al. XML Schema Part 1: Structures, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/

[XML Schema Part 2]Paul V. Biron, et al. XML Schema Part 2: Datatypes, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-2/

[XML1.0 3rd Edition]Tim Bray, et al., Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, February 2004, http://www.w3.org/TR/REC-xml

[XNS] Tim Bray, et al., Extensible Namespaces in XML, W3C Recommendation, January 1999, http://www.w3.org/TR/REC-xml-names/

[SOAP1.1] Don Box, et al., Simple Object Access Protocol (SOAP) 1.1, W3CNote, May 2000, http://www.w3.org/TR/soap11/

[WSDL1.1] Erik Christensen, et al., Web services Description Language (WSDL) 1.1, W3C Note, March 2001, http://www.w3.org/TR/wsdl

[UDDI] Tom Bellwood, et al., Web UDDI Version 3.0, UDDI Spec Technical Committee Specification, July 2003, http://uddi.org/pubs/uddi-v3.00-published-20020719.htm

[WSA] David Booth, et al. Web Servics Architecture, W3C Working Group Note, February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

[WSRF] Karl Czajkowski, et al. The WS-Resource Framework version 1.0, http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-1-0.pdf and related documents available at http://devresource.hp.com/drc/specifications/wsrf/index.jsp

[WS-ResourceProperties]


839

840

841842

843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878

8283

84

http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-1-0.pdf

http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-1-0.pdf

http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

http://uddi.org/pubs/uddi-v3.00-published-20020719.htm

http://uddi.org/pubs/uddi-v3.00-published-20020719.htm

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/REC-xml



Steve Graham, et al., Web service Resource Properties version 1.1, January 2004, http://devresource.hp.com/drc/specifications/wsrf/WS-ResourceProperties-1-1.pdf

[WS-Addressing] Don Box, et al., Web services Addressing, March 2003, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-addressing.asp

7.2 Non-normative[RFC2396bis] T. Berners-Lee, et al., Uniform Resource Identifier (URI): Generic

Syntax, IETF RFC 2396bis-04, February 2004, http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-04.txt

[MUWS REQS] Pankaj Kumar, et al., Requirements – Management Using Web Services, Committee Draft, October 2003, http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/6185/WSDM-MUWS-Req-committee-draft-1.0-20031002.pdf


879880881

882883884885

886887

888

889890891

892893894895896

897

8586

87

http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/6185/WSDM-MUWS-Req-committee-draft-1.0-20031002.pdf

http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/6185/WSDM-MUWS-Req-committee-draft-1.0-20031002.pdf

http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-04.txt

Appendix A. AcknowledgementsThe following people made contributions to this specification:

Winston Bumpus <[email protected]>

Brian Carol <[email protected]>

Fred Carter <[email protected]>

John DeCarlo <[email protected]>

Andreas Dharmawan <[email protected]>

Mark Ellison <[email protected]>

Heather Kreger <[email protected]>

Hal Lockhart <[email protected]>

Bryan Murray <[email protected]>

Richard Nikula <[email protected]>

Micheal Perks <[email protected]>

Homayoun Pourheidari <[email protected]>

Karl Schopmeyer <[email protected]>

Igor Sedukhin <[email protected]>

Ellen Stokes <[email protected]>

William Vambenepe <[email protected]>

Andrea Westerinen <[email protected]>

The following individuals were voting members of the committee during the development of this specification:

Guru Bhat <[email protected]>

Jeff Bohren <[email protected]>

Winston Bumpus <[email protected]>

Fred Carter <[email protected]>

John DeCarlo <[email protected]>

Andreas Dharmawan <[email protected]>

Mark Ellison <[email protected]>

Daniel Foody <[email protected]>

Heather Kreger <[email protected]>

Bryan Murray <[email protected]>


898

899

900

901

902

903

904

905

906

907

908

909

910

911

912

913

914

915

916

917

918919

920

921

922

923

924

925

926

927

928

929

8889

90

Paul Lipton <[email protected]>

Hal Lockhart <[email protected]>

Rajiv Maheshwari <[email protected]>

Richard Nikula <[email protected]>

Michael Perks <[email protected]>

Homayoun Pourheidari <[email protected]>

Karl Schopmeyer <[email protected]>

Igor Sedukhin <[email protected]>

Davanum Srinivas <[email protected]>

Ellen Stokes <[email protected]>

Thomas Studwell <[email protected]>

Ryoichi Ueda <[email protected]>

William Vambenepe <[email protected]>

Andrea Westerinen <[email protected]>

Concepts for the "Metrics" section were inspired by work from the DMTF applications/Metrics WG.


930

931

932

933

934

935

936

937

938

939

940

941

942

943

944

945946

9192

93

Appendix B. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2003. 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.


947

948949950951952953954955956

957958959

960

961962963964965966967968969

970971

972973974975976

977

978

979

980

981

9495

96

Appendix C. Schemas (Normative)<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:muws-xs="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema"targetNamespace="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema"elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="ResourceId" type="xs:anyURI"/><xs:element name="Name" type="xs:string"/><xs:element name="Version" type="xs:string"/>

<xs:complexType name="StateInformation"><xs:sequence>

<xs:element name="State" type="xs:anyURI"/><xs:element name="TimeEntered" type="xs:dateTime"/>

</xs:sequence></xs:complexType>

<xs:element name="ResourceState" type="muws-xs:StateInformation"/>

<xs:attributeGroup name="MetricAttributes"><xs:attribute name="ResetAt" type="xs:dateTime"/><xs:attribute name="LastUpdated" type="xs:dateTime"/><xs:attribute name="ChangeType">


<xs:enumeration value="Counter"/><xs:enumeration value="Gauge"/>


</xs:attribute><xs:attribute name="TimeScope">


<xs:enumeration value="Interval"/><xs:enumeration value="PointInTime"/><xs:enumeration value="SinceReset"/>


</xs:attribute><xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:attributeGroup>

<xs:complexType name="IntegerMetric"><xs:simpleContent>

<xs:extension base="xs:integer"><xs:attributeGroup ref="muws-xs:MetricAttributes"/><xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:extension></xs:simpleContent>

</xs:complexType>

<xs:complexType name="DurationMetric">


982983984985986987988989990991992993994995996997998999

10001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034

9798

99

<xs:simpleContent><xs:extension base="xs:duration">

<xs:attributeGroup ref="muws-xs:MetricAttributes"/><xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:extension></xs:simpleContent>

</xs:complexType>

<xs:element name="CurrentTime" type="xs:dateTime"/>

<xs:complexType name="ResourceIdentityPropertiesType"><xs:sequence><xs:element ref="muws-xs:ResourceId"/><xs:element ref="muws-xs:Name" minOccurs="0"/><xs:element ref="muws-xs:Version" minOccurs="0"/><xs:any minOccurs="0" maxOccurs="unbounded"/></xs:sequence>

</xs:complexType>

<xs:element name="ResourceIdentityProperties" type="muws-xs:ResourceIdentityPropertiesType"/>

<xs:complexType name="ResourceStatePropertiesType"><xs:sequence><xs:element ref="muws-xs:ResourceState"/><xs:any minOccurs="0" maxOccurs="unbounded"/></xs:sequence>

</xs:complexType>

<xs:element name="ResourceStateProperties" type="muws-xs:ResourceStatePropertiesType"/>

<xs:complexType name="ResourceMetricsPropertiesType"><xs:sequence><xs:element ref="muws-xs:CurrentTime"/><xs:any minOccurs="0" maxOccurs="unbounded"/></xs:sequence>

</xs:complexType>

<xs:element name="ResourceMetricsProperties" type="muws-xs:ResourceMetricsPropertiesType"/>

<xs:element name="Start"><xs:complexType/></xs:element><xs:element name="StartOK"><xs:complexType/></xs:element>

<xs:element name="Stop"><xs:complexType/></xs:element><xs:element name="StopOK"><xs:complexType/></xs:element>

<xs:element name="ResetAll"><xs:complexType/></xs:element><xs:element name="ResetAllOK"><xs:complexType/></xs:element></xs:schema>


103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085

100101

102

Appendix D. WSDL elements (Normative)<?xml version="1.0" encoding="utf-8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns:wsrp="http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties" xmlns:muws-xs="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema"xmlns:muws-wsdl="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/wsdl"targetNamespace="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/wsdl">

<types> <xs:schema elementFormDefault="qualified"

targetNamespace="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/wsdl">

<xs:import namespace="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema" schemaLocation="http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema"/>

</xs:schema> </types> <message name="StartRequest">

<part name="body" element="muws-xs:Start"/> </message> <message name="StartResponse">

<part name="body" element="muws-xs:StartOK"/> </message> <message name="StopRequest">

<part name="body" element="muws-xs:Stop"/> </message> <message name="StopResponse">

<part name="body" element="muws-xs:StopOK"/> </message> <message name="ResetAllRequest">

<part name="body" element="muws-xs:ResetAll"/> </message> <message name="ResetAllResponse">

<part name="body" element="muws-xs:ResetAllOK"/> </message>

<portType name="Identity" wsrp:ResourceProperties="muws-xs:IdentityProperties"/>

<portType name="ResourceState" wsrp:ResourceProperties="muws-xs:ResourceStateProperties">

<operation name="Start"> <input name="StartRequest" message="muws-wsdl:StartRequest"/> <output name="StartResponse" message="muws-wsdl:StartResponse"/> </operation>


10861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138

103104

105

<operation name="Stop"> <input name="StopRequest" message="muws-wsdl:StopRequest"/> <output name="StopResponse" message="muws-wsdl:StopResponse"/> </operation> </portType> <portType name="Metrics"

wsrp:ResourceProperties="muws-xs:MetricsProperties"> <operation name="ResetAll"> <input name="ResetAllRequest" message="muws-wsdl:ResetAllRequest"/> <output name="ResetAllResponse" message="muws-wsdl:ResetAllResponse"/> </operation> </portType></definitions>


1139114011411142114311441145114611471148114911501151115211531154

106107

108

Appendix E. Web Services PlatformThis section briefly describes the Web services platform features that are required in order to specify management using Web services and recommendations for how to support each feature. Recommendations will either reference another specification to be used to provide the feature, identify the feature to be provided by the industry in the future, or identify the feature that the WSDM TC must define in an interim specification until one is available for the Web services platform.

Initial Focus The following features must be supported by the Web services platform depended upon by the current version of the MUWS specification.

PropertiesProperties are describable information that can be queried and may be written. Properties may be provided by a Web service interface with a schema (data type and name) of the properties and operations (message exchanges) to find, read and write them. Property declarations (names) and descriptions (types) should be introspect-able at design time and at runtime. For manageability, a property is part of the advertised manageability interface for a resource. A property can be used to represent configuration values, metrics, identifiers, etc.

Motivation: Many manageability capabilities of a manageable resource take the form of information about the resource that the manager is able to query and set. Such information should be modeled as a set of properties with access methods that allow access to it in ways that meet the scalability requirements of management applications, e.g. bulk get.

Recommendation: Use the WS-Resource Properties specification [WS-ResouceProperty] to describe the properties of a manageable resource.

Meta Data Meta data is generally defined as data about data. In the context of management, it is additional descriptive information about all the components of a manageability interface, including properties, operations, events, capabilities, the context, quality and condition, or characteristics of the data. Meta data can be introspected at design time and runtime.

Motivation: In IT management, meta data is important to a) describe data in richer ways so that it can ultimately be linked to the goals that drive the existence of the source of this data, e.g. limitations, purpose, context, quality, and characteristics of management data as an associated piece of that data will help to describe how the data is related to the objectives of an IT environment. b) meta data can be used to enable interoperability of manageability capabilities provided by a number of different providers

Recommendation: Descriptive information about the manageability interface will be expressed as XML element attributes as a tactical solution for WSDM 0.5. This satisfies runtime introspection, but does not provide design time introspection.

A strategic solution will be developed for WSDM 1.0 which supports runtime and design time introspection. The Distributed Management Task Force's Common Information Model (CIM) qualifiers (meta-data concerning a class, property, method, notification or method parameter) may be mined for useful information for manageability meta-data.


1155115611571158115911601161

1162

11631164

1165

116611671168116911701171

1172117311741175

11761177

1178

1179118011811182

118311841185118611871188

118911901191

1192119311941195

109110

111

Addressing An address or reference is the data structure used to refer to a unique Web service. Addressing may be used to refer to Web services for a manageability provider as well as a manageable resource. The data structure must have sufficient information for a manageability consumer to be able to locate the Web service and send messages to the Web service. In the case the referenced Web service provides manageability for several resources, it is also necessary to uniquely identify a specific resource in the reference data structure. The reference data structure must include the ability to locate the description of the Web service in order for the manageability consumer to identify the messages understood by the Web service. In this context, address and reference are used synonymously.

Motivation: Management needs interoperable addressing in order to refer to common manageability services and manageable resources for relationships, notifications, and as part of messages exchanged.

Recommendation: Use the WS-Addressing specification (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-addressing.asp).

Notification Notification is a method of conveying information from a source to recipients that expressed interest in that information. In terms of Web services it means delivering an XML message from the source to addressable recipients. An interest in receiving those messages must be established by the recipients, or by third parties on behalf of the recipients. When registering interest, address(es) of recipient(s) must be provided (see Addressing).

Motivation: Manageable resources need to convey information to the managers. In certain cases, it is unreasonable for the manager to explicitly poll (request) the information, and it has to be sent to the manager by the manageable resource. For example, a manager may be interested when a service receives a new message. The manageable resource for the service has to notify the manager when it happens (event). The manageable resource needs to know which managers are interested in which information and what are the deliverable addresses of the managers to send the notification message when an event occurs.

Recommendation: Use the WS-Notifications specification [WS-Notification].

Versioning Version is an attribute of a resource identifying a set of supported capabilities and a sequence of modifications to the component. There are two kinds of versioning; the resource version and the Web service version. The format of the former is out of scope of this work. Version information is useful so that the manager can know if the manageable Web Service interfaces have changed since she obtained her copy.

Motivation: A manager of manageable resources must have the ability to query the available endpoints’ revisions along with the corresponding change descriptions such that the manager can discern the most appropriate and compatible interface of a particular manageability function that her management client can use.

Recommendation: Addressed by WSDM as part of the “Management of Web Services” specification development for a Web service, taking into account W3C recommendations on this topic [W3C TAG finding on Versioning]. “Management Using Web Services” must provide access to version information as part of description of identity of manageable resources.


1196

119711981199120012011202120312041205

120612071208

120912101211

1212

12131214121512161217

1218121912201221122212231224

1225

1226

12271228122912301231

1232123312341235

1236123712381239

112113

114

SecurityThere are many ways to categorize information security, but the most common today are Confidentiality, Integrity, and Authentication. Additional concepts that can be arguably kept separate are: Access Control, Non-repudiation, Availability, and Privacy. [see Glossary] Security requirements within manageability are not unique to manageability. Every manageability endpoint and many business endpoints will have requirements for confidentiality, integrity, and authentication, as well as access control, availability, and privacy (see the definition of Security).

Motivation: Resources have to be manageable in a secure way (see definition of security). Security infrastructure mechanisms should be composed and layered on top of the manageability exposed via Web services, similar to securing any other capability of a resource exposed via a Web service. For example, access to a manageability operation can be granted to only clients that present “manager’s identity” in a request message.

Recommendation: WSDM will follow the recommendation of the OASIS WS-Security TC. WSDM 1.0 should examine WS-Security to ensure nothing done in the specification precludes the composability of Security. In addition, security should be manageable via Web services.

Registration and Discovery Registration is a method of advertising an existence of an element so that it can be discovered. Discovery is a method of locating an existing element so that it can be used or operated. Discovery can be based on selection criteria or simply a name or identity of an element. Location is a method of obtaining an address of an element. In the Web services sense, registration, discovery and location can be represented by a set of operations and schema which may be implemented by a Registry.

Motivation: Manageable resources have to be discoverable by the managers. Manageable resources exposed via Web services can be registered, discovered and located via a Registry.

Recommendation: UDDI specification will satisfy most requirements. Existing Web services discovery practices are sufficient.

Future FocusFor future versions of WSDM may also require the following support from the Web services platform.

Policy A Policy is a course of action, guiding principle, or procedure considered expedient, prudent, or advantageous for a given condition or event. It describes a broad range of service requirements, preferences, and capabilities. There are two kinds of policy that governs management of manageable resources: a) a set of policy that describes how the client of a manageable resource interacts with the functional interfaces of the resource (e.g. policy describing the privacy of data), b) a set of policy that describes how the manager of a manageable resource places operational requirements on to the resource, e.g. service level agreements.

Motivation: There are various policies that can be specified to manageable resources including: authentication, access control, privacy, non-repudiation, service level agreement, quality of service, routing, content inspection, and auditing, etc. policies. MUWS must leverage as much as existing Webservices specifications and technologies in applying policies to the manageable resources. MUWS should endorse a list of such specifications and technologies, and should specify the compatibility and interoperability requirements.


1240

124112421243124412451246

12471248124912501251

125212531254

1255

125612571258125912601261

12621263

12641265

1266

12671268

1269

1270127112721273127412751276

127712781279128012811282

115116

117

Recommendation: None at this time.

Name ResolutionFor management purposes: A service which accepts a name identifier (URI) of a resource and returns an address or reference for the manageability endpoint for the resource. The service should return sufficient information such that the manageability endpoint can be invoked. The name resolution service may be used to resolve names to references in other application domains unrelated to management as well, i.e. service discovery, etc.

Motivation: A name resolution service is necessary for management because resources and manageability services have identifiers (from existing instrumentation and technologies) and it will be necessary to be able to get a reference for that resource identifier so that the manager can interact with a resource through its manageability interface.


Transaction A “unit of work” that consists of multiple actions (typically, an ordered set) invoked against a single resource, the same action applied to multiple resources, or multiple actions against multiple resources. The “unit of work” should be executed once and only once, even if due to transmission failures or other errors, the request may be received multiple times. One of three outcomes will result from the execution of a transaction: a) all actions against all resources may succeed, b) one or more actions may fail and all actions against all resources are rolled back (if roll back is not possible or not supported, then the resources should be reconfigured to an operational, state of compensation), or c) one or more actions may fail and the resources are left as affected by the actions

Motivation: Grouping actions against resources and assuring their execution is very valuable. A manager may request that multiple actions/operations be performed as a single “unit”, and that the integrity of the complete/combined request be preserved.


Flow Flow, more often called workflow or workflow management, is the management of business processes with information technology. By defining, analyzing, and organizing an organization’s resources and operations, workflow management systems ensure that the right information reaches the right person or computer application at the right time. Business process management (BPM) workflow or execution languages support composing services into more complex processes and may expose itself as a Web service. Such coordination description includes, but may not be limited to, constructs for the identification of partners, message correlation, fault detection and compensating activities, parallel and serial execution of services, and so on.

Motivation: Web services orchestration languages may be useful tools allowing Web services management providers to enable more complex and meaningful actions to be taken as a result of observations. A manageability interface may need to be defined for a business process engine to properly and consistently monitor and control flows and composite Web services which might expose the sessions and state of a process, subordinate resources, etc.



1283

1284

12851286128712881289

1290129112921293

1294

1295

129612971298129913001301130213031304

130513061307

1308

1309

131013111312131313141315131613171318

13191320132113221323

1324

118119

120

NegotiationNegotiation is the process by which two services dynamically negotiate terms of a contract between initiators and participants of that contract. A contract is a document that represents a set of objectives and resources.

Motivation: It is important for resources to understand what they can expect from the other resources both between managed resources, management services, and managers. This enables them to better describe their own level of performance, as well as how information is exchanged between the components of federated deployments.



1325

132613271328

1329133013311332

1333

1334

121122

123

Documents

MUWS specification v0.5 · Web viewTo subscribe, send an email message to [email protected] with the word “subscribe” as the body of the message. For