En théorie, le déploiement d’un service web se limite à la publication de ses méthodes d’invocation dans un annuaire. Il peut alors être utilisé par n’importe quelle application. Dans la pratique, comme dans tout environnement distribué, les choses ne sont pas aussi simples. Excepté pour le Cobol et le client-serveur à deux niveaux, l’intégration à l’existant pose moins de problèmes que la synchronisation de traitements impliquant différents services web.“Le dialogue entre un serveur HTTP ou de messagerie et l’existant n’étant pas spécifique aux services web, le déploiement ne pose pas vraiment de problème d’intégration, affirme Philippe Mougin, architecte logiciel chez Orchestra. En revanche, la conception de nouveaux services web devrait changer les habitudes des développeurs. Il n’est, en effet, pas intéressant d’utiliser un modèle objet distribué tel que les EJB, car les services web sont déjà distribués.”
Modéliser l’application à déployer : une étape préparatoire
C’est précisément parce que les services web offrent les mêmes possibilités d’orchestration de composants que n’importe quel environnement distribué qu’ils soulèvent les mêmes difficultés. De granularité variable, les services web peuvent, en effet, être répartis sur différents serveurs, s’invoquer mutuellement à travers un réseau local ou étendu dans le cadre des échanges électroniques B to B. Le déploiement d’une application se prépare donc dès la modélisation de son architecture, c’est-à-dire lors du découpage des fonctions en services web. Et ce afin de tenir compte de la localisation du service dans le système, de l’éventuelle synchronisation de traitements entre deux services web, de la charge CPU d’une machine ou du serveur d’applications qui héberge le proxy, de la charge réseau, etc. En l’absence d’outils de simulation, cette modélisation est d’autant plus complexe que les protocoles de transport utilisés par les services web, HTTP ou SMTP, ne garantissent aucune qualité de service. Soutenue par BEA, HP et Sun, l’Oasis (Organization for the Advancement of Structured Information Standards) tente de combler en partie ce défaut avec BTP (Business Transaction Protocol), une norme qui enrichit Soap de fonctions de gestion de validation ou d’annulation des transactions (en “two phase commit”).
Des traitements de contrôle codés au niveau applicatif
S’appuyant sur le langage XML, BTP permet de gérer et de surveiller les traitements couplés pour s’assurer qu’ils s’effectuent dans l’ordre initialement prévu et que toutes les conditions d’exécution sont bien remplies. Déjà mis en ?”uvre par HP et BEA dans leurs serveurs d’applications, BTP se concrétise par l’ajout d’un message XML dans l’en-tête du mécanisme de transport. Et ce qu’il s’agisse de Soap, d’ebXML Messaging ou de Rosettanet. Pour l’heure, ces traitements conditionnels et autres synchronisations doivent être codés au niveau applicatif, les outils de BPM (Business Process Management) jouant, dans ce cadre, un rôle primordial dans l’orchestration des processus métier. A défaut de protocole garantissant la qualité de service, l’enchaînement des traitements est, en effet, géré par ces outils qui permettent de modéliser le comportement d’une application et automatisent son exécution grâce au moteur de workflow, qui dialogue avec le courtier de message d’un outil d’EAI.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
