Conformité à la spécification DPWS
Cette rubrique décrit comment WSDAPI implémente la fonctionnalité élective dans la spécification DpWS (Devices Profile for Web Services ). Il décrit également quelle fonctionnalité DPWS a été omise de l’implémentation WSDAPI.
La spécification DPWS fournit un moyen cohérent de communiquer avec les appareils. Il ajoute également des restrictions et des recommandations spécifiques qui simplifient le processus de prise en charge des services web sur le matériel incorporé.
La spécification DPWS décrit les fonctionnalités électives en utilisant les termes MAY ou SHOULD dans une recommandation ou restriction d’implémentation donnée. Les fonctionnalités omises peuvent être décrites comme ÉTANT REQUISEs dans la spécification DPWS qui n’a pas été implémentée par WSDAPI, ou il peut s’agir d’une fonctionnalité implémentée par WSDAPI dans une méthode autre que celle spécifiée dans la spécification DPWS.
Cette rubrique suit la disposition du DPWS section par section. Chaque section décrit comment les restrictions, les exigences et les fonctionnalités facultatives spécifiques sont gérées par l’implémentation WSDAPI. Il est préférable de lire cette rubrique en tandem avec la spécification DPWS.
Messagerie DPWS 3.0
Formats d’URI DPWS 3.1
Les restrictions R0025 et R0027 limitent les URI à MAX_URI_SIZE octets. WSDAPI applique ces deux restrictions comme spécifié.
Messagerie UDP DPWS 3.2
La recommandation R0029 suggère que les paquets UDP supérieurs à l’unité de transfert maximale (MTU) pour UDP ne doivent pas être envoyés. WSDAPI n’implémente pas cette recommandation et permettra aux implémentations d’envoyer et de recevoir des messages de découverte plus volumineux que le MTU.
Messagerie HTTP DPWS 3.3
R0001 exige que les services prennent en charge le transfert en bloc. WSDAPI accepte les données segmentées dans les messages de requête et envoie des données segmentées dans les messages de requête.
R0012 et R0013 décrivent les parties requises de la liaison HTTP SOAP. Pour R0012, WSDAPI implémente la liaison HTTP SOAP, mais ne commencera pas à lire la réponse HTTP tant que WSDAPI n’aura pas terminé d’envoyer la requête HTTP. WSDAPI implémente le modèle d’échange de messages requis dans R0013, implémente le nœud SOAP de réponse facultatif dans R0014 et n’implémente pas la fonctionnalité de méthode web facultative dans R0015. WSDAPI prend également en charge les exigences de R0030 et R0017.
Enveloppe SOAP DPWS 3.4
WSDAPI prend en charge R0034 et applique R0003 et R0026 par défaut. Plus précisément, conformément à R0003 et R0026, si WSDAPI reçoit une enveloppe SOAP supérieure à MAX_ENVELOPE_SIZE via HTTP, elle est rejetée et la connexion est fermée.
DPWS 3.5 WS-Addressing
R0004 reflète l’utilisation recommandée de l’API d’appareil dans WSDAPI et est pris en charge par l’API cliente dans WSDAPI. Étant donné qu’il s’agit d’une recommandation, WSDAPI permettra aux clients et aux appareils d’utiliser des URI autres que urn:uuid des URI pour leurs points de terminaison d’appareil afin d’assurer une compatibilité maximale. Étant donné que l’API d’appareil dans WSDAPI ne conserve pas l’état entre les initialisations, il appartient aux développeurs d’applications qui utilisent l’API d’appareil dans WSDAPI de s’assurer que R0005 et R0006 sont correctement pris en charge. L’API cliente dans WSDAPI suppose que les identités d’appareil sont uniques et persistantes, et les fonctionnalités générées sur l’API cliente dans WSDAPI (telles que PnP-X) l’exigent pour reconnaître correctement l’appareil entre les redémarrages d’appareil.
R0007 recommande de ne pas utiliser de propriétés de référence dans les références de point de terminaison. WSDAPI reconnaît toujours et accepte les points de terminaison avec des propriétés de référence, et les développeurs peuvent choisir de les utiliser, mais par défaut WSDAPI ne les remplit pas dans les points de terminaison qu’il crée. De même, avec R0042, lorsque WSDAPI crée des points de terminaison de service, il utilise une adresse de transport HTTP ou HTTPS, mais ne nécessite pas que les appareils utilisent des adresses de transport HTTP ou HTTPS dans leurs points de terminaison de service. Le comportement du client lors de la tentative de communication avec un service qui n’utilise pas HTTP ou HTTPS n’est pas défini.
En cas d’erreur, R0031 contraint le point de terminaison de réponse et décrit l’erreur à envoyer si l’erreur n’est pas anonyme. WSDAPI force le point de terminaison de réponse à utiliser la valeur correcte lors de l’envoi de messages et est défectueux correctement si WSDAPI reçoit un message de requête avec le point de terminaison de réponse incorrect. R0041 donne aux implémentations la possibilité de supprimer une erreur si le point de terminaison de réponse n’est pas valide. Au lieu de supprimer l’erreur, WSDAPI renvoie l’erreur sur le canal de requête, adressée au point de terminaison anonyme, comme « meilleur effort » pour communiquer avec le client.
Enfin, il existe deux restrictions sur les en-têtes SOAP, R0019 et R0040, que WSDAPI respecte et applique aux messages reçus.
Pièces jointes DPWS 3.6
WSDAPI prend en charge les pièces jointes et est conforme à R0022. WSDAPI est également conforme à R0037. Lors de l’envoi de pièces jointes, WSDAPI définit toujours l’encodage de transfert de contenu sur « binaire » pour toutes les parties MIME. Toutefois, WSDAPI n’applique pas R0036. Le comportement de WSDAPI lors de la réception d’un composant MIME avec un encodage de transfert de contenu non défini sur « binaire » n’est pas défini.
DPWS définit également les clauses d’ordre des parties MIME. Pour R0038, WSDAPI applique l’ordre des parties et rejette un message MIME si l’enveloppe SOAP n’est pas la première partie MIME. Pour R0039, WSDAPI envoie toujours l’enveloppe SOAP comme première partie MIME.
Découverte DPWS 4.0
R1013 et R1001 différencient la découverte d’appareils et la découverte de service. WSDAPI est conforme à R1013. L’implémentation d’hébergement est conforme à R1001, mais WSDAPI n’applique pas cette recommandation au client.
DPWS fournit également des conseils sur les types et les règles de correspondance d’étendue. WSDAPI prend en charge toutes les règles de correspondance d’étendue définies dans WS-Discovery , à l’exception de LDAP. WSDAPI fournit également un modèle extensible pour définir des règles de correspondance d’étendue personnalisées, conforme ainsi à R1019. L’API d’hébergement fournit également toujours le wsdp:Device type de découverte par R1020, mais l’API cliente n’exige pas qu’il soit présent. D’autres applications basées sur WSDAPI, telles que PnP-X, ont une exigence matérielle pour que le type soit présent dans la wsdp:Device découverte.
Pour faciliter la découverte et la liaison, WSDAPI prend en charge R1009 et R1016. Selon R1018, WSDAPI ignore la multidiffusion UDP non envoyée à l’adresse anonyme. R1015, R1021 et R1022 définissent une liaison HTTP pour le message Probe, que WSDAPI prend en charge comme décrit.
DPWS 5.0 Description
WSDAPI applique R2044 sur le client. Côté hébergement, WSDAPI ne fournira jamais que l’élément dans le wsx:Metadata corps de l’enveloppe SOAP. R2045 permet aux appareils de prendre en charge un sous-ensemble de la fonctionnalité WS-Transfer . L’API d’hébergement génère toujours l’erreur wsa:ActionNotSupported .
Caractéristiques de DPWS 5.1
DPWS décrit les caractéristiques de base de l’appareil. En plus des restrictions décrites dans cette rubrique, des limites de longueur sont définies pour des chaînes et DES URI spécifiques. WSDAPI applique les limites de longueur de cette section 5.1 DPWS, soit avant l’envoi du message, soit après l’analyse de son contenu.
DPWS décrit également les sections de métadonnées requises et le cycle de la version des métadonnées. L’implémentation du client applique la présence des métadonnées ThisModel et ThisDevice. L’implémentation d’hébergement gère également correctement la version des métadonnées et fournit toujours ces sections, conformes à R2038, R2012, R2001, R2039, R2014 et R2002.
Hébergement DPWS 5.2
Cette section décrit la hiérarchie des services et des métadonnées de relation. WSDAPI n’applique pas l’unicité du ServiceId comme décrit dans cette section côté client ou côté appareil.
WSDAPI est conforme à R2040, et il est possible pour l’implémentation d’hébergement d’envoyer une réponse de métadonnées sans section de relation s’il n’existe aucun service hébergé. L’implémentation du client accepte correctement la réponse de métadonnées.
R2029 autorise plusieurs sections de relation dans une réponse de métadonnées, que WSDAPI acceptera correctement. R2030 et R2042 décrivent la gestion de la version des métadonnées, qui est implémentée correctement dans l’API d’hébergement.
DPWS 5.3 WSDL
Si un service fournit des données WSDL (Web Services Description Language), les implémentations clientes peuvent obtenir la définition du service et manipuler le service à la volée. Il est utilisé par les clients liés en retard. L’implémentation du client WSDAPI accepte WSDL fourni à partir d’un service, mais le client ne le valide pas et le client ne fournit pas de modèle de programmation lié en retard. L’implémentation d’hébergement peut être utilisée pour fournir WSDL, mais l’hôte n’est pas tenu de le faire, car les métadonnées de niveau de service ne sont pas gérées par l’hôte lui-même.
DPWS 5.4 WS-Policy
DPWS décrit les assertions de stratégie à utiliser pour les appareils. Étant donné que WSDAPI ne fournit pas et n’interprète pas WSDL, il ne peut pas reconnaître et appliquer la stratégie incorporée dans les données WSDL.
Événements DPWS 6.0
Abonnement DPWS 6.1
DPWS nécessite la prise en charge de la livraison Push. WSDAPI implémente la livraison push côté service, conforme ainsi aux normes R3009 et R3010, et n’accepte que le mode de remise Push côté client. R3017 et R3018 nécessitent des erreurs spécifiques du service s’il ne reconnaît pas les NotifyTo adresses ou EndTo . WSDAPI ne valide pas ces adresses à l’avance et ne génère pas ces erreurs. Toutefois, l’implémentation du client reconnaît correctement ces erreurs. De même, R3019 est facultatif et WSDAPI n’implémente pas cette recommandation, mais l’implémentation du client reconnaît correctement le SubscriptionEnd message et notifiera l’application d’un échec de remise.
Filtrage DPWS 6.1.1
WSDAPI est conforme à R3008 et implémente le Action filtre. Conformément à R3011 et R3012, WSDAPI ne génère pas les erreurs dans les conditions spécifiées. WSDAPI implémente également l’erreur décrite R3020 s’il ne reconnaît pas les actions sur lesquelles il est invité à filtrer.
Durée et renouvellement de l’abonnement DPWS 6.2
WSDAPI est conforme à R3005, R3006 et R3016. WSDAPI utilise xs:duration toujours mais accepte xs:dateTime s’il est fourni, et n’émet donc pas l’erreur facultative dans R3013. WSDAPI prend en charge GetStatus et n’émet pas l’erreur wsa:ActionNotSupported par R3015. WSDAPI accepte l’erreur wsa:ActionNotSupported si un service répond à une GetStatus demande avec lui.
Sécurité DPWS 7.0
DPWS décrit un modèle de sécurité recommandé pour les appareils. WSDAPI n’implémente pas ces recommandations comme décrit et n’applique pas les restrictions de cette section comme décrit.
DpWS Annexe I
DPWS modifie les constantes globales d’autres spécifications pour les adapter aux appareils. WSDAPI utilise les constantes de cette section et remplace les constantes par défaut dans l’implémentation WS-Discovery par ces constantes. Les applications utilisant WSDAPI pour WS-Discovery seront liées aux constantes définies dans DPWS, et non aux constantes définies dans WS-Discovery.