DPWS-Spezifikationscompliance

In diesem Thema wird beschrieben, wie WSDAPI die wahlfähige Funktionalität in der Spezifikation Devices Profile for Web Services (DPWS) implementiert. Außerdem wird beschrieben, welche DPWS-Funktionalität aus der WSDAPI-Implementierung weggelassen wurde.

Die DPWS-Spezifikation bietet eine konsistente Möglichkeit für Nachrichten mit Geräten. 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 wahlpflichtige Funktionen mithilfe der Begriffe MAY oder SHOULD in einer bestimmten Implementierungsempfehlung oder -einschränkung. Ausgelassene Funktionen können funktionen sein, die in der DPWS-Spezifikation als ERFORDERLICH beschrieben werden, die nicht von WSDAPI implementiert wurde, oder es kann sich um Funktionalität handelt, die WSDAPI in einer anderen Methode in der in der DPWS-Spezifikation angegebenen implementiert wurde.

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

DPWS 3.0 Messaging

DPWS 3.1-URI-Formate

Einschränkungen R0025 und R0027 beschränken URIs auf MAX_URI_SIZE Oktetts. WSDAPI setzt diese beiden Einschränkungen wie angegeben durch.

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 Discoverynachrichten, die größer als die MTU sind.

DPWS 3.3 HTTP-Messaging

R0001 erfordert, dass Dienste eine blockierte Übertragung unterstützen. WSDAPI akzeptiert blockierte Daten in Anforderungsnachrichten und sendet Daten in Anforderungsnachrichten.

R0012 und R0013 beschreiben die erforderlichen Teile der SOAP-HTTP-Bindung. Für R0012 implementiert WSDAPI die SOAP-HTTP-Bindung, beginnt jedoch nicht mit dem Lesen der HTTP-Antwort, bis WSDAPI das Senden der HTTP-Anforderung abgeschlossen hat. WSDAPI implementiert das erforderliche Nachrichtenaustauschmuster in R0013, implementiert den optionalen reaktionsfähige 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 Envelope

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 sie abgelehnt und die Verbindung 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 die Verwendung anderer URIs als urn:uuid URIs für ihre Geräteendpunkte, um maximale Kompatibilität sicherzustellen. Da die Geräte-API in WSDAPI nicht zwischen Initialisierungen beibehalten wird, 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 Funktionalität, die auf der Client-API in WSDAPI (z. B. PnP-X) aufbauen, erfordert dies, um das Gerät über Geräteneustarts ordnungsgemäß zu erkennen.

R0007 empfiehlt die Verwendung von Referenzeigenschaften in Endpunktverweise. WSDAPI erkennt und akzeptiert weiterhin Endpunkte mit Referenzeigenschaften, und Entwickler können diese verwenden, aber standardmäßig füllt WSDAPI sie nicht in endpunkten, die es erstellt. Ebenso verwendet WSDAPI bei R0042 Dienstendpunkte, die eine HTTP- oder HTTPS-Transportadresse verwenden, für Geräte jedoch keine HTTP- oder HTTPS-Transportadressen in ihren Dienstendpunkten erforderlich sind. Das Verhalten des Clients beim Versuch, mit einem Dienst zu kommunizieren, der http oder HTTPS nicht 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 den Antwortendpunkt, den richtigen Wert beim Senden von Nachrichten zu verwenden, und tritt ordnungsgemäß auf, wenn WSDAPI eine Anforderungsnachricht mit dem falschen Antwortendpunkt empfängt. R0041 bietet Implementierungen die Möglichkeit, einen Fehler abzulegen, wenn der Antwortendpunkt ungültig ist. Anstatt den Fehler abzulegen, sendet WSDAPI den Fehler an den Anforderungskanal zurück, der an den anonymen Endpunkt adressiert ist, als "best effort", um mit dem Client zu kommunizieren.

Schließlich gibt es zwei Einschränkungen für SOAP-Header, R0019 und R0040, deren WSDAPI sowohl den empfangenen Nachrichten entspricht als auch erzwingt.

DPWS 3.6 Anlagen

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

DPWS definiert auch MIME-Part-Sortierklauseln. Für R0038 erzwingt WSDAPI die Teilesortierung 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 die Geräteermittlung und die Dienstermittlung. WSDAPI entspricht R1013. Die Hostingimplementierung entspricht R1001, aber WSDAPI erzwingt diese Empfehlung nicht auf dem Client.

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

Zur Erleichterung der Ermittlung und Bindung unterstützt WSDAPI R1009 und R1016. Per R1018 ignoriert WSDAPI Multicast UDP nicht an die anonyme Adresse. R1015, R1021 und R1022 definieren eine HTTP-Bindung für die Probenachricht, die WSDAPI wie beschrieben unterstützt.

DPWS 5.0 Beschreibung

WSDAPI erzwingt R2044 auf dem Client. Auf der Hostingseite stellt WSDAPI nur das wsx:Metadata Element im SOAP-Umschlagtext bereit. R2045 ermöglicht Geräten die Unterstützung einer Teilmenge der WS-Transfer- Funktionalität. Die Hosting-API generiert immer den wsa:ActionNotSupported Fehler.

DPWS 5.1 Merkmale

DPWS beschreibt grundlegende Merkmale für das Gerät. Zusätzlich zu den in diesem Thema beschriebenen Einschränkungen werden Längengrenzwerte für bestimmte Zeichenfolgen und URIs definiert. WSDAPI erzwingt die Längenbeschränkungen 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 das Durchlaufen der Metadatenversion. Die Clientimplementierung erzwingt das Vorhandensein der Metadaten "ThisModel" und "ThisDevice". Die Hostingimplementierung verwaltet auch die Metadatenversion ordnungsgemäß und stellt immer diese Abschnitte bereit, die R2038, R2012, R2001, R2039, R2014 und R2002 einhalten.

DPWS 5.2 Hosting

In diesem Abschnitt wird die Hierarchie der Dienst- und Beziehungsmetadaten beschrieben. WSDAPI erzwingt nicht die Eindeutigkeit der ServiceId, wie in diesem Abschnitt auf client- oder geräteseitiger Seite 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 WSDAPI ordnungsgemäß akzeptiert. R2030 und R2042 beschreiben die Verwaltung der Metadatenversion, die ordnungsgemäß in der Hosting-API implementiert wird.

DPWS 5.3 WSDL

Wenn ein Dienst Webdienstbeschreibungssprache (Web Services Description Language, WSDL)-Daten bereitstellt, können Clientimplementierungen die Dienstdefinition abrufen und den Dienst unterwegs 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 es nicht, und der Client stellt kein spät gebundenes Programmiermodell bereit. Die Hostingimplementierung kann verwendet werden, um WSDL bereitzustellen, der Host ist jedoch nicht erforderlich, da die Metadaten auf Dienstebene nicht vom Host selbst verwaltet werden.

DPWS 5.4 WS-Policy

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

DPWS 6.0-Ereignis

DPWS 6.1-Abonnement

DPWS erfordert Unterstützung für die Pushübermittlung. WSDAPI implementiert push delivery on the service side, also complianceing with R3009 and R3010, and will only accept the Push delivery mode on the client side. R3017 und R3018 erfordern spezifische Fehler vom Dienst, wenn die NotifyTo- oder EndTo Adressen nicht erkannt werden. WSDAPI überprüft diese Adressen nicht vorab und generiert diese Fehler nicht. Die Clientimplementierung erkennt diese Fehler jedoch richtig. Ebenso ist R3019 optional, und WSDAPI implementiert diese Empfehlung nicht, aber die Clientimplementierung erkennt die SubscriptionEnd Nachricht ordnungsgemäß und benachrichtigt die Anwendung eines Zustellungsfehlers.

DPWS 6.1.1 Filterung

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

Dauer und Verlängerung des DPWS 6.2-Abonnements

WSDAPI entspricht R3005, R3006 und R3016. WSDAPI verwendet immer xs:duration, akzeptiert aber xs:dateTime, falls angegeben, und stellt daher den optionalen Fehler in R3013 nicht aus. WSDAPI unterstützt GetStatus und gibt den wsa:ActionNotSupported Fehler pro R3015 nicht aus. WSDAPI akzeptiert den wsa:ActionNotSupported Fehler, wenn ein Dienst auf eine GetStatus Anforderung reagiert.

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 von anderen Spezifikationen entsprechend den Geräten. 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, werden an die in DPWS definierten Konstanten gebunden, nicht an die in WS-Discovery-definierten Konstanten.