Web Services COMMUNICATION INTER LANGAGE

labo-sun@supinfo.com Web Services COMMUNICATION INTER LANGAGE Auteur : Maxime Vialette Version n 1.0 22 octobre 2004 Nombre de pages : 26 Ecole Supérieure d Informatique de Paris 23. rue Château Landon 75010 PARIS www.supinfo.com

Web Services - Communication inter langage 2 / 26

Web Services - Communication inter langage 3 / 26 Table des matières 1. INTRODUCTION... 4 1.1. INTRODUCTION AUX WEB SERVICES... 4 1.2. QU'EST-CE QU'UN WEB SERVICE?... 5 1.3. LE CONCEPT DES WEB SERVICES... 5 1.4. POUR QUOI FAIRE?... 5 2. LE PROTOCOLE SOAP... 7 2.1. GENERALITES... 7 2.2. LES MESSAGES SOAP... 8 2.3. LES REQUETES HTTP... 8 2.4. LES REPONSES HTTP... 9 2.5. LES NAMESPACES... 9 3. WSDL : DONNEES ET SECURITE... 10 3.1. LES DONNEES ACCESSIBLES... 10 3.2. LA SECURITE... 10 4. L'ANNUAIRE UDDI... 11 4.1. LE PRINCIPE D ANNUAIRE... 11 4.2. LA RECHERCHE D UN WEB SERVICE... 11 4.3. LA PUBLICATION D UN WEB SERVICE... 12 5. L ARCHITECTURE ET CREATION DES WEB SERVICES... 13 5.1. LES ETAPES DE CREATION D UN WEB SERVICE... 14 5.2. L INTEGRATION D UN WEB SERVICE... 15 5.3. LA RECHERCHE D UN WEB SERVICE... 16 5.4. L APPEL D UN WEB SERVICE... 16 5.5. DESCRIPTION DU CAS... 17 5.5.1. Développement... 17 5.5.2. Déploiement... 18 5.5.3. Utilisation... 19 6. LA MODELISATION BPML... 22 6.1. L ORCHESTRATION... 22 6.2. LA CHOREGRAPHIE... 23 6.3. MODELISATION DES PROCESSUS... 24 7. CONCLUSION... 25 7.1. EST-IL URGENT D'ATTENDRE?... 26

Web Services - Communication inter langage 4 / 26 1. Introduction 1.1. Introduction aux Web Services De plus en plus avec l essor d Internet, le développement tend vers les technologies du Web. Il est difficile de faire la distinction entre les différents logiciels qui sont de plus en plus intégrés au Web. Les Web Services rentrent dans l optique de différencier bien précisément les différentes couches d une application (présentation, métier et données). Les Web Services sont des applications modulaires basées sur Internet qui exécutent des tâches précises et qui respectent un format spécifique. Ils permettent à vos applications de faire appel à des fonctionnalités (décrites par les web services) à distance (soit sur le même réseau, soit sur Internet) et simplifient l échange des données. Les Web Services permettent aux applications de dialoguer à travers le réseau, indépendamment de leur plate-forme et de leur langage d'implémentation. Ils s inscrivent dans la continuité d'initiatives telles que CORBA (Common Object Request Broker Architecture, de l'omg) en apportant toutefois une réponse plus simple, s appuyant sur des technologies et standards reconnus et maintenant acceptés de tous. Les protocoles existants : DCOM, RMI, CORBA, DIIOP et RPC sont progressivement abandonnés au profit des Web Services. La définition des Web Services ne serait pas complète si l on n'évoquait pas ses principaux standards : SOAP, WSDL et UDDI, des protocoles mis en place par Microsoft, IBM, Sun, Les Web Services peuvent également servir au développement d applications distribuées et sont accessibles depuis n importe quel type de clients (WAP, Web, Applicatif,...).

Web Services - Communication inter langage 5 / 26 1.2. Qu'est-ce qu'un Web Service? Un Web Service est un composant implémenté dans n'importe quel langage, déployé sur n'importe quelle plate-forme et enveloppé dans une couche de standards dérivés du XML. Il doit pouvoir être découvert et invoqué dynamiquement par d'autres services. Le plus souvent les Web Services sont des fonctionnalités basiques du serveur d entreprise mis à disposition. Cette technologie, initiée par IBM et Microsoft, puis en partie normalisée par le W3C, est maintenant acceptée par l'ensemble des acteurs de l'industrie informatique sans exception. C'est surtout ce point qui fait des Web Services une technologie révolutionnaire. 1.3. Le concept des Web Services Les aspects purement technologiques n ont eux rien de fondamentalement novateurs. Au contraire, l architecture des Web Services s est imposée (tout comme le langage XML) grâce à sa simplicité, à sa lisibilité et à ses fondations normalisées. L XML (extended Markup Language) est à la base de tous les protocoles décrits. Le fait que les Web Services utilisent l XML leurs procurent l'avantage d être non propriétaire et ainsi réellement multiplateforme. Il est donc recommandé de posséder un minimum de bases (XML, DTD, les schémas, XSL,...) afin de pouvoir mettre en place des Web Services réellement optimisés. Le concept des Web Services s articule actuellement autour des trois acronymes suivants : SOAP (Simple Object Access Protocol) est un protocole d'échange inter-applications indépendant de toute plate-forme, basé sur le langage XML. Un appel de service SOAP est un flux ASCII encadré dans des balises XML et transporté dans le protocole HTTP. WSDL (Web Services Description Language) donne la description au format XML des Web Services en précisant les méthodes pouvant être invoquées, leurs signatures et le point d accès (URL, port, etc..). C est, en quelque sorte, l équivalent du langage IDL pour la programmation distribuée CORBA. UDDI (Universal Description, Discovery and Integration) normalise une solution d annuaire distribué de Web Services, permettant à la fois la publication et l'exploration. UDDI se comporte lui-même comme un Web service dont les méthodes sont appelées via le protocole SOAP. Un avantage significatif des Web services, relativement aux autres solutions d architecture distribuée, est son support des pare-feux (firewalls) : l utilisation du protocole HTTP sur le port 80, généralement ouvert, leur permet de passer sans encombre ces barrières de l'entreprise. Cette facilité engendre d autres soucis de sécurité, l utilisation par défaut de ces caractéristiques est trop permissive et nécessite une prise en compte de la sécurité au niveau des protocoles. 1.4. Pour quoi faire? Les Web Services comportent de nombreux avantages : utilisables à distance via n'importe quel type de plate-forme, ils peuvent servir au développement d applications distribuées et sont accessibles

Web Services - Communication inter langage 6 / 26 depuis n importe quel type de clients. Les Web Services appartiennent à des applications capables de collaborer entre elles de manière transparente pour l utilisateur. A quelles applications se destinent les technologies des Web Services? Pourquoi les utiliser? Comment les mettre en place? Les technologies des Web Services peuvent être appliquées à toutes sortes d applications auxquelles elles offrent de considérables avantages en comparaison aux anciennes API propriétaires, aux implémentations spécifiques à une plate-forme et à quelques autres restrictions classiques que l on peut rencontrer (multi-plateforme, multi-langage, disponible sur Internet avec une information actualisée disponible en temps réel,...) L application des Web Services est multiple, autant dans les domaines du B2C, B2B que pour des domaines de gestion de stocks, etc... B2C (Business to Consumer) : Qualifie une application, un site Internet destiné au grand public. B2B (Business to Business) : Qualifie une application, un site Internet destiné au commerce de professionnel à professionnel. Les Web Services peuvent être utiles dans la plupart des scénarios applicatifs où la communication peut être établie sur un modèle bidirectionnel (requête/réponse). C est néanmoins loin d'être aussi limitatif, beaucoup d autres modèles peuvent avoir recours aux Web Services. Les entreprises qui mettent à disposition leurs Web Services permettent aux développeurs intéressés par ses fonctionnalités de les réutiliser sans avoir tout à recoder. Le principe des Web Services permet d avoir un partage des fonctionnalités et permet de faciliter grandement le développement.

Web Services - Communication inter langage 7 / 26 2. Le protocole SOAP SOAP (Simple Object Access Protocol) est un protocole à la fois simple et léger, destiné à l'échange d informations. SOAP diffère de RMI, CORBA et COM car il concentre les informations et utilise le principe d auto description des données. SOAP fait partie de la couche de communication des Web Services. La force de ce protocole réside dans son universalité et sa flexibilité. Il définit la structure des messages XML utilisés par les applications pour dialoguer entre elles. SOAP fait figure de pièce centrale parmi tous les protocoles évoqués. SOAP est très complexe si l on voulait en détailler toutes les spécificités. Nous allons donc seulement évoquer les plus utilisées. 2.1. Généralités La communication avec les Web Services s effectue via le protocole SOAP. SOAP peut être utilisé : pour l appel de méthodes (SOAP RPC) pour l échange de messages (SOAP Messaging) SOAP définit la structure principale du message, dite «enveloppe» qui contient deux parties : l entête (Header) : facultatif le corps (Body) : obligatoire SOAP définit aussi l encodage pour les différents types de données qui est basé sur la technologie schéma XML du W3C. Les données peuvent être de type simple (chaîne, entier, flottant,...) ou de type composé.

Web Services - Communication inter langage 8 / 26 2.2. Les messages SOAP SOAP régit le format des données lors de leur envoi/réception. C est ainsi que l on désigne le trafic en plusieurs types différents : Les messages Les enveloppes Tous les messages SOAP contenus dans un document XML sont appelés des enveloppes qui sont des conteneurs d un message SOAP. Une enveloppe est le premier des éléments dans un document XML qui représente un message SOAP. C est la neutralité de ce principe qui permet la mobilité de la technologie des Web Services. L enveloppe étant formatée selon les spécificités de SOAP, l expéditeur et le consommateur peuvent totalement être écrit sur des plateformes différentes sans que cela pose problème. 2.3. Les requêtes HTTP Les requêtes HTTP consistent à avoir une méthodologie de requête, une requête en URL en spécifiant les entêtes et corps du flux envoyé. Les messages SOAP sont transmis via HTTP permettant une complète interopérabilité entre les clients et les Web Services. Lors de l envoi d une requête HTTP, le champ d entête doit avoir la valeur «SOAPAction :» pour que le message soit assimilé à un message SOAP. GET retourne la ressource identifiée par la requête. HEAD retourne l entête identifiée par la requête. POST envoie des valeurs sans limite de taille vers le serveur. PUT stocke une ressource pour la requête. DELETE supprime la ressource identifiée par la requête. OPTIONS retourne les méthodes HTTP supportées par le serveur. TRACE retourne le contenu des entêtes utilisées avec l option TRACE. HTTP 1.0 inclut seulement les méthodes GET, HEAD, et POST. Bien que les serveurs J2EE requièrent seulement la version HTTP 1.0, beaucoup de serveurs supportent la version HTTP 1.1. POST /LocalWeather HTTP/1.0 Host: www.mindstrm.com Content-Type: text/xml; charset="utf-8" Content-Length: 328 SOAPAction: "WeatherStation" <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:getcurrenttemperature xmlns:m="weatherstation"> <m:scale>celsius</m:scale> </m:getcurrenttemperature> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Web Services - Communication inter langage 9 / 26 2.4. Les réponses HTTP Les réponses HTTP utilisent le même procédé. Une réponse HTTP contient un code du résultat, l entête et un corps. Voici quelques erreurs identifiées par un numéro précis sur le protocole HTTP : 404 indique que la ressource demandée est indisponible. 401 indique que la requête requière une authentification HTTP. 500 indique une erreur interne au serveur HTTP. 503 indique que le serveur est surchargé. HTTP/1.0 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 359 <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:getcurrenttemperatureresponse xmlns:m="weatherstation"> <m:temperature>26.6</m:temperature> </m:getcurrenttemperatureresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Pour la fiabilité des données transmises, IBM a mis en place un standard : HTTPR (HTTP Reliable, HTTP Fiable). Ce standard doit permettre d assurer l envoi ou la réception fiable de messages SOAP. 2.5. Les namespaces Il est important de comprendre les namespaces XML pour comprendre SOAP. <m:getcurrenttemperature xmlns:m="weatherstation"> <m:scale>celsius</m:scale> </m:getcurrenttemperature> Analysons le flux XML ci-dessus, XML permet de créer des noms de variables de manière similaire à un langage de programmation. Ici l identifiant du namespace se nomme «m» et cette variable contient «WeatherStation» comme namespace. Ce principe de variable est très utilisé dans les fichiers de description de données. Nous en avons un exemple, «m GetCurrentTemperature» permet directement d identifier le namespace grâce à l identifiant «m». XML supporte cependant les namespaces par défaut, vous pouvez donc rencontrer des flux tels que celui-ci. <GetCurrentTemperature xmlns="weatherstation"> <scale>celsius</scale> </GetCurrentTemperature>

Web Services - Communication inter langage 10 / 26 3. WSDL : Données et sécurité C est un format de description des méthodes et des paramètres des composants invocables par le biais des messages au format SOAP. WSDL (Web Service Description Language) est une grammaire dérivée de l XML. A l heure actuelle, seule la couche de transport est réellement normalisée et ne souffre d'aucune contestation. Elle s appuie sur le protocole SOAP pour l échange des messages et sur le langage WSDL pour la définition du contrat de l interface. Lorsque vous voulez avoir des informations sur un Web Service, pour pouvoir l utiliser par exemple, vous devez faire une référence au fichier WSDL. Ex : http://www.xmethods.net/sd/2001/temperatureservice.wsdl 3.1. Les données accessibles WSDL comprend la définition de plusieurs données : type : un conteneur de la définition du type de données utilisées. message : description du type de données transmises lors des messages operation : description d une des actions supportées par le Web Service. porttype : description de l ensemble des actions supportées. binding : protocole et format de données spécifiques pour un type de port précis. port : un endpoint défini comme une combinaison entre une liaison et une adresse réseau. service : une collection qui relie les endpoints WSDL est un système de communication «point à point». Un consommateur du Web Service interroge le serveur, sur lequel celui-ci est disponible, et celui-ci retourne la description du Web Service demandé. 3.2. La sécurité La gestion de la sécurité et des transactions est actuellement le frein le plus important à la mise en place d'architectures distribuées à base de Web Services. Plusieurs chantiers sont ouverts mais aucun n'est réellement accepté. La norme XACML (extensible Access Control Markup Language ) et SAML (Security Assertion Markup Language) sont les deux principales normes au niveau de la sécurité. XACML est donc capable de faire communiquer les politiques de contrôle d accès dans un environnement des Web Services. SAML exprime des informations d authentification à l aide d assertion sur des sujets (humains ou virtuels) qui ont une identité pour le système de sécurité considéré. En ce qui concerne l aspect transactionnel, la lutte est plus ouverte, même si BTP (Business Transaction Protocol) semble plus soutenu actuellement.

Web Services - Communication inter langage 11 / 26 4. L'annuaire UDDI UDDI (Universal Description, Discovery and Intégration) est une spécification définissant la manière de publier et de découvrir les Web Services sur un réseau. Ainsi, lorsque l on désire mettre à disposition un nouveau service à disposition, on crée un fichier appelé business Registry qui décrit le service en utilisant un langage dérivé de l XML selon les spécifications de UDDI. 4.1. Le principe d annuaire UDDI permet de classer et de rechercher des Web Services. Si l accès à l information est trop élevé, le recours aux Web Services ne devient plus intéressant. C est pourquoi le principe d annuaire universel a été mis en place. Les annuaires UDDI ne répondent pas aux mêmes besoins que les annuaires de type LDAP (Lightweight Directory Access Protocol), dont la vocation est de référencer aussi bien des personnes que des ressources matérielles ou logicielles et de gérer les droits d accès à ces ressources. Les annuaires UDDI sont des annuaires privés sur le Web dont l usage est orienté dans le cadre d échanges B2B. On y trouve aussi bien des informations techniques (documents WSDL, par exemple) que des informations à caractère général sur une entreprise (page Web d accueil ou de produits, par exemple). L API UDDI est divisée en une interface de programmation pour l enregistrement de Web Services dans un annuaire UDDI et une interface de programmation pour la recherche d informations dans un annuaire. L API UDDI est composé de 2 grandes bibliothèques : API de requête API de publication 4.2. La recherche d un Web Service La recherche se fait grâce à un moteur de recherche intégré au site de l opérateur UDDI choisi. Ce moteur de recherche vous permettra d affiner votre recherche selon plusieurs critères : Nom de l entreprise La localisation de l entreprise Identifiant de l entreprise Le nom du Web Service L API de requête regroupe les appels aux sites opérateurs qui n ont pas besoin d authentification particulière. Les annuaires UDDI ont pour but de localiser virtuellement des Web Services hébergés sur les serveurs du monde entier. Lors de votre recherche vous pouvez ainsi vous renseigner sur tous les services mis à disposition d une entreprise, avoir des informations sur l entreprise, Les opérateurs UDDI vous certifient la sécurité et l intégrité des Web Services contenus dans l annuaire.

Web Services - Communication inter langage 12 / 26 Les appels aux sites des opérateurs donnent accès aux différents éléments de l enregistrement d un Web Service dans un annuaire UDDI : find_binding : récupère la liaison du service considéré. find_business : récupère l identité de l entreprise productrice du Web Service. find_relatedbusiness : récupère la liste des entreprises étant reliées (filiale, département, partenaire, ) à l entreprise productrice du Web Service. find_service : récupère la définition du service. find_tmodel : récupère le modèle de données associé. get_bindingdetail : récupère, par une liaison précédemment établie par find_binding les champs individuels. get_businessdetail, get_businessdetailext : récupère une entité précédemment établie par find_business les attributs individuels. get_servicedetail : récupère un service précédemment établi par find_service les attributs individuels du service (prototypes des méthodes). get_tmodeldetail : récupère un modèle établie par find_tmodel les champs individuels. 4.3. La publication d un Web Service Comme dans WSDL, la liaison UDDI regroupe, pour un protocole de communication donné, les données techniques nécessaires à l exploitation du Web Service (adresse IP, noms de domaines, les informations sur les modalités d usage du service, ) La publication par une entreprise d un Web Service requière que celle-ci s authentifie auprès du site de l opérateur UDDI. L entreprise doit s enregistrer chez l opérateur si cela n est pas déjà le cas. Une fois le site de l opérateur choisi, les modifications ultérieures ou la mise à jour de cet enregistrement doivent être faites auprès du même opérateur. Lors de l enregistrement, vous pouvez enregistrer simultanément un ensemble d entreprises affiliées, des relations entres entreprises indépendantes décrivant des accords croisés. L API se décompose en 3 groupes : La manipulation (save et delete) L authentification des commandes par jeton (get_authtoken et discard_authtoken) L ajout de relations interentreprises (joint_ventures)

Web Services - Communication inter langage 13 / 26 5. L architecture et création des Web Services L architecture des Web Services repose sur un mécanisme de transport d une demande de service entre un client et un serveur, tous deux connectés au réseau (réseau d entreprise ou Internet). La normalisation actuelle autour des Web Services est cependant un vaste chantier qui va bien au-delà de la simple invocation d'une méthode d un objet distant. Différents travaux ont ainsi démarré pour tenter de définir une véritable infrastructure distribuée, capable de satisfaire l ensemble des besoins d une application distribuée, aussi bien en terme de normalisation des échanges qu en terme de services transverses. On peut schématiser cette organisation des comités de normalisation selon le découpage matriciel suivant : Normalisation des services transverses sur trois axes horizontaux : o o o Couche de transport : Définition de la structure des messages utilisés par les applications pour se découvrir et dialoguer entre elles Couche de sémantique : Normalisation des données participant aux échanges selon des critères métiers Couche de gestion des processus : Standardisation de la gestion des processus métiers qui s'étendent sur plusieurs applications disponibles sur l'internet Normalisation des services transverses sur trois axes verticaux : o o Service d'annuaire : Standardisation des moyens d accès à un service à partir d'une requête portant sur le contenu d'un service ou sur un fournisseur Service de sécurité : Normalisation des moyens permettant de couvrir les problématiques d authentification et de gestion des droits d'accès. Service de transaction :

Web Services - Communication inter langage 14 / 26 o Normalisation des moyens permettant de garantir l'intégrité des transactions longues impliquant plusieurs Web Services Que ce soit dans le monde de J2EE ou dans celui de.net, tous les acteurs majeurs proposent une solution orientée Web Services ainsi que l intégration imminente des standards associés. Parallèlement, les premières utilisations de cette technologie voient le jour, notamment dans le domaine des solutions de CRM (Sevina ou Onyx), de gestion des ressources humaines (CCMX) ou de mutualisation de contenu (Systeme U, Digiplug). 5.1. Les étapes de création d un Web Service La mise en place d un Web Service étant très importante dans une logique d entreprise, il est nécessaire d identifier correctement les traitements à effectuer. La phase d analyse avant de développer le Web Service doit particulièrement être importante : Identifier les traitements Exposer les services Administrer Orchestrer Les Web Services peuvent donc se positionner à plusieurs niveaux au sein de l entreprise. Vous pouvez donc tout à fait avoir des Web Services au niveau métier, technique ou au niveau des applications d entreprises. On parle ainsi de multiples canaux de diffusion des Web Services. JAX-RPC (Java API for XML Remote Procedure Call) est utilisé dans le développement des Web Services, cette API supporte les classes suivantes du SDK de J2SE : java.lang.boolean java.lang.byte java.lang.double java.lang.float java.lang.integer java.lang.long java.lang.short java.lang.string java.math.bigdecimal java.math.biginteger java.net.uri java.util.calendar java.util.date

Web Services - Communication inter langage 15 / 26 Les types primitifs à utiliser sont les suivants : boolean byte double float int long short 5.2. L intégration d un Web Service L intégration des Services Web à la plate-forme J2EE s effectue selon plusieurs procédés. Vous pouvez utiliser des outils de génération et d intégration mais ceux-ci se baseront sur des API et librairies que vous auriez pu utiliser à la main sans faire de génération. Les éléments utiles dans la mise en place de Web Services sont les suivants : API Java utiles aux Services Web : JAXP, JAX-RPC, JAXM et JAXR Les librairies Apache : AXIS, XML-RPC et WSIF Création d'un service avec AXIS Outils d'orchestration : BPEL, BPWS Ces notions ne sont pas obligatoirement toutes à maîtriser, ce cours n a pour but que de vous présenter les différents aspects des Web Services. Si vous voulez plus de renseignement vous aurez des points de départs pour effectuer vos recherches.

Web Services - Communication inter langage 16 / 26 5.3. La recherche d un Web Service Pour rechercher les Web Services déjà créés et mis à votre disposition, il vous suffit de rechercher dans des annuaires UDDI (Universal Description, Discovery and Intégration). L'UDDI définit différents annuaires qui permettent de présenter les services d une entreprise à d'autres. Une compagnie peut donc publier un de ces Web Services, qu elle a développé, dans un annuaire afin de les partager à une personne qui peut en avoir besoin. C est l'adoption de cet annuaire par les sociétés qui permettra d accélérer les échanges commerciaux par exemple. Grâce à ces annuaires vous pourrez être assuré que les Web Services publiés sont fonctionnels et vous pourrez en trouver certains qui sont des versions d évaluations, d autres gratuits et enfin des versions professionnelles payantes. Vous pouvez ainsi, vous-même, rechercher des Web Services existant afin d accélérer votre développement. Il vous suffit d'utiliser un moteur de recherche via annuaire UDDI. Il existe de très nombreux sites qui sont dédiés à cette fonctionnalité, par exemple : https://uddi.ibm.com/beta/find http://www.strikeiron.com 5.4. L appel d un Web Service Lorsque vous aurez trouvé, grâce aux annuaires UDDI, le Web Service que vous souhaitez utiliser, vous devrez récupérer l adresse du WSDL associée au Web Service. Ex : http://www.xmethods.net/sd/2001/temperatureservice.wsdl Le client qui appelle un Web Service peut être soit un navigateur Web, soit une application. L appel peut être fait expressément par l utilisateur ou peut être automatisé. Les appels peuvent être complètement indépendants de l utilisateur (procédure de tâches automatisées par exemple). Le client peut être une plateforme différente de la plateforme hébergeant le Web Service (Mainframe, PC Serveur, PC Desktop, PC portable, PDA, Téléphone portable, etc ) De même, si le Web Service a été écrit en C#, le client peut très bien être fait en Java. En fait, le client n a même pas à savoir le langage dans lequel a été programmé le Web Service pour pouvoir l utiliser.

Web Services - Communication inter langage 17 / 26 5.5. Description du cas Dans le cas suivant nous allons développer et utiliser un Web Service. La phase complète impose 3 étapes différentes : Création de classes Java de Service Web Déploiement d'un Service Web Test d'un Service Web 5.5.1. Développement Voici un exemple de l arborescence à adopter dans le cas d un projet Web Dynamique au sein d Eclipse.

Web Services - Communication inter langage 18 / 26 5.5.2. Déploiement Lorsque votre phase de développement est finie, vous devrez créer le Web Service sur votre serveur et Eclipse vous permettra également de générer le client associé afin de pouvoir tester si votre Web Service est en bon fonctionnement. Sur votre classe «Calcul.java» vous devez simplement créer un Web Service via le menu : Clic droit Web Services Create Web Service Parmi les écrans de génération de déploiement vous aurez la possibilité de choisir les plateformes sur lesquelles votre Web Service et votre client seront exécutés.

Web Services - Communication inter langage 19 / 26 L un des écrans vous permet d obtenir un listing de l ensemble des méthodes que fournit votre Web Service. 5.5.3. Utilisation Lorsque le déploiement est fini, vous avez dans un dossier «sample» avec des pages JSP qui ont été générées. Exécuter la page «TestClient.jsp» sur votre serveur.

Web Services - Communication inter langage 20 / 26 Voici la page client JSP appelant le Web Service venant d être déployé : Parmi les différentes pages JSP, celles-ci permettent différentes fonctionnalités : La frame «Methods» permet de lister les méthodes du Web Service appelé. La frame «Inputs» permet de saisir un paramètre à envoyer si nécessaire et permet d appeler la méthode. La frame «Result» permet d afficher le résultat ou, le cas échéant, les messages d erreurs.

Web Services - Communication inter langage 21 / 26 Vous pourriez ensuite créer vos propres JSP vous permettant d appeler un Web Service selon le principe ci-dessous : Page de saisie du nombre : Page d appel du Web Service et d affichage du résultat : Ci-dessous vous trouverez le code à écrire afin de reproduire la deuxième des pages. La première page étant un simple formulaire, elle ne présente pas un grand intérêt. La deuxième page en revanche s occupe de récupérer le paramètre saisi et ensuite d utiliser le Bean créé par Eclipse lors de la génération du Web Service. Vous pouvez ensuite, grâce à ce Bean (ligne 1), appeler la méthode que vous souhaitez (calcul.carre() ligne 5).

Web Services - Communication inter langage 22 / 26 6. La modélisation BPML BPML (Business Process Modelling Language) permet de modéliser les processus métiers complets, mettant éventuellement en œuvre plusieurs entreprises connectées et plusieurs Web Services communiquant entre eux. Il existe de nombreux outils de modélisation, BPM rentre notamment en œuvre lors de la phase d analyse et de mise en place d un Web Service. Il convient en effet de savoir où situer le Web Service créé de celui à utiliser. BPML, plus général que WSFL (Web Service Flow Language), WSCL (Web Service Conversion Language) et XLANG, s intéresse à la représentation et à la gestion des processus métiers intra et inter-entreprises. Des efforts de modélisation et de représentation en XML de l enchaînement des opérations des processus ont été faits, il en résulte 3 grands principes l orchestration la chorégraphie la modélisation des processus 6.1. L orchestration La représentation de l orchestration d un ensemble d activités doit en restituer à la fois des données statiques : La définition des acteurs Le rôle des acteurs Que des données dynamiques : Les états et transitions Le modèle L instanciation L état d instanciation Orchestration Messages SOAP WSDL Composant

Web Services - Communication inter langage 23 / 26 D autres modèles plus spécifiques peuvent être utilisés comme le diagramme de flux (flow models) ou des diagrammes plus généraux (global models) se fondent sur des standards dépendant des choix faits par la stratégie d entreprise par exemple. L'orchestration de transactions B2B complexes, fondée sur une modélisation normalisée des flux est également une initiative qui n'avance que très lentement et sur des activités non concertées. Au niveau des services, on pouvait penser que la proposition d'annuaire UDDI apporterait une solution définitive. On constate qu'il n'en est rien et que le canevas, trop global, du projet ne convient pas à une problématique d'échanges entre entreprises se connaissant. Il se voit maintenant concurrencer par WS- Inspection (proposé par IBM et Microsoft, pourtant à l'origine de UDDI). Moins ambitieux puisque consistant en une simple exposition, par agrégation, des services d'une entreprise, il est toutefois plus adapté à cette seconde problématique. 6.2. La chorégraphie La chorégraphie, tout comme l orchestration, est définie lors de la description de la mise en œuvre de différents services sur le Web en vue d une application ou d un processus métier particulier. C est un principe mis en place lors de la phase d analyse. Interne Externe Interne Le BPML consiste à séparer la gestion des données, la gestion des processus métiers, du code de l application. Le but de ce dialecte XML est donc en partie de chorégraphier les différents modèles possibles afin de pouvoir définir des priorités dans les actions faites et d orchestrer les différents flux dans l application.

Web Services - Communication inter langage 24 / 26 6.3. Modélisation des processus La base de la modélisation des processus métiers est évidement la conception de processus mais également leurs coordinations. La notion de processus métier et la segmentation en différentes couches de votre application devient alors une nécessitée. Lors de la modélisation, il faut identifier plusieurs points différents : Les messages Les participants Les activités Les règles métiers Les défaillances Les transactions Abstractions et exécutions Voici une représentation très sommaire d un diagramme de modélisation des processus : Les messages échangés entre les participants doivent être correctement définis. L ensemble de tous les participants utilisateurs, qu ils soient statiques ou dynamiques, doit être prévu. L activité, encore appelée tâche, correspond à des unités d exécution. Les opérations élémentaires d un processus étant regroupées par domaine d activité. On dit alors qu un acteur recevant un message correspond à une activité de consommation de message (on parle d activité de production de message dans le cas inverse). Il existe 2 niveaux d activités, simple et complexe, qui permettent de savoir si l activité est consommatrice d autres activités. Une règle métier est une contrainte, exprimée sur les flux transmis, utilisée pour assurer l intégrité des données. Une défaillance génère une exception. Le BPML définit un système de gestion des exceptions. Une transaction permet de spécifier le comportement du traitement à effectuer selon des attributs définis. L abstraction de processus est la description «non instanciée» des interactions entre un processus et ses participants. Une exécution est une instanciation, correctement paramétrée pour permettre l exécution du processus.

Web Services - Communication inter langage 25 / 26 7. Conclusion Les Web Services peuvent fonctionner de différentes manières (selon le choix du programmeur qui les a développé). Ils peuvent traiter des opérations unidirectionnelles, des opérations requêtes/réponses, des opérations sollicitations/réponses ou bien des opérations de notifications. Les Web Services offrent de nombreuses fonctionnalités et une réelle souplesse d'utilisation. Ils vous permettront d'accélérer votre développement.

Web Services - Communication inter langage 26 / 26 7.1. Est-il urgent d'attendre? Les Web Services provoquent un intérêt évident auprès des architectes et des décideurs. La question récurrente concerne leur degré de maturité. Il est clair que sur une technologie aussi récente, le recul n existe pas. Mais, même si l édifice est encore fragile, il repose sur des bases solides (SOAP et WSDL) qui ont prouvé leur efficacité et leur maturité. D ores et déjà, les Web Services ont quitté le champ des échanges interentreprises pour s accaparer celui du référencement et de la mise à disposition des ressources de l entreprise, empiétant en ce sens sur les technologies de type EAI. Cette utilisation à elle seule prouve la qualité du modèle et sa pérennité, notamment au niveau des couches les plus basses. Par contre, la normalisation complète d une architecture distribuée fondée sur les Web Services n est pour le moment qu un rêve annoncé chaque année, pour la fin de l'année suivante! Par ailleurs, ce modèle n échappe pas à des problèmes de performance : les données sont transmises en ASCII dans une encapsulation XML elle-même intégrée dans une enveloppe SOAP puis HTTP Le problème du choix de la bonne granularité du service, commun à toutes les architectures distribuées, se présente dans le cas des Web Services de manière plus aiguë encore. Même s ils n'ont pas acquis la maturité nécessaire à leur industrialisation, les Web services s annoncent plus que jamais comme la réponse appropriée aux problématiques d échange de données et d intégration d applications.