Freigeben über


WS-Discovery Spezifikationskonformität

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

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

Um dies zu erreichen, definiert WS-Discovery zwei unidirektionale Nachrichten, Hello und Bye, und zwei bidirektionale Suchnachrichten, Probe und Resolve.

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

Die WS-Discovery Spezifikation beschreibt die wahlpflichtige Funktionalität, indem die Begriffe MAY oder SHOULD in einer bestimmten Implementierungsempfehlung oder -einschränkung verwendet werden. Fehlende Funktionalität kann in der WS-Discovery Spezifikation als ERFORDERLICH beschrieben werden, die nicht von WSDAPI implementiert wurde, oder es kann eine Funktionalität sein, die WSDAPI in einer anderen Methode in der in der WS-Discovery-Spezifikation angegebenen implementiert hat.

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

unterstützung für WS-Discovery und SOAP-over-UDP

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. Wie für WS-Discovery erforderlich, 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, wird WSDAPI ausgehende WS-Discovery Nachrichten abmelden und Signaturen für eingehende Nachrichten überprüfen.

WSDAPI implementiert den in Anhang I definierten Neuübertragungsalgorithmus, wie durch DPWS Anhang I geändert.

In WS-Discovery verwendet WSDAPI die in Abschnitt 2.4 angegebenen Adressen. WSDAPI erweitert APP_MAX_DELAY aus Abschnitt 2.4, jedoch nicht in dem Umfang, wie in DPWS Anhang I definiert. Weitere Informationen zu APP_MAX_DELAY finden Sie unter Zusätzliche WS-Discovery Funktionen.

WS-Discovery beschreibt die Empfehlung für das uuid: URI-Format in Abschnitt 2.6, aber WSDAPI überschreibt diese Empfehlung. Stattdessen verwendet WSDAPI das urn:uuid: in DPWS beschriebene 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 Ermittlungsproxys. In Windows 7 implementiert WSDAPI eine private Erweiterung für das WS-Discovery-Protokoll, WS-Discovery Remoteerweiterungen, damit Ermittlungsclients nach Diensten suchen können, die über viele verschiedene Netzwerke verteilt sind, indem Anforderungen an zentralisierte Proxys gesendet werden. Weitere Informationen finden Sie unter Zusätzliche WS-Discovery Funktionalität.

Abschnitt 4.1, Absatz 3 der WS-Discovery erfordert, dass ein Timer verstreichen muss, bevor eine Hello-Nachricht gesendet wird. Die Hosting-API wartet nicht vor dem Senden einer Hello-Nachricht. 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 Meldungen. WSDAPI erzwingt auch die MATCH_TIMEOUT, die in Abschnitt 7 in der durch DPWS Anhang I geänderten Fassung beschrieben sind. WSDAPI schützt nur vor "Replay" vor den sicheren Überlegungen in Abschnitt 9.

WSDAPI implementiert die Anwendungssequenzierung, wie in WS-Discovery Anhang I beschrieben.