Créés pour faciliter les relations B to B, les services Web pourraient réaliser une percée inattendue dans les solutions d’intégration d’applications, également appelées EAI (Enterprise application integration). L’interopérabilité des différentes plates-formes logicielles du marché qu’ils apportent était, en effet, inconnue jusqu’alors. Le duo Soap-WSDL est utilisable sous Windows, Unix, OS390, AS/400… Les grands éditeurs de logiciels fonctionnels (Oracle, Commerce One, SAP…) ont tous annoncé l’ouverture de leurs produits grâce à de multiples points d’entrée qui emploient les services Web, simplifiant d’autant l’accès à ces applications lourdes.
Des services adaptés à la couche de transport
Mais l’apparition des services Web n’annonce pas pour autant la fin de l’EAI traditionnel. Les solutions d’EAI ont un double objectif : assurer la cohérence des données métiers entre les applications puis le séquencement des traitements réalisés par ces mêmes applications. Il est assez complexe d’atteindre ces deux objectifs, et cela nécessite des fonctions beaucoup plus riches qu’une simple interopérabilité multiplate-forme en mode point à point.Les solutions d’EAI sont divisées en trois couches. La première assure le transport des données, elle englobe les middlewares orientés messages (MOM), les courtiers d’objets ou les moniteurs de transfert de fichiers. La deuxième couche traite les données : transformation de leur format et routage des messages entre les différentes applications. La troisième, enfin, gère le cadencement des processus métiers. Les services Web devraient naturellement s’imposer dans la couche de transport en parallèle des middlewares. Les technologies Soap et WSDL sont adaptées aussi bien aux invocations synchrones de services (de type RPC) qu’aux invocations asynchrones (de type échange de messages). Elles sont utilisables en couplage avec les MOM pour fiabiliser les échanges. Les standards de base des services Web peuvent constituer un canal d’échange complémentaire des précédents, et sont beaucoup plus simples à mettre en ?”uvre. Ils ne remplaceront pas tous les canaux, car Soap et WSDL étant basés sur XML, le problème de performances rencontré avec XML se trouve amplifié.
Des processus métiers accessibles via un portail
Un appel de service utilisant Soap est dix fois moins performant qu’un appel binaire, mais il est dix fois plus facile à mettre en place ! Gageons que l’augmentation de la puissance des machines autorisera rapidement un usage fréquent de Soap. En revanche, ces nouveaux standards n’auront probablement pas d’impact important sur la couche de traitement des données. Certes, celle-ci est modifiée par l’apparition du langage XML et des feuilles de style XSLT. Or, les services Web définissent un protocole et non des fonctions de traitement. Ainsi, la couche de traitement des données utilisera le duo Soap-WSDL pour communiquer avec de nouvelles applications. Enfin, concernant la couche de gestion des processus métiers, le même diagnostic s’applique. Le couple Soap-WSDL ne contient aucune fonction de gestion des processus métiers. Les services Web devraient donc être utilisés pour communiquer entre les applications et les gestionnaires de processus métiers ou entre les gestionnaires de processus.De plus, il est possible, avec les solutions d’EAI de divers éditeurs, de présenter les processus métiers sous la forme de services Web et d’autoriser leur appel depuis un portail ou une plate-forme d’intégration B to B. “Il faut pouvoir appeler, depuis un gestionnaire de processus métiers, des services Web qui déclencheront des actions chez des partenaires commerciaux, c’est essentiel. De même, il faudra être rapidement capable de déclencher l’exécution de processus au moyen de services Web exposés dans un annuaire UDDI. Le duo Soap-WSDL devrait devenir le protocole d’interopérabilité des gestionnaires de processus. Ces derniers devront donc prendre en compte les services Web au même titre que les interventions humaines, les appels d’applications existantes ou de progiciels de gestion “, précise Ian Howells, directeur marketing de SeeBeyond.Les solutions d’intégration d’applications évoluent donc pour prendre en compte les technologies de services Web comme un canal de communication supplémentaire. Toutefois, nombre d’entreprises n’ont pas recours à l’EAI.Grâce aux services Web facilitant grandement l’intégration point à point, il n’est pas exclu qu’un certain nombre de problèmes qui auraient entraîné auparavant la mise en ?”uvre d’une solution d’EAI soient réglés par l’emploi des services Web, même si cela doit complexifier l’architecture d’ensemble. Le plus souvent, il n’est pas utile de réurbaniser le système d’information, comme l’illustre l’exemple du pôle services d’Air Liquide. La société a préféré modifier ses applications pour accéder à une base de données commune, encapsulée par des services Web. Les applications d’optimisation des tournées et de télémétrie avaient chacune leur vision du client, obligeant une nouvelle saisie des données dans diverses bases locales. Plutôt que de recourir à l’EAI, afin de faire circuler ces informations, Air Liquide les a centralisées et rendues accessibles par des services Web. Une simplification qui n’est possible que si l’on accepte de retoucher les applications existantes !
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
