WS-Discovery Spezifikationscompliance

WS-Discovery- beschreibt, wie die folgenden Aufgaben ausgeführt werden:

• Ankündigung der Verfügbarkeit von Diensten im lokalen Subnetz
• Suchen nach Diensten im Subnetz
• Suchen eines zuvor referenzierten Diensts

Dazu definiert WS-Discovery zwei unidirektionale Nachrichten, Hello und Byesowie zwei bidirektionale Suchnachrichten, Probe und Auflösen.

WS-Discovery stellt außerdem Adressen und einen reservierten Port für die lokale IPv4- und IPv6-Verknüpfung bereit. Die Spezifikation ermöglicht es auch, alternative Bindungen an anderer Stelle zu definieren, z. B. die Probe über HTTP-Bindung, die im Geräteprofil für Webdienste (DPWS) definiert ist.

In der WS-Discovery Spezifikation werden wahlpflichtige Funktionen mithilfe der Begriffe MAY oder SHOULD in einer bestimmten Implementierungsempfehlung oder -einschränkung beschrieben. Die ausgelassene Funktionalität kann in der WS-Discovery Spezifikation, die nicht von WSDAPI implementiert wurde, als ERFORDERLICH beschrieben werden, oder es kann sich um Funktionalität handelt, die WSDAPI in einer anderen Methode in der in der WS-Discovery Spezifikation angegebenen implementiert wurde.

In diesem Thema wird beschrieben, wie WS-Discovery Einschränkungen, Anforderungen und Wahlfunktionen von der WSDAPI-Implementierung behandelt werden. Dieses Thema ist am besten zusammen mit der WS-Discovery Spezifikation zu lesen.

WS-Discovery- und SOAP-over-UDP-Unterstützung

In SOAP-over-UDP gibt Abschnitt 3.2 an, dass die UDP-Nachricht in ein 64K-Datagramm passen muss. WSDAPI akzeptiert 64K UDP-Nachrichten, aber die DPWS-Einschränkung von MAX_ENVELOPE_SIZE (32K) schränkt die Nachrichtengröße ein. Gemäß WS-Discovery-unterstützt WSDAPI die in Abschnitt 4 beschriebenen Nachrichtenmuster.

WSDAPI kann für die Unterstützung des Sicherheitsmodells in Den Abschnitten 7 und 8 konfiguriert werden. Wenn dies konfiguriert ist, werden von WSDAPI ausgehende WS-Discovery Nachrichten abgemeldet und Signaturen für eingehende Nachrichten überprüft.

WSDAPI implementiert den in Anhang I definierten Retransmissionsalgorithmus gemäß der Fassung des DPWS Anhang I.

In WS-Discovery verwendet WSDAPI die in Abschnitt 2.4 angegebenen Adressen. WSDAPI erweitert APP_MAX_DELAY aus Abschnitt 2.4, jedoch nicht im Umfang, wie in ANHANG I der DPWS definiert. Weitere Informationen zu APP_MAX_DELAY finden Sie unter Additional WS-Discovery Functionality.

WS-Discovery beschreibt die empfehlung für das uuid: URI-Format in Abschnitt 2.6, aber WSDAPI setzt diese Empfehlung außer Kraft. Stattdessen verwendet WSDAPI das in DPWS beschriebene urn:uuid: URI-Format.

Abschnitt 3 von WS-Discovery beschreibt, wie ein Client mit einem Ermittlungsproxy interagiert. WSDAPI erkennt diese Interaktion nicht und ignoriert Ankündigungen von Discoveryproxys. In Windows 7 implementiert WSDAPI eine private Erweiterung für das WS-Discovery-Protokoll, WS-Discovery Remoteerweiterungen, um Ermittlungsclients die Suche nach Diensten in vielen verschiedenen Netzwerken zu ermöglichen, indem Anforderungen an zentralisierte Proxys gesendet werden. Weitere Informationen finden Sie unter Zusätzliche WS-Discovery Funktionalität.

Abschnitt 4.1, Absatz 3 von WS-Discovery erfordert, dass ein Timer verstrichen sein muss, bevor eine Hello Nachricht gesendet wird. Die Hosting-API wartet nicht, bevor eine Hello-Nachricht gesendet wird. Wenn ein Szenario eine Verzögerung erfordert, bevor eine Hello-Nachricht gesendet wird, muss der Anwendungsentwickler eine Wartezeit implementieren.

WSDAPI implementiert alle in WS-Discovery Abschnitten 4, 5 und 6 beschriebenen Nachrichten. WSDAPI erzwingt auch die in Abschnitt 7 beschriebene MATCH_TIMEOUT in der geänderten Fassung von DPWS Anhang I. WSDAPI schützt nur vor "Replay" vor den sicheren Überlegungen in Abschnitt 9.

WSDAPI implementiert Anwendungssequenzierung wie in anhang I WS-Discovery beschrieben.