*Classement PAC

Transcription

1

2 De l opportunité technique au choix stratégique Portés sur le devant de la scène médiatique, à grand renfort de campagnes marketing menées de concert par les ténors du secteur, les Web Services ont déjà fait couler beaucoup d encre. Certains n y ont vu qu une utopie de plus, d autres s en firent les fervents apôtres. Aujourd hui, les premières implémentations de Web Services ont fait prendre conscience de leur vrai portée : une démarche de standardisation destinée à faciliter l inter-opérabilité des applications d entreprises. Dans le même temps, les projets d intégration d applications basés sur des solutions d EAI (Enterprise Application Integration) sont entrés dans une phase d industrialisation leur faisant quitter les frontières de l entreprise, pour s étendre aux échanges BtoB. Cette convergence de maturité et de périmètres conduit nécessairement à ne plus concevoir l un ou l autre comme une simple alternative technique, mais bien comme un choix stratégique d architecture d échange des Systèmes d Informations. Comprendre et évaluer Après une introduction à la nature des Web Services pour une intégration étendue, ce livre blanc explore leurs enjeux, avant de présenter l offre des principaux acteurs du marché (BEA, IBM, Microsoft, SeeBeyond, Tibco, webmethods), en illustrant leur positionnement respectif par des cas réels d utilisation de Web Services dans des projets d intégration BtoB. A qui s adresse l ouvrage? A tous les décideurs, architectes de SI ou consultants, qui souhaitent appréhender les enjeux des Web Services dans les problématiques d intégration étendue. Au sommaire Comprendre. Qu est-ce que l EAI-BtoB. Qu est ce que les Web Services d intégration étendue. Les nouvelles opportunités pour la gestion de la sécurité et la gestion des échanges. Mythes et réalités sur les Web Services BtoB. Devenir des Web Services dans la démarche EAI. Evaluer. Les modules d intégration BtoB. Les outils EAI dédiés aux Web Services. Les cartographies des offres. La participation aux groupes de travail. Les exemples d utilisation de Web Services dans les projets BtoB. Les auteurs Georges Abou Harb, est l associé en charge de l activité EAI au sein d Unilog Management. Il fut un des premiers à croire dans le potentiel des solutions EAI et a très fortement contribué à hisser Unilog au rang de premier prestataire EAI français pour le conseil et l intégration*. georges.abouharb@unilog.fr Jean-Marc Zuliani, fut l un des fondateurs de la société CloudLink, créée en 2001, alors le premier éditeur à proposer un add-in de Visual Studio.Net, pour le versionning et la gestion des droits d accès de Web Services. Titulaire du DESS de Systèmes d information de l IAE de la Sorbonne et diplômé de l ILECI (Institut de l Economie et du Commerce International), Jean-Marc Zuliani est aujourd hui consultant senior chez Unilog Management, responsable de l offre Web Services/BtoB, au sein de l activité EAI pilotée par Georges Abou Harb. jean-marc.zuliani@unilog.fr *Classement PAC

3 Remerciements Ce livre blanc n aurait pu être réalisé sans l aide de nos partenaires. Nous avons donc à cœur de remercier : Chez BEA Erwin Moedersheim Philippe Reveillon Chez IBM Florence Calvez Jerome Carrasco Thomas Dognin Chez Microsoft Marc Gardette Yohann Evrard Renaud Marcadet Vincent Poncet Eric Vallet Chez SeeBeyond Patrick Menahem Chez Tibco François Dumont Daniel Pacyga Chez webmethods Philippe Bessis Laurent Cozette Une mention spéciale sera également accordée à : François Rivard, qui a su faire bénéficier les auteurs de son expérience de la publication Christophe Brendel, pour son œil critique et sa connaissance des enjeux BtoB

4 Publications Unilog Management Forte de sa place de leader de la prestation EAI avec plus de 35 projets réalisés depuis 1999, Unilog Management a souhaité communiqué sur son retour d expérience du conseil et de la mise en œuvre de solutions EAI, en réalisant une série d ouvrage sur le thème de l intégration d applications. Titre «Les Web Services dans l EAI-BtoB : opportunité technique ou choix stratégique pour l intégration étendue?» Auteurs Jean-Marc Zuliani, Georges Abou Harb Date de publication Juin 2003 Edition Centre de Compétences EAI Titre «L'infrastructure fédérée ou l'eai expliquée aux managers» (titre non définitif) Auteurs François Rivard, Georges Abou Harb Date de publication Septembre 2003 Edition Maxima Titre Auteurs «L'EAI par la pratique» François Rivard, T.Plantain Date de publication Octobre 2002 Edition Eyrolles - 4 -

5 Sommaire Remerciements...3 Publications Unilog Management...4 Sommaire...5 Introduction...6 Nature des Web Services BtoB et règles de fonctionnement Définitions Qu est-ce que l EAI-BtoB Qu est-ce qu un Web Service? Mécanismes Les fondamentaux Les nouvelles opportunités pour l intégration étendue...18 Enjeux et prospectives Mythes et réalités sur les Web Services Bénéfices attendus des Web Services Points communs et divergences Web Services et promesses de l intégration étendue Enjeux métiers de l intégration étendue De la théorie de l évolution aux business webs...36 Offre des éditeurs...41 Chiffres clés...41 Solutions 42 Prise en compte des Web Services pour l intégration étendue...43 Participations aux groupes de travail sur la standardisation...48 Exemples d implémentations...49 BEA Virgin Mobile USA...49 IBM - E2open...52 Microsoft - KDI...54 SeeBeyond - Onetrail...56 Tibco - Deustche Bahn...59 webmethods - Infinity...61 Conclusion...65 Liens utiles & Bibliographie

6 Nature des Web Services et règles de fonctionnement Introduction Avec 35 projets de conseil et de mise en œuvre de solutions d intégration d application (Enterprise Integration Application - EAI) réalisés depuis 1999, Unilog Management a confirmé les résultats de ces dernières années en devenant en 2002, le premier prestataire EAI en France 1. Cette expertise reconnue l a conduit à sortir des sentiers battus de l EAI l intégration d applications internes à l entreprise pour accompagner ses clients dans leurs démarches d intégration BtoB. Interrogés dans le cadre de cet ouvrage, les six principaux éditeurs de ce marché (BEA, IBM, Microsoft, SeeBeyond, Tibco, webmethods), partenaires de longue date d Unilog Management, font état de plus de solutions mises en œuvre de par le monde, dont 20% pour répondre à des besoins d intégration étendue hors de frontières de l entreprise. Dans le même temps, de nombreuses initiatives autour de l inter-opérabilité des applications, ont été promues au rang de standard, faisant ainsi passer les Web Services de l état de simples concepts, à l état d opportunité technique réelle pour l intégration BtoB. Cette convergence de maturité et de périmètre fait naître (ou re-naître) de nombreux espoirs et interrogations, auxquels Unilog Management a souhaité répondre : EAI et Web Services sont-ils de simples alternatives techniques concurrentes? Ou sont-ils devenus complémentaires au point de représenter un véritable choix stratégique d architecture du SI favorisant urbanisation, flexibilité, ouverture et interopérabilité dans un contexte d entreprise étendue? En tant que livre blanc, cet ouvrage se penche sur la nature et les règles de fonctionnement des technologies étudiées, avant d en explorer les enjeux et promesses. Mais les auteurs ont souhaité lui apporter un éclairage singulier, en soulignant le positionnement des principaux éditeurs de solutions EAI du marché à l aide de cas réels d utilisation de Web Services dans des projets d intégration BtoB basés sur leurs solutions. 1 Etude PAC 2002 sur le classement des prestataires EAI en France

7 Nature des Web Services et règles de fonctionnement Nature des Web Services BtoB et règles de fonctionnement Les Web Services ont souvent été présentés comme des concepts, porteurs de nombreuses promesses technologiques et économiques. Nous verrons qu ils reposent avant tout sur des démarches de standardisation, concrètes et particulièrement adaptées à l intégration étendue. 1 - Définitions Bien que les solutions EAI Enterprise Application Integration ou solutions d intégration d applications d entreprises ne soient plus à présenter, encore est-il nécessaire de s arrêter sur la notion d EAI-BtoB. 1.1 Qu est-ce que l EAI-BtoB Afin de segmenter leur marché, les éditeurs d EAI ont, par le passé, effectué une différenciation des problématiques adressées, selon que l on considère : Les échanges internes de l entreprise, ou AtoA - Application to Application, Les échanges inter-entreprises, ou BtoB Business to Business, Les échanges entre l entreprise et les consommateurs finaux, ou BtoC Business to Consumers Aujourd hui, cette segmentation de niches a parfois laissé la place à des stratégies globales de couverture des besoins d intégration de l entreprise, car la frontière est souvent ténue, voire artificielle, entre des échanges applicatifs transfrontaliers mais avec les filiales de la société mère (AtoA?), des échanges locaux mais avec des partenaires non juridiquement liés (BtoB?), des échanges avec un particulier non considéré comme une personne morale mais ayant son propre SI (BtoC?). Dans le cadre de notre réflexion, nous appèlerons intégration BtoB intégration étendue interopérabilité élargie - toute démarche d intégration d échanges interapplicatifs, soumise à la conjugaison de deux critères fondamentaux : Les protagonistes conversent via les protocoles de transport de l Internet (HTTP, SMTP, FTP) Ils ont des exigences spécifiques en terme de détermination de la preuve et de la responsabilité juridique, de l échange (authentification, confidentialité, intégrité, non répudiation) Enfin, il est possible d identifier plusieurs types d intégration étendue

8 Les Web Services pour l'intégration étendue Typologie d intégration BtoB Eut égard aux nombreuses études et ouvrages publiés sur la typologie des échanges BtoB, nous retiendrons ici pour exemple, celle effectuée par le Boston Consulting Group : Type A : échanges bi-directionnels Une entreprise, connectée à une autre entreprise. Type B : e-procurement Figure 1 : Typologie EAI-BtoB -> échanges bi-directionnels Les fournisseurs se connectent au système d information du client Type C : e-sales Les clients se connectent au SI du fournisseur Figure 2 : Typologie EAi-BtoB -> e-procurement Figure 3 : Typologie EAI-BtoB ->e-sales Type D : place de marché pour centrales d achats La place de marché a été mise en place par les acheteurs (ex : GlobalNetExchange WRE), afin d augmenter leur pouvoir de négociation (mode «centrale d achat») en invitant tous les fournisseurs à s y connecter Type E : place de marché neutre Figure 4 : typologie EAI-BtoB -> place de marché neutre La place de marché a été mise en place par une société tiers (non dépendante des fournisseurs ou des acheteurs). Figure 5 : typologie EAI-BtoB -> place de marché sell-side Type F : place de marché pour collectif de vendeurs La place de marché a été mise en place par plusieurs vendeurs souhaitant mutualiser leurs catalogues (ex : IndustrySuppliers) Figure 6 : typologie EAI-BtoB -> place de marché buy-side - 8 -

9 Nature des Web Services et règles de fonctionnement Typologie d implémentations EAI-BtoB Cette typologie d intégration des échanges BtoB reflète très largement les rapports de force existant entre les partenaires économiques (cf. voir également partie 2 de ce document). De ces rapports de force naissent également les solutions techniques retenues pour gérer l échange, l intégrer à l existant : Type A Aucune des entreprises n a de solutions EAI et a développé ad hoc une interface spécifique d échange point à point, Type B & C - La solution EAI est localisée dans une seule entreprise, les autres entreprises connectées se contentent de fournir les informations avec leur format/typage/codification, à charge pour cette première de supporter seule les coûts de mise en place et de fonctionnement, Type D, E, F - Chacune des entreprises candidates à l échange possède son propre EAI, ou à l inverse, la place de marché intervient comme tiers à valeur ajoutée d intégration, en proposant des prestations de transformation sur la base de son propre EAI 1.2 Qu est-ce qu un Web Service? Si le terme de Web Services a particulièrement été galvaudé, sa définition a bien souvent été dépassée par les concepts qui ont pu s y rattacher. Pour notre part, nous faisons une différence entre l idée originelle de Web Services, l état actuel de leurs avancées, et leur futur improbable. DES TECHNOLOGIES DE CONVERGENCES Genèse De prime abord, les Web Services ont été décrits par leur promoteurs, comme tout ou partie d applications (ex : la fonction convertisseur de devises), que d autres applications pourraient utiliser/appeler, à distance, via Internet. «A Web Service is a unit of application logic providing data and services to other applications through the Internet 2.» - Microsoft «A Web service is a granular software component that can be used as a building block for distributed applications or for the assembly of business processes 3.» - IBM Nous sommes alors en septembre 2000, les premières spécifications de description de Web Services (WSDL) et d appel de Web Services (SOAP) voient officiellement le jour, et d autres y voient déjà l avènement d un nouveau paradigme de l informatique. Web Services are business processes that can be discovered and run over the Internet using standard technologies.web Services enable developers to build e-business applications that can connect with any customer, supplier, and business partner anywhere in the world-regardless of the chosen platform or programming language 4. - Borland

10 Les Web Services pour l'intégration étendue Don Tapscott et Franck Moss, respectivement auteur de «Digital Capital : Harnessing the power of Business Webs 5 et co-fondateur de Bowstreet, vont ensuite ouvrir le champ du possible des Web Services, en abordant «la quatrième vague de l informatique», celle qui allait permettre à tout individu - toute entreprise, de pouvoir exposer sur Internet son savoir faire, et ainsi non seulement faciliter les échanges entre applications, mais également créer de nouveaux modèles économiques. Dans le même temps, les plus gros acteurs de l industrie du logiciel (Microsoft, IBM, SUN, HP, etc.) dépensaient des sommes considérables pour évangéliser le marché sur le potentiel des Web Services, espérant ainsi créer la demande. Etat des lieux Un peu plus de deux ans après ces mouvements de fond, force est de constater qu il existe toujours un décalage entre le discours des promoteurs des Web Services et ses utilisateurs : si de multiples initiatives ont vu le jour pour faciliter la publication d applications sous forme de Web Services, les grands éditeurs commencent tout juste à proposer certaines parties de leurs solutions sous forme de Web Services. Pourquoi? Sans doute agacés par tant de débauche promotionnelle, les détracteurs des Web Services ont abondamment commentées leur succès mitigé : technologies pas assez mûres, volonté hégémonique des majors de l informatique, utopie de l inter-opérabilité remise au goût du jour pour relancer les ventes. Avec un peu de recul, on constate que les Web Services sont essentiellement utilisés à des fins d intégration d applications, loin devant l utilisation de l Internet comme nouveau canal de distribution pour l industrie du logiciel. A l exception des trop rares exemples publics d applications célèbres disponibles sous forme de Web Service 6, la majorité des projets Web Services répondent aujourd hui à des enjeux d intégration BtoB (voir partie 3 sur l offre du marché). Il faut y voir le reflet du caractère si singulier de la nature des Web Services : des spécifications pour une inter-opérabilité élargie des applications. Le transport des messages est en effet assuré sur des réseaux et protocoles publics (TCP/IP, HTTP, SMTP), entre des acteurs qui ne se connaissent pas forcément, mais qui devront de toute manière s assurer de l identité des parties à l échange, puisqu ils sont sur un réseau public. Dans ces conditions, la clé du succès 7 des Web Services repose sur la réalité et la pertinence des solutions qui permettront de sécuriser les échanges, tout en offrant la possibilité de gérer la succession de processus basés sur les Web Services (transactions longues). Or si ces solutions existent désormais, le chemin pour y parvenir a été parsemé d obstacles, tenant plus à la divergence d intérêts économiques, qu à l infaisabilité technique Nous ne considérons ici les Web Services que dans une démarche d intégration d applications, l examen des modèles économiques attribuables aux Web Services a été examiné dans une précédente étude parue en 2001 «Les Web Services : nouveau paradigme de l Internet? Anciennes promesses, nouveaux standards, nouveaux enjeux» Jean-Marc Zuliani, disponible gratuitement, via téléchargement, sur

11 Nature des Web Services et règles de fonctionnement Car les Web Services sont un paradoxe pour leurs promoteurs. D un côté, le concept qui les anime (universalité) doit reposer sur le plus large consensus possible (les standards), de l autre la rentabilité des sommes investies dans la mise au point et la promotion des Web Services doit rapidement se trouver dans une implémentation réussie (la vente de licences). Dans ces conditions, bon nombre d éditeurs (si ce n est la totalité), ont cherché à mener de front les deux approches : mettre sur le marché de nouveaux produits permettant d exploiter les Web Services, sans forcément attendre que les spécifications utilisées dans ces produits aient été érigées au rang de standard, tout en participant activement à la mise au point de ces mêmes standards 8. Dans cette épineuse question de l œuf et de la poule, certains y ont laissé des «plumes», lorsque les implémentations qu ils proposaient se retrouvaient basées sur des spécifications dépassées et remplacées. Le consommateur final avait donc toutes raisons de rester sceptique et attentiste, avant de se lancer dans un projet basé sur les Web Services. Fort heureusement, bon nombre des spécifications Web Services sont aujourd hui érigées au rang de standards 9, que nous détaillerons plus loin (chapitre 2 de cette partie). Perspectives Nous nous attacherons à démontrer dans cet ouvrage, que l avenir des Web Services réside dans la portée de leur contribution aux promesses des solutions d EA-BtoB. Parce que les projets d intégration BtoB nécessitent une démarche de standardisation entre les acteurs de l échange, les Web Services ont de facto leur place au sein des EAI, comme standards de l intégration étendue. UNE TYPOLOGIE DE WEB SERVICES Au début des Web Services, un examen de leurs premiers moteurs d indexation, tels SalCentral 10 ou Xmethods 11, permettait de constater l étendue du champ d implémentation des Web Services : un marché vaste, qui pouvait concerner n importe quel type d application informatique, mais où l on pouvait identifier deux catégories de Web Services : les Web Services de connexion, qui à l instar des connecteurs applicatifs des solutions EAI (ex : connecteur JDBC, connecteur ALE, etc.), représentent une solution technique de connectivité permettant à une application d être invocable (utilisée) par d autres applications, avec ou sans l emploi d un EAI/middleware. Une application spécifique développée en C++ pourra ainsi s interfacée avec des applications développées en Java, les Web Services de présentation, qui à l instar des initiatives menées par l éditeur de portail d informations Epicentric 12, facilitent la centralisation de l accès aux informations hétérogènes, offrant la possibilité de visualiser l état de traitement d une donnée ou l état d avancement du processus auquel son traitement appartient, 8 A l instar des XDR de Microsoft, préfigurant ce que deviendront les XML Schemas

12 Les Web Services pour l'intégration étendue Dans le cadre de notre réflexion, nous nous inspirerons des travaux du groupe de travail sur la convergence XML, réunis au sein de l Internet Business Consortium 13 (BIC), pour schématiser les différents types de Web Services. On pourra ainsi distinguer deux ensembles: Les Web Services techniques (spécifications sur le transport, la communication, les langages de descriptions de services, les registres et annuaires) Les Web Services métier (documents métiers et processus). WS-Security, WS-Secure Conversation, WS-Privacy, XML-Dsig, XML-Encrypt, XKMS, XACML, SAML Securité CIDX, FIX, HIPAA, HL7, TRAX, UCCnet, etc. ebxml, cxml, RosettaNet, VCML, etc. Documents métiers verticaux Documents métiers transverses Processus métiers verticaux Processus métiers transverses en cours OAGIS, RosettaNet, ebxml, WS-Transaction, WSCI, WS-I, BPEL4WS, XAML, BTP UDDI WS-Inspection Annuaires Référentiels ebxml RosettaNet WSDL SOAP SOAP avec attachements Language de description de Services Communication SOAP-Routing SOAP Referral HTTP SMTP Transport HTTP-R HHTP-S Architectures Orientées Services Intégration aux applications Back-end Figure 7 : les Web Services pour l intégration étendue

13 Nature des Web Services et règles de fonctionnement 2 Mécanismes Un examen plus approfondi des technologies regroupées sous le terme de Web Services permet de souligner deux éléments essentiels : Les Web Services répondent à une démarche de standardisation pour l interopérabilité élargie des applications Les Web Services ont donc pour vocation de remplacer, à terme, les initiatives individuelles des éditeurs de l intégration d applications 2.1 Les fondamentaux Les quatre technologies à l origine du concept de Web Services ont posé les bases de leur ambition : XML, SOAP, WSDL, UDDI. XML Définition L XML - extensible Markup Language est un méta-langage 14 de structuration de données permettant de distinguer les informations de présentation et de structure d'un document. XML is a method for putting structured data in a text file. XML is a set of rules, guidelines, conventions, whatever you want to call them, for designing text formats for such data, in a way that produces files that are easy to generate and read (by a computer), that are unambiguous, and that avoid common pitfalls, such as lack of extensibility, lack of support for internationalization/localization, and platformdependency [2]. Origine Le langage HTML, conçu pour décrire les pages Web, s'est avéré limité dans la mesure où il ne distinguait pas les informations de présentation et de contenu d'un document. Or, la multiplication des canaux et des formats poussait à l indépendance du contenu et de la présentation. D autre part, l accroissement des échanges B2B et les besoins d interopérabilité convergeaient vers une structuration plus explicite des documents et vers importance accrue de la sémantique. Les regards se sont alors tournés vers SGML (Standard Generalized Markup Language), langage international, normalisé, standard de fait dans le milieu de la gestion documentaire et exploité pour structurer des documentations complexes ; mais, très sophistiqué et trop lourd pour être utilisé sur Internet, il devait faire l objet d un travail spécifique. 14 langage de description de langages

14 Les Web Services pour l'intégration étendue Les communautés du Web et SGML ont alors conjointement élaboré un dérivé du langage, capable de structurer les documents tout en tenant compte des spécificités d Internet : XML, langage de balises définissant un format universel de représentation des données. Sous-ensemble de SGML défini par l ISO (ISO 8879), XML représente 80% des fonctionnalités pour seulement 20 % de sa complexité. Langage de description des données, il imprègne une sémantique au document en plus de le structurer, ce qui lui vaut l appellation de méta-langage, où «langage de langages». Extensible, il fait preuve d une flexibilité particulièrement recherché dans toute problématique d interopérabilité ou de gestion d un cycle de vie (séquences et processus métier, versions d un document ). Impacts De la formation de groupes de travail sur la sémantique 15 du Web, au sein du W3C, en passant par le ralliement de tous les éditeurs de SGDB à XML 16, et par les principaux ERP exposant leurs API en XML 17, le méta langage XML a tenu toutes ses promesses pour devenir la lingua franca des échanges et de la structuration de données 18. Saisir XML est un préalable indispensable à la compréhension du fonctionnement des Web Services, dont il constitue la brique incontournable, mais aussi de leurs enjeux : ils partagent en effet une philosophie identique, basée sur des principes de flexibilité, de légèreté, de standardisation et d interopérabilité. Cette universalité étend le champ du possible pour les Web Services : dès lors qu une application sait travailler avec et en XML, elle est susceptible de devenir un Web Service, capable de collaborer alors avec d autres Web Services. Les Web Services permettent aux applications existantes de s interfacer, sans pour autant avoir besoin de les réécrire, en interne à l entreprise ou avec ses partenaires. Ils constituent un moyen commode de décloisonner et d ouvrir un système d information, répondant ainsi aux enjeux technologiques modernes, basés sur la réutilisation et l optimisation de l existant. SOAP Définition Simple Object Access Protocol - SOAP - pour procédure simple d appel distant d objet, est un protocole standardisé permettant à une application d envoyer et de recevoir des messages, de types requêtes-réponses, via l Internet. SOAP is a simple, lightweight XML protocol for exchanging structured and typed information on the Web 19. SOAP est un protocole d échange de messages dans un milieu distribué Voir les travaux du W3C sur la sémantique du Web, basée sur XML IDC Research prévoit par ailleurs une croissance soutenue du marché des bases de données XML, estimant que le marché devrait atteindre 600 millions $ d'ici

15 Nature des Web Services et règles de fonctionnement Deux modes de fonctionnement de SOAP sont possibles : Mode RPC Mode Message/Document SOAP RPC (Remote Procedure Call ou Appel de Procédures Distantes), est un mode de fonctionnement requête-réponse synchrone. SOAP Message/Document permet de fonctionner au choix, en mode synchrone ou asynchrone. Origine La définition du protocole SOAP débuta en 1998, à l initiative de Microsoft, de DevelopMentor et de Userland 20 Software, dans le but de parvenir à la création d une procédure d appel distant utilisant http comme couche de transport de données. Puis, ce groupe de réflexion fut rejoint par IBM et d autres grands éditeurs, afin de contribuer à transformer SOAP en un standard, soumis au World Wide Web Consortium 21 - W3C. SOAP se base sur les spécifications XML-RPC. Ce dernier est un RPC au même titre que CORBA ou DCOM, mais il n impose aucun modèle de composants, des deux côtés de la connexion. L activation des objets exécutant les méthodes est aussi laissée à la charge des applications. La norme XML-RPC précise l enveloppe des messages échangés par les deux applications (envoi de requête et de réponse), et la manière d utiliser ces messages dans le but de faire des appels de procédures distantes Impacts SOAP est devenue un standard d appel distant d applications. WSDL Définition WSDL - Web Services Description Language ou langage de description de Web Service, est une syntaxe XML pour décrire les méthodes et paramètres des Web Services invocables par le biais de messages au format SOAP. Il permet de définir qu est-ce qu un Web Service est capable de faire, où est-ce qu il réside et comment l invoquer. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. WSDL is an XML-based language used to define what a Web service can do, where it resides, and how to invoke it Organisme international de réflexion et de standardisation des nouvelles technologies Web

16 Les Web Services pour l'intégration étendue WSDL pour les Web Services est l équivalent de l IDL (Interface Definition Language) pour la programmation distribuée (CORBA, DCOM). Ce langage permet de décrire de façon précise les Web Services, en incluant des détails tels que les protocoles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, le format des messages d entrée et de sortie, et les exceptions pouvant être renvoyées. Origine Il y eut d autres tentatives de langages pour résoudre le problème de la définition des Web Services. Microsoft a d abord proposé SDL (Service Description Language) avec une implémentation fournie dans leur toolkit SOAP, puis IBM a proposé NASSL (Network Accessible Service Specification Language), dont une implémentation est fournie dans SOAP4J. Microsoft modifia sa première spécification et proposa SCL (SOAP Contract Language), puis les différents acteurs s accordèrent sur WSDL. UDDI Définition Universal Description, Discovery and Integration 23 UDDI est un référentiel commun d entreprises. UDDI permet de décrire (Description), et de localiser (Discovery) une entreprise ou un service, à partir d'interfaces qui sont personnalisables. L'annuaire indique également comment accéder aux services Web (Integration). UDDI se comporte lui-même comme un Web Service dont les méthodes sont appelées via le protocole SOAP. UDDI est composé de deux parties : L UDDI Business Registry, annuaire d entreprise et de Web Services Les interfaces d accès à ces annuaires, et les modèles de données UDDI Business Registry contient trois types d informations disponibles au format XML : Information Pages blanches: Informations publiques de type nom, adresse, téléphone et autres coordonnées. Pages jaunes: Informations sur la classification de l entreprise au moyen de taxinomies standards. Pages vertes: Description technique des différents Web Services offerts par l'entreprise. Opérations Publier: Permet au fournisseur du Web Service de se référencer lui-même. Trouver : Permet de chercher et trouver un Web Service particulier. Lier : Permet de comprendre comment une application peut se connecter et interagir avec le Web Service trouvé

17 Nature des Web Services et règles de fonctionnement Steve Graham, architecte Web Services chez IBM Emerging Internet Technologies différencie 6 types 24 d UDDI : L opérateur UDDI : un annuaire global distribué sur Internet et accessible par tous. Parmi les opérateurs UDDI on compte Microsoft, IBM et HP ; L UDDI e-marketplace :un annuaire regroupant des informations spécifiques à un corps de métier. Les entreprises d un même corps de métier s inscrivent et enregistrent leurs services ; L UDDI portail : situé au niveau d un firewall d une entreprise, cet annuaire est accessible de l extérieur. C est un moyen pour l entreprise de publier ses services à destination de ses partenaires, tout en gardant un contrôle total des informations publiées. Des mécanismes permettent une réflexion des changements de cet UDDI sur les opérateurs et les e-marketplaces. L UDDI catalogue partenaire (ou UDDI B2B) : interne à une entreprise, cet annuaire n est accessible que par les applications de cette entreprise. On y ajoute toutes les informations contenant ses partenaires et les services qu ils proposent. Lorsqu une entreprise désire travailler avec un nouveau partenaire, elle examine les services proposés dans un UDDI portail et ajoute les informations les plus utiles dans son UDDI catalogue partenaire. Ces informations sont publiées par les applications de B2B de l entreprise. L UDDI EAI : cet annuaire est lui aussi interne à l entreprise, mais les informations contenues servent avant tout à faire de l intégration d application en interne. On y retrouve les services publiés par les applications de l entreprise, et des informations sur les rôles de l organisation. Les informations contenues dans cet annuaire permettent aux applications d une même entreprise de se découvrir et de collaborer. L UDDI de test : cet annuaire UDDI est coupé des autres car les informations contenues ne sont pas consistantes avec elles des autres annuaires. Il est utile lors des phases de tests précédent le déploiement des Web Services. Plus qu un annuaire global, UDDI devient alors un outil incontournable pour faciliter l intégration, que ce soit pour des problématiques EAI (UDDI EAI, UDDI catalogue partenaire) ou B2B (UDDI partenaire, UDDI e-marketplace, opérateur UDDI). Origine L UDDI est né d un projet commun débuté en septembre 2000 par Ariba, IBM et Microsoft, ainsi que 33 autres sociétés. Aujourd hui, l annuaire UDDI rassemble une communauté de 200 entreprises

18 Les Web Services pour l'intégration étendue Impacts L objectif premier d UDDI est de faciliter les échanges commerciaux interentreprises. Selon ses fondateurs, UDDI serait est la clé de voûte des formats d'annuaires Web. Vision, semble-t-il partagée par tous les grands noms de l'informatique (Compaq, Dell, SAP, Sun, Oracle), ainsi que d'autres grandes entreprises issues du monde industriel ou bancaire (Boeing, American Express). Selon ses détracteurs, UDDI serait voué à l'échec car le marché très lucratif des annuaires professionnels est en effet verrouillé par quelques acteurs (Yellow Pages, BT, SEAT PG, VNU, France Télécom, Télénor...) peu enclins à ouvrir leurs standards et qui concentrent 75 % du marché. De plus, UDDI s oppose parfois à WSDL - WSDL permet de faire une description standard des Web Services, ce que ne permet pas de faire UDDI. UDDI permet de préciser l URL d accès du Web Service, l URL d un document de description, etc., mais pas de décrire le service de manière aussi précise qu avec un document WSDL. Ainsi chaque entreprise peut utiliser sa méthode de description de ses services et on retrouve le phénomène, de sorte que personne n est capable de comprendre une description de Web Service publiée par une autre entreprise. On espère que les futurs versions d UDDI obligeront l utilisation de WSDL pour décrire les services. 2.2 Les nouvelles opportunités pour l intégration étendue Issus à l origine de réflexions sur les couches techniques de base facilitant l interopérabilité des applications(xml, SOAP, WSDL, UDDI), les Web Services ont depuis suscités de nombreuses initiatives portant sur la convergence des technologies pour l intégration étendue. Sans même parvenir à être exhaustif, on peut dénombrer plus d une centaine d initiatives autour des technologies de convergence pour une inter-opérabilité élargie (cf. partie 3 sur l offre des éditeurs). Bien-sûr, toutes ces technologies ne répondent à la définition stricto sensu des Web Services et ne sont pas non plus devenues des standards. Un standard nécessitant en effet la réunion d une la double condition : Une spécification promulguée par un organisme international indépendant (ex :W3C, IETF, OASIS, etc.) Et implémenté par une majorité significative d entreprises Pour notre part, nous nous bornerons à examiner plus en détail ici les initiatives à proprement issues des groupes de réflexion sur les Web Services, qui ont en outre apporté une réelle valeur ajoutée aux solutions EAI plus orientées vers l intégration AtoA, à savoir : des spécifications pour la gestion de la sécurité, pour la gestion des échanges et des processus métiers. Nous finirons notre examen par un état des lieux des standards actuels

19 Nature des Web Services et règles de fonctionnement LA GESTION DE LA SECURITE Afin de faciliter l appréhension des technologies Web Services pour la gestion de la sécurité, nous les classerons ci-dessous, en fonction de leur rôle joué dans l un des quatre pans d une politique de sécurité : Authentification (authentifier l auteur du message, l identité du récepteur du message) Confidentialité (s assurer que le message ne puisse être compris/décrypté que par les parties) Intégrité (garantir un contenu de message non altérer/modifier par des tiers) Non-répudiation (apporter la preuve de l émission et de la réception du message) Authentification Confidentialité Intégrité Non répudiation WS-Security WS-Security WS-Security WS-Secure Conversation WS-Privacy XML-Sig XML-Sig XML-Sig XML-Enc XKMS XKMS XACML SAML Figure 8 : Les Web Services appliqués aux 4 volets d une politique de sécurité SSL WS-Security A l initiative de Microsoft, IBM et Verisign. Objectifs : Inclure l'ensemble des systèmes nécessaires à la mise en oeuvre d'une transaction sécurisée entre une application et un Web Service, deux Web Services. Fonctionnement : WS-Security délivre un ensemble de spécifications sur l utilisation de XML Encryption, XML Signature (du W3C) et autres certificats, dans les en-tête et extensions de message SOAP, pour signer et crypter les requêtes et réponses à des Web Services. Mais WS-Security prévoie également l utilisation d autres spécifications (WS-Policy, WS- Trust, WS-Privacy, WS-Secure Conversation, WS-Federation et WS-Authorization) pour garantir cette fois, l'intégrité, la confidentialité, l'authentification et la non répudiation des messages échangés

20 Les Web Services pour l'intégration étendue Exemple : Une entreprise A (un tour operator), effectue une requête auprès du Web Service de réservation en ligne de l entreprie B (compagnie aérienne), en cryptant son message SOAP à l aide de sa clé privé et de la clé publique de B. La compagnie aérienne peut donc ensuite vérifier que la demande de réservation provient bien du tour operator A et qu'il n'a pas été altéré en chemin. Le mécanisme de non répudiation certifie quand à lui que l entreprise A a bien appelé le Web Service de l agence de voyage B, et que le Web Service B a bien répondu à la requête de A : il devient alors difficile à ces acteurs de nier leur échange. XML Encryption (XML-Enc) Le XML Encryption Syntax and Processing est une recommandation conjointe du W3C et l IETF. Objectifs : Proposer un standard de cryptage des données et balises XML au sein d un même document, puis les représenter au format XML. Offrir un niveau de contrôle granulaire qui permet à la personne qui fournit les données XML de contrôler leur visibilité en fonction du public cible. Fonctionnement : Crypter certaines parties d'un document à l'aide de différentes clés pour pouvoir envoyer le même document XML à plusieurs destinataires, ces derniers ne pouvant décrypter que les parties les concernant. Exemple : Une application XForms peut demander à ce qu'une autorisation de paiement soit signée de manière numérique, et que la méthode de paiement, par carte de crédit, soit encryptée. XML Signature (XML-Sig) Le XML-SIG et son pendant, Le Decryption Transform for XML Signature sont également une recommandation conjointe du W3C et l IETF. Objectifs : Garantir que le contenu d'un document XML n'a pas changé (que les données reçues correspondent aux données envoyées). Fonctionnement : Les données et balises du fichier XML sont utilisées pour créer une signature unique, ignorant des informations moins cruciales telles que les sauts de ligne et les tabulations. Lors de la réception du document «signé», le système client effectue une "transformation de décryptage de la signature XML", qui fait la distinction entre le contenu crypté avant signature et le contenu crypté après. L'intégrité des données est vérifiée par comparaison du résultat et de la signature incluse dans le document XML

21 Nature des Web Services et règles de fonctionnement XML Key Management Specification (XKMS) Divers fournisseurs, tels que VeriSign, sont largement impliqués dans ce protocole. Ils ont développé des boîtes à outils et d'autres applications facilitant l'implémentation de cette spécification. Objectifs : Représenter une architecture d enregistrement et de distribution de clés publiques de chiffrement. Définir un moyen de distribuer et d'enregistrer les clés publiques utilisées par la spécification XML-SIG. Fonctionnement : XKMS est composé de deux parties: la spécification XML Key Registration Service Specification (X-KRSS) et la spécification XML Key Information Service Specification (X- KISS). Le X-KRSS détaille comment récupérer et enregistrer les clés publiques d un Web Service. Le X-KISS est utilisée pour résoudre les clés fournies dans une signature XML, en délégant à un web service le traitement de ces clés. Security Assertion Markup Language (SAML) Objectifs : Contrepartie du XACML, le SAML traite l'échange des requêtes et réponses d'authentification et d'autorisation. Fonctionnement : Une requête SAML contient des informations telles que le nom d'utilisateur et le mot de passe d'authentification, ou encore d'autres détails concernant l'individu qui exécute la requête. Ces informations sont ensuite transmises à une application conçue pour les traiter, avec pour objectif d'utiliser la spécification XACML pour accorder ou refuser l'accès à une ressource XML. SAML utilise un "schéma d'assertion" géré par OASIS. Trois types d'instructions d'assertion peuvent être employés: authentification, décision d'autorisation et attribut. Ces trois instructions sont utilisées à différents moments dans une application pour déterminer qui fait la requête, quelles données sont concernées par la requête, et si celle-ci est acceptée ou non. extensible access control markup language (XACML) Objectifs : Utilisée conjointement au langage SAML, cette spécification fournit un moyen de standardiser les décisions de contrôle d'accès pour les documents XML

22 Les Web Services pour l'intégration étendue Fonctionnement : XACML reçoit une requête SAML pour déterminer si l'accès à une ressource doit être octroyé en fonction de jeux de règles définis par le fournisseur. Contrairement au cryptage XML, les informations relatives au contrôle d'accès sont conservées dans un référentiel physiquement distinct, auquel il est fait référence lorsqu'une requête est exécutée. Les expressions XPointers et XPaths sont définies au sein de balises, qui informent le parseur de contrôler les règles XACML en lui indiquant où les trouver. Une fois que la règle est évaluée et renvoie une valeur vraie ou fausse pour indiquer si l'accès est accordé ou non, une assertion de décision d'autorisation SAML est retournée, puis traitée en conséquence. LA GESTION DES ECHANGES ET DES PROCESSUS METIERS Profils des spécifications compatibles entre-elles Inter-opérabilité WS-I Combiner des Web Services pour emplir une tâche Orchestration BPEL4WS WSCI Deécrire des inter-actions entre Web Services Formaliser le dialogue en XML, templates métiers et sémantique Processus Décrire les processus métiers en XML ebxml RosettaNet Xpdl Echanger des définitions de processus entre différents outils de workflow Gérer les transactions de Web Services entre de multiples partenaires Transactions XAML BTP WS-Transactions Garantir que toutes les transactions aboutissent ou échouent + opérations de compensation Coordonner le travail entre plusieurs Web Services Figure 9 : représentation conceptuelle des spécifications pour la gestion des échanges et des processus métiers ebxml Lancée en 1999, l initiative ebxml a pour but la définition d un cadre de travail commun sur le commerce électronique. Forte de plus de 150 participants, ebxml est très largement soutenue par l OASIS (compte tenu de son action sur la promotion d XML) et par l UN/CEFACT (pour le prolongement des apports de l EDIFACT). De ces travaux est née un consensus sur la définition des composants essentiels au commerce électronique : Des spécifications pour convertir en documents XML, des processus métiers originellement décrits en UML Des protocoles et contrats de collaboration entre Web Services Des services de messagerie (SOAP & MIME) Des services d annuaire

23 Nature des Web Services et règles de fonctionnement Les processus métiers, au sens ebxml, s entendent comme l enchaînement de tâches donnant lieu à l échange de messages conventionnels (des documents commerciaux) entre les protagonistes. Enfin, l initiative a également permis la mise au point de vues fonctionnelles (représentations UML) et vues d implémentation (DTD 25 ), qui seront stockées dans les référentiels ebxml. RosettaNet Créée en 1998, RosettaNet est un consortium d industriels des secteurs informatiquesélectronique & semi-conducteurs rassemblant plus de 400 membres, dont le but est de formaliser, en XML, le dialogue entre les partenaires d une transaction commerciale, afin de définir les éléments nécessaires à l automatisation des Web Services dans une chaîne logistique. L architecture de RosettaNet repose sur trois notions : Des templates, ou modèles de processus métiers, les PIPs (Partner Interface Processes), référencés au sein d un catalogue RosettaNet Des dictionnaires et des codes pour harmoniser les vocabulaires XML Un cadre d implémentation, le RosettaNet Implementation Framework (RNIF) Grâce à la conjugaison de ces trois notions, il est possible d échanger des messages RosettaNet, en respectant un enchaînement défini par le PIP, et avec une sémantique compréhensible par les parties, grâce aux dictionnaires et aux codes. Les PIPs gèrent les transactions entre partenaires de l échange. Ils représentent des enchaînement de tâches que les entreprises ont rendu publiques, pour gérer leur échange. A charge pour elles de conserver leurs propres processus internes de traitement des informations entrantes et sortantes. Les référentiels d harmonisation de la sémantique sont au nombre de cinq (trois types de codification et deux types de dictionnaires) : DUNS (Data Universal Numbering System) est un code à 9 chiffres géré par Dun & Bradstreet, permettant d identifier les partenaires à un échange UN/SPSC, également géré par Dun & Bradstreet, est un code de classification des produits et sous-familles de produits en 4 niveaux GTIN (Global Trade Item Number) est un code à 14 chiffres, géré par EAN international (European Article Number) et UCC (Uniform Code Council), pour l identification des produits RNTD (RosettaNet Technical Dictionary), est destiné à la spécification des catalogues et fiches produit RNBD (RosettaNet Business Dictionary), est destine à la description de l objet métier véhiculé (ex : la facture) La combinaison des trois codes fournit une description unique et compréhensible par les parties, de l origine et de la nature des produits échangés. Tandis que le combinaison des deux dictionnaires, caractérise sans erreur possible, les données transmises dans les documents. 25 Les vues d implémentations peuvent bien-sûr être obtenues à l aide de schémas XML, même si une certaine polémique demeure sur leur recommandation par le W3C :

24 Les Web Services pour l'intégration étendue WS-Transaction But : Gérer les transactions longues et complexes entre une application et un Web Services Garantir que toutes les transactions aboutissent ou échouent en groupe WS-Transactions Définit les comportements transactionnels d'un fournisseur de Web Services PTAs CTAs Etablit le lien entre les actions et les ports WDL concernés Figure 10 : WS-Transactions Fonctionnement : WS-Transaction se compose de règles applicatives XML dans l en tête du message SOAP, ainsi que de commandes au format WSDL pour déclencher des opérations de compensation en cas d erreur. Exemple : Lors d une commande en ligne, en cas de rupture d un des deux serveurs d échange, WS-Transaction intervient pour réaffecter les quantités prélevées au sein de la base de données de gestion des stocks requêtée. BPEL4WS Né d une fusion de deux anciens standards rivaux: WSFL (Web Services Flow Language) d'ibm, et XLANG (XML Business Process Language) de Microsoft, BPEL4WS (Business Process Execution Language for Web Services) est un langage de programmation dont le but est d aider les entreprises à définir la manière de combiner des Web Services pour remplir une tâche. XLANG (MS) WSFL (IBM) BPML (BPMI) BPEL4WS (IBM, MS, BEA) WSCI (Intalio, SAP, SUN, BEA)? Fonctionnement : Figure 11 : convergence des standards autour du Business Process Language Spécifier les actions qui doivent s'effectuer au sein d'un processus opérationnel et décrire les services web offerts par ce processus grâce à WSDL Une approche "exécutable" dans laquelle le modèle de processus reflète le comportement réel Une approche "protocole" dans laquelle des descriptions spécifient l'échange de messages résultant du modèle de processus

25 Enjeux et prospectives LE POINT SUR LES STANDARDS BPML HTTP SAML Publié par le BPMI.org en novembre prochainement proposé au W3C Choreography WG. définis dans les RFCs de l IETF OASIS SOAP 1.2 recommandation candidate du W3C, décembre Recommandation finale attendue pour fin troisième trimestre 2003 SOAP 1.2 avec attach. premier document de travail du W3C, août 2002 SSL définis dans les RFCs de l IETF UDDI 3 spécification officielle de l OASIS, juillet 2003 WSDL 1.2 document de travail du W3C, mars 2003 WS-Security Définis dans OASIS TC (standard de facto) XML 1.0 recommandation officielle du W3C, octobre 2000 XML Encryption XML Signature W3C Recommendations W3C Recommendations X.509 IETF RFC XKMS XACML W3C Note OASIS WS-Security, WS-Privacy, XML-Dsig, XML-Encrypt, XKMS, XACML, SAML, SSL Securité CIDX, FIX, HIPAA, HL7, TRAX, UCCnet, etc. ebxml, cxml, RosettaNet, VCML, etc. Documents métiers verticaux Documents métiers transverses Processus métiers verticaux Processus métiers transverses en cours OAGIS, RosettaNet, ebxml, WS-Transaction, WSCI, WS-I, BPEL4WS, XAML, BPML, BTP UDDI 2.0 WS-Inspection Annuaires Référentiels ebxml RosettaNet WSDL 1.1 SOAP 1.1 SOAP avec attachements 1.1 Language de description de Services Communication SOAP-Routing SOAP Referral HTTP SMTP Transport HTTP-R HHTP-S Architectures Orientées Services Intégration aux applications Back-end Fig. Les Web Services standardisés

26 Les Web Services pour l'intégration étendue Enjeux et prospectives Alors que les groupes de réflexion internationaux travaillent à l amélioration des standards pour l intégration d applications, les entreprises continuent de leur côté, à rechercher de nouvelles opportunités pour fluidifier leurs échanges d informations, tout en capitalisant, au mieux leurs investissements passés. Si ces efforts tendent au même but : faciliter l intégration des flux intra et interentreprises, les intérêts de ces acteurs restent parfois divergents, comme le montrera un examen des mythes et réalités sur les Web Services, étayé par les promesses de l intégration étendue. 1 Mythes et réalités sur les Web Services 1.1 Bénéfices attendus des Web Services Dans une récente étude parue en 2002, le Stand Hill group 26, s est attaché à récupérer l avis de 76 éditeurs, afin de faire ressortir les grandes tendances à venir sur les Web Services. On y apprend ainsi, que si 90% des interrogés supportent déjà SOAP et 70% exposent déjà leurs applications dans des fichiers WSDL, tandis que la totalité de ces éditeurs annonce supporter ces deux technologies fondamentales d ici En outre, compte-tenu des définitions polymorphes qui leur ont été attribué, les Web Services ont vu leur impact s étendre à la fois à la résolution de problématiques techniques et de problématiques métiers. Enjeux techniques et enjeux métiers Enjeux Métiers Diminution des coûts opérationnels Augmentation des revenus Meilleure connaissance du client Enjeux Techniques Réduction des coûts d intégration Diminution du nombre de duplications Indépendance des plate-formes 26 The Web Services Derby : winning strategies for Enterprise Software Vendors, M.Nukala & M.R.Rangaswami, juillet

27 Enjeux et prospectives Figure 12 : bénéfices attendus des Web Services L avis des dirigeants En 2001 Lors du forum entreprise de San Francisco, le 12 et 13 septembre 2001, organisé par le Jupiter MediaMetrix, une étude 27 a souligné quelques distinctions effectuées par les quelques 471 dirigeants interrogés sur les enjeux de la révolution Web Services. Il en ressort ainsi que : 53% utiliseront des Web Services externes pour interagir avec leurs fournisseurs et clients existants 49% y voient le moyen de réduire leurs coûts d intégration 28 44% y voient de nouvelles sources de revenues potentiels 16% d entre eux voient avant tout l utilisation des Web Services, pour l année à venir, comme un moyen pour découvrir de nouveaux partenaires économiques et interagir avec eux,

28 Les Web Services pour l'intégration étendue En 2002 D après l étude «The Web Services Derby» publiée par le Stand Hill Group 29, il apparaît que : L utilisation des WS réduirait de 10 à 15% les coûts classiques d un projet EAI Sur les 60 projets de WS, 32 % étaient tournés vers l extérieur Plus du tiers des projets sont destinés à diminuer les coûts opérationnels, tandis que 22% cherchent à accroître les revenus. 1.2 Points communs et divergences LE DEBAT SOLUTION INTEGREE VS SOLUTION COMPOSEE L opposition désormais traditionnelle entre les partisans du tout intégré/fournisseur unique d un côté et ceux d une solution créée par assemblage du meilleur des composants de l autre, sera-t-elle influencée, voire remise en cause par l introduction des Web Services? Non, les Web Services ne semblent pas avoir encore mis d accord les protagonistes de ce débat. C est du moins ce qu il ressort de l étude menée par le stand Hill Group, puisque 55% des directeurs de systèmes d information interrogés préfèrent une solution unique, tandis que 53% d entre-eux considèrent que les Web Services n auront pas suffisamment d impact pour faire évoluer ce pourcentage. Quelles sont les raisons qui justifient cette position? Les premiers travaux de standardisation autour des Web Services se sont concentrés sur la définition des couches techniques basses, et non sur les processus même d échange. Leurs applications n ont pas réussi à faire basculer ces prises de position, car ces dernières reposent avant tout sur des considérations économiques, techniques et fonctionnelles. De manière schématique, on peut considérer que la raison économique est avancée par les partisans d une solution intégrée, tandis que les considérations techniques et fonctionnelles profitent au contraire aux convaincus du «best of breed». Considérations économiques Les raisons économiques poussant à préférer un seul fournisseur en lieu et place d une multitude ne s appliquent pas uniquement au secteur informatique. La grande distribution, par exemple 30, n a eu de cesse d augmenter son pouvoir de négociation en agissant à la fois sur une centralisation de ses achats et une diminution de ses fournisseurs. Cette double action ayant contribué, au final, à augmenter la quantité et la qualité de prestations de ces derniers. En période de ralentissement économique, le maintien des marges passe souvent par une diminution drastique des coûts. Appliqué à nos technologies de l information, cela s est traduit par une re-centralisation des décisions d investissements informatiques dans les mains des DSI et services achats, au détriment des directions fonctionnelles. En d autres termes, les entreprises préfèrent porter d avantage d attention aux coûts et à la simplicité technique de mise en œuvre, qu à une adéquation de la solution avec 100% des besoins fonctionnels, qui pourrait être trop consommatrice de ressources. 29 The Web Services Derby : Winning strategies for Enterprise Software Vendors The Stand Hill Group M.Nukala, M.R.Rangaswami

29 Enjeux et prospectives Les Web Services remettent-ils en cause ces points de vues économiques? Sans pour autant se prononcer de manière catégorique, car les Web Services ne sont pas encore entrés dans une phase d implémentation de masse, force est de constater qu ils ne sont pas conçus pour apporter un avantage concurrentiel métier, comme l ont fait, par exemple, les progiciels métiers de gestion logistique ou de gestion de la relation client. Cependant, ils apportent des réponses concrètes en terme de simplicité de mise en œuvre (publiée une fois sous forme de Web Service, une application est utilisable par tous) et indépendance du fournisseur (standards d intégration), qui sont autant de caractéristiques auxquelles sont sensibles les DSI et services achats. A l évocation de ces quelques points, on se rend bien compte que la frontière entre les raisons économiques et les raisons techniques est bien mince, lorsqu on parle de Web Services. Considérations techniques La plupart des initiatives autour des Web Services sont soumises, dans leur grande majorité, à l approbation d organismes et consortium internationaux, ils ont donc pour vocation d être érigés au rang de standards. Il n est pas question de faire ici, l éloge de la standardisation, mais l on peut néanmoins prendre pour acquis, son postulat de base : un standard technique rend davantage ses utilisateurs indépendants de la solution d un seul fournisseur, propriétaire de sa propre spécification. D un côté les DSI sont donc tentés par la perspective d une plus grande facilité (présumée) d installation/intégration d une solution unique, relayée par un meilleur retour sur investissement (lui aussi présumé). De l autre, ils gardent en tête les souvenirs des gros systèmes propriétaires les ayant conduit à se retrouver pieds et poings liés, totalement dépendants d un fournisseur. Et ce seul souvenir les rend favorables à l idée d être libre de pouvoir changer de fournisseur à moindre coût, parce que les socles techniques qu ils utilisent sont basés sur des standards. Considérations Fonctionnelles Certes, les Web Services n ont pas pour objet d offrir un cadre fonctionnel, comme peuvent le faire les ERP 31, mais ils offrent une souplesse en terme de fonctionnalités. Cette richesse s entend au travers des nombreuses initiatives dont la presse se fait régulièrement l écho 32. Rendons à Caesar, ce qui est à Caesar Frank Mos et Don Tapscott, respectivement cofondateur de BowStreet et auteur de «Harnessing the power of Business Webs», furent les premiers à souligner le formidable potentiel que pourraient représenter des Web Services 33, facilement «intégrables» dans les applications existantes pour couvrir les dernières fonctionnalités non offertes par une solution unique. Car c est bien de «pourcentages», d équilibre, dont il est question, lorsqu il s agit de trancher entre une solution unique couvrant 70 à 80% des besoins, ou une solution faîte par assemblage du meilleur de chaque composant pouvant couvrir 100% des besoins. 31 Bien que nous ayons vu dans le chapitre premier, par exemple avec ebxml et RosettaNet, que les couches métiers des Web Services tendent peu à peu vers ce but Voir notamment les livres blancs publiés par Bowstreet sur le sujet :

30 Les Web Services pour l'intégration étendue LA CONVERGENCE EAI ET WEB SERVICES Les Web Services sont souvent comparés, puis opposés aux EAI : Les partisans des premiers mettent en avant les promesses de la standardisation (indépendance des éditeurs, faible coût, facilité d implémentation) Les partisans des seconds se basent sur «l intelligence» embarquée (outils de mapping graphique, moteurs de routage, gestion des erreurs, etc.) et la robustesse de ces solutions Or, les Web Services n ont pas à être opposés aux EAI! Choix et complémentarité Comme nous avons pu le voir dans le chapitre premier, les Web Services sont avant tout des spécifications, certes élevés au rang de standards, mais dont l implémentation reste à la charge des éditeurs ou clients finaux. Et ces spécifications, à l exception flagrante de WS-Routing et WS-Referral, n ont pas eu pour vocation, de supplanter les grandes fonctions de l EAI, mais bien au contraire d offrir des garanties supplémentaires de pérennité et de simplification d interopérabilité aux utilisateurs finaux. Car, le passage à une phase d industrialisation des EAI, a logiquement confronter les entreprises à une nouvelle complexité : la gestion d EAI hétérogènes. Il est effectivement devenu primordial pour l entreprise de pouvoir appuyer sur des technologies partagées par un plus grand nombre, afin de diminuer les coûts d évolution et de maintenance de ses solutions d EAI. Conscients de cette préoccupation, les éditeurs ont donc engagé de vastes refontes de leurs solutions 34 afin d en faciliter l ouverture à d autres systèmes : support de Java comme langage de développement, XML et XSLT comme langages de structuration des objets pivots, par exemple. Critères d utilisation d un EAI Dans le cas d échanges inter-applicatifs particulièrement simples, il est compréhensible qu une entreprise se tourne vers une solution d intégration légère : l exposition de l application émettrice des informations, sous forme d un Web Service invocable par l application consommatrice. Mais il reste primordial d arbitrer ce choix au regard d un examen des critères objectifs, permettant d évaluer de quelle manière cet échange pourrait s insérer dans une démarche globale d intégration. Et ce dans le but de bénéficier des atouts d une solution EAI (gains de développement lors de l évolution des interfaces, garantie de l information délivrée, traçabilité des informations échangées et de leur état, etc.) Critères positifs d utilisation Les critères positifs interviennent en faveur du traitement d un flux dans un EAI : L activité de l entreprise nécessite d avoir une vision claire sur l état d avancement de ses processus inter-applicatifs Les traitements effectués sur les données échangées sont mutualisables, facilitant ainsi la maintenance et l évolution des interfaces applicatives 34 L exemple de la société SeeBeyond (ex STC), est assez pertinent à ce sujet, dans la mesure où l éditeur a fait migrer l ensemble de ses outils de son langage propriétaire monk, pour du Java

31 Enjeux et prospectives Réutilisation des objets transportés Lorsqu un flux, candidat à l EAI, transporte des données susceptibles d être utilisé par plus d une application (émettrice ou destinatrice), la mutualisation des traitements au sein de l EAI est souhaitable dans la mesure où elle simplifiera les tâches de maintenance et de d évolution de ces transformations. Importance des transformations Au-delà de trois flux d échange, la complexité de gestion et de maintenance de leurs interfaces applicatives va croissante. Cette complexité du système d informations, communément comparée à un plat de spaghetti est à prendre en compte à chaque fois qu un échange est envisagé entre une ou plusieurs applications. Transmission des informations au fil de l eau Les solutions EAI sont particulièrement bien adaptées à une transmission/transformation des informations dès qu elles sont disponibles. Contrôle de l avancement des processus Les récents concepts de BAM 35 et CPM 36 ont souligné l intérêt d un suivi de l activité des échanges inter-applicatifs : par exemple, quel est l état d une facture (validée, non validée) d une livraison (bordereau reçu, non reçu). Conclusion sur les critères de choix positifs Il n existe pas de règle immuable et irréfragable rendant obligatoire l utilisation d un EAI pour traiter un flux. Cependant, les retours d expérience d implémentation de solutions EAI laissent entrevoir : qu avec un EAI déjà en place dans l entreprise, il est moins coûteux de faire traiter un flux par cet EAI, plutôt que de laisser son traitement effectué hors de l EAI que la centralisation des traitements facilite la gestion des référentiels métiers et leurs transcodages, de même que l ordonnancement de l ensemble des flux. Critères négatifs Flux spécifique/non pérenne La question peut se poser quant à la justification de faire traiter un flux par l EAI selon que l on se trouve : en présence d un flux déjà implémenté, et développé ad hoc uniquement pour deux applications. Dans ce cas, non seulement les transformations effectuées dans l EAI ne seront pas réutilisables pour d autres flux, mais les coûts de développement-tests et maintenance auront été dupliqués. dans le cas d une application destinée à disparaître à courte échéance et les données véhiculées n ayant donc pas vocation à être réutilisées par d autres applications 35 BAM : Business Activity Monitoring ou contrôle de l activité des processus inter-applicatifs 36 CPM : Corporate Process Management ou gestion des indicateurs de performances de l entreprise

32 Les Web Services pour l'intégration étendue Fréquence faible & volumétrie élevée La juxtaposition d une fréquence particulièrement faible (échange 1 fois par mois, ou par an), alliée à une volumétrie élevée (plusieurs centaines de Mo d un bloc) font davantage appel à un mode de fonctionnement de type ETL (Extraction Transformation Loading), qui n est pas forcément adapté pour un EAI (notamment pour des raisons de performances). Mais il est vrai qu un tel mode n est pas très adapté au fonctionnement d un Web Service non plus. Conclusion sur les critères de choix négatifs A l exception du caractère non pérenne d un flux, peu des critères ci-dessus mentionnés justifient le non emploi d un EAI déjà en place dans l entreprise. La question demeure dans le cas où il n y a pas encore d EAI utilisé dans l entreprise. C est alors que les Web Services deviennent une alternative viable pour traiter le flux

33 Enjeux et prospectives En conclusion de cette section, nous soulignerons quelques uns des mythes et réalités les plus répandus sur la prétendue dualité Web Services / EAI : Mythes Réalités les WS peuvent se passer d un socle technique EAI les technologies à l origine du concept de Web Services (XML, SOAP, WSDL), sont devenus des standards, dont les spécifications sont très largement utilisées par les éditeurs d EAI faux : pourquoi réinventer l intelligence et le savoir-faire des EAI (d autant que ces derniers ont fait la preuve de leur fiabilité)? des managers métiers pourront créer de nouvelles applications (Business- Webs) en assemblant «à la volée» des Web Services découverts sur UDDI les éditeurs (tous domaines confondus) dépensent des sommes considérables pour leur promotion faux : si l utilisation des Web Services est aujourd hui facilitée par les premières implémentations des éditeurs, on est encore loin d un niveau d abstraction suffisant pour méconnaître les contraintes techniques d interfaçage entre des applications hétérogènes faux : les mises en œuvre de répertoires UDDI sont à usage essentiellement privé, et non public. les WS sont assez matures pour garantir la sécurité des échanges B2B les Web Services sont indépendants des plate-formes et des langages de programmation, et sont accessibles via les réseaux publics Vrai : dans la mesure où de nombreuses et vastes initiatives ont effectivement abouties à la définition d outils qui permettent de respecter une politique de sécurité à l extérieur du firewall de l entreprise. Faux : une politique de sécurité très lourde, grèvera considérablement les performances des échanges BtoB (ex : l encryption/décryption d un document de plus de 100 Mo peut prendre des heures) Figure 13 : Mythes et réalités sur les Web Services

34 Les Web Services pour l'intégration étendue 2 Web Services et promesses de l intégration étendue A l instar de la récente initiative des chaînes de magasins Wal-Mart 37, «invitant» l ensemble de ses fournisseurs à se connecter à son Système d Information, la lente mais irrémédiable adoption des échanges électroniques inter-entreprises tendrait à positionner l EAI-B2B comme un des enjeux stratégique majeur de ces prochaines années. Cet enjeux est-il différemment perçu selon que l on soit fournisseur ou client? selon son secteur d activité? La réponse est affirmative, aux vues des premiers retours d expérience de projets d intégration BtoB et études portant sur l adoption des échanges électroniques et de leur automatisation. Mais des points communs demeurent, selon que l on se place au niveau des enjeux organisationnels ou techniques. 2.1 Enjeux métiers de l intégration étendue L INTEGRATION ETENDUE, VUS PAR LES ACHETEURS Selon l étude publiée par Médiamétrie sur l automatisation des échanges électroniques 38, les acheteurs seraient plutôt optimistes quant aux retombées à attendre de l intégration BtoB, puisque près de 80% d entre eux les envisagent positives d ici 2 à 5 ans. A y regarder de plus près, leur optimisme se fonde en grande part sur les gains de productivité. D une part parce que le leitmotiv des éditeurs de solutions BtoB fait la part belle à la réduction du temps de traitement des actes administratifs tels que les commandes et factures. Et d autre part, parce que les trois objectifs prioritaires et communs aux démarches d automatisation des échanges BtoB - la gestion des commandes, la gestion de factures, la mise à disposition d informations et de services clients par le web - rappellent le traditionnel triptyque - bon de commande / bon de livraison / facture - des projets EDI. Si l on en croit les récentes études 39 du Gartner Group, la valeur des transactions interentreprises va croître de manière significative entre 2001 et 2005, pour passer de 200 milliards de dollars à 1750 milliards. En d autres terme, la rationalisation des achats est plus que jamais au cœur des pré-occupations. 37 Le 9 septembre 2002, la presse internationale se faisait l écho de l initiative du géant de la distribution Wal-Mart, «invitant» l ensemble de ses fournisseurs à utiliser la nouvelle norme "EDI-INT AS2", afin de réduire les coûts d échanges d information. Pour atteindre cet objectif, le géant de la distribution leur proposa soit d utiliser sa propre solution EAI-B2B, soit d en utiliser une autre, dans la mesure où elle supportait les spécifications de l EDI-INT AS «L'adoption des échanges électroniques par les fournisseurs : Enjeux, freins et accélérateurs» fo/lb_novametrie.html&xmlpath=/france/entreprises/solutions/b2b/actus.xml&rang=

35 Enjeux et prospectives Il ne s agit pas là d une nouveauté. Des initiatives similaires ont été menées lors des grands projets EDI des années 75-80, lors des phases de re-engineering des processus des années 80-85, ou plus récemment, avec la mise en place d extranet et de places de marché. Mais l ampleur du mouvement laisse penser que la plus grande majorité des acteurs semblent convaincus de la nécessité de poursuivre les efforts passés en allant au bout de leur logique : l intégration BtoB, ou l automatisation des échanges électroniques inter-entreprises. LES FOURNISSEURS, DU MIMETISME AU MILITANTISME POUR L EAI-B2B Si les acheteurs sont particulièrement dynamiques dans leurs démarches d intégration BtoB, les fournisseurs semblent en retrait dans ce domaine. Certains y voient la représentation d une pression exercée par les clients. D autres parlent au contraire de la poursuite d objectifs différents, nécessitant plus de temps dans la réflexion et la mise en œuvre. Nous pourrions même avancer l hypothèse de fournisseurs échaudés par les efforts et les investissements consentis à l EDI et aux places de marché, avec un retour sur investissement parfois difficilement palpable. Par pression exercée sur un fournisseur, il faut comprendre le risque de voir s envenimer ses relations avec certains clients, lorsqu il ne participe pas à leurs efforts de rationalisation des achats. Parmi les impacts attendus des échanges électroniques intégrés, les fournisseurs ne placent la réduction des coûts de gestion commerciale qu en quatrième position. La meilleure diffusion de l'information produit/service et l amélioration de la qualité de relation clients se plaçant très largement en tête. Or, ce développement de la connaissance client est particulièrement gourmand en temps, dans la mesure où il suppose la mise en place des moyens de trouver la bonne donnée - et de l'exploiter correctement. Ce qui passe par un gros travail d'intégration. L IMPACT DE L INTEGRATION ETENDUE SUR L ORGANISATION Les fournisseurs espèrent augmenter leur taux de pénétration auprès des acheteurs, en répondant plus vite que les autres à leurs besoins, par exemple en créant un lien de commande direct, ce qui favorise leur collecte d informations en temps réel sur les habitudes de leurs clients. Cette espérance n est pas sans rappeler les initiatives menées par les entreprises du BtoC, où la fidélisation du client rime avec anticipation de ses attentes (et donc parfaite connaissance de ses goûts et habitudes). Mais les fournisseurs du BtoB sont encore loin d une telle démarche, car les retours d expérience sur les projets de Business Intelligence ont largement prouvé que les promesses n étaient tenues que dans la mesure où la réorganisation du Système d Information autour du client devait également s accompagner d une réorganisation de l entreprise elle même 40. Or les fournisseurs n en sont pas là, l enjeu majeur est aujourd hui pour eux de répondre aux exigences exprimées par leurs clients, pas d anticiper leurs besoins futurs. En outre, les fournisseurs font la différence entre les clients stratégiques et non stratégiques, c est à dire entre ceux qui représentent une part significative de leur chiffre d affaires et les autres. Priorité aux 20% de leurs clients qui réalisent 80% de leur ventes et pour lesquels ils entendent mettre en place les outils qui augmenteront encore davantage les achats de ces derniers. 40 Obtenir plus de détails sur le concept d entreprise «customer centrics» sur =1&qt=customer+centric

36 Les Web Services pour l'intégration étendue Dans cette optique les types de transactions avant tout concernés sont : la prise de commande et le catalogue. Sur le paiement, les réticences demeurent, du fait de la complexité de la gestion de la sécurité. Si la gestion des transactions en EDI n a plus de secrets pour la plus grande majorité, l EAI-BtoB (et a fortiori les Web Services), ne peuvent prétendre à la même connaissance auprès de leur cible, comparé aux presque 30 ans d existence de l EDI. Même les initiatives récentes autour des places de marché et des sites marchands, malgré toute la publicité qui a pu les accompagner, ne verraient que 10% du chiffre d affaires des grands acteurs, réalisé via leur média. L utilisation des Web Services et des solutions EAI sont cependant susceptibles de bouleverser les résultats de ces premières études, du fait de leur rôle joué dans d autres sphères telles que l intégration de la chaîne logistique ou la relation client (cf. Section 3 de ce chapitre sur le devenir des Web Services dans les EAI). 2.2 De la théorie de l évolution aux business webs FACTEURS D INNOVATION SCHUMPETERIENS "Ce ne sont pas les espèces les plus fortes ou les plus intelligentes qui survivent, mais celles qui s'adaptent le mieux au changement" - Charles Darwin 41 Depuis Joseph A. Schumpeter 42, on connaît le rôle de l'innovation dans la croissance économique. Ce procédé de "destruction créatrice" (disparition des anciennes combinaisons productives au profit de nouvelles) est le moteur essentiel du développement sur le long terme, mais passe par un processus de confrontation entre anciens et modernes. Pour l économiste, cinq catégories d'innovations pouvaient être distinguées : La fabrication d'un produit nouveau. L'introduction d'une méthode de production nouvelle. La conquête d'une nouvelle source de matières premières. La mise en oeuvre d'une nouvelle méthode d'organisation de la production. L'ouverture d'un nouveau débouché. Or, Les Web Services semblent réunir à eux seuls la quasi-totalité des critères de l innovation : Il s agit d un concept nouveau : le dialogue entre applications, à distance, et sur un réseau public, en utilisant des standards Ils peuvent révolutionner les méthodes de création d applications, en favorisant la réutilisation de composants existants Ils permettent aux entreprises d exploiter plus facilement la richesse de leurs systèmes d informations répartis en les interconnectant Ils modifient les chaînes de valeur en suivant une théorie Ricardienne des avantages comparatifs de la spécialisation J.Schumpeter : "Théorie de l'évolution économique", Dalloz,

37 Enjeux et prospectives Si ces Web Services constituent autant de «grappes d innovations», dans quelle mesure sont-ils susceptibles de chambouler l ordre établi dans les échanges d informations entre partenaires économiques? Débuts et fin d une destruction créatrice Les entreprises n ont pas attendu les Web Services pour échanger les informations produites et consommées par leurs applications. Il ne sera pas question ici de revenir sur l historique des échanges inter-entreprise, et des raisons qui ont conduit à leur lente mais irrémédiable automatisation (voir Chapitre 2, Section 1 sur «les Web Services et les promesses de l intégration BtoB), mais nous reviendrons néanmoins sur les deux fondamentaux qui ont conduit à toutes ces évolutions : la diminution des coûts de traitement administratifs, la mise au point d une sémantique commune. Diminution des coûts de traitement administratifs Selon une étude 43 publiée par l'ocde en 2001 sur les répercussions d Internet dans l économie, les systèmes d informations dont l accès a été rendu possible via l Internet, permettraient de simplifier la chaîne de distribution, tout en diminuant le coût des traitements administratifs, au point de réduire les coûts par transactions par un rapport de 5 à 30. Billets d avion Services bancaires Paiement de factures Logiciels informatiques Système traditionnel 8 1,08 2,22 à 3,32 15 Par Internet 1 0,13 0,65 à 1,1 0,2 à 0,5 Economie réalisée 87 % 89 % 71 à 67 % 97 à 99 % Mise au point d une sémantique commune Dans son livre blanc 44 sur la mise en réseau des catalogues électroniques, GENCOD EAN France souligne l importance des «données de base» (les produits et les entreprises prenant part à l échange) et de leur alignement. Les défauts de sémantique des données de base rendent quasiment impossible toute automatisation du traitement administratif, d où des erreurs dans la facturation et l approvisionnement qui finissent par coûter près de 0,5% du chiffre d affaires du commerce de détail Ouvrage realise par Gencod EAN France ( en étroite collaboration avec EAN International ( Uniform Code Council ( Global Commerce Initiative ( et Efficient Consumer Response (

38 Les Web Services pour l'intégration étendue Figure 14 : organigramme EAN France Anciennes promesses et nouveaux standards Le paradigme initial des Web Services, tendant à imposer la programmation par utilisation-réutilisation de composants invocables à distance n a rien de nouveau. Par le passé, le groupe de réflexion sur la programmation objet, l OMG (Object Management Group) et ses quelques 700 membres avaient tenté de définir de quelle manière les vendeurs de logiciels pouvaient définir des Object Request Brokers (ORBs) afin de rendre possible l interopérabilité. Mais, les implémentations de l ORB n ont pas eu le succès espéré, car au delà de l interopérabilité, la véritable motivation des membres de l OMG était de réussir à vendre leurs solutions de bout en bout de la chaîne. Plus tard, d autres initiatives tels les modèles Corba (Common Object Request Broker Architecture) ont elles aussi tenté d apporter une solution à la problématique du manque d interopérabilité entre systèmes hétérogènes. Mais deux principales difficultés s opposaient dans la pratique à leur succès : les spécifications de ces modèles étaient déterminées par seulement quelques acteurs, limitant de fait l adéquation entre leurs solutions et les besoins d un plus grand nombre les coupe-feu des entreprises bloquaient les protocoles de communication utilisés par ces objets, compliquant terriblement leur déploiement Les Web Services subiront-ils les mêmes déboires? Alors qu ils étaient portés sur le devant de la scène médiatique, de nombreuses voies se sont en effet élevées pour dénoncer dans les Web Services, une manœuvre marketing de quelques éditeurs (Microsoft en tête) destinée à remettre au goût du jour d anciennes gammes de produits en les présentant comme une solution aux problèmes d interopérabilité

39 Enjeux et prospectives Cependant, d autres voies s élèvent pour croire au succès des Web Services, notamment en s appuyant sur leurs différences : Le concept de Web Services n est pas la propriété de quelques éditeurs, mais repose sur un socle de standards universellement reconnu et partagé par la majorité Ce concept est destiné à amener les applications d entreprise au niveau de popularité de certaines applications Web (ex : Google, Amazon, feu Napster) Enfin, les Web Services portent en leur sein les promesses d un nouveau canal de distribution unique, capable de transformer en nouvelle source de revenus, tout service REFLEXIONS AUTOUR DES RPC UNIVERSELLES Depuis quelques années, l industrie du logiciel rend la majorité de ses solutions compatibles avec XML. Les Web Services ne font pas exception à la règle, ils se servent même du XML comme élément fondateur. En effet, les Web Services exposent une interface décrite en XML, qui communique avec d autres applications, en utilisant des protocoles de messages basés sur le XML, tels SOAP, ebxml Message Service. La soumission de SOAP au W3C Comme nous l avons vu lors de l exposé des mécanismes des Web Services (Chapitre 1), SOAP fournit un protocole évolutif pour les messages XML, ainsi qu une couche de programmation RPC. A ce jour, plus d une cinquantaine d implémentations de SOAP sont disponibles, bien qu historiquement, les plus utilisées soient : L implémentation Java en open source, en provenance de l Apache Software foundation 45 L implémentation Microsoft, au sein du SDK (Service Driver Kit 46 ) «.net» Bien que stables, ces deux implémentations n atteignent pas le niveau d interopérabilité souhaité par le W3C. C est pourquoi ce dernier a réuni le XML Protocol Working Group - groupe de réflexion sur le protocole XML dès septembre 2000, dans le but de définir un protocole standardisé sur l échange de messages XML. Les développeurs travaillant sur la définition des spécifications SOAP ont soumis leurs travaux au W3C, afin que celles-ci servent de point de départ aux réflexions sur les messages XML. L intégration de SOAP dans ebxml UN/CEFACT (United Nation 47 /CEFACT) et OASIS (Organization for the Advanced of Structured Information Standards 48 ) ont annoncé l intégration de SOAP dans les spécifications ebxml. Comme nous l avons vu dans le premier chapitre, ebxml est une initiative commune des Nations Unies et d OASIS pour la définition d une architecture XML capable de créer un marché électronique unique et global

40 Les Web Services pour l'intégration étendue ebxml is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebxml, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes 49. Cette intégration de SOAP dans ebxml pourrait conduire à la fin de la multiplication des formats complexes et donc l ouverture de l intégration étendue aux PME-PMI BUSINESS-WEBS A b-web is a distinct system of suppliers, distributors, commerce services providers, infrastructure providers and customers that use the Internet for communications and transactions. In the most elegant of B-Webs, each participant focuses narrowly on the things that it does best. Don Tapscott La double approche consistant à rendre accessible via le Web n importe quel composant informatique et pouvoir définir, dans le même temps, de nouveaux processus sur la base de ces composants est défini par Don Tapscott 50 comme l avènement des Business Webs. Pour l auteur, cette double approche résulte de trois tendances : L évolution de la programmation par objets vers une programmation par réutilisation de composants Web Services L évolution de la conception des processus métiers comme actifs propriétaires internes pour des «noyaux de compétence» délivrables sous forme de Web Services sur l Internet L évolution d une économie de produits vers une économie de services En ce sens qu ils reposent sur les socles technologiques des Web Services, les b-webs sont susceptibles de permettre aux entreprises de dynamiquement connecter des systèmes hétérogènes, y compris ceux de leurs partenaires économiques (fournisseurs, clients, administrations) pour créer ainsi un maillage informationnel et applicatif d un nouveau type. Ce maillage de b-webs, voit ainsi les fonctionnalités d une application améliorées par invocation des fonctionnalités d autres applications, exposées sous forme de Web Services «Digital Capital: Harnessing the power of Business Webs», Harvard Business School Press,

41 Enjeux et prospectives Offre des éditeurs Nota Bene : dans un but d impartialité et d objectivité, nous nous sommes attachés à illustrer nos propos, à l aide d informations fournies par un large panel d éditeurs. Néanmoins, afin de confiner ce livre blanc dans des délais de réalisation raisonnables, tous les acteurs de l intégration étendue n auront pu être cités. De même, les informations divulguées dans cette section, nous ont été fournies par les éditeurs eux-même. Les erreurs ou omissions ne préfigurent en aucun cas, une interprétation ou évaluation de la part des auteurs de cette étude. Chiffres clés Ces quelques chiffres clés fournis par les éditeurs contactés (et ayant souhaité répondre), fournissent un bon indicateur de l ampleur des besoins d intégration d application hors des frontières de l entreprise. On constate ainsi que les projets BtoB représentent près de 20% des projets d EAI, tandis que les Web Services sont utilisés dans + de 30% des projets d intégration étendue. Nombre de projets d intégration d applications dans le monde BEA IBM 51 Microsoft SeeBeyond Tibco webmethods AtoA BtoB nc 800 Etendue / Web Services nc 30 Peut-on pour autant considérer que les Web Services favorisent le BtoB? La tendance souligne en tout cas une augmentation parallèle du nombre de projets BtoB et Web Services. 51 Nota Bene : CrossWorlds racheté par IBM 52 chiffres couvrant uniquement les périodes 2002 et premier trimestre idem

42 Les Web Services pour l'intégration étendue Solutions Modules et plate-formes BtoB BEA WebLogic Integration / WLI Business Connect IBM Business Connexion 54 Microsoft SeeBeyond Tibco webmethods BizTalk Server e*xchange integrator / e*xpressay integrator Active Exchange Trading Networks / Integration Server Modules et outils Web Services BEA IBM Microsoft SeeBeyond Tibco webmethods WebLogic integration / Framework Business Connection BizTalk Server / Visual Studio.Net / WSTK / SOAP toolkit Suite ICAN / e*insight Enterprise Service Bus BusinessWorks WebMethods Integration Server 54 Depuis le rachat de l éditeur CrossWorlds par IBM, les solutions des deus éditeurs ont fusionné au sein d une et même entité : Business Connection

43 Enjeux et prospectives Prise en compte des Web Services pour l intégration étendue Standards et protocoles de la sécurité BEA IBM Microsoft SeeBeyond Tibco webmethods ACLs AES Certificats X.509 DES HTTP-R HHTP-S PKCSSSL & TLSRSA RC2 SHA-1 SAML S/MIME SPI 55 SSL MD5 Triple-DES WS-Security XKMS XML-Enc XML-Sig 55 Service Provider Interface (SPI) : non répudiation garantie par tiers de confiance

44 Les Web Services pour l'intégration étendue Standards et protocoles de la communication Form-GET Form-POST SOAP - Document SOAP/JMS SOAP-RPC XML/JMS BEA IBM Microsoft SeeBeyond Tibco webmethods Standards et protocoles du routage WS-Referral WS-Routing BEA IBM Microsoft SeeBeyond Tibco webmethods

45 Enjeux et prospectives Standards et protocoles des échanges BPEL4WS BPMN BTP JSRs 56 WSFL WSCI WS-Transaction WSTx XAML XLANG XPDL BEA IBM Microsoft SeeBeyond Tibco webmethods Standards et protocoles de la santé CMS formats for UB92 CMS formats NSF CMS for 4010 Flat HIPAA HL7 HPRIM IHE NCPDP Telecommunications 5.1 BEA IBM Microsoft SeeBeyond Tibco webmethods

46 Les Web Services pour l'intégration étendue Standards et protocoles de la banque-finance-assurance CREST DTCC/NSCC FIX FpML GSTPA TFM IAC ISO15022 Data Field Dictionnary Market Match Oasys Global OMGEO SWIFT message library TRAX BEA IBM Microsoft SeeBeyond Tibco webmethods Standards et protocoles de la chimie ChemXML CIDX BEA IBM Microsoft SeeBeyond Tibco webmethods

47 Enjeux et prospectives Standards et protocoles de la distribution BEA IBM Microsoft SeeBeyond Tibco webmethods ANSI X12 AS1 AS2 Atlas400 BusinessMail Cargo-IMP ebxml EDIFACT EDIINT EANCOM GEIS EDI*Express Gencod IBM Information Exchange ICC.net Kleinschmidt OAGI BODs ODETTE PIPs (RosettaNet) RNIF (RosettaNet) SITA Sterling Commerce Tradacoms Tradanet Transettlements UCC.Net UCS Uniplus 400 Net VDA VICS WINS XCBL XOCP Worldcom EDI*Net

48 Les Web Services pour l'intégration étendue Participations aux groupes de travail sur la standardisation BPEL4WS BPEL BPMI ECMA IETF OASIS W3C WS-I WS-Security WS-Transaction BEA IBM Microsoft SeeBeyond Tibco webmethods

49 Enjeux et prospectives Exemples d implémentations Dans le but d illustrer le positionnement des différents acteurs de l intégration étendue, nous exposerons ci-dessous quelques exemples d utilisation de Web Services dans des projets réels. Nota Bene : dans un but d impartialité et d objectivité, nous nous sommes attachés à illustrer notre propos, à l aide d exemples fournis par un large panel d acteurs. Néanmoins, afin de confiner la réalisation de ce livre blanc dans des délais raisonnables, tous les acteurs de l intégration étendue n auront pu être contactés. BEA Virgin Mobile USA Contexte Virgin Mobile USA est née d une joint venture de 300 millions de dollars (USD) entre la société Sprint PCS et le groupe Virgin. Virgin Mobile USA fournit un service de télécommunication mobile «pay-as-you-go» à destination du marché des moins de 30 ans. En tant qu opérateur «virtuel», Virgin se trouve dans la situation unique de maîtriser l intégralité de la relation client (dont gestion des appels), sans pour autant être propriétaire du réseau physique. Les challenges de Virgin Mobile sont multiples : Son business modèle particulier (Mobile Virtual Network Operator MVNO - ou Réseau Virtuel d opérateurs de télécommunications mobiles) suppose une intégration poussée entre les systèmes d information de Virgin et l infrastructure légataire de Sprint PCS, alors que ce dernier n a pas été prévu pour communiquer avec un système externe. Le secteur des télécoms, en particulier dans le monde du mobile, impose une grande réactivité et rapidité de mise sur le marché de nouveaux produits et services. Dans ces conditions, Virgin Mobile USA décida d une mise en œuvre limitée à 7 mois pour l intégration des différents systèmes. Objectifs Objectifs métiers Offrir aux consommateurs de Virgin Mobile USA, un panel de services multicanaux, issus de différents partenaires et via des technologies hétérogènes. Réussir à mettre sur le marché en moins de 7 mois, un nouveau business model : le Mobile Virtual Network Operator (MVNO) ou Réseau Virtuel d opérateurs de télécommunications mobiles Etre capable de continuellement élargir et améliorer les services offerts par le MVNO

50 Les Web Services pour l'intégration étendue Objectifs projets Connecter ensemble : o un système de GRC (Siebel), o un système de facturation (Telcordia) o un système de gestion de contenu (Screaming Media ) o un serveur vocal inter-actif (BeVocal) o un système EDI pour le réapprovisionnement ( utilisé par Best Buy) Supporter les canaux Web et WAP, pour l accès à l activation des comptes, la traçabilité des ordres et le recouvrement des créances Solution Nota Bene : les partenaires ont la possibilité d utiliser leurs propres protocoles B2B et formats de données WebLogic Server, comme moteur de transaction WebLogic Portal, pour la gestion du contenu web WebLogic Integration, comme hub de connectivité pour l ensemble des services Virgin une Base Oracle 8i pour la gestion de la persistance Microsoft IIS Servers pour la ferme de serveurs web Web Services, comme interfaces des applications internes et externes (fournisseurs de contenu et partenaires distributeurs) Web Farm Retail Content / WAP Oracle IVRU WAP Call Center Oracle App Server WAP SPCS Internet SMTP CRM Activation Data Repository ISCP SS7 SMPP Unimobile UEG Usage DB SMS Figure 15 : solution BEA-Virgin Mobile

51 Enjeux et prospectives Sécurité des Web Services Encryption SSL bit Réseau VPN sécurisé Lignes de connexions privées Firewall et politiques de sécurité étendues Vérification et accréditation des applications propriétaires XML Digital Signatures XML Encryption XML Access Control Language Bénéfices Un mariage des solutions BEA et des standards d intégration Web Services, pour atteindre les objectifs fixés, en 6 mois : Répondre aux besoins de Virgin Mobile USA en : o Connexion au système légataire d approvisionnement o Multiples fournisseurs de contenu o Multiples canaux de distribution o Développement prochain d une multitude d interfaces internes et externes, dans un laps de temps très court Offrir une alternative aux interfaces internes point à point et aux traditionnels connecteurs propriétaires spécifiques Dupliquer les logiques de transaction Faciliter les transactions temps réel et l échange de données avec des partenaires externes Une infrastructure supportant plus de deux millions de messages par jour Un accès préférentiels aux portables et accessoires Virgin pour les lieux de vente

52 Les Web Services pour l'intégration étendue IBM - E2open Contexte E2open est un fournisseur de réseau d intégration destiné à faciliter la gestion des cycles de vie des produits, entre les partenaires de l industrie électronique. L industrie électronique, peut-être plus encore que les autres secteurs, a connu récemment de forts bouleversements de son environnement économique ayant conduit ses acteurs à se réorganiser. Ces récentes restructurations ont conduit à l éclatement des systèmes d information tout au long de la chaîne de valeur, augmentant de surcroît les coûts d interaction entre les entreprises. Objectifs Objectifs métiers Afin de faciliter ces entreprises dans leurs démarches de réorganisation, E2open a souhaité enrichir les fonctionnalités de son réseau d intégration, en améliorant notamment : Objectifs projets La réduction des coûts de gestion des inventaires et des stocks, tout au long de la chaîne de valeur La réduction des cycles des processus clés, tel que les phases de lancement de produit La réduction des coûts généraux de fonctionnement, grâce à l automation E2open a souhaité répondre aux deux principaux challenges auxquels font ainsi face les entreprises de l industrie électronique : Pouvoir partager/ouvrir son SI à ses partenaires économiques distants et hétérogènes Conserver la maîtrise des échanges d informations entre les applications de ses propres systèmes répartis E2open a considérer que ces challenges pouvaient être relevés par l adoption de standards ouverts, tout en offrant un niveau de sécurité des données suffisant

53 Enjeux et prospectives Solution IBM WebSphere Business Connection software Sécurité des Web Services Cross company Single sign-on Périmètre de défense Gestion de l identification et de l authentification Figure 16 : Projet E2Open Bénéfices Répertoire UDDI privé, facilitant le référencement rapide et à moindre coût des partenaires de l échange et des spécificités de connexion de leurs systèmes Gateway de Web Services téléchargeable, destiné à simplifier la connexion des partenaires au réseau E2open Prise en compte de l existant : utiliser les Web Services pour permettre à ces partenaires de gérer leurs échanges électroniques inter-entreprises sans pour autant réécrire leurs applications

54 Les Web Services pour l'intégration étendue Microsoft - KDI Contexte Le groupe KDI (Klöckner Distribution), née en juillet 1999 de la fusion de 44 sociétés spécialisées dans la distribution d aciers et de fournitures pour l industrie et le bâtiment est le leader français de la distribution généraliste de métaux, avec une cinquantaine d enseignes commerciales, employant plus de 3000 personnes. Objectifs Objectifs métiers S adapter - Archétype de l entreprise étendue, KDI doit par nature adapter en permanence son système d informations à l historique et à l évolution des 44 sociétés fusionnées entre-elles. Répondre aux nouveaux besoins de ses clients Ouverts aux nouveaux modèles économiques des échanges électroniques, KDI doit rapidement pouvoir faire face aux nouvelles demandes de ses clients et fournisseurs. Objectifs projets Solution Ouvrir et adapter le SI aux échanges électroniques avec les partenaires Ne pas entrer dans un effet de tunnel, passer juste un peu plus d un mois pour modéliser et mettre en œuvre les premiers processus d échanges Intégrer la réception des flux de commandes, leur traitement et leur acheminement vers des applications cibles, au travers d une modélisation des processus Se baser sur les standards Web Services, pour assurer l inter-opérabilité des systèmes et sécuriser les échanges Windows 2000 Advanced Server Biztalk Server 2002 SQL Server 2000 Visual Studio.Net

55 Enjeux et prospectives Bénéfices Simplicité d utilisation pour les non-informaticiens (processus modélisé via l outil Biztalk Orchestration) Fort retour sur investissement (Nota Bene : l éditeur s étant en outre engagé sur les résultats, KDI n a eut à payer les licences BizTalk que lorsque le projet est entré en phase opérationnelle) Facilité de mise en œuvre (36 jours, un consultant et un chef de projet MOA ont suffit pour mettre en œuvre les premiers flux) La capacité à répondre plus rapidement aux demandes des clients, grâce à un outil ouvert aux formats et protocoles de communication des partenaires

56 Les Web Services pour l'intégration étendue SeeBeyond - Onetrail Contexte Onetrail est une start-up basée en Hollande qui offre une solution externalisée de Business Process Exchange pour gérer et orchestrer l approvisionnement et la distribution (Supply Chain) de matériel et d équipements informatiques entre fournisseurs, distributeurs, grossistes, transporteurs et clients finaux. Elle traite un très grand nombre de commandes de faible montant à travers des réseaux complexes en utilisant principalement Rosettanet comme standard d échange. Figure 17 : Projet Onetrail.net Cette chaîne de valeur est caractérisée par de nombreuses contraintes : Objectifs Le passage du mode stock au mode client (orientée demande) L augmentation croissant des volumes de commandes La réduction continuelle des marges et de la valeur unitaire de vente La redéfinition des modèles de collaborration (exemple KBB/Compaq) La disjonction de la chaîne physique et de la chaîne virtuelle L adoption de standards (XML, RosettaNet, etc.) Pour péréniser son modèle, Onetrail doit mettre à la disposition de l ensemble des acteurs de la chaîne de valeur une solution économique et simple pour que chaque acteur puisse s intégrer dans un système d échange et de collaboration temps-réel et transparent. Objectifs métiers Créer un réseau d information temps-réel pour l ensemble de partenaires intervenant dans la Supply Chain et garantir l interopérabilité quels que soient les plate-formes, les standards utilisées. Modéliser et monitorer les processus de commande, livraison

57 Enjeux et prospectives Cette supply chain requiert de la part des différents acteurs des niveaux d efficacité et de scalabilité importants pour : Garantir la qualité et l exactitude des informations (produits & commandes) Réduire les coûts internes liés aux traitements des commandes ( 70 en moyenne par commande manuelle) Offrir et garantir la visibilité, la transparence et la circulation en temps réel des informations pendant et entre chaque étape des processus à travers un réseau complexe En offrant une plate-forme d échanges commerciaux orientée processus métiers Business Process Exchange, Onetrail est chargée de gérer et d administrer des business process complexes ainsi que d orchestrer les transactions entre fournisseurs, distributeurs, grossistes, transporteurs et clients finaux. Onetrail traite un très grand nombre de commandes relativement petites à travers des réseaux complexes en utilisant le standard Rosettanet, développé par et pour les acteurs de l industrie informatique et des semi-conducteurs (ex : Intel, 3Com, Cisco, etc.) réduisant par l automatisation des processus et l utilisation du Web (au lieu du fax, téléphone, etc.) le coût unitaire d une commande de 60%. Onetrail se distingue des places de marché électroniques classiques parce que ces dernières mettent à la disposition de ses participants des fonctions métier et les exécutent ensuite entre elles et chaque participant. Objectifs projets Onetrail a souhaité répondre aux deux principaux challenges auxquels font ainsi face les entreprises de l industrie électronique : Pouvoir partager/ouvrir son SI à ses partenaires économiques distants et hétérogènes Conserver la maîtrise des échanges d informations entre les applications de ses propres systèmes répartis Onetrail a considéré que ces challenges pouvaient être relevés par l adoption de standards ouverts, tout en offrant un niveau de sécurité des données suffisant. Solution La réussite du modèle de Onetrail repose sur le principe de regrouper la complexité technique (transformation, routage intelligent, formatage, etc.) au centre des échanges, limitant ainsi les efforts de développement et d intégration de chacun des participants. E*Insight Business Process Manager a permis de modéliser l ensemble des processus métiers, de les intégrer, de les administrer en temps réel et de les optimiser E*Gate Integrator assure la transformation et le routage des messages E*Xchange Integrator assure l analyse des échanges avec les partenaires et leur sécurisation E*Xpressway Integrator permet à chaque participant de télécharger un composant autoinstallable pour être intégré dans l ensemble des processus

58 Les Web Services pour l'intégration étendue Figure 18 : solution SeeBeyond - Onetrail Bénéfices OneTrail met à la disposition de ses participants et de ses partenaires une solution souples, flexible, sécurisée et évolutives pour gérer l ensemble des processus critiques du Supply Chain en toute transparence entre chacun des acteurs, réduisant de 65% les efforts d installation des composants chez ses participants Pour certains des partenaires utilisant d autres protocoles que RosettaNet et EDIFACT, Onetrail a implémenté le connecteur e*way Intelligent Adapter SOAP de SeeBeyond pour supporter et publier des Web Services s appuyant sur le protocole SOAP. L objectif de cette implémentation est pour l instant de faciliter la consultation en temps-réel des produits, de leus disponibilité, des prix, et d en fournir une date de livraison. Les VARs peuvent ensuite intégrer ces données facilement dans leurs back-office grâce au composant e*xpressway mis à la disposition des partenaires. Ces services sont disponibles et en production depuis le mois de novembre

59 Enjeux et prospectives Tibco - Deustche Bahn Contexte Deutsche Bahn est la compagnie nationale des chemins de fer d Allemagne. Son réseau couvre près de 5948 stations, avec plus d un milliard cent millions de personnes de transportées, chaque année. Récemment, l Allemagne a été choisie comme organisateur officiel de la prochaine coupe du monde de football (2006), avec plusieurs millions de voyageurs supplémentaires à transporter. Deutsche Bahn souhaite se préparer à la gestion de cette gigantesque logistique ferroviaire, en modernisant l ensemble de son infrastructure, nécessaire à l optimisation du transport de ses passagers. Objectifs Objectifs métiers Anciens processus - Les stations de chemin de fer sont très peu connectées les unes aux autres : téléphone et/ou FAX, dans la majorité des cas, produisant erreurs & retards, plaintes de passagers. Le manque de visibilité sur les attentes (proposition d amélioration de service) des passagers, ainsi que la résistance aux changements de certains horaires, ont incité la société Deutsche Bahn à rechercher le moyen de devenir plus réactive. Nouveaux processus - Publication de Web Services tous les composants SI du réseau ferroviaire de Deutsche Bahn sont connectés les uns aux autres, et échangent au fil de l eau. Chacun de ces composants sont inter-connectés au travers de processus métiers complexes, afin de résoudre les problèmes «en temps réel». Par exemple, si un signal d alarme est déclenché dans une station, cet «événement déclencheur» lance automatiquement un processus de découverte de la source de l incident (via caméras de surveillance automatiques), et conduit à une action correctrice (ex : prévenir automatiquement les passagers de la ligne qu un retard est à prévoir), ainsi que son reporting. Tous ces processus d échange d information devant conduire à l amélioration de la sécurité et la satisfaction des passagers. Objectifs projets Faire la preuve du concept d une plate-forme d intégration basée sur les Web Services, au travers de la connexion des principaux SI de deux des plus grosses stations de Deutsche Bahn. Le projet Deustche Bahn aura donc pour objectif de connecter les applications de : Gestion de facility, Gestion de la sécurité Gestion de la propreté Système de réservation/information des voyageurs

60 Les Web Services pour l'intégration étendue Solution Plate-formes Solaris et Windows Applications spécifiques TIBCO BPM, TIBCO BusinessWorks, TIBCO Adapter SDK, TIBCO Hawk Security, Services Traveler Info System at Station Workflow Web services Control station Cologne RCS (Bandwidth Management) Audio and Video input systems TIBCO ActiveEnterprise BPM BusinessWorks Control station Aachen Figure 19 : solution Tibco - Deutsche Bahn Bénéfices Amélioration de la qualité des services offerts aux passagers, grâce au partage de l information entre les stations Augmentation de la sécurité des voyageurs, grâce à une remontée d alerte en temps réel et engagement automatique d actes correctifs Optimisation de la gestion des réservations (taux d occupation des trains), grâce à l intégration de la chaîne de maintenance permettant une plus grande coordination-anticipation des immobilisations pour réparation Flexibilité et rapidité dans la création et le changement des horaires/services

61 Enjeux et prospectives webmethods - Infinity Contexte Infinity Pharmaceuticals, Inc. est une compagnie de recherche pharmaceutique qui développe des capacités et des approches uniques dans les domaines de la chimie synthétique, la génétique chimique, l informatique et le criblage biologique. Infinity a créé la plate-forme de connaissance InfiNet (InfiNet Knowledge Platform) pour intégrer ses applications de R&D et ses Bases de données. Cette plate-forme offre une manière organisée d insérer de grandes quantités de données biologiques et chimiques complexes, à partir de diverses sources de données, vers un système centralisée. Cela permet aux scientifiques de partager les informations provenant de ces multiples sources de données, au travers d une interface unique de type navigateur, et d améliorer ainsi sensiblement leurs probabilités de succès. InfiNet utilise la technologie des Web services pour intégrer et automatiser les canaux d information basés sur le logiciel, la robotique et l activité humaine dont: Objectifs Conception et production des bibliothèques de composés chimiques Criblage biologique de Haut-débit (HTS) Systèmes de gestion de l'information des laboratoires (LIMS) Analyze «Hit-to-lead» Recherche collaborative de tiers Objectifs métiers Pour les compagnies de recherche pharmaceutique, une quantité accablante de données doit être manipulée régulièrement ce qui comprend les données du génome, les protéines, les molécules chimiques, les expériences, le métabolisme, les brevets, et les effets secondaires de médicaments. La recherche exigée pour produire cette richesse des données rend le procédé de recherche extraordinairement cher. Plus tôt les compagnies pharmaceutiques peuvent éliminer les formules inefficaces, mieux c est. Andy Ellicott, Directeur technologique d Infinity Pharmaceuticals, explique: «Dans l'ère d Internet et du post-génome, il y a une abondance d'information publique et privée disponible pour les organismes de recherche en médicaments. La différence entre les «thrivers» et les «laggards» dépend de leur capacité à assimiler cette information et la rendre disponible de manière fluide, opportune et appropriée. Ceux qui le feront le plus rapidement et de la manière la plus adaptée fourniront un niveau d automatisation supérieure, des supports de décision et des capacités prédictives à leurs équipes de recherche médicamenteuse. D u point de vue de l architecture, nous avons trouvé que le succès dépend de l adoption d une plateforme basée sur les Web services qui offre le moyen le plus productif de réutiliser les données et les fonctionnalités au travers des applications (faîtes maison ou du commerce), des plate-formes, des disciplines et mêmes des frontières de l entreprise."

62 Les Web Services pour l'intégration étendue Ellicott ajoute "Au cœur de l infrastructure d intégration Web service d InfiNet se trouve webmethods, que nous avons sélectionnés pour sa fiabilité et sa performance avérées en environnements d entreprise, sa facilité d utilisation et, le plus important, sa capacité inhérente à nous aider. Il nous aident à dépasser les frontières de la technologie, la plate-forme et de l entreprise." Infinity utilise la technologie à de nombreux niveaux du processus de recherche pharmaceutique, en réduisant de manière incrémentale le cycle global. Au coeur d InfiNet se trouve une architecture orientée Web service (Web service-based integration = WSBI) s appuyant sur webmethods. Infinity voit les Web Services comme une réponse à l exposition de leurs applications basée sur les standards et rentable. InfiNet intègre plus de 30 applications et systèmes de gestion de données pour fournir une manière organisée d insérer de larges volumes de données chimiques et biologiques complexes, à partir de multiples sources d information vers un système centralisé. (voir la Figure suivante). Les principaux composants sont: Objectifs projets Systèmes de gestion de l'information des laboratoires (LIMS) Cahiers électroniques de laboratoires Systèmes de criblage biologique de Haut-débit (HTS) Système d'enregistrement de composés chimiques Modèles de prévision de réactivité chimique et de bio activité Gestion de projet et comptabilité Grâce à l application de la technologie Web service au processus de recherche pharmaceutique, Ellicott espère: Solution Augmenter les probabilités de succès d Infinity Accélérer la création de valeur Optimiser l agilité de son système d informations Figure 20 : Solution webmethods - Infinity