Computer system for accessing instrumentation information (09-Mar-2010)

RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. provisional patent application having an application Ser. No. 60/537,637, filed Jan. 20, 2004, and entitled SYSTEM PROTOCOL FOR USING URI FOR COMPUTER MANAGEMENT, the entire contents of which is expressly incorporated herein by reference.

FIELD OF THE INVENTION

This application is directed to computer communication protocols, and more particularly, to computer communication protocols for managing resource instrumentation.

BACKGROUND OF THE INVENTION

Distributed and networked computer systems typically comprise a variety of types and sizes of components such as routers, gateways, servers, databases, personal computers, and the like. Each component may include a variety of resources including hardware and software resources such as disk drives, fans, memory allocation, and the like. To manage and maintain the effective use of these components, a systems administrator may monitor the health and other computer system management information of the resource, and modify that information if necessary or otherwise take corrective action. To monitor the system information, the systems administrator may communicate with the desired resource either receiving broadcast messages of status and health information and/or requesting specific information from a defined port. The format of the messages containing the health and/or status information may be controlled by one of several standard protocols which define the format of messages presenting status information from certain devices. For example, Simple Network Management Protocol (SNMP) is a Transmission Control Protocol/Internet Protocol (TCP/IP) standard that is used to manage and control IP gateways and the networks to which they are attached. In another example, SYSLOG is a distributed interface standard for logging short text messages regarding systems health information which are communicated to clients with User Datagram Protocol (UDP) datagrams. In yet anther example, Intelligent Platform Management Interface (IPMI) is a remote management control protocol (RMCP) for request/reply and uses SNMP for events/traps. IPMI is further IPMI data and SNMP data can be mapped into the common information model/Web-based enterprise management (CIM/WBEM)-based standards for retrieving and describing management data over HTTP. In another example, Web Services Distributed Management (WSDM) is a management standard directed toward Web-services.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an exhaustive or limiting overview of the disclosure. The summary is not provided to identify key and, or critical elements of the invention, delineate the scope of the invention, or limit the scope of the invention in any way. Its sole purpose is to present some of the concepts disclosed in a simplified form, as an introduction to the more detailed description that is presented later.

To maintain and manage a computer network, a system administrator may monitor a large number and variety of components, each component comprising a variety of resources. Generally, each resource may implement a different standard protocol and/or require a different transport. For example, some server components may accept and generate messages compliant with IPMI, and other components may accept and generate messages compliant with SNMP. Moreover, the messages to and from different resources may be required to be sent over different transports. For example, some messages may require a Hypertext Transfer Protocol (HTTP) transport and other messages from other resources may require a different transport. In this manner, monitoring and maintaining a large and/or heterogeneous computer network may be difficult.

To support various transports for health and/or status information messages, a systems administrator may implement a common message protocol wrapped in a Simple Object Access Protocol (SOAP) envelope. In one example, a client manager may request access to instrumentation information of a particular resource. Accordingly, the client manager may generate a SOAP request message including a resource identifier such as a URI, and an operation identifier indicating the desired operation on the resource, e.g., retrieve desired instrumentation information, change instrumentation/configuration, perform an action on the resource, and the like. The client manager may send the SOAP request to a resource agent associated with the indicated resource. The resource agent may resolve the resource identifier into an address of a local handler, such as an API, of the resource. The resource agent may retrieve the requested instrumentation information or execute the action on the resource through the local handler. The resource agent may then return the instrumentation information, verification of a successful operation, and/or fault message to the client manager, which may be in the form of a SOAP response message.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is an example functional diagram of a management system in accordance with one embodiment;

FIG. 2 is a flow chart of an example method of requesting and receiving resource instrumentation information of FIG. 1;

FIG. 3 is an example request message of FIG. 1;

FIG. 4 is an example response message of FIG. 1; and

FIG. 5 is an example schematic diagram of an example computer system in one embodiment.

DETAILED DESCRIPTION

Various types and sizes of both hardware and software resources may exist in a computer system network. Examples of hardware resources may include network devices, computing devices, and peripheral devices. Example network devices may include routers, gateways, bridges and the like. Example computing devices may include among others, personal computers, workstations, mini-computers, mainframes, and small form devices like palm devices and cellular telephones. Example peripheral devices may include printers, hard disk controllers, magnetic tape drives, plotters, and the like. Software resources may include compilers, editors, debuggers, typesetters, and services such as security services, name services, management services, transaction services, and time services.

Instrumentation is a technique whereby a developer can surface or expose information that is consumable by the administrator and managing a resource. When the resource has been instrumented, objects and events can be discovered, monitored, and configured from diverse data sources. The resource providing the information might be a piece of hardware, operating system, or software application. The information provided by the data source is known as instrumentation. The purpose of instrumentation is very similar to the purpose served by the instrument panel of a car dashboard. Car instrumentation includes gauges, lights and indicators that allow for monitoring information about various resources (such as the fuel gauge) when various events occur (such as the open door alarm). All this instrumentation allows decisions to be made on how the car is driven and maintained. Computer system resources that provide instrumentation may allow management software to diagnose and correct problems in an enterprise computing environment.

As noted above, the various resources of a network may utilize different instrumentation message protocols and/or transport protocols, and may not be compatible with each other. To support various transports for instrumentation information messages, a systems administrator may ‘wrap’ the message in a Simple Object Access Protocol (SOAP) envelope. SOAP is an Extensible Markup (XML) based protocol used to send messages for invoking methods in a distributed environment. SOAP is described in Gudgin, et al., “SOAP 1.2,” W3C Recommendation, Jun. 24, 2003, which is available on the Internet at http://www.w3.org/TR/soap12-part1/ and http://www.w3.org/TR/soap12 -part2/, which is incorporated herein by reference Generally, SOAP is a communication protocol for communication between applications via the Internet.

A SOAP message generally comprises a SOAP envelope element, a SOAP body element, and an optional SOAP header element. The SOAP envelope defines the XML document as a SOAP message with a SOAP envelope element of <soap:Envelope xmls:soap=http://www.w3.org/2001/12/soap-envelope . . . </soap:Envelope>. The SOAP body element contains the actual SOAP message intended for the ultimate endpoint of the message, e.g., the addressee of the message. The SOAP body is delimited by a body element of <soap:Body> . . . </soap:Body>. Generally, the contents of the body element of the SOAP message may be application specific and not part of the SOAP standard. The SOAP header element may contain application specific information, such as authentication, payment, and the like about the SOAP message, with the headers defined by the namespaces listed within the SOAP envelope.

Since SOAP is platform independent, language independent, and transport independent, a SOAP message may be used to encapsulate a request for instrumentation information from any resource. An example of a management system 10 for receiving and sending SOAP instrumentation information messages is shown in FIG. 1. The management system 10 may include a client manager 12 connected to a resource agent 16 through a connection 14. The resource agent 16 communicates with the resource 18 through a local handler 22, such as an application program interface (API) and the like, and may access a catalog data store 20.

Each resource agent 16 may communicate with multiple local handlers 22 to access multiple resources 18 resident on a single component. Accordingly, a system with one or more components may be managed by one or more client managers 12 through one or more resource agents 16, with each resource agent 16 accessing one or more local handlers 22, each local handler being associated with one or more resources 18, as shown in FIG. 1. In one example different resource agents may be associated with different resources, although the resources all reside on a single component, e.g., are hosted by a single server. In this manner, the different resource agents may compartmentalize access to resources on a single component by giving some client managers access to some of the resource agents, and not to other resource agents which may effectively segregate access of resources by different client managers. Alternatively, access to resources may be controlled by verifying access privileges which may be stored in a data store, such as the catalog data store.

The client manager 12 may be provided by any suitable process such as a dedicated application, an automated service, a script, an interactive shell, or any other suitable process. In practice, the client-manager may provide a language-specific library which wraps the SOAP message and/or resource agent access in a simple interface. The resource agent may be provided by any suitable process such as a dedicated application, an automated service, a script, an interactive shell, or any other suitable process. It is to be appreciated that the resource agent may not require a supporting operating system, and may be, for example, supported by a BIOS of a small form device. For example, the baseboard management controller (BMC) may expose resources that allow a management client to monitor and manage the hardware. The resource agent implementation, such as on the server side, may have some type of standardized plug-in or “provider” model for associating resource identifiers, such as URI values, with the appropriate local handlers. This makes the addition of new handlers a matter of implementing the plug-in model for the particular platform.

Although the client manager 12 may be supported by the same component or system as the resource agent, FIG. 1 illustrates that the client manager 12 may remotely access a resource agent 16 through a connection 14 which may be any suitable connection, such as the Internet, Wide Area Network (WAN) or Local Area Network (LAN). The connection may be regulated by any suitable transport protocol. Although the following examples are described with reference to a connection 14 transport protocol of hypertext transfer protocol (HTTP) and hypertext transfer protocol secure (HTTPS), other transport protocols may be suitable such as TCP/IP, and any other transport protocol suitable for SOAP messages.

A method 200 of implementing the process of FIG. 1 is illustrated in FIG. 2. To manage the resource 18, the client manager 12 may request instrumentation information from or apply actions to the resource by sending 202 a SOAP request message 30 to the resource agent 16. The request 30 may include a resource indicator indicating the target resource 18 and an operation identifier indicating the information to be retrieved and/or action to be taken.

The client manager may identify the appropriate resource identifier and address of the appropriate resource agent in any suitable manner by either knowing or discovering the appropriate resource identifier and selecting the appropriate operation for that resource and/or selecting the appropriate resource agent 16. In one example, the client manager may send the SOAP request message 30 to all available resource agents and the appropriate agent may self-determine that it is the intended addressee. In another example, the appropriate resource agent for a desired resource may be determined by the client manager in any suitable manner such as by accessing a client data store (not shown) which associates a resource identifier with an address for the appropriate resource agent.

In yet another example, referring to FIGS. 1 and 2, the client manager 12 may send 220 a resource identification message to a resource agent 16 requesting available resources and/or valid operations. The resource agent 16 may identify 222 available resources in any suitable manner, such as by accessing the catalog data store 20 which lists available resource identifier. The catalog data store may be any suitable data store such as a database, a virtual catalog, or hard-wired into software code. One suitable method to generate and store the catalog store 20 is discussed in more detail in U.S. patent application Ser. No. 10/692,432 titled USE OF ATTRIBUTION TO DESCRIBE MANAGEMENT INFORMATION, and filed Oct. 23, 2003, and incorporated herein by reference. The resource agent may send 224 a response to the client manager 12 listing available resource identifiers. The system administrator may select a desired resource identifier from the list, and the client manager may automatically generate the required message to be sent to the resource agent and incorporate the selected resource identifier. The resource agent, in response to the identification message, may also list valid operations and/or accessible information for one or more of the listed resources. In this manner, the systems administrator may choose the desired resource identifier by analyzing the accessible information listing and may choose the desired and valid operation to execute against the selected resource identifier. It is to be appreciated that any suitable user interface of the client component may be appropriate to support receiving resource information from the resource agent, selecting a resource identifier and/or operation identifier, and/or generating a request message to be sent to the resource agent.

Upon receipt of a request message 30 from a client manager requesting an operation against an identified resource 18, the resource agent 16 may resolve 204 the resource identifier into an address for the appropriate local handler 22. The resource agent may use any suitable method or process to resolve the resource identifier into an address for the local handler such as accessing a catalog data store 20 which associates a resource identifier with a local handler address. The catalog data store may be any suitable data store such as a database, a virtual catalog, or hard-wired into software code. The resource agent 16 may then translate 206 the SOAP message 30 into an appropriate format and/or schema compliant with the local handler 22. The resource agent 16 may determine the appropriate schema or message format for the resolved local handler 22. For example, different local handlers 22 for different resources 18 may require different schemas such as message formats, data fields, parameters, actions, and the like. The resource agent may determine the local handler message schema in any suitable manner such as accessing the catalog data store 20 which may associate the local handler address with a communication schema. Appropriate methods of communicating with local handlers and their schema is discussed further in U.S. patent application Ser. No. 10/692,432 titled USE OF ATTRIBUTION TO DESCRIBE MANAGEMENT INFORMATION, and filed Oct. 23, 2003, and incorporated herein by reference.

The local handler 22 associated with a resource 18 may be provided by the provider of the resource to expose information within or about the resource. The resource identifier associated with a resource may be any suitable identifier such as a uniform resource identifier (URI) which may be the same as or different from the URI provided by the manufacturer of the resource. Accordingly, the resource identifier provided by the client manager may be able to direct the resource agent towards the local handler and/or resource desired by the client manager.

The resource agent may dispatch 208 the local request/action message 32 to the resolved address of the local handler 22 for operation on the identified resource 18. It should be recognized that any dispatching architecture may be appropriate for the platform supporting the resource agent 16. The resource agent 16 may additionally propagate the security credentials of the client manager 12 to the local handler so that the local handler can properly authenticate 209 the message. It is to be appreciated that the resource agent and/or the local handler may authenticate the request message. Moreover, it is to be appreciated that any suitable authentication scheme may be appropriate. For example, the content contained in the header and/or body element of the SOAP request 30 may be encrypted. Accordingly, authentication may include decrypting the request. Additionally or alternatively, authentication may include verifying that the header and/or body elements of the SOAP request 30 are in the proper format.

The local handler 22 may then access 210 the appropriate resource 18 to retrieve the requested information and/or enact the indicated operation on the resource. The local handler may return 212 a response 34 containing the results and/or verification of the requested operation to the resource agent 16. The resource agent 16 may convert 214 the results in the response 34 into a SOAP response message 36, such as by translation or encapsulation, and send 216 the response message with the results to the client manager 12.

To manage the resource 18, the client manager 12 may request instrumentation information from and/or apply actions to the resource 18 through a SOAP message 30 sent to the resource agent 16. The resource identifier included in the SOAP request message 30 from the client manager may be any suitable address for the resource 18 such as a name, domain name, IP address, uniform resource locator (URL), uniform resource identifier (URI), or any other suitable unique naming convention that may be communicated by the client manager and resolved by the resource agent to an associated local handler for a resource. For example, the URI may be a location-independent network address with a systems management protocol suffix, such as /wsman. URIs are further described in Berners-Lee et al., “RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax,” August 1998, available at http://www.ietf.org/rfc/rfc2396.txt. The resource identifier may identify the target resource, the item or information to be retrieved, the method being accessed, the table being queried, the event stream to which a subscription applies, and the like. For example an HTTP transport URI may be http://1.2.3.4/wsman and a Windows Secure Transport URI may be wst://mymachine.microsoft.com/wsman. It is to be recognized that additional or alternative namespaces may be used as appropriate such as other namespaces may be used as proxy namespaces for logical resources. For example, https://1.2.3.4/wsman/otgweb may be considered a portal namespace for managing the otgweb Web site which may be a distributed deployment using clustered servers. In this manner, no one machine ‘owns’ the management space.

In another example, the resource identifier may include a common information model (CIM) class compliant with the CIM standard available from DMTF at http://www/dmtf.org/standards/cim and incorporated herein by reference. For example, the Object Path accessor in CIM may become the resource identifier and may be represented by an XML schema. The resource identifier containing a CIM class may also be a URI. For example, a URI for a CIM class may start with a prefix comprising the CIM namespace followed by the class name. Using CIM_NumericSensor as an example, the URI prefix may be:

• • wsman:dmtf.cim/root/cimv2/CIM.NumericSensor.
    The CIM class may have one or more URIs associated with it, each URI accessing an instance of the CIM class. For example, the NumericSensor example may include four URIs, each associated with a ‘resource’ as a specific instance of the class:

wsman:dmtf.cim/root/cimv2/CIM.NumericSensor

wsman:dmtf.cim/root/cimv2/CIM.NumericSensor?DeviceID=_—1

wsman:dmtf.cim/root/cimv2/CIM.NumericSensor/Reset?DeviceId=_—1/Reset

wsman:dmtf.cim/root/cimv2/CIM.NumericSensor/SetPowerState?DeviceId=_—1

In the above example, the first URI may reference a resource that enumerates all instances whereas the second URI may retrieve a specific instance identified by its key property (e.g., multiple keys may be comma separated). For example, a general syntax may be used such as:
key1=value1+key2=value2+key3=value3
If the value of a key contains a ‘+’, ‘=’, or any other suitable symbol, then a parenthesis or other suitable separator may be used, e.g., key=(1+2=3). Generally, conversion of a CIM class to a URI may involve generating a number of URIs or other resource identifiers. For example, there may be one URI for getting individual instances, another URI for enumerating all instances of the class, another URI for each method, another URI for each type of update of writeable properties, and possibly another URI for each creation and/or deletion of instances.

As shown in the example schematic SOAP request of FIG. 3, the SOAP request 30 may contain a SOAP envelope element 302, a SOAP header element 304, and a SOAP Body element 306. As shown in FIG. 3, the header element may include a To header 308, an Action header 310, and a MessageID header 312. In this manner, the SOAP message 30 from the client manager 12 includes at least one tuple including an operation identifier and a resource identifier 314 and indicates that it is a SOAP message with contents that are compliant with a specification accessible through the defined XML namespace.

The To header may contain a transport-level address of the resource agent and the namespace within the system supporting the resource agent and may be compliant with WS-Addressing standards. The To header element may also contain a mustUnderstand attribute which may be set equal to TRUE.

The SOAP request 30 may also contain a MessageID header which may contain a message identifier, such as a UUID, indicating a particular message and may be compliant with the WS-Addressing MessageID standard. The MessageID header may also contain a mustUnderstand attribute which may be set equal to TRUE. An example message ID field may take the form of

	<wsa:MessageID env:mustUnderstand=“true”>

uuid:e83327d2-7eab-4ad2-8c76-e206e763d634

	</wsa:MessageID>

The Action header 310 may indicate that the request message 30 is a particular type of request for a particular operation or action. The Action header may also contain a mustUnderstand attribute that may be set equal to TRUE. The operation may be identified by any suitable identifier such as a name, number, or namespace. As shown in FIG. 3, the operation identifier may take the format of <namespace of governing standard>/<name of operation>. In this manner, the Action header may be compliant with the standards defined in the namespace of the operation identifier. The governing standard for the operation may include a user defined or accepted standard such as

wsman—http://schemas.xmlsoap.org/ws/2004/04/wsmanprof

wsa—http://schemas.xmlsoap.org/ws/2003/03/addressing

wsh—http://schemas.xmlsoap.org/ws/2004/04/shellexec

wxf—http://schemas.xmlsoap.org/ws/2004/01/transfer

wsen—http://schemas.xmlsoap.org/ws/2004/04/enumeration

wse—http://schemas.xmlsoap.org/ws/2004/01/eventing

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

The WS-Addressing namespace is described in Bosworth et al., “Web Services Addressing (WS-Addressing),” Mar. 13, 2003, http://msdn.microsoft.com/library/default.asp?url=/library/en -us/dnglobspec/html/wsaddressingspecindex.asp. The wsh, or WS-ShellExecute, namespace may define and/or configure operations of the client manager. The wxf, or WS-Transfer, namespace, may provide operations suitable for management of network systems, e.g., Get, Put, Create, and Delete. The wse, or WS-Enumeration, namespace may provide the Enumerate operation and optional subordinate operations. The wse, or WS-Eventing, namespace may expose event subscription operations which may allow client managers to receive events from streaming sources. The xs, or XML, namespace may define the configuration and format of XML. XML is described further in Gudgin et al., “SOAP 1.2 Part 1: Messaging Framework,” Jun. 23, 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. Those of skill in the art will recognize that the namespace locations and the namespace prefixes may be selected as appropriate. For example, custom or user defined namespaces may also be suitable to defined custom methods and/or user-defined actions. The namespaces may be defined as a convention for headers and/or operations. For example, the WSDL, WS-Addressing, and other protocol defined namespaces may define SOAP header and/or body element blocks to standardize the identification of the operation, the message identification, the sender, the recipients, and the like.

The prefix of the namespace may be used to define the associated instruction or operation in the SOAP message 30. Any suitable operation may be defined through any suitable specification defined in a namespace including operation names of Get, Put, Create, Delete, Enumerate, Pull, Release, Subscribe, Unsubscribe, Renew, OpenShell, CloseShell, ControlShell, Command, CommandIO, Trap, EventBatch, or any other suitable operation indicator for managing a network system resource. The identified operation may also allow parameters to be set and/or input for the execution of the indicated operation, and may be indicated by the operation parameters which may be included in the header element 304 and/or body element 306.

The request 30 may also contain a resource identifier field 314 containing a resource identifier, such as a URI, which identifies the target resource, e.g., an indicator of the object which is being retrieved or modified, the table being enumerated, and the like. Together the To header and the ResourceURI element may form a complete network path from the client manager to the specific target resource. The resource identifier field may contain a mustUnderstand attribute set to TRUE. The element identifying the target resource may be contained in the header element and/or body element as appropriate. For example, a resource identifier element for a disk drive may take the form of

	<wsaResourceURI env:mustUnderstand=’true’

wsman:Microsoft.os.storage.disks/Drives/diskInfo?drive=c:

	</wsa:ResourceURI>

Other operation and message parameters may included in additional headers and/or in the body element 306 of the request message 30.

Referring to FIG. 1, upon receipt of a SOAP request 30 including a resource identifier and action identifier, the resource agent 16 may resolve the resource identifier into a local handler 22 address, translate the request, and dispatch the translated request 32 to the local handler. The resource agent and/or local handler may also authenticate the SOAP request 30, which may be under a consistent authentication scheme defined by the SOAP standards. The local handler may access the indicated resource 18 and retrieve the requested information and/or execute the indicated operation. The results 34, such as the retrieved information and/or an indication of success or failure of the operation, may be sent from the local handler to the resource agent. The resource agent may convert the result into a SOAP response 36 and send that response to the client manager in reply to the SOAP request 30.

As shown in the example schematic SOAP response of FIG. 4, the SOAP response 36 may contain a SOAP envelope element 402, a SOAP header element 404, and a SOAP Body element 406. As shown in FIG. 4, the header element may include a From header 408, an Action header 410, a MessageID header 412, and a RelatesTo header 414. Other operation and message parameters may included in additional headers and/or in the body element 406 of the response message 36. In this manner, the SOAP response message 36 from the resource agent 16 includes at least one tuple including an operation identifier and a RelatesTo message identifier and indicates that it is a SOAP message with contents that are compliant with a specification accessible through the defined XML namespace.

The From header may contain a transport-level address of the resource agent and/or a resource agent identifier, and the namespace within the system supporting the resource agent which may be compliant with WS-Addressing standards. The address of the resource agent may be the same as or different from the address of the resource agent provided in the To header of the associated request 30.

The MessageID header 412 may contain a field indicating a message identifier which identifies the specific message any be compliant with the WS-Addressing MessageID standard. The MessageID header may also contain a mustUnderstand attribute which may be set equal to TRUE.

The RelatesTo header 414 may include a field containing a copy of the message ID of the original request. In this manner, the client manager may distinguish between simultaneously arriving replies using some modes of transports. The RelatesTo header may be compliant with WS-Addressing standards.

The Action header 410 of the SOAP response 36 may contain an operation identifier which indicates that the message is response to a request of a particular operation. The Action header may also contain a mustUnderstand attribute that may be set equal to TRUE. The operation may be identified by any suitable identifier such as a name, number, or namespace. As shown in FIG. 4, the operation identifier may take the format of <namespace of governing standard>/<name of operation>Response. In this manner, the Action header may be compliant with the standards defined in the namespace of the operation identifier.

The SOAP request and response messages may be coded using any appropriate character encoding standard such as UNICODE 3.0 (UTF-16) and UTF-8. The characters supported by the management system 10 may include U+0000 to U+007F inclusive with both UTF-8 and/or UTF-16 encodings and may support characters outside this range.

WS-Transfer Messages

Get Request and Response A Get request containing a Get action identifier may retrieve information from a resource 18 indicated by the resource identifier of the SOAP request 30. The information retrieved may be a representation or value of a resource, which may simple or complex values, such as an instance, a file system resource, and the like. Example information retrieved by a Get operation may include configuration settings or dynamic runtime-only values such as disk free space, hardware status, application settings, operating system performance values, and the like. The Get operation may be appropriate for a singleton and may not be appropriate for multiple entries or rows from tables and logs, however, the Get operation may be suitable for retrieving a single entry from such collections.

In one example, the Get request has an empty body element and all information describing what instrumentation information to retrieve is contained in the SOAP header element. The Get message may contain a TO header, an Action header, a ResourceURI header, a MessageID header, an optional Timeout header, an optional Locale header, an optional Summary header, and any other header suitable for a Get request. One example of a Get request 30 is illustrated in FIG. 3 described above.

The To header, ResourceURI header, Action header, MessageID header may be similar to those described above with reference to FIG. 3. The Action header may contain the name of the operation which may be any suitable action or operation indicator such as Get, providing a namespace of http://schemas.xmlsoap.org/ws/2004/01/transfer/Get, which may be compliant with WS-Transfer standards.

The Get request message may contain an optional Timeout header which indicates the maximum amount of time the client is willing to wait for a reply. If the time expires without information from the resource, the resource agent 16 may return a fault message. If the resource agent cannot comply with the specified Timeout period, the resource agent may return an Unsupported Timeout or other suitable fault message. If the Timeout field is not defined in the message, the resource agent 16 may implement a default timeout period which may be published. The Timeout header may be compliant with the xs namespace standards and may be a xsd:duration.

The Get request message may also include an optional Locale header containing a locale identifier indicating the locale of the client element to assist the resource agent when producing localized content. The locale identifier may use an XML attribute ‘lang’ whose value conforms to ISO 639 language codes described further in http://www.w3.org/WAI/ER/IG/ert/iso639.htm. The resource agent 16 may access the locale identifier and default fault and textual descriptions to match the indicated locale. It is to be appreciated that if the resource agent cannot comply with the indicated locale, it may return a fault message or may return all messages in a default locale, such as English. The Locale header may be complaint with the wsman namespace standards described herein.

The Get request message may include an optional Summary header that provides a hint to the resource agent that a summary representation is preferred if available. Summary representations may be abbreviated equivalents with less detail, but may be lightweight and more efficient. The Summary header may be complaint with the wsman namespace standards described herein.

The information communicated by the Get response message may included in the SOAP response message 36 header and/or body element, as may be appropriate. For example, the retrieved information may be contained in the body element, and various headers may contain message identifying information The Get response message may contain a From header, an Action header, a MessageID header, a RelatesTo header as described above, and any other header suitable for a Get response. An example Get response is illustrated in FIG. 4.

The From header may also contain the resource identifier which may be the same as the resource identifier sent in the ResourceURI header of the Get request. The resource identifier may be wrapped in a WS-Addressing wrapper, such as a ResourceProperties element. The From field may be compliant with WS-Addressing for the base type as defined by WS-Transfer.

An Action header of a Get response message 36 may indicate that the message is a response to a Get request. The Action header may be compliant with WS-Addressing for the based type as defined by the WS-Transfer protocol. Accordingly, the Get Action namespace may be constant and be http://schemas.xmlsoap.org/ws/2004/01/transfer/GetResponse.

The body element to a Get response may contain the information from the resource and may be in any suitable format including an XML Infoset. If the resource agent 16 cannot respond to the any of the above requests with the requested information, the resource agent may send a suitable fault response as described further below.

In one example, a client manager may desire the fan speed of a motherboard identified by the URI of wsman:acme.boards.model12012/fanspeed. In this case, the resource is a single, read-only value, and therefore compatible with a Get operation. The client manager 12 may build a SOAP message 30 indicating the Get operation and the URI of the motherboard, and send the message 30 to the resource agent 16. The resource agent 16 may access the catalog data store 20 to resolve the resource identifier, here a URI, to the location of the local handler 22 and the schema for communicating with the local handler. The resource agent 16 may reformat the operation identifier of the SOAP message 30 into the appropriate schema for communicating with the local handler and send the operation to the local handler. The resource agent may also forward to the local handler the client component's security credentials so that the operation can be properly secured, audited, and executed by the local handler. The local handler may determine the desired value and return it to the resource agent in a message 34. The resource agent 16 may then enclose the retrieved value in a SOAP response message 36 having the format of a Get Response and send the message to the client manager 12. The SOAP response message may include a SOAP body element such as wxf:GetResponse <speed xmlns=“http://schemas.acme.com/2004/07/model12012”> 1200</speed> to communicate the desired resource information to the client manager. The client manager 12 may extract the value (an XML Infoset) from the SOAP response message 36, and display the value to the user through a display device.

Put Request and Response

The Put SOAP request 30 may request that information of an existing resource 18 be updated. The information may be “settings’ or “configuration” values, whether permanent or temporary, and may include disk volume comment, logging level of a device, cache size setting, working directory, or any other appropriate setting or configuration value that is not read-only. The Put operation may update a single value of may update an entire file.

Some values of resources may be read-only or may be read-write. If the value is read-only, the resource agent may determine the legality of the update request in a Put request. For example, a resource representing a complex real-world object, such as a logical disk drive with a volume label may provide disk information within the body of a Get response as:

<DiskInfo xmlns=http://schemas.microsoft.com/windows/os/diskinfo”>

	<Drive> C: </Drive>
	<TotalCapacity> 12000000000 </TotalCapacity>
	<FreeSpace> 802012911 </FreeSpace>
	<FileSystem> NTFS </FileSystem>
	VolumeLabel> CDrive </VolumeLabel>

</DiskInfo>

In the above example, only the VolumeLabel value may be read-write, and the rest of the retrieved information may be read only. The status, either read-write or read-only, may be exposed in any suitable manner. For example, the resource identifier, such as a URI, may be different for a Get operation than for a Put operation. In this manner, the Get URI for a resource may expose those values that can be read, whereas the Put URI for the same resource may expose only those values which are read-write capable. Alternatively, the resource identifier may be the same for a Get operation as for a Put operation, however, the resource agent may validate the property of the value of the resource to determine if the resource value indicated may be ‘put’, e.g., is a read-write capable value. The resource agent 16 may validate the resource property using any suitable method including accessing the catalog data store 20 which may associate the resource identifier with a resource property identifier. If the indicated Put operation does not reference a resource identifier having a valid property type, e.g., a read-only resource value, then the resource agent may return a fault message.

The information communicated by the Put request message may be included in the header and/or body element of the request message as appropriate. For example, the information regarding the resource and put information may be included in the body element of the SOAP message 30 and may also provide additional headers in the header element to identify other suitable message information. The Put message may contain a To header, an Action header, a MessageID header, a ResourceURI header, an optional Timeout header, an optional Locale header, and any other suitable header for a put request. The To header, Action header, MessageID header, and ResourceURI header may be similar to those described above with reference to FIG. 3. The Action header may be compliant with the WS-Transfer protocol. Accordingly, the Put Action namespace may be constant and be http://schemas.xmlsoap.org/ws/2004/01/transfer/Put. The Timeout and Locale headers may be similar to those headers described above with reference to the Get request. The body of the Put request may contain the new representation of the resource to be implemented, such as in an XML Infoset. One example of a Put request is shown below. Although the body element below lists both read-write and read-only values, the resource agent will only implement the read-write type values, here the VolumeLabel.

	(1)	<?xml version=“1.0”?>
	(2)	<env:Envelope

	(3)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
	(4)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
	(5)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”>
	(6)
	(7)	<env:Header>

(8)

<wsa:To env:mustUnderstand=“true”>

(9)

https://1.2.3.4/wsman

	(10)	</wsa:To>
	(11)
	(12)	<wsa:Action env:mustUnderstand=“true”>

(13)

http://schemas.xmlsoap.org/ws/2004/01/transfer/Put

	(14)	</wsa:Action>
	(15)	<wsa:MessageID env:mustUnderstand=“true”>

(16)

uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

	(17)	</wsa:MessageID>
	(18)
	(19)	<wsman:ResourceURI env:mustUnderstand=“true”>

(20)

wsman:microsoft.os.storage.disks/Drives/diskInfo?drive=c:

	(21)	</wsman:ResourceURI>
	(22)	<wsman:Timeout> PT30S </wsman:Timeout>
	(23)	</env:Header>
	(24)
	(25)	<env:Body>

(26)

<DiskInfo xmlns=http://schemas.com/2004/06/diskinfo”>

	(27)	<Drive> C: </Drive>
	(28)	<TotalCapacity> 12000000000 </TotalCapacity>
	(29)	<FreeSpace> 802012911 </FreeSpace>
	(30)	<FileSystem> NTFS </FileSystem>
	(31)	<VolumeLabel> MyCDisk </VolumeLabel>

(32)

</DiskInfo>

	(33)	</env:Body>
	(34)

	(35)	</env:Envelope>

Upon receiving a Put request, the resource agent 16 may follow a best-effort logic to carry out the update through the appropriate local handler 22 and resource 18, as shown in FIG. 1. In response to a Put request, the resource agent 16 may generate a Put SOAP response 36. The Put response may indicate success and optionally may contain the new updated resource, or may return a fault response. The information communicated by the Put response may be included in the header element of the SOAP response and may optionally include information in the SOAP body element.

The Put response message 36 may contain a From header, an Action header, a MessageID header, a RelatesTo header, a NewResourceURI header, and any other header suitable for a Put response. The From header, Action header, MessageId header and RelatesTo header may be similar to those headers described above with reference to FIG. 3. The From header may include the Address element with the address of the resource agent and may also include a Reference Properties element which contains the resource identifier of the target resource indicated in the Put request. The resource identifier may be wrapped in a Resource URI element. The Action header may be compliant with the WS-Transfer protocol. Accordingly, the Put Action namespace may be constant and be http://schemas.xmlsoap.org/ws/2004/01/transfer/PutResponse. The NewResourceURI header may be used to indicate the new URI of the resource. In this manner, the Put operation may cause the resource identifier such as a URI to change, e.g., a rename operation. The client manager 12 may store the resource identifier to ensure that future messages to that resource are identified properly, such as in the catalog data store.

An example Put response is illustrated below.

(1)	<?xml version=“1.0”?>
(2)	<env:Envelope

(3)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
(4)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
(5)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”>
(6)

(7)	<env:Header>

(8)	<wsa:From>
(9)	<wsa:Address> http://1.2.3.4/wsman </wsa:Address>
(10)	<wsa:ReferenceProperties>

(11)	<wsman:ResourceURI>

(12)	wsman:microsoft.os.storage.disks/Drives/diskInfo?drive=c:

(13)	</wsman:ResourceURI>

(14)	</wsa:ReferenceProperties>

(15)	</wsa:From>
(16)	<wsa:Action env:mustUnderstand=“true”>

(17)	http://schemas.xmlsoap.org/ws/2004/01/transfer/PutResponse

(18)	</wsa:Action>
(19)	<wsa:RelatesTo >

(20)	uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

(21)	</wsa:RelatesTo>
(22)	<wsa:MessageId>

(23)	uuid:f9726325-aa90-120b-6ed2-ae5ffb223a81

(24)	</wsa:MessageId>
(25)	<wsman:NewResourceURI>

(26)	wsman:microsoft.os.storage.disks/Drives/diskInfo?drive=c:

(27)	</wsman:NewResourceURI>
(28)	</env:Header>
(29)
(30)	<env:Body/>
(31)	</env:Envelope>

In a successful Put operation, the body of the put response may be left blank. Alternatively, the body of the SOAP response message 36 may be used to communicate the value actually put into the resource. For example, it may verify that the proper value was put by the local handler into the resource, or if the resource agent needed to change a value, the returned value may communicate that the requested put value was modified during the Put operation. For example, the Put request may request that the name be changed to “los angeles”. The resource agent 16 may accept the put action, but may modify the name such that the final representation is not identical, e.g., may change the name to “Los Angeles, Calif.”. The modified information may be placed into the body of the response message in a manner similar to the Get response illustrated in FIG. 4. If the resource agent 16 cannot successfully put the indicated value into the indicated resource 18, the resource agent may send a suitable fault response.

Create Request and Response

The Create request may create a new resource 18 indicated by the resource identifier of the SOAP message 30. Accordingly, the Create operation may create a new resource which can be subsequently queried or retrieved using a Get request. In some cases, the Create operation may be logically equivalent to a ‘constructor’ in object-oriented databases and programming languages, e.g., the create request may create any resource which can subsequently be accessed by other wsman operations. Example new resources may include a new log, a new shared disk volume, a new-user, a new file, a new network share point, a new performance monitoring process, and the like. Although the new resource may support retrieval of information through Get operations, updating of information with a Put operation and/or deletion of information with a Delete operation, it should be appreciated that any combination or no operations may be supported by the newly created resource. For example, a newly created resource may allow a Put operation to update the resource information but not allow a Get operation to discover that information.

The Create request may indicate a resource identifier which indicates a ‘factory’ resource which creates the resource, and may also include a resource identifier for the new resource and any other parameters required to create the new resource, which may be submitted as an XML Infoset. The factory resource may function as a constructor and the resource identifier of the new resource may be communicated in the SOAP request message 30 through the body element or the header element. The Create request may include a To header, an Action header, a MessageID header, a ResourceURI header, an optional Timeout header, an optional Locale header, and any other suitable header for a Create request. An example Create message is illustrated below.

	(1)	<?xml version=“1.0”?>
	(2)	<env:Envelope

	(3)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
	(4)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
	(5)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”>

(6)

<env:Header>

(7)

<wsa:To env:mustUnderstand=“true”>

(8)

https://1.2.3.4/wsman

	(9)	</wsa:To>
	(10)
	(11)	<wsa:Action env:mustUnderstand=“true”>

(12)

http://schemas.xmlsoap.org/ws/2004/01/transfer/Create

	(13)	</wsa:Action>
	(14)
	(15)	<wsa:MessageID env:mustUnderstand=“true”>

(16)

uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

	(17)	</wsa:MessageID>
	(18)
	(19)	<wsman:ResourceURI env:mustUnderstand=“true”>

(20)

wsman:microsoft.os.networking/shares/create

	(21)	</wsman:ResourceURI>
	(22)
	(23)	<wsman:Timeout> PT30S </wsman:Timeout>

	(24)	</env:Header>
	(25)
	(26)	<env:Body>

(27)

<CreateShare xmlns=“http://schemas.org/2004/06/shareCreate”>

	(28)	<Name> SchemaShare </Name>
	(29)	<Resource> c:\temp\xmlschemas </Resource>
	(30)	<Label> This is where I share out my XML schemas </Label>

(31)

</CreateShare>

	(32)	</env:Body>
	(33)
	(34)	</env:Envelope>

The To header, the Message ID header, the Timeout header, and Locale header of the Create request may be similar to those described above with reference to the Get request. The Action header may indicate that the requested action or operation of a create operation and may be compliant with the WS-Transfer standard. The Create Action header may be constant and may take the form of:

	<wsa:Action env:mustUnderstand=“true”

http://schemas.xmlsoap.org/ws/2004/01/transfer/Create

	</wsa:Action>

The Resource ID header may be similar to that described above, however, the resource identifier contained in the resource ID header field may be the resource ID of the factory resource which may create the new resource. The body of the create message may contain the parameters which represent the values required to create or construct the new resource, and may be in the form of an XML Infoset.

The resource agent 16, after receiving a Create request may communicate with the local handler for the indicated factory resource and create the new resource. The resource agent may respond to the client manager 12 with a Create response indicating success and the new resource identifier of the created resource, or may indicate a fault message. The Create response may contain a From header, an Action header, a Message ID header, and any other suitable header for a Create response. An example Create response is illustrated below.

	(1)	<?xml version=“1.0”?>
	(2)	<env:Envelope

	(3)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
	(4)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
	(5)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”>
	(6)
	(7)	<env:Header>
	(8)	<wsa:From>

(9)

<wsa:Address> http://1.2.3.4/wsman </wsa:Address>

(10)

<wsa:ReferenceProperties>

(11)

<wsman:ResourceURI>

(12)

wsman:microsoft.os.networking/shares/create

(13)

</wsman:ResourceURI>

	(14)	</wsa:ReferenceProperties>
	(15)	</wsa:From>
	(16)	<wsa:Action env:mustUnderstand=“true”>
	(17)	http://schemas.xmlsoap.org/ws/2004/01/transfer/CreateResponse
	(18)	</wsa:Action>
	(19)	<wsa:RelatesTo >

(20)

uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

	(21)	</wsa:RelatesTo>
	(22)	<wsa:MessageId>

(23)

uuid:f9726325-aa90-120b-6ed2-ae5ffb223a81

	(24)	</wsa:MessageId>
	(25)	</env:Header>
	(26)
	(27)	<env:Body>

(28)

<wxf:ResourceCreated>

(29)

<wsman:ResourceURI>

(30)

wsman:os.shares/SchemaShare

(31)

</wsman:ResourceURI>

(32)

</wxf:ResourceCreated>

	(33)	</env:Body>
	(34)

	(35)	</env:Envelope>

The From header and Message ID header may be similar to those described above with reference to the Get response. The Action header may indicate that the response is a Create Response action, and may have the value: http://schemas.xmlsoap.org/ws/2004/01/transfer/CreateResponse. The resource identifier for the new resource may be in a new resource header, or alternatively, may be contained in the body element of the create response, such as a ResourceCreated wrapper containing a ResourceURI element. If the resource agent 16 cannot successfully create the new resource, the resource agent may send a suitable fault response. The fault response may indicate the reason why the resource agent cannot create the new resource.

Delete Request and Response

The Delete operation may remove an existing resource 18 indicated by the resource identifier of the SOAP message 30. The delete operation may be logically similar to a destructor in object-oriented databases and programming languages. Example deleted resources may include an obsolete log, an unused share volume, a user accounts, and the like.

The Delete SOAP message may communicate the resource identifier of the resource to be removed in the header element or body element of the SOAP message. In one example, the resource identifier may be contained in the header element. The Delete request may include a To header, an Action header, a Message ID header, an optional Timeout header, a ResourceURI header, and any other header suitable for a delete request. An example Delete request is shown below.

	(1)	[<?xml version=“1.0”?>
	(2)	<env:Envelope

	(3)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
	(4)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
	(5)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”>
	(6)
	(7)	<env:Header>
	(8)	<wsa:To env:mustUnderstand=“true”>

(9)

https://1.2.3.4/wsman

	(10)	</wsa:To>
	(11)	<wsa:Action env:mustUnderstand=“true”>

(12)

http://schemas.xmlsoap.org/ws/2004/01/transfer/Delete

	(13)	</wsa:Action>
	(14)

(15)

<wsa:MessageID env:mustUnderstand=“true”>

(16)

uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

	(17)	</wsa:MessageID>
	(18)
	(19)	<wsman:ResourceURI env:mustUnderstand=“true”>

(20)

wsman:microsoft.os.network.share/delete/MyShare

	(21)	</wsman:ResourceURI>
	(22)	<wsman:Timeout> PT30S </wsman:Timeout>
	(23)	</env:Header>
	(24)
	(25)	<env:Body/>
	(26)
	(27)	</env:Envelope>

The To header, MessageID header, and ResourceURI header may be similar to those described above with respect to the Get request. The Action header may indicate that the response is a Delete Request action, and may have the value: http://schemas.xmlsoap.org/ws/2004/01/transfer/Delete which may be compliant with WS-Transfer standards.

The resource agent 16, after receiving a Delete request may communicate with the local handler 22 for the indicated resource and delete the new resource. The resource agent may respond to the client manager 12 with a delete response indicating success, or may indicate a fault message. The Delete response may contain a From header, an Action header, a Message ID header, a RelatesTo header, and any other suitable header for a Create response. An example Create response is illustrated below.

	(1)

	(2)	<?xml version=“1.0”?>
	(3)	<env:Envelope

	(4)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
	(5)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
	(6)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”>
	(7)
	(8)	<env:Header>
	(9)	<wsa:From>
	(10)	<wsa:Address> http://1.2.3.4/implementation </wsa:Address>
	(11)	<wsa:ReferenceProperties>

	(12)	<wsman:ResourceURI>
	(13)	microsoft.os.network.share/delete/MyShare
	(14)	</wsman:ResourceURI>

(15)

</wsa:ReferenceProperties>

	(16)	</wsa:From>
	(17)
	(18)	<wsa:Action env:mustUnderstand=“true”>
	(19)	http://schemas.xmlsoap.org/ws/2004/01/transfer/DeleteResponse
	(20)	</wsa:Action>
	(21)
	(22)	<wsa:RelatesTo >

(23)

uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

	(24)	</wsa:RelatesTo>
	(25)	<wsa:MessageId>

(26)

uuid:f9726325-aa90-120b-6ed2-ae5ffb223a81

	(27)	</wsa:MessageId>
	(28)
	(29)	</env:Header>
	(30)
	(31)	<env:Body/>
	(32)	</env:Envelope>

The From header, Message ID header, and RelatesTo header may be similar to those described above with reference to the Get response. The Action header may indicate that the response is a Delete Response action, and may have the value: http://schemas.xmlsoap.org/ws/2004/01/transfer/DeleteResponse.

If the resource agent 16 cannot successfully delete the resource, the resource agent may send a suitable fault response. The fault response may indicate the reason why the resource agent cannot delete the new resource.

WS-Enumeration Messages

Enumerate Request and Response

The Enumerate request may create an enumeration sequence or list of the contents of a container or table-based resource 18 identified by the resourced identifier of the SOAP message 30. Table based resources may include tables, logs and the like. Each table ‘row’ or log entry may be an XML fragment or document, so that the entire table may be a list of XML fragments or documents. The resource may contain a single schema or a mix of schemas. An Enumerate operation may be applied against dynamic lists such as running processes, lists of logged-on users, event log content and the like.

After receiving an enumeration request, the resource agent 16 may send an enumerate response message which contains a token such as an Enumeration Context which represents the enumerator. If the targeted resource cannot supply an enumeration of its content, a fault message may be returned. In this manner the Enumerate operation may create an enumerator which may be accessed with one or more Pull requests which ‘pull’ the content from the enumerator in the Pull responses. The pulled information may be in any suitable format, such as an XML Infoset in the body element of the Pull response. Each Pull response may have one or more XML Infosets representing the enumeration. At any time, the resource agent may issue a fault response if the enumeration cannot be continued or a timeout occurs. The enumerator may be terminated early, e.g., before all batches of the information in pulled, with a Release operation.

The Enumerate request message 30 may include information in the header element and/or the body element of the SOAP message 30. In one example, the Enumerate request message may include a To header, an Action header, a Message ID header, a ResourceURI header, a Timeout header, a Locale header, and any other header suitable for an Enumerate request. The body element of the Enumerate request message 30 may include any other parameters which specify the filter or query, such as an XPath query, applied to the enumeration. If the body element is empty, the resource agent may interpret the Enumerate request as a simple enumeration. An example Enumerate Request is illustrated below.

(1)	<?xml version=“1.0”?>
(2)	<env:Envelope

(3)	xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
(4)	xmlns:wsman=“http://schemas.xmlsoap.org/ws/2004/06/wsman”
(5)	xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing”
(6)	xmlns:wsen=“http://schemas.xmlsoap.org/ws/2004/04/enumeration”>

<env:Header>

(7)	<wsa:To env:mustUnderstand=“true”>

(8)	https://1.2.3.4/wsman

(9)	</wsa:To>
(10)

(11)	<wsa:Action env:mustUnderstand=“true”>

(12)	http://schemas.xmlsoap.org/ws/2004/04/enumeration/Enumerate

(13)	</wsa:Action>
(14)
(15)	<wsa:MessageID env:mustUnderstand=“true”>

(16)	uuid:d9726315-bc91-430b-9ed8-ce5ffb858a87

(17)	</wsa:MessageID>
(18)
(19)	<wsman:ResourceURI env:mustUnderstand=“true”>

(20)	wsman:microsoft.os.system.processes/list

(21)	</wsman:ResourceURI>
(22)	</env:Header>
(23)
(24)	<env:Body>
(25)	<wsen:Enumerate>

(26)	<wsen:Filter>

(27)	Process[Type=“Service”]

(28)	</wsen:Filter>

(29)	</wsen:Enumerate>
(30)	</env:Body>
(31)
(32)	</env:Envelope>

The To header, the Message ID header, ResourceURI header, Timeout header, and Locale header may be similar to those headers described above with reference to the Get request. The Action header may indicate that the response is an Enumeration action, and may have the value: http://schemas.xmlsoap.org/ws/2004/04/enumeration/Enumerate and may be compliant with WS-Enumeration standards.

The Enumeration header may also include a mustUnderstand field set to TRUE. In one example, the Enumerate request message 30 may include a Filter element which supports mixed content. In some cases, the default dialect for filters may be XPath and other dialects may be indicated with a Dialect attribute. If another dialect is indicated, the language must have a URI or other suitable identifier associated with it such that the provided query may be parsed and enacted. For example, a body element of an example Enumeration request may be:

	...
	<s:Body ...>

<wsen:Enumerate>

	<wsen:Filter Dialect=”xs:anyURI”?> </wsen:Filter>
	Query text or XML

</wsen:Enumerate>

	</s:Body>
	</s:Envelope>

In another example, the query may be structured using an XML rather than a simple string. In this case, an XML namespace may be provided in addition to the XML. An example body element of an Enumeration request indicating a union of independent SQL queries may be:

	...
	<s:Body ...>

<wsen:Enumerate>

<wsen:Filter

	<myQuery:Query
	xmlns:myQuery=“queries.org/2003/3/myquery”>

<Sql> select * from ProcessList </Sql>

1. A computer storage medium having computer executable instructions for performing steps comprising: (a) receiving from a sending device at a receiving device a first Simple Object Accessing Protocol (SOAP) message comprising a first operation identifier for accessing instrumentation information and a first resource identifier associated with a first computer system resource; (b) resolving the first resource identifier into an address for a local handler associated with the first resource; (c) sending a local request to the local handler at the resolved address; (d) determining a timeout period for the first Simple Object Accessing Protocol message, the timeout period being a published default timeout period, the timeout period not being part of the first Simple Object Accessing Protocol message, determining the timeout period including requesting the published timeout period from a publishing device, the publishing device being different from the sending device and the receiving device; and (e) when the receiving device cannot comply with the timeout period, sending an Unsupported Timeout message to the sending device.

2. The computer storage medium of claim 1, wherein the first resource identifier includes a Uniform Resource Identifier.

3. The computer storage medium of claim 1, wherein the first resource identifier includes a CIM.

4. The computer storage medium of claim 1, further comprising determining a schema for communicating with the local handler, and generating the local request from the SOAP message and the accessed schema.

5. The computer storage medium of claim 1, further comprising receiving the instrumentation information from the local handler, and sending to a client manager a SOAP response comprising the instrumentation information.

6. The computer storage medium of claim 1, further comprising authenticating the first SOAP message using hypertext transport protocol secure (HTTPS).

7. The computer storage medium of claim 1, wherein the first operation identifier includes at least one of a group consisting of a get identifier, a put identifier, a create resource identifier, a delete resource identifier, an enumerate identifier, a pull identifier, a release identifier, an open shell identifier, a close shell identifier, a control shell identifier, a command result identifier, a subscribe identifier, an unsubscribe identifier, a renew subscription identifier, a event batch identifier, and a trap identifier.

8. The computer storage medium of claim 1, further comprising receiving a second SOAP message comprising a second operation identifier for accessing instrumentation information and a second resource identifier associated with a second computer system resource, wherein the first operation identifier includes at least one of the a group consisting of a get request, a put request, a delete request, and a create request, and the second operation identifier includes at least one of a group consisting of a subscribe identifier, an unsubscribe identifier, an event batch identifier, and a trap identifier.

9. The computer storage medium of claim 8, further comprising authenticating the first SOAP message and the second SOAP message with a consistent authentication scheme.

10. A computer storage medium having computer executable instructions for performing steps comprising: (a) sending from a client manager to a resource agent a first Simple Object Accessing Protocol (SOAP) request comprising an first operation identifier for retrieving instrumentation information and a resource identifier indicating a resource that is the source of the instrumentation information; (b) receiving at the client manager a first SOAP response comprising a first value of the instrumentation information of the resource; (c) sending from the client manager a second SOAP request comprising a second operation identifier for correcting instrumentation information, the resource identifier, and a second value of the instrumentation information, the second SOAP request requesting that the first value be replaced by the second value in the resource associated with the resource identifier; and (d) receiving at the client manager a second SOAP response, the second SOAP response being in response to the second SOAP request and indicating that the first value has been replaced by a third value instead of the second value in the resource associated with the resource identifier, the third value being different from the second value.

11. The computer storage medium of claim 10, further comprising receiving a second SOAP response verifying that the first value has been replaced by the second value in the resource associated with the resource identifier.

12. The computer storage medium of claim 10, wherein the resource identifier includes a uniform resource identifier (URI).

13. The computer storage medium of claim 10, wherein the first value is a singleton value.

14. The computer storage medium of claim 10, wherein the first value is an enumeration sequence.

15. The computer storage medium of claim 10, wherein the first operation identifier includes a namespace of a governing standard and a name of the operation.

16. The computer storage medium of claim 10, further comprising determining the type of instrumentation information of the second value.

17. The computer storage medium of claim 10, further comprising sending a fault response if the type of instrumentation information is not read-write accessible.

18. A computer storage medium having computer executable instructions for performing steps comprising: (a) receiving a request message comprising an operation identifier for accessing instrumentation information, an address of a resource agent, and a uniform resource identifier identifying a computer system resource associated with the resource agent; (b) resolving the uniform resource identifier into an address for a local handler associated with the resource; (c) sending a local request to the local handler at the resolved address; (d) receiving resource instrumentation information; (e) determining based on a maximum time value in the request message, the maximum time value indicating a maximum time and not a set of requested information whether the maximum time for the resource agent to respond is zero; and (f) sending, in response to the local request, only cached results in response to determining the maximum time for the resource agent to respond is zero.