Conformité aux spécifications WS-Discovery

WS-Discovery décrit comment effectuer les tâches suivantes :

• Annoncer la disponibilité des services sur le sous-réseau local
• Rechercher des services sur le sous-réseau
• Rechercher un service précédemment référencé

Pour ce faire, WS-Discovery définit deux messages unidirectionnels, Hello et Bye, et deux messages de recherche bidirectionnelle, Probe et Resolve.

WS-Discovery fournit également des adresses et un port réservé pour la découverte locale de liaison IPv4 et IPv6. La spécification permet également de définir d’autres liaisons ailleurs, telles que la liaison Probe over HTTP définie dans le profil d’appareils pour les services web (DPWS).

La spécification WS-Discovery décrit les fonctionnalités électives en utilisant les termes MAY ou SHOULD dans une recommandation ou restriction d’implémentation donnée. La fonctionnalité omise peut être une fonctionnalité décrite comme OBLIGATOIRE dans la spécification WS-Discovery 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 WS-Discovery.

Cette rubrique décrit comment les restrictions WS-Discovery, les exigences et les fonctionnalités facultatives sont gérées par l’implémentation WSDAPI. Il est préférable de lire cette rubrique en parallèle avec la spécification WS-Discovery.

prise en charge des WS-Discovery et SOAP-over-UDP

Dans SOAP-over-UDP, la section 3.2 spécifie que le message UDP doit tenir dans un datagramme de 64 Ko. WSDAPI accepte 64 000 messages UDP, mais la contrainte DPWS de MAX_ENVELOPE_SIZE (32 Ko) limite la taille du message. Comme requis par WS-Discovery, WSDAPI prend en charge les modèles de message décrits dans la section 4.

WSDAPI peut être configuré pour prendre en charge le modèle de sécurité dans les sections 7 et 8. Lorsqu’il est configuré, WSDAPI signe les messages WS-Discovery sortants et valide les signatures sur les messages entrants.

WSDAPI implémente l’algorithme de retransmission défini à l’Annexe I tel que modifié par DPWS Annexe I.

Dans WS-Discovery, WSDAPI utilise les adresses spécifiées dans la section 2.4. WSDAPI étend APP_MAX_DELAY de la section 2.4, mais pas dans la mesure définie dans l’annexe I du DPWS. Pour plus d’informations sur APP_MAX_DELAY, consultez Fonctionnalités de WS-Discovery supplémentaires.

WS-Discovery décrit la uuid: recommandation de format d’URI dans la section 2.6, mais WSDAPI remplace cette recommandation. Au lieu de cela, WSDAPI utilise le format d’URI urn:uuid: décrit dans DPWS.

La section 3 de WS-Discovery décrit comment un client interagit avec un proxy de découverte. WSDAPI ne reconnaît pas cette interaction et ignore les annonces des proxys de découverte. Dans Windows 7, WSDAPI implémente une extension privée au protocole WS-Discovery, WS-Discovery extensions distantes, pour permettre aux clients de découverte de rechercher des services répartis sur de nombreux réseaux différents en envoyant des requêtes aux proxys centralisés. Pour plus d’informations, consultez Fonctionnalités WS-Discovery supplémentaires.

La section 4.1, paragraphe 3 de WS-Discovery exige qu’un minuteur s’écoule avant l’envoi d’un message Hello . L’API d’hébergement n’attend pas avant d’envoyer un message Hello. Si un scénario nécessite un délai avant l’envoi d’un message Hello, le développeur de l’application doit implémenter une attente.

WSDAPI implémente tous les messages décrits dans WS-Discovery sections 4, 5 et 6. WSDAPI applique également les MATCH_TIMEOUT décrites dans la section 7 telle que modifiée par l’annexe I de DPWS. WSDAPI protège uniquement contre la « relecture » des considérations relatives à la sécurité dans la section 9.

WSDAPI implémente le séquencement des applications comme décrit dans WS-Discovery Annexe I.