Développement : une écriture assistée du code

Les outils de développement de services web génèrent le proxy Soap, mais pèchent dans l'interfaçage d'applications plus anciennes.

Pour le développeur, un service web s'apparente à la fois à une API universelle décrite en WSDL et à un mécanisme de type RPC (Remote Procedure Call), reposant le plus souvent sur Soap et HTTP. Il s'agit donc d'une enveloppe permettant de publier et d'appeler de façon homogène les méthodes d'un composant où qu'il se trouve ?" internet, réseau local, etc. ?" et quelle que soit la technologie utilisée pour le créer.Du côté du " serveur ", le service est composé d'un proxy (passerelle) Soap et d'un fichier WSDL, publié sur un annuaire UDDI privé ou public. Le fichier WSDL fournit au développeur la liste des méthodes qu'il peut appeler dans son programme " client ". Il lui indique également le détail des arguments attendus par chaque méthode et le format de la réponse fourni par le service web. Le " client " et le " serveur " sont en fait de simples composants COM, EJB, Servlet ou PHP, interfacés avec un proxy Soap. Les deux proxies dialoguent entre eux par messages Soap et se chargent de traduire les documents XML échangés dans un format compréhensible par chaque composant. Un mapping des données,?" un travail de correspondance des données ?" est en général nécessaire lorsque le " client " a été développé avant la publication du service web. Ce dernier peut, par exemple, attendre " numéro-commande " en argument, alors qu'il s'agit de " purchaseorderid " au niveau du client.Heureusement pour le développeur, les éditeurs fournissent des environnements de développement qui génèrent le proxy Soap et le fichier WSDL presque sans intervention de sa part. Il s'agit, tout au plus, de rajouter quelques lignes de code et de suivre les étapes d'un assistant. C'est ce que proposent notamment Visual Studio .Net, de Microsoft, ou Capeconnect, de Cape Clear. De son côté, Glue, de The Mind Electric, ne nécessite aucune manipulation préalable pour exposer une classe Java. Côté client, Visual Studio .Net et Wasp Tools de Systinet permettent de récupérer l'API du service web directement dans l'outil de développement en indiquant une simple URL. Il suffit alors à un développeur J2EE de créer un objet Soap pour ensuite manipuler une méthode COM comme n'importe quelle méthode J2EE locale.

Obligation de réécrire les applications client-serveur

Cette apparente facilité ne correspond cependant qu'à la partie émergée de l'iceberg. En effet, les entreprises qui possèdent un système d'information conçu à base de technologies objet dernier cri sont rares. La plupart souhaitent, au contraire, utiliser les services web pour ouvrir des applications client-serveur ou Cobol à leurs partenaires. Les applications écrites en Cobol ne posent pas de gros problème : il suffit de les interfacer au préalable à l'aide de composants COM+ ou J2EE. En revanche, les applications client-serveur reposant sur une architecture à deux niveaux doivent être réécrites en partie ou en totalité, ou préalablement être interfacées avec un outil d'EAI. Elles intègrent, en effet, une partie des traitements dans la couche présentation (client). Dans ces deux cas représentatifs de la réalité de l'entreprise, les outils de développement ne sont d'aucune aide.

Air Liquide : partir d'un modèle de composants bien conçu

Le projet Ibisa permettra aux clients d'Air Liquide de consommer son savoir-faire métier (optimisation de tournées, traçabilité, etc.) au travers de services web. La solution de Business Design Consulting, filiale architecture e-business du groupe, permet d'ajouter, de modifier, de consulter et de supprimer des données métier hétérogènes, regroupées dans une base commune. Ces opérations se font au moyen de composants COM+ possédant une interface WSDL. " Nous avons d'abord modélisé les processus métier et les documents XML qui seront échangés. Puis avec SMO (Soap Messaging Object) Generator de Microsoft nous avons généré plus de 70 % du code des services web, explique Christian Sanchez, responsable technique du projet Ibisa. L'important, c'est le modèle de composants sous-jacent. S'il est bien conçu, la création des services web est, en grande partie, automatisée par les outils de développement. "

Jean-Marie Chauvet (Dassault Développement) : " A terme, la plomberie Soap et WSDL sera masquée "

" L'infrastructure technique des services web n'offre que de la plomberie. Mais pour consommer des logiciels sous forme de services, il faut pouvoir les découvrir et les assembler dynamiquement. UDDI et BPML remplissent cette mission, mais ils manquent encore de maturité. Une couche métier est en train d'apparaître avec ebXML et Rosettanet. Elle va rapidement masquer la plomberie dans les outils de développement. C'est déjà le cas avec Biztalk, de Microsoft : les utilisateurs fonctionnels manipulent des processus et des documents métier dans un éditeur graphique ; ils ne savent pas s'il sagit de services web ou de connecteurs EAI. "