Services web sécurisés, fiables et traités : architecture et composition

 

Septembre 2003

IBM Corporation Donald F. Ferguson   IBM Fellow et Président  IBM Software Group Architecture Board Tony Storey  IBM Fellow

Microsoft Corporation   Brad Lovering  Ingénieur distingué    John Shewchuk  Architecte des services web

Contenu

1.0 Introduction
   1.1 Services composables
   1.2 Un exemple de composition dans la pratique
2.0 Services web : architecture Service-Oriented
   2.1 Les services sont décrits par schéma et par contrat et non par type
   2.2 La compatibilité des services est plus que la compatibilité de type
   2.3 L’orientation du service part du principe que de mauvaises choses peuvent et vont se produire
   2.4 L’orientation du service permet une liaison flexible des services
3.0 Spécifications et fonctions du service web
   3.1 Une approche composable des services web
   3.2 Principes de base – Transports et messagerie
      3.2.1 Transports – HTTP, HTTP/S, SMTP
      3.2.2 Formats de message – XSD
      3.2.3 WS-Addressing
   3.3 Description
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 Obtention de descriptions
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 Garanties de service
   3.5 Sécurité
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 Messagerie fiable
      3.6.1 WS-ReliableMessaging
   3.7 Transactions
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 Composition du service
      3.8.1 BPEL4WS
4.0 Services web dans la pratique – Un exemple
   4.1 Partie 1 : L’expérience client
   4.2 Partie 2 : L’expérience du fournisseur
5.0 Conclusions
6.0 Accusés de réception

1.0 Introduction

Aujourd’hui, les services web, en particulier les services distribués qui traitent les messages SOAP encodés au format XML, envoyés via HTTP et décrits à l’aide du langage WSDL (Web Services Description Language) sont déployés à grande échelle. (Les termes XML, SOAP et HTTP sont couramment utilisés aujourd’hui et, à bien des égards, leur utilisation a dépassé leurs acronymes d’origine. Pour des fins d’exhaustivité, ces acronymes sont répertoriés ici : XML—eXtensible Markup Language, SOAP—Simple Object Access Protocol et HTTP—HyperText Transfer Protocol.) Les services web sont utilisés dans une gamme de scénarios d’intégration d’applications : du simple, ad hoc, derrière le pare-feu, au partage de données à la vente au détail sur Internet à très grande échelle et au commerce de devises. Et de plus en plus de services web sont appliqués dans des scénarios mobiles, d’appareils et de grille.

Les services web fournissent une interopérabilité entre les composants logiciels qui peuvent communiquer entre différentes entreprises et résider sur différentes infrastructures. Cela résout l’un des problèmes les plus critiques auxquels les clients, les développeurs de logiciels et les partenaires sont confrontés. HTTP et SOAP fournissent une communication et une interopérabilité des messages. WSDL fournit la description du service pour prendre en charge l’interopérabilité entre les outils de développement ; il complète l’interopérabilité des communications avec la possibilité d’échanger des définitions d’interface.

L’ensemble de base des spécifications de service Web permet aux clients et aux éditeurs de logiciels de résoudre des problèmes importants. S’appuyant sur leur succès, de nombreux développeurs et entreprises sont prêts à s’attaquer à des problèmes plus difficiles avec la technologie des services Web. Le succès des services Web a conduit les développeurs à désirer encore plus de fonctionnalités des services Web. Étant donné que l’interopérabilité significative des outils et des communications a réussi, les développeurs s’attendent maintenant à ce que les fonctions améliorées interagissent.

En plus de l’interopérabilité des messages de base et de l’échange d’interface, les développeurs ont de plus en plus besoin que les services d’application de niveau supérieur interagissent. De nombreuses applications commerciales s’exécutent dans un environnement (« middleware » ou « systèmes d’exploitation ») qui prend en charge des fonctions telles que la sécurité et les transactions.

IBM, Microsoft et d’autres acteurs du secteur sont souvent invités à rendre les services Web plus sécurisés, plus fiables et plus capables de prendre en charge les transactions. En outre, nous sommes invités à fournir ces fonctionnalités tout en conservant la simplicité et l’interopérabilité essentielles que l’on trouve aujourd’hui dans les services Web.

Ce document fournit une vue d’ensemble succincte de l’ensemble des spécifications de service Web qui répondent à ces besoins. Pour plus d’informations sur les spécifications, nous fournissons des références aux documents réels. L’objectif main de ce document est de définir brièvement la valeur que ces spécifications fournissent à nos clients. Nous décrivons également comment ces spécifications se complètent pour composer des environnements robustes pour les applications distribuées.

Nous sommes confrontés à un défi d’ingénierie clé : comment donner aux services Web de nouvelles fonctionnalités de sécurité, de fiabilité et de transaction sans ajouter plus de complexité que nécessaire ?

1.1 Services composables

Comme nous l’avons fait avec SOAP et WSDL, IBM, Microsoft et nos partenaires ont suivi le principe de conception de la composabilité dans la définition des spécifications de service Web. L’approche que nous avons suivie est basée sur le principe de conception de la composabilité dans la définition des spécifications de service Web. Chaque spécification que nous avons développée résout un besoin immédiat et est précieuse en soi. Par exemple, les développeurs peuvent adopter une messagerie fiable pour simplifier le développement de leur solution ou adopter BPEL4WS pour définir leurs compositions de service. Et bien que chaque spécification soit autonome, elles sont conçues pour être combinées et fonctionner les unes avec les autres.

Nous utilisons le terme composabilité pour décrire des spécifications indépendantes qui peuvent être combinées pour fournir des fonctionnalités plus puissantes. Les fournisseurs de systèmes d’exploitation et d’intergiciels peuvent prendre en charge des fonctionnalités composées, par exemple, les fournisseurs peuvent intégrer une prise en charge fiable de la messagerie pour la communication des processus BPEL4WS. Cet exemple combine deux spécifications indépendantes pour simplifier le développement des processus de communication en éliminant la nécessité de gérer les erreurs de communication des messages lors de la conception du processus.

La composabilité permet la consommation incrémentielle ou la découverte progressive de nouveaux concepts, outils et services. Les développeurs ont seulement besoin d’apprendre et d’implémenter ce qui est nécessaire, et pas plus. La complexité de la solution augmente uniquement parce que les exigences du problème augmentent, et n’est pas due à la technologie « ballonnement ».

La composabilité est et continue d’être l’un des principaux objectifs de conception des services Web. Au cours des dernières années, nous avons défini les spécifications de service Web les plus basiques (SOAP et WSDL) pour prendre en charge intrinsèquement la composition. L’une des caractéristiques fondamentales d’un service Web est une structure de message en plusieurs parties régulière. Cette structure permet la composition de nouvelles fonctionnalités. De nouveaux éléments de message prenant en charge de nouveaux services peuvent être ajoutés aux messages d’une manière qui ne modifie pas le traitement des fonctionnalités existantes. Par exemple, il est possible d’ajouter indépendamment des identificateurs de transaction et des numéros de séquence de messagerie fiables. Les deux extensions ne sont pas en conflit l’une avec l’autre et sont compatibles avec les structures de message préexistantes.

Figure 1. La composabilité permet d’utiliser des éléments en fonction des besoins.

La figure 1 montre un message de services Web simple qui contient des éléments pour WS-Addressing, WS-Security et WS-ReliableMessaging. Notez que les éléments WS-Addressing, WS-Security et WS-ReliableMessaging sont indépendants et que ces éléments peuvent être utilisés indépendamment sans modifier le traitement d’autres éléments.

Cette caractéristique permet de définir la sécurité, la fiabilité et les transactions en termes d’éléments de message composables .

La notion de composition permet également la création d’un ensemble spécifique de services Web composables bien définis qui prennent en charge la sécurité, la fiabilité, etc. Ces services bien définis spécifient le comportement des services nécessaires pour prendre en charge les fonctionnalités de service Web de niveau supérieur. Par exemple, le service de jeton sécurisé défini dans WS-Trust émet et valide les éléments de sécurité dans les messages.

De plus, il est important que les consommateurs d’un service soient en mesure de déterminer les garanties de service prises en charge et requises. Les services doivent documenter leurs exigences et la prise en charge des transactions, de la sécurité, de la messagerie fiable, etc. WS-Policy permet aux services web d’augmenter de manière incrémentielle leur WSDL pour documenter les fonctions de transaction, de sécurité et de fiabilité qu’ils prennent en charge ou nécessitent. WSDL et WS-Policy permettent la composition pour la description des services. Cela permet aux autres parties de comprendre quels éléments de message et quels services de niveau supérieur utiliser lors de l’interaction avec le service.

1.2 Un exemple de composition dans la pratique

La figure 2 fournit une vue d’ensemble de la composition dans la pratique. Un client et un fournisseur utilisent les services Web pour traiter les commandes.

Figure 2 : Composition dans un système de traitement des commandes

Lors de la création de ces services Web, les développeurs utilisent WSDL et les documents associés pour décrire leur interface métier. Ces documents WSDL décrivent l’ensemble des messages que les services Web du client et du fournisseur traiteront, par exemple le message SubmitPurchaseOrder (SubmitPO) qui transite du client vers le fournisseur. Cela est illustré en haut de la figure 2. Une fois les éléments principaux de l’application en place, les développeurs peuvent décider de prendre en charge une fonctionnalité supplémentaire, par exemple, ici, ils décident de traiter la commande. Pour ce faire, ils composent les éléments suivants dans la structure existante :

• Les services associent WS-Policy documents décrivant leur prise en charge des transactions à leur description WSDL de leurs services. Notez que ces instructions de stratégie augmentent, mais ne modifient pas fondamentalement les fonctionnalités métier existantes.
• Pour prendre en charge le traitement traité, les services ajoutent un élément de message supplémentaire décrivant les transactions qui composent avec, mais ne modifient pas fondamentalement, les messages d’application existants.
• Lorsque le service fournisseur reçoit des messages qui contiennent l’élément transactionnel, il utilise ces informations pour communiquer avec un service Web désigné appelé coordinateur qui prend en charge la fonction de transaction. Là encore, ce service Web supplémentaire ajoute simplement à la solution et ne nécessite pas de modification de la description de la fonctionnalité métier existante.
• Enfin, les services peuvent implémenter des opérations supplémentaires pour prendre en charge l’intégration au service coordinateur des transactions.

Dans la figure précédente, ces éléments supplémentaires sont mis en surbrillance.

Le modèle est incrémentiel et composable pour les raisons suivantes :

• L’ajout des nouvelles fonctions peut être effectué indépendamment de l’ajout d’autres fonctions.
• L’ajout de la fonction n’interrompt pas les messages existants, la logique de traitement des messages ou WSDL.

La composabilité est un principe de conception de plus en plus important, mais l’approche n’est pas toujours bien comprise. Bien que les spécifications individuelles du service Web définissent la façon dont les éléments et les services individuels interagissent, ce livre blanc est destiné à fournir une vue d’ensemble de la façon dont la collection de spécifications peut être composée pour fournir des services Web interopérables plus sophistiqués.

2.0 Services web : architecture Service-Oriented

Au cours des dernières années, nous avons été témoins d’une foule d’activités centrées sur le développement de services Web. Avec toutes ces activités, il est important de prendre du recul et de poser la question « Pourquoi ? » Certes, les services Web n’activent pas de nouveaux types de fonctionnalités de calcul, une fois que tous les services Web s’exécutent toujours sur des ordinateurs existants, en exécutant le même ensemble d’instructions et en accédant aux mêmes données. En outre, les protocoles de service Web dans de nombreux cas peuvent effectivement augmenter la surcharge de protocole pour une tâche donnée.

L’une des principales raisons pour lesquelles nous constatons un tel intérêt pour les services Web est que les services Web sont bien adaptés pour permettre une architecture Service-Oriented (SOA). Lorsque vous utilisez des services Web pour créer un SOA, les solutions se composent de collections de services autonomes, identifiés par des URL, avec des interfaces documentées à l’aide de WSDL et qui traitent des messages XML bien définis. SOA est un complément naturel aux approches orientées objet (OO), procédurales et centrées sur les données de l’implémentation de la solution. En effet, lors de la création d’un système SOA, les services individuels sont généralement construits à l’aide d’une ou plusieurs de ces technologies.

Une architecture Service-Oriented diffère des systèmes oo et procédural par un aspect clé : la liaison. Les services interagissent en fonction des fonctions qu’ils fournissent et de la façon dont ils les fournissent. Les systèmes oo et procédural lient des éléments en fonction du type ou du nom. Les sections suivantes fournissent plus de détails.

2.1 Les services sont décrits par schéma et par contrat et non par type

Contrairement aux systèmes précédents, le modèle de service Web ne fonctionne pas sur la notion de types partagés qui nécessitent une implémentation commune. Au lieu de cela, les services interagissent uniquement en fonction des contrats (WSDL/BPEL4WS pour le comportement de traitement des messages) et des schémas (WSDL/XSD pour la structure de message). Cela permet au service de décrire la structure des messages qu’il peut envoyer et/ou recevoir et séquencer des contraintes sur ces messages. La séparation entre la structure et le comportement et la description explicite et vérifiable de ces caractéristiques simplifie l’intégration dans des environnements hétérogènes.

En outre, ces informations caractérisent suffisamment l’interface de service pour que l’intégration d’applications ne nécessite pas d’environnement d’exécution partagé pour créer la structure ou le comportement des messages.

Le modèle orienté service suppose un environnement entièrement distribué où il est difficile, voire impossible, de propager les modifications de schéma et/ou de contrat à toutes les parties qui ont rencontré un service. L’orientation du service implique que les contrats et le schéma doivent rester rétrocompatibles et peuvent contenir des informations qui ne sont pas comprises de manière incomplète par des systèmes de traitement particuliers.

Pour cette raison, les technologies de contrat et de schéma conçues pour une utilisation dans les conceptions orientées service offrent plus de flexibilité que les interfaces orientées objet traditionnelles. En particulier, les services utilisent des fonctionnalités telles que les caractères génériques d’éléments XML (par exemple, xsd:any), les extensions de schéma et les blocs d’en-tête SOAP facultatifs pour faire évoluer les services de manière à ne pas interrompre les applications déployées. Ces caractéristiques sont la clé de la composabilité des services Web.

2.2 La compatibilité des services est plus que la compatibilité de type

Les conceptions procédurales et orientées objet assimilent généralement la compatibilité des types à la compatibilité sémantique. L’orientation du service fournit un modèle plus riche pour déterminer la compatibilité. La compatibilité structurelle est basée sur le contrat (WSDL et éventuellement BPEL4WS) et le schéma (XSD) et peut être validée. En outre, l’avènement de WS-Policy fournit une analyse automatisée supplémentaire de la compatibilité de l’assurance de service entre les services. Cette opération est effectuée sur la base d’assertions explicites de fonctionnalités et d’exigences sous la forme d’instructions WS-Policy.

À l’aide de WS-Policy, les services décrivent leurs fonctionnalités et exigences d’assurance de service sous la forme d’une expression de stratégie lisible par ordinateur contenant des combinaisons d’assertions. Cela permet au service de se sélectionner les uns les autres en fonction du « comment » ou de la « qualité » qu’ils livrent leurs contrats,

Les assertions de stratégie sont identifiées par des noms stables et globalement uniques dont la signification est cohérente dans le temps et l’espace, quel que soit le service auquel l’assertion est appliquée. Les assertions de stratégie peuvent également avoir des paramètres qui qualifient l’interprétation exacte de l’assertion.

2.3 L’orientation du service part du principe que de mauvaises choses peuvent et vont se produire

Certaines approches précédentes des applications distribuées supposaient explicitement un espace de type commun, un modèle d’exécution et un modèle de référence de procédure/objet. En substance, le modèle de programmation « en mémoire » définissait le modèle de système distribué.

L’orientation du service suppose simplement que les services s’exécutent de manière autonome et qu’il n’existe aucune notion d’exécution locale ou d’environnement d’exploitation commun. Pour cette raison, une SOA suppose explicitement que les erreurs de communication, de disponibilité et de type sont courantes.

Pour maintenir l’intégrité du système, les conceptions orientées service s’appuient explicitement sur diverses technologies pour gérer les modes de défaillance partielle et asynchronisation. Les techniques telles que la messagerie asynchrone, les transactions, la messagerie fiable et le déploiement redondant sont la norme dans les systèmes orientés service.

En outre, contrairement au modèle en mémoire, l’orientation du service suppose que non seulement un message entrant peut être mal formé, mais également qu’il a été transmis à des fins malveillantes ou complètement inattendues. Par conséquent, les systèmes orientés service se protègent en faisant peser la charge de la preuve sur tous les expéditeurs de messages en exigeant des applications qu’elles prouvent que les droits requis ont été accordés à l’expéditeur. Cohérentes avec la notion d’autonomie des services, les architectures orientées service s’appuient généralement sur des relations d’approbation gérées par l’administration pour éviter les mécanismes d’authentification par service courants dans les applications web classiques.

2.4 L’orientation du service permet une liaison flexible des services

L’un des concepts fondamentaux de l’architecture orientée service (SOA) est la liaison flexible des services. Les modèles procéduraux, de composants et d’objets plus traditionnels lient les composants par le biais de références (pointeurs) ou de noms. Un SOA prend en charge la découverte plus dynamique des instances de service qui fournit l’interface, la sémantique et les garanties de service attendues par le demandeur.

Dans les systèmes procéduraux ou orientés objet, un appelant trouve généralement un serveur en fonction des types qu’il exporte ou d’un espace de noms partagé. Dans un système SOA, les appelants peuvent rechercher un service dans des registres tels que UDDI .

1. Il s’agit d’un message compatible avec les exigences de l’appelant. La compatibilité peut se produire via WSDL ou des messages correspondants provenant de schémas XML connus.
2. Qui documente la prise en charge des garanties de service requises par l’appelant. Par exemple, l’appelant peut souhaiter certaines approches en matière de sécurité ou de transactions.

La liaison souple par rapport à l’implémentation du service qui permet d’autres implémentations de comportement peut être utilisée pour répondre à diverses exigences métier. Par exemple, les implémentations alternatives peuvent correspondre à d’autres fournisseurs dans une chaîne d’approvisionnement permettant une réponse plus rapide à l’évolution des conditions du marché. De même, l’implémentation alternative peut être des centres de données distribués géographiquement qui permettent la tolérance aux sinistres.

3.0 Spécifications et fonctions du service web

Cette section fournit une vue d’ensemble des spécifications du service Web.

3.1 Une approche composable des services web

Cette section décrit brièvement les spécifications du service Web disponibles. Nous expliquons leur valeur aux fournisseurs de solutions, leur rôle dans une architecture plus large et comment ils se complètent.

La figure suivante fournit un regroupement général des spécifications de service Web publiées par IBM, Microsoft et d’autres. Notez que cette figure n’est pas destinée à impliquer une superposition stricte entre les groupes ; au lieu de cela, il est destiné à fournir une intuition sur les relations entre les zones fonctionnelles. Par exemple, la sécurité des messages ne nécessite pas description et de même Description est un concept de temps de développement utile pour la messagerie.

Figure 3. Architecture du protocole des services Web interopérables

3.2 Principes de base — Transports et messagerie

Si je vous envoie une lettre écrite en Français mais que vous attendiez un appel téléphonique en anglais, nous ne communiquerons pas. L’interopérabilité des services Web est confrontée au même problème; nous y répondons en fournissant un ensemble commun de technologies de transport et de messagerie.

En outre, pour s’assurer que ces technologies sont efficaces dans la pratique, IBM, Microsoft et d’autres ont créé l’organisation d’interopérabilité des services web (WS-I). Récemment, le WS-I a publié un profil de base qui documente formellement les mécanismes de transport et de messagerie du service Web interopérables.

3.2.1 Transports : HTTP, HTTP/S, SMTP

Cet ensemble de spécifications définit les principaux mécanismes de communication pour le déplacement de données brutes entre les services Web.

HTTP, HTTP/S et SMTP (Simple Mail Transport Protocol) sont des exemples dans ce groupe. Les implémentations de service web peuvent également prendre en charge d’autres transports, mais il est essentiel de prendre en charge les protocoles standard et interopérables.

3.2.2 Formats de message — XSD

Le groupe de spécifications suivant définit des mécanismes interopérables pour l’encodage des messages de service Web pour le transport. Les transports déplacent des blocs de « octets » entre les services. Cela n’est utile que si les participants peuvent convertir les octets en structures de données utiles que leur application traite.

Le groupe de spécifications de messagerie définit comment mettre en forme les messages correctement. Les définitions de schéma XML et XML fournissent le mécanisme permettant d’accepter de manière abstraite les structures de message (données). SOAP définit l’encodage standard pour la représentation des messages XML dans les informations d’octet que les services échangent sur les transports.

3.2.3 WS-Addressing

Les messages et les réponses vont quelque part et proviennent de quelque part. WS-Addressing fournit une approche interopérable et indépendante du transport pour identifier les expéditeurs et les récepteurs de messages. WS-Addressing fournit également une approche plus précise pour identifier des éléments spécifiques au sein d’un service qui envoient ou doivent recevoir un message.

Aujourd’hui, la plupart des systèmes utilisant des services Web encodent la destination d’un message de service Web avec une URL qui est placée dans le transport HTTP. La destination de la réponse est déterminée par l’adresse de transport de retour. Cette approche s’appuie sur le modèle de serveur de navigateur de base de HTTP.

En utilisant l’approche d’aujourd’hui, les informations source et de destination ne font pas partie du message lui-même. Cela peut entraîner plusieurs problèmes. Les informations peuvent être perdues si une connexion de transport se termine (par exemple, si la réponse prend beaucoup de temps et que la connexion expire) ou si le message est transféré par un intermédiaire tel qu’un pare-feu.

WS-Addressing fournit un mécanisme pour placer la cible, la source et d’autres informations d’adresse importantes directement dans le message de service Web. En bref, WS-Addressing dissocie les informations d’adresse d’un modèle de transport spécifique.

Dans de nombreux scénarios, les messages sont ciblés directement vers un service et les informations d’adressage dans le message peuvent être décrites simplement à l’aide d’une URL. Mais dans la pratique, nous constatons souvent que les messages ciblent des éléments ou des ressources spécifiques au sein d’un service. Par exemple, un service de coordination peut coordonner de nombreuses tâches différentes. Le coordinateur doit associer la plupart des messages entrants à une tâche spécifique instance qu’il gère et non au service de coordination lui-même. 

WS-Addressing fournit un mécanisme simple mais puissant appelé référence de point de terminaison pour l’adressage des entités gérées par un service. Bien que ces informations puissent être encodées de manière ad hoc dans l’URL du service, les références de point de terminaison fournissent un élément XML standard qui permet une approche structurée pour encoder cet adressage affiné.

La combinaison d’un contrôle précis sur l’adressage couplée à l’encodage neutre du transport de la source et de la destination du message permet d’envoyer des messages de service Web à travers une gamme de transports, par le biais d’intermédiaires, et permet des modèles de communication asynchrones et de durée prolongée.

WS-Addressing permet également à un expéditeur d’indiquer où une réponse doit aller de manière indépendante du transport. La réponse à un message peut ne pas nécessairement être envoyé à l’expéditeur. Dans HTTP par exemple, sans WS-Addressing il est impossible de spécifier que la réponse doit être envoyée ailleurs.

Ces améliorations apportées au modèle de messagerie permettent d’utiliser les services web pour prendre en charge de nombreux scénarios métier. Par exemple, certaines tâches bancaires nécessitent un examen humain pour approbation à certaines étapes. Il existe généralement de nombreuses instances actives de la tâche à tout moment. WS-Addressing fournit un mécanisme général pour associer des messages entrants ou sortants à des tâches spécifiques. Le mécanisme utilisé par le service est transparent pour ceux qui utilisent le service via une référence de point de terminaison.

3.3 Description

Les spécifications de transport et de message permettent aux services web de communiquer à l’aide de messages. Mais comment les participants savent-ils quels sont les messages ? Comment un service web documente-t-il ou décrit-il les messages qu’il envoie et reçoit ? L’utilisation d’un service Web nécessite une compréhension des messages que le service Web consommera et produira, c’est-à-dire l’interface du service Web. Le groupe de description des spécifications permet à un service Web d’exprimer son interface et ses fonctionnalités.

En plus de l’interopérabilité des messages ; ces spécifications permettent également l’interopérabilité des outils de développement. Les spécifications de description fournissent un modèle standard qui permet à différents outils de différents fournisseurs de prendre en charge les développeurs en collaboration. De la même façon que les services web isolent les partenaires des choix d’implémentation et d’infrastructure, les spécifications de description isolent les partenaires des choix d’outils de développement.

3.3.1 WSDL

Le langage WSDL (Web Services Description Language) et le schéma XML (XSD) sont les spécifications de base de ce groupe. Le schéma XML permet aux développeurs et aux fournisseurs de services de définir des types XML pour les structures de données, par exemple, un bon de commande et des messages, par exemple le message CreatePO. WSDL permet à un service Web de documenter les messages qu’il reçoit et envoie. En d’autres termes, les « actions » ou « fonctions » effectuées par le service en termes de messages qu’il reçoit et envoie.

WSDL prend en charge une gamme de modèles d’interaction de message. Il prend en charge les messages d’entrée unidirectionnel qui n’ont aucune réponse, demande/réponse et envois unidirectionnel avec ou sans réponse. Les deux derniers modèles permettent à un service de spécifier d’autres services dont il a besoin.

Les améliorations WSDL proposées prennent en charge la documentation des protocoles et des formats de message pris en charge par un service, ainsi que l’adresse du service.

3.3.2 WS-Policy

Les définitions WSDL et XSD ne fournissent souvent pas suffisamment d’informations pour appeler un service Web. WSDL et XSD définissent la syntaxe d’interface du service, mais ils n’expriment pas d’informations sur la façon dont le service fournit son interface ou ce que le service attend de l’appelant. Par exemple, le service nécessite-t-il une sécurité ou implémente-t-il des transactions ?

WS-Policy permet à un service de spécifier ce qu’il attend des appelants et comment il implémente son interface. WS-Policy est essentiel pour atteindre l’interopérabilité au niveau supérieur du fonctionnement fonctionnel du service. La sécurité, les transactions, la messagerie fiable et d’autres spécifications nécessitent un schéma WS-Policy concret. Ceux-ci permettent aux services de décrire l’assurance fonctionnelle qu’ils attendent de et fournissent aux appelants.

L’infrastructure WS-Policy fournit un modèle de base pour définir des expressions de stratégie.

WS-Policy prend en charge une grammaire pour l’agrégation des instructions de stratégie et permet la construction d’ensembles de stratégie plus flexibles et complets.

WS-PolicyAttachment spécifie comment associer un jeu de stratégies à des messages XML et des éléments WSDL (opérations et portTypes).

Ensemble, WS-Policy et WS-PolicyAttachment fournissent le framework. Les spécifications individuelles définissent leurs instructions de stratégie et leur schéma spécifiques au domaine.

Enfin, @PageWS-PolicyAssertions fournit un ensemble fondamental d’instructions de stratégie communes qui peuvent être utilisées pour atteindre l’interopérabilité.

3.3.3 Obtention de descriptions

XML, XSD, WSDL et WS-Policy prennent en charge la description de l’interface et des garanties de service pour un service. Mais comment les utilisateurs potentiels du service trouvent-ils ces informations ?

À l’heure actuelle, l’approche la plus courante consiste à échanger des messages électroniques ou à utiliser le bouche à oreille. Un modèle évolutif à usage plus général est nécessaire. Il existe deux options : le service peut accéder directement au service pour obtenir des informations à l’aide de WS-MetadataExchange ou choisir d’utiliser un service UDDI qui agrège ces informations pour plusieurs services cibles.

Les développeurs utilisent WS-MetadataExchange lorsqu’ils ont une référence à un service et qu’ils ont besoin de comprendre ce qu’il fait. Les développeurs utilisent UDDI lorsqu’ils souhaitent trouver une référence à un service qui prend en charge un ensemble spécifique de fonctions.

3.3.4 WS-MetadataExchange

Comme décrit ci-dessus, les services fournissent généralement des informations telles que WSDL, WS-Policy et XSD, qui décrivent le service lui-même. Collectivity, nous faisons référence aux informations sur le service en tant que métadonnées. La spécification WS-MetadataExchange permet à un service de fournir des métadonnées à d’autres personnes par le biais d’une interface de services Web. Étant donné uniquement une référence à un service Web, un utilisateur potentiel peut accéder à un ensemble d’opérations WSDL/SOAP pour récupérer les métadonnées qui décrivent le service. Les clients peuvent utiliser WS-MetadataExchange au moment de la conception, lors de la création de leurs clients ou au moment de l’exécution.

3.3.5 UDDI

Il est souvent utile de collecter des métadonnées sur une collection de services et de rendre les informations disponibles dans un formulaire pouvant faire l’objet d’une recherche. Ces services d’agrégation de métadonnées constituent un référentiel utile dans lequel les organisations peuvent publier les services qu’elles fournissent, décrire les interfaces de leurs services et activer des taxonomies de services spécifiques à un domaine. La spécification UDDI (Universal Description and Discovery Interface) définit un service d’agrégation de métadonnées.

Les solutions peuvent interroger UDDI au moment de la conception pour trouver des services compatibles avec leurs besoins. Les développeurs peuvent utiliser ces services dans la définition de leurs workflows BPEL4WS, par exemple. Les solutions peuvent également interroger UDDI au moment de l’exécution. Dans ce scénario, l’appelant « connaît » l’interface dont il a besoin et recherche un service qui répond à ses exigences fonctionnelles ou qui est fourni par un partenaire connu.

Notez que l’un des mécanismes qui peuvent être utilisés pour remplir un service UDDI avec des métadonnées consiste à acquérir les métadonnées des services à l’aide de WS-MetadataExchange.

3.4 Garanties de service

Les services web ont généré tant d’enthousiasme en partie en raison de leur capacité à relier des systèmes disparates. Les développeurs ont produit de nombreuses solutions entièrement fonctionnelles en utilisant les fonctionnalités de base du transport, de la messagerie et de la description. Toutefois, pour être acceptés par les développeurs qui créent des solutions d’intégration plus puissantes, les services web doivent fournir des fonctionnalités pour garantir le même niveau d’assurance de service que les solutions d’intergiciels plus traditionnelles. Il ne suffit pas d’échanger simplement des messages. Les applications et services résident dans des intergiciels et des systèmes qui fournissent des fonctions de niveau supérieur précieuses telles que la sécurité, la fiabilité et les opérations traitées. Les services web doivent fournir un mécanisme d’interopérabilité entre ces fonctions.

3.5 Sécurité

Cette @Pagefamille de spécifications est essentielle pour les services Web inter-organization. Ces spécifications prennent en charge l’authentification et l’intégrité des messages, la confidentialité, la confiance et la confidentialité. Ils prennent également en charge la fédération de la sécurité entre différentes organisations.

3.5.1 WS-Security

WS-Security est le bloc de construction de base pour les services Web sécurisés. Aujourd’hui, la plupart des services Web distribués s’appuient sur la prise en charge au niveau du transport pour les fonctions de sécurité. Par exemple, l’authentification HTTP/S et BASIC-Auth. Ces approches de la sécurité fournissent le minimum nécessaire pour une communication sécurisée. Le niveau de fonction qu’ils fournissent, cependant, est considérablement inférieur à celui fourni par les intergiciels existants et les environnements distribués.

Deux exemples mettent en évidence les lacunes de BASIC-Auth et HTTP/S.

• A envoie un message au service B. B traite partiellement les messages et le transfère au service C. HTTP/S autorise l’authentification, la confidentialité et l’intégrité entre A-B et B-C. Toutefois, C et A ne peuvent pas s’authentifier mutuellement ou masquer les informations de B.
• Pour que A, B et C utilisent BASIC-Auth pour l’authentification. Ils doivent partager les mêmes informations d’utilisateur et de mot de passe répliquées. C’est inacceptable dans de nombreux scénarios.

WS-Security résout ces problèmes. Il prend en charge les éléments suivants :

• Jetons de sécurité signés et chiffrés. A peut générer un jeton que C peut vérifier comme provenant de A. B ne peut pas falsifier le jeton.
• Un peut signer les éléments sélectionnés ou l’intégralité du message. Cela permet à B et C de confirmer que le message n’a pas changé depuis que A l’a envoyé.
• Un peut sceller le message ou les éléments sélectionnés. Cela garantit que seul le service prévu pour ces éléments peut utiliser les informations. Cela empêche B de voir les informations destinées à C et vice versa.

WS-Security utilise des modèles de sécurité existants (Kerberos, X509, etc.). Les spécifications définissent concrètement comment utiliser les modèles existants de manière interopérable. Les calculs de service web multi-tronçons et multipartis ne peuvent pas être sécurisés sans WS-Security.

3.5.2 WS-Trust

La sécurité repose sur des relations d’approbation prédéfinies. Kerberos fonctionne parce que les participants « approuvent » le Centre de distribution de clés Kerberos. PKI fonctionne parce que les participants approuvent les autorités de certification racine. WS-Trust définit un modèle extensible pour la configuration et la vérification des relations d’approbation.

Le concept clé dans WS-Trust est un service de jeton de sécurité (STS). Un STS est un service web unique qui émet, échange et valide des jetons de sécurité. WS-Trust permet aux services web de configurer et de convenir des serveurs de sécurité auxquels ils « font confiance » et de s’appuyer sur ces serveurs.

Le STS a une large applicabilité en ce qu’il peut être utilisé pour émettre des jetons de sécurité qui font un large éventail d’assertions. Dans de nombreux cas, il sera utilisé pour émettre les mêmes assertions, mais dans des formats différents. Par exemple, un STS peut émettre un jeton Kerberos affirmant que le détenteur de la clé est Susan et qu’il peut le faire sur la base d’un certificat X.509 émis par une autorité de certification approuvée. Cela permet aux organisations qui utilisent différentes technologies de sécurité de se fédérer. Un STS peut également émettre un jeton de sécurité affirmant que le titulaire de la clé est membre du groupe BankTellers sur la base d’un jeton de sécurité entrant qui affirme une revendication d’identité.

3.5.3 WS-SecureConversation

Certains scénarios de service Web impliquent uniquement l’échange sporadique de quelques messages. WS-Security prend facilement en charge ce modèle. D’autres scénarios impliquent des conversations multi-messages de longue durée entre les services Web. WS-Security prend également en charge ce modèle, mais la solution n’est pas optimale.

Il existe deux utilisations sous-optimales de WS-Security dans ces scénarios :

• Utilisation répétée d’opérations de chiffrement coûteuses en calcul, telles que la validation de clé publique.
• Envoi et réception de nombreux messages à l’aide des mêmes clés de chiffrement, fournissant plus d’informations qui permettent aux attaques par force brute de « casser le code ».

Pour ces raisons, des protocoles comme HTTP/S utilisent des clés publiques pour effectuer une négociation simple qui définit des clés spécifiques à une conversation. Cet échange de clés permet des implémentations de sécurité plus efficaces et réduit également la quantité d’informations chiffrées avec un ensemble spécifique de clés.

WS-SecureConversation offre une prise en charge similaire pour WS-Security. Les participants utilisent souvent WS-Security avec des clés publiques pour démarrer une « conversation » ou une « session », et utilisent WS-SecureConversation pour convenir de clés spécifiques à la session pour la signature et le chiffrement des informations.

3.5.4 WS-Federation

WS-Federation permet à un ensemble d’organisations d’établir un domaine de sécurité virtuel unique. Par exemple, un agent de voyages, une compagnie aérienne et une chaîne d’hôtels peuvent créer une telle fédération. Un utilisateur final qui « se connecte » à un membre de la fédération s’est effectivement connecté à tous les membres. WS-Federation définit plusieurs modèles pour fournir une sécurité fédérée via des protocoles entre les topologies WS-Trust et WS-SecureConversation.

En outre, les clients ont souvent des « propriétés » lorsqu’ils traitent avec une entreprise. Un exemple est une préférence pour les sièges de fenêtre ou d’allée, ou une voiture de taille moyenne. WS-Federation permet aux membres de configurer un espace de propriété fédéré. Cela permet à chaque participant d’avoir un accès contrôlé sécurisé aux informations de propriété de chaque membre sur les utilisateurs finaux.

Les propriétés et les informations sur les individus peuvent être étroitement détenues à des fins de protection de la vie privée ou parce que ces informations offrent un avantage concurrentiel à un membre spécifique. Pour prendre en charge ces exigences, WS-Federation prend en charge un modèle de pseudonyme. Les utilisateurs qui se sont authentifiés auprès de l’agence de voyage ont généré des « alias » d’agence dans leurs interactions avec la compagnie aérienne ou l’hôtel. Cela protège la confidentialité de l’utilisateur final et l’avantage concurrentiel que l’agence de voyages peut obtenir en connaissant les propriétés de l’utilisateur.

3.6 Messagerie fiable

Dans un monde Internet, presque tous les canaux de communication ne sont pas fiables. Les messages disparaissent. Les connexions s’interrompent.

Sans norme de messagerie fiable, les développeurs d’applications de service web doivent créer ces fonctions dans leurs applications. Les approches et techniques de base sont bien comprises, par exemple de nombreux systèmes d’exploitation et d’intergiciels garantissent que les messages ont des identificateurs uniques, fournissent des numéros de séquence et utilisent la retransmission en cas de perte de messages. Si les développeurs de service web d’application implémentent ces modèles dans leurs applications. Ils peuvent faire des hypothèses différentes ou faire des choix de conception, ce qui entraîne peu ou pas de messages fiables.

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging définit des mécanismes qui permettent aux services Web d’assurer la remise des messages sur des réseaux de communication non fiables.

WS-ReliableMessaging garantit que les services implémentent des approches interopérables et permet également aux fournisseurs d’exécution de faciliter le développement d’applications en fournissant des services qui implémentent les protocoles. Cela simplifie considérablement la tâche de développement d’applications. La logique métier a alors beaucoup moins de conditions d’erreur qu’elle doit gérer.

Enfin, le secteur dispose d’un ensemble complet d’intergiciels orientés message pour le routage et la distribution fiables des messages. Chaque implémentation utilise des protocoles propriétaires. WS-Reliable protocoles de messagerie permettent à différents systèmes d’exploitation et intergiciels d’échanger des messages de manière fiable. Ainsi, il prend en charge le pontage de deux infrastructures différentes en un seul modèle logiquement complet de bout en bout.

3.7 Transactions

Un scénario métier complexe peut nécessiter l’échange de plusieurs ensembles de messages par plusieurs parties. Par exemple, un ensemble d’institutions financières qui mettent en place une offre financière qui implique des polices d’assurance, des rentes, des comptes de chèque et des comptes de courtage. Les messages multiples échangés entre les participants constituent une « tâche » ou un « objectif » logique.

Pour réussir, les parties doivent être en mesure de :

1. Démarrez de nouvelles tâches coordonnées.
2. Associez des opérations à leur tâche logique. Les parties peuvent configurer plusieurs comptes pour différents clients en même temps.
3. S’entendre sur le résultat du calcul. Par exemple, est-ce que tout le monde est d’accord pour dire que les packages financiers ont été mis en place ?

WS-Coordination, WS-AtomicTransaction et WS-BusinessActivity prennent en charge ces exigences.

3.7.1 WS-Coordination

WS-Coordination@Pageest un mécanisme général permettant de démarrer et de se mettre d’accord sur le résultat des tâches de service Web multipartie et multi-messages. WS-Coordination comporte trois éléments clés :

1. Élément de message appelé contexte de coordination qui circule sur tous les messages échangés par les services Web pendant le calcul. Le contexte de coordination contient la référence de point de terminaison WS-Addressing au service de coordination et contient à son tour des informations permettant d’identifier la tâche spécifique en cours de coordination.
2. Service coordinateur. Le service coordinateur fournit un service, décrit à l’aide de WSDL, qui permet de démarrer une tâche coordonnée, de mettre fin à une tâche coordonnée, de permettre à un participant de s’inscrire dans une tâche et de produire un contexte de coordination qui fait partie de tous les messages au sein d’un groupe.
3. Le service de coordination comprend également une interface, définie dans WSDL, que les services participants utilisent pour être informés du résultat de la tâche coordonnée.

Un service web qui reçoit un message avec un nouveau contexte de coordination s’inscrit auprès du service coordinateur dans le contexte afin de recevoir des informations sur les résultats. D’autres spécifications peuvent renforcer cette infrastructure pour les exigences spécifiques au domaine et à l’assurance.

WS-Coordination est une infrastructure et une fonctionnalité générales. WS-AtomicTransaction et WS-BusinessActivity étendre cette infrastructure pour permettre aux participants au calcul distribué de déterminer de manière robuste les résultats.

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction définit un ensemble spécifique de protocoles qui se connectent au modèle WS-Coordination pour implémenter des protocoles de transaction atomiques en deux phases traditionnels. Il est important de noter que le modèle atomique en deux phases ne concerne que les services impliqués. Les sites ou les services d’infrastructure offrant des services peuvent publier une validation en deux phases, mais utiliser un autre modèle intra-entreprise comme la compensation ou le contrôle de version. Cette liberté rend un modèle de validation en deux phases simple plus utile pour les calculs Internet de longue durée.

3.7.3 WS-BusinessActivity

WS-BusinessActivity définit un ensemble spécifique de protocoles qui se connectent au modèle WS-Coordination pour implémenter des protocoles transactionnels de longue durée basés sur la compensation. Bien que BPEL4WS définisse un modèle de transaction pour les processus métier, il est WS-BusinessActivity qui spécifie le rendu du protocole correspondant. Il s’agit là encore d’un exemple de composabilité des spécifications des services Web.

3.8 Composition du service

L’élément le plus haut dans la superposition de services Web est la composition du service. La composition de service permet aux développeurs de « composer » des services qui échangent des messages SOAP et définissent leur interface dans WSDL et WS-Policy dans une solution d’agrégation. L’agrégat est un service Web composé.

3.8.1 BPEL4WS

La spécification BPEL4WS (Business Process Execution Language for Web Services) prend en charge la composition du service. Il permet aux développeurs de définir la structure et le comportement d’un ensemble de services Web qui implémentent conjointement une solution métier partagée. Chaque élément de l’ensemble de services définit son interface à l’aide de WSDL et WS-Policy. La solution composée est elle-même un service Web, qui prend en charge les messages HTTP/SOAP et définit son interface à l’aide de WSDL et WS-Policy.

La composition comporte trois aspects : structure, informations et comportement. BPEL4WS introduit trois constructions prenant en charge chaque aspect de composition.

Un partnerLink définit une association nommée entre le service composite et un service Web qui participe à la solution globale. Le service composite et le service participant définissent leurs interfaces les uns avec les autres à l’aide de WSDL et WS-Policy. Par exemple, il peut s’agir d’une association entre une entreprise de fabrication et un fournisseur.

Le concept partnerLink et les interfaces WSDL/WS-Policy entre la composition et les partenaires définissent la structure de la composition du service. Ils définissent les types de services qui collaborent pour former la composition, et les messages qu’ils échangent avec quels niveaux d’assurance (sécurité, transactions, etc.)

BPEL4WS prend également en charge la définition des informations de la composition du service. BPEL4WS définit le concept d’une variable. Le service composite définit un ensemble de variables, chacune ayant une définition XSD. L’état actuel d’un service spécifique est l’état de ses variables. Cela définit les messages qu’il a reçus ou envoyés.

Enfin, BPEL4WS prend en charge la définition du comportement du service composite par le concept d’activité. Un service défini par BPEL4WS est un ensemble d’activités ou « étapes », qui définissent le comportement du service. Les activités les plus basiques sont l’envoi d’un message à un partenaire ou la réception d’un message d’un partenaire. Chaque message correspond à une variable. BPEL4WS prend en charge le déplacement de données entre des variables.

L’un des aspects clés des activités BPEL4WS est que BPEL4WS fournit une prise en charge spéciale pour la définition d’un comportement visible externement (public) des services en autorisant l’utilisation contrôlée d’un comportement non déterministe. Par instance le fait qu’un crédit case activée soit exécuté d’une manière spécifique dans le processus de décision d’acceptation d’un bon de commande peut être une affaire privée pour un fournisseur. BPEL4WS permet de masquer le processus de décision en supprimant le comportement case activée de crédit de la description du processus, mais en montrant que la réponse au bon de commande peut être acceptation ou rejet. Ce type de processus abstrait peut être utilisé conjointement avec WSDL pour définir des protocoles métier interopérables entre les partenaires commerciaux et pour des domaines verticaux tels que la chaîne logistique.

BPEL4WS prend également en charge plusieurs approches pour contrôler le flux d’exécution des activités. Il s’agit notamment du séquencement et des flux basés sur des graphiques. BPEL4WS prend en charge les prédicats sur les variables pour déterminer les chemins de contrôle suivis par le service composite.

Pour résumer, BPEL4WS apporte deux ajouts aux spécifications de service Web précédemment définies.

1. BPEL4WS étend WSDL et WS-Policy prise en charge de la description des services. BPEL4WS prend en charge la combinaison de services Web en services d’agrégation et la documentation des associations entre les services, telles que le flux d’informations et le comportement. Cela permet de prendre en charge l’interopérabilité entre les outils de couche supérieure prenant en charge la conception collaborative des services Web.
2. BPEL4WS est un langage d’exécution. BPEL4WS permet aux développeurs de spécifier entièrement le comportement d’un service Web composite. IBM, Microsoft et d’autres partenaires fournissent des environnements qui exécutent des documents BPEL4WS et prennent en charge la liaison de temps de conception et d’exécution aux partenaires.

4.0 Services web dans la pratique — Un exemple

Le scénario suivant montre comment les spécifications WS peuvent être utilisées ensemble pour créer des services Web qui résolvent des besoins réels. Le scénario fournit un exemple des puissantes fonctionnalités disponibles pour les développeurs en raison de la composabilité des différentes spécifications WS.

Les services Web décrits dans ce scénario ont été créés pour une démonstration conjointe IBM-Microsoft de la technologie le 17 septembre 2003. Ils ont été utilisés pour créer une application interopérable, sécurisée, fiable et transactionnée ; et qui couvrent les limites organisationnelles.

La démonstration montre un exemple en cours d’exécution d’un système de traitement des commandes fédéré et de système VMI (Vendor Managed Inventory) pour un concessionnaire automobile qui commande une pièce auprès d’un constructeur automobile; le fabricant à son tour obtient des pièces auprès d’un fournisseur exploitant plusieurs entrepôts. Toutes les communications d’application à application dans le système ont été créées exclusivement à l’aide des protocoles de service Web décrits précédemment et exécutées sur une collection d’ordinateurs avec des logiciels IBM et Microsoft.

Le scénario porte sur certains des aspects les plus courants de la conduite des affaires, à savoir l’interaction entre une entreprise de vente au détail, son grossiste et le fournisseur du grossiste. Le scénario montre comment différentes spécifications WS peuvent être composées pour automatiser les éléments essentiels des processus métier tels que :

1. Authentification pour appliquer la sécurité (WS-Security)
2. Fédération d’approbation entre différentes organisations (WS-Trust et WS-Federation)
3. Échange de données pour terminer une transaction (WS-AtomicTransaction)
4. Assurance que les commandes ont été envoyées via une messagerie fiable (WS-ReliableMessaging)

4.1 Partie 1 : L’expérience client

L’exemple commence par Heather, une employée d’une entreprise appelée Concessionnaire automobile, qui se connecte au site web intranet sécurisé de son concessionnaire. Ce site web est conçu à l’aide de technologies web standard et prêtes à l’emploi. Heather entre sur le site à l’aide de son navigateur. L’accès au site est protégé par mot de passe.

Figure 4. Heather se connecte au site web intranet sécurisé de son entreprise et accède à sa page Personnalisée.

Heather clique sur Ma page. En arrière-plan, l’application collecte des informations à partir de la base de données d’inventaire du concessionnaire automobile. Si les niveaux d’inventaire d’un élément tombent en dessous d’un seuil défini, un rapport est généré et répertorié dans l’affichage « Vos alertes » de la page de Heather.

Heather constate que son entreprise a un stock faible sur les lames d’essuie-glace WindshieldPro.

Heather clique sur le lien et est redirigée en toute transparence vers une page Web sécurisée sur l’extranet Du fabricant d’automobiles, où Heather peut passer une commande. L’expérience est transparente, car le logiciel Concessionnaire auto est basé sur les services Web. Le service Web reliant l’intranet du concessionnaire automobile à l’extranet Constructeur automobile a été composé à l’aide de WS-Federation. WS-Federation garantit que les informations d’identification de sécurité accordées par un site sont respectées par un deuxième site.

Voici comment cela fonctionne. Le concessionnaire et le fabricant d’automobiles ont convenu de fédérer leurs sites. WS-Federation coordonne une série de communications de serveur à serveur. Dès que Heather a cliqué sur le lien WindshieldPro pour l’amener à la page Web du fabricant d’automobiles, le serveur de page Web du fabricant d’automobiles a interrogé son service d’autorisation, qui à son tour interrogé le service d’autorisation du concessionnaire automobile. Le service d’autorisation des concessionnaires automobiles confirme que Heather est une utilisatrice autorisée, transmettant les informations d’identification, ainsi que le nom de la concessionnaire de Heather, au service d’autorisation du fabricant d’automobiles, qui lui accorde l’accès. Cela se produit de façon si transparente que toutes les notes de Heather sont qu’elle est passée d’une page Web à l’autre.

Le service Web interroge également la base de données des clients du fabricant d’automobiles pour obtenir des informations de commande liées au compte de Heather. Les informations sont présentées dans une page web personnalisée « My Page » Auto Manufacturer.

Figure 5 : Composition d’un service Web à l’aide de WS-Federated permet à Heather de passer en toute transparence de sa page personnalisée chez Concessionnaire automobile à sa page personnalisée chez Auto Manufacturer.

La page Web personnalisée de Heather sur l’extranet Du fabricant d’automobiles lui permet de voir qu’elle n’a actuellement aucune commande en suspens; elle a une commande (pour 50 SuperTires) en transit; et que sa liste de commandes terminées comprend 20 unités de CDPlus et 50 unités de Leather Cleaner.

Heather clique sur « Créer une nouvelle commande », et une nouvelle page s’ouvre, préremplie avec la partie qu’elle souhaite : les lames d’essuie-glace WindshieldPro et la date de commande. Tout ce qu’elle doit entrer, c’est la quantité. Toutes les autres informations nécessaires pour terminer la commande sont renseignées à partir de la base de données Du fabricant automatique.

Figure 6. Une commande est facile à passer, car la plupart des données de commande ont déjà été importées à partir du fichier de Heather dans la base de données des clients du fabricant d’automobiles.

Heather envoie la commande et recherche des articles supplémentaires à acheter, ou clique sur Se déconnecter, pour mettre fin à sa session et empêcher quiconque d’effectuer une commande à partir de son ordinateur sans assistance.

Notez que la composition du service Web avec WS-Federation fourni à la fois au concessionnaire automobile et au fabricant d’automobiles des coûts d’administration inférieurs et une sécurité de bout en bout. Sans cette technologie, le fabricant d’automobiles aurait dû tenir à jour une liste de tous les employés des concessionnaires autorisés et leurs mots de passe. Cela serait coûteux, sujet aux erreurs et réduirait la sécurité de l’application.

Par instance, si Heather quitte son emploi, son compte d’utilisateur est supprimé chez Concessionnaire automobile. Mais, si l’administrateur du concessionnaire oubliait de communiquer avec le fabricant d’auto au sujet de son départ, elle continuerait d’avoir accès au site d’achat. Avec WS-Federation, ce n’est pas un problème, car le seul système qui doit être modifié est le service fournisseur d’identité du concessionnaire automatique. Les systèmes du fabricant d’automobiles, à la fois l’application et le service d’autorisation, n’ont aucune connaissance innée de Heather, de son nom d’utilisateur ou de son mot de passe.

4.2 Partie 2 : L’expérience du fournisseur

Bien que Heather commande des lames d’essuie-glaces WindshieldPro à l’Auto Manufacturer, cela fait un demi-siècle que la société a fait ses propres lames. Les lames d’essuie-glace WindshieldPro proviennent d’un fournisseur, Fournisseur.

Tony est le représentant commercial de Supplier, et il commence sa journée en se connectant à l’intranet du fournisseur, tout comme Heather s’est connectée à l’intranet du concessionnaire automobile. Mais au lieu d’utiliser un navigateur web standard, Tony fonctionne avec une application Windows qui dispose d’une prise en charge intégrée des services Web.

Figure 7. La page personnelle de Tony sur l’intranet du fournisseur lui rappelle d’case activée commandes et d’inventaire chez l’un de ses principaux clients, Auto Manufacturer.

Lorsque Tony clique pour case activée commandes et l’inventaire, son application utilise un service Web pour demander des données d’inventaire auxquelles Tony est autorisé à accéder.

L’un des aspects clés de cette demande de services web au niveau de l’application pour les données est qu’elle est composée de WS-Federation qui authentifie son accès à l’extranet du fabricant d’automobiles.

Le service Web retourne les résultats à la page du fournisseur où ils sont affichés par type de produit et le nombre d’inventaires actuels.

Figure 8. Un service web remplit la page Fournisseur de Tony avec les données d’inventaire des bases de données d’inventaire du fabricant d’automobiles. La requête a été sécurisée en la composant avec WS-Security et WS-Federation.

Le fournisseur a conclu un contrat d’achat juste-à-temps avec le fabricant d’automobiles. Tony est autorisé à fournir une commande de réapprovisionnement automatique dans le cadre de l’inventaire géré par le fournisseur (VMI) pour le compte du fabricant d’automobiles une fois que l’inventaire est inférieur à 20. Tony clique sur WindshieldPro pour passer une commande. Tous les messages entre Tony et Auto Manufacturer sont protégés, car l’application est prise en charge par des services Web composés avec les protections de WS-Security.

Figure 9. Un accord juste-à-temps avec le fabricant d’automobiles permet à Tony de passer une commande pour le compte de l’entreprise.

L’application de Tony lui fournit un écran pour créer des demandes au fournisseur avec une commande d’achat du fabricant d’automobiles. Tony commande 50 essuie-glaces WindishieldPros à expédier directement au fabricant automobile.

Lorsque Tony clique sur OK, le service d’entrepôt, un service web composé de WS-AtomicTransactions, WS-Security et WS-ReliableMessaging, tente de passer la commande auprès d’un autre service Web, les services d’entrepôt subordonnés. Lorsqu’une réponse n’est pas immédiatement retournée à partir du service d’entrepôt (en raison d’une panne réseau temporaire), WS-ReliableMessaging continue à renvoyer la requête jusqu’à ce qu’une réponse soit reçue.

Lorsque le service d’entrepôt reçoit la commande, il les transmet en interne aux deux entrepôts physiques de l’entreprise. Étant donné que cela implique des bases de données entre les deux entrepôts, WS-AtomicTransaction est utilisé pour garantir le comportement transactionnel entre les bases de données.

L’application Entrepôt divise les commandes entre les services d’entrepôt subordonnés pour garantir la couverture des stocks, 70 % des commandes vont à l’entrepôt 1 et les 30 % restants à l’entrepôt 2. Le coordinateur racine dans l’entrepôt principal envoie un message au coordinateur racine de l’entrepôt 2 demandant 30 % de la commande. Le coordinateur racine de l’entrepôt 2 vérifie son inventaire et envoie un message au coordinateur racine de l’entrepôt principal indiquant qu’il n’y a pas suffisamment d’inventaire en stock.

Le coordinateur racine main sachant qu’il n’y a pas suffisamment d’inventaire annule l’intégralité de la transaction et envoie un message à l’application de service Web de Tony indiquant le status, les niveaux d’inventaire et que la transaction a été annulée. Le coordinateur racine commence à annuler la transaction et, une fois la transaction terminée, retourne à l’entrepôt pour indiquer que la transaction a été annulée.

Tony, avec les connaissances actuelles sur l’inventaire, envoie une autre demande à l’entrepôt. Le coordinateur racine se coordonne entre d’autres entités transactionnelles (contrôleur d’autres transactions) et envoie cette demande aux 2 entrepôts qui passent par le même processus qu’auparavant. Nous utilisons WS-Security pour signer l’intégralité du corps du message afin que, quel que soit le domaine dans lequel vous vous trouvez, vous sachiez que vous êtes sécurisé.

À présent, le coordinateur racine valide les transactions, verrouille les ressources et termine la transaction. Un message est renvoyé à Tony indiquant que la transaction s’est terminée avec succès.

WS-AtomicTransaction compose avec WS-ReliableMessaging et WS-Security dans ces messages, pour offrir un système distribué complet prêt pour l’entreprise.

5.0 Conclusions

IBM, Microsoft et nos partenaires développent des spécifications de service Web qui peuvent être utilisées comme blocs de construction pour une nouvelle génération de services Web puissants, sécurisés, fiables et traités.

Ces spécifications sont conçues de manière modulaire et composable afin que les développeurs puissent utiliser uniquement les fonctionnalités dont ils ont besoin. Cette composabilité « de type composant » permettra aux développeurs de créer de puissants services Web de manière simple et flexible, tout en n’introduisant que le niveau de complexité dicté par l’application spécifique.

Cette technologie permettra aux organisations de créer facilement des applications à l’aide d’une architecture Service-Oriented (SOA). En outre, IBM et Microsoft ont démontré des applications SOA sécurisées, fiables et traitées qui illustrent la richesse des processus métier qui peuvent être créés à l’aide de cette approche. De plus, ces démonstrations fonctionnent dans un environnement de sécurité fédéré sur un environnement hétérogène composé de logiciels IBM WebSphere et Microsoft .NET.

Nous prévoyons que ces technologies de service web seront disponibles dans les systèmes d’exploitation, les intergiciels, avec des outils qui faciliteront l’utilisation de ces technologies par les développeurs. Il sera intéressant de voir les applications qui émergent à mesure que les développeurs et les organisations utilisent ces systèmes pour créer la prochaine génération de solutions basées sur les services Web.

6.0 Accusés de réception

Nous tenons à remercier les personnes suivantes qui ont contribué à ces idées : (alphabétique) Tony Andrews, Bob Atkinson, Keith Ballinger, Don Box, John Brezak, Allen Brown, Felipe Cabrera, Erik Christensen, George Copeland, Michael Coulson, Giovanni Della-Libera, Brendan Dixon, Mike Dusche, Colleen Evans, Max Feingold, Jeff Frey, Henrik Frystyk Nielsen, Praerit Garg, Omri Gazitt, Scot Gellock, Josh Gray, Martin Gudgin, MaryAnn Hondo, Destry Hood, Efim Hudis, Tomasz Janczuk, Jim Johnson, Ryan Johnson, Gopal Kakivaya, Chris Kaler, Johannes Klein, Scott Konersmann, Brian LaMacchia, Dave Langworthy, Andrew Layman, Paul Leach, Al Lee, Frank Leymann, Rodney Limprecht, Joe Long, Steve Lucco, John Manferdelli, Ashok Malhotra, Jonathan Marsh, Steve Millet, Angela Mills, Tony Nadalin, Martin Nally, Karla Norsworthy, Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Sanjiva Weerawarana, Hervey Wilson, Eric Zinda.