1
4
Web Services Distributed
Management: Management Using
Web Services (MUWS 1.0)
5
Working Draft, October 19th 2004
6
7
Document identifier:
wd-wsdm-muws-1.0
8
9
Location:
http://docs.oasis-open.org/wsdm/2004/XX/muws
2
3
10
11
12
Editors:
Andreas Dharmawan, Westbridge Technology <[email protected]>
William Vambenepe, Hewlett-Packard <[email protected]>
13
14
15
Abstract:
There are two parts of Web services Distributed Management: Management Using Web
services and Management of Web services. This document defines the former.
16
17
18
19
20
21
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 working draft of version 1.0. There is no guarantee that any part of its
content will appear in the final release specification.
22
23
24
25
26
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.
27
28
29
30
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.oasisopen.org/committees/wsdm/).
31
32
The errata document for this specification is at:
http://docs.oasis-open.org/wsdm/2004/XX/muws-errata
33
34
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 1 of 55
35
Table of Contents
36
1
Introduction ............................................................................................................................. 5
37
1.1
Terminology.................................................................................................................... 6
38
1.2
Notational conventions ................................................................................................... 6
39
2
Architecture ............................................................................................................................. 7
40
2.1
Context ........................................................................................................................... 7
41
2.2
Conceptual Model........................................................................................................... 8
42
2.3
Logical Model ............................................................................................................... 10
43
2.3.1
Role Definitions ........................................................................................................ 10
44
2.3.2
Discussion ................................................................................................................ 11
45
2.4
Composability ............................................................................................................... 12
46
2.5
Processing Model ......................................................................................................... 13
47
2.5.1
Prerequisites ............................................................................................................ 13
48
2.5.2
Discovery ................................................................................................................. 14
49
2.5.3
Interaction ................................................................................................................ 14
50
3
Support from Web Services Platform ................................................................................... 15
51
3.1
Use of WSRF ............................................................................................................... 15
52
3.2
Use of WS-Notification ................................................................................................. 16
53
3.3
Security......................................................................................................................... 16
54
3.4
Taxonomy..................................................................................................................... 16
55
56
4
Capabilities applicable to manageable resources ................................................................. 17
4.1
Identity .......................................................................................................................... 18
57
4.1.1
Definition .................................................................................................................. 18
58
4.1.2
Information Markup Declarations ............................................................................. 19
59
4.1.3
Properties ................................................................................................................. 19
60
4.2
Correlateable Properties .............................................................................................. 21
61
4.2.1
Definition .................................................................................................................. 21
62
4.2.2
Information Markup Declarations ............................................................................. 21
63
4.2.3
Properties ................................................................................................................. 22
64
4.3
State ............................................................................................................................. 24
65
4.3.1
Definition .................................................................................................................. 24
66
4.3.2
Description of State Model ....................................................................................... 25
67
4.3.3
Information Markup Declarations ............................................................................. 26
68
4.3.4
Properties ................................................................................................................. 26
69
4.3.5
Operations................................................................................................................ 26
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 2 of 55
70
4.4
Metrics .......................................................................................................................... 27
71
4.4.1
Definition .................................................................................................................. 27
72
4.4.2
Information Markup Declarations ............................................................................. 28
73
4.4.3
Properties ................................................................................................................. 30
74
4.4.4
Operations................................................................................................................ 30
75
5
76
Capabilities applicable to management in general................................................................ 31
5.1
Relationships ................................................................................................................ 31
77
5.1.1
Definition .................................................................................................................. 31
78
5.1.2
Information Markup Declarations ............................................................................. 32
79
5.1.3
Properties ................................................................................................................. 34
80
5.1.4
Operations................................................................................................................ 35
81
5.1.5
Events ...................................................................................................................... 35
82
5.2
Relationship Access Capability .................................................................................... 36
83
5.3
Relationship Resource Capability................................................................................. 36
84
5.3.1
85
5.4
Properties ................................................................................................................. 36
Advertisement .............................................................................................................. 37
86
5.4.1
Definition .................................................................................................................. 37
87
5.4.2
Properties ................................................................................................................. 37
88
5.4.3
Operations................................................................................................................ 37
89
5.4.4
Events ...................................................................................................................... 37
90
6
Discovery and Introspection .................................................................................................. 39
91
7
Defining a Manageability Interface ........................................................................................ 40
92
8
References ............................................................................................................................ 41
93
8.1
Normative ..................................................................................................................... 41
94
8.2
Non-normative .............................................................................................................. 42
95
Appendix A.
Acknowledgements ............................................................................................. 43
96
Appendix B.
Notices ................................................................................................................. 45
97
Appendix C.
Schemas (Normative) .......................................................................................... 46
98
Appendix D.
WSDL elements (Normative) ............................................................................... 49
99
Appendix E.
Web Services Platform ........................................................................................ 51
100
Initial Focus ............................................................................................................................... 51
101
Properties .............................................................................................................................. 51
102
Meta Data.............................................................................................................................. 51
103
Addressing ............................................................................................................................ 52
104
Notification ............................................................................................................................ 52
105
Versioning ............................................................................................................................. 52
106
Security ................................................................................................................................. 53
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 3 of 55
107
Registration and Discovery ................................................................................................... 53
108
Future Focus ............................................................................................................................. 53
109
Policy ..................................................................................................................................... 54
110
Name Resolution................................................................................................................... 54
111
Transaction ........................................................................................................................... 54
112
Flow....................................................................................................................................... 55
113
Negotiation ............................................................................................................................ 55
114
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 4 of 55
115
1 Introduction
116
117
118
119
120
121
Management Using Web Services (MUWS) enables management of distributed information
technology (IT) resources using Web services. Many distributed IT resources use different
management interfaces. By leveraging Web service technology, MUWS enables easier and more
efficient IT management systems by providing a flexible common framework for manageability
interfaces that benefit from the features of Web services protocols. Universal management and
interoperability across the many various distributed IT resources can be achieved using MUWS.
122
123
124
The types of management capabilities exposed by MUWS are the management capabilities
generally expected in distributed IT management systems. Examples of manageability functions
that can be performed via MUWS include:
125

monitoring quality of services
126

enforcing service level agreements
127

controlling tasks
128

managing resource life-cycles
129
130
131
132
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.
133
134
135
There is a minimum set of manageability capabilities the manageability provider must support in
order to participate in MUWS. This minimum set of manageability capabilities is defined in this
specification.
136
137
Additionally, the methods and mechanisms provided by MUWS for discovering the manageability
interfaces of manageable IT resources are discussed in this specification.
138
Finally, some of the manageability interfaces themselves are defined in this specification.
139
140
To understand the various topics discussed in this specification, the reader should be familiar with
IT management concepts. In addition, the following assumptions are made:
141

The reader is familiar with the Web Services Architecture [WSA]
142
143

The reader is familiar with XML [XML1.0 3rd Edition] , XML Schema [XML Schema Part
1] [XML Schema Part 2], and XML Namespace [XNS]
144

The reader is familiar with WSDL [WSDL1.1], SOAP [SOAP1.1] , UDDI [UDDI]
145
146

The reader is familiar with WS-ResourceProperties [WS-ResourceProperties],
WS-Addressing [WS-Addressing]
147
148
149
150
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 this document is a non-normative, explanatory material intended to
ease the understanding of the normative specifications.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 5 of 55
151
1.1 Terminology
152
153
154
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [RFC2119].
155
1.2 Notational conventions
156
157
This specification uses an informal syntax to describe the XML grammar of the messages making
up the management interfaces. This syntax uses the following rules:
158

The syntax appears as an XML instance, but data types appear instead of values.
159
160

{any} is a placeholder for elements from some other namespace (like ##other in the XML
Schema).
161
162

The Cardinality of an attribute, element, or {any}, is indicated by appending characters to
the item as follows:
163
? none,or one
164
*
165
+ one, or more
166
No character exactly one
none, or more
167

Items contained within the square brackets, [ and ], are treated as a group.
168
169

Items separated by | and grouped within parentheses, ( and ), indicate syntactic
alternatives.
170
171

Three consecutive periods, ... are used in XML start elements to indicate that attributes
from some other namespace are allowed.
172

The XML namespace prefixes,defined below, indicate the namespace of the Item.
173
174
175
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 Appendix D
of this specification.
176
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 6 of 55
177
2 Architecture
178
2.1 Context
179
180
This section provides a context for the MUWS Architecture. The MUWS Architecture builds upon
the Web Services Architecture (WSA).
181
182
183
184
185
186
WSA provides a common definition of a Web service, as well as a conceptual model and context
for understanding Web services and the relationships between Web service components. WSA
describes the characteristics common to all Web services and describes some characteristics
needed by many, but not all, Web services. Additionally, by identifying the global elements of the
global Web services network that are required to ensure interoperability among Web services,
WSA provides an architecture of interoperability for MUWS.
187
188
189
190
191
Since WSA defines how to specify information and operations through WSDL interfaces, access
through bindings, and discovery through endpoints, it is consistent to use WSA to describe, as
well as provide access to, and discoverability of, the manageable components of the WSA itself.
In fact, this paradigm can be extended by providing access to, and discoverability of, any
manageable resource in the IT infrastructure.
192
193
194
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.
195
196
Figure 1 illustrates two possible methods a manageable Web service may use to fulfill
management requests on an exposed resource.
197
198
199
Figure 1: MUWS on IT Resource
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 7 of 55
200
201
202
203
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.
204
205
206
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.
207
208
This second method enables existing management instrumentation of a resource to be exported
through Web services to a management consumer.
209
210
211
212
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.
213
214
215
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.
216
217
218
219
Creating a Web service 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 management
information from an exposed resource.
220
2.2 Conceptual Model
221
222
223
224
225
This 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 relates the concepts
necessary for MUWS.
226
227
Figure 2: MUWS Concepts
228
229
230
According to the concepts in the WSDL specification, a Web service is an aggregate of endpoints.
Each endpoint offers the Web service at an address that is accessible according to a binding. A
Web service has some number of interfaces that are realized by its endpoints.
231
232
Each interface describes a set of named messages, and their formats, that can be exchanged.
Properly formatted messages can be sent to the address of an endpoint in a way prescribed by
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 8 of 55
233
234
235
the binding. A WSDLdescription, either as a document, or as an artifact, is composed of
definitions of interfaces and services. A WSDL description may contain definitions of interfaces, or
definitions of services, or definitions of both.
236
237
238
239
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.
240
241
242
243
244
Thus, a single manageability interface represents all or part of a manageability capability.
Similarly, a single manageability capability may be represented by one or more interfaces. The
semantics of a particular interface includes the description of the set of possible message
exchanges. The exchanges are rendered as message formats grouped into one or more
interfaces.
245
246
247
248
249
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 the
“http://docs.oasis-open.org/wsdm/2004/XX/manageability/metrics” namespace. Such a rendering
would be an instance of the manageability interface concept.
250
251
252
253
254
255
256
257
This specification defines the base set of manageability capabilities that can be composed into a
manageable resource or combined into aggregate capabilities. For example, a
TotallyManagableResource über-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 or identify aggregate capabilities. Rather, this
specification focuses on the definition of the base set of manageability capabilities.
258
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 9 of 55
259
2.3 Logical Model
260
261
This section describes the logical model of the MUWS architecture, as represented by the UML in
Figure 3.
262
263
Figure 3: MUWS Logical Model
264
2.3.1 Role Definitions
265
266
267
This section defines the roles and interactions of the major components within the MUWS
Architecture. This section is not intended to constrain the locus of implementation. Rather, this
section describes the required components, their roles, and how they interact.
268
269
NOTE: One implementation may be a single component with many roles while another
implementaion may be composed of several components, each with an assigned role.
270
271
272
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.3.-1).
273
2.3.1.1 Manageability Consumer
274
The manageability consumer:
275

Consumes management information about the resource
276

Manages, monitors, configures the resource
277

Understands the manageability capabilities of the resource
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 10 of 55
278
2.3.1.2 Manageability Provider
279
The manageability provider:
280
281

Provides the manageability quality for a resource, enabling a resource to become a
manageable resource
282
283

Provides management information for consumers according to the manageability
capabilities of the resource
284
285
286
287
NOTE: The manageability provider may be implemented in the manageable resource or it may
not. The manageability provider may provide the manageability quality for more than one
resource. Thus, the role of manageability provider is not intended to constrain the locus of
implementation.
288
2.3.1.3 Manageable Resource
289
290
291
292
The Manageable Resource is an IT resource that is manageable via a 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 provider for the manageability
service.
293
294
295
296
A manageable resource does not have to be fine-grained. To illustrate this point, a complete
server could be a manageable resource. The manageability provider offering the manageability
endpoint for the server can run either on the server, or on some other machine. At an even higher
level of granularity, a server farm could be exposed as a single manageable resource.
297
298
For example, an IT management software package could act as a manageability provider offering
manageability endpoints exposing manageability capabilities for the server farm.
299
300
301
302
303
304
Other examples of manageability capabilities might be retrieving the aggregate available disk
space for all servers in the farm, or, bringing up or down all servers in the farm. Such a
manageability provider for the server farm could be implemented using a set of proprietary
interfaces for the servers in the farm. Alternatively, if the servers are manageable resources, such
a manageability provider could act as a manageability consumer by accessing and aggregating
the manageability capabilities of the servers in the farm.
305
2.3.2 Discussion
306
307
308
A manageability provider may provide manageability capabilities for many resources. In other
words a manageability provider may allow many resources to be exposed as manageable
resources.
309
310
311
312
313
314
To accomplish this, a manageability provider maintains manageability endpoints. A manageability
endpoint provides a means to access one or more manageable resources. According to our
conceptual definition, a manageable resource is a resource composed with any number of
manageability capabilities. In order to compose manageability capabilities onto a manageable
resource, a manageability provider must support the manageability capabilities offered by the
manageability endpoints of the manageable resource.
315
316
317
318
For example, a manageability provider could embed code into a resource supporting the
manageability capabilities of the resource, thus making the resource manageable. A
manageability provider could also support manageability capabilities by deploying resources within
a container that supports manageability capabilities for all resources in the container.
319
320
The manageability consumer manages manageable resources. To manage in this context means
to exert control and to obtain and interpret information about the manageable resource. In order to
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 11 of 55
321
322
manage the manageable resource, the manageability consumer accesses manageability
endpoints and exercises the manageability capabilities offered by the endpoint.
323
324
325
326
327
328
To exercise in this context means to use the distinct semantics of a manageability capability.
Essentially, the consumer exercises an understanding of the semantics defined by a
manageability capability, but exercises this understanding on an actual manageable resource. In a
technical sense, to exercise offered manageability capabilities translates into using a distinct
group of properties, operations, events and metadata by exchanging messages with the
manageability endpoint.
329
330
331
332
333
334
For example, consider a server with several disk drives. The manageability provider could be a
software process running on the server. This manageability provider could allow each disk drive to
become a manageable resource by providing a manageability endpoint for each disk drive. The
implementation of these endpoints by the provider could use OS calls to access the disk drives.
This pattern could be used to provide manageability capabilities exposed through manageability
endpoints, such as retrieving the amount of disk space available in each disk drive.
335
336
337
338
An IT management console, acting as a manageability consumer, could then exercise this
manageability property by accessing the manageability endpoints provided by the manageability
provider. Using this example, the management console could retrieve the amount of disk space
available on each disk drive.
339
2.4 Composability
340
341
342
343
344
345
MUWS 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 manageability capabilities and functional capabilities. In this case,
the resource may allow manageability consumers access to appropriate functional capabilities
along with the manageability capabilities. Managers could discover such composition by
inspecting the service description.
346
347
348
349
350
Manageability consumers might take advantage of a composition of manageability and functional
capabilities by querying for free disk space using a disk manageability capability and then reading
disk sectors using a disk functional capability. Composability makes it easy for implementers of a
resource service to offer an appropriate subset of functional capabilities along with its set of
manageability capabilities.
351
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 12 of 55
352
2.5 Processing Model
353
This section describes the processing model of the MUWS architecture.
354
355
Compliant implementations of the roles as defined in section 2.3, the logical model, act according
to a set of basic processing rules, as described in this section.
356
Figure 4 represents the main principles of the processing model as described below.
357
358
359
Figure 4: MUWS Basic Processing Model
360
361
2.5.1 Prerequisites
362
363
364
365
366
367
A manageability consumer and a manageability provider must understand the information model
within which semantics of a manageability capability are described. For example, a UML model
could express a group of properties, operations, events and metadata. The meaning of what the
model defines must be equally understood by both manageability parties, provider and consumer.
The base capabilities defined in MUWS, as well as the capabilities defined in domain-specific
specifications built on top of MUWS, are the means to achieving such an understanding.
368
369
370
A manageability consumer and a manageability provider must both understand how to identify
which manageability interface corresponds to which manageability capability, and vice versa. The
base capabilities described in MUWS are the means to achieving such an understanding.
371
372
373
A manageability consumer must 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 manageability consumer.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 13 of 55
374
375
376
377
A manageability provider must 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 manageability capabilities. MUWS also indicates URL
locations of such XML schema documents and WSDL documents hosted on the OASIS Web site.
378
2.5.2 Discovery
379
380
381
382
A manageability consumer discovers manageable resources by discovering, reading the
descriptions of, and exchanging messages with manageability endpoints.. MUWS indicates which
manageability capabilities can be used to discover other Web services endpoints and other
manageability endpoints.
383
384
385
386
To discover manageability endpoints, the manageability consumer uses the same discovery
techniques as used for discovering any Web service endpoint. For example, the manageability
consumer may be provided a URL referencing a WSDL document describing the manageability
service.
387
388
A manageability provider advertises, registers, and publishes available manageability endpoints
just like any other Web service endpoint.
389
390
391
392
393
394
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 manageability consumer may inspect a WSDL
document looking for manageability operations of interest. MUWS, and the specifications that
build on top of it, clearly indicate which message Qnames correspond to which operations and
manageability capabilities.
395
2.5.3 Interaction
396
Within the context of the MUWS processing model, to interact means to exchange messages.
397
398
399
400
401
A manageability consumer exerts control over, and obtains information about, the manageable
resource by exchanging messages with one or more manageability endpoints providing access to
the manageable resource. Message exchanges must match the format and sequence as
prescribed by the binding description of the endpoint. This interaction is no different than
exchanging messages with functional Web service endpoints.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 14 of 55
402
3 Support from Web Services Platform
403
404
405
406
407
408
409
Management Using Web Services (MUWS) is a foundation for management of all IT resource
domains. It accomplishes this 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 E, Web Services Platform. Appendix E also
provides details about these Web service features and motivating factors for using Web services
features in MUWS, and provides a non-normative analysis of what standards or capabilities
should be leveraged to support these features.
410
3.1 Use of WSRF
411
412
413
414
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.
415
416
417
418
419
420
421
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.
422
423
424
425
426
427
428
429
430
431
In the specific case where 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 does not expect to receive the
elements listed 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 such an invocation succeeds, the
manageability consumer can infer it is talking about a manageable resource through a
manageability provider.
432
433
434
435
Further, management properties defined in MUWS are represented as “properties”, in the WSRF
sense of the term, using the mechanisms defined in WS-ResourceProperties ([WSResourceProperties]). This means that each manageable resource exposes a resource properties
document and makes this document available as specified in WS-ResourceProperties.
436
437
438
439
440
441
442
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-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.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 15 of 55
443
3.2 Use of WS-Notification
444
445
446
447
MUWS uses the notification mechanism described by the WS-Notification family of specifications
([WSN]). When a manageability capability includes the ability to offer events to a consumer, the
definition of the capability will include a Ws-Topics ([WST]) topic space containing the topics
appropriate for the events offered by the capability.
448
449
450
451
Note that as WS-Notification does not currently support a way to specify that only some of the
information contained in the notification message should be sent to the consumer. MUWS does
not define a way to specify this either. Consumers and providers should be aware of the
performance cost of processing a large number of large notification messages.
452
3.3 Security
453
454
For security, MUWS relies on generic Web services security mechanisms, including
transport-level security and WSS SOAP Message Security as standardized by OASIS.
455
3.4 Taxonomy
456
457
458
459
In the description of several manageability capabilities, the need occurs to specify how a category
fits inside a taxonomy when the entire taxonomy might not be known to the consumer. This is for
example the case for relationship types and operational states. In order to support this need,
MUWS creates the following convention:
460
461
MUWS defines a “marker” complex type called muws-xs:Category. The content of this type is
xsd:Any. When an element is defined of this type, it MUST obey the following rules:
462

The element and all its of its descendant have at most one child element,
463
464

The top-level element and each of its descendants each represent one category in the
taxonomy,
465
466
467

The top level element represents the most specialized category and each element
represents a more specialized category than the category represented by the element it
contains, if any.
468
469
470
471
472
473
474
475
476
477
478
479
480
481
Here is an example element using this style. In this example, we assume that someone has
defined a sub-state of the muws-xs:Unavailable state, called mydomain:Offline. Furthermore, we
assume that there also is a substate of mydomain:Offline defined, called mydomain:Maintenance.
The following XMl element of type muws-xs:Category would represent the mydomain:Offline state
and also convey what states this is a sub-state off.
<mydomain:Maintenance>
<mydomain:Offline>
<muws-xs:Unavailable/>
</mydomain:Offline>
</mydomain:Maintenance>
A consumer who learns that a resource is in the mydomain:Maintenance operational state by use
of this notation will know, even without any knowledge of the “mydomain” namespace, that the
state the resource is in is a sub-state of muws-xs:unavailable and can take any action that is
appropriate based on this information.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 16 of 55
483
4 Capabilities applicable to manageable
resources
484
485
There is a minimum set of manageability capabilities that the manageability provider must support
in order to implement the MUWS specification.
486
487
Manageability capabilities define resource-specific properties, operations and events. Details of
these manageability capabilities are exposed by the manageable resource.
488
A manageable resource MAY also define new resource-specific manageability capabilities.
489
490
491
492
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.
493
494
495
496
497
498
Each capability is formally expressed in a UML diagram using the following approach. Figure 5
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 are then expressed as
properties, operations, events and metadata contained in the capability model representation
(UML class).
482
499
500
Figure 5: Manageability Capability UML Sample
501
502
503
504
505
506
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, xs:int is an example of a simple information type
that belongs to XML Schema Data Types UML package.
507
508
509
As a simplification, this document uses a convention that all simple information types having a
name which begins with “xs:” 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/.
510
511
512
513
514
Events are expressed as UML properties with an <<event>> strereotype. 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 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.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 17 of 55
515
516
517
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.
518
519
520
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.
521

ro – means read only, applicable to properties,
522

rw – means read/write, applicable to properties.
523

const – means constant, does not change during runtime, applicable to properties.
524
525
526
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/XX/muws/schema
muws-wsdl
http://docs.oasis-open.org/wsdm/2004/XX/muws/wsdl
pbm
http://docs.oasis-open.org/wsdm/2004/XX/pbm
wsdl
http://www.w3.org/2002/07/wsdl
soap
http://schemas.xmlsoap.org/wsdl/soap/
xs
http://www.w3.org/2001/XMLSchema
527
Table 4-1 Manageability Capability Namespaces
528
XML elements and schema types introduced in this section belong to the muws-xs namespace.
529
WSDL elements introduced in this section belong to the muws-wsdl namespace.
530
4.1 Identity
531
4.1.1 Definition
532
533
534
535
The goal of Identity is to establish whether two entities are the same. This is a required capability
and it MUST be provided by every manageability service. Observe that this requirement does not
preclude the manageability service using a security policy that prevents some requester from
accessing a capability.
536
537
538
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, Discovery, for additional
information.
539
Figure 6 shows the UML representation of MUWS Identity.
540
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 18 of 55
541
542
Figure 6: MUWS Identity
543
4.1.2 Information Markup Declarations
544
This specification does not define any data type to represent Identity.
545
4.1.3 Properties
546
Following is the specification of the resource Identity properties (elements).
547
548
549
550
551
552
553
554
555
556
557
558
559
<ResourceId>xs:anyURI</ResourceId>
<Caption xml:lang=”xs:language”>xs:string</Caption>*
<Description xml:lang=”xs:language”>xs:string</Description>*
<Version>xs: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>
<Caption xml:lang=”en”>Laptop 23 drive</Caption>
<Caption xml:lang=”fr”>Disque du portable 23</Caption>
<Description xml:lang=”en”>The disk drive in Bob’s laptop</Description>
<Description xml:lang=”fr”>Le disque dur dans le portable de
Bob</Description>
<Version>1.0</Version>
560
561
562
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.
563
The following constraints are applicable to ResourceId:
564
565
566
567

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.
568
569

Uniqueness in time: A ResourceId MUST NOT be reused by any manageability endpoint
for another resource, even after the original resource no longer exists.
570
571
572
573

Consistency across endpoints: A manageability provider SHOULD use the ResourceId
that is suggested by the characteristics of the resource to identify the resource. This is for
example possible when the ResourceId can be retrieved from the resource by the
manageability endpoint or when an application of MUWS to a given domain specifies a
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 19 of 55
574
575
576
method to build the ResourceId based on characteristics of the resources within the
domain. It is not guaranteed that different manageability endpoints attached to the same
resource will, in all cases, return the same ResourceId.
577
578
579

Consistency within an endpoint: A manageability provider that exposes several
manageability endpoints for the same resource SHOULD use the same ResourceId for all
manageability endpoints.
580
581
582
583
584
585
586
587

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 try to provide a consistent
ResourceId via predictable identifier generation or delegation of Identity assignment.
Manageability consumers may not be able to determine if two manageable resources
which do not provide the same ResourceId correspond to the same resource and as a
result a single resource may be treated as many resources.
588
589
590
591
592
593
594
595
596

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 avoided in a conscious and deliberate manner, as some managers may not be able to
distinguish that the two identifiers are, in fact, attached to the same resource. Thus, the
managers would be forced to treat every identifier as an attachment to an unique
resource.
597
598
599
600
601
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.
602
603
604
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.
605
606
MUWS defines an additional mechanism to establish oneness of two resources. This mechanism,
called “correlatable properties” is defined in the next section.
607
608
609
610
611
Caption is a string containing a descriptive name for the resource being managed. The Caption is
intended for human consumption and is expected to be short and suitable for display next to a
graphical icon. It is a read-write optional property that has a cardinality of 0 to many. The Caption
has an xml:lang attribute which contains a language identifier as defined by [RFC3066]. There
cannot be more than one Caption for the same language identifier.
612
613
614
615
616
Description is a string containing a description for the resource being managed. The Description
is intended for human consumption and is expected to be longer and more detailed than the
Caption. It is a read-write optional property that has a cardinality of 0 to many. The Description
has an xml:lang attribute which contains a language identifier as defined by [RFC3066]. There
cannot be more than one Description for the same language identifier.
617
618
619
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 use MUWS. Version is a read-write optional property with a cardinality of 0..1.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 20 of 55
620
4.2 Correlateable Properties
621
4.2.1 Definition
622
623
624
625
626
627
628
629
630
631
632
633
634
This capability allows a manageability representation to expose its understanding of what property
values could be compared to establish that the manageability representation in question and
another manageability representation correspond to the same resource. This is especially useful
in the case where the two manageability representations are unable to return the same
ResourceId for the resource. For example, one manageability representation may enable
temperature control capability for a SCSI HDD and another manageability representation may
enable capacity management capability for the same SCSI HDD. Each manageability
representation may return its own unique muws-xs:ResourceId due to the implementation
requirements or constraints (e.g. firmware). However, implementers of the manageability
representations may be aware of some unique resource-specific property values which indicate if
the resource is the same or different. In the SCSI example, it could be host IP, bus #, channel #,
SCSI ID, LUN ID. If those properties match, one could be generally certain that per SCSI resource
definition manageability is provided for the same SCSI resource.
635
636
637
638
Using this capability both manageability representations may expose their understanding of what
resource property values need to match to establish the correlation between manageable
resources. The manageability consumer uses this information to evaluate and establish the
correlation.
639
640
641
642
643
Note that if the ResourceId returned by both manageability representations are the same but the
correlatable properties do not match, the resources should be considered the same as the Identity
capability takes precedence over Correlatable Properties. Typically, manageability consumers will
not evaluate correlatable properties if the two manageability representations return the same
ResourceId.
644
Figure 7 shows the UML representation of MUWS Correlatable Properties.
645
646
XXXX
647
Figure 7: MUWS Correlatable Properties
648
4.2.2 Information Markup Declarations
649
650
651
Three elements are defined by this specification to provide a simple Boolean property match
dialect that can be used to express correlation for correlatable properties. These elements are
defined in a separate namespace from the rest of the MUWS specification.
652
653
654
655
656
657
658
659
660
<pbm:Match>xs:QName</pbm:Match>
This element evaluates to true if values of the property (as returned by both manageability
representations) identified by the given QName match.
<pbm:MatchAny>(<pbm:Match/>|<pbm:MatchAll>)*</pbm:MatchAny>
This element evaluates to true if any of the enclosed Match and/or MatchAll conditions evaluates
to true.
<pbm:MatchAll>(<pbm:Match/>|</pbm:MatchAny>)*</pbm:MatchAll>
This element evaluates to true if all of the enclosed Match and/or MatchAny conditions evaluate to
true.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 21 of 55
661
662
663
664
665
666
667
668
669
670
671
672
673
4.2.3 Properties
<CorrelateableProperties
Dialect="xs:anyURI"
NegativeAssertionPossible=”xs:boolean”?>
{any} *
</CorrelateableProperties>*
This property indicates the manageability representation’s view of what property values and/or
conditions and/or expressions could be used to correlate manageable resources. The value of this
property is the correlation expression. The format of the correlation expression is determined by
the “Dialect” attribute. This specification defines two possible dialect values. Additional dialect
values can be defined to provide additional functionalities. Manageability representations can offer
”CorrelatableProperties” properties in different dialects. The manageability consumer may
evaluate any dialect that it understands. Support for any dialect is optional.
674
675
676
677

Simple Property Boolean Match (Dialect="http://docs.oasis-open.org/wsdm/2004/XX/pb,”).
The contents of the property is as described in the previous section. If all top-level match
conditions are evaluated true, the correlation between manageable resources is
established.
678
679
680
681
682
683
684

XPath 1.0 (Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116"). The contents of
the property is an XPath 1.0 expression. This XPath expression is to be evaluated on the
resource properties document of the other manageability representation to establish
correlation between the resources corresponding to the two manageability
representations. 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, the correlation between
manageable resources is established.
685
686
687
688
689
690
691

XPath 2.0 (Dialect="http://www.w3.org/TR/xpath20/"). The contents of the property is an
XPath 2.0 expression. This XPath expression is to be evaluated on the resource
properties document of the other manageability representation to establish correlation
between the resources corresponding to the two manageability representations. 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, the correlation between manageable resources is
established.
692
693
694
The optional “NegativeAssertionPossible” attributes expresses whether a negative result in
the evaluation of the correlation expression implies that the resources are different. The
default value is false.
695
696
697
698
699
700
701

If “NegativeAssertionPossible” is false, only a positive match is meaningful to the
consumer. That is to say, if the correlation expression evaluates successfully
(according to the evaluation rules defined by the dialect) then the consumer can
consider that the resources are the same. If the correlation expression does not
evaluate successfully then the consumer doesn’t know whether the resources are the
same of not. It cannot infer that they are different from the use of this
“CorrelatableProperties” property.
702
703
704

If “NegativeAssertionPossible” is true, a positive match still means that the resources
are the same. But a negative match now means that the resources are guaranteed to
NOT be the same.
705
4.2.3.1 Examples of use (non normative)
706
707
Consider the following two simplified resource properties documents, obtained through two
different manageability representations:
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 22 of 55
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
Properties document obtained through manageability representation MR1:
<print:PrinterResourcePropDoc xmlns:print=”http://example.com/print”>
...
<print:PrinterModel>PrintCo SuperJet 5000</print:PrinterModel>
<print:Location>Building 42 lower pillar D4</print:Location>
<print:Owner>Sir Printalot</print:Owner>
<print:IPAddress>15.244.62.41</print:IPAddress>
<muws-xs:Name>Baby got ink</muws-xs:Name>
<muws-xs:CorrelatableProperties
Dialect=”http://docs.oasis-open.org/wsdm/2004/XX/pbm”>
<pbm:MatchAny>
<pbm:Match>print:IPAddress</pbm:Match>
<pbm:MatchAll>
<pbm:Match>muws-xs:Name</pbm:Match>
<pbm:Match>print:PrinterModel</pbm:Match>
<pbm:Match>print:Location</pbm:Match>
<pbm:Match>print:Owner</pbm:Match>
</pbm:MatchAll>
</pbm:MatchAny>
</muw-xs:CorreletableProperties>
</print:PrinterResourcePropDoc>
Properties document obtained through manageability representation MR2:
<print:PrinterResourcePropDoc xmlns:print=”http://example.com/print”>
...
<print:PrinterModel>PrintCo UltraJet 40</print:PrinterModel>
<print:Location>Building 42 lower pillar D4</print:Location>
<print:Owner>Sir Printalot</print:Owner>
<print:IPAddress>15.244.10.89</print:IPAddress>
<muws-xs:Name>Baby got ink</muws-xs:Name>
</print:PrinterResourcePropDoc>
738
739
740
741
742
743
The “CorrelatableProperties” property provided through manageability representation MR1 asserts
that if a manageability representation provides a view of a resource which either has the same
IPAddress as MR1 or has the same Name, PrinterModel, Location and Owner as MR1 then the
printers behind these two manageability representations are the same printer. In this example,
since the IPAddress doesn’t match and the PrinterModel is different, the correlation is not
established and the consumer cannot deduce that the two printers are the same.
744
745
746
747
748
Note that since the “NegativeAssertionPossible” attribute is not specified on
“CorrelatableProperties” it takes the default value of false and therefore the consumer cannot
assume that the resources are indeed two different printers. At this point, the consumer still
cannot know whether the two manageability representations correspond to the same printer or
not.
749
Properties document obtained through manageability representation MR3:
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
<print:PrinterResourcePropDoc xmlns:print=”http://example.com/print”>
...
<muws-xs:CorrelatableProperties
Dialect=http://www.w3.org/TR/1999/REC-xpath-19991116
NegativeAssertionPossible=”false”>
boolean(/print:PrinterResourcePropDoc/print:LastJob/print:JobID="5622654
8451262")
and
boolean(/print:PrinterResourcePropDoc/print:LastJob/print:JobOriginator=
"15.244.30.30")
</muw-xs:CorreletableProperties>
</print:PrinterResourcePropDoc>
Properties document obtained through manageability representation MR4:
<print:PrinterResourcePropDoc xmlns:print=”http://example.com/print”>
...
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 23 of 55
765
766
767
768
769
770
<print:LastJob>
<print:JobID>56226548451262</print:JobID>
<print:JobOriginator>15.244.30.30</print:JobOriginator>
<print:JobDate>2004-03-11T11:30:56Z</print:JobDate>
</print:LastJob>
</print:PrinterResourcePropDoc>
771
772
773
774
775
776
777
778
779
780
The “CorrelatableProperties” property provide through manageability representation MR3 asserts
that if a manageability representation provides a view of a resource for which the jobID of the last
job is 56226548451262 and the JobOriginator of the last job is 15.244.30.30 then the printers
behind these two manageability representations are the same printer. In this example, the
condition is satisfied, so the consumer knows that MR3 and MR4 correspond to the same physical
printer. Not that, as the example shows, with this dialect the consumer only needs to retrieve the
“CorrelatableProperties” property and no other property from MR3 to check correlation. From MR4
it needs to retrieve the properties needed to evaluate the XPath expression. In this example too,
“NegativeAssertionPossible” is set to false so a negative result would not guarantee that the
printers behind MR3 and MR4 are indeed different.
781
4.3 State
782
4.3.1 Definition
783
784
785
The 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 support the state change capabilities
and the events for lifecycle and status changes. Additionally, the state model must be extensible.
786
Figure 8 shows the resource state model without any sub-states.
787
788
789
Figure 8: Resource State Model
Figure 9 shows the UML representation of MUWS State.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 24 of 55
790
791
Figure 9: MUWS State
792
4.3.2 Description of State Model
793
QNames for the valid top-level resource states:
794

795
796
797
This QName corresponds to the Available state in the UML diagram. A resource in the
Available state is able to perform all of its functional tasks.

798
799
800
801
802
803
muws-xs:Available
muws-xs:Degraded
This QName corresponds to the Degraded state in the UML diagram. A resource in this
Degraded state is able to perform some, but not all, of its functional tasks.

httpmuws-xs:Unavailable
This QName corresponds to the Unavailable state in the UML diagram. A resource in
this state is not able to perform any of its functional tasks.
804
805
806
807
808
809
810
811
812
813
814
The resource state model, as defined in this specification, identifies three generic states that are
relevant for most, if not all, types of resources. Implementers SHOULD reuse a defined state if it
is appropriate for their resource. It is anticipated that new states, and corresponding QNames,
may need to be defined. For example, the need for a new state may be indicated when the
existing states do not represent the intended meaning for a resource, or when the existing states
are too general and the implementer wishes to expose a more specific and useful state
description. Just as implementers MAY create new states, implementers MAY create new
transitions between any two states. Note, the two states involved in the transition need not be
defined within the same organization. Also, note that unless a standard way to represent the state
model for a resource is defined, "creating a new transition" just means writing some text to explain
that a resource state can change from one state to another.
815
The following table lists the valid transitions between the top-level resource states.
816
Start State
End State
Available
Degraded
Available
Unavailable
Degraded
Available
Degraded
Unavailable
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 25 of 55
Unavailable
Available
817
818
4.3.3 Information Markup Declarations
819
820
The following is a pseudo-schema fragment declaring reusable data types for managing the
resource state.
821
822
823
824
825
826
827
<xs:complexType name="StateInformation">
<xs:sequence>
<xs:element name="State" type="muws-xs:Category"/>
<xs:element name="TimeEntered" type="xs:dateTime"/>
</xs:sequence>
</xs:complexType>
828
829
The (StateInformation) type contains information about a resource state.
830
831
The (StateInformation)/State element provides an element representing the state of the
resource. It follows the convention for the muws-xs:Category type described in section 3.4.
832
833
The (StateInformation)/TimeEntered element provides the time the resource entered the
identified state.
834
4.3.4 Properties
835
The resource state properties, or elements, are specified as follows:
836
837
<ResourceState>StateInformation</ResourceState>
838
839
840
841
842
843
844
845
846
847
848
849
850
The following fragment provides an example from a resource properties instance document
containing this property:
<ResourceState>
<State>
<mydomain:Maintenance>
<mydomain:Offline>
<muws-xs:Unavailable/>
</mydomain:Offline>
</mydomain:Maintenance>
</State>
<TimeEntered>2004-03-11T11:30:56Z</TimeEntered>
</ResourceState>
851
852
853
The ResourceState property contains the current state of the resource. This property is a readonly and mandatory with a cardinality of 1
854
4.3.5 Operations
855
This section describes the messages for performing operations on the state of a resource.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 26 of 55
856
4.3.5.1 Start
857
Request:
858
<Start/>
859
860
861
Reply:
<StartOK/>
862
863
864
865
866
Upon receiving a request for a Start operation, a manageability provider attempts to transition the
resource state from Unavailable to Available, according to the state model. If the transition
completes, then the operation also completes successfully. If the initial resource state is Available,
this operation completes successfully.
867
4.3.5.2 Stop
868
Request:
869
<Stop/>
870
871
872
Reply:
<StopOK/>
873
874
875
876
877
Upon receiving a request for a Stop operation, a manageability provider attempts to change the
resource state from Available, or Degraded, to Unavailable according to the state model. If the
transition completes, this operation completes successfully. If the initial resource state is
Unavailable, this operation completes successfully.
878
4.4 Metrics
879
4.4.1 Definition
880
881
Metrics are a specific type of property. Metrics represent collected values and have a related
collection period.
882
883
884
The goal of this section is to describe the characteristics of a typical property used to represent
collected numerical data, called Metrics. A common characteristic of metrics is that they change
over time and can be reset.
885
886
Figure 10: MUWS metricsError! Reference source not found. presents the Metrics capability in
context.
887
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 27 of 55
888
889
Figure 10: MUWS metrics
890
891
892
893
894
895
896
897
As a simple example, 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; 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
collecting, or counting, the number of cars typically for some duration of time, 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.
898
899
900
901
902
When accessing metrics, the time associated with the metric is typically required. In the example,
above it would be useful to know that the number “100” represents the number of cars that have
passed over the bridge in the last fifteen minutes. Similarly, if data is posted on a periodic basis, it
may be useful to know the time of last update.. For this reason, the standard data type for Metrics
has reset-time and update-time attributes. However, both are optional.
903
904
When looking at a value, it is important to have a notion of how changes to that metric are
interpreted. That notion is defined as a change type. Metrics have two (2) change types:
905

Counter, increments with usage
906

Gauge, moves between a range of values
907
908
909
910
911
Metrics can be reset either periodically, such as 'once a day', or on demand. The meaning of
resetting a metric varies with each metric. The meaning of a metric SHOULD be clarified as
needed, in the description of a metric. Often, resetting a metric means setting it to its base or
initial value, typically zero, but this is not mandatory. (Note that this specification provides no
specific means for the scheduling of reset operations.)
912
4.4.2 Information Markup Declarations
913
914
The following schema fragment declares the (reusable) data types used to expose the metrics of
the resource. All attributes defined in the MetricAttributes attribute group are optional.
915
916
917
918
919
920
921
922
923
<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"/>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 28 of 55
924
925
926
927
928
929
930
931
932
933
934
935
936
937
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute 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:attribute>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:attributeGroup>
938
939
940
(MetricAttributes) attribute group MUST be included in every metric type or metric property
element declaration.
941
942
(MetricAttributes)/ResetAt indicates the time when a particular metric was reset. UTC or Zcoded can be reported.
943
(MetricAttributes)/LastUpdated indicates the last update time of a metric value.
944
(MetricAttributes)/ChangeType indicates a type of change pattern supported by a metric.
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966


Counter declares a metric value. that can only increase
Gauge declares a metric value that can increase or decrease
(MetricAttributes)/TimeScope indicates the time interval used to calculate a metric.



Interval declares a metric value that is calculated within a certain time interval. Usually
the interval is defined by the specification of the metric property. For example,
RequestsPerSecond is an interval metric.
PointInTime declares a metric value that is calculated when the metric property is
retrieved. For example, CurrentTemperature is a point-in-time metric.
SinceReset declares a metric value that is calculated since the ResetAt time mark.
The following two types are defined for metrics that are integers, durations, or times.
Specifications that use MUWS to create manageability properties applicable to specific domains
are encouraged to use these types, or to create new metric types, by including the
MetricAttributes attribute group in created metric 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>
967
968
(IntegerMetric) type declares an xs:integer metric.
969
970
971
972
973
974
975
<xs:complexType name="DurationMetric">
<xs:simpleContent>
<xs:extension base="xs:duration">
<xs:attributeGroup ref="muws-xs:MetricAttributes"/>
<xs:anyAttribute namespace="##other"
processContents="lax"/>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 29 of 55
976
977
978
</xs:extension>
</xs:simpleContent>
</xs:complexType>
979
980
981
(DurationMetric) type declares an xs:duration metric.
982
4.4.3 Properties
983
The following provides the specification of a resource metrics property.
984
985
<CurrentTime>xs:dateTime</CurrentTime>
986
987
988
The following is an example fragment of a resource properties instance document containing this
property.
989
990
<CurrentTime>2004-03-11T11:30:56Z</CurrentTime>
991
992
993
994
995
CurrentTime contains the time the property was retrieved from the manageability provider. This
property is useful to manageability consumers when analysing time values received from a
manageability endpoint in the absence of a time synchronization mechanism. It is a read-only
mandatory property that has a resource cardinality of 1.
996
997
998
999
The Metrics capability requires the CurrentTime property is present in the resource properties,
and provides a reference point for time-based attributes as defined by metric data types. Note that
CurrentTime is not a metric. Rather, it is a property of type xs:dateTime defined as part of the
“Metrics” capability)
1000
4.4.4 Operations
1001
This capability does not define any operation.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 30 of 55
1003
5 Capabilities applicable to management in
general
1004
1005
1006
1007
1008
1009
1010
1011
1012
Section 4 (Capabilities) contains the list of manageability capabilities defined by MUWS. This
section (Section 5, ) contains management-related capabilities, which are different from
manageability capabilities. A manageability capability is offered by a manageability representation
and applies to the resource represented by the manageability representation. A management
capability can be offered by any Web service, not only manageability endpoints. Its function is
related to the field of management, but not necessarily to the direct management of a resource
through its manageability endpoint. For example, the capability to help a manager discover new
manageable resources can be provided by a registry and not necessarily a management
representation of a specific resource.
1013
5.1 Relationships
1014
5.1.1 Definition
1015
1016
1017
1018
1019
1020
1021
1022
A relationship is an N-ary association between resources. A relationship may have properties 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.
The arrows in Figure 11 depict navigability, which means that by following the arrow one could
resolve what the end points to (reference).
1002
1023
1024
1025
1026
Figure 11: Relationship conceptual model
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.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 31 of 55
1027
5.1.2 Information Markup Declarations
1028
5.1.2.1 Relationship category
1029
1030
1031
1032
1033
1034
1035
Relationships could be categorized. That is each relationship is of certain type/category which
describes the semantics of the relationship. One type/category may be a specialization or
generalization of another type/category. This defines taxonomy of relationship categories. WSDM
defines a way to represent a type/category and its taxonomy lineage, but actual definition of the
categories is resource management model specific and therefore not defined by WSDM. In other
words, WSDM specifies only the mechanism to convey a type/category in XML. The WSDM
mechanism applied to relationship types/categories is defined as follows.
1036
RelationshipType XML Schema type is declared as follows
1037
1038
1039
1040
1041
<xs:complexType name=”RelationshipType”>
<xs:complexContent>
<xs:extension base=”muws-xs:Category”/>
</xs:complexContent>
</xs:complexType>
1042
1043
The RelationshipType is used to declare XML elements which contain instances of relationship
type/category information.
1044
The relationship type/category information MUST be declared as follows.
1045
1046

An XML element is declared which QName identifies the semantics of a relationship
type/category.
1047
1048

The XML element MUST be declared with the XML Schema type which is a restriction of
RelationshipType.
1049

The contents of the XML element MUST be either
1050
1051

The only one XML element which corresponds to the generalization of the currently
declared relationship type/category
1052
1053

Or empty sequence, if currently declared relationship type/category does not have
any generalizations (top of the taxonomy).
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
For example, the “USB attached” relationship type/category may be generalized to the “Bus
connected” which, in turn, may be generalized to the “Generally linked”. An instance of the “USB
attached” relationship type/category information may be represented in the following XML
fragment by using the rules described above.
<my:RelationshipTypeInstanceElement xsi:type=”RelationshipType”>
<usb:Attached>
<bus:Connected>
<generally:Linked/>
<bus:Connected>
</usb:Attached>
</my:RelationshipTypeInstanceElement>
1065
5.1.2.2 Element declaration
1066
1067
MUWS defines the following Global Element Declaration (GED) to represent an instance of a
relationship.
1068
1069
1070
<Relationship>
<Name>xs:string</Name> ?
<Type>muws-xs:RelationshipType</Type>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 32 of 55
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
<Participant Role=”xs:anyURI”>
<ManageabilityEndpointReference>
wsa:EndpointReferenceType
</ManageabilityEndpointReference> *
<muws-xs:ResourceID/> ?
{any}*
</Participant>
<Participant/>+
<AccessEndpointReference>
wsa:EndpointReferenceType
</AccessEndpointReference>?
{any}*
</Relationship>
1084
1085
Relationship/Name is a human readable name of the relationship. Name should not be used for
machine reasoning about the semantics of the relationship. Type should be used instead.
1086
1087
1088
1089
1090
1091
Relationship/Type is a type/category which this relationship belongs to. Such as linkage,
containment, dependency, etc. 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 muwsxs:Category type defined in section 3.4.
1092
1093
Relationship/Participant contains information about the participant in the relationship. There
MUST be at least two participants, but MAY be more.
1094
1095
1096
Relationship/Participant[@Role] is a URI which identifies the role that the participant plays in
the relationship. A participant role MUST be unique within a given instance of the relationship. The
set of valid roles is defined by the relationship type.
1097
1098
1099
Relationship/Participant/ManageabilityEndpointReference is a reference to a WSDM
manageability endpoint which MAY be included if the participant is WSDM manageable and the
provider of this information knows and wishes to indicate that.
1100
1101
1102
1103
1104
1105
1106
Relationship/Participant/muws-xs:ResourceID is a WSDM manageable resource identifier
which MAY be reported by the provider of the relationship information. This information may be
used to locate manageability endpoints for this participant or may be used for other purposes. For
example, the resource identifier SHOULD be used to express that the provider of the relationship
information is also a participant of the relationship (by returning its own resource identifier for one
of the participants). Obviously, in order for this assertion to work, the provider of the relationship
information has to be a WSDM manageable resource.
1107
1108
1109
1110
1111
Relationship/Participant/{any}* is an XML extensibility content which MAY contain elements that
further or otherwise describe the participant. For example, when a participant is a Web service
endpoint, a mows-xs:EndpointReference element MAY be included in the extensibility content to
indicate reference to the functional/operational Web service endpoint participant of the
relationship.
1112
1113
1114
Relationship/AccessEndpoint is a reference to the Web service endpoint which provides
access to this relationship (if available). The endpoint MUST implement the relationship access
capability (see section 1)
1115
1116
1117
1118
Following is an example of a relationship information instance. The relationship is that a WSDM
manageable network host myhost.myorg.org contains an attached SCSI disk which is not
manageable by itself, but is exposed as a functional/operational Web service endpoint (e.g. to
read/write from the disk).
1119
1120
1121
<Relationship>
<Name>SCSI disk attached to the host computer</Name>
<Type>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 33 of 55
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
<scsi:Attached>
<bus:Connected>
<generally:Linked/>
<bus:Connected>
<scsi:Attached>
</Type>
<Participant Role=”urn:role:bus:host”>
<ManageabilityEndpointRefrence>
…EPR1…
</ManageabilityEndpointReference>
<muws-xs:ResourceID>urn:uuid:123</muws-xs:ResourceID>
<netop-xs:HostName>myhost.myorg.org</netop-xs:NostName>
</Participant>
<Participant Role=”urn:role:bus:device”>
<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>
</Participant>
</Relationship>
1145
5.1.3 Properties
1146
This capability defines the following properties.
1147
<Relationship/> *
1148
1149
1150
Relationship is a representation of a relationship which provider of this capability is aware of. See
section 5.1.2 for the definition of the Relationship element. The provider of this capability is not
necessarily a participant in the relationships represented by this property.
1151
1152
1153
1154
1155
1156
1157
It is not recommended to request all values of the Relationship property with either
wsrp:GetResourceProperty or wsrp:GetMultipleResourceProperties operations as there may be
too many relationships. It is RECOMMENDED to use wsrp:QueryResourceProperties operation
when retrieving the Relationships property. Provider of this manageability capability SHOULD, in
general, support wsrp:QueryResourceProperties operation. However, if the provider of this
capability knows of just a few relationships, it MAY choose not to support
wsrp:QueryResourceProperties operation.
1158
1159
For example, the following request may be sent to retrieve all “Bus connected” relationships which
point to devices exposed as Web services.
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
<soap:Envelope …>
<soap:Header>
…
</soap:Header>
<soap:Body>
<wsrp:QueryResourceProperties>
<wsrp:QueryExpression
Dialect=”http://www.w3.org/TR/1999/REC-xpath-19991116” >
boolean(/*/muws-xs:Relationship/muws-xs:Type/*/bus:Connected and
/*/muws-xs:Relationship/muwsxs:Participant[@Role=”urn:role:bus:device”]/mows-xs:EndpointReference)
</wsrp:QueryExpression>
</wsrp:QueryResourceProperties>
</soap:Body>
</soap:Envelope>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 34 of 55
1175
5.1.4 Operations
1176
This capability defines the following message exchanges.
1177
5.1.4.1 QueryRelationshipsByType
1178
1179
This operation is optional and is a shortcut to query the relationships of the same type. The
request to perform this operation is the following message.
1180
1181
1182
<QueryRelationshipsByType>
<Type>muws-xsRelationshipType</Type> +
</QueryRelationshipsByType>
1183
1184
QueryRelationshipsByType is a Global Element Declaration (GED) which identifies the
operation requested.
1185
1186
1187
QueryRelationshipsByType/Type is a category which the relationship belongs to. Such as
containment, dependency, etc. The actual markup of the value of this element is described in
section 5.1.2.
1188
The response to the above request is either a fault (any fault) or the following message.
1189
1190
1191
<QueryRelationshipsByTypeResponse>
<Relationship/> *
</QueryRelationshipsByTypeResponse>
1192
1193
QueryRelationshipsByTypeResponse is a GED which identifies response to the requested
operation.
1194
1195
1196
QueryRelationshipByTypeResponse/Relationship is a relationship representation matching
one of the requested types (categories). See section 5.1.2.2 for the definition of the relationship
element.
1197
5.1.5 Events
1198
1199
To obtain notifications of changes in relationships, the following notification topics are defined in
the manageable relationships capability.
1200
1201
1202
1203
1204
1205
1206
<wstop:TopicSpace name=”ManageableRelationships”
targetNamespace=”http://docs.oasis-open.org/wsdm/2004/XX/muws/schema”>
<wstop:Topic name=”RelationshipCreated” messageTypes=”muwsxs:RelationshipCreatedNotification”/>
<wstop:Topic name=”RelationshipDeleted” messageTypes=”muwsxs:RelationshipDeletedNotification”/>
</wstop:TopicSpace>
1207
1208
1209
1210
muws-xs:ManageableRelationships/muws-xs:RelationshipCreated indicates addition of a
new relationship. It is recommended to subscribe to this notification with appropriate selector
against the contents of the notification message to reduce the notification message volume. The
notification message contains at least the following information.
1211
1212
1213
1214
1215
1216
1217
1218
<RelationshipCreatedNotification>
<Relationship/>
</RelationshipCreatedNotification>
muws-xs:ManageableRelationships/muws-xs:RelationshipDeleted indicates removal of an
existing relationship. It is recommended to subscribe to this notification with appropriate selector
against the contents of the notification message to reduce the notification message volume. The
notification message contains at least the following information.
<RelationshipDeletedNotification>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 35 of 55
1219
1220
<Relationship/>
</RelationshipDeletedNotification>
1221
5.2 Relationship Access Capability
1222
1223
1224
1225
1226
1227
The capability to access a relationship is defined here. The provider of the Web service endpoint
that supports this capability also provides access to the relationship. If this capability is supported,
the endpoint reference for the service implementing it MUST contain sufficient information to allow
the provider of this capability to disambiguate which relationship is being accessed by the
message exchanges. The endpoint reference could be obtained from the
Relationship/acccessEndpointReference in relationship element defined in section 5.1.2.
1228
1229
1230
In general, this capability is not more specific than what is described above. That is, an endpoint
MAY support any message exchanges it needs to provide access to the relationship. The
message exchanges may entirely be management model specific.
1231
1232
1233
The only other normative requirement is that if the relationship lifecycle is to be exposed by the
provider of this capability, then the Web service endpoint MUST implement WS-ResourceLifetime
specification [WS-RL].
1234
5.3 Relationship Resource Capability
1235
1236
1237
1238
1239
1240
1241
A Web service endpoint, in addition to providing access to the relationship as described in section
5.2, may also represent the relationship. Representing the relationship means that an endpoint is
able to provide relationship information as described in section 5.1.2. In this case, the Web
service endpoint MUST be a WS-Resource, as defined by the WSRF, and one such WSResource provides information about one relationship instance. Representing relationships as
WS-Resources is useful when a manageability model defines additional properties, operations
and/or events for a given relationship.
1242
1243
1244
In order to represent a relationship as a WS-Resource, a set of properties is normatively required.
The rest is up to the relationship manageability model and the discretion of the provider of the
WS-Resource and the relationship.
1245
5.3.1 Properties
1246
This capability defines the following properties.
1247
1248
1249
1250
<Name>xs:string</Name> ?
<Type>muws-xs:RelationshipType</Type>
<Participant> … </Participant>
<Participant/>+
1251
Name is an element as defined by the Relationship/Name in section 5.1.2. It is optional.
1252
1253
Type is an element as defined by the Relationship/Type in section 5.1.2. It is required and can
only appear once.
1254
1255
Participant is an element as defined by the Relationship/Participant in section 5.1.2. It appears at
least twice (one per participant in the relationship).
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 36 of 55
1256
5.4 Advertisement
1257
5.4.1 Definition
1258
1259
1260
1261
1262
The “advertisement” capability is exposed by Web services that are able to provide notification on
creation and/or destruction of manageable resources. Since one cannot register for notification on
a resource before the resource is created, the creation events reported by the implementer of the
“lifetime notification” capability necessarily apply to other resources than those represented by the
Web service on which the registration was done.
1263
1264
1265
1266
1267
1268
1269
Note that this capability is not only implementable by manageable resources (see the distinction
between “manageability capability” and “management-related capability” in section 5). A service
might offer the capability to notify on creation/destruction of resources even though the service
itself is not manageable. For example, if a system included a registry to which resources are
added as soon as they are created and from which they are removed when they are destroyed,
this registry could expose the “advertisement” capability and use it to share the information about
resource creation/destruction with managers.
1270
1271
This capability does not define any property or operation, but it defines four topics used for
notification.
1272
1273
1274
An example of use of this capability would be for a container (e.g. a J2EE server, a business
process execution engine, etc) to expose it to advertise the fact that it can notify a manager when
a resource (in this example a resource contained by the container) is created.
1275
5.4.2 Properties
1276
This capability defines no property.
1277
5.4.3 Operations
1278
This capability defines no operation.
1279
5.4.4 Events
1280
This capability defines a topic space containing four notification topics:
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
<wstop:TopicSpace name=”AdvertisementTopicSpace”
targetNamespace=”http://docs.oasis-open.org/wsdm/2004/XX/muws/schema”>
<wstop:Topic name=”ManageabilityEndpointCreation” messageTypes=”muwsxs:CreationNotification”>
<wstop:Topic name=”ManageableResourceCreation” messageTypes=”muwsxs:CreationNotification”/>
</wstop:Topic>
<wstop:Topic name=”ManageabilityEndpointDestruction”
messageTypes=”muws-xs:DestructionNotification”>
<wstop:Topic name=”ManageableResourceDestruction”
messageTypes=”muws-xs:DestructionNotification”/>
</wstop:Topic>
</wstop:TopicSpace>
1294
1295
1296
1297
1298
The “muws-ev:ManageabilityEndpointCreation” topic corresponds to notification on creation of
a new manageability endpoint for a resource. This could be because the resource was just
created along with a manageability endpoint or the resource itself could have been creating some
time in the past. In this case, this notification means that a new manageability endpoint for the
resource was created. This new manageability endpoint could be the first one for the resource or
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 37 of 55
1299
1300
be in addition to existing ones. The associated muws-xs:CreationNotification message contains
the EPR of the newly created manageability endpoint.
1301
1302
1303
1304
1305
1306
The “muws-ev:ManageableResourceCreation” topic is a specialization of the “Manageability
EndpointCreation” topic. This topic corresponds to the case where the 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 returned. But if, along with the resource
being created, a manageability endpoint for the resource is created then a notification will be sent
to subscribers on this topic.
1307
1308
1309
1310
1311
The “muws-ev:ManageabilityEndpointDestruction” topic corresponds to notification on
destruction of a manageability endpoint. It does not imply that the associated resource was
destroyed. The associated muws-xs:DestructionNotification message contains the muwsxs:ResourceId that the newly destroyed manageability endpoint was providing for the resource
before being destroyed.
1312
1313
1314
1315
1316
1317
1318
The “muws-ev:ManageableResourceDestruction” topic is a specialization of the
“ManageabilityEndpointDestruction” topic. This topic corresponds to the case where the resource
itself is being destroyed at the same time as the manageability endpoint. Note that if a resource is
being destroyed that was not manageable (that didn’t have a manageability endpoint) no
notification on this topic will be sent. The associated muws-xs:DestructionNotification message
contains the muws-xs:ResourceId that the newly destroyed manageability endpoint was providing
for the resource before being destroyed.
1319
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 38 of 55
1320
6 Discovery and Introspection
1321
1322
1323
1324
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
as commonly used for Web services will be used as discovery methods for manageability
services.
1325
1326
1327
1328
1329
1330
There exists but one normative requirement relative to discovering manageability services, as
follows: A manageability service MUST provide the Identity capability through the corresponding
WSDL interface as defined by MUWS. As a result of this requirement, a consumer can inspect
the WSDL description for a Web service and determine if the discovered service acts as a
manageability service. If the discovered service implements the Identity interface defined by
MUWS, then it is a manageability service.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 39 of 55
1331
7 Defining a Manageability Interface
1332
The following are normative statements for MUWS representation.
1333

WSDL 1.1 must be used.

1334
1335
Additionally, WSDM defines portTypes which have to be combined into a custom
portType, operation by operation, according to the WSDL specification.
1336

Document/literal binding must be used.
1337
1338

MUWS defines property elements which have to be combined into a custom properties
document according to WS-ResourceProperties specification
1339
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 40 of 55
1340
8 References
1341
8.1 Normative
1342
1343
[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.
1344
1345
[RFC3066]
1346
1347
1348
IETF (Internet Engineering Task Force). RFC 3066: Tags for the
Identification of Languages, ed. H. Alvestrand. 2001,
http://www.ietf.org/rfc/rfc3066.txt
1349
1350
[XML Schema Part 1]
1351
1352
Henry S. Thompson, et al. XML Schema Part 1: Structures, W3C
Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/
1353
1354
[XML Schema Part 2]
1355
1356
Paul V. Biron, et al. XML Schema Part 2: Datatypes, W3C
Recommendation, May 2001, http://www.w3.org/TR/xmlschema-2/
1357
1358
[XML1.0 3rd Edition]
1359
1360
Tim Bray, et al., Extensible Markup Language (XML) 1.0 (Third Edition),
W3C Recommendation, February 2004, http://www.w3.org/TR/REC-xml
1361
1362
1363
1364
1365
1366
1367
[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/
1368
1369
[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.00published-20020719.htm
[WSA]
David Booth, et al. Web Services Architecture, W3C Working Group
Note, February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch20040211/
[WS-BaseN]
XXX
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 41 of 55
1381
[WST]
XXX
[WSN]
XXX
[WSRL]
XXX
[WSRF]
Karl Czajkowski, et al. The WS-Resource Framework version 1.0,
http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-10.pdf and related documents available at
http://devresource.hp.com/drc/specifications/wsrf/index.jsp
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
[WS-ResourceProperties]
1393
1394
1395
Steve Graham, et al., Web service Resource Properties version 1.1,
January 2004, http://devresource.hp.com/drc/specifications/wsrf/WSResourceProperties-1-1.pdf
1396
1397
1398
1399
[WS-Addressing] Don Box, et al., Web services Addressing, March 2003,
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnglobspec/html/ws-addressing.asp
1400
1401
1402
1403
1404
1405
8.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/internetdrafts/draft-fielding-uri-rfc2396bis-04.txt
[MUWS REQS]
Pankaj Kumar, et al., Requirements – Management Using Web Services,
Committee Draft, October 2003, http://www.oasisopen.org/apps/org/workgroup/wsdm/download.php/6185/WSDM-MUWSReq-committee-draft-1.0-20031002.pdf
1406
1407
1408
1409
1410
1411
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 42 of 55
1412
Appendix A. Acknowledgements
1413
The following people made contributions to this specification:
1414

Winston Bumpus
<[email protected]>
1415

Brian Carol
<[email protected]>
1416

Fred Carter
<[email protected]>
1417

John DeCarlo
<[email protected]>
1418

Andreas Dharmawan
<[email protected]>
1419

Mark Ellison
<[email protected]>
1420

Heather Kreger
<[email protected]>
1421

Hal Lockhart
<[email protected]>
1422

Bryan Murray
<[email protected]>
1423

Richard Nikula
<[email protected]>
1424

Micheal Perks
<[email protected]>
1425

Homayoun Pourheidari
<[email protected]>
1426

Karl Schopmeyer
<[email protected]>
1427

Igor Sedukhin
<[email protected]>
1428

Ellen Stokes
<[email protected]>
1429

William Vambenepe
<[email protected]>
1430

Andrea Westerinen
<[email protected]>
1431
1432
1433
The following individuals were voting members of the committee during the development of this
specification:
1434

Guru Bhat
<[email protected]>
1435

Jeff Bohren
<[email protected]>
1436

Winston Bumpus
<[email protected]>
1437

Fred Carter
<[email protected]>
1438

John DeCarlo
<[email protected]>
1439

Andreas Dharmawan
<[email protected]>
1440

Mark Ellison
<[email protected]>
1441

Daniel Foody
<[email protected]>
1442

Heather Kreger
<[email protected]>
1443

Bryan Murray
<[email protected]>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 43 of 55
1444

Paul Lipton
<[email protected]>
1445

Hal Lockhart
<[email protected]>
1446

Rajiv Maheshwari
<[email protected]>
1447

Richard Nikula
<[email protected]>
1448

Michael Perks
<[email protected]>
1449

Homayoun Pourheidari
<[email protected]>
1450

Karl Schopmeyer
<[email protected]>
1451

Igor Sedukhin
<[email protected]>
1452

Davanum Srinivas
<[email protected]>
1453

Ellen Stokes
<[email protected]>
1454

Thomas Studwell
<[email protected]>
1455

Ryoichi Ueda
<[email protected]>
1456

William Vambenepe
<[email protected]>
1457

Andrea Westerinen
<[email protected]>
1458
1459
Concepts for the "Metrics" section were inspired by work from the DMTF applications/Metrics WG.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 44 of 55
1460
Appendix B. Notices
1461
1462
1463
1464
1465
1466
1467
1468
1469
OASIS takes no position regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such rights. Information on
OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS
website. Copies of claims of rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a general license or permission
for the use of such proprietary rights by implementors or users of this specification, can be
obtained from the OASIS Executive Director.
1470
1471
1472
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.
1473
Copyright © OASIS Open 2003. All Rights Reserved.
1474
1475
1476
1477
1478
1479
1480
1481
1482
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.
1483
1484
The limited permissions granted above are perpetual and will not be revoked by OASIS or its
successors or assigns.
1485
1486
1487
1488
1489
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.
1490
1491
1492
1493
1494
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 45 of 55
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
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/XX/muws/schema"
targetNamespace="http://docs.oasis-open.org/wsdm/2004/XX/muws/schema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name=”LangString”>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ResourceId" type="xs:anyURI"/>
<xs:element name="Caption" type=”muws-xs:LangString” minOccurs=”0” maxOccurs=”unbounded”/>
<xs:element name="Description" type=”muws-xs:LangString” minOccurs=”0” maxOccurs=”unbounded”/>
<xs:element name="Version" type="xs:string" minOccurs=”0”/>
<xs:complexType name="Category">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name=”Available”/>
<xs:element name=”Degraded”/>
<xs:element name=”Unavailable”/>
<xs:complexType name="StateInformation">
<xs:sequence>
<xs:element name="State" type="muws-xs:Category"/>
<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:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Counter"/>
<xs:enumeration value="Gauge"/>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 46 of 55
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="TimeScope">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Interval"/>
<xs:enumeration value="PointInTime"/>
<xs:enumeration value="StartupInterval"/>
</xs:restriction>
</xs:simpleType>
</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">
<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"
namespace="##other" processContents="lax"/>
</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"
namespace="##other" processContents="lax"/>
</xs:sequence>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 47 of 55
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
</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"
namespace="##other" processContents="lax"/>
</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:complexType name=”RelationshipType”>
<xs:complexContent>
<xs:extension base=”muws-xs:Category”/>
</xs:complexContent>
</xs:complexType>
</xs:schema>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 48 of 55
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
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/XX/muws/schema"
xmlns:muws-wsdl="http://docs.oasis-open.org/wsdm/2004/XX/muws/wsdl"
targetNamespace="http://docs.oasis-open.org/wsdm/2004/XX/muws/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>
<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>
<operation name="Stop">
<input name="StopRequest" message="muws-wsdl:StopRequest"/>
<output name="StopResponse" message="muws-wsdl:StopResponse"/>
</operation>
</portType>
<portType name="Metrics"
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 49 of 55
1682
1683
1684
1685
wsrp:ResourceProperties="muws-xs:MetricsProperties">
</portType>
</definitions>
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 50 of 55
1686
Appendix E. Web Services Platform
1687
1688
1689
This section briefly describes the Web services platform features that are required in order to
specify Management Using Web Services (MUWS), and makes recommendations on the support
of each feature. Recommendations made in this section will either:
1690

Reference another specification to be used to provide the feature
1691

Identify the feature as something that needs to be provided by the industry in the future
1692
1693

Identify the feature as something that needs to be defined in a WSDM TC interim
specification until such a feature is available for the Web services platform.
1694
Initial Focus
1695
The Web services platform used by this version of MUWS must support the features listed below.
1696
Properties
1697
1698
1699
1700
1701
Properties are describable information that can be queried and may also be set.. Properties, and
their associated messages and operations, may be provided by a Web service interface in a
schema document. A Property consist of a declaration, or name, and a description, or type.
Properies should be introspectable at design-time and at run-time. By using a property schema,
it is possible to find, to read, and to write a property.
1702
1703
For manageability, a property is part of the advertised manageability interface for a resource. For
manageability, a property can represent configuration values, metrics, identifiers, and so on.
1704
1705
1706
1707
Motivation: Many manageability capabilities of a manageable service concern the resource the
manager is able to query and set. This information should be modeled as a set of properties, and
their access methods. Note that there is a need for access methods that meet the scalability
requirements of management applications, for example ”bulk-get”.
1708
1709
Recommendation: Use the WS-Resource Properties specification [WS-ResouceProperty] to
describe the properties of a manageable resource.
1710
Meta Data
1711
1712
1713
1714
1715
Meta data is generally defined as data about data. In the context of management, it is additional
descriptive information about the components of a manageability interface. Meta data may apply
to the properties, operations, events, and capabilities of the manageability interface, or, meta data
may apply to the context, quality, condition, and character of referenced data. Meta data can be
introspected at design-time and at run-time.
1716
Motivation: In IT management, meta data is important for:
1717
1718
1719
1720

describing data in richer ways, and ultimately, to link data with the goals driving the
existence of the source of this data, For example, meta data concerning the limitations,
purpose, context, quality, and character of management data helps describe how the
associated data relates to the objectives of an IT environment
1721
1722

enabling the interoperability of manageability capabilities, as provided by numerous,
different providers
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 51 of 55
1723
1724
1725
Recommendation: Descriptive information about the manageability interface will be expressed
as XML element attributes as a tactical solution for WSDM 0.5. This satisfies run-time
introspection, but does not provide for design-time introspection.
1726
1727
1728
1729
A strategic solution will be developed for WSDM 1.0 supporting run-time and design-time
introspection. The concept of a qualifier, as described in the DMTF Common Information Model
(CIM), and consisting of meta-data concerning a class, property, method, notification or method
parameter may be mined for useful ideas for manageability meta-data..
1730
Addressing
1731
1732
1733
1734
1735
1736
1737
1738
1739
An address, or reference, is a data structure referencing a unique Web service. Addressing may
be used to reference the Web services of a manageability provider, or, to reference a
manageable resource. This data structure must hold sufficient information for a manageability
consumer to to locate the Web service and to exchange messages with the Web service. When
the referenced Web service provides manageability for several resources, the reference data
structure needs to uniquely identify a specific resource. The reference data structure must include
data needed to locate the description of its Web service. This enables the manageability
consumer to identify the messages understood by the Web service. In this context, address and
reference are used synonymously.
1740
1741
1742
Motivation: Manageability consumers need interoperable addressing to reference common
manageability services and manageable resources, as a reference for relationships, in
notifications and messages.
1743
1744
1745
Recommendation: Use the WS-Addressing specification
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsaddressing.asp).
1746
Notification
1747
1748
1749
1750
1751
Notification is a method of conveying information from a source to recipients expressing interest.
In terms of Web services, a notification means delivering an XML message from the source to
addressable recipients. An interest in receiving notifications must be established with the source
by the recipient, or by a third party on behalf of the recipient. When registering interest, the
address(es) of the recipient(s) must be provided (see Addressing, above).
1752
1753
1754
1755
1756
1757
1758
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 the event occurs. The manageable resource needs to know which manager is
interested in which information and the address(es) of the manager in order to send a notification
message whenever an event occurs.
1759
Recommendation: Use the WS-Notifications specification [WS-Notification].
1760
Versioning
1761
1762
1763
1764
1765
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.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 52 of 55
1766
1767
1768
1769
Motivation: A manager of manageable resources must have the ability to query the available
endpoint revisions, along with the corresponding change descriptions allowing that the manager to
discern the most appropriate and compatible interface of a particular manageability function that
her management client can use.
1770
1771
1772
1773
1774
Recommendation: Addressed by the WSDM TC as part of the “Management of Web Services”
(MOWS) specification under development for a Web service. W3C recommendations on this
topic [W3C TAG finding on Versioning] must be considered and accomodated. MUWS must
provide access to version information as part of the description of the identity property of a
manageable resource.
1775
Security
1776
1777
1778
1779
1780
1781
1782
There 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 TBD]
Security requirements within the scope of manageability are not unique to manageability. Every
manageability endpoint and many business, or functional, endpoints have similar requirements for
confidentiality, integrity, and authentication, as well as for access control, availability, and privacy
(see the glossary definition of Security).
1783
1784
1785
1786
1787
Motivation: Resources have to be manageable in a secure way (see the glossary definition of
Security). Security infrastructure mechanisms should be composed and layered on top of
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.
1788
1789
1790
1791
Recommendation: WSDM will follow the recommendation of the OASIS WS-Security TC. For
the 1.0 specifications, WSDM should examine WS-Security in order to ensure nothing in the
specification precludes the composability of Security. In addition, security should be manageable
via Web services.
1792
Registration and Discovery
1793
1794
1795
1796
1797
1798
Registration is a method of advertising the 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.
1799
1800
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.
1801
1802
Recommendation: UDDI specification will satisfy most requirements. Existing Web services
discovery practices are sufficient.
1803
Future Focus
1804
1805
Future versions of the WSDM TC specifications may also require support from the Web services
platform, as follows.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 53 of 55
1806
Policy
1807
1808
1809
A Policy is a course of action, a guiding principle, or a procedure that is considered expedient,
prudent, or advantageous, for a given condition or event. A Policy describes a broad range of
service requirements, preferences, and capabilities.
1810
1811
1812
1813
1814
There are two kinds of policy governing the management of manageable resources. One policy
set describes how the client of a manageable resource interacts with the functional interfaces of
the resource. An example might be a policy describing the privacy of data., A policy set describing
how the manager of a manageable resource establishes operational requirements for a resource.
An example might be a policy describing service level agreements.
1815
1816
1817
1818
1819
1820
Motivation: There are various policies that can be specified for manageable resources including:
authentication, access control, privacy, non-repudiation, service level agreement, quality of
service, routing, content inspection, auditing, and so on. MUWS must leverage existing Web
services specifications and technologies in its approach to applying policies to manageable
resources. MUWS should endorse a list of such specifications and technologies, and should
specify compatibility and interoperability requirements.
1821
Recommendation: None at this time.
1822
Name Resolution
1823
1824
1825
1826
1827
1828
Name Resolution is necessary for management purposes and requires a name resolution service.
The name resolution service accepts a name identifier (URI) of a resource and returns an address
or reference to the manageability endpoint for the resource. The service should return sufficient
information to invoke the manageability endpoint. . The name resolution service may be used to
resolve names to references that are meaningful within other application domains, and unrelated
to management. One example would be service discovery.
1829
1830
1831
1832
Motivation: A name resolution service is necessary for manageability because manageable
resources and manageability services expose many identifiers provided by existing
instrumentation and technologies. A manageability consumer needs the ability to get a reference
to any resource identifier, within any application domain, with which it wishes to interact..
1833
Recommendation: None at this time.
1834
Transaction
1835
1836
1837
1838
1839
A “unit of work” that consists of multiple actions, typically an ordered set operation, that is applied
to a single resource, or applied to multiple resources. The “unit of work” should be executed once
and only once, even if, due to transmission failures or other errors, some request within the
transaction is received multiple times. There are three possible results from the execution of a
transaction:
1840

all actions against all resources succeed
1841
1842
1843

one or more actions fail, and all actions against all resources are rolled back.
Note: if roll back is not possible, or not supported, then the resource state should revert to
some known-as-good operational state or configuration.
1844

one or more actions may fail, and the resource states are left as affected.
1845
1846
1847
Motivation: Grouping actions against resources and assuring their execution is of great value in
managing the resources. A manager may request that multiple actions or operations be
performed as a single “unit of work” preserving the integrity of the resources involved.
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 54 of 55
1848
1849
Recommendation: None at this time.
1850
Flow
1851
1852
1853
1854
1855
1856
1857
Flow, more often called workflow or workflow management, is the management of business
processes using information technology. When an organization defines, analyzes, and organizes
its resources and operations, workflow management systems can ensure the right information
reaches the right person, or computer application, at the right time. Business process
management (BPM) workflow or execution languages support the composing services into more
complex processes which may also be exposed as a Web service. The description of such
coordinated activities should include,, but should not be limited to:
1858

constructs for the identification of partners
1859

message correlation
1860

fault detection and compensating activities
1861

parallel and serial execution of services
1862
1863
1864
1865
1866
Motivation: Web services orchestration languages may be useful tools allowing Web services
management providers to support the more complex business oriented actions that can 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, for a composite Web
service that exposes the sessions and the state of a resource and any subordinate resource,.
1867
Recommendation: None at this time.
1868
Negotiation
1869
1870
1871
Negotiation is the process by which two services dynamically negotiate the terms of a contract. A
contract is negotiated by the initiators and the participants of that contract. A contract is a
document that represents a set of objectives assigned to a set of resources.
1872
1873
1874
1875
1876
Motivation: It is important for resources to understand what they can expect from other
resources, from managed resources, from management services, and from managers. The
process of negotiation enables initiators and participants to better describe their own level of
performance and how information shall be exchanged between the components of federated
deployments.
1877
Recommendation: None at this time.
1878
cd-wsdm-muws-10
Copyright © OASIS Open 2003-2004. All Rights Reserved.
Page 55 of 55