DPWS-Spezifikationskonformität

In diesem Thema wird beschrieben, wie WSDAPI die wahlfähige Funktionalität in der DPWS-Spezifikation ( Geräteprofil für Webdienste ) implementiert. Außerdem wird beschrieben, welche DPWS-Funktionalität aus der WSDAPI-Implementierung weggelassen wurde.

Die DPWS-Spezifikation bietet eine konsistente Möglichkeit, Nachrichten mit Geräten zu senden. Außerdem werden spezifische Einschränkungen und Empfehlungen hinzugefügt, die den Prozess der Unterstützung von Webdiensten auf eingebetteter Hardware vereinfachen.

Die DPWS-Spezifikation beschreibt die wahlpflichtige Funktionalität unter Verwendung der Begriffe MAY oder SHOULD in einer bestimmten Implementierungsempfehlung oder -einschränkung. Fehlende Funktionalität kann eine Funktionalität sein, die in der DPWS-Spezifikation als ERFORDERLICH beschrieben wird, die nicht von WSDAPI implementiert wurde, oder es kann eine Funktionalität sein, die WSDAPI in einer anderen Methode in der in der DPWS-Spezifikation angegebenen methode implementiert hat.

Dieses Thema folgt dem Layout des DPWS-Abschnitts nach Abschnitt. In jedem Abschnitt wird beschrieben, wie bestimmte Einschränkungen, Anforderungen und Wahlfunktionen von der WSDAPI-Implementierung behandelt werden. Dieses Thema ist am besten zusammen mit der DPWS-Spezifikation gelesen.

DPWS 3.0 Messaging

DPWS 3.1-URI-Formate

Die Einschränkungen R0025 und R0027 beschränken URIs auf MAX_URI_SIZE Oktette. WSDAPI erzwingt beide Einschränkungen wie angegeben.

DPWS 3.2 UDP-Messaging

Empfehlung R0029 schlägt vor, dass UDP-Pakete, die größer als die maximale Übertragungseinheit (MTU) für UDP sind, nicht gesendet werden sollten. WSDAPI implementiert diese Empfehlung nicht und ermöglicht Implementierungen das Senden und Empfangen von Ermittlungsmeldungen, die größer als die MTU sind.

DPWS 3.3 HTTP-Messaging

R0001 erfordert, dass Dienste die blockierte Übertragung unterstützen. WSDAPI akzeptiert abgeblockte Daten in Anforderungsnachrichten und sendet in Anforderungsnachrichten daten mit Blöcken.

R0012 und R0013 beschreiben die erforderlichen Teile der SOAP-HTTP-Bindung. Für R0012 implementiert WSDAPI die SOAP-HTTP-Bindung, beginnt jedoch erst mit dem Lesen der HTTP-Antwort, wenn WSDAPI das Senden der HTTP-Anforderung abgeschlossen hat. WSDAPI implementiert das erforderliche Nachrichtenaustauschmuster in R0013, implementiert den optional reagierenden SOAP-Knoten in R0014 und implementiert nicht das optionale Webmethodenfeature in R0015. WSDAPI unterstützt auch die Anforderungen in R0030 und R0017.

DPWS 3.4 SOAP-Umschlag

WSDAPI unterstützt R0034 und erzwingt R0003 und R0026 standardmäßig. Genauer gesagt, gemäß R0003 und R0026, wenn WSDAPI einen SOAP-Umschlag empfängt, der größer als MAX_ENVELOPE_SIZE über HTTP ist, wird er abgelehnt und die Verbindung wird geschlossen.

DPWS 3.5 WS-Addressing

R0004 spiegelt die empfohlene Verwendung der Geräte-API in WSDAPI wider und wird von der Client-API in WSDAPI unterstützt. Da dies eine Empfehlung ist, ermöglicht WSDAPI Clients und Geräten, andere URIs als urn:uuid URIs für ihre Geräteendpunkte zu verwenden, um maximale Kompatibilität sicherzustellen. Da die Geräte-API in WSDAPI den Zustand zwischen Initialisierungen nicht beibehalten kann, liegt es an Anwendungsentwicklern, die die Geräte-API in WSDAPI verwenden, um sicherzustellen, dass R0005 und R0006 ordnungsgemäß unterstützt werden. Die Client-API in WSDAPI geht davon aus, dass Geräteidentitäten eindeutig und dauerhaft sind, und die Funktionalität, die auf der Client-API in WSDAPI (z. B. PnP-X) aufbaut, erfordert dies, um das Gerät bei Geräteneustarts ordnungsgemäß zu erkennen.

R0007 empfiehlt die Verwendung von Verweiseigenschaften in Endpunktverweise. WSDAPI erkennt weiterhin Endpunkte mit Verweiseigenschaften und akzeptiert sie, und Entwickler können sie verwenden, aber standardmäßig füllt WSDAPI sie nicht in von ihr erstellten Endpunkten auf. In ähnlicher Weise verwendet WSDAPI bei R0042 beim Erstellen von Dienstendpunkten eine HTTP- oder HTTPS-Transportadresse, erfordert jedoch nicht, dass Geräte HTTP- oder HTTPS-Transportadressen in ihren Dienstendpunkten verwenden. Das Verhalten des Clients bei dem Versuch, mit einem Dienst zu kommunizieren, der weder HTTP noch HTTPS verwendet, ist nicht definiert.

Bei Fehlern schränkt R0031 den Antwortendpunkt ein und beschreibt den zu sendenden Fehler, wenn der Fehler nicht anonym ist. WSDAPI erzwingt, dass der Antwortendpunkt beim Senden von Nachrichten den richtigen Wert verwendet, und fehlerbehaftet, wenn WSDAPI eine Anforderungsnachricht mit dem falschen Antwortendpunkt empfängt. R0041 bietet Implementierungen die Möglichkeit, einen Fehler zu löschen, wenn der Antwortendpunkt ungültig ist. Anstatt den Fehler zu löschen, sendet WSDAPI den Fehler zurück auf den Anforderungskanal, der an den anonymen Endpunkt adressiert ist, als "best effort" für die Kommunikation mit dem Client.

Schließlich gibt es zwei Einschränkungen für SOAP-Header, R0019 und R0040, die WSDAPI erfüllt und für empfangene Nachrichten erzwingt.

DPWS 3.6 Anlagen

WSDAPI unterstützt Anlagen und entspricht R0022. WSDAPI entspricht auch R0037. Beim Senden von Anlagen legt WSDAPI die Inhaltsübertragungscodierung für alle MIME-Teile immer auf "binär" fest. WSDAPI erzwingt R0036 jedoch nicht. Das Verhalten von WSDAPI beim Empfangen eines MIME-Teils mit einer Inhaltsübertragungscodierung, die nicht auf "binär" festgelegt ist, ist nicht definiert.

DPWS definiert auch MIME-Klauseln für die Teilereihenfolge. Für R0038 erzwingt WSDAPI die Teilereihenfolge und lehnt eine MIME-Nachricht ab, wenn der SOAP-Umschlag nicht der erste MIME-Teil ist. Für R0039 sendet WSDAPI immer den SOAP-Umschlag als ersten MIME-Teil.

DPWS 4.0 Discovery

R1013 und R1001 unterscheiden Geräteermittlung und Dienstermittlung. WSDAPI entspricht R1013. Die Hostingimplementierung entspricht R1001, WSDAPI erzwingt diese Empfehlung jedoch nicht auf dem Client.

DPWS bietet auch Anleitungen zu Typen und Bereichsabgleichsregeln. WSDAPI unterstützt alle in WS-Discovery definierten Bereichsabgleichsregeln mit Ausnahme von LDAP. WSDAPI bietet auch ein erweiterbares Modell zum Definieren benutzerdefinierter Bereichsabgleichsregeln und entspricht somit R1019. Die Hosting-API stellt auch immer den Typ in der wsdp:Device Ermittlung pro R1020 bereit, aber die Client-API erfordert nicht, dass er vorhanden ist. Andere Anwendungen, die auf WSDAPI basieren, z. B. PnP-X, haben eine harte Anforderung, damit der Typ bei der wsdp:Device Ermittlung vorhanden ist.

Um die Ermittlung und Bindung zu erleichtern, unterstützt WSDAPI R1009 und R1016. Gemäß R1018 ignoriert WSDAPI Multicast-UDP, das nicht an die anonyme Adresse gesendet wurde. R1015, R1021 und R1022 definieren eine HTTP-Bindung für die Testnachricht, die WSDAPI wie beschrieben unterstützt.

DPWS 5.0 Beschreibung

WSDAPI erzwingt R2044 auf dem Client. Auf der Hostseite stellt WSDAPI immer nur das wsx:Metadata Element im SOAP-Umschlagtext bereit. R2045 ermöglicht Es Geräten, eine Teilmenge der WS-Transfer-Funktionalität zu unterstützen. Die Hosting-API generiert den wsa:ActionNotSupported Fehler immer.

DPWS 5.1 Merkmale

DPWS beschreibt grundlegende Merkmale des Geräts. Zusätzlich zu den in diesem Thema beschriebenen Einschränkungen werden Längenlimits für bestimmte Zeichenfolgen und URIs definiert. WSDAPI erzwingt die Längengrenzwerte in diesem DPWS-Abschnitt 5.1, entweder vor dem Senden der Nachricht oder nach der Analyse des Inhalts.

DPWS beschreibt auch die erforderlichen Metadatenabschnitte und den Zyklus der Metadatenversion. Die Clientimplementierung erzwingt das Vorhandensein von ThisModel- und ThisDevice-Metadaten. Die Hostingimplementierung verwaltet auch ordnungsgemäß die Metadatenversion und stellt immer diese Abschnitte bereit, die den Anforderungen von R2038, R2012, R2001, R2039, R2014 und R2002 entsprechen.

DPWS 5.2 Hosting

In diesem Abschnitt wird die Hierarchie der Dienste und Beziehungsmetadaten beschrieben. WSDAPI erzwingt weder auf der Client- noch auf der Geräteseite die Eindeutigkeit der ServiceId, wie in diesem Abschnitt beschrieben.

WSDAPI entspricht R2040, und es ist möglich, dass die Hostingimplementierung eine Metadatenantwort ohne Beziehungsabschnitt sendet, wenn keine gehosteten Dienste vorhanden sind. Die Clientimplementierung akzeptiert die Metadatenantwort ordnungsgemäß.

R2029 ermöglicht mehrere Beziehungsabschnitte in einer Metadatenantwort, die von WSDAPI ordnungsgemäß akzeptiert werden. R2030 und R2042 beschreiben die Verwaltung der Metadatenversion, die ordnungsgemäß in der Hosting-API implementiert wird.

DPWS 5.3 WSDL

Wenn ein Dienst WSDL-Daten (Web Services Description Language) bereitstellt, können Clientimplementierungen die Dienstdefinition abrufen und den Dienst direkt bearbeiten. Dies wird von spät gebundenen Clients verwendet. Die WSDAPI-Clientimplementierung akzeptiert WSDL, die von einem Dienst bereitgestellt wird, aber der Client überprüft sie nicht, und der Client stellt kein spät gebundenes Programmiermodell bereit. Die Hostingimplementierung kann verwendet werden, um WSDL bereitzustellen, aber der Host ist dazu nicht erforderlich, da die Metadaten des Servicelevels nicht vom Host selbst verwaltet werden.

DPWS 5.4 WS-Policy

DPWS beschreibt Richtlinienassertionen, die für Geräte verwendet werden sollen. Da WSDAPI WSDL nicht bereitstellt und nicht interpretiert, kann es keine in WSDL-Daten eingebettete Richtlinie erkennen und erzwingen.

DPWS 6.0-Ereigniserstellung

DPWS 6.1-Abonnement

DPWS erfordert Unterstützung für die Pushübermittlung. WSDAPI implementiert die Pushbereitstellung auf der Dienstseite und entspricht somit R3009 und R3010 und akzeptiert nur den Push-Übermittlungsmodus auf der Clientseite. R3017 und R3018 erfordern bestimmte Fehler vom Dienst, wenn er die NotifyTo Adressen oder EndTo nicht erkennt. WSDAPI überprüft diese Adressen nicht im Voraus und generiert diese Fehler nicht. Die Clientimplementierung erkennt diese Fehler jedoch ordnungsgemäß. In ähnlicher Weise ist R3019 optional, und WSDAPI implementiert diese Empfehlung nicht, aber die Clientimplementierung erkennt die SubscriptionEnd Nachricht ordnungsgemäß und benachrichtigt die Anwendung über einen Übermittlungsfehler.

DPWS 6.1.1 Filterung

WSDAPI entspricht R3008 und implementiert den Action Filter. In Übereinstimmung mit R3011 und R3012 generiert WSDAPI die Fehler in den angegebenen Bedingungen nicht. WSDAPI implementiert auch den beschriebenen R3020-Fehler, wenn es die Aktionen nicht erkennt, nach denen es gefiltert werden soll.

DPWS 6.2 Abonnementdauer und -verlängerung

WSDAPI entspricht R3005, R3006 und R3016. WSDAPI wird immer verwendet xs:duration , akzeptiert xs:dateTime jedoch, wenn angegeben, und stellt daher den optionalen Fehler in R3013 nicht aus. WSDAPI unterstützt GetStatus und gibt den wsa:ActionNotSupported Fehler nicht gemäß R3015 aus. WSDAPI akzeptiert den wsa:ActionNotSupported Fehler, wenn ein Dienst auf eine GetStatus Anforderung mit diesem antwortet.

DPWS 7.0-Sicherheit

DPWS beschreibt ein empfohlenes Sicherheitsmodell für Geräte. WSDAPI implementiert diese Empfehlungen nicht wie beschrieben und erzwingt die Einschränkungen in diesem Abschnitt nicht wie beschrieben.

DPWS Anhang I

DPWS ändert globale Konstanten aus anderen Spezifikationen an Geräte. WSDAPI verwendet die Konstanten aus diesem Abschnitt und überschreibt die Standardkonstanten in der WS-Discovery-Implementierung mit diesen Konstanten. Anwendungen, die WSDAPI für WS-Discovery verwenden, sind an die in DPWS definierten Konstanten gebunden, nicht an die in WS-Discovery definierten Konstanten.