Présentation de l’architecture des services web et de ses spécifications

 

Version 2.0

Octobre 2004

Auteurs

Luis Felipe Cabrera
Christopher Kurt
Don Box

Avis de copyright

© 2004 . Tous droits réservés.

Résumé: Cette introduction à l’architecture des services Web décrit les principes de conception sous-jacents de l’architecture et les technologies fondamentales pour les services Web. Les fonctionnalités sont décrites et liées aux spécifications qui les définissent formellement. Ce document sert également de guide de référence à toutes les spécifications de l’architecture. (51 pages imprimées)

Statut

Le contenu de ce livre blanc reflète les caractéristiques des différentes spécifications des services Web aux niveaux de révision actuels à la date de publication. À mesure que les spécifications des services Web sont affinées et que d’autres spécifications sont publiées, ce document sera mis à jour pour refléter les modifications les plus récentes.

Contenu

Introduction
   Message-Orientation
   Composabilité du protocole
   Services autonomes
   Transparence managée
   intégration Protocol-Based
Architecture des services web
Messagerie principale
   XML et l’ensemble d’informations
   SOAP
   Modèles d’échange de messages
   Indépendance du transport
   Addressing
Métadonnées
Sécurité
   Intégrité et confidentialité des messages
   Approbation basée sur les jetons de sécurité
   Sessions sécurisées
   Politiques de Sécurité
   Fédérations système
Découverte
   Répertoires
   Découverte dynamique
Protocoles de coordination des accords – Messagerie et transactions fiables
   Messagerie fiable
   Coordinateurs désignés
Énumération, transfert et événements
   Énumération
   Transférer
   Événements
Gestion
Remarques finales
Remerciements
Annexe A : Glossaire
Annexe B : Éléments d’informations d’ensemble d’informations XML
Annexe C : Attaques de sécurité courantes
Annexe D : Références
   Spécifications principales
   Spécifications des services web
   Profils d’interopérabilité
   Autres ressources

Introduction

Le Web a été un succès phénoménal en permettant des interactions simples entre ordinateurs et humains à l’échelle d’Internet. La pile de protocoles HTTP [HTTP] et HTML [HTML] d’origine utilisées par les navigateurs Web d’aujourd’hui s’est avérée être un moyen rentable de projeter des interfaces utilisateur sur un large éventail d’appareils. Un facteur clé dans la réussite de HTTP et HTML a été leur simplicité relative: HTTP et HTML sont principalement basés sur du texte et peuvent être implémentés à l’aide de divers systèmes d’exploitation et environnements de programmation.

Les services Web prennent bon nombre des idées et des principes du Web et les appliquent aux interactions ordinateur/ordinateur. Comme le World Wide Web, les services Web communiquent à l’aide d’un ensemble de protocoles de base qui partagent une architecture commune et sont destinés à être réalisés dans une variété de systèmes développés et déployés indépendamment. À l’instar du World Wide Web, les protocoles de services Web doivent beaucoup à l’héritage textuel d’Internet et sont conçus pour superposer aussi proprement que possible sans dépendances indues au sein de la pile de protocoles.

L’étendue est un domaine important dans lequel les services Web diffèrent du World Wide Web. HTTP et HTML ont été conçus autour de la navigation interactive « en lecture principalement » du contenu qui est souvent statique, ou du moins hautement mis en cache. En revanche, l’architecture des services Web est conçue pour des interactions de programme à programme hautement dynamiques. Dans l’architecture des services Web, de nombreux types de systèmes distribués peuvent être implémentés. Par exemple, les systèmes de messagerie synchrones et asynchrones, les clusters de calcul distribués, les systèmes en réseau mobile, les systèmes de grille et les environnements d’égal à égal. Le large éventail d’exigences dans les interactions de programme à programme force la pile de protocoles des services Web à être beaucoup plus à usage général que les premiers protocoles Web. Toutefois, à l’instar du web, les services Web s’appuient sur un petit nombre de protocoles spécifiques. Nous en discuterons plus longuement plus tard.

Nous prévoyons que la prochaine génération d’applications standard sera basée sur des services Web autonomes. Les implications de l’autonomie sont au cœur de l’architecture, et elles seront explorées tout au long de ce document. Le contenu technique de ce document décrit les protocoles d’infrastructure définissant l’architecture des services Web et un concept clé nécessaire pour créer des applications distribuées autonomes : le concept de contrats.

Les principes de base qui ont piloté la conception et l’implémentation des protocoles d’architecture de service Web sont les suivants :

• Orientation des messages : utiliser uniquement des messages pour communiquer entre les services et se rendre compte que les messages ont souvent une vie au-delà d’un événement de transmission donné.
• Composabilité de protocole : éviter les monolithes grâce à l’utilisation de blocs de construction de protocole d’infrastructure qui peuvent être utilisés dans presque toutes les combinaisons.
• Services autonomes : permettant aux points de terminaison d’être générés, déployés, gérés, versionnés et sécurisés de manière indépendante.
• Transparence managée : contrôle des aspects d’un point de terminaison qui sont (et ne sont pas) visibles par les services externes.
• Intégration basée sur le protocole : restriction du couplage entre applications aux artefacts de fil uniquement.

Le reste de cette section décrit ces principes en détail.

Message-Orientation

Les services web communiquent à l’aide de messages. Ils mettent l’accent sur la façon dont les messages individuels sont formés et traités. Contrairement aux systèmes RPC dans lesquels les messages sont strictement subordonnés à l’expérience de programmation locale, l’architecture des services Web est créée avec les messages comme unité atomique de communication. Cela s’applique non seulement au format de fil utilisé pour les échanges de messages (SOAP [SOAP]), mais aussi aux descriptions d’un service Web donné (WSDL [WSDL]). Certes, certains développeurs peuvent choisir d’afficher un service Web à l’aide de la métaphore d’appel de procédure distante ; Toutefois, cette décision est locale dans le code de ce développeur et n’est pas visible sur le réseau.

Les services web considèrent SOAP comme la couche la plus basse de la pile de protocoles et isolent le transfert des messages des détails de transport. Dans l’idéal, les liaisons spécifiques au protocole ne fuient pas dans la sémantique de l’application. Cette approche fournit une base solide pour atteindre l’interopérabilité des services entre les plateformes de développement et fournit des modèles de communication plus riches. Les services web s’appuient généralement sur HTTP comme transport de message sous-jacent. En tirant parti de l’extensibilité ouverte de HTTP POST, de nombreux services Web ont été démarrés à l’aide de technologies Web prêtes à l’emploi. À mesure que des applications plus sophistiquées des services Web émergent, l’importance des autres transports devient évidente. Par exemple, il est fastidieux, au mieux, d’implémenter des échanges de messages duplex complets sur la discipline stricte de requête/réponse http. En revanche, l’envoi de messages SOAP via TCP [TCPIP] à l’aide d’un protocole d’encadrement léger permet à n’importe quel modèle d’échange de messages à deux parties d’être implémenté de manière triviale.

Les services web peuvent distribuer le traitement d’un message donné sur plusieurs nœuds réseau, chacun d’entre eux contribuant à certaines fonctionnalités, telles que les vérifications d’accès, le routage basé sur le contenu ou la validation spécifique à l’application. Ce modèle de traitement distribué implique qu’un message donné peut avoir besoin de parcourir deux ou plusieurs transports de messages avant d’arriver au récepteur final. Pour cette raison, la plupart des premiers travaux de protocole dans les services Web étaient axés sur la fourniture de bout en bout de messages sécurisés et fiables sur des transports arbitraires. Pour les déploiements les plus simples dans un domaine d’approbation unique où un transport sécurisé et fiable est disponible (par exemple, TLS [TLS] sur TCP ou HTTP), des protocoles plus robustes tels que WS-Security [WS-Security] ou WS-ReliableMessaging [WS-RM] sont facultatifs. Pour les déploiements plus riches, ces derniers protocoles sont essentiels.

Composabilité de protocole

Les protocoles sont dits de composer lorsqu’ils peuvent être utilisés indépendamment ou en combinaison. De nombreux protocoles de communication spécifiques à un domaine sont en fait des « silos » dans lesquels les concepteurs de protocoles se retrouvent à créer de nouveaux mécanismes pour gérer la sécurité, la fiabilité, le signalement d’erreurs, etc. Étant donné la large applicabilité des services web, cette approche de la définition d’un protocole entier pour chaque domaine vertical s’interrompt lorsque les domaines se chevauchent et devient extrêmement coûteuse en termes de développement initial et de coûts de support continus.

Pour éviter ces coûts, la suite de protocoles de services Web est conçue comme une famille de blocs de construction de protocole composables. Par conception, chacun des protocoles d’infrastructure définit une unité de fonctionnalité affinée. Par exemple, les principes de base de la signature et du scellement du contenu des messages sont suffisamment génériques pour être spécifiés une seule fois (dans WS-Security), puis exploités par différents protocoles d’infrastructure et protocoles au niveau de l’application.

La composition du protocole de service web est basée sur l’architecture modulaire de SOAP. L’architecture SOAP anticipe la composition des protocoles d’infrastructure grâce à l’utilisation d’un mécanisme d’en-tête flexible. L’un des avantages de cette approche est que la surface de protocole d’une application particulière est basée sur les fonctionnalités réelles utilisées par cette application. Un protocole donné n’impose absolument aucun coût aux applications qui ne l’utilisent pas. Les logiciels fonctionnant sur des appareils informatiques de différentes échelles peuvent utiliser les protocoles exacts dont ils ont besoin, ce qui optimise l’applicabilité de l’architecture. Un deuxième avantage est que de nouveaux protocoles peuvent être introduits à tout moment pour compléter ceux existants et étendre les fonctionnalités. La capacité d’innovation est donc intégrée à l’architecture. Le défi d’obtenir une vue cohérente et complète de l’éventail des protocoles disponibles est réel. Relever ce défi est l’objectif de ce document.

Des profils de spécification sont fournis pour définir les contraintes d’utilisation et les meilleures pratiques d’utilisation de ces spécifications dans différentes combinaisons. Pour plus d’informations sur des profils spécifiques, consultez la section sur les profils d’interopérabilité, le profil de sécurité de base WS-I et le profil d’appareil pour les services web.

Services autonomes

Les services web sont des agents autonomes dont le développement, le déploiement, l’exploitation, la gestion et la sécurité varient tous indépendamment de ceux du consommateur du service. Cette « indépendance forcée » a plusieurs ramifications importantes qui imprégnent l’architecture.

L’autonomie du service a des implications profondes sur la façon dont le contrôle de version est implémenté. À mesure que l’implémentation d’un service évolue, des changements dans l’univers des applications compatibles consommatrices sont inévitables. Disposer d’outils raisonnables pour gérer ces modifications est essentiel au bon fonctionnement des systèmes basés sur les services Web. Au niveau le plus basique, SOAP fournit un modèle d’évolution de protocole basé sur les en-têtes SOAP. Les en-têtes SOAP sont censés être ajoutés ou supprimés dans un format de message donné pendant la durée de vie d’un protocole donné. À mesure que de nouveaux en-têtes sont introduits, la stratégie de mise à niveau est effectuée dans l’en-tête lui-même. Les en-têtes qui peuvent être ignorés en toute sécurité sont simplement insérés dans le message. Les en-têtes qui ne peuvent pas être ignorés en toute sécurité sont annotés avec un attribut mustUnderstand , ce qui indique que leur insertion est une modification cassante et que seuls les destinataires qui reconnaissent l’en-tête peuvent traiter le message. Ce modèle de base pour l’extensibilité est le plus visible dans SOAP lui-même ; toutefois, il est mis en miroir dans divers autres protocoles de service Web, y compris WSDL. Plus important encore, ce principe est utilisé par les services web pour ajouter de nouvelles fonctionnalités de protocole (par exemple, la sécurité) à un format de messagerie unique (SOAP). En fin de compte, la principale fonctionnalité de SOAP est l’extensibilité: les nouvelles versions de SOAP ne sont pas nécessaires pour chaque nouvelle exigence de protocole.

La nature autonome des services nécessite également une plus grande importance sur la gestion explicite de la confiance entre les applications. Étant donné que de nombreux services ont des adresses réseau visibles à partir de l’Internet public, un plus grand degré de prudence est nécessaire pour s’assurer que les agents malveillants ne peuvent pas compromettre l’intégrité d’un service. Une partie de ce soin prend la forme d’une validation d’entrée plus forte, qui peut souvent être automatisée à l’aide de différents langages de schéma. Un aspect plus intéressant de cette attention accrue à l’intégrité du système est l’utilisation de modèles d’approbation explicites. Une fonctionnalité clé des systèmes basés sur WS-Security est qu’un message donné peut contenir plusieurs jetons de sécurité. Certains de ces jetons peuvent correspondre à des identités d’utilisateur ou des principaux. D’autres jetons peuvent correspondre à des droits accordés à un utilisateur ou à une application spécifique et peuvent être validés par chiffrement dans le cadre d’un schéma d’autorisation plus large.

Les services autonomes doivent également garder le contrôle sur les ressources qu’ils gèrent. En particulier, ils doivent recycler les ressources créées par les demandes de services qui n’interagiront plus. Des stratégies de récupération des ressources sont nécessaires pour tous les types de ressources. Un schéma populaire est l’utilisation de baux comme illustré par les abonnements pour la notification d’événement plus loin dans ce document. La messagerie asynchrone permet aux services d’avoir un contrôle local complet sur la planification du traitement des messages. Les services disposent également d’une flexibilité en ce qui concerne les transmissions de messages, la gestion de la connectivité et les modes d’échec indépendants.

Enfin, la nature autonome des services Web nécessite invariablement des processus ou des systèmes qui étaient à un moment centralisés pour passer à un modèle fédéré. Cela est vrai non seulement pour les identités de sécurité, mais aussi pour les répertoires de service et la gestion des systèmes. Ces nouveaux systèmes doivent fonctionner correctement en présence de latences de message non liées, de modes d’échec indépendants et lorsque les services sont connectés de manière intermittente au réseau.

Transparence managée

Tous les détails d’implémentation sont privés à un service. La façade orientée message que chaque service expose fournit une isolation suffisante des choix d’implémentation effectués par un développeur de service particulier. Cette opacité est essentielle à l’autonomie du service et permet la flexibilité des modèles de programmation, des systèmes d’exploitation et d’autres détails d’implémentation. Il permet également de remplacer une implémentation de service par une autre. Dans l’idéal, tant que les deux services répondent au même ensemble de messages de requête avec des résultats comparables, le demandeur n’est pas plus sage qu’une implémentation différente d’un service ait été utilisée.

Étant donné l’accent mis sur les services autonomes, il est quelque peu ironique que les services Web mettent beaucoup l’accent sur la transparence des informations spécifiques à la mise en œuvre. Par exemple, si un service était complètement opaque, on ne pouvait pas dire si l’ensemble des messages d’entrée acceptés par le service A était similaire ou différent de ceux acceptés par le service B. Pour cette raison, les services sont censés rendre leurs aspects visibles publiquement transparents pour le monde extérieur. Cette transparence est obtenue grâce à l’utilisation de contrats, de descriptions lisibles par machine des messages qu’un service envoie ou reçoit, ainsi que des fonctionnalités abstraites et des exigences du service.

Les descriptions de service public sont essentielles pour créer un écosystème riche pour les outils et les environnements d’exécution, et jouent un rôle important dans l’interopérabilité entre les systèmes hétérogènes. Les outils de développement s’appuient sur des descriptions de service afin de créer des liaisons de langage adaptées aux programmeurs pour les messages qu’un service accepte ou envoie. Les outils de déploiement s’appuient sur des descriptions de service pour connecter un service déployé à une ou plusieurs adresses de point de terminaison visibles publiquement. Les outils de gestion s’appuient sur des descriptions de service pour déterminer si un service donné fonctionne dans sa collection attendue de messages d’entrée et de sortie. Enfin, la liaison au runtime d’un demandeur à un service donné peut tirer parti des descriptions de service pour s’assurer qu’un service compatible est sélectionné pendant l’exécution normale d’une application.

La transparence managée s’applique non seulement aux descriptions des services, mais également aux messages eux-mêmes. Contrairement aux protocoles monolithiques du passé, SOAP et WS-Security ensemble fournissent une couche de sécurité flexible dans laquelle différentes parties d’un message peuvent avoir des caractéristiques de sécurité distinctes. Cela signifie que l’expéditeur peut choisir de laisser certains aspects du message complètement transparents et visibles pour tous les lecteurs potentiels, tout en chiffrant d’autres parties du message pour qu’un ensemble de lecteurs de confiance puisse voir uniquement. Dans le cas général, chaque partie de message peut être chiffrée pour un ensemble distinct de lecteurs. Les parties de message qui ne sont pas chiffrées peuvent être signées pour les protéger contre la falsification.

intégration Protocol-Based

L’intégration d’application est simplifiée lorsque des protocoles basés sur des messages sont utilisés pour toutes les communications. En créant un système autonome pour la description et la messagerie dépourvu de langage de programmation ou de détails du système d’exploitation, les services web ont montré qu’il est possible pour les applications s’exécutant dans des environnements vraiment disparates de communiquer de manière sécurisée et fiable. La seule façon de faire fonctionner cela était de supposer qu’il n’y a pas de système d’exploitation partagé, pas de machine virtuelle partagée et pas de langage de programmation partagé ou d’abstraction. L’indépendance vis-à-vis de la technologie d’implémentation sous-jacente est la clé de l’interopérabilité des services web. Les services web ont influencé de nombreux aspects du développement logiciel. La principale contribution des services Web a été l’accent mis sur l’intégration de logiciels basés sur des protocoles.

L’influence de l’intégration basée sur les protocoles sur l’industrie dans son ensemble se voit dans l’accent mis de plus en plus sur les architectures orientées service. Les services web et l’orientation des services doivent beaucoup aux idées de logiciels de composants, d’objets distribués et d’intergiciels orientés message. L’encapsulation d’informations et le polymorphisme ont été adoptés à partir de l’orientation objet, et l’utilisation obligatoire d’interfaces et l’utilisation des métadonnées d’exécution ont été adoptées à partir du logiciel de composant. Les objets distribués ont apporté des notions de contexte qui circulent entre les entités et les liaisons basées sur un répartiteur. Bien sûr, le middleware orienté message a apporté l’utilisation de files d’attente, de relais. et la transmission explicite de messages.

Les services web communiquent à l’aide d’un ensemble concret de protocoles basés sur une architecture commune avec SOAP comme base. En revanche, l’orientation de service est un ensemble abstrait d’idées et de concepts qui peuvent se manifester de plusieurs manières (tout comme l’orientation objet avant elle).

Les services Web peuvent être utilisés pour implémenter un système orienté service, mais l’orientation du service ne nécessite pas l’utilisation de protocoles de service Web, et l’utilisation de protocoles de service Web ne garantit pas que la conception globale du système est orientée service. Cela dit, Microsoft investit massivement pour faire de la combinaison des services Web et de l’orientation des services une partie importante de Windows.

L’adoption généralisée des architectures orientées service s’accélère en raison de plusieurs facteurs sous-jacents. L’infrastructure réseau est désormais omniprésente, ce qui permet une communication d’ordinateur à ordinateur économique. Les systèmes créés à partir de services web fournissent une approche de développement logiciel qui permet d’incorporer des applications héritées dans des étapes incrémentielles. Enfin, l’autonomie du service offre des applications plus robustes.

Cette introduction a présenté les main les activateurs, les motivations, les exigences et les principes qui guident l’architecture des services Web. Le reste du document présente les principales technologies qui sous-tendent l’architecture, suivi d’une visite guidée de la collection de spécifications qui définissent les services Web.

Architecture des services web

Le reste de ce document fournit une introduction détaillée à l’architecture des services Web. Nous examinons les composants des services Web et les mécanismes sur lesquels ils s’appuient pour prendre en charge la conception de l’architecture. Chaque fonctionnalité de l’architecture est présentée dans le contexte des spécifications où elle est définie.

Messagerie principale

Cette section présente les principales spécifications utilisées pour formuler des messages dans l’architecture des services Web : XML, SOAP et WS-Addressing [WS-Addressing]. Les services web s’appuient sur XML pour le modèle de données sous-jacent de base, SOAP pour le traitement des messages et le modèle de données, et WS-Addressing pour l’adressage des services et l’identification des messages indépendamment du transport.

XML et l’ensemble d’informations

Pour tous les systèmes de messagerie, la sélection de l’unité de transfert d’informations est une décision importante. En termes simples, une compréhension commune de ce qui constitue exactement un message est nécessaire. Dans les services Web, un message est un élément d’informations de document XML tel que défini par l’ensemble d’informations XML, ou Infoset, [XML-Infoset]. L’ensemble d’informations est un modèle de données abstrait qui est compatible avec le xml texte 1.0 [XML-10] et constitue la base de toutes les spécifications XML modernes (schéma XML [XML-Schema], XML Query [XML-Query] et XSLT 2.0 [XSLT-20]). En basant l’architecture des services Web sur l’ensemble d’informations XML plutôt que sur un format de représentation spécifique, l’architecture et les principaux composants du protocole sont compatibles avec d’autres encodages.

L’ensemble d’informations modélise un document XML en fonction d’un ensemble d'« éléments d’information ». L’ensemble d’éléments d’informations possibles est généralement mappé aux différentes fonctionnalités d’un document XML, telles que les éléments, les attributs, les espaces de noms et les commentaires. Chaque élément d’information est associé à un ensemble de propriétés qui fournissent une description plus complète de l’élément. Les onze types d’éléments d’information d’un document XML sont décrits dans l’annexe B. Chaque document XML bien formé se compose exactement d’un élément d’informations de document et d’au moins un élément d’information d’élément.

En plus de l’encodage purement textuel de l’Infoset, l’architecture des services Web prend également en charge un encodage Infoset qui permet d’entrelacer des données binaires opaques avec le balisage textuel traditionnel. Le format W3C XML-binary Optimized Packaging (ou XOP [XOP]) utilise mime [MIME] en plusieurs parties pour permettre l’inclusion de données binaires brutes dans un document XML 1.0 sans recourir à l’encodage en base64. Une spécification complémentaire, SOAP Message Transmission Optimization Method, ou MTOM, [MTOM], spécifie ensuite comment lier ce format à SOAP. XOP et MTOM sont l’approche préférée pour mélanger des fichiers binaires bruts avec du code XML textuel et remplacent le soap désormais déprécié par les pièces jointes (SwA) et WS-Attachments/DIME.

SOAP

SOAP fournit un mécanisme simple et léger pour l’échange d’informations structurées et typées entre homologues dans un environnement décentralisé et distribué à l’aide de XML. SOAP a été conçu pour réduire autant que possible le coût d’ingénierie de l’intégration d’applications basées sur différentes plateformes en supposant que la technologie la plus économique a les meilleures chances d’obtenir l’acceptation universelle. Un message SOAP est un élément d’informations de document XML qui contient trois éléments : <Enveloppe>, <En-tête> et <Corps>.

Envelope est l’élément racine du message SOAP et contient un élément Header facultatif et un élément Body obligatoire. L’élément Header est un mécanisme générique permettant d’ajouter des fonctionnalités à un message SOAP de manière décentralisée. Chaque élément enfant de Header est appelé bloc d’en-tête, et SOAP définit plusieurs attributs connus qui peuvent être utilisés pour indiquer qui doit traiter un bloc d’en-tête (rôle) et si son traitement est facultatif ou obligatoire (mustUnderstand), les deux décrits ci-dessous. Lorsqu’il est présent, l’élément Header est toujours le premier élément enfant de l’enveloppe. L’élément Body est toujours le dernier élément enfant de l’enveloppe et est un conteneur pour la « charge utile » destinée au destinataire final du message. SOAP lui-même ne définit aucun bloc d’en-tête intégré et une seule charge utile, qui est l’élément Fault utilisé pour signaler les erreurs.

Tous les messages des services Web sont des messages SOAP qui tirent pleinement parti de l’ensemble d’informations XML. Le fait que la charge utile du message et les en-têtes de protocole utilisent le même modèle pour garantir l’intégrité des en-têtes d’infrastructure ainsi que des corps d’application. Les applications peuvent acheminer des messages en fonction du contenu des en-têtes et des données contenues dans le message. Les outils qui ont été développés pour le modèle de données XML peuvent être utilisés pour inspecter et construire des messages complets. Ces avantages n’étaient pas disponibles dans les architectures telles que DCOM, CORBA et RMI, où les en-têtes de protocole étaient des détails d’infrastructure opaques pour l’application.

Les messages SOAP sont transmis unidirectionnel de l’expéditeur au destinataire. Plusieurs messages unidirectionnel peuvent être combinés en modèles plus sophistiqués. Pour instance, un modèle populaire est une paire de messages de demande/réponse synchrone.

Tout agent logiciel qui envoie ou reçoit des messages est appelé nœud SOAP. Le nœud qui effectue la transmission initiale d’un message est appelé expéditeur d’origine. Le nœud final qui consomme et traite le message est appelé récepteur final. Tout nœud qui traite le message entre l’expéditeur d’origine et le destinataire final est appelé intermédiaire. Les intermédiaires sont utilisés pour modéliser le traitement distribué d’un message individuel. La collection de nœuds intermédiaires parcourus par le message et le récepteur final sont collectivement appelés chemin d’accès du message.

Pour permettre d’identifier des parties du chemin d’accès du message, chaque nœud participe à un ou plusieurs rôles. Les rôles SOAP sont un schéma de catégorisation qui associe un nom [RFC1630] basé sur un URI à des fonctionnalités abstraites (par exemple, mise en cache, validation, autorisation). La spécification SOAP de base définit deux rôles intégrés : Next et UltimateReceiver. Suivant est un rôle universel en ce que chaque nœud SOAP autre que l’expéditeur appartient au rôle Suivant. UltimateReceiver est le rôle que joue le nœud de terminal dans un chemin de message. Il s’agit généralement de l’application, ou dans certains cas, de l’infrastructure qui effectue un travail pour le compte de l’application.

Le corps d’une enveloppe SOAP est toujours ciblé sur le récepteur ultime. En revanche, les en-têtes SOAP peuvent cibler les intermédiaires ou le récepteur final. Pour fournir un modèle sécurisé et pouvant être versionnable pour le traitement des messages, SOAP définit trois attributs qui contrôlent la façon dont les intermédiaires et le récepteur final traitent un bloc d’en-tête donné : role, relay et mustUnderstand. L’attribut de rôle est utilisé pour identifier le nœud ciblé par le bloc d’en-tête. L’attribut mustUnderstand indique si ce nœud peut ignorer le bloc d’en-tête s’il n’est pas reconnu. Les blocs d’en-tête marqués mustUnderstand="true » sont appelés blocs d’en-tête obligatoires. Les blocs d’en-tête marqués mustUnderstand="false » ou qui n’ont pas d’attribut mustUnderstand sont appelés blocs d’en-tête facultatifs. L’attribut relais indique si ce nœud doit transférer des en-têtes facultatifs non reconnus ou les ignorer.

Chaque nœud SOAP doit utiliser ces trois attributs pour implémenter le modèle de traitement SOAP. Les étapes suivantes définissent ce modèle :

1. Identifiez tous les blocs d’en-tête du message SOAP destiné au nœud SOAP actuel à l’aide de l’attribut role (l’absence de cet attribut implique que le bloc d’en-tête est destiné au récepteur final).
2. Vérifiez que tous les blocs d’en-tête obligatoires identifiés à l’étape 1 peuvent être traités par le nœud SOAP actuel à l’aide de l’attribut mustUnderstand SOAP. Si un bloc d’en-tête obligatoire ne peut pas être traité par le nœud SOAP actuel, le message doit être ignoré et un message d’erreur distingué doit être généré.
3. Traitez le message. Les éléments de message facultatifs peuvent être ignorés.
4. Si le nœud SOAP n’est pas le récepteur final du message, tous les blocs d’en-tête identifiés à l’étape 1 qui ne sont pas relayables sont supprimés et le message est ensuite relayé vers le nœud SOAP suivant dans le chemin du message. Le nœud SOAP est libre d’insérer de nouveaux blocs d’en-tête dans le message relayé. Certains de ces blocs d’en-tête peuvent être des copies de blocs d’en-tête identifiés à l’étape 1.

Le modèle de traitement SOAP est conçu pour permettre l’extensibilité et le contrôle de version. L’attribut mustUnderstand contrôle si l’introduction d’un nouveau bloc d’en-tête est une modification cassant ou non cassant. L’ajout de blocs d’en-têtes facultatifs (par exemple, les en-têtes marqués mustUnderstand="false ») est un changement non cassant, car tout nœud SOAP est libre de l’ignorer. L’ajout de blocs d’en-têtes obligatoires (par exemple, les en-têtes marqués mustUnderstand="true ») est un changement cassant, car seuls les nœuds SOAP qui connaissent la syntaxe et la sémantique du bloc d’en-tête peuvent traiter le message. Les attributs de rôle et de relais composent avec mustUnderstand pour distribuer ce modèle de traitement le long d’un chemin de message.

Modèles d’échange de messages

La flexibilité de messagerie fournie par SOAP permet aux services de communiquer à l’aide de divers modèles d’échange de messages, répondant aux exigences des applications distribuées. Nous exploitons plusieurs d’entre eux dans les blocs de construction de base de l’architecture. Plusieurs modèles se sont avérés particulièrement utiles dans les systèmes distribués. L’utilisation d’appels de procédure distante, par exemple, a popularisé le modèle d’échange de messages de demande/réponse synchrone. Lorsque les latences de remise des messages ne sont pas contrôlées, une messagerie asynchrone est nécessaire. Lorsque le modèle de requête/réponse asynchrone est utilisé, la corrélation explicite des messages devient obligatoire.

La diffusion transporte des transmissions de messages un-à-plusieurs popularisées. L’expéditeur d’origine qui impose ses messages aux destinataires en les envoyant simplement est appelé modèle push. Bien que ce modèle soit efficace dans les réseaux locaux, il n’est pas bien mis à l’échelle sur les réseaux étendus et n’offre pas aux destinataires une option pour réguler le flux des messages.

Un autre modèle utile est basé sur la capacité d’une application à exprimer son intérêt pour des types particuliers de messages, ce qui rend le modèle de publication/abonnement très populaire. En s’abonnant explicitement à des sources de messages (ou à des rubriques), les applications disposent d’un flux plus contrôlé d’informations pertinentes.

Le modèle de tirage est utilisé lorsqu’un destinataire demande explicitement un message à partir d’une source. Cela rend le flux de messages responsable de la responsabilité du destinataire. Le modèle de tirage peut également être combiné avec publier/s’abonner. Il convient parfaitement aux situations où les destinataires peuvent être déconnectés par intermittence des sources.

Indépendance du transport

SOAP est défini indépendamment du mécanisme de transport de messagerie sous-jacent utilisé. Il permet l’utilisation de nombreux transports alternatifs pour l’échange de messages et autorise le transfert et le traitement de messages synchrones et asynchrones.

Un exemple de système qui nécessite à la fois plusieurs transports et une messagerie asynchrone est celui qui communique entre un service Web sur une base de réseau terrestre et à haut débit et un service Web connecté par intermittence hébergé sur un téléphone cellulaire. Un tel système nécessite qu’un seul message circule sur différents transports en fonction du tronçon réseau entre lequel le message se déplace. Un tel système montre également un exemple où la latence de remise des messages ne peut pas être déterminée avec précision. Au lieu d’essayer de déterminer ou de lier la latence de remise des messages, le développeur de service web doit créer le système en supposant que la pleine puissance de la transmission de messages asynchrones est totale. Contrairement à l’utilisation d’appels de procédure distante, la messagerie asynchrone permet à l’expéditeur de continuer à traiter après chaque transmission de message sans être obligé de bloquer et d’attendre une réponse. Bien sûr, les modèles de requête-réponse synchrones peuvent être basés sur la base de la messagerie asynchrone.

Étant donné que les protocoles de service Web sont conçus pour être complètement indépendants du transport sous-jacent, la sélection du mécanisme approprié peut être différée jusqu’à l’exécution. Cela permet aux applications de service web de déterminer le transport approprié lors de l’envoi du message. En outre, le transport sous-jacent peut changer à mesure que le message est acheminé entre les nœuds, et là encore, le mécanisme sélectionné pour chaque tronçon peut varier en fonction des besoins.

Malgré cette indépendance générale du transport, la plupart des services Web de première génération communiquent à l’aide de HTTP, car il s’agit de l’une des liaisons principales incluses dans la spécification SOAP. HTTP utilise TCP comme protocole de transport sous-jacent. Toutefois, la conception de TCP introduit une surcharge de traitement qui n’est pas toujours nécessaire. Plusieurs modèles de protocole d’application correspondent plus étroitement à la sémantique du protocole de datagramme utilisateur ou UDP [UDP]. Ces modèles sont particulièrement utiles pour les appareils et autres systèmes à ressources limitées.

UDP ne dispose pas des garanties de remise de TCP ; il fournit une messagerie de datagramme au meilleur effort. Il nécessite également moins de ressources à implémenter que TCP. En outre, UDP fournit des fonctionnalités multi-cast, ce qui permet à un expéditeur de transmettre simultanément un message à plusieurs destinataires. Les spécifications pour lier des messages SOAP à UDP sont publiées dans SOAP-over-UDP [SOAP-UDP].

Addressing

Pour que les messages soient acheminés et traités dans ce monde multi-transport, un mécanisme commun est nécessaire pour que les propriétés de messagerie critiques soient transportées sur plusieurs transports. La spécification WS-Addressing définit trois ensembles de blocs d’en-tête SOAP à cet effet.

Le bloc d’en-tête Action est utilisé pour indiquer le traitement attendu d’un message. Ce bloc d’en-tête contient un URI unique qui est généralement utilisé par le destinataire final pour distribuer le message en vue de son traitement.

Les blocs d’en-tête MessageID et RelatesTo sont utilisés pour identifier et mettre en corrélation les messages. Les en-têtes MessageID et RelatesTo utilisent des URI simples pour identifier les messages de manière unique. Ces URI sont généralement des UUID temporaires.

Les blocs d’en-tête To/ReplyTo/FaultTo sont utilisés pour identifier les agents qui doivent traiter le message et ses réponses. Ces en-têtes s’appuient sur une structure définie par WS-Addressing appelée référence de point de terminaison qui regroupe les informations nécessaires pour traiter correctement un message SOAP.

Les références de point de terminaison sont l’aspect le plus important de l’adressage WS, car elles prennent en charge l’adressage plus précis qu’un SIMPLE URI. Ils sont largement utilisés dans l’architecture des services Web. Les références de point de terminaison contiennent trois informations critiques : une adresse de base et des ensembles facultatifs de propriétés de référence et de paramètres de référence. L’adresse de base est un URI utilisé pour identifier un point de terminaison et apparaît dans le bloc d’en-tête To de chaque message SOAP ciblé sur ce point de terminaison. Les propriétés de référence et les paramètres de référence sont des collections d’éléments XML arbitraires utilisés pour compléter l’adresse de base en fournissant des informations de routage ou de traitement supplémentaires pour le message. Ils sont représentés en tant qu’éléments d’en-tête littéral. Lorsque vous utilisez une référence de point de terminaison pour construire un message pour le point de terminaison, l’expéditeur est responsable d’inclure toutes les propriétés de référence et paramètres de référence comme blocs d’en-tête.

La distinction entre les propriétés de référence et les paramètres de référence réside dans la façon dont ils sont liés aux métadonnées d’un service. La stratégie et le contrat d’un service Web sont basés uniquement sur son adresse de base et ses propriétés de référence. En règle générale, l’adresse de base et les propriétés de référence identifient un service déployé donné et les paramètres de référence sont utilisés pour identifier des ressources spécifiques gérées par ce service.

Les propriétés et paramètres de référence sont simplement des éléments XML opaques qui sont censés être traités uniquement par le récepteur final. Ils permettent de s’assurer que les informations qui peuvent être utilisées pour la distribution, le routage, l’indexation ou d’autres activités de traitement côté expéditeur sont incluses dans un message donné. Bien que les intermédiaires ne soient pas censés traiter ces informations, il est possible que certains intermédiaires, tels que les pare-feu ou les services de passerelle, utilisent certaines propriétés ou paramètres de référence pour le routage et/ou le traitement des messages.

Il existe de nombreuses utilisations pour les propriétés de référence. Deux exemples simples sont les classes d’identificateurs de service et d’entité privée. Dans l’exemple de classe de service, les propriétés de référence peuvent être utilisées pour différencier un service Web pour les clients standard et un service « gold » qui fournit une qualité de service supérieure et des fonctionnalités améliorées (éventuellement par le biais d’opérations supplémentaires ou de liaisons supplémentaires) formant logiquement deux points de terminaison différents. Les propriétés telles que celles-ci ne sont définies qu’une seule fois dans une session, puis réutilisées tout au long du reste de l’interaction. Un deuxième type d’utilisation d’une propriété de référence est un mécanisme permettant d’identifier un client d’une manière privée au système d’origine. Une combinaison de ces deux types de propriétés de référence peut permettre une distribution efficace des messages vers la collection appropriée de serveurs et la recherche efficace de l’état de l’application qui concerne un utilisateur particulier. Ces exemples montrent également comment les données qui font référence à des instances de services et les données qui font référence à des instances d’utilisateurs peuvent être représentées dans des propriétés de référence.

En particulier, les propriétés de référence permettent également d’adresser des collections d’entités WSDL qui partagent une URL et une étendue communes. WSDL, le format XML permettant de décrire les services Web en tant qu’ensemble de points de terminaison fonctionnant sur des messages, spécifie d’abord ses entités de manière abstraite, puis les lie concrètement à des instances spécifiques. En particulier, les messages et les opérations sont définis de manière abstraite et sont ensuite liés à un point de terminaison avec des informations de transport réseau et de format de message. Par conséquent, du point de vue de WSDL, lorsque vous ciblez différentes entités concrètes, telles que les messages d’entrée ou de sortie, les liaisons portType, les ports ou les services dans un service Web à l’aide d’une URL commune, les propriétés de référence du point de terminaison correspondantes doivent être différentes. WSDL est présenté plus en détail dans la section Métadonnées.

Deux exemples d’utilisation de paramètres de référence sont infrastructurel et au niveau de l’application. Un exemple d’infrastructure d’un paramètre de référence peut être un ID de transaction/inscription envoyé à un moniteur de traitement des transactions. Dans un scénario d’achat de livre, le numéro ISBN d’un livre peut être un exemple au niveau de l’application d’un paramètre de référence.

Métadonnées

Toutes les interactions du service Web sont effectuées en échangeant des messages SOAP comme décrit dans la section précédente. Pour fournir un environnement de développement et opérationnel robuste, les services sont décrits à l’aide de métadonnées lisibles par machine. Les métadonnées permettent l’interopérabilité. Les métadonnées de service web servent à plusieurs fins. Il est utilisé pour décrire les formats d’échange de messages que le service peut prendre en charge et les modèles d’échange de messages valides d’un service. Les métadonnées sont également utilisées pour décrire les fonctionnalités et les exigences d’un service. Cette dernière forme de métadonnées est appelée stratégie d’un service. Les formats d’échange de messages et les modèles d’échange de messages sont exprimés en WSDL. Les stratégies sont exprimées à l’aide de WS-Policy. Les contrats sont exprimés à l’aide des trois types de métadonnées décrits ci-dessus. Les contrats sont des abstractions qui isolent les applications des détails d’implémentation interne des services sur lesquels elles s’appuient.

Le langage de description du service web, ou WSDL, a été le premier mécanisme largement adopté pour décrire les caractéristiques de base d’un service Web. Les messages décrits dans WSDL sont regroupés en opérations qui définissent les modèles de message de base. Les opérations sont regroupées en interfaces appelées ports qui spécifient un contrat abstrait pour un service. Enfin, les ports et les liaisons sont utilisés pour associer des portTypes à des transports concrets et des informations de déploiement physique. Une description WSDL est une première étape pour identifier automatiquement toutes les caractéristiques du service cible et activer les outils de développement logiciel.

WSDL spécifie ce qu’un message de requête doit contenir et à quoi ressemblera le message de réponse en notation non ambiguë. La notation qu’un fichier WSDL utilise pour décrire les formats de message est basée sur le schéma XML. Cela signifie qu’il est à la fois neutre en langage de programmation et basé sur des normes, ce qui le rend approprié pour décrire les interfaces de service accessibles à partir d’un large éventail de plateformes et de langages de programmation. En plus de décrire le contenu des messages, WSDL peut définir l’emplacement où le service est disponible et le protocole de communication utilisé pour communiquer avec le service. Cela signifie que le fichier WSDL peut spécifier les éléments de base nécessaires pour écrire un programme afin d’interagir avec un service Web. Plusieurs outils sont disponibles pour lire un fichier WSDL et générer le code nécessaire pour produire des messages syntactiquement corrects pour un service Web.

Bien que WSDL soit un bon point de départ, il ne suffit pas de décrire tous les aspects d’un service Web. WSDL autorise uniquement l’expression d’un ensemble assez petit de propriétés. Voici des exemples d’informations plus détaillées nécessaires pour les services Web :

• Caractéristiques opérationnelles : le service prend en charge SOAP version 1.2.
• Caractéristiques de déploiement : le service n’est disponible qu’entre 9 h et 17 h.
• Caractéristiques de sécurité : des tickets Kerberos [KERBEROS] sont requis pour accéder au service.

Les services Web de première génération doivent échanger des métadonnées hors bande à l’aide de protocoles propriétaires. Ce problème est résolu avec WS-Policy [stratégie WS]. WS-Policy fournit un modèle et une syntaxe à usage général pour décrire et communiquer les stratégies d’un service Web. Il spécifie un ensemble de constructions de base qui peuvent être utilisées et étendues par d’autres spécifications de service Web pour décrire un large éventail d’exigences et de fonctionnalités de service. WS-Policy introduit une grammaire simple et extensible pour exprimer des assertions de stratégie et un modèle de traitement pour les interpréter. Les assertions peuvent être combinées en alternatives logiques.

Les assertions de stratégie permettent aux programmeurs d’ajouter des métadonnées appropriées aux informations de service au moment du développement ou au moment de l’exécution. Les exemples de stratégies de temps de développement incluent la taille maximale autorisée des messages ou la version exacte d’une spécification prise en charge. Les exemples de stratégies d’exécution incluent le temps d’arrêt obligatoire du service ou l’indisponibilité d’un service Web pendant une procédure administrative donnée, comme la maintenance régulière du matériel. Des exemples de stratégies liées à la sécurité sont présentés plus loin dans ce document.

Les assertions de stratégie individuelles peuvent être regroupées pour former des alternatives de stratégie. Les stratégies sont des collections d’alternatives de stratégie. Pour faciliter l’interopérabilité, les stratégies sont définies en termes de représentation de leur infoset XML. Un formulaire compact pour les stratégies est défini pour réduire la taille des documents de stratégie tout en préservant l’interopérabilité.

Les stratégies sont utilisées pour transmettre des conditions d’interaction entre deux points de terminaison de service Web. La satisfaction des assertions dans une stratégie entraîne généralement un comportement qui reflète ces conditions. Par conséquent, l’évaluation des assertions de stratégie est essentielle à l’identification des comportements compatibles. Une assertion de stratégie, le bloc de construction des stratégies, est prise en charge par un demandeur si et uniquement si le demandeur répond à la condition requise ou prend en charge la fonctionnalité correspondant à l’assertion. En général, cette détermination utilise des connaissances spécifiques au domaine. Une alternative de stratégie est prise en charge par un demandeur si et uniquement si le demandeur prend en charge toutes les assertions dans l’alternative. Cela est déterminé mécaniquement à l’aide des résultats des assertions de stratégie. En outre, une stratégie est prise en charge par un demandeur si et uniquement si le demandeur prend en charge au moins une des alternatives dans la stratégie. Cette détermination est également mécanique une fois que les options de politique ont été évaluées. Notez que bien que les alternatives de stratégie soient censées s’exclure mutuellement, il ne peut pas être décidé en général si plusieurs alternatives peuvent être prises en charge en même temps.

Pour transmettre une stratégie sous une forme interopérable, une expression de stratégie est une représentation d’infoset XML d’une stratégie. L’expression de stratégie de formulaire normal est l’ensemble d’informations le plus simple ; Équivalent, les autres ensembles d’informations permettent d’exprimer une stratégie de manière compacte par le biais d’un certain nombre de constructions. Les expressions de stratégie sont le bloc de construction de base des stratégies. Deux opérateurs sont utilisés pour exprimer leurs assertions : All et ExactlyOne. L’opérateur All spécifie que toutes les assertions présentes dans une collection d’alternatives de stratégie doivent être conservées pour que l’assertion de stratégie soit satisfaite. L’opérateur ExactlyOne spécifie qu’une des assertions présentes dans une collection d’alternatives de stratégie doit être conservée pour que l’assertion de stratégie soit satisfaite.

Les stratégies s’ajoutent aux descriptions WSDL et les augmentent. Les stratégies sont associées aux métadonnées de services Web, telles que les définitions WSDL ou les entités UDDI [UDDI] via l’utilisation de WS-PolicyAttachment [WS-PA]. Les stratégies peuvent être associées à des ressources en tant que partie intrinsèque de leur définition, ou séparément. Les mécanismes sont définis pour chacune de ces fins. En particulier, les stratégies peuvent également être utilisées avec des messages SOAP individuels. Lorsque plusieurs pièces jointes de stratégie sont effectuées pour une entité, elles déterminent conjointement la stratégie effective pour l’entité. Il faut être prudent lors de l’attachement de stratégies à différents niveaux de la hiérarchie WSDL, car le résultat net pour chaque niveau d’une hiérarchie est la stratégie efficace. En règle générale, pour l’auto-description et la clarté compréhensible par l’homme, il est préférable d’être détaillé et de répéter une assertion de stratégie à chaque niveau d’une hiérarchie qu’elle applique, plutôt que d’être tertré et de s’appuyer sur le mécanisme qui calcule la stratégie efficace. Dans un document WSDL, un échange de messages avec un point de terminaison déployé peut contenir des stratégies efficaces dans les quatre types d’objets simultanément.

La combinaison de WS-Policy et de WS-PolicyAttachment offre une capacité accrue à découvrir et à raisonner par programmation les stratégies prises en charge par d’autres services. La flexibilité d’ajouter des stratégies est un complément important aux informations WSDL qui décrivent les interactions de message.

WSDL et WS-Policy définissent tous deux des formats pour les métadonnées, mais ne spécifient pas de mécanismes d’acquisition ou d’accès aux métadonnées pour un service donné. En général, les métadonnées de service peuvent être découvertes à l’aide de diverses techniques. Pour permettre aux services d’être autodescripteurs, l’architecture des services web définit des protocoles d’accès soap pour les métadonnées dans WS-MetadataExchange [WS-MEX]. L’opération GetMetadata est utilisée pour récupérer les métadonnées qui se trouvent à la référence de point de terminaison de la requête. L’opération Get est similaire, mais elle est conçue pour récupérer les métadonnées référencées dans une section de métadonnées et doit être récupérée au niveau de la référence de point de terminaison où elles sont stockées.

Les métadonnées échangées à l’aide de WS-MEX peuvent être décrites comme une ressource. Une ressource est définie comme toute entité adressable par une référence de point de terminaison où l’entité peut fournir une représentation XML d’elle-même. Les ressources constituent la base nécessaire pour créer la gestion de l’état dans les services Web.

Que sont les profils d’interopérabilité ?

Un profil est un ensemble d’instructions pour l’utilisation des spécifications des services Web au-delà des protocoles de base. Ces instructions sont nécessaires en raison de la conception à usage général de la spécification. Dans certains cas, les développeurs ont besoin d’aide supplémentaire pour déterminer les fonctionnalités des services Web qui doivent être utilisées pour répondre à une exigence particulière. Les profils d’interopérabilité résolvent également les ambiguïtés dans les domaines où les spécifications des services Web ne sont pas suffisamment claires pour garantir que toutes les implémentations traitent les messages SOAP de la même façon.

Profil de base WS-I

Les premiers profils de services Web ont été publiés par web Services-Interoperability Organization (WS-I) [WS-I]. WS-I a finalisé son premier profil, simplement intitulé Basic Profile 1.0 [WSI-BP10]. Ce profil fournit des conseils principalement sur l’utilisation interopérable de SOAP 1.1 et WSDL 1.0.

Sécurité

Cette section présente les spécifications utilisées dans l’architecture des services Web pour fournir l’intégrité des messages, l’authentification et la confidentialité, l’échange de jetons de sécurité, la sécurité de session de message, l’expression de stratégie de sécurité et la sécurité d’une fédération de services au sein d’un système. Les spécifications fournissant ces fonctionnalités sont WS-Security, WS-Trust [WS_Trust], WS-SecureConversation [WS-SecureConv], WS-SecurityPolicy [WS-SecurityPolicy] et WS-Federation [WS_Federation].

La sécurité est un aspect fondamental des systèmes informatiques, en particulier ceux constitués de services Web. La sécurité doit être robuste et efficace. Étant donné que les systèmes ne peuvent émettre que des hypothèses câblées sur le format des messages et des échanges de messages juridiques, la sécurité doit être fondée sur des mécanismes et des hypothèses explicites et convenus. L’infrastructure de sécurité doit également être suffisamment flexible pour prendre en charge la grande variété de stratégies de sécurité requises par différentes organisations.

Lorsqu’un transport sécurisé est disponible entre les services Web de communication, tels que SSL (Secure Sockets Layer) et TLS (Transport Layer Security), la création d’une solution sécurisée est simplifiée. Avec un transport sécurisé, les services ne doivent pas se préoccuper du maintien de l’intégrité et de la confidentialité des messages individuels; ils peuvent s’appuyer sur le transport sous-jacent. Toutefois, la sécurité existante au niveau du transport est une solution limitée uniquement à la messagerie point à point. Si des intermédiaires sont présents lors de l’utilisation d’un transport sécurisé, l’expéditeur initial et le destinataire final doivent faire confiance à ces intermédiaires pour assurer une sécurité de bout en bout, car chaque tronçon est sécurisé séparément. Outre la confiance explicite de tous les intermédiaires, d’autres risques tels que le stockage local des messages et le risque de compromission d’un intermédiaire doivent être pris en compte.

Pour optimiser la portée des services Web, une sécurité de bout en bout doit être fournie lorsque les intermédiaires ne sont pas approuvés par les points de terminaison de communication. Cela nécessite des protocoles de sécurité de niveau supérieur. La sécurité des messages de bout en bout est une alternative plus riche à la sécurité au niveau du transport point à point, car elle prend en charge l’environnement faiblement couplé, fédéré, multiport et extensible requis par les services web SOAP. Cette infrastructure puissante et flexible peut être développée à partir d’une combinaison de technologies et de protocoles de services Web existants tout en atténuant un grand nombre des risques de sécurité associés à la messagerie point à point.

Même si les exigences de sécurité pour les services Web sont complexes, aucun nouveau mécanisme de sécurité n’a été inventé pour répondre aux besoins de la messagerie soap. Les approches existantes en matière de sécurité des systèmes distribués, telles que les tickets Kerberos, les technologies de chiffrement à clé publique, les certificats X.509 [X509] et d’autres se sont avérées suffisantes. De nouveaux mécanismes étaient nécessaires uniquement pour appliquer ces approches de sécurité existantes à SOAP. Ces nouveaux protocoles de sécurité ont été conçus avec l’extensibilité à l’esprit afin de permettre l’intégration de nouvelles approches à l’avenir. Un objectif de conception principal était de fournir des mécanismes permettant d’auto-décrire les propriétés de sécurité conçues pour SOAP et le reste de l’architecture des services Web.

La sécurité des services web est basée sur l’exigence que les messages entrants prouvent un ensemble d’assertions faites sur un expéditeur, un service ou une autre ressource. Nous appelons ces revendications, ou assertions de sécurité. Parmi les exemples de revendications de sécurité, citons l’identité, les attributs, la possession de clé, les autorisations ou les fonctionnalités. Ces assertions sont encodées dans des jetons de sécurité binaires encapsulés au format XML. Dans la terminologie de sécurité traditionnelle, ces jetons de sécurité représentent une combinaison de fonctionnalités et de contrôles d’accès.

Différentes approches sont utilisées pour créer des jetons de sécurité. Un service Web peut créer un jeton de sécurité personnalisé à partir d’informations locales. Vous pouvez également récupérer un jeton de sécurité à partir de services spécialisés tels qu’une autorité de certification X.509 ou un contrôleur de domaine Kerberos. Pour automatiser la communication entre les services, un mécanisme d’expression des exigences de sécurité est nécessaire.

Les services peuvent exprimer leurs exigences de sécurité à l’aide d’assertions de stratégie spécifiées dans WS-SecurityPolicy. Cette spécification est décrite dans une sous-section ultérieure de ce document. En récupérant ces assertions de stratégie, une application peut générer des messages conformes aux exigences du service cible. Cette combinaison de fonctionnalités fournies par les revendications, les jetons de sécurité et les stratégies, et la possibilité de les récupérer à partir d’un service Web est puissante.

Le modèle de sécurité général des services Web prend en charge plusieurs modèles de sécurité plus spécifiques, tels que l’autorisation basée sur l’identité, les listes de contrôle d’accès et l’autorisation basée sur les fonctionnalités. Il permet d’utiliser des technologies existantes telles que les certificats de clé publique X.509, les jetons XML, les tickets de secret partagé Kerberos et les synthèses de mot de passe. Le modèle général est suffisant pour construire des systèmes qui utilisent des approches plus sophistiquées pour l’échange de clés de niveau supérieur, l’authentification, le contrôle d’accès basé sur des stratégies, l’audit et les relations d’approbation complexes. Les proxys et les services de relais peuvent également être utilisés. Par exemple, un service de relais peut être créé pour appliquer une stratégie de sécurité à une limite d’approbation ; Les messages qui sortent de la limite sont chiffrés tandis que ceux qui restent à l’intérieur de la limite ne sont pas chiffrés. Cette flexibilité et ce degré de sophistication ne sont pas présents dans les solutions précédentes.

Les attaques de sécurité courantes décrites dans l’Annexe C incluent une taxonomie de base des menaces système qui doivent être soigneusement prises en compte lors du choix des fonctionnalités de sécurité des services Web.

Le reste de cette section explore l’application du modèle de sécurité des services Web. Les deux sujets clés sont la sécurisation des communications et la sécurisation des applications. Un transport de messages sécurisé n’est pas supposé, pas plus qu’il n’est nécessaire pour des services Web sécurisés.

Intégrité et confidentialité des messages

La sécurité au niveau du message est le bloc de construction clé pour la sécurité de bout en bout. Lors de l’utilisation de la sécurité au niveau du message, aucune sécurité au niveau du transport n’est requise. Les exigences en matière de sécurité au niveau du message sont l’intégrité des messages, l’authentification des messages et la confidentialité. L’intégrité du message garantit qu’un message ne peut pas être modifié sans détection. L’utilisation de la signature XML [XMLSIG] garantit que les modifications de message peuvent être détectées.

L’authentification du message identifie le principal qui a envoyé le message. Si le chiffrement à clé publique est utilisé, l’identité unique du principal peut être déterminée. L’utilisation du chiffrement à clé publique avec des clés certifiées par une source approuvée fournit cette authentification. Toutefois, si le chiffrement par clé symétrique est utilisé, ce n’est pas le cas : seul le groupe de principaux qui connaissent le secret partagé peut être identifié.

La confidentialité des messages garantit qu’un message ne peut pas être lu par un tiers non autorisé lors de sa transmission. Les messages SOAP sont conservés confidentiels grâce à l’utilisation du chiffrement XML [XMLENC] conjointement avec des jetons de sécurité.

Les mécanismes d’intégrité, d’authentification et de confidentialité prennent le message d’origine (ou des parties du message) comme entrée, et les données appropriées au produit (telles qu’une somme de contrôle) comme sortie. Par exemple, la signature d’un élément XML peut, dans un cas simple, être implémentée en tant que chiffrement asymétrique d’un hachage de tous les caractères de l’élément XML. Ce hachage chiffré peut ensuite être stocké et transmis dans le message.

Les documents XML peuvent être considérés comme des chaînes de caractères. La comparaison caractère par caractère est une opération de sécurité critique, comme les signatures XML. Une différence d’un caractère est un résultat différent. La sérialisation est la méthode utilisée pour représenter des objets « sur le réseau ». Par exemple, la sérialisation est utilisée pour créer la représentation XML d’un message SOAP. Toutes les variations typographiques non essentielles produites par différents logiciels de sérialisation sont ignorées par les logiciels de traitement des messages, mais ont un impact significatif sur le logiciel de sécurité. La représentation Infoset d’un message XML améliore ce problème. Pour que les signatures XML fonctionnent, les messages doivent être transformés en un formulaire XML cohérent pour toutes les parties. La canonisation est le terme utilisé pour décrire la méthode utilisée pour produire une vue cohérente des informations non critiques telles que les sauts de ligne, les espaces de tabulation, l’ordre des attributs et le style des balises de fermeture. Les signatures incluent la méthode de canonisation utilisée pour permettre au destinataire d’un message de traiter les informations de sécurité d’une manière cohérente avec l’expéditeur. La méthode de canonisation spécifique utilisée par un service est une assertion de stratégie utile à placer sur une liaison portType WSDL ou un port WSDL.

WS-Security spécifie les mécanismes d’intégrité et de confidentialité des messages, ainsi que l’authentification à message unique. Pour l’intégrité du message, la spécification détaille la façon dont une signature de chiffrement est représentée et associée à des parties spécifiques du message SOAP. L’approche permet aux fragments arbitraires et bien formés du message d’avoir des signatures distinctes. De la même manière, la confidentialité est obtenue par le chiffrement de fragments bien formés du message. L’authentification est obtenue à l’aide de signatures numériques.

La spécification WS-Security décrit les mécanismes de sécurité courants utilisés aujourd’hui, mais n’empêche pas d’en ajouter de nouveaux à l’avenir. Étant donné que le modèle de traitement SOAP utilise les éléments d’en-tête pour prendre des décisions de traitement, vous devez faire preuve d’une grande prudence lors de la détermination des éléments d’un message SOAP à chiffrer.

Les concepteurs de services web doivent savoir comment le message sera traité pour décider quels éléments doivent être chiffrés et quels algorithmes de chiffrement utiliser. Ces décisions sont encore plus importantes lorsque des éléments d’en-tête spécifiques doivent être traités par des tiers ou des intermédiaires. Si ces parties ne sont pas au courant des données de déchiffrement appropriées ou des conventions utilisées pour chiffrer les éléments XML, elles ne pourront pas fonctionner correctement. En outre, chaque nœud de traitement doit avoir une compréhension commune des informations de sécurité incluses dans le message.

Un choix naturel pour chiffrer un élément XML dans un en-tête consiste à le chiffrer complètement, en remplaçant l’élément d’origine par un élément de type de données chiffrées. Cette approche simple présente des inconvénients. Les intermédiaires, par exemple, ont du mal à déterminer quels éléments doivent être traités (ceux ornés de l’attribut mustUnderstand="1 ». En outre, lorsque le type d’élément est modifié, il est difficile de déterminer son type d’origine.

Une autre approche consiste à transformer l’élément en un élément où tous les attributs clés nécessaires au traitement SOAP correct sont conservés et l’élément d’origine est chiffré et placé dans un sous-élément distingué. L’avantage de cette approche est que le traitement correct peut être effectué même par des intermédiaires qui ne savent pas comment déchiffrer l’élément. L’inconvénient de cette approche est qu’elle exige que la convention utilisée pour représenter l’élément d’origine soit comprise par toutes les parties. Même si WS-Security ne fournit pas d’orientation sur cette approche, nous nous attendons à ce que des travaux futurs le fassent. L’autre méthode est recommandée, car elle permet le traitement correct de tous les éléments d’en-tête SOAP.

Plusieurs types de jetons de sécurité sont décrits dans les spécifications de profil de WS-Security. Des profils ont été développés pour les jetons représentant des noms d’utilisateur, des certificats X.509 et des jetons de sécurité XML. Les jetons de sécurité xml incluent le langage SAML (Security Assertion Markup Language) [SAML] et le langage eXtensible Markup Language/Rights Expression Language (REL) [REL]. Des spécifications pour l’utilisation de tickets Kerberos sont également en cours de développement.

Profil de sécurité de base WS-I

L’un des profils d’interopérabilité les plus récents publiés par WS-I est le profil de sécurité de base (BSP) [WSI-BSP10]. Ce profil fournit des conseils d’implémentation pour WS-Security et divers jetons de sécurité, tels que username [WS-SecUsername] et les jetons de certificat X.509 [WS-SecX509]. Il est conçu pour compléter et composer avec le profil de base WS-I.

Approbation basée sur des jetons de sécurité

Les jetons de sécurité sont nécessaires pour fournir une solution de sécurité de bout en bout. Ces jetons de sécurité doivent être partagés, directement ou indirectement, entre les parties impliquées dans le traitement des messages. Chaque partie doit également déterminer si les informations d’identification déclarées peuvent être approuvées. Ces relations d’approbation sont basées sur l’échange et le brokering de jetons de sécurité et dans les stratégies d’approbation de prise en charge qui ont été établies. La quantité d’un jeton réparti approuvé, par exemple, est déterminée par les administrateurs système et les relations d’approbation qu’ils ont établies.

Les services qui fournissent des jetons de sécurité peuvent être très variés. C’est là que chacune des technologies de sécurité sous-jacentes est utilisée pour la première fois par un service Web. Afin de fournir une solution uniforme quelle que soit la technologie de sécurité, de nouveaux protocoles ont été conçus pour l’échange de jetons de sécurité entre les domaines d’approbation.

WS-Trust [WS-Trust] complète WS-Security par des protocoles pour la demande, l’émission et le répartiteur de jetons de sécurité. En particulier, les opérations d’acquisition, d’émission, de renouvellement et de validation des jetons de sécurité sont définies. Une autre caractéristique de la spécification est un mécanisme permettant de créer de nouvelles relations d’approbation. Les mécanismes de protection du réseau et du transport tels que IPsec ou TLS/SSL peuvent être utilisés conjointement avec WS-Trust pour différents scénarios et exigences de sécurité.

L’acquisition de jetons de sécurité peut être effectuée directement en demandant explicitement un jeton à un émetteur approprié, ou indirectement en déléguant l’acquisition à un tiers de confiance. Les jetons peuvent également être acquis hors bande. Par exemple, le jeton peut être envoyé d’une autorité de sécurité à une partie sans que le jeton ait été explicitement demandé. Pour compléter l’image, les administrateurs système déterminent les relations d’approbation initiales désignant, par exemple, un service donné en tant que service racine approuvé. Cette approche est similaire à ce qui est utilisé pour démarrer la sécurité sur le Web aujourd’hui. Tous les jetons obtenus à partir de ce service sont approuvés dans la même mesure que la racine approuvée elle-même. Par exemple, si une racine est approuvée uniquement pour les revendications A et B, et qu’un message contient les revendications A, B et C, seules les revendications A et B du message sont approuvées. La flexibilité de la configuration est fournie via la délégation de relation d’approbation.

Pour résoudre les scénarios dans lesquels un ensemble d’échanges entre les parties est nécessaire avant le retour ou l’émission d’un jeton de sécurité, des mécanismes sont spécifiés pour la validation, la négociation et l’échange. Une forme particulière d’échange appelée « défi » fournit un mécanisme permettant à une partie de prouver qu’elle possède un secret associé à un jeton. D’autres types d’échanges incluent le tunneling de protocole hérité. WS-Trust définit comment étendre la spécification des protocoles d’échange de jetons supplémentaires au-delà de ces deux exemples.

Les jetons de sécurité exprimant des revendications de sécurité sont émis par une racine approuvée ou par le biais d’une chaîne de délégation. Ces revendications de sécurité sont utilisées pour vérifier que le message est conforme aux stratégies de sécurité en place. Ils vérifient également que les attributs du demandeur sont prouvés par les signatures. Dans les modèles d’approbation réparti, c’est-à-dire ceux où un intermédiaire de confiance distribue des jetons de sécurité, la signature peut ne pas vérifier l’identité du demandeur, mais plutôt l’identité de l’intermédiaire. Cet intermédiaire peut simplement affirmer l’identité du demandeur.

Sessions sécurisées

Certains mécanismes d’authentification et de confidentialité des messages peuvent être coûteux en matière de calcul. En particulier, de nombreuses techniques de chiffrement consomment une puissance de traitement importante. Ces coûts sont généralement inévitables lorsque les messages sont sécurisés individuellement. Toutefois, lorsque deux services Web échangent de nombreux messages, des approches plus efficaces et plus robustes en matière de confidentialité des messages que celles définies dans WS-Security sont disponibles. Ces mécanismes, basés sur le chiffrement symétrique, doivent être utilisés lors de la sécurisation des sessions de messages.

WS-SecureConversation [WS-SecConv] définit un contexte de sécurité entre deux parties communiquantes basées sur des secrets partagés, tels que le chiffrement symétrique. Un contexte de sécurité est partagé entre les parties pendant la durée de vie d’une session. Les clés de session sont dérivées d’un secret partagé et sont utilisées pour déchiffrer les messages individuels envoyés dans la conversation. Le contexte de sécurité est représenté sur le réseau sous la forme d’un nouveau type de jeton de sécurité (le jeton de contexte de sécurité ou SCT).

Trois façons différentes d’établir un contexte de sécurité entre les parties d’une conversation sécurisée sont définies. Tout d’abord, un service de jeton de sécurité peut les créer, et la partie à l’origine doit les extraire pour les propager. Deuxièmement, l’une des parties qui communiquent crée le contexte de sécurité et le propage dans un message à l’autre partie. Troisièmement, le contexte de sécurité est créé par la négociation et les échanges. Les services web sélectionnent l’approche la plus adaptée à leurs besoins.

Les contextes de sécurité peuvent être modifiés si nécessaire. Un exemple d’exigence de mise à jour d’un contexte de sécurité est la nécessité d’étendre le délai d’expiration du contexte.

Un jeton de contexte de sécurité implique ou contient un secret partagé. Ce secret est utilisé pour la signature et/ou le chiffrement des messages. Lors de l’utilisation d’un secret partagé, les parties peuvent choisir un autre modèle de dérivation de clé à utiliser. Par exemple, quatre clés peuvent être dérivées afin que deux parties puissent signer et chiffrer à l’aide de clés distinctes. Afin de garder les clés à jour et de maintenir un niveau de sécurité élevé, des dérivations ultérieures doivent être utilisées. La sécurisation des sessions à l’aide de cette approche est recommandée. La spécification WS-SecureConversation définit un mécanisme pour indiquer quelle dérivation est utilisée dans un message donné. Chaque algorithme de dérivation est identifié avec un URI.

Politiques de Sécurité

WS-SecurityPolicy [WS-SecurityPolicy] complète WS-Security en spécifiant des assertions de stratégie de sécurité dans un langage conforme à WS-Policy. Ses six assertions concernent les jetons de sécurité, l’intégrité du message, la confidentialité des messages, la visibilité des messages pour les intermédiaires SOAP, les contraintes sur l’en-tête de sécurité et l’âge d’un message. Par exemple, une assertion de stratégie peut exiger que tous les messages soient signés à l’aide de clés publiques d’une autorité donnée, ou que l’authentification soit basée sur des tickets Kerberos.

Fédérations système

La sécurité des applications nécessite des mécanismes supplémentaires au-delà de ce que nous avons présenté jusqu’à présent. Les identités, par exemple, sont valides au sein d’un domaine d’approbation, mais très probablement vides de sens dans d’autres domaines d’approbation. Pour que les services de différents domaines d’approbation puissent valider des identités, des mécanismes appropriés sont nécessaires. WS-Federation définit des mécanismes pour activer le partage d’informations d’identité, de compte, d’attribut, d’authentification et d’autorisation entre les domaines d’approbation. En utilisant ces mécanismes, plusieurs domaines de sécurité peuvent se fédérer en autorisant et en répartitant la confiance des identités, des attributs et de l’authentification entre les services Web participants. La spécification étend le modèle WS-Trust pour permettre l’intégration d’attributs et de pseudonymes dans le mécanisme d’émission de jetons, ce qui aboutit à un mécanisme de mappage d’identités multi-domaines. Ces mécanismes prennent en charge l’authentification unique, la déconnexion et les pseudonymes, et décrivent le rôle des services spécialisés, pour les attributs et les pseudonymes.

Une grande variété d’exigences peut être traitée par le biais de la fédération d’identité. Par exemple, l’association d’un employé à son employeur. Dans ce cas, Jane, de CompanyA effectue un achat auprès de OfficeSupplyStore.com. CompanyA et OfficeSupplyStore.com ont un contrat d’achat. Étant donné que l’identité de Jane est associée à CompanyA, elle peut être autorisée à effectuer un achat en vertu du contrat.

Un deuxième exemple est le mappage d’une seule personne à plusieurs pseudonymes. Joe peut être connu au travail sous le nom joe@companya.comde . Il peut également avoir d’autres identités, telles que joe_bloggs@hotmail.com et josephb@cornell.edu. Grâce à la fédération des identités, les systèmes peuvent déterminer que chacune de ces identités est le même Joe.

Deux grandes classes de demandeurs (expéditeurs de messages) sont définies dans l’architecture de sécurité fédérée des services Web : passive et intelligente (active). Un demandeur passif [WS-FedPassive] est un service qui utilise uniquement HTTP et n’émet jamais de jetons de sécurité. Un demandeur intelligent est un service capable d’émettre des messages contenant des jetons de sécurité, tels que ceux décrits dans WS-Security et WS-Trust. Un navigateur web http traditionnel est un exemple de demandeur passif. Des spécifications de profil ont été développées pour définir les comportements de ces deux types de demandeurs.

Pour les demandeurs intelligents, le profil de demandeur actif [WS-FedActive] spécifie comment l’authentification unique, la déconnexion et les pseudonymes sont intégrés au modèle de sécurité des services Web à l’aide de messages SOAP. En effet, le profil décrit comment implémenter le modèle décrit dans WS-Federation dans le contexte des demandeurs intelligents. Il spécifie des exigences sur différents types de jetons de sécurité. À titre d’exemple d’une de ces exigences de jeton de sécurité, lorsque vous n’utilisez pas de canal sécurisé, les jetons pour les certificats X.509 doivent contenir le nom de l’autorité et une signature sur l’ensemble du jeton. Le profil nécessite également que les jetons X.509 contiennent l’identificateur d’objet identifiant de manière unique l’objet pour lequel le jeton a été accordé.

Découverte

Cette section présente les composants fonctionnels de l’architecture des services Web utilisés pour localiser les services Web sur un réseau et déterminer la disponibilité du service : UDDI et WS-Discovery [WS-Discovery].

La découverte de services web est un élément clé pour automatiser les connexions aux services sans intervention humaine. L’approche du service Web pour la découverte reflète les deux approches les plus courantes pour trouver des informations dans un système informatique : la recherche dans un emplacement connu ou la diffusion d’une demande à tous les écouteurs disponibles. Les registres UDDI servent de répertoire et les protocoles de découverte sont utilisés pour diffuser les demandes.

Répertoires

Le protocole UDDI (Universal Description, Discovery, and Integration Protocol) spécifie un protocole permettant d’interroger et de mettre à jour un répertoire commun d’informations de service Web. Le répertoire inclut des informations sur les fournisseurs de services, les services qu’ils hébergent et les protocoles que ces services implémentent. Le répertoire fournit également des mécanismes permettant d’ajouter des métadonnées à toutes les informations inscrites.

L’approche d’annuaire UDDI peut être utilisée lorsque les informations de service Web sont stockées dans des emplacements connus. Une fois le répertoire localisé, une série de demandes de requête peut être envoyée pour obtenir les informations souhaitées. Les emplacements de répertoire UDDI sont obtenus hors bande, généralement via des données de configuration système.

Les fournisseurs de services Web disposent de différentes options pour déployer des registres UDDI. Les scénarios de déploiement appartiennent à l’une des trois catégories suivantes : public, extra-entreprise et intra-entreprise. Pour prendre en charge les déploiements publics, un groupe de fournisseurs dirigés par Microsoft, IBM et SAP héberge le registre d’entreprise UDDI [UBR]. L’UBR est un registre UDDI public qui est répliqué dans plusieurs organisations d’hébergement, servant à la fois de ressource pour les services Web basés sur Internet et de banc de test pour les développeurs de services Web. Bien que l’implémentation publique de l’UDDI ait reçu le plus d’attention à ce jour, les utilisateurs précoces utilisent plus souvent l’approche extra-entreprise et intra-entreprise. Dans ces deux scénarios de déploiement, un registre privé est déployé par un organization et un contrôle beaucoup plus étroit sur les types d’informations inscrites est possible. Ces registres privés peuvent être dédiés à un seul organization ou à des groupes de partenaires commerciaux. UDDI définit également des protocoles pour la réplication entre les registres et pour la fédération d’approbation entre les déploiements. L’utilisation de ces protocoles augmente davantage le nombre de scénarios de déploiement disponibles pour les implémenteurs.

Pour tous les scénarios de déploiement, les répertoires UDDI contiennent des informations détaillées sur les services Web et leur emplacement d’hébergement. Une entrée d’annuaire UDDI comprend trois parties principales : le fournisseur de services, les services Web proposés et les liaisons aux implémentations. Chacune de ces parties fournit des informations progressivement plus détaillées sur le service Web.

Les informations les plus générales décrivent le fournisseur de services. Ces informations ne sont pas destinées aux logiciels de services Web, mais à un développeur ou à un implémenteur qui doit contacter directement une personne responsable du service. Les informations du fournisseur de services incluent les noms, les adresses, les contacts et d’autres détails administratifs. Toutes les entrées UDDI ont plusieurs éléments pour les descriptions multilingues.

La liste des services Web disponibles est stockée dans une entrée de fournisseur de services. Ces services peuvent être organisés en fonction de leur utilisation prévue : ils peuvent être regroupés en zone d’application, zone géographique ou tout autre schéma approprié. Les informations de service stockées dans un registre UDDI incluent simplement une description du service et un pointeur vers les implémentations de service Web qu’il contient. Les liens vers des services hébergés par d’autres fournisseurs, appelés « Projections de services », peuvent également être inscrits.

La dernière partie d’une entrée de fournisseur de services UDDI est la liaison à une implémentation. Cette liaison associe l’entrée de service Web aux URI exacts pour identifier l’endroit où le service est déployé, spécifie le protocole à utiliser pour l’accès et contient des références aux protocoles exacts implémentés.

Ces détails sont suffisants pour qu’un développeur écrive une application qui appelle le service Web. La définition de protocole détaillée est fournie par le biais d’une entité UDDI appelée modèle de type (ou tModel). Dans de nombreux cas, le tModel fait référence à un fichier WSDL décrivant l’interface du service Web SOAP, mais les tModels sont également suffisamment flexibles pour décrire presque n’importe quel type de ressource.

Pour chaque fournisseur ou service inscrit dans UDDI, des métadonnées supplémentaires provenant de taxonomies standard (telles que NAICS [NAICS] et les anciens codes de secteur SIC [SIC]) ou d’autres schémas d’identification (comme une clé d’index Edgar Central) peuvent être utilisées pour catégoriser les informations et améliorer la précision de la recherche. L’ensemble des taxonomies et des schémas d’identificateur disponibles est facilement extensible dans le cadre de n’importe quelle implémentation, de sorte qu’il peut être personnalisé pour prendre en charge des exigences géographiques, sectorielles ou d’entreprise spécifiques.

Découverte dynamique

La découverte du service Web dynamique est fournie d’une manière différente. En guise d’alternative au stockage d’informations dans un registre connu, les services Web découverts dynamiquement annoncent explicitement leur arrivée et leur départ du réseau. WS-Discovery définit des protocoles pour annoncer et découvrir des services Web via des messages de multidiffusion.

Lorsqu’un service Web se connecte à un réseau, il annonce son arrivée en envoyant un message Hello. Dans le cas le plus simple, ces annonces sont envoyées sur le réseau à l’aide de protocoles de multidiffusion. Nous appelons cela un réseau ad hoc. Cette approche réduit également le besoin d’interrogation sur le réseau. Afin de limiter la quantité de trafic réseau et d’optimiser le processus de découverte, un système peut inclure un proxy de découverte. Un proxy de découverte remplace la nécessité d’envoyer des messages de multidiffusion par un emplacement de service bien connu, transformant un réseau ad hoc en réseau managé. À l’aide des informations de configuration, les collections de services proxy peuvent être liées pour mettre à l’échelle le service de découverte sur des groupes de serveurs, en passant d’une machine à plusieurs.

Étant donné que les proxys de découverte sont eux-mêmes des services Web, ils peuvent annoncer leur présence avec leur propre message Hello spécial. Les services web recevant ce message peuvent alors tirer parti des services du proxy et ne sont plus obligés d’utiliser les protocoles de découverte un-à-plusieurs plus bruyants.

Lorsqu’un service quitte un réseau, WS-Discovery spécifie un message Bye à envoyer au réseau ou au proxy de découverte. Ce message informe les autres services du réseau que le service Web sortant n’est plus disponible.

Pour compléter cette approche de base de l’annonce et du départ du service, WS-Discovery définit deux opérations, Probe et Resolve pour localiser les services Web sur un réseau. Pour les réseaux ad hoc, les messages de sonde sont envoyés à un groupe de multidiffusion, et les services cibles qui correspondent à la demande retournent une réponse directement au demandeur. Pour les réseaux managés utilisant un proxy de découverte, les messages de sonde sont monodiffusion sur le proxy de découverte à la place. Le message Résoudre est utilisé lorsqu’un service Web doit être localisé par nom. Le message Résoudre est envoyé uniquement en mode multidiffusion. Resolve est analogue au protocole de résolution d’adresses ou ARP [ARP], qui convertit une adresse IP en son adresse réseau physique correspondante.

La spécification WS-Discovery autorise également les configurations système où le message Probe est envoyé à un proxy de découverte qui a été établi par d’autres moyens administratifs, par exemple à l’aide d’un enregistrement DHCP bien connu.

La possibilité de trouver des services de manière dynamique active le démarrage de la gestion des services Web. Conjointement avec WS-Eventing [WS-Eventing] et d’autres protocoles, des services de gestion plus sophistiqués peuvent être créés à l’aide de cette infrastructure de découverte dynamique.

La découverte dynamique étend également l’architecture des services Web aux appareils, tels que ceux qui peuvent implémenter les protocoles UPnP (Universal Plug Play & ) aujourd’hui. Il s’agit d’une étape importante pour rendre l’architecture véritablement universelle. Avec WS-Discovery et WS-Eventing, des appareils tels que des imprimantes ou des supports de stockage, par exemple, peuvent être incorporés dans un système en tant que services Web sans avoir besoin d’outils ou de protocoles spécialisés.

Spécification du profil d’appareil pour les services web

La spécification Profil d’appareil pour les services web [WS-DP] fournit des conseils sur le sous-ensemble de la famille de spécifications d’architecture des services Web qui doit être implémenté sur les appareils à ressources limitées. Ce profil tente de trouver l’équilibre entre les fonctionnalités riches disponibles et celles qui sont les plus importantes lors des compromis en raison de contraintes de ressources.

Protocoles de coordination des accords – Messagerie et transactions fiables

Cette section présente les composants de l’architecture des services Web qui fournissent une remise de messages fiable, un comportement transactionnel et la possibilité de fournir une coordination explicite entre une collection de services Web. Les spécifications qui définissent cette fonctionnalité sont WS-ReliableMessaging, WS-Coordination [WS-Coord], WS-AtomicTransaction [WS-AT] et WS-BusinessActivity.

Lorsque plusieurs services Web doivent effectuer une unité de travail conjointe ou fonctionner selon un comportement commun, il doit y avoir un accord commun sur les protocoles à utiliser. Cette coordination minimale entre les services Web est inévitable. Des protocoles de coordination sont également requis pour pouvoir déterminer et convenir qu’un objectif commun a été atteint. Chaque interaction entre les services Web peut être vue comme une sorte de coordination. Les protocoles de coordination des accords donnent à l’architecture une meilleure chance que les services participants réussissent dans ce qu’ils ont établi pour faire conjointement. L’architecture des services Web est conçue pour fonctionner correctement face aux transports qui perdent des messages et aux services qui ne fonctionnent pas correctement.

Toute coordination multipartite peut être créée à partir d’une coordination bipartis en se joignant successivement à davantage de participants si nécessaire. La coordination entre deux parties peut être spontanée ou nécessiter un coordinateur désigné. Un exemple de protocole de coordination spontanée populaire est le modèle de messagerie de demande-réponse synchrone. Il s’agit de l’une des formes les plus simples de coordination des accords; pour chaque demande de travail, le service Web destinataire doit effectuer tout le travail attendu avant de retourner des données au demandeur. Les deux parties suivent ce modèle strict sans avoir besoin d’un service de coordination explicite. Un deuxième exemple de coordination spontanée est présenté dans la section The Three-Leg Handshake. WS-ReliableMessaging est un exemple de coordination spontanée à plusieurs messages très général et est décrit dans la section suivante.

Messagerie fiable

De nombreuses conditions peuvent interrompre l’échange de messages entre deux services. Il s’agit en particulier d’un problème quand des protocoles de transport non fiables tels que HTTP 1.0 et SMTP [SMTP] sont utilisés pour la transmission ou lorsqu’un échange de messages s’étend sur plusieurs connexions de couche de transport. Les messages peuvent être perdus, dupliqués ou réorganisés, et les services Web peuvent échouer et perdre leur état volatile. WS-ReliableMessaging est un protocole qui permet la remise fiable de messages en fonction de caractéristiques d’assurance de remise spécifiques. La spécification définit trois garanties différentes qui peuvent être utilisées en combinaison :

• Remise au moins une fois : chaque message est remis au moins une fois.
• Remise au maximum : les messages en double ne seront pas remis.
• remise In-Order : les messages sont remis dans l’ordre dans lequel ils ont été envoyés.

La combinaison de garanties au moins une fois et au plus une fois entraîne une assurance de livraison exactement une fois. En raison de la conception indépendante du transport de l’architecture des services Web, toutes les garanties de livraison sont garanties, quel que soit le transport de communication ou la combinaison de transports utilisés. L’utilisation de WS-ReliableMessaging simplifie le développement du système en raison du plus petit nombre de modes d’échec de livraison potentiels qu’un développeur doit anticiper.

La remise fiable des messages ne nécessite pas de coordinateur explicite. Lors de l’utilisation de WS-ReliableMessaging, les participants doivent reconnaître le protocole en fonction des informations envoyées dans les en-têtes de message SOAP. L’ensemble de messages transmis en tant que groupe est appelé séquence de messages. Une séquence de messages peut être établie par l’initiateur/expéditeur ou le service Web, et souvent par les deux lors de l’établissement d’une association duplex. Les séquences sont établies explicitement à l’aide des messages CreateSequence et CreateSequenceResponse. Lorsque le résultat final souhaité est d’avoir deux séquences unidirectionnel agissant comme une séquence duplex, l’initiateur fournit la séquence que le service Web doit utiliser. L’ID de cette séquence est inclus par l’initiateur dans le message CreateSequence.

Plusieurs assertions de stratégie sont définies dans WS-ReliableMessaging. Ces assertions de stratégie sont exprimées à l’aide des mécanismes définis dans WS-Policy.

Les protocoles de messagerie fiables simplifient le code que les développeurs doivent écrire pour transférer des messages sous différentes garanties de transport. Au lieu de cela, l’infrastructure sous-jacente vérifie que les messages ont été correctement transférés entre les points de terminaison, en retransmettant les messages et en détectant la duplication si nécessaire. Les applications n’ont besoin d’aucune logique supplémentaire pour gérer les retransmissions de messages, l’élimination des messages en double, la réorganisation des messages ou l’accusé de réception de message qui peuvent être nécessaires pour fournir les garanties de remise. L’implémentation de WS-ReliableMessaging est répartie entre l’initiateur et le service. Les caractéristiques qui ne sont pas visibles « sur le réseau », telles que l’ordre de remise de messages, sont fournies par l’implémentation de la spécification WS-ReliableMessaging. Bien que les caractéristiques telles que les retransmissions de messages dues à des pertes de transport soient gérées par la couche de messagerie à l’insu de l’application, d’autres caractéristiques de bout en bout telles que la remise dans l’ordre exigent que l’infrastructure de messagerie et l’application récepteur collaborent. Il est intéressant de noter que fournir un ordre de message « tel que reçu » sur le destinataire lorsque l’expéditeur attend « comme envoyé » est une implémentation incorrecte de l’ordre. Fournir une commande « telle que envoyée » sur le destinataire lorsque l’expéditeur attend « comme reçu » est une implémentation correcte de l’ordre.

Coordinateurs désignés

Certaines familles de protocoles de coordination multidirectionnel ont besoin d’un coordinateur désigné pour gérer une unité de travail par le biais d’un certain nombre de services de coopération. Par exemple, les activités doivent être coordonnées entre les services qui ne sont pas tous censés être connectés en même temps. Tant que chaque participant et le coordonnateur communiquent à un moment donné, une coordination peut se produire et un accord sur le résultat peut être atteint. L’architecture des services Web définit certaines opérations simples pour les coordinateurs désignés.

La spécification WS-Coordination définit une infrastructure de coordination extensible pour prendre en charge les scénarios où des coordinateurs explicites sont nécessaires. Ce protocole introduit un bloc d’en-tête SOAP, appelé contexte de coordination, pour identifier de manière unique le travail conjoint à entreprendre. Pour lancer un travail conjoint, un service Web envoie un contexte de coordination à un ou plusieurs services cibles. La réception d’un contexte de coordination signale à un service destinataire que la collaboration conjointe est demandée. Le contexte de coordination contient suffisamment d’informations pour que le destinataire de la demande détermine s’il faut participer au travail. Les informations exactes contenues dans le contexte de coordination varient en fonction du type de travail demandé.

L’ensemble des types de coordination est ouvert. De nouveaux types peuvent être définis par une implémentation, à condition que chaque service participant au travail conjoint ait une compréhension commune du comportement requis. Par exemple, les transactions atomiques sont l’un des quelques types de coordination de pierre angulaire initiale qui ont été définis dans l’architecture des services Web.

Si le type de coordination demandé est compris et accepté, un service Web utilise le protocole d’inscription WS-Coordination pour avertir le coordinateur et participer au travail conjoint. Un contexte de coordination inclut une référence de point de terminaison pour le coordinateur et des identificateurs des comportements possibles qui peuvent être sélectionnés. L’opération d’inscription spécifie le comportement pris en charge par le service Web participant. Une fois le message d’inscription envoyé au coordinateur, le service Web participe au travail en fonction des protocoles auxquels il s’est abonné. L’inscription est l’opération clé dans l’infrastructure de coordination. Il permet le « câblage ensemble » de différents services Web qui souhaitent se coordonner pour effectuer une unité de travail conjointe.

WS-AtomicTransaction spécifie les transactions ACID traditionnelles [Gray & Reuter] pour les services Web. Dans le contexte du type de coordination de transaction atomique, trois protocoles sont définis : un protocole d’achèvement et deux variantes d’un protocole de validation Two-Phase. Le protocole d’achèvement est utilisé pour lancer le traitement de validation. Un service Web inscrit pour l’achèvement a la possibilité d’indiquer au coordinateur désigné quand le traitement de la validation doit commencer. Ce protocole définit également les messages pour communiquer le résultat final de la transaction à l’initiateur. Toutefois, le protocole ne nécessite pas que le coordinateur s’assure que l’initiateur traite le résultat. En revanche, d’autres comportements dans WS-AtomicTransaction nécessitent que le coordinateur s’assure que les participants traitent les messages de coordination.

Le protocole Two-Phase Commit (2PC) amène tous les participants inscrits à une décision commune de validation ou d’abandon, et garantit que tous les participants sont informés du résultat final. Comme son nom l’indique, il utilise deux séries de notifications pour terminer la transaction. Deux variantes de ce protocole sont définies : Volatile 2PC et Durable 2PC. Les deux protocoles utilisent les mêmes messages sur le réseau (correspondant aux opérations de préparation, de validation et d’abandon), mais Volatile 2PC n’avait aucune exigence de durabilité. Le protocole volatile 2PC doit être utilisé par les participants qui gèrent les ressources volatiles, telles que les gestionnaires de cache ou les gestionnaires de fenêtres. Ces participants sont contactés lors d’une première série de notifications par le coordinateur et n’ont pas besoin d’une deuxième série de notifications.

Le protocole 2PC durable doit être utilisé par les participants qui gèrent des ressources durables telles que des bases de données et des fichiers. Lorsqu’un traitement de validation a été lancé, ces participants sont contactés pour la première fois après que tous les participants volatiles 2PC ont été contactés. Cela permet, par exemple, de vider les caches. Les participants durables 2PC nécessitent les deux séries complètes de notifications pour obtenir le comportement tout ou rien imposé par le coordinateur et pour terminer la transaction. Ces comportements sont les plus appropriés pour les scénarios où des ressources peuvent être conservées pendant la durée de la transaction, et où les transactions sont généralement de très courte durée. Ce protocole garantit que, dans le cadre d’un traitement normal, le coordinateur contactera tous les participants avec le résultat de la première phase. Pour les transactions qui devraient nécessiter plus de temps ou lorsque des ressources telles que des verrous ne peuvent pas être conservées, d’autres comportements sont définis par d’autres protocoles de coordination.

Plusieurs assertions de stratégie sont définies dans WS-AtomicTransaction. Ces assertions de stratégie sont exprimées à l’aide des mécanismes définis dans WS-Policy.

Systèmes mis en file d’attente

Un modèle qui s’est avéré très utile lors de la création de systèmes distribués est l’utilisation de files d’attente transactionnelles durables pour fournir la remise de messages asynchrones de magasin et de transfert. Dans ce modèle, les transactions atomiques sont exploitées à chacun des points de terminaison de transmission. Côté expéditeur, l’application émettrice remet un message à une file d’attente durable d’une manière transactionnelle atomique où l’application et le gestionnaire de files d’attente utilisent tous deux WS-AtomicTransaction pour coordonner. Ce n’est que s’il n’y a pas d’erreur lors du traitement du message qu’il est considéré comme correctement remis à la file d’attente.

Ensuite, le sous-système de file d’attente prend en charge la remise du message entre la file d’attente d’origine et la file d’attente du destinataire. Cette étape de transmission peut être effectuée à un moment ultérieur de celui où le message a été placé dans la file d’attente d’origine. En outre, l’emplacement de la file d’attente d’origine n’a pas besoin de coïncider avec l’emplacement de l’application d’où provient le message.

De même, l’application qui récupère le message de la file d’attente de destinataires le fait à l’aide d’une transaction atomique. De cette façon, un message peut être supprimé de la file d’attente uniquement en l’absence d’erreurs de traitement.

Activités de longue durée

WS-BusinessActivity [WS-BA] spécifie deux protocoles pour les transactions de longue durée. Au lieu de conserver des verrous sur les ressources jusqu’à ce que la transaction soit validée, la spécification WS-BusinessActivity est basée sur des actions de compensation. Le modèle de transaction sous-jacent est la transaction imbriquée ouverte [Gray & Reuter]. Ces protocoles codifient la façon dont des paires de services faiblement couplés s’entendent pour conclure qu’elles ont mis fin à une tâche conjointe. Dans un protocole, le coordinateur indique explicitement aux participants qu’il n’est plus demandé de travail pour le compte de la tâche conjointe. Dans le deuxième protocole, le participant est celui qui informe le coordinateur que le travail au nom de la tâche conjointe a été accompli. L’utilisation d’actions compensatoires fournit un mécanisme permettant de terminer des opérations provisoires sans laisser de verrous dessus. Une opération de compensation doit être émise si, pour une raison quelconque, le système souhaite annuler les effets de l’opération provisoire terminée.

WS-AtomicTransaction et WS-BusinessActivity tirer parti des WS-Coordination pour gérer la collaboration entre les services Web.

L’établissement d’une liaison Three-Leg

Le protocole d’établissement d’une connexion d’établissement de liaison et de déchirure à trois étapes est un exemple de protocole de coordination qui ne nécessite pas de service coordinateur désigné. Pour établir une connexion, l’expéditeur envoie une demande au récepteur. Cette demande établit une session. S’il est accepté, le destinataire répond positivement à cette demande avec un message d’accusé de réception. Un troisième message est transmis par l’expéditeur en tant qu’accusé de réception, vérifiant que les deux parties savent que l’autre partie a établi une session.

Le protocole de démontage est analogue. L’une des parties envoie à l’autre partie une demande de retrait de session. Le destinataire répond avec un accusé de réception du message de retrait. Lors de la réception de cet accusé de réception, la partie à l’origine du message de retrait termine l’échange de messages en envoyant un accusé de réception à l’accusé de réception.

Énumération, transfert et événements

Cette section présente des spécifications qui fournissent l’énumération des ressources de service, leur gestion de l’état et la notification d’événements dans l’architecture des services Web. Ils sont basés sur WS-Enumeration [WS-Enum], WS-Transfer [WS-Transfer] et WS-Eventing.

Énumération

De nombreux scénarios nécessitent l’échange de données à l’aide d’une seule paire de messages demande/réponse. Les types d’applications qui nécessitent ces échanges de données plus longs incluent les requêtes de base de données, le streaming de données, la traversée d’informations telles que les espaces de noms et l’énumération de listes. L’énumération, en particulier, est obtenue par l’établissement d’une session entre la source de données et le demandeur. Les messages successifs au sein de la session transportent la collection d’éléments récupérés. Aucune hypothèse n’est faite sur l’approche utilisée par le service pour organiser les éléments qui seront produits. Ce qui est attendu, c’est que dans des circonstances de traitement normales, l’énumération produira toutes les données sous-jacentes avant la fin de la session.

WS-Enumeration spécifie les protocoles permettant d’établir une session d’énumération et de récupérer des séquences de données. Les protocoles d’énumération permettent à la source de données de fournir une abstraction de session, appelée contexte d’énumération, au service consommateur. Ce contexte d’énumération représente un curseur logique via une séquence d’éléments de données. Le demandeur utilise ensuite ce contexte d’énumération sur une étendue d’un ou plusieurs messages SOAP pour demander les données. Les données énumérées sont représentées sous forme d’ensembles d’informations XML. La spécification permet également à une source de données de fournir un mécanisme personnalisé pour démarrer une nouvelle énumération. Étant donné qu’une session d’énumération peut nécessiter plusieurs échanges de messages, l’état de la session doit être conservé.

Les informations d’état relatives à la progression de l’itération peuvent être conservées entre les demandes de la source de données ou du service consommateur. WS-Enumeration permet à la source de données de décider, demande par demande, quelle partie sera responsable du maintien de l’état pour la demande suivante. Cette flexibilité permet plusieurs types d’optimisations. Un exemple d’optimisation consiste à permettre à un serveur d’éviter d’enregistrer l’état du curseur entre les appels. Étant donné que les latences de message peuvent être importantes pour un service prenant en charge plusieurs énumérations simultanées, le fait de ne pas préserver l’état peut générer des économies substantielles dans la quantité totale d’informations qui doivent être conservées. Les implémentations de service sur les appareils à ressources limitées, tels que les téléphones cellulaires, peuvent ne pas être en mesure de conserver les informations d’état du tout.

Transférer

Les opérations de base requises pour gérer les entités de données accessibles via les services web sont définies dans WS-Transfer [WS-Transfer]. Une compréhension de WS-Transfer nécessite l’introduction de deux nouveaux termes : factory et of resource. Une fabrique est un service web qui peut créer une ressource à partir de sa représentation XML. WS-Transfer introduit des opérations qui créent, mettent à jour, récupèrent et suppriment des ressources. Il convient de noter que la maintenance de l’état d’une ressource est tout au plus soumise aux « meilleurs efforts » du serveur d’hébergement. Lorsqu’un client reçoit l’acceptation par le serveur d’une demande de création ou de mise à jour d’une ressource, il peut raisonnablement s’attendre à ce que la ressource existe maintenant à l’emplacement confirmé et avec la représentation confirmée, mais ce n’est pas une garantie, même en l’absence de tiers. Le serveur peut modifier la représentation d’une ressource, supprimer entièrement une ressource ou ramener une ressource qui a été supprimée. Ce manque de garanties est cohérent avec le modèle faiblement couplé apporté par le web. Si vous le souhaitez, les services peuvent offrir des garanties supplémentaires qui ne sont pas requises par l’architecture des services Web.

Les opérations de création, de mise à jour et de suppression de WS-Transfer étendent les fonctionnalités des opérations en lecture seule disponibles dans WS-MetadataExchange. L’opération de récupération est exactement la même opération Get dans WS-MetadataExchange. La demande De création est envoyée à une fabrique. La fabrique crée ensuite la ressource demandée et détermine sa représentation initiale. La fabrique est supposée être distincte de la ressource en cours de création. Une référence de point de terminaison déterminée par le service est affectée à la nouvelle ressource qui est retournée dans le message de réponse.

L’opération Put met à jour une ressource en fournissant une représentation de remplacement. Une instantané ponctuelle de la représentation d’une ressource, identique à l’opération Get dans WS-MetadataExchange, peut être récupérée à l’aide de l’opération Get dans WS-Transfer. Après une opération de suppression réussie, la ressource n’est plus disponible via la référence du point de terminaison. Ces quatre opérations de gestion des métadonnées constituent la base nécessaire pour créer la gestion de l’état dans les services Web.

Événements

Dans les systèmes constitués de services qui communiquent entre eux, éventuellement à l’aide d’une messagerie asynchrone, il existe de nombreux scénarios où les informations produites par un service intéressent un autre service. En raison de caractéristiques de mise à l’échelle médiocres, l’interrogation n’est souvent pas un mécanisme approprié pour obtenir de telles informations; trop de messages inutiles sont envoyés via le réseau. Au lieu de cela, l’architecture nécessite un mécanisme pour les notifications explicites lorsque des événements se produisent. Plus important encore est l’exigence que la liaison d’un service source et d’un service consommateur soit effectuée dynamiquement au moment de l’exécution. L’architecture des services Web prend en charge cela via un protocole d’événements léger.

WS-Eventing spécifie les mécanismes permettant aux quatre entités suivantes d’interagir : abonnés, gestionnaires d’abonnements, sources d’événements et récepteurs d’événements. Cela permet à un service Web, lorsqu’il agit en tant qu’abonné, d’enregistrer de l’intérêt pour des événements spécifiques qui sont fournis par un autre service Web (la source de l’événement). Cette inscription est appelée abonnement. WS-Eventing définit les opérations qu’un service peut fournir qui permettent de créer et de gérer des abonnements. Lorsqu’une source d’événement détermine qu’un événement s’est produit, elle fournit ces informations au gestionnaire d’abonnements. Le gestionnaire d’abonnements peut ensuite communiquer l’événement à tous les abonnements correspondants. Cela est similaire à la publication de rubriques dans un système traditionnel de notification d’événements de publication/abonnement. L’architecture des services web offre une flexibilité totale dans la façon dont les rubriques sont définies, organisées et découvertes ; il fournit une infrastructure commune pour la gestion des abonnements qui peuvent être exploités dans de nombreux domaines d’application différents.

Les abonnements louent des ressources qui doivent être récupérées à terme. Le mécanisme principal utilisé pour récupérer des ressources est une heure d’expiration pour chaque abonnement. Il existe également un mécanisme permettant d’interroger le status des abonnements. Des opérations supplémentaires pour aider les abonnés à gérer leur collection d’abonnements, y compris le renouvellement, les notifications et les demandes de désinscription sont également définies. Bien entendu, tout service est libre de mettre fin à un abonnement à tout moment, conformément au principe d’autonomie de tous les services Web. Le message de fin d’abonnement peut être utilisé par la source d’événement pour informer les abonnés de la résiliation prématurée d’un abonnement.

Bien que le modèle général des messages asynchrones basés sur les événements soit courant, différentes applications nécessitent souvent d’autres mécanismes de remise d’événements. Pour instance, un message asynchrone simple peut être optimal dans certains cas, tandis que d’autres situations peuvent fonctionner mieux si le récepteur d’événements peut contrôler le flux et la date d’arrivée des messages via l’interrogation. L’interrogation est également nécessaire lorsque le récepteur n’est pas accessible à partir de la source, par exemple dans le cas où le récepteur se trouve derrière un pare-feu. La notion de modes de livraison a été introduite dans WS-Eventing pour répondre à ces exigences. Le mode de livraison est utilisé comme point d’extension pour fournir aux abonnés, aux récepteurs d’événements et aux sources d’événements un moyen d’établir des mécanismes de livraison personnalisés. La spécification de gestion décrite ci-dessous utilise ce mécanisme.

Un répartiteur d’événements peut être utilisé pour agréger ou redistribuer des notifications via différentes sources. Un répartiteur peut également être utilisé comme gestionnaire d’abonnements autonome. Ces deux approches sont prises en charge par WS-Eventing. Les courtiers peuvent jouer plusieurs rôles importants dans un système. Les rubriques peuvent être organisées pour être utilisées par certaines classes d’applications. Les courtiers peuvent agir en tant qu’agrégateurs de notification qui combinent des informations d’événement provenant de plusieurs sources. Ils peuvent également faire office de filtres, recevant plus de messages que ceux qu’ils utilisent pour leurs propres notifications. Cette flexibilité est nécessaire pour déployer des systèmes de notification robustes et évolutifs.

Gestion

Les fonctionnalités de gestion sont le dernier aspect de l’architecture des services Web à discuter. Ces fonctionnalités sont définies dans la spécification WS-Management [WS-Management].

WS-Management s’appuie sur plusieurs composants de l’architecture, fournissant un ensemble commun d’opérations qui sont requises par toutes les solutions de gestion des systèmes. Cela inclut la possibilité de découvrir la présence de ressources de gestion et la navigation entre elles. Les ressources de gestion individuelles telles que les paramètres et les valeurs dynamiques peuvent être récupérées, définies, créées et supprimées. Le contenu des conteneurs et des collections, tels que les grandes tables et les journaux, peut être énuméré. Enfin, les abonnements aux événements et les opérations de gestion spécifiques sont définis. Dans chacun de ces domaines, WS-Management définit uniquement des exigences d’implémentation minimales.

Des précautions ont été prises pour que les implémentations de WS-Management conformes puissent être déployées sur de petits appareils. En même temps, il a été conçu pour effectuer un scale-up vers de grands centres de données et des installations distribuées. En outre, les mécanismes sont définis indépendamment des modèles de données implicites ou des modèles d’intégrité du système. Cette indépendance prend en charge son application à tous les types de services Web.

WS-Management nécessite que les ressources managées soient référencées à l’aide de références de point de terminaison avec des informations supplémentaires spécifiques. Ces informations incluent l’URL de l’agent qui fournit l’accès à la ressource, l’URI d’identificateur unique du type de ressource auquel la ressource appartient et aucune ou plusieurs clés qui identifient la ressource. Ces clés sont supposées être des paires nom/valeur. Le mappage de ces informations à une référence de point de terminaison WS-Addressing est le suivant : l’URL de la ressource est mappée à la propriété address, l’identificateur de type de ressource est mappé à une propriété de référence spécifique nommée ResourceURI (dans l’espace de noms XML approprié) et chaque clé est mappée à un paramètre de référence nommé Key avec un attribut nommé Name.

Pour répondre aux besoins de messagerie des services de gestion, trois qualificateurs sont définis pour les opérations. La représentation SOAP de ces qualificateurs se trouve dans les éléments d’en-tête. Un délai d’expiration de l’opération spécifie une échéance après laquelle l’opération n’a pas besoin d’être soignée. L’élément de paramètres régionaux est utilisé lorsque des traductions des informations sous-jacentes sont nécessaires ou attendues. Enfin, un qualificateur d’actualisation est fourni pour demander des valeurs à jour et interdire le retour de données obsolètes.

Pour l’accès aux données à l’aide des opérations de WS-Transfer, WS-Management spécifie trois qualificateurs supplémentaires. L’opération Get peut être qualifiée avec l’en-tête SummaryPermitted et l’en-tête NoCache. Le qualificateur SummaryPermitted permet la transmission des représentations abrégées, lorsqu’elles sont disponibles. Le qualificateur NoCache nécessite la transmission de nouvelles données, ce qui interdit la mise en cache des informations. Pour les opérations Put et Create , le qualificateur ReturnResource oblige le service à retourner la nouvelle représentation d’une ressource. ReturnResource permet aux services Web limités en ressources de ne conserver aucun état lors de la mise à jour d’une ressource.

WS-Management définit trois modes de remise personnalisés pour la notification d’événement : lot, extraction et interruption. Chacun de ces modes est identifié par un URI. Ces URI sont utilisés lors de l’établissement d’abonnements. Le mode de remise par lots permet à un abonné de recevoir plusieurs messages d’événements groupés dans des messages SOAP uniques. L’abonné peut également demander qu’un nombre maximal d’événements soit inclus dans l’offre groupée, une durée maximale pendant laquelle le service doit prendre des événements d’accumulation et une quantité maximale de données qui doivent être retournées. Le mode de distribution d’extraction permet au service de production de données de maintenir une file d’attente logique d’événements afin que l’abonné puisse interroger les notifications à la demande. Cette interrogation est effectuée à l’aide de WS-Enumeration avec un contexte d’énumération retourné avec le message de réponse de l’abonnement. Enfin, lorsque la multidiffusion UDP est un mécanisme de messagerie approprié, le mode de remise d’interruption permet à une source d’événement de l’utiliser. En mode d’interruption, la source d’événement peut envoyer ses notifications à une adresse de multidiffusion UDP prédéterminée.

Remarques finales

Cet article présente les blocs de construction fonctionnels de l’architecture des services Web et ses principes sous-jacents. Chaque bloc de construction est défini en termes de spécification de protocole. Nous nous attendons à ce que l’étendue fonctionnelle et les principes directeurs décrits dans ce document restent inchangés. Toutefois, nous nous attendons à ce que l’architecture se développe pour prendre en charge d’autres scénarios. La capacité de prendre en charge l’innovation est une force fondamentale de l’architecture.

Un grand soin a été pris pour s’assurer que les différents protocoles de service Web peuvent être composés les uns avec les autres; bien qu’ils aient été conçus ensemble, ils peuvent être utilisés dans un large éventail de combinaisons. En tant que blocs de construction fonctionnels, ils se comportent comme un framework de développement traditionnel. Si nécessaire, comme pour les pièces jointes SOAP, nous avons développé de nouvelles solutions qui s’intègrent parfaitement dans l’architecture. L’accent mis sur la composition n’est pas un obstacle à la richesse des fonctionnalités.

La base de messagerie SOAP de l’architecture garantit une large portée. La messagerie SOAP prend en charge les modèles asynchrones et synchrones de manière indépendante du transport. Il n’y a pas d’infrastructure plus flexible. Pour accélérer l’adoption à grande échelle de l’architecture des services web, les spécifications ont été créées avec une vaste collection de partenaires techniques. Le partenariat avec ces fournisseurs de technologies clés accélère le déploiement d’appareils et d’environnements de programmation qui prennent en charge les protocoles on-the-wire. Atteindre une large portée, une adoption généralisée et des constructions indépendantes de l’échelle sont trois de nos objectifs principaux.

Nous nous efforçons de garantir que l’architecture peut être implémentée sur n’importe quelle plateforme et dans n’importe quel langage de programmation. Cela est facilité par la nature basée sur les messages et les protocoles de l’architecture. Si nécessaire, comme l’utilisation de WS-Security uniquement pour l’intégrité, la confidentialité et l’authentification des messages, et l’expression de métadonnées uniquement à l’aide de WS-Policy, nous avons restreint l’univers des approches techniques pour augmenter le niveau d’interopérabilité. Dans l’idéal, tant que les implémentations suivent fidèlement les spécifications du protocole de l’architecture, elles peuvent communiquer avec n’importe quel autre service Web.  La vérité est sur le fil.

Remerciements

Nous remercions tout particulièrement Omri Gazitt pour son soutien continu et ses nombreuses suggestions, à Alan Geller, Jim Johnson et Rodney Limprecht pour leurs examens approfondis et à ses excellentes idées, à Dan Simon pour sa description des attaques courantes en matière de sécurité, et à Chris Kaler pour ses conseils et ses multiples révisions de la section sécurité. Les contributions de John Shewchuk à la section architecture ont également été d’une grande aide. Merci à Phil Bernstein, Shy Cohen, Paul Cotton, David Langworthy, Andrew Layman, Brad Lovering, Jeffrey Schlimmer, Scott Seely, Satish Thatte, Marvin Theimer, Jorgen Thelin et Hervey Wilson pour leurs commentaires et encouragements.

Last but not least, les personnes suivantes ont participé à la définition de l’architecture des services Web : (alphabétique) Tony Andrews, Bob Atkinson, Keith Ballinger, Don Box, John Brezak, Allen Brown, Luis Felipe Cabrera, Erik Christensen, George Copeland, Michael Coulson, Giovanni Della-Libera, Brendan Dixon, Mike Dusche, Colleen Evans, Max Feingold, Henrik Frystyk Nielsen, Praerit Garg, Omri Gazitt, Alan Geller, Josh Gray, Martin Gudgin, Destry Hood, Efim Hudis, Tomasz Janczuk, Jim Johnson, Ryan Johnson, John Justice, Gopal Kakivaya, Chris Kaler, Johannes Klein, Scott Konersmann, Brian LaMacchia, Dave Langworthy, Andrew Layman, Paul Leach, Al Lee, Rodney Limprecht, Joe Long, Steve Lucco, John Manferdelli, Ashok Malhotra, Jonathan Marsh, Steve Millet, Angela Mills, Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, John Shewchuk, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Hervey Wilson, Kenny Wolf et Eric Zinda.

Annexe A : Glossaire

Demandeur actif : un demandeur actif est une application (éventuellement un navigateur Web) capable d’émettre des messages de services Web tels que ceux décrits dans WS-Security et WS-Trust.

Authentification : processus de validation des informations d’identification de sécurité.

Autorisation : processus d’octroi de l’accès à une ressource sécurisée en fonction des informations d’identification de sécurité fournies.

Canonisation : processus de conversion d’un document XML en un formulaire cohérent pour toutes les parties. Utilisé lors de la signature de documents et de l’interprétation des signatures.

Revendication : une revendication est une déclaration faite à propos d’un expéditeur, d’un service ou d’une autre ressource (par exemple, nom, identité, clé, groupe, privilège, fonctionnalité, etc.).

Contexte de coordination : identificateur unique d’un ensemble de travaux à effectuer par un groupe de services coordonnés.

Désérialisation : processus de construction d’un infoset XML à partir d’un flux d’octets. Il s’agit de la méthode utilisée pour créer la représentation Infoset d’un message à partir du format filaire d’un message.

Digest : une synthèse est une somme de contrôle de chiffrement d’un flux d’octets.

Domaine : un domaine de sécurité représente une unité unique d’administration ou d’approbation de la sécurité.

Validation à deux phases durable : protocole utilisé pour les transactions sur des ressources durables, telles que des fichiers ou des bases de données.

Stratégie efficace : une stratégie efficace, pour un sujet de stratégie donné, est la combinaison résultante des stratégies attachées aux étendues de stratégie qui contiennent l’objet de la stratégie.

Modèle Exchange : modèle utilisé pour l’échange de messages entre les services.

Fabrique : une fabrique est un service web qui peut créer une ressource à partir d’une représentation XML.

Fédération : une fédération est une collection de domaines d’approbation qui ont établi une approbation mutuelle par paire. Le niveau de confiance peut varier, mais inclut généralement l’authentification et peut inclure l’autorisation.

Mappage d’identité : le mappage d’identité est une méthode permettant de créer des relations entre les propriétés d’identité. Certains fournisseurs d’identité peuvent utiliser le mappage d’identité.

Fournisseur d’identité (IP) : le fournisseur d’identité est une entité qui agit en tant que service d’authentification pour les demandeurs finaux. Un fournisseur d’identité agit également en tant que service d’authentification d’origine des données pour les fournisseurs de services (il s’agit généralement d’une extension d’un service de jeton de sécurité).

Message : un message est une unité complète de données disponibles pour être envoyées ou reçues par les services. Il s’agit d’une unité autonome d’échange d’informations. Un message contient toujours une enveloppe SOAP et peut inclure des parties MIME supplémentaires comme spécifié dans MTOM et/ou des en-têtes de protocole de transport.

Chemin du message : ensemble de nœuds SOAP parcourus entre la source d’origine et le récepteur final.

Demandeurs passifs : un demandeur passif est un navigateur HTTP capable de prendre en charge http (par exemple, HTTP/1.1).

Stratégie : une stratégie est une collection d’alternatives de stratégie.

Alternative de stratégie : une alternative de stratégie est une collection d’assertions de stratégie.

Assertion de stratégie : une assertion de stratégie représente une exigence individuelle, une fonctionnalité, une autre propriété ou un comportement spécifique au domaine.

Expression de stratégie : une expression de stratégie est une représentation d’un ensemble d’informations XML d’une stratégie, sous une forme normale ou dans un formulaire compact équivalent.

Principal : toute entité système qui peut se voir accorder des droits de sécurité ou qui fait des assertions sur la sécurité ou l’identité.

Composition du protocole : la composition du protocole est la possibilité de combiner des protocoles tout en conservant la cohérence technique et en l’absence d’effets secondaires fonctionnels inattendus.

Ressource : une ressource est définie comme toute entité adressable par une référence de point de terminaison où l’entité peut fournir une représentation XML d’elle-même.

Contexte de sécurité : un contexte de sécurité est un concept abstrait qui fait référence à un état d’authentification établi et à des clés négociées qui peuvent avoir des propriétés supplémentaires liées à la sécurité.

Jeton de contexte de sécurité : un jeton de contexte de sécurité (SCT) est une représentation filaire du concept abstrait du contexte de sécurité, qui permet à un contexte d’être nommé par un URI et d’être utilisé avec [WS-Security].

Jeton de sécurité : un jeton de sécurité représente une collection de revendications.

Service de jeton de sécurité : un service de jeton de sécurité (STS) est un service web qui émet des jetons de sécurité (voir [WS-Security]). Autrement dit, elle fait des assertions basées sur des preuves qu’elle fait confiance à quiconque lui fait confiance (ou à des destinataires spécifiques). Pour communiquer l’approbation, un service nécessite une preuve, telle qu’une signature pour prouver la connaissance d’un jeton de sécurité ou d’un ensemble de jetons de sécurité. Un service lui-même peut générer des jetons ou il peut s’appuyer sur un STS distinct pour émettre un jeton de sécurité avec sa propre instruction d’approbation (notez que pour certains formats de jeton de sécurité, il peut simplement s’agir d’une ré-émission ou d’une co-signature). Cela constitue la base du brokering d’approbation.

Sérialisation : processus de représentation d’un ensemble d’informations XML en tant que flux d’octets. Il s’agit de la méthode utilisée pour créer le format de connexion d’un message.

Service : entité logicielle dont les interactions avec d’autres entités se font via des messages. Notez qu’un service n’a pas besoin d’être connecté à un réseau.

Signature : une signature est une valeur calculée à l’aide d’un algorithme de chiffrement et liée aux données de telle sorte que les destinataires prévus des données puissent utiliser la signature pour vérifier que les données n’ont pas été modifiées et qu’elles proviennent du signataire du message, ce qui fournit l’intégrité et l’authentification du message. La signature peut être calculée et vérifiée avec des algorithmes de clé symétrique ou asymétrique.

Déconnexion : une déconnexion est le processus par lequel un principal indique qu’il n’utilisera plus son jeton et que les services du domaine peuvent détruire leurs caches de jetons pour le principal.

Authentification unique (SSO) : Authentification unique est une optimisation de la séquence d’authentification pour supprimer la charge des actions répétées placées sur le demandeur. Pour faciliter l’authentification unique, un élément appelé fournisseur d’identité peut agir en tant que proxy au nom d’un demandeur pour fournir des preuves d’événements d’authentification aux tiers qui demandent des informations sur le demandeur. Ces fournisseurs d’identité (IP) sont des tiers de confiance et doivent être approuvés à la fois par le demandeur (pour conserver les informations d’identité du demandeur, car la perte de ces informations peut entraîner la compromission de l’identité des demandeurs) et les services Web qui peuvent accorder l’accès à des ressources et des informations précieuses en fonction de l’intégrité des informations d’identité fournies par l’adresse IP.

SOAP Intermédiaire : un intermédiaire SOAP est un nœud de traitement SOAP qui n’est ni l’expéditeur du message d’origine ni le destinataire final.

Algorithme de clé symétrique : algorithme de chiffrement dans lequel la même clé est utilisée pour le chiffrement et le déchiffrement d’un message.

Système : collection de services implémentant une fonctionnalité particulière. Synonyme d’application distribuée.

Approbation : l’approbation indique qu’une entité est prête à s’appuyer sur une deuxième entité pour exécuter un ensemble d’actions et/ou pour effectuer un ensemble d’assertions sur un ensemble de sujets et/ou d’étendues.

Domaine d’approbation : un domaine de confiance est un espace de sécurité administré dans lequel la source et la cible d’une requête peuvent déterminer et convenir si des ensembles d’informations d’identification particuliers d’une source satisfont aux stratégies de sécurité pertinentes de la cible. La cible peut reporter la décision d’approbation à un tiers (si cela a été établi dans le cadre du contrat) afin d’inclure le tiers de confiance dans le domaine d’approbation.

Validation volatile à deux phases : protocole utilisé pour les transactions sur des ressources volatiles, telles que les caches ou les gestionnaires de fenêtres.

Service web : un service web est un logiciel réutilisable qui interagit avec l’échange de messages sur le réseau via XML, SOAP et d’autres normes reconnues par le secteur.

Annexe B : Éléments d’informations de l’ensemble d’informations XML

Un document XML peut contenir onze types d’éléments d’informations. Ci-dessous, nous listons et définissons ceux autorisés par SOAP et mention les autres. Les six éléments d’information autorisés par SOAP sont les suivants :

1. Document: Un élément d’informations de document est présent dans chaque jeu d’informations. Il est utilisé pour référencer tous les autres éléments d’information.
2. Élément: Un élément d’informations sur un élément est inclus dans le jeu d’informations pour chaque élément XML du document. L’accès à tous les éléments est fourni en suivant de manière récursive les propriétés Child.
3. Attribut: Un élément d’informations d’attribut est inclus dans le jeu d’informations pour chaque attribut du document. Des éléments d’informations supplémentaires sur les attributs sont présents pour les espaces de noms.
4. Noms: Un élément d’informations d’espace de noms est contenu dans le jeu d’informations pour chaque espace de noms qui se trouve dans l’étendue de son élément parent.
5. Personnage: Un élément d’informations sur un caractère est inclus dans le jeu d’informations pour chaque caractère de données du document.
6. Commentaire: Un élément d’informations de commentaire est inclus dans l’ensemble d’informations pour chaque commentaire du document, à l’exception de ceux qui apparaissent dans le DTD.

Les cinq éléments d’informations non autorisés par SOAP, mais présents dans la définition d’origine de l’infoset XML sont : Instruction de traitement, Déclaration de type de document, Référence d’entité non expirée, Entité non traitée et Notation.

Annexe C : Attaques de sécurité courantes

Les attaques contre les systèmes distribués peuvent être réparties sur plusieurs axes. Ils peuvent être dirigés contre un ou plusieurs des hôtes dans le système, ou contre la communication entre eux. Les attaques peuvent être destinées à perturber les opérations, à obtenir des informations confidentielles ou à effectuer des actions non autorisées au sein du système. Ils peuvent attaquer le chiffrement et d’autres techniques axées sur la sécurité utilisées dans le système, ou tenter de les contourner en attaquant les systèmes et les couches réseau en dessous ou les couches d’application ci-dessus.

Voici une liste brève et non exhaustive des classes d’attaques de sécurité, organisées selon ces axes, ainsi que des contre-mesures standard pour chacune d’elles :

• Attaques sur les hôtes :

  • Les attaques par déni de service (DoS) perturbent les opérations de l’hôte en écrasant leur capacité à répondre.

    Lorsqu’il est dirigé vers la couche de chiffrement, un doS tente généralement de forcer l’hôte à effectuer à plusieurs reprises les opérations de clé publique coûteuses en calcul nécessaires pour certains protocoles d’authentification ou d’échange de clés. La défense classique contre de telles attaques consiste à retarder les opérations de clé publique jusqu’à ce que la légitimité de l’interlocuteur puisse être vérifiée par des moyens moins coûteux, tels que le chiffrement symétrique ou des « énigmes ».

    Les attaques DoS sur la couche réseau sous-jacente ou la couche d’application globale sont très difficiles à empêcher, en particulier si l’attaquant dispose de ressources massives et que le trafic est indistinguible d’une « foule flash » de trafic légitime. L’infrastructure réseau devait généralement être déployée d’une manière qui entonnoir le trafic à des niveaux gérables.

  • Les attaques de confidentialité ou d’autorisation de l’hôte tentent de compromettre la confidentialité ou l’identité.

    Ces attaques peuvent exploiter les vulnérabilités du logiciel hôte pour prendre le contrôle de l’hôte. Une bonne administration de la sécurité, telle que l’installation de correctifs, la configuration du pare-feu et la réduction des privilèges des applications exposées, est la contre-mesure habituelle.

    Un autre type d’attaque exploite les faiblesses du système ou des applications, telles que des stratégies incorrectement définies ou des erreurs de logique d’application, qui autorisent des compromissions de confidentialité ou d’autorisation sans compromission générale de l’hôte. Une bonne administration de la stratégie de sécurité et une programmation d’applications minutieuse sont les seules défenses contre de telles attaques.

    Les attaques d’usurpation d’identité sont des attaques où un attaquant tente d’obtenir l’autorisation pour diverses actions en supposant l’identité d’une autre partie autorisée et en agissant en conséquence. Les protocoles d’authentification sécurisés, correctement utilisés, peuvent empêcher l’usurpation, à condition que l’hôte et la partie autorisée protègent soigneusement les secrets de chiffrement utilisés pour l’authentification.

• Attaques contre la communication :

  • Les attaques DoS sur le réseau tentent d’interrompre la communication avec un service. Comme ceux de la couche réseau hôte, ceux-ci ne peuvent être traités qu’à l’aide de moyens d’infrastructure réseau.

  • Les attaques contre la confidentialité de la communication réseau tentent de compromettre la confidentialité sur le réseau.

    La surveillance directe de la communication en texte clair peut être empêchée par l’utilisation du chiffrement.

    Les attaques de cryptanalyse peuvent être rendues impossibles par des algorithmes de chiffrement suffisamment forts, avec des tailles de clé suffisantes.

  • Les attaques contre l’autorisation de communication réseau tentent de compromettre l’identité.

    Les attaques par falsification de message, dans lesquelles l’attaquant tente d’injecter des messages dans une conversation, et les attaques par altération de message, dans lesquelles l’attaquant modifie les messages envoyés dans une conversation, peuvent être empêchées avec des protocoles de sécurité des messages qui incluent l’authentification des messages.

    Les attaques par relecture de messages, dans lesquelles l’attaquant injecte des messages précédemment envoyés (et donc correctement authentifiés) dans une conversation peuvent être détectées et traitées via des numéros de séquence, ou la combinaison d’horodatages et de caches de messages.

Annexe D : Références

Spécifications principales

[ARP]

Un protocole de résolution d’adresses Ethernet [RFC826]. David C. Plummer. Novembre 1982. Groupe de travail d’ingénierie Internet.

[HTML]

Spécification HTML 4.01. Ed. Dave Raggett, et al. 24 décembre 1999. W3C.org.

[HTTP]

Hypertext Transfer Protocol : HTTP/1.1 (RFC 2616). Ed. R. Fielding, et al. juin 1999. L’Internet Society.

[KERBEROS]

Service d’authentification réseau Kerberos (V5). J. Kohl et C. Neuman. Septembre 1993. Groupe de travail d’ingénierie Internet.

[MIME]

Mime (Multipurpose Internet Mail Extensions) Partie 1 : Format des corps de message Internet. Ed. N. Libéré, et al. novembre 1996. Groupe de travail d’ingénierie Internet.

[REL]

Technologies de l’information – Infrastructure multimédia (MPEG-21) – Partie 5 : Rights Expression Language. Organisation internationale de normalisation (ISO/IEC 21000-5:2004).

[RFC1630]

Identificateurs de ressource universels dans WWW (RFC 1630). Ed. T. Berners-Lee. Juin 1994. Groupe de travail d’ingénierie Internet.

[SAML]

Assertions et protocole pour le langage SAML (Security Assertion Markup Language) OASIS V1.1. Ed. Eve Maler, et al. 2 septembre 2003. OASIS-Open.org.

[SMTP]

Protocole de transfert de courrier simple. Ed. J. Klensin. Avril 2001. Groupe de travail d’ingénierie Internet.

[TCPIP]

Protocole de contrôle de transmission. Ed. Jon Postel. Septembre 1981. Defense Advanced Research Projects Agency.

Protocole Internet. Ed. Jon Postel. Septembre 1981. Defense Advanced Research Projects Agency.

[TLS]

Protocole TLS. T. Dierks, et al. Janvier 1999. The Internet Society.

[UDP]

Protocole de datagramme utilisateur. J. Postel. Août 1980. Groupe de travail d’ingénierie Internet.

[X509]

Réseaux de données et Répertoire des communications de système ouvert (Recommandation UIT-T X.509). Juin 1997. Union internationale des télécommunications.

[XSLT-20]

XSL Transformations (XSLT) version 2.0. Ed. Michael Kay. 12 novembre 2004. W3C.org

[XML-Infoset]

Jeu d’informations XML (deuxième édition). Ed. John Cowan, et coll. 4 février 2004. W3C.org.

[XML-10]

Xml (Extensible Markup Language) 1.0 (troisième édition). Ed. Tim Bray, et al. 4 février 2004. W3C.org

[XMLENC]

Syntaxe et traitement du chiffrement XML. Ed. Takeshi Imamura, et al. 10 décembre 2002. W3C.org.

[XML-Query]

XQuery 1.0 : langage de requête XML. Ed. Scott Boag, et al. 23 juillet 2004. W3C.org

[Schéma XML]

Xml-Schema Part 0 : Primer. Ed. David Fallside. 2 mai 2001. W3C.org.

Xml-Schema Part 1 : Structures. Ed. Henry Thomson, et coll. 2 mai 2001. W3C.org.

XML-Schema Part 2 : Types de données. Ed. Paul Biron, et al. 2 mai 2001. W3C.org.

[XMLSIG]

Syntaxe et traitement des signatures XML. Ed. Donald Eastlake, et coll. 12 février 2004. W3C.org.

Spécifications des services web

[SOAP]

Protocoles d’accès aux objets simples (SOAP) 1.1. Ed. Don Box, et al. 8 mai 2000. W3C.org.

[SOAP-UDP]

SOAP-over-UDP. Harold Combs, et coll. Septembre 2004. BEA, Lexmark, Microsoft et Ricoh.

[MTOM]

Mécanisme d’optimisation du transfert de messages SOAP. Ed. Noah Mendelsohn, et al. 8 juillet 2004. W3C.org.

[UDDI]

Spécification de l’API UDDI version 2.04. Ed. Tom Bellwood. 19 juillet 2004. OASIS-Open.org.

[WSDL]

Web Service Description Language (WSDL) 1.1. Ed. Erik Christensen, et coll. 15 mars 2001. W3C.org.

[Adressage WS]

Adressage des services web (WS-Addressing). Don Box, et al. août 2004. BEA, IBM et Microsoft.

[WS-AT]

Web Services Atomic Transaction (WS-AtomicTransaction). Luis Felipe Cabrera, et al. septembre 2003. BEA, IBM et Microsoft.

[WS-BA]

Web Services Business Activity Framework (WS-BusinessActivity). Luis Felipe Cabrera, et al. janvier 2004. BEA, IBM et Microsoft.

[WS-Coord]

Web Services Coordination (WS-Coordination). Luis Felipe Cabrera, et al. Septembre 2003. BEA, IBM et Microsoft.

[WS-Discovery]

Découverte dynamique des services web (WS-Discovery). John Beatty, et al. Février 2004. Microsoft Corporation.

[WS-Enum]

Web Service Enumeration (WS-Enumeration). Don Box, et al. Septembre 2004. Microsoft Corporation.

[WS-Eventing]

Événements des services web (WS-Eventing). Luis Felipe Cabrera, et al. Septembre 2004. BEA, Microsoft et TIBCO.

[WS-Federation]

Langage de fédération des services web (WS-Federation). Siddharth Bajaj, et al. 8 juillet 2003. IBM, Microsoft, BEA, RSA Security et VeriSign.

[WS-FedActive]

WS-Federation : profil de demandeur actif. Siddharth Bajaj, et al. 8 juillet 2003. IBM, Microsoft, BEA, RSA Security et VeriSign.

[WS-FedPassive]

WS-Federation : Profil de demandeur passif. Siddharth Bajaj, et al. 8 juillet 2003. IBM, Microsoft, BEA, RSA Security et VeriSign.

[WS-MEX]

Web Services Metadata Exchange (WS-MetadataExchange). Keith Ballinger, et al. mars 2004. BEA, IBM, Microsoft et SAP.

[WS-Policy]

Web Services Policy Framework (WS-Policy). Don Box, et al. 3 septembre 2004. BEA, IBM, Microsoft et SAP.

[WS-PA]

Pièce jointe de stratégie de services web (WS-PolicyAttachment). Don Box, et al3 septembre 2004. BEA, IBM, Microsoft et SAP.

[WS-RM]

Services Web Reliable Messaging (WS-ReliableMessaging). Ruslan Bilorusets, et al. Mars 2004. BEA, IBM, Microsoft et TIBCO.

[WS-SecureConv]

Web Services Secure Conversation Language (WS-SecureConversation). Steve Anderson, et al. mai 2004. BEA Systems, Inc., Computer Associates International, Inc., International Business Machines Corporation, Layer 7 Technologies, Microsoft Corporation, Netegrity, Inc., Oblix Inc., OpenNetwork Technologies Inc., Ping Identity Corporation, Reactivity Inc., RSA Security Inc., VeriSign Inc. et Westbridge Technology.

[WS-Security]

Sécurité des services web : Sécurité des messages SOAP (WS-Security). Ed. Anthony Nadalin, et al. Mars 2004. OASIS-Open.org.

[WS-SecurityPolicy]

Web Services Security Policy Language (WS-SecurityPolicy). Giovanni Della-Libera, et al. 18 décembre 2002. IBM, Microsoft et VeriSign.

[WS-SecUsername]

Sécurité des services web : profil de jeton de nom d’utilisateur V1.0. Ed. Anthony Nadalin, et al. Mars 2004. OASIS-Open.org.

[WS-SecX509]

Sécurité des services web : profil de jeton X.509 v1.0. Ed. Phillip Hallam-Baker, et al. Mars 2004. OASIS-Open.org.

[WS-Transfer]

Transfert de service web (WS-Transfer). Ed. Don Box, et al. Septembre 2004. Microsoft Corporation.

[WS-Trust]

Web Services Trust Language (WS-Trust). Steve Anderson, et al. mai 2004. BEA Systems, Inc., Computer Associates International, Inc., International Business Machines Corporation, Layer 7 Technologies, Microsoft Corporation, Netegrity, Inc., Oblix Inc., OpenNetwork Technologies Inc., Ping Identity Corporation, Reactivity Inc., RSA Security Inc., VeriSign Inc. et Westbridge Technology, Inc.

[XOP]

Xml-binary Optimized Packaging (XOP). Ed. Noah Mendelsohn, et al. 8 juin 2004. W3C.org.

Profils d’interopérabilité

[WSI-BP10]

Profil de base version 1.0. Ed. Keith Ballinger, et al. 16 avril 2004. Organisation Services-Interoperability web.

[WSI-BSP10]

Profil de sécurité de base version 1.0 (brouillon de groupe de travail). Ed. Abbie Barbir, et al. 12 mai 2004. Organisation Services-Interoperability web.

[WS-DP]

Profil d’appareils pour les services web. Shannon Chan, et al. mai 2004. Microsoft Corporation.

Autres ressources

[SCIAN]

Système de classification des industries de l’Amérique du Nord (SCIAN). Association NAICS.

[SIC]

Classification industrielle standard (SIC).

[UBR]

Registre des entreprises UDDI.

[WS-I]

Web Services-Interoperability Organization (WS-I).

[Gris & Reuter]

Traitement des transactions : concepts et techniques. Jim Gray et Andreas Reuter. Morgan-Kaufmann, 1993.