Partager via

WSDAPI Devices and Services Concepts (Windows Embedded CE 6.0)

  • Article

1/6/2010

Applies to Windows Embedded CE 6.0 R2

Content about WSDAPI uses the following terminology.

  • DPWS
    Microsoft follows the Devices Profile for Web Services (DPWS) protocol standard. For more information, see this Web Site.
  • WSDAPI
    Microsoft's Web Services on Devices stack and API (WSDAPI) which is an implementation of the DPWS.
  • Device host
    A DPWS-compliant device that hosts DPWS-compliant services.
  • Client application
    A DPWS-compliant client.
  • Client-side proxy
    Generated code that converts method calls within the client application into SOAP messages, and sends those SOAP messages over the network.
  • Service-side stub
    Generated code that receives SOAP messages from the network, and converts them to method calls into an application-supplied service object.
  • DPWS device
    DPWS-compliant device that can run on WSDAPI or run on other DPWS stacks.

You can use WSDAPI to develop client applications and device implementations. The following home control system scenario shows an example of client applications and device host implementations.

Home Control Automation Example

A home control automation product attached to a network includes a temperature sensor and an alarm controller. The automation product advertises itself on the local subnet as a device host with two services: a temperature read-out service, and an alarm service.

  • A temperature display application that runs on a Windows Vista PC or a Windows Embedded CE powered device sends a WS-Discovery Probe message to search for any devices advertising the temperature device type. The temperature display application connects to the automation box to retrieve the metadata that describes the type and address of the temperature service. The client application then issues a GetTemperature request and receives from the automation box a response that includes the current temperature reading.
  • An alarm control application similarly sends WS-Discovery messages searching for alarm device types, and retrieves metadata to determine the type and address of the alarm service. The alarm service exposes three operations: one that sets the current alarm state to Armed or Disarmed; another that queries the front door sensor for the status of Open or Closed; and a third that issues an event notification to all subscribed clients when something triggers the alarm. The client application can invoke the first or second operations as necessary, and can subscribe to event notifications for the third operation.

See Also

Concepts

About Web Services on Devices
Discovery and Metadata Exchange Message Patterns