3.1.4.13 Send

Web Services Management Protocol Extensions for Windows Vista MUST support the Send operation, using the following Action URIs.

 http://schemas.microsoft.com/wbem/wsman/1/windows/shell/Send http://schemas.microsoft.com/wbem/wsman/1/windows/shell/SendResponse
            

The set of resource URIs on which Web Services Management Protocol Extensions for Windows Vista MUST support the Send operation is defined in the following table, and where relevant, the Xml Schema Definition (XSD) type for the data that is passed as part of the request or response is referenced.

In the Text-based Command Shell scenario, the Send message is used to pipe input to a running command, and in the Custom Remote Shell scenario, the Send message is used to pipe input to the Shell processor. The message MUST be of the same general format, with the value of Resource URI being the only difference between the two scenarios. Also, the CommandId attribute of each stream element MUST be used for Text-based Command Shell and MUST be omitted for CustomShell. The message for the Text-based Command Shell is as follows.

 <s:Envelope ...>
   <s:Header ...>
     <wsman:ResourceURI>
       http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd
     </wsman:ResourceURI>
     <wsman:SelectorSet>
        <wsman:Selector Name="ShellID">
              ...shell GUID...
        </wsman:Selector>
     </wsman:SelectorSet>
       ...other WS-Addressing & WS-Management headers...
   </s:Header>
   <s:Body ...>
     <rsp:Send ...>
         ...Value defined by the Send data type...
     </rsp:Send>
   </s:Body>
 </s:Envelope>
            

The value of Resource URI will be different for the Text-based Command Shell and the Custom Remote Shell.

In case of the Text-based Command Shell, the value of Resource URI MUST be as follows. http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd

An example of Resource URI for the Custom Remote Shell scenario is as follows. http://schemas.microsoft.com/wbem/wsman/1/windows/shell/CustomShell

The following rules apply to the Send operation:

• Only one Send request can be outstanding per instance of the Shell. Only when a rsp:SendResponse is received can another rsp:Send occur. However, a rsp:Send can occur asynchronously to any rsp:Receive request.

• In case of the Text-based Command Shell scenario, if the input is being sent to a specific command and the command completes or fails without consuming all the input, that additional unconsumed input MUST be discarded and ignored.

• Sending empty stream content ("dummy" messages) is permitted. This might be required to prevent deadlock or livelock in certain commands with heavy input and output interaction. CommandId MUST be included for the Text-based Command Shell scenario and MUST be omitted for the Custom Remote Shell scenario.

Upon successful processing of a Send request message, a processor MUST return a SendResponse message, which MUST adhere to the same general form in both scenarios. The Custom Shell scenario uses SendResponse to get status information. SendResponse reflects the status of writing the BLOB of data (commands+args+data) to stdin; the status of executing the commands, if any, is not reflected in the SendResponse message, but later in the ReceiveResponse message (stdout/stderr); this is transparent to the Remote Shell protocol and up to the Shell.

The response message is as follows.

 <s:Envelope ...>
   <s:Header ...>
     <wsman:SelectorSet>
        <wsman:Selector Name="ShellID">
              ...shell GUID...
        </wsman:Selector>
     </wsman:SelectorSet>
       ...other WS-Addressing & WS-Management headers...
   </s:Header>
   <s:Body ...>
     <rsp:SendResponse ...>
         ...Value defined by the SendResponse data type...
     </rsp:SendResponse>
   </s:Body>
 </s:Envelope>
            

The attribute CommandId MUST only be used in the Text-based Command Shell scenario and MUST NOT be used in Custom Remote Shell scenario.