Agrégation de plusieurs services sur un même site
Ce site fictif de réservation de voyages agrège l’offre de ses partenaires. Il propose automatiquement l’hôtel correspondant au lieu d’arrivée du billet de train et l’assurance annulation adaptée. L’internaute n’a plus à se connecter sur trois sites différents pour organiser son voyage.
Orchestrer l’appel des services
L’assemblage des différents services est orchestré par un moteur de workflow. Il construit le squelette de l’application à la volée, en fonction du contexte de consommation : la réservation d’un billet de train ou d’avion n’appelle pas le même service. Ce processus est modélisé avec des langages XML, tels que BPML, Xlang ou WSFL. Ils permettent d’indiquer dans quel ordre doit s’effectuer l’agrégation. Ils précisent également ce qui doit se passer lorsqu’un service web ne répond pas : la transaction doit-elle être annulée ou le serveur d’applications doit-il rechercher un service similaire dans un annuaire UDDI ?
Dialoguer avec ses partenaires
L’échange entre deux services web distants s’effectue au travers des passerelles (proxy) Soap sur différents protocoles internet : HTTP, SMTP, etc. Les requêtes de l’agence de voyages en ligne à destination du service web “assurance” sont écrites en Soap. Ces requêtes peuvent véhiculer des documents XML directement dans l’enveloppe ou sous forme de pièces attachées. Dans le cas d’échange de documents commerciaux, le format de ces documents est spécifié par ebXML ou Rosettanet. Ces deux frameworks ne se contentent pas d’indiquer les formats à employer. Ils précisent aussi dans quel ordre les appels de services doivent avoir lieu.
Intégrer les applications en interne
Lorsque le service web “assurance” reçoit un appel de l’agence de voyages, il interroge son back office pour connaître la police d’assurance la mieux adaptée. L’intégration des applications peut reposer sur des services web internes. Le client Soap interne (C1 et C2) gère alors l’interface avec l’API de l’application interrogée, remplaçant ainsi le connecteur EAI. Il peut donc appeler une méthode ?” par exemple, celle de Siebel ou de SAP ?” pour lire, effacer ou modifier une information. Le serveur d’applications orchestre alors les appels de services web en fonction d’un processus métier, via son client Soap (C3).
Recenser les services disponibles
Pour découvrir dynamiquement les services web de ses partenaires, l’agence de voyages consulte un annuaire UDDI, public ou privé. Cette interrogation s’effectue via une requête Soap. L’annuaire retourne alors la liste des URL des fichiers WSDL, qui exposent les API des différents services web. L’annuaire peut se trouver au sein d’une entreprise. Il est alors utilisé pour des besoins internes, mais il peut tout de même exposer des services publics. Les différents annuaires UDDI se synchronisent entre eux selon un schéma de réplication qui rappelle celui des annuaires LDAP.
Vers des hébergeurs de services web
Les services web proposent une architecture distribuée sur HTTP. On peut imaginer que des hébergeurs spécialisés ?” places de marché de composants comme Flashline ou Componentsource, ASP, etc. ?” concentreront des grappes de services en garantissant leur disponibilité. Ils faciliteront également le déploiement chez les partenaires.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
