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

2Web Services Distributed 3Management: Management Using 4Web Services (MUWS 0.5)

5Committee Draft, 1 April 2004

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

8Location: 9 http://docs.oasis-open.org/wsdm/2004/04/muws-0.5 10Editors: 11 Andreas Dharmawan, Westbridge Technology 12 William Vambenepe, Hewlett-Packard 13Abstract: 14 There are two parts of Web services Distributed Management: Management Using Web 15 services and Management of Web services. This specification defines the former. 16 Management Using Web services defines how an Information Technology resource 17 connected to a network provides the manageability interfaces such that it can be 18 managed remotely using Web services technologies.

19Status: 20 This document is a committee draft approved by the WSDM TC. It is not intended to 21 become an OASIS standard. There is no guarantee that any part of its content will 22 appear in the final release specification, MUWS 1.0. 23 Committee members should send comments on this specification to the 24 [email protected] list. Others should subscribe to and send comments to the 25 [email protected] list. To subscribe, send an email message to 26 [email protected] with the word “subscribe” as the body of 27 the message. 28 For information on whether any patents have been disclosed that may be essential to 29 implementing this specification, and any offers of patent licensing terms, please refer to 30 the Intellectual Property Rights section of the WSDM TC web page (http://www.oasis- 31 open.org/committees/wsdm/). 32 The errata document for this specification is at: 33 http://docs.oasis-open.org/wsdm/2004/04/muws-0.5-errata

361 Introduction...... 4 37 1.1 Terminology...... 4 38 1.2 Notational conventions...... 4 392 Architecture...... 6 40 2.1 Context...... 6 41 2.2 Conceptual Model...... 7 42 2.3 Logical Model...... 8 43 2.3.1 Role Definitions...... 9 44 2.4 Composability...... 10 45 2.5 Processing Model...... 11 46 2.5.1 Prerequisites...... 11 47 2.5.2 Discovery...... 11 48 2.5.3 Interaction...... 11 493 Support from Web Services Platform...... 13 504 Manageability Capabilities...... 14 51 4.1 Identity...... 15 52 4.1.1 Definition...... 15 53 4.1.2 Data Types...... 16 54 4.1.3 Properties...... 16 55 4.2 State...... 17 56 4.2.1 Definition...... 17 57 4.2.2 Description of State Model...... 18 58 4.2.3 Data Types...... 19 59 4.2.4 Properties...... 19 60 4.2.5 Operations...... 20 61 4.3 Metrics...... 21 62 4.3.1 Definition...... 21 63 4.3.2 Data Types...... 22 64 4.3.3 Properties...... 23 65 4.3.4 Operations...... 23 665 Discovery and Introspection...... 25 676 Defining a Manageability Interface...... 26 687 References...... 27 69 7.1 Normative...... 27 4wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 5Copyright © OASIS Open 2003. All Rights Reserved. Page 2 of 40 6 70 7.2 Non-normative...... 28 71Appendix A. Acknowledgements...... 29 72Appendix B. Notices...... 31 73Appendix C. Schemas (Normative)...... 32 74Appendix D. WSDL elements (Normative)...... 34 75Appendix E. Web Services Platform...... 36 76 Initial Focus...... 36 77 Properties...... 36 78 Meta Data...... 36 79 Addressing...... 37 80 Notification...... 37 81 Versioning...... 37 82 Security...... 38 83 Registration and Discovery...... 38 84 Future Focus...... 38 85 Policy...... 38 86 Name Resolution...... 39 87 Transaction...... 39 88 Flow...... 39 89 Negotiation...... 40

92Management Using Web Services (MUWS) enables management of distributed IT resources 93using Web services. Many different distributed complex IT resources have use different 94management interfaces. By leveraging the Web service technology, MUWS enables easier and 95more efficient IT management systems through by providing a flexible common framework for 96manageability interfaces that benefits from the features of Web services protocols. Universal 97management interoperability among across the many different varieties of distributed IT 98resources can be achieved using MUWS. 99The types of management capabilities that exposed by MUWS allows to expose are the 100management capabilities generally expected in distributed IT management systems. Examples of 101manageability functions that can be performed via MUWS are include: 102  monitoring quality of services monitoring, 103  enforcing service level agreements enforcement 104  , task controlling tasks 105  , managing resource life-cycles, and so on. 106 107MUWS is designed to meet the requirements defined in the MUWS Requirements document 108[MUWS REQS]. Whenever possible, MUWS leverages existing Web services specifications to 109ensure interoperability, adoptability, and extensibility. 110There is a minimum set of manageability capabilities that the manageability provider must support 111in order to participate in MUWS. This minimum set of manageability capabilities is defined in this 112specification. 113Additionally, this specification discusses the methods and mechanisms provided by MUWS to for 114discovering the manageability interfaces of the manageable IT resource is discussed in this 115specification.. 116Finally, the manageability interface itself also is defined in this specification. 117To understand the various topics discussed in this specification, the reader should be familiar with 118the IT management concepts. In addition, the following assumptions are made: 119  The reader is familiar with the Web Services Architecture [WSA] 120  The reader is familiar with XML [XML1.0 3rd Edition] , XML Schema [XML Schema Part 121 1] [XML Schema Part 2], and XML Namespace [XNS] 122  The reader is familiar with WSDL [WSDL1.1], SOAP [SOAP1.1] , UDDI [UDDI] 123  The reader is familiar with WS-ResourceProperties [WS-ResourceProperties], WS- 124 Addressing [WS-Addressing] 125Section 3, 4, 5, 6 and appendices C (schemas) and D (WSDL elements) are normative 126specifications with the following exception: UML illustrations found in section 4 are non- 127normative. The rest of the document is a non-normative, explanatory material intended to ease 128the understanding...

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

1331.2 Notational conventions

134This specification uses an informal syntax to describe the XML grammar of the messages making 135up the management interfaces. This syntax uses the following rules: 136 . The syntax appears as an XML instance, but the values indicate the data types appear 137 instead of values. 138 . {any} is a placeholder for elements from some other namespace (like ##other in the XML 139 Schema). 140 . Characters are appended to attributes, elements, and {any} to indicate the The 141 Cardinality of an attribute, element, or {any}, is indicated by appending characters to the 142 item as follows: 143 ? none,or one 144 * none, or more 145 + one, or more 146 No character exactly one 147  Items contained within the square brackets, [ and ], are treated as a group. 148 . Items separated by | and grouped within parentheses, ( and ), indicate syntactic 149 alternatives. 150 . Three consecutive periods, ... is are used in XML start elements to indicate that attributes 151 from some other namespace are allowed. 152 . The XML namespace prefixes, (defined below,) are used to indicate the namespace of 153 the element being definedItem. 154When defining operations, this specification uses pseudo-schema to describe the input and, (if 155appropriate,) output messages. A full WSDL description of all operations is available in the 156appendix of this specification.

1592.1 Context

160This section provides a context for the WSDM MUWS Architecture. The MUWS Architecture 161makes use of the Web services Services Architecture (WSA). 162WSA provides a common definition of a Web service, as well as a conceptual model and a 163context for understanding Web services and the relationships between its Web service 164components. It WSA describes the characteristics that are common to all Web services and 165describes some characteristics that are needed by many, but not all, Web services. Additionally, it 166is interoperability architecture.: Byit identifyingies those global elements of the global Web 167services network that are required in order to ensure interoperationbility between among Web 168services, WSA provides an architecture of interoperability for MUWS. 169Since the Web services architectureWSA defines how to specify information and operations 170through WSDL interfaces, access through bindings, and discovery through endpoints. Therefore, 171it is consistent to use the Web services architectureWSA to describe,- as well as provide access 172to, and discoverability- of, the manageable components of the Web services architectureWSA 173itself. In fact, the this paradigm can be extended to by providinge the access to, and 174discoverability of, any manageable resource in the IT infrastructure. 175The management interface of a resource can be exposed through a Web service interface in the 176same way as the functional interface. This is true even if Web services are not used to provide 177access to the functionality of the resource. 178Figure 2.1-1 illustrates two possible methods a manageable Web service may use to fulfill 179management requests on an exposed resource.

181 16wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 17Copyright © OASIS Open 2003. All Rights Reserved. Page 6 of 40 18 182 Figure 2.1-1, MUWS on IT Resource 183With the first method, a manageability service interacts directly with an exposed resource through 184a supported management interface. For example, the manageability service may interact with an 185exposed resource supporting Java’s JMX facility, or interact with an exposed resource supporting 186a proprietary C API. 187With the second method, the manageability service interacts indirectly with an exposed resource 188through a management agent acting as an intermediary. This management agent interacts either 189directly or indirectly with the exposed resource. 190This second method enables existing management instrumentation of a resource to be exported 191through Web services to a management consumer. 192Whether the manageability service uses the direct method or the indirect method, the 193management consumer is provided a consistent view of the management instrumentation of the 194exposed resource. The management consumer remains unaware of any legacy management 195agent, facillity or API utilized by the manageability service. 196Using Web services to describe and provide access to a manageability interface for an exposed 197resource creates a consistent, cross platform, cross vendor, and potentially cross enterprise 198interaction model for consumers and producers of management information. 199Creating a Web services to access manageability information of an exposed resource does not 200preclude alternate means to access this information. For example, a management consumer is 201able to use any and all of WSDM MUWS, SNMP or CIM/WBEM to access manageability 202information for an exposed resource.

2032.2 Conceptual Model

204This MUWS specification defines how manageability of an arbitrary IT resource can be accessed 205via Web services. Manageability is one possible quality of a resource. Manageability is composed 206of a number of capabilities. Each capability has its own distinct semantics. Therefore, a 207manageable resource composes a set of manageability capabilities. Figure 2.3-1, relates the 208concepts necessary for management using Web servicesMUWS. 209According to the concepts in the WSDL specification, a Web service is an aggregate of 210endpoints. Each endpoint each offering offers the Web service at an address and that is 211accessible according to a binding. A Web service has a some number of interfaces that are 212realized by all of its endpoints. 213Each interface describes a set of named messages, that could be exchanged and their formats, 214that can be exchanged. Properly formatted messages could can be sent to the address of an 215endpoint’s address in a way prescribed by the binding. A description, either as (a document, or 216an artifact,) is composed of with definitions of interfaces and services. A description may contain 217definitions of interfaces, or definitions of services, or definitions of both. or either of the definitions. 218In accordance with the Web services concepts expressed above, access to the manageability for 219a resource must be provided by an endpoint. We call such an endpoint a manageability endpoint. 220Implicitly, a manageability endpoint belongs to a manageability service, which has a number of 221manageability interfaces that are realized by manageability endpoints. 222Thus, a single manageability interface represents all or part of a manageability capability. 223Similarly, a single manageability capability may be represented in by one or more interfaces. The 224semantics of a particular interface includes the description of a the set of possible message 225exchanges. The exchanges are which is rendered in as message formats grouped into one or 226more interfaces.

19wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 20Copyright © OASIS Open 2003. All Rights Reserved. Page 7 of 40 21 227For example, the ability to offer metrics could be captured in a “Metrics” UML model which is an 228instance of the manageability capability concept. The semantics of offering metrics could be 229rendered from the UML model into a WSDL interface description defined within a the 230“http://www.docs.oasis-open.org/wsdm/2004/04/manageability/metrics” namespace. That Such a 231rendering would be an instance of the manageability interface concept. 232This specification defines the base set of manageability capabilities that could can be composed 233into a manageable resource or combined into aggregate capabilities. For example, a 234TotallyManagableResource uber-capability could be defined that includes all of the base 235manageability capabilities defined in this specification. Such an aggregate manageability 236capability could also be composed into a manageable resource, and in that sense, an aggregate 237manageability capability is conceptually the same as any other capability. However, this 238specification does not currently attempt to define (define or identify) the aggregate capabilities. 239Rather, this specification and focuses on the definition of the base set manageability capabilities.

240 241 Figure 2.3-1, MUWS Concepts

2432.3 Logical Model

244A manageability provider may provide the manageability quality capabilities for many resources. 245In other words a manageability provider may enable expose many resources become as 246manageable resources., instances of which belong to one instance of the Provider. 247To accomplish this, a manageability provider maintains manageability endpoints. which A 248manageability endpoint provides a means to access to the one or more manageable 249resources. According to the our concepts conceptual definition, a manageable resource is a 250resource composed with any number of manageability capabilities composed into it. In order to 251compose capabilities into the manageable resource, a manageability provider supports the 252manageability capabilities that are are offered by the its manageability endpoints. 253For example, a manageability provider could embed a piece of code into a resource to supporting 254the manageability capabilities into a of the resource, thus making a the resource manageable. A 255manageability Pprovider may could also support the manageability capabilities by deploying 256resources within a container that could add supports manageability quality capabilities to for all its 257resources. 258The manageability consumer manages manageable resources. To manage in this context means 259to exert control and to obtain and interpret the information about the manageable resource. In

22wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 23Copyright © OASIS Open 2003. All Rights Reserved. Page 8 of 40 24 260order to manage the manageable resource, the consumer accesses manageability endpoints and 261exercises the offered manageability capabilities offered by the endpoint. 262To exercise in this context means to make use of the distinct semantics defined byof a given 263manageability capability. Essentially, the consumer exercises the an understanding of the 264semantics defined by a manageability capability, but exercises it this understanding on the an 265actual manageable resource. In a tTechnically sense, to exercise offered manageability 266capabilities it translates into being able to usinge a distinct group of properties, operations, events 267and metadata by exchanging messages with the manageability endpoint. 268For example, consider a server with several disk drives. The manageability provider could be a 269piece of software process running on the machineserver. This manageability provider could allow 270each disk drive to become a manageable resource by providing a manageability endpoint for 271each disk drive a manageability endpoint. The implementation of these endpoints by the provider 272could use OS calls to access the disk drives. This pattern could be used to provide and expose 273(through the manageability endpoints) manageability capabilities exposed through manageability 274endpoints,, such as retrieving the amount of disk space available in each disk drive. 275An IT management console, acting as a manageability consumer, could then exercise this 276manageability property by connecting to the manageability endpoints provided by the 277manageability provider. In Using this example, the management console could retrieve the 278amount of disk space available in on each disk drive.

279 280 Figure 2.4-1, MUWS Logical Model

2812.3.1 Role Definitions

282This section documents defines the roles and interactions that of the major components of the 283MUWS Architecture, as well asand related components, within the MUWS Architecture., will have 284during Management Using Web services. It This section is not intended to constrain the locus of 285implementation., but insteadRather, this section is intended to documents the required 286components, their roles, and how they interact. 25wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 26Copyright © OASIS Open 2003. All Rights Reserved. Page 9 of 40 27 287NOTE: One application implementation may have be a single component with many roles or 288while another implementaion a full role may be implemented by a combinationcomposed of many 289different applicationsseveral components, each with an assigned role. 290The major roles are the manageability consumer, the manageability provider, and the 291manageability resource. These roles are represented by the shaded boxes in the MUWS Logical 292Model (Figure 2.4.-1).

2932.3.1.1 Manageability Consumer

294The manageability consumer: does the following: 295  Consumes managementability information. about the resource 296  Manages, monitors, configures the resource (monitor, configure, etc). 297  Understands the manageability capabilities of the resource.

2982.3.1.2 Manageability Provider

299The manageability provider does the following: 300  Provides the manageability quality for a manageable resource, enabling a resource to 301 become a manageable resource. 302  Provides management information for consumers (according to the manageability 303 capabilities of the resource). 304NOTE: The manageability Pprovider may be implemented in the manageable resource or it may 305not. The manageability provider may supply provide the manageability quality for more than one 306manageable resource. In other words, thisThus, the role of manageability provider is not 307intended to constrain the locus of implementation.

3082.3.1.3 Manageable Resource

309The Manageable Resource is an IT resource that can beis manageabled by via a WSDM MUWS 310based infrastructure. Because there are no restrictions on the locus of implementation, the 311manageable resource may, or may not, implement the role of manageability Pprovider of for the 312manageability service. 313For An example, of a disk drive could beas a manageable resource was explained described in 314the example in section 2.4. The 315A manageable resources does not have to be fine-grained. For exampleTo illustrate this point, a 316complete server could be a manageable resource. (and tThe manageability provider providing 317offering the manageability endpoint for theat “server” resource could can run either on the server, 318being made manageable or on another some other machine). At an even higher level of 319granularity, a server farm could be exposed as a single one manageable resource. For 320exampleTo illustrate this point, an IT management software package could act as a manageability 321provider and provideoffering a manageability endpoints for a the server farm, and exposing 322manageability capabilities. Examples of manageability capabilities might be such retrieving the 323cumulative aggregate available disk space available in for all the servers in on the farm, or, 324bringing up or down the all the servers in on the farm. This Such a manageability provider for the 325server farm could be implemented using a set of proprietary interfaces to for the servers 326composing on the farm. or, Alternatively, (if the servers are manageable resources,) by such a 327manageability provider could acting as a manageability consumer by accessing and aggregating 328the manageability capabilities of the servers on the farmand aggregating them. 28wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 29Copyright © OASIS Open 2003. All Rights Reserved. Page 10 of 40 30 3292.4 Composability

330MUWS specification allows the resource and its service to be manageable in a standard and 331interoperable manner. This is achieved by defining the manageability capabilities and interfaces 332of a resource. A resource may support both the manageability capabilities and functional 333capabilities. In which this case, it the resource may chose to allow managmanageability 334consumersers access to appropriate functional capabilities along with the manageability 335capabilities. Managers could discover such composition by inspecting the service description. 336 Managers could take advantage of the composition of manageability with functional capabilities 337by, for example, querying for free disk space using a disk manageability capability and along with 338thatthen reading disk sectors from the disk serviceusing a disk functional capability. This 339Composability makes it easy for implementers of the a resource services to offer an appropriate 340subset of functional capabilities along with its proper set of manageability capabilities.

3412.5 Processing Model

342The cCompliant implementations of the roles as defined in section 2.3, the logical model, act 343according to the following basic processing rules.

3442.5.1 Prerequisites

345A manageability consumer and a manageability provider have toMUST understand the 346information model with in which the semantics of a manageability capability are described. For 347example, it could be a UML model that could expresses a group of properties, operations, events 348and metadata. The meaning of what the model defines has tomust be equally understood by both 349parties, provider and consumer. The bBase capabilities defined in MUWS, as well as those the 350capabilities defined in domain-specific specifications that builtd on top of MUWS, are the means 351to achievinge such an understanding. 352A manageability consumer and a manageability provider both have to equallyMUST understand 353how to establish identify which manageability interface corresponds to which with a manageability 354capability, and vice versa. The base capabilities described Specification ofin WSDM MUWS 355manageability capabilities clearly indicates thatare the means to achieving such and 356understanding. 357A manageability consumer has toMUST be able to obtain the description of the manageability 358service, its endpoints and necessary manageability interfaces. The manageability provider (,or 359another party on behalf of the provider,) makes such descriptions available to the consumer. 360A manageability provider has toMUST be able to obtain the description of the manageability 361interfaces for the capabilities it wants to support. MUWS includes in-line descriptions, (usually as 362appendices,) of XML Schemas and WSDL elements for all of the manageability capabilities. It 363MUWS also indicates URL locations of such XML schema documents and WSDL documents 364hosted on the OASIS Web site.

3652.5.2 Discovery

366A manageability consumer discovers the necessary manageable resources by discovering the 367manageable endpoints, reading their descriptions and exchanging messages as required. MUWS 368indicates which manageability capabilities can be used to discover other Web services endpoints 369and/or other manageability endpoints. 370To discover manageable endpoints in the first place, the consumer uses the same discovery 371techniques in discoveringas used for any other Web service endpoints. For example, it the

31wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 32Copyright © OASIS Open 2003. All Rights Reserved. Page 11 of 40 33 372consumer may be provided with a URL to referencing a WSDL document that describinges a the 373manageability service. 374A manageability provider advertises, /registers, and /publishes available manageability endpoints 375just like any other Web service endpoints. 376A manageability consumer establishes which capabilities are supported by the manageable 377resource either from the description of the manageability service or by exchanging messages with 378the manageability endpoint. For example, a consumer may inspect a WSDL document looking for 379manageability operations it is interested in. MUWS and the specifications that build on top of it 380clearly indicate which message Qnames correspond to which operations and which capabilities 381they participate in.

3822.5.3 Interaction

383A manageability consumer exerts control over, and obtains information about, the manageable 384resource by exchanging messages with one or more manageability endpoints that providinge 385access to the manageable resource. Message exchanges must match theat format and sequence 386which isas prescribed by the binding description of the endpoint. This interaction is not any 387different than exchanging messages with any otherfunctional Web service endpoints. 388Figure 2.5.3-1 captures the main principles of the processing model as described above. In this 389context, to interact means to exchange messages.

391 392 Figure 2.5.3-1, MUWS Basic Processing Model

394Management Using Web Services (MUWS) is a foundation for management of all IT resource 395domains. It accomplishes thisat goal by using Web services features and standards to provide a 396flexible, scalable, distributed, and collaborative management framework. An overview of the 397features of this framework is provided in Appendix EF, "Web Services Platform." Furthermore, 398itAppendix E also provides details about these Web service features., theand motivatingion 399factors behind for using them Web services features in MUWS, and provides a non-normative 400analysis of what standards or capabilities should be leveraged to support themthese features. 401MUWS leverages the Web Services Resources Framework ([WSRF]), in which, the MUWS 402manageable resources are represented by Web services as “resources”, (in the WSRF sense of 403the term). This implies that references to manageability endpoints in MUWS use the mechanism 404defined by WSRF, leveraging endpoint references (EPR) as defined by WS-Addressing. 405If the manageability endpoint corresponds to a variable number (zero or more) of manageable 406resources, then the WSRF Implied Resource Pattern MUST be followed. This means that the 407element(s) listed in the ReferenceProperties of a WS-Resource qualified EPR must be included in 408the header of messages sent to such manageability endpoints. This specification does not 409currently define how to obtain the EPR. There may be an out-of-band agreement between 410provider and consumer on how to obtain EPRs or future versions of this specification would clarify 411this subject. 412In the specific case where the a manageability endpoint corresponds to one and only one 413manageable resource, then, either the WSRF Implied Resource Pattern, (as above,) or the 414singleton WS-Resource implied pattern MUST be used. If the singleton WS-Resource implied 415pattern is used, this means that the manageability endpoint doesn't does not expect to receive the 416elements listed, indicating which resource is being managed, in the ReferenceProperties section 417of WS-Resource qualified EPRs in the message headers. to indicate which resource is being 418managed. A manageability consumer who does not have an EPR for a manageability endpoint 419MAY try to invoke manageability operations without including reference properties information. If 420this such an invocation succeeds, the manageability consumer knows that it is talking about a 421manageable resource through a manageability provider. 422Furthermore, management properties defined in MUWS are represented as “properties”, (in the 423WSRF sense of the term), using the mechanisms defined in WS-ResourceProperties ([WS- 424ResourceProperties]). This means that each manageable resource exposes a resource 425properties document and makes it this document available as specified in WS- 426WS-ResourceProperties. 427Supporting WS-ResourceProperties means that any implementation of an interface that includes 428properties MUST include access methods to these properties as defined by WS- 429WS-ResourceProperties. More sSpecifically, this means the interface MUST include the 430GetResourceProperty operation defined by WS-ResourceProperties and MAY include the 431GetMultipleProperties, SetResourceProperties and QueryResourceProperties operations. If the 432QueryResourceProperties operation is provided, it SHOULD support the XPath 1.0 query 433expression dialect, represented by URI http://www.w3.org/TR/1999/REC-xpath-19991116. 434For security, MUWS relies on generic Web services security mechanisms, including 435transport--level security and WSS SOAP Message SecuritySecurity as standardized by OASIS. 436MUWS 1.0 will include a more detailed “security considerations” section and will include 437corresponding supporting operations. 438Events are not supported in MUWS 0.5 but will be supported in MUWS 1.0. To do so, MUWS 1.0 439will leverage a Web services eventing mechanism. 37wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 38Copyright © OASIS Open 2003. All Rights Reserved. Page 13 of 40 39 4404 Manageability Capabilities

441There is a minimum set of manageability capabilities that the manageability provider must support 442in order to implement the MUWS specification. 443Manageability capabilities define resource specific properties, operations and events. Details of 444these manageability capabilities are exposed by the manageable resource. 445A manageable resource MAY also define new resource-specific manageability capabilities. 446A manageable resource SHOULD extend a MUWS manageability capability when defining a 447resource-specific manageability capability that uses similar semantics. A manageable resource is 448not required to extend a MUWS manageability capability when defining a resource-specific 449manageability capability that uses conflicting semantics. 450Each capability is formally expressed in a UML diagram using the following approach. Figure 4-1 451expresses that a ManageableXSampleCapabilityY is a concept X manageability capability, which 452is also a manageability capability in a general, conceptual, sense. The name of the capability 453identifies the distinct semantics that the capability bears. Semantics is are then expressed in as 454properties, operations, events and metadata contained in the capability model representation 455(UML class).

456 457 Figure 4-1 Manageability Capability UML Sample 458Properties and operations are expressed as regular UML properties and operations. The meaning 459of properties and operations is expressed in the text. Properties are defined with, and operations 460act upon, the information types that are captured by UML classes. SamplePropertyType1 is an 461example of such an information type. Simple information types may also be used directly when 462defining properties and operations. For example, xsd:int is an example of a simple information 463type that belongs to XML Schema Data Types UML package. 464For As a simplification, of the look of the UML diagrams this document uses a convention that all 465simple information types having a name which name starts from with xsd: belong to that package. 466XML Schema simple information types, or (data types) , are defined by the W3C specification at 467http://www.w3.org/TR/xmlschema-2/. 468Events are expressed as UML properties with an <> strereotype. Name The name of the 469property is the name of the event. The text describes why and when an event occurs and the 470specific information that is generated or (captured) when it the event occurs. The information type 471of an event is captured in a UML class which contains proper information element definitions. 472SampleEventInformationType1 is an example of an event information type.

40wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 41Copyright © OASIS Open 2003. All Rights Reserved. Page 14 of 40 42 473Optionality of properties and events is indicated by multiplicity of the corresponding model 474elements: [1] indicates that an element is mandatory, [0..1] indicates that an element is optional. 475For array properties, [0..*] indicates optional and [1..*] indicates mandatory. 476The metadata about various model elements is captured as UML constrains. For example, 477sampleReadOnlyProperty has an {ro} constraint. This document uses the following common 478constraints in the models. 479  ro – means read only, applicable to properties, 480  rw – means read/write, applicable to properties. 481  const – means constant, does not change during runtime, applicable to properties.

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

Prefix Namespace

muws-xs http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/schema muws-wsdl http://docs.oasis-open.org/wsdm/2004/04/muws-0.5/wsdl wsdl http://www.w3.org/2002/07/wsdl soap http://schemas.xmlsoap.org/wsdl/soap/ xs http://www.w3.org/2001/XMLSchema

485 Table 4-1 Manageability Capability Namespaces 486XML elements and schema types introduced in this section belong to the muws-xs namespace. 487WSDL elements introduced in this section belong to the muws-wsdl namespace.

4884.1 Identity

4894.1.1 Definition

490The goal of Identity is to establish whether two entities are the same. This is a required capability 491and it MUST therefore be provided by every manageability service.s (Observe that this 492requirement doesn’t does not preclude the manageability service to haveusing a security policy 493that preventsing some requester to from accessing this a capability). 494In addition, this interface is used as a “marker” interface to allow a consumer to know that the 495service that implements it is a manageability service. See section 2.5.2, “dDiscovery,” section for 496more additional information. 497Figure 4.1.1-1 shows the UML representation of MUWS Identity.

5014.1.2 Data Types

502This specification does not define any data type to represent Identity.

5034.1.3 Properties

504Following is the specification of the resource Identity properties (elements).

505 506 xsd:anyURI 507 xsd:string? 508 xsd:string?

509 510Following is an example excerpt from a resource properties instance document that contains 511these properties. 512 http://example.com/resource/diskDrive/9F34AD35B 513 The disk drive in Bob’s laptop 514 1.0

515 516ResourceId is an opaque identifier of the resource managed through the manageability endpoint. 517It is a read-only mandatory property that has a cardinality of 1. 518The following constraints are applicable to ResourceId: 519  Globally unique: A manageability endpoint MUST create the ResourceId URI in a way 520 that ensures that the ResourceId is unique to the resource managed through the 521 manageability endpoint and globally unique.. This specification does not prescribe the 522 means by which global uniqueness is achieved. 523  Uniqueness in time: A given ResourceId MUST NOT be reused by any manageability 524 endpoint for another resource, even after the original resource no longer exists.it was 525 attached to has stopped existing. 526  Consistency across endpoints: A manageability provider SHOULD use the ResourceId 527 that is suggested by the characteristics of the resource to identify the resource. The 528 cases where Tthis is possible include when the ResourceId can be retrieved from the 529 resource by the manageability endpoint or when an application of MUWS to a given 530 domain specifies a method to build the ResourceId based on characteristics of the 46wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 47Copyright © OASIS Open 2003. All Rights Reserved. Page 16 of 40 48 531 resources within theat domain. It is not guaranteed that different manageability endpoints 532 attached to the same resource will, in all cases. return the same ResourceId in all cases 533  Consistency within an endpoint: A manageability provider that exposes several 534 manageability endpoints for the same resource SHOULD use the same ResourceId for 535 all the manageability endpoints. 536  Persistence: A manageability endpoint SHOULD return the same ResourceId during the 537 entire lifetime of the manageability endpoint, including across power cycles of the 538 manageability endpoint. Resources which are not able to persist the ResourceId across 539 power cycles of the manageability endpoint should SHOULD try to provide a consistent 540 ResourceId via predictable identifier generation or delegation of Identity assignment. 541 Managers may not be able to determine that if a resources which does cannot return 542 provide the same ResourceId are the same resource and the a single resource may be 543 treated as many resources. 544  Equality: If the ResourceIds are equal then the consumer MUST assume that the two 545 manageability endpoints represent the same resource. However, a manageability 546 consumer MUST NOT assume that two manageability endpoints are representing two 547 different resources solely because the ResourceId is different. Two different ID’s could 548 conceivably reference the same resource. It is strongly recommended that this condition 549 be deliberately avoided in a conscious and deliberate manner, as some managers may 550 not be able to ascertain distinguish that the two identifiers are, in fact, for attached to the 551 same resource. and Thus, the managers may would be forced to treat every identifier as 552 an attachment to an unique resource. 553 Since the ResourceId is defined as opaque, this specification does not allow the consumer to 554 infer any characteristic of the resource by examining the ResourceId, other than comparing 555 the ResourceId to another ResourceId as one way to establish oneness. For example, one 556 possible way to construct the ResourceId and ensure its uniqueness is to use a UUID 557 wrapped in a URI. 558Note that this specification does not define equivalence of URIs and the consumer should decide 559which level of the comparison ladder defined in section 6 of [RFC2396bis] is appropriate to use 560for this comparison. 561The following paragraph is a describesption of a mechanism, intended to be introduced in MUWS 5621.0, called “correlatable names”. Thise mechanism is not available in MUWS 0.5. 563The correlatable names mechanism is one of several possible mechanisms that can be used to 564solve the case wherewhen the ResourceId mechanism cannot provide certainty about the 565oneness of two resources. but not necessarily the only such mechanism. The correlate 566management capability can be used by the a resource manager to discern determine whether 567theif two different resouceIds, produced at different times, by the same manageability provider for 568the one an endpoint, represents the same endpoint. 569The basic idea is to provide a list of properties that, if all are equal between two manageability 570endpoints, guarantees that the resource(s) behind the manageability endpoints are one. In the 571case where two ResourceIds match but the correlatable names doesn’t do not, a (this case that is 572not allowed, but can’t can not be guaranteed that it will never to happen), the resource is 573considered to be the same. This is because the ResourceId has the precedence over the 574correlatable name. 575Name is a string containing a descriptive name for the resource being managed. The Name is 576intended for human consumption. It is a read-write optional property that has a cardinality of 0..1. 577Version is a string representing the version of the resource being managed. MUWS doesn’t does 578not specify how this string is constructed. This The version string can be specified by any domain-

49wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 50Copyright © OASIS Open 2003. All Rights Reserved. Page 17 of 40 51 579specific specifications that use MUWS. It Version is a read-write optional property that haswith a 580cardinality of 0..1.

5814.2 State

5824.2.1 Definition

583The goal of this section is to define a state model for any IT resource and state management 584capabilities through Web services. The state model must MUST support the state change 585capabilities and the events for lifecycle and/or status changes. Additionally, the state model must 586MUST be extensible. 587Figure 4.2.1-1 shows the resource state model without any sub-states.

588 589 Figure 4.2.1-1 Resource State Model 590Figure 4.2.1-2 shows the UML representation of MUWS State.

591 592 Figure 4.2.1-2 MUWS State

5934.2.2 Description of State Model

594The following are the identifiers of the valid top-level resource states.

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

52wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 53Copyright © OASIS Open 2003. All Rights Reserved. Page 18 of 40 54 597This corresponds to the Available state in the UML diagram. In this state, the resource is able to 598perform all functional tasks it is designed to perform.

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

603 604http://docs.oasis-open.org/wsdm/2004/04/muws/state/unavailable 605This corresponds to the Unavailable state in the UML diagram. In this state, the resource is not 606able to perform any of the functional tasks it is designed to perform. 607 608The states defined by this specification are intended to be generic states that are relevant for any 609type of resource. Implementers SHOULD reuse existing states if they are appropriate for their 610resources. Implementers are sole judges in deciding what states are appropriate and it is 611expected that new states will be defined (and therefore new URIs created to represent them), for 612example if the existing states do not cover the intended meaning or if the existing states are too 613general and the implementer wishes to expose a more specific state description. Just like they 614MAY create new states, implementers MAY create new transitions between any two states (the 615two states don't need to have been defined by the same people). Note that until MUWS defines a 616way to represent the state model for a resource, "creating a new transition" just means writing 617some text to explain that a resource's state can change from one state to another. Finally, it is 618expected that MUWS 1.0 will define a way for states to be defined as sub-states of another state, 619at which point the specification will have specifications and recommendations on using this 620mechanism. 621The following table lists the valid transitions between the top-level resource states.

622 Start State End State Available Degraded Available Unavailable Degraded Available Degraded Unavailable Unavailable Available

6244.2.3 Data Types

625Following is the schema fragment that declares the (reusable) data types used to manage the 626resource state.

627 628 629 630 631 632 633

55wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 56Copyright © OASIS Open 2003. All Rights Reserved. Page 19 of 40 57 634 635(StateInformation) type contains information about a resource state. 636(StateInformation)/State is an identifier of a resource state. 637(StateInformation)/TimeEntered is time at which the resource entered the identified state.

6384.2.4 Properties

639Following is the specification of the resource state properties (elements).

640 641 StateInformation 642Following is an example excerpt from a resource properties instance document that contains this 643property. 644 645 646 http://docs.oasis-open.org/wsdm/2004/04/muws/state/available 647 648 2004-03-11T11:30:56Z 649

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

6544.2.5 Operations

655Following are the definitions of the messages that can be exchanged to perform operations on 656the resource state.

6574.2.5.1 Start

658Request: 659

660 661Reply: 662

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

6684.2.5.2 Stop

669Request:

671 672Reply: 673

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

6804.3 Metrics

6814.3.1 Definition

682Metrics are a specific type of property. Metrics represent collected values and have a related 683collection period. 684The goal of this section is to describe the characteristics of a typical property used to represent 685collected numerical, called Metrics. A common characteristic of metrics is that they change 686overtime and can be reset. 687Figure 4.3.1-1 presents the Metrics capability in context.

689 690 Figure 4.3.1-1 MUWS Metrics 691As a simple example, consider a toll bridge and two properties; the length of the bridge and the 692number of cars that have passed over the bridge. The length of the bridge, while numeric, is not a 693metric; it represents the current configuration of the bridge. You can not reset the length of the 694bridge. By contrast, the number of cars that have passed over the bridge is a metric. It requires 695collection (counting) the number of cars, which is typically done over some duration, such as the 696last hour, the last day or even since the bridge was constructed. You can reset the number of 697cars, for example at the start of a new interval. 698When accessing metrics, the time represented by the metric is typically required. In the example, 699above would be useful to know that a number of 500 represented the number of cars that have 700passed over the bridge in the last 3 minutes. Similarly, if data is posted periodically, there are

61wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 62Copyright © OASIS Open 2003. All Rights Reserved. Page 21 of 40 63 701cases when it is useful to know the last time the data was updated. For this reason, the standard 702data type for Metrics allows for both reset time and updated time attributes. However, both are 703optional. 704When looking at a value, it is important to have a notion of how changes to that metric are to be 705interpreted. That notion is defined as a change type. Metrics have two (2) change types: 706  Counter, increments with usage 707  Gauge, moves between a range of values 708Metrics can be reset either periodically, such as 'once a day', or on demand. The meaning of 709resetting a metric varies with each metric and should be clarified, if needed, in the description of a 710metric. Often, resetting a metric means setting its base or initial value, which is typically zero, but 711this is not mandatory. (Note that this specification provides no specific means for the scheduling 712of reset operations.)

7134.3.2 Data Types

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

716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738

739 740(MetricAttributes) attribute group has to be included in every metric type or metric property 741element declaration. 742(MetricAttributes)/ResetAt indicates time when a particular metric has been reset. UTC or Z- 743coded! 744(MetricAttributes)/LastUpdated indicates time when a particular metric value was last updated. 745(MetricAttributes)/ChangeType indicates a type of change pattern supported by a particular 746metric. 747 . Counter declares an incrementally increasing metric value. 748 . Gauge declares a metric value that can increase and decrease. 64wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 65Copyright © OASIS Open 2003. All Rights Reserved. Page 22 of 40 66 749(MetricAttributes)/TimeScope indicates a time interval which is used to calculate a particular 750metric. 751 . Interval declares that a metric value is calculated within a certain time interval. Usually 752 the interval would be defined by the metric property specification. For example, a 753 RequestsPerSecond is an interval metric. 754 . PointInTime declares that a metric value is calculated for the moment of retrieving a 755 metric property. For example, CurrentTemperature is a point-in-time metric. 756 . SinceReset declares that a metric value is calculated since ResetAt time mark. 757The following three types are defined for metrics that are integers, durations or times. 758Specifications that use MUWS to create manageability properties applicable to specific domains 759are free to use these types or to create new metric types by including the MetricAttributes 760attribute group in their types. 761 762 763 764 765 767 768 769

770 771(IntegerMetric) type declares an xsd:integer metric.

772 773 774 775 776 777 779 780 781 782 783 784(DurationMetric) type declares an xs:duration metric.

7854.3.3 Properties

786Following is the specification of the resource metrics properties (elements).

787 788 xs:dateTime

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

792 793 2004-03-11T11:30:56Z

67wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 68Copyright © OASIS Open 2003. All Rights Reserved. Page 23 of 40 69 794 795CurrentTime contains information about the current time at the manageability provider (current at 796the moment of retrieving this property). This property is meant to help manageability consumers 797interpret times received from the manageability endpoint in the absence of a time synchronization 798mechanism. It is a read-only mandatory property that has a cardinality of 1. 799The Metrics capability requires that the CurrentTime property be present, providing a reference 800point for the time-based attributes defined for the metric data types. (Note that CurrentTime is not 801a metric, it is a property of type xsd:dateTime that is defined as part of the “Metrics” capability, 802consequently, the ResetAll() operation has no effect on it.)

8034.3.4 Operations

804Following are the definitions of the messages that can be exchanged to perform operations on 805the resource metrics.

8064.3.4.1 ResetAll

807Request: 808 809 810Reply: 811 812 813Upon receiving a request for a ResetAll operation, manageability provider resets values of all 814metrics that it is collecting. Metrics may be grouped into logical groups that can be reset 815individually through some other mechanisms. However, this action indicates that all metrics be 816reset. A manageability consumer MUST NOT assume that different metrics are reset at the same 817time, even if they are provided by the same manageability endpoint.

819Many forms of discovery are supported by Web services. This specification does not normatively 820prescribe specific ways of discovering manageability services. It is expected that the discovery 821methods commonly used for Web services will be used for manageability Web services. 822The only normative requirement in this specification that applies to discovery is the need for a 823manageability service to provide the Identity capability, through the corresponding WSDL 824interface defined by this specification. As a result, when a consumer discovers a WSDL 825description for a Web service (through any discovery mean), it is able to determine whether or not 826the service acts as a manageability service by checking whether the service implements the 827Identity interface defined by MUWS.

829The following are normative statements for MUWS representation. 830  WSDL 1.1 must be used. 831  Additionally, WSDM defines portTypes which have to be manually put together into a 832 custom portType operation by operation according to the WSDL specification. 833  Document/literal binding must be used. 834  WSDM defines property elements which have to be manually put together into a custom 835 properties document according to WS-ResourceProperties specification

8387.1 Normative 839 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 840 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 841 842 [XML Schema Part 1] 843 Henry S. Thompson, et al. XML Schema Part 1: Structures, W3C 844 Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/ 845 846 [XML Schema Part 2] 847 Paul V. Biron, et al. XML Schema Part 2: Datatypes, W3C 848 Recommendation, May 2001, http://www.w3.org/TR/xmlschema-2/ 849 850 [XML1.0 3rd Edition] 851 Tim Bray, et al., Extensible Markup Language (XML) 1.0 (Third Edition), 852 W3C Recommendation, February 2004, http://www.w3.org/TR/REC-xml 853 854 [XNS] Tim Bray, et al., Extensible Namespaces in XML, W3C 855 Recommendation, January 1999, http://www.w3.org/TR/REC-xml- 856 names/ 857 858 [SOAP1.1] Don Box, et al., Simple Object Access Protocol (SOAP) 1.1, W3CNote, 859 May 2000, http://www.w3.org/TR/soap11/ 860 861 [WSDL1.1] Erik Christensen, et al., Web services Description Language (WSDL) 1.1, 862 W3C Note, March 2001, http://www.w3.org/TR/wsdl 863 864 [UDDI] Tom Bellwood, et al., Web UDDI Version 3.0, UDDI Spec Technical 865 Committee Specification, July 2003, http://uddi.org/pubs/uddi-v3.00- 866 published-20020719.htm 867 868 [WSA] David Booth, et al. Web Servics Architecture, W3C Working Group Note, 869 February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ 870 871 [WSRF] Karl Czajkowski, et al. The WS-Resource Framework version 1.0, 872 http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-1- 873 0.pdf and related documents available at 874 http://devresource.hp.com/drc/specifications/wsrf/index.jsp 875 876 [WS-ResourceProperties]

79wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 80Copyright © OASIS Open 2003. All Rights Reserved. Page 27 of 40 81 877 Steve Graham, et al., Web service Resource Properties version 1.1, 878 January 2004, http://devresource.hp.com/drc/specifications/wsrf/WS- 879 ResourceProperties-1-1.pdf 880 881 [WS-Addressing] Don Box, et al., Web services Addressing, March 2003, 882 http://msdn.microsoft.com/library/default.asp?url=/library/en- 883 us/dnglobspec/html/ws-addressing.asp 884 885

8867.2 Non-normative 887 [RFC2396bis] T. Berners-Lee, et al., Uniform Resource Identifier (URI): Generic 888 Syntax, IETF RFC 2396bis-04, February 2004, 889 http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-04.txt 890 891 [MUWS REQS] Pankaj Kumar, et al., Requirements – Management Using Web Services, 892 Committee Draft, October 2003, http://www.oasis- 893 open.org/apps/org/workgroup/wsdm/download.php/6185/WSDM-MUWS- 894 Req-committee-draft-1.0-20031002.pdf 895

897The following people made contributions to this specification: 898 Winston Bumpus 899 Brian Carol 900 Fred Carter 901 John DeCarlo 902 Andreas Dharmawan 903 Mark Ellison 904 Heather Kreger 905 Hal Lockhart 906 Bryan Murray 907 Richard Nikula 908 Micheal Perks 909 Homayoun Pourheidari 910 Karl Schopmeyer 911 Igor Sedukhin 912 Ellen Stokes 913 William Vambenepe 914 Andrea Westerinen

915 916The following individuals were voting members of the committee during the development of this 917specification: 918 Guru Bhat 919 Jeff Bohren 920 Winston Bumpus 921 Fred Carter 922 John DeCarlo 923 Andreas Dharmawan 924 Mark Ellison 925 Daniel Foody 926 Heather Kreger

85wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 86Copyright © OASIS Open 2003. All Rights Reserved. Page 29 of 40 87 927 Bryan Murray 928 Paul Lipton 929 Hal Lockhart 930 Rajiv Maheshwari 931 Richard Nikula 932 Michael Perks 933 Homayoun Pourheidari 934 Karl Schopmeyer 935 Igor Sedukhin 936 Davanum Srinivas 937 Ellen Stokes 938 Thomas Studwell 939 Ryoichi Ueda 940 William Vambenepe 941 Andrea Westerinen

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

946OASIS takes no position regarding the validity or scope of any intellectual property or other rights 947that might be claimed to pertain to the implementation or use of the technology described in this 948document or the extent to which any license under such rights might or might not be available; 949neither does it represent that it has made any effort to identify any such rights. Information on 950OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 951website. Copies of claims of rights made available for publication and any assurances of licenses 952to be made available, or the result of an attempt made to obtain a general license or permission 953for the use of such proprietary rights by implementors or users of this specification, can be 954obtained from the OASIS Executive Director. 955OASIS invites any interested party to bring to its attention any copyrights, patents or patent 956applications, or other proprietary rights which may cover technology that may be required to 957implement this specification. Please address the information to the OASIS Executive Director. 958Copyright © OASIS Open 2003. All Rights Reserved. 959This document and translations of it may be copied and furnished to others, and derivative works 960that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 961published and distributed, in whole or in part, without restriction of any kind, provided that the 962above copyright notice and this paragraph are included on all such copies and derivative works. 963However, this document itself does not be modified in any way, such as by removing the 964copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 965specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 966Property Rights document must be followed, or as required to translate it into languages other 967than English. 968The limited permissions granted above are perpetual and will not be revoked by OASIS or its 969successors or assigns. 970This document and the information contained herein is provided on an “AS IS” basis and OASIS 971DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 972ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 973ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 974PARTICULAR PURPOSE.

975 976 977 978 979

91wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 92Copyright © OASIS Open 2003. All Rights Reserved. Page 31 of 40 93 980Appendix C. Schemas (Normative) 981 982 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032

94wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 95Copyright © OASIS Open 2003. All Rights Reserved. Page 32 of 40 96 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1054 1055 1056 1057 1058 1059 1060 1061 1062 1064 1065 1066 1067 1068 1069 1070 1071 1072 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083

97wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 98Copyright © OASIS Open 2003. All Rights Reserved. Page 33 of 40 99 1084Appendix D. WSDL elements (Normative) 1085 1086 1093 1094 1095 1097 1098 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1130 1131 1133 1134 1135 1136

103wd-wsdm-muws-05 Created on 4/1/2004 3:48 AM 104Copyright © OASIS Open 2003. All Rights Reserved. Page 35 of 40 105 1153Appendix E. Web Services Platform 1154This section briefly describes the Web services platform features that are required in order to 1155specify management using Web services and recommendations for how to support each feature. 1156Recommendations will either reference another specification to be used to provide the feature, 1157identify the feature to be provided by the industry in the future, or identify the feature that the 1158WSDM TC must define in an interim specification until one is available for the Web services 1159platform.

1160 Initial Focus

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

1163 Properties

1164Properties are describable information that can be queried and may be written. Properties may be 1165provided by a Web service interface with a schema (data type and name) of the properties and 1166operations (message exchanges) to find, read and write them. Property declarations (names) and 1167descriptions (types) should be introspect-able at design time and at runtime. For manageability, a 1168property is part of the advertised manageability interface for a resource. A property can be used 1169to represent configuration values, metrics, identifiers, etc. 1170Motivation: Many manageability capabilities of a manageable resource take the form of 1171information about the resource that the manager is able to query and set. Such information 1172should be modeled as a set of properties with access methods that allow access to it in ways that 1173meet the scalability requirements of management applications, e.g. bulk get. 1174Recommendation: Use the WS-Resource Properties specification [WS-ResouceProperty] to 1175describe the properties of a manageable resource.

1176 Meta Data

1177Meta data is generally defined as data about data. In the context of management, it is additional 1178descriptive information about all the components of a manageability interface, including 1179properties, operations, events, capabilities, the context, quality and condition, or characteristics of 1180the data. Meta data can be introspected at design time and runtime. 1181Motivation: In IT management, meta data is important to a) describe data in richer ways so that it 1182can ultimately be linked to the goals that drive the existence of the source of this data, e.g. 1183limitations, purpose, context, quality, and characteristics of management data as an associated 1184piece of that data will help to describe how the data is related to the objectives of an IT 1185environment. b) meta data can be used to enable interoperability of manageability capabilities 1186provided by a number of different providers 1187Recommendation: Descriptive information about the manageability interface will be expressed 1188as XML element attributes as a tactical solution for WSDM 0.5. This satisfies runtime 1189introspection, but does not provide design time introspection. 1190A strategic solution will be developed for WSDM 1.0 which supports runtime and design time 1191introspection. The Distributed Management Task Force's Common Information Model (CIM) 1192qualifiers (meta-data concerning a class, property, method, notification or method parameter) 1193may be mined for useful information for manageability meta-data.

1195An address or reference is the data structure used to refer to a unique Web service. Addressing 1196may be used to refer to Web services for a manageability provider as well as a manageable 1197resource. The data structure must have sufficient information for a manageability consumer to be 1198able to locate the Web service and send messages to the Web service. In the case the 1199referenced Web service provides manageability for several resources, it is also necessary to 1200uniquely identify a specific resource in the reference data structure. The reference data structure 1201must include the ability to locate the description of the Web service in order for the manageability 1202consumer to identify the messages understood by the Web service. In this context, address and 1203reference are used synonymously. 1204Motivation: Management needs interoperable addressing in order to refer to common 1205manageability services and manageable resources for relationships, notifications, and as part of 1206messages exchanged. 1207Recommendation: Use the WS-Addressing specification 1208(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws- 1209addressing.asp).

1210 Notification

1211Notification is a method of conveying information from a source to recipients that expressed 1212interest in that information. In terms of Web services it means delivering an XML message from 1213the source to addressable recipients. An interest in receiving those messages must be 1214established by the recipients, or by third parties on behalf of the recipients. When registering 1215interest, address(es) of recipient(s) must be provided (see Addressing). 1216Motivation: Manageable resources need to convey information to the managers. In certain 1217cases, it is unreasonable for the manager to explicitly poll (request) the information, and it has to 1218be sent to the manager by the manageable resource. For example, a manager may be interested 1219when a service receives a new message. The manageable resource for the service has to notify 1220the manager when it happens (event). The manageable resource needs to know which managers 1221are interested in which information and what are the deliverable addresses of the managers to 1222send the notification message when an event occurs. 1223Recommendation: Use the WS-Notifications specification [WS-Notification].

1224 Versioning

1225Version is an attribute of a resource identifying a set of supported capabilities and a sequence of 1226modifications to the component. There are two kinds of versioning; the resource version and the 1227Web service version. The format of the former is out of scope of this work. Version information is 1228useful so that the manager can know if the manageable Web Service interfaces have changed 1229since she obtained her copy. 1230Motivation: A manager of manageable resources must have the ability to query the available 1231endpoints’ revisions along with the corresponding change descriptions such that the manager can 1232discern the most appropriate and compatible interface of a particular manageability function that 1233her management client can use. 1234Recommendation: Addressed by WSDM as part of the “Management of Web Services” 1235specification development for a Web service, taking into account W3C recommendations on this 1236topic [W3C TAG finding on Versioning]. “Management Using Web Services” must provide access 1237to version information as part of description of identity of manageable resources.

1239There are many ways to categorize information security, but the most common today are 1240Confidentiality, Integrity, and Authentication. Additional concepts that can be arguably kept 1241separate are: Access Control, Non-repudiation, Availability, and Privacy. [see Glossary] Security 1242requirements within manageability are not unique to manageability. Every manageability endpoint 1243and many business endpoints will have requirements for confidentiality, integrity, and 1244authentication, as well as access control, availability, and privacy (see the definition of Security). 1245Motivation: Resources have to be manageable in a secure way (see definition of security). 1246Security infrastructure mechanisms should be composed and layered on top of the manageability 1247exposed via Web services, similar to securing any other capability of a resource exposed via a 1248Web service. For example, access to a manageability operation can be granted to only clients 1249that present “manager’s identity” in a request message. 1250Recommendation: WSDM will follow the recommendation of the OASIS WS-Security TC. 1251WSDM 1.0 should examine WS-Security to ensure nothing done in the specification precludes 1252the composability of Security. In addition, security should be manageable via Web services.

1253 Registration and Discovery

1254Registration is a method of advertising an existence of an element so that it can be discovered. 1255Discovery is a method of locating an existing element so that it can be used or operated. 1256Discovery can be based on selection criteria or simply a name or identity of an element. Location 1257is a method of obtaining an address of an element. In the Web services sense, registration, 1258discovery and location can be represented by a set of operations and schema which may be 1259implemented by a Registry. 1260Motivation: Manageable resources have to be discoverable by the managers. Manageable 1261resources exposed via Web services can be registered, discovered and located via a Registry. 1262Recommendation: UDDI specification will satisfy most requirements. Existing Web services 1263discovery practices are sufficient.

1264 Future Focus

1265For future versions of WSDM may also require the following support from the Web services 1266platform.

1267 Policy

1268A Policy is a course of action, guiding principle, or procedure considered expedient, prudent, or 1269advantageous for a given condition or event. It describes a broad range of service requirements, 1270preferences, and capabilities. There are two kinds of policy that governs management of 1271manageable resources: a) a set of policy that describes how the client of a manageable resource 1272interacts with the functional interfaces of the resource (e.g. policy describing the privacy of data), 1273b) a set of policy that describes how the manager of a manageable resource places operational 1274requirements on to the resource, e.g. service level agreements. 1275Motivation: There are various policies that can be specified to manageable resources including: 1276authentication, access control, privacy, non-repudiation, service level agreement, quality of 1277service, routing, content inspection, and auditing, etc. policies. MUWS must leverage as much as 1278existing Webservices specifications and technologies in applying policies to the manageable 1279resources. MUWS should endorse a list of such specifications and technologies, and should 1280specify the compatibility and interoperability requirements.

1282 Name Resolution

1283For management purposes: A service which accepts a name identifier (URI) of a resource and 1284returns an address or reference for the manageability endpoint for the resource. The service 1285should return sufficient information such that the manageability endpoint can be invoked. The 1286name resolution service may be used to resolve names to references in other application 1287domains unrelated to management as well, i.e. service discovery, etc. 1288Motivation: A name resolution service is necessary for management because resources and 1289manageability services have identifiers (from existing instrumentation and technologies) and it will 1290be necessary to be able to get a reference for that resource identifier so that the manager can 1291interact with a resource through its manageability interface. 1292Recommendation: None at this time.

1293 Transaction

1294A “unit of work” that consists of multiple actions (typically, an ordered set) invoked against a 1295single resource, the same action applied to multiple resources, or multiple actions against 1296multiple resources. The “unit of work” should be executed once and only once, even if due to 1297transmission failures or other errors, the request may be received multiple times. One of three 1298outcomes will result from the execution of a transaction: a) all actions against all resources may 1299succeed, b) one or more actions may fail and all actions against all resources are rolled back 1300(if roll back is not possible or not supported, then the resources should be reconfigured to an 1301operational, state of compensation), or c) one or more actions may fail and the resources are left 1302as affected by the actions 1303Motivation: Grouping actions against resources and assuring their execution is very valuable. A 1304manager may request that multiple actions/operations be performed as a single “unit”, and that 1305the integrity of the complete/combined request be preserved. 1306 Recommendation: None at this time.

1307 Flow

1308Flow, more often called workflow or workflow management, is the management of business 1309processes with information technology. By defining, analyzing, and organizing an organization’s 1310resources and operations, workflow management systems ensure that the right information 1311reaches the right person or computer application at the right time. Business process management 1312(BPM) workflow or execution languages support composing services into more complex 1313processes and may expose itself as a Web service. Such coordination description includes, but 1314may not be limited to, constructs for the identification of partners, message correlation, fault 1315detection and compensating activities, parallel and serial execution of services, and so on. 1316Motivation: Web services orchestration languages may be useful tools allowing Web services 1317management providers to enable more complex and meaningful actions to be taken as a result of 1318observations. A manageability interface may need to be defined for a business process engine to 1319properly and consistently monitor and control flows and composite Web services which might 1320expose the sessions and state of a process, subordinate resources, etc. 1321Recommendation: None at this time.

1323Negotiation is the process by which two services dynamically negotiate terms of a contract 1324between initiators and participants of that contract. A contract is a document that represents a 1325set of objectives and resources. 1326Motivation: It is important for resources to understand what they can expect from the other 1327resources both between managed resources, management services, and managers. This 1328enables them to better describe their own level of performance, as well as how information is 1329exchanged between the components of federated deployments. 1330Recommendation: None at this time. 1331