“La recherche d’interactions programmatiques généralisées n’est pas neuve. Au milieu des années 90, elle avait même trouvé un slogan ?” les Intergalactic Distributed Objects ?”, et était l’une des promesses de Corba. Soap [Simple Object Access Protocol, Ndlr] est lui-même bâti sur les bases de XML-RPC “, explique Philippe Mougin, architecte logiciel chez Orchestra Networks. De fait, les services web n’offrent qu’une interface de programmation et un mécanisme de RPC (Remote Procedure Call) basiques. Ils permettent à un logiciel d’appeler les méthodes d’un autre logiciel. On peut donc bâtir des applications distribuées, dont certaines parties se trouvent chez un partenaire. Mais, contrairement aux modèles précédents ?” DCOM et Corba ?”, les appels RPC des services web passent sans encombre les coupe-feu. Alors qu’il fallait ouvrir des ports particuliers pour RMI et IIOP, les services web utilisent HTTP pour le transport de bas niveau et XML pour l’encapsulation des messages et la présentation des API. Autre différence, HTTP et Soap n’ont aucune capacité transactionnelle, contrairement à DCOM couplé à Microsoft Transaction Server.
Une simple interface… mais standard
Pour faire dialoguer des composants existants (COM, Corba, J2EE, etc.), il faut commencer par générer une API standard au format WSDL (Web Services Description Language) à partir de l’interface de l’objet Java ou de la recherche des méthodes utilisées par le composant COM. Le fichier WSDL peut ensuite être référencé sur un annuaire UDDI (Universal Description, Discovery and Integration) public ou privé afin que les développeurs sachent quelle méthode appeler et quels paramètres lui donner. Ils y apprennent aussi le format des réponses renvoyées par le service. De nombreux outils, tels que CapeStudio de CapeClear ou WASP Tools d’Idoox permettent déjà de rechercher des services dans les quelques annuaires UDDI disponibles. Côté performances et stabilité, certains éditeurs privilégient la génération d’un serveur proxy Soap dynamique plutôt que statique. Ce proxy Soap traduit les appels de méthodes arrivant par HTTP au format XML, encapsulé dans un protocole Soap, vers l’API propriétaire du composant. Le mapping entre les deux API s’effectue souvent graphiquement et donne lieu à la génération d’un fichier WSDL. Ainsi, deux applications peuvent facilement être intégrées l’une à l’autre par la publication d’une “façade” WSDL. Mais, dans une approche many to many, il est préférable de centraliser les échanges entre les services web à l’aide d’un message broker (courtier de messages) qui joue le même rôle qu’un ORB (Object Request Broker). Pour les architectes, la difficulté est de structurer les applications en “services “, chacun de ceux-ci ayant entre eux un couplage lâche (une modification dans un service web n’oblige pas le redéveloppement des autres).
| Les principaux outils de développement | ||||
| Éditeur | Produit | Fonctions | ||
| CapeClear | CapeStudio | Génération dynamique des fichiers WSDL et des proxy Soap à partir de composants J2EE et EJB. | ||
| IBM | WSDE et Soap Toolkit | Le développement s’effectue avec Web Services Development Environment et l’exécution avec le Web Services Toolkit (WebSphere + Apache Soap 2.0). | ||
| Microsoft | Visual Studio .Net | Visual Studio .Net assiste le développement des services web. Soap Toolkit 2.0 implémente WSDL. L’environnement d’exécution CLR (Common Language Runtime) est stable bien qu’en version bêta. | ||
| Idoox | WASP Tools | Transforme Forte for Java de Sun et JBuilder de Borland en outils de développement de services web. | ||
| Lucin | Soap:Net | Génère automatiquement le code Visual Basic ou JavaScript du client Soap à partir du fichier WSDL du serveur Soap. | ||
| WebGain | Application Composer | Plate-forme d’assemblage statique de composant et génération de l’interface WSDL. | ||
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
