Compartir a través de

Introducing DPWS

  • Artículo

[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]

Your PC or other device can detect DPWS-enabled devices on a network, then discover and invoke the Web service functionality each device provides. You can use these DPWS capabilities in the .NET Micro Framework. DPWS is also sometimes called Web Services on Devices (WSD). A PC or other device can detect DPWS-enabled devices on a network, then discover and invoke the Web service functionality each device provides. DPWS is part of the Windows Rally technology set. A DPWS client library (known as WSDAPI) is a part of Windows Vista, and DPWS-enabled devices automatically appear in the Windows Vista Network Explorer.

In Web Services terms, a profile is a set of guidelines for how to use Web Services technologies for a given purpose. The Web Services standards allow implementers to choose from a variety of message representations, text encodings, transport protocols, and other options, some of which are not mutually interoperable. By constraining these decisions, profiles ensure that implementations conforming to the profile will work well together.

Communicating Between Devices

DPWS provides the following functionality between compatible devices:

  • Discovering DPWS-capable devices on the network and the services they offer

  • Sending messages to DPWS-capable devices and receiving replies

  • Describing a Web service by providing a WSDL file

  • Interacting with a service using its description

  • Subscribing to and receiving events from a Web service

Devices can be DPWS clients (invoking services on devices), servers (providing services), or both. DPWS for the .NET Micro Framework supports devices in either role or both simultaneously. These two sets of functionality are provided in separate DLLs and are not dependent on each other.

DPWS is based on existing Web Services standards, including XML, WSDL, XML Schema, SOAP, MTOM, and HTTP. DPWS for the .NET Micro Framework also incorporates this functionality, although not all of it is exposed in the API. For example, there are classes for reading and writing XML documents so that applications and service implementations can parse Web Services messages and build responses to them.

Understanding Implementation Specifics

DPWS is a profile developed by Microsoft and others for communication with and among networked devices and peripherals. As such, the DPWS library for the .NET Micro Framework is not a full Web Services implementation but rather a lightweight subset with only the specific functionality needed to support DPWS on a device. The full specification is at the following URL: https://schemas.xmlsoap.org/ws/2006/02/devprof/

The DPWS specification defines the required behavior of a DPWS implementation, but leaves some decisions to the implementer. The following list describes the behavior of the .NET Micro Framework DPWS implementation relative to the specification. See the DPWS specification for further details on any of these requirements.

  • URIs longer than MAX_URI_SIZE (2,048 octets) are not processed and a SOAP fault is generated. (Section 3.1, requirement R0025.)

  • The address property of a device’s Endpoint Reference must be a UUID. (Section 3.5, requirement R0004.)

  • A device will not include any reference properties in its Endpoint Reference. (Section 3.5, requirement R0007.)

  • A service will always use an HTTP transport address as the address property of its Endpoint Reference. (Section 3.5, requirement R0042.) The address is formed using the device’s IP address and a unique UUID-based URN.

  • The developer must manually increment the metadata version number if any of the device’s ThisDevice or relationship metadata changes. (Section 5.1 requirement R2002, Section 5.2 requirement 2030).

  • The implementation does not provide any WSDL-related functionality aside from message validation (Section 5.3, requirements R2023 and R2024), although validation uses the .NET service classes rather than WSDL. The device developer must provide a WSDL description of their service and make it publicly accessible via URL (for example, by placing it on a Web server).

  • This implementation does not support WS-POLICY (Section 5.4), DateTime expiration types (Section 6.2), or security (Section 7), all optional features.