Définition de l`EAI (Enterprise Application Intégration) - E
publicité
1 1. Introduction La diversité des applications existantes dans une même entreprise et la nécessité de manipulations de quantités de plus en plus importantes de données, posent un grand problème. De par le fait, la communication entre les applications d’une même entreprise devient de plus en plus difficile, à cause des technologies hétérogènes utilisées par chaque application. Par conséquent, on obtient un système incohérent, mal adapté et incompatible. Dans ce sens, et pour régler ces problèmes, le concept d’EAI est apparu comme solution. Si nous voulons donner une définition globale et simple à ce concept, nous pouvons dire que l’EAI est le chef d’orchestre qui fait communiquer et collaborer les applications d'une même entreprise et offre l’interopérabilité entre les différentes applications hétérogènes afin de fournir un système d’informations homogène et intégré. En plus à l'urbanisation de son système d'information interne, l’entreprise aujourd’hui a besoin d’une ouverture vers son environnement économique pour accomplir des échanges interentreprises avec ses partenaires par le biais d’Internet (B2B : Business to Business) et répondre aux besoins de ses clients le plus rapidement possible (B2C : Business to Consumer). Donc, nous pouvons dire qu’il y a deux principaux types d’intégrations : interne et externe. Mais réellement, le monde d’EAI est très vaste car il englobe plusieurs approches, techniques et technologies d’intégrations. Ces derniers ont évolué dans le temps depuis que le concept d’EAI a vu le jour. Actuellement, les solutions EAI de la deuxième génération sont tournées vers les processus métiers et les échanges interentreprises : elles prennent en compte les nouveaux modèles économiques créés et promus par Internet et ses technologies (TCP/IP, SMTP, HTTP, FTP, XML, etc.). De plus, les progiciels de gestion intégrés de la deuxième génération apportent une quantité de nouveaux modules organisés autour d'une nouvelle vision pour les systèmes d’information qui est l’architecture orientée services (SOA). Dans ce contexte, les services Web qui sont basés sur des technologies Web dérivées du fameux standard XML présentent de nombreux atouts pour faire communiquer des systèmes caractérisés par une hétérogénéité croissante. Ils permettent également de mettre en oeuvre des services applicatifs partagés et de gérer la connectivité aux données. 2. Architecture orientée services L’architecture orientée services est une nouvelle vision pour le système informatique. Ce dernier n’est plus décrit comme un ensemble d’applications mais comme un ensemble de services. Donc, plutôt que de privilégier une architecture applicative basée sur des contraintes 2 techniques, l’architecture orientée service (SOA) propose de découper les fonctionnalités d’une application en services métier, réutilisables dans d’autres applications. En se concentrant sur les services, les applications sont agrégées pour fournir des processus opérationnels plus riches et plus significatifs. Contrairement aux applications à trois niveaux qui sont conçues selon un découpage de type : présentation, logique applicative et base de données, la SOA sépare la conception selon le modèle : la présentation, l’interaction synchrone, les processus, les services et les bases de données. Les services d’une architecture SOA répondant, notamment, aux critères suivants: Faiblement couplés : les applications traditionnelles incluent dans leur code les données métiers de l’entreprise. Elles sont complètement liées aux systèmes pour lesquels elles ont été conçues. Cette contrainte implique la difficulté de toute demande de modification, qu’elle concerne l’accès aux données, les règles de gestion ou celles de présentation. Un faible couplage permet une scission des aspects métiers du code qui permettra une simple reconfiguration des processus quand les fonctions métiers évoluent. Distribués : les services qui composent les applications peuvent être physiquement répartis sur des différents systèmes dans l’entreprise, mais aussi au-delà. Invocables et publiables : les services doivent être invocables et publiables quels que soit les systèmes utilisés. Une architecture de services (SOA) est constituée de trois composants primaires. Le premier est le prestataire de services (le service réel). Vient ensuite le demandeur du service, autrement dit le composant qui accède au service. Enfin, l'agence de services fournit des services de découverte et d'enregistrement. Prestataire de services : Un prestataire de services est la source de la fonctionnalité des services. Un prestataire publie un contrat d'interface utilisé par les demandeurs pour accéder au service. Le contrat définit ce que fait le service et comment y accéder. Demandeur de service : Le demandeur est le client d'un service. Il utilise l'agence pour découvrir quels services sont disponibles. Une fois un service est localisé, le demandeur extrait le contrat d'interface correspondant de l'agence. Le client utilise le contrat d'interface pour comprendre comment accéder au service. Agence de services : Une agence de services est un registre des services disponibles. Chaque prestataire publie son contrat d'interface à l'agence avec les informations à utiliser pour localiser le service. Le demandeur recherche les services appropriés dans l'agence et extrait le contrat d'interface correspondant. 3 3. Caractéristiques des services Web L’évolution rapide des nouvelles technologies introduit un changement des stratégies dans les entreprises. Ces dernières veulent intégrer les nouvelles technologies dans ses systèmes d’information le plus tôt possible, pour donner plus de souplesse et de simplicité surtout pour les communications externes avec ses partenaire et clients. Les services Web font partie de celle- là. Ils ont une motivante clé qui est l’interopérabilité. Ils sont invocables via des protocoles Internet standards et légers comme HTTP, FTP, SMTP. Les services Web offrent des fonctionnalités permettant à une organisation de simplifier l'utilisation de services applicatifs à distance via le réseau Internet ou via un réseau privé [BERN 03]. 3.1 Définition des services Web Les services Web sont des composants logiciels encapsulant des fonctionnalités métiers de l'entreprise et accessibles via des protocoles standards du Web. Ils sont constitués d'un ensemble de standards : XML (Extensible Markup Language) en tant que technologie utilisée pour décrire les informations, UDDI (Universal Discovery, Description and Integration) pour trouver les services dont on a besoin, WSDL (Web Services Description Language) pour décrire le fonctionnement des services Web et SOAP (Simple Object Access Protocol) pour exécuter à distance les services Web [IMPR 02]. 3.2 Les deux parties d’un service Web Pour donner une vue plus claire et plus détaillée, nous donnerons une autre définition pour le concept de services Web : Un service Web est un composant d’application programmable accessible via les protocoles Internet standard, il est constitué de deux interfaces : la partie propriétaire du service Web expose un composant logiciel écrit dans tout type de langage (C++, java, PHP, …etc.), et la deuxième est construite d’un ensemble de standards : WSDL, SOAP et UDDI. Les applications clientes (utilisateurs de services Web) peuvent localiser ces services publiés par des applications serveur (prestataires de services Web) à l'aide du standard UDDI; elles peuvent déterminer la définition de l'interface du service à l'aide du langage WSDL et échanger des données par des documents XML reposant sur le protocole SOAP et sur des protocoles universels tels que HTTP, FTP et SMTP [SAMT 02], [BURE 03], [CIME 02]. 4 S T A N D A R D S W S D L Transport : HTTP, FTP et SMTP -------------------------------------------------------Envelope SOAP: En tête - XML Corps - XML P R O P R I E T A I R E U D D I Service wrapper Service Figure 4 : Les deux parties d’un service Web [CIME 02] La partie «standards» de la figure 4 contient l’ensemble des standards de base pour un service Web, cet ensemble simple a permis aux services Web de se bâtir une forte popularité. La figure 4 illustre également une notion importante : les standards associés aux services Web n'ont pas prétention à définir la manière de construire un service qui va être "publié". Le service peut exister ou être nouveau, et quelle que soit la technologie d'implémentation, cela ne changera pas sa présentation vis-à-vis des autres services. La partie "Service Wrapper" est elle aussi propriétaire, sans lien avec les standards Web Services [CIME 02]. En plus des trois standards de bases (SOAP, WSDL et UDDI), ils existent d’autres standards Web services qui sont dérivés du XML. Selon les objectifs et les besoins des entreprises connectées sur le Web et suite à l’évolution et la généralisation de XML, les trois classes générales des standards Web services sont distinguées [CHAU 02] : Le service de communication (SOAP) qui définit une couche de transport où XML est utilisé pour décrire la structure des messages échangés entre les services Web. Les services techniques qui sont utilitaires indispensables au bon fonctionnement de l’assemblage des services Web (UDDI, WSDL,..). Les services métiers (soit business process) : BPEL, BPEL4WS, WSBPEL, WSCDL,…etc., soit à des scénarios mutualisés entre applications (ebXML), comme le paiement électronique. 5 4.4 Architecture des services Web : L’architecture de base des services Web est composée de trois participants qui jouent trois rôles [CHAM 02]: Le consommateur du service (service requestor) : il envoie une requête pour exécuter un service Web. Le fournisseur du service (service provider) : il reçoit la requête du consommateur, la traiter et renvoi la réponse. L’agence de découverte (Discovery agency) : elle publie la description du service. Le schéma suivant décrit l’architecture de base des services Web, et explique le protocole de découverte, de recherche et d’invocation des services en utilisant les trois standards de base SOAP, WSDL et UDDI. Agence de découverte Annuaire UDDI 1 2 Client Consommateur du service Description du service 3 Service Fournisseur du service Description du service Figure 5 : Le protocole de découverte des services Web via des annuaires UDDI [CHAU 02]. La figure 5 contient deux composants (service et description du service), les trois rôles déjà indiqués précédemment et trois opérations : la publication (1), la recherche (2) et l’interaction (3) [CHAM 02] : a) Les composants Le service est considéré comme une interface décrite par un service de description (WSDL) et une implémentation qui représente le service lui même. Un service est un 6 composant logiciel déployé sur un réseau, accessible et fourni par un fournisseur. Le service peut être invoqué et interrogé par un consommateur du service. Il peut également fonctionner comme un demandeur en utilisant d'autres services Web dans son exécution. La description du service contient des détails sur l’interface et l’implémentation du service : les types de données, les opérations fournies par le service, l’endroit du service sur le réseau et les méta-données pour faciliter la découverte et l’utilisation du service par le consommateur. La description du service est réalisée dans un document WSDL et peut être publiée directement à un consommateur du service ou à une agence de découverte. b) Les rôles Fournisseur du service : du point de vue business, c'est le propriétaire du service. D'une perspective architecturale, c'est la plateforme ou l’environnement d’exécution du Web service. D’une autre façon, nous pouvons dire que dans un modèle d’échange de messages client/serveur le fournisseur du service est le serveur. Le consommateur du service : d'une perspective architecturale, c'est l'application qui recherche et invoque ou débute une interaction avec un service. Le consommateur du service peut être une personne qui utilise un navigateur comme il peut être un programme (un autre Web service, par exemple). Nous pouvons dire que dans un modèle d’échange de messages client/serveur, le consommateur du service est le client. Agence de découverte : C'est un ensemble de descriptions de services publiés par les fournisseurs de services. Il peut être centralisé ou distribué. Le consommateur du service peut chercher des services et obtenir des informations sur un service donné à partir de sa description. c) Les opérations 1. la publication : le fournisseur du service publie la description WSDL de son service Web dans l’agence de découverte. Cette dernière utilise le standard UDDI qui est considéré comme un annuaire des services. 2. Le consommateur cherche un service dans l’annuaire UDDI. Une fois il reçoit la liste des fournisseurs du service recherché, le consommateur cherche l’interface du service spécifié en WSDL puis télécharge le document WSDL correspondant. 3. le consommateur fournit les paramètres attendus par l'interface et invoque le service en utilisant SOAP. Lorsque le fournisseur reçoit la requête, il renvoie la réponse. 7 4. Standards de base pour les services Web Pour mieux comprendre l’architecture des services Web, il faut présenter avec plus de détails les trois standards de base qui sont utilisés dans cette architecture (WSDL, UDDI et SOAP), ainsi que les relations entre ces trois standards. 5.1 SOAP (le protocole de communication des Services Web) SOAP : Simple Object Access Protocol ou (Service Oriented Architecture Protocol) est un protocole XML permettant la communication entre composants, logiciels et applications en s’appuyant sur des protocoles standards de type http, smtp,…etc. Sa première version SOAP1.1 proposée à W3C en 2000 par UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA, Lotus, Microsoft et SAP. En suite, il fut standardisé par W3C pour la version SOAP 1.2. [BEDU 03]. SOAP définit un ensemble de règles pour structurer des messages qui peuvent être utilisés dans de simples transmissions unidirectionnelles, mais il est particulièrement utile pour exécuter des dialogues requête-réponse RPC (Remote Procedure Call). Il n'est pas lié à un protocole particulier. Il n'est pas non plus lié à un système d'exploitation ni à un langage de programmation, donc, théoriquement, les clients et serveurs de ces dialogues peuvent tourner sur n'importe quelle plate-forme et être écrits dans n'importe quel langage du moment qu'ils puissent formuler et comprendre des messages SOAP. En tant que tel, il s'agit d'un important composant de base pour développer des applications distribuées qui exploitent des fonctionnalités publiées comme services par des intranets ou Internet [SOAP 03]. Toutes ces caractéristiques donnent une grande motivation pour l’utilisation de SOAP dans un contexte d’intégration d’application d’entreprise (EAI) et dans un contexte d’échanges interentreprises (B2B) [CHAU 02]. Structure d’un message SOAP Un message SOAP constitué d’une enveloppe qui contient deux sous-éléments spécifiques à SOAP à l'intérieur : un env:Header (en-tête) et un env:Body (corps). Les contenus de ces éléments sont définis par l'application et ne font pas partie de la spécification de SOAP [MITR 03]. 8 Enveloppe SOAP En- tête SOAP (Header facultatif) Corps du message SOAP (Body) Figure 6: La structure des messages SOAP [CHAU 02]. L’enveloppe est la racine du document XML contenant le message SOAP. L'en-tête SOAP est optionnel: c’est un mécanisme d'extension qui donne un moyen de passer des informations dans un message SOAP sans poids pour l'application. Ces informations de "contrôle" incluent, par exemple, des directives ou des informations contextuelles liées au traitement du message. Ceci permet d'étendre un message SOAP de manière spécifique à l'application. Les éléments fils immédiats d'un élément env:Header sont appelés blocs d'en-tête et représentent un regroupement logique de données qui peuvent être destinées individuellement à des intermédiaires rencontrés sur le chemin suivi par le message entre l'émetteur et le destinataire final. Les en-têtes SOAP ont été conçus pour anticiper des utilisations diverses de SOAP, parmi lesquelles beaucoup impliquent la participation d'autres noeuds SOAP -appelés intermédiaires SOAP- au long du cheminement d'un message depuis un émetteur SOAP initial jusqu'à un récepteur SOAP final. Ceci permet à ces noeuds d'échanger des informations ajoutant de la valeur au service. Les en-têtes peuvent être inspectés, insérés, supprimés ou réacheminés par les noeuds SOAP rencontrés au long d'un chemin de message SOAP [MITR 03]. Le corps SOAP est l'élément obligatoire dans l'env:Envelope, ce qui signifie qu'il contient l'information principale transportée de bout en bout par le message SOAP. L'élément env:Body est destiné à échanger l'information entre l'émetteur SOAP initial et le noeud SOAP qui assume 9 le rôle de récepteur SOAP final dans le chemin du message. Donc, le env:Body et son contenu sont implicitement adressés et supposés être compris par le récepteur final [MITR 03]. 5.2 WSDL : le service de description Le langage WSDL (Web Service Description Language [CHRI 01]) proposé par Ariba, IBM et Microsoft auprès du W3C est un format de description des services Web fondé sur XML. Il permet de décrire de façon précise les services Web en incluant des détails tels que les protocoles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, les formats des messages d'entrée et de sortie et les exceptions pouvant être renvoyées [IMPR 02]. Le langage WSDL sert de référence à la génération de Proxy SOAP qui traduit le flux entrant SOAP dans le langage du composant (Java, C#, PHP, etc.) [BURE 03]. Il assure que le couplage entre le client et le serveur se fasse via les interfaces. Un document WSDL contient des informations opérationnelles concernant le service. La définition du service marquée par la balise <definitions> est la racine de tout document WSDL. Elle peut contenir les attributs précisant le nom du service et les espaces de nommage. Un document WSDL contient les entités suivantes: Types: précise les types de données complexes, pour lequel WSDL emploi XML Schema. Message: l’abstraction décrivant les données échangées entre services Web. Operation: l’abstraction décrivant une action implémentée par service Web. Type de port: un ensemble d’opérations implémenté par une terminaison donnée. Liaison (binding): un protocole concret d’accès à un port et un format de spécification des messages et des données pour ce port. Port: un point de terminaison identifié de manière unique par la combinaison d’une adresse Internet et d’une liaison. Service Web: une collection de ports. Chaque document WSDL peut être documenté grâce à une balise <documentation>. Cet élément est facultatif. Un document WSDL est divisé en deux parties : l’interface du service et son implémentation. L’interface du service est la partie réutilisable de la définition du service, elle peut être référencée par de multiples implémentations du service. Cette partie contient les éléments : WSDL : binding, WSDL : portType, WSDL : message et WSDL:type. Dans l’élément WSDL:portType, les opérations d’un service Web sont définies. Ces opérations définissent comment un message XML peut apparaître dans les flux des données 10 entrants et sortants. Une opération est comprise comme une signature d’une méthode dans un langage de programmation. L’élément WSDL:message spécifie comment les types de données XML constituent les différentes parties d’un message. L’élément WSDL:message est utilisé pour définir les paramètres entrants et sortants d’une opération. L’utilisation des types de données complexes dans le message est décrite dans l’élément WSDL : types. L’élément WSDL : binding décrit le protocole, le format de données, la sécurité et autres attributs pour une interface d’un service particulier (WSDL : portType) [KREG 01]. La définition d’implémentation d’un service est un document WSDL qui décrit comment une interface particulière d’un service est implémentée par un fournisseur donné. Un service Web est modélisé par un élément WSDL:service. Un élément service contient une collection (habituellement une seule) d’éléments WSDL:port. Un port associé un «endpoint» (par exemple une adresse d’un endroit sur le réseau ou une URL) à un élément WSDL : binding d’une définition d’interface d’un service [KREG 01]. Service Définition d’implémentation d’un service Port Binding Définition d’interface d’un service PortType Message Type Figure 7 : Description WSDL d’un service [KREG 01]. 5.3 UDDI : le service d’enregistrement UDDI (Universal Description, Discovery and Integration) est une spécification pour la description et la découverte de Services Web. Les spécifications UDDI se définissent à l’aide de XML Schema ; il convient de décrire les quatre constitutions de l’enregistrement d’un service Web : l’identité du fournisseur (pages blanches), la description du ou des services offerts (pages jaunes), l’information sur les modes d’exploitation et les différents modèles de données sousjacents [CHAU 02]. 11 Donc un document UDDI a la structure suivante [BEDU 03] : Pages blanches : elles référencent noms, adresses, contacts, identifiants,… des entreprises enregistrées. Ces informations sont décrites dans des entités de type Business Entity. Cette description inclut des informations de catégorisation permettant de faire des recherches spécifiques dépendant du métier de l’entreprise ; Pages jaunes : elles contenant des détails sur le métier de l’entreprise, les services qu’elle propose. Ces informations sont décrites dans des entités de type Business Service ; Pages vertes : elles comportent des informations techniques sur les services proposés. Elles incluent des références vers les spécifications des services Web et les détails nécessaires à l’utilisation de ces services. Ces informations sont décrites dans deux documents : un Binding Template et un Technology Model (tModel). <businessEntity> nom, contacts, description, identités, catégories Service Web (1..n) <businessService> <bindingTemplate> Information Technique <tModel> nom description pointeurs URL vers les specifications WSDL Figure8 : Les quatre principaux éléments d’un document UDDI [CHAU 02] Un annuaire UDDI offre plusieurs point d’entrées (API), mais les deux grandes bibliothèques d’appels sont : l’API de requête utilisé par les utilisateurs des services Web pour chercher et exploiter les services et l’API de publication pour publier les services Web par les fournisseurs (les entreprises). 5.3.1 Publication d’un document WSDL dans un annuaire UDDI 12 Pour enregistrer un service dans un annuaire UDDI, il faut publier ses deux documents WSDL : le document interface qui contient la définition du service (<Types>, <Message>, <Portype>, <binding>) et le document implémentation qui contient la description du service luimême (<Service>, <Port>) où ce dernier importe le document interface. Implémentation UDDI <import> BusinessEntity <service> BusinessService BusinessTemplate <port> BusinessTemplate <port> Interface tModel <types> <messages> <portType> <Binding> Figure 9 : Enregistrement du document WSDL dans un annuaire UDDI [BEDU 03]. 5.3.2 Utilisation d’UDDI comme un annuaire privé Dans sa première publication en septembre 2000 par Ariba, IBM et Microsoft, UDDI fut l’objet d’un certain nombre de critiques. La philosophie de UDDI est la première cause de ces critiques, parce qu’il centralise les points d’entrées des services Web c’est à dire la création d’un annuaire universel pour les services Web et les entreprises. Cet annuaire universel recueillant les inscriptions des fournisseurs de services Web permet à tout un chacun d’effectuer des recherches pour trouver les services particuliers dont il a besoin [CHAU 02]. Cette centralisation pose un grand problème qui est la lourdeur le l’annuaire UDDI considéré dans ce cas comme un grand moteur de recherche. Cette lourdeur augmente bien sur le temps de recherche des services Web. De plus, un des objectifs de cette première version 13 d’UDDI est de faciliter les échanges B2B sur l’Internet, mais UDDI pose deux grands problèmes dans ce contexte [MODI 02]: Le manque de modération dans les enregistrements UDDI existants parce que les modérateurs sont responsables de régler les teneurs des enregistrements qu'ils modèrent (des compagnies posant comme fournisseurs des services qu'ils ne fournissent pas). L'absence d'une telle modération implique que deux sur chaque trois entrées d’un enregistrement UDDI sont probablement inutiles. L’absence de sécurité et de fiabilité pour les échanges B2B particulièrement dans le cas de paiement électronique. La deuxième version d’UDDI publiée en juin 2001 a pour but de corriger quelques problèmes de la première version. Cette version est moins lourde à mettre en œuvre, elle est en plus adaptée aux échanges B2B privés (sur un Extranet), au commerce électronique (dans un contexte B2C) et même à l’intégration des applications à l’intérieur de l’entreprise. La deuxième version d’UDDI, a été suivie par d’autres initiatives, la plus importante est la spécification WS-Inspection (WSIL : Web Service Inspection Language) proposée par IBM et Microsoft. 5.4 Panorama des Web services En plus des standards de base qui constituent l’architecture des services Web, plusieurs initiatives sont lancées par des éditeurs spécialisés dans ce domaine. Ces standards sont destinés à accomplir différents objectifs (échange, découverte, description, sécurité, gestion d’interfaçage client, orchestration des processus,…etc.). Mais, tous ces standards ont un point commun qui est XML. Le tableau ci-dessous fait le point sur quelques technologies établies dans la sphère des Web Services [DAMA 01], [DAMA 02], [CHAU 02]: Fonctions Découverte Description Echange Transaction Standards UDDI, WSIL, ADS (Advertisement and Discovery of Services Protocol), ebXML. WSDL, Daml-S, OWL-S, SAWSDL, SOAP, DIME (Direct Internet Message Encapsulation), SWAT (SOAP With Attachment). SOAP-RP (SOAP-Routing Protocol) WS-Transaction (XML Web Services Transaction Language) 14 BTP (Business Transaction Protocol) SAML (Security Assertion Markup Language) Sécurité XACML (XML Access Control Markup Language) WS- Security (Web Services Security) ebXML XLang XPDL (XML Pipeline Definition Language) Gestion des processus WSFL (Web Services Flow Language) WSCL (Web Services Conversation Language) tpaML (Trading Partner Agreement Markup Language) BPWS (Business Process Execution Language) BPML (Business Process Management Language) Orchestration des BPEL4WS (Business Process Execution Language for Web processus Services)WSBPEL, WSUI (Web Services User Interface) Gestion de l’interfaçage WSXL (Web Services eXperience Language) WSRP (Web Services for Remote Portals) client WSCL (Web Services Component Model) BTP Pilotage des échanges Biztalk ebXML B2B RosettaNet Documents xCBL (XML Common Business Library) commerciaux UBL (Universel Business Language) Tableau 1 : Panorama des Web Services. 5. Cycle de vie de développement des services Web Comme nous avons déjà vu, le service Web a trois composants principaux : le demandeur du service, le service d’annuaire d’enregistrement et le fournisseur de services. Le cycle de vie de développement des services Web décrit ci-dessous prend en considération les rôles de fournisseur de services et de demandeur de services, il est défini en quatre phases [BRIT 01] : Construction : la phase de construction inclut le développement et le test de l’implémentation du service Web, la définition de la description de l’interface et la définition de la description d’implémentation. Il y a trois possibilités pour fournir une implémentation d’un service Web : soit par la création de nouveaux services, la transformation des applications existantes en services Web ou bien par la composition de nouveaux services Web et applications existantes. Le développement d’un nouveau service Web implique l’utilisation des langages de programmations et les modèles appropriés pour l’environnement de développement du fournisseur du service. 15 La transformation des applications existantes implique la génération de la définition de l’interface du service et l’enveloppement (Wrapping) de l’application existante pour permettre l’interaction entre l’application existante et le monde extérieur. L’enveloppe (Wrapper) est un logiciel qui communique avec l’application existante telle qu’elle a été conçue et offre à l’extérieur une nouvelle API (Application Programming Interface) où une interface graphique peut être développée pour cette API [SERA 01]. Il est intéressant de faire la remarque que ce travail est réalisé pour les anciennes applications (Legacy systems). Pour la troisième possibilité qu’est la composition de nouveaux services Web à partir des services Web existants implique l’ordonnancement et l’orchestration de flux des messages entre les programmes directement ou bien avec la technique de Workflow. Déploiement : la phase de déploiement inclut la publication de la description du service Web dans un service d’enregistrement, déploiement du code exécutable du service Web dans l’environnement d’exécution et l’intégration avec les legacy systems. Pour les services Web qui représentent des applications existantes, le déploiement peut inclure seulement le service Wrapper parce que l'application peut être déjà déployée. Exécution : dans cette phase le consommateur du service peut trouver la description du service et invoquer toutes les opérations définies dans le service. Gestion : cette phase couvre la gestion et l’administration de l’application du service Web : sécurité, disponibilité,…etc. 6.1 Processus de développement des services Web côté fournisseur Il existe quatre méthodes de développement d’un service Web pour un fournisseur de services, l’utilisation de ces méthodes dépend de l’existence de l’application/service et l’interface du service. Ces méthodes sont représentées dans le tableau suivant [BRIT 01]: Interface du service n’existe pas Interface de service existe déjà Nouveau Web service Green-Feild Top-Down Application/service existe déjà Bottom-up Meet-in-the-Middle Tableau 2: Les méthodes de développement des services Web pour un fournisseur du service. 16 Les quatre méthodes indiquées dans le tableau sont décrites dans ce qui suit : 6.1.1 Scénario Green-Field Cette méthode décrit comment une nouvelle description de l’interface du service sera créée pour un nouveau service Web. Dans se scénario le processus de développement est comme suit : Construction : Création d’un nouveau service Web : cette étape inclut la conception, le développement et le test du service. Création ou génération de l’interface WSDL, qui décrit le service et la manière de son invocation. La description de l’interface du service peut être générée à partir de l’implémentation du service (actuellement la plupart des plateformes de développement fournissent une génération automatique du code WSDL qui décrit le service Web). Déploiement : Publication de l’interface du service : La définition d'interface de service doit être publiée avant que le service ne soit déployé. L’interface du service est utilisée par un demandeur du service pour déterminer comment accéder à un service. Un service d’enregistrement (UDDI par exemple) est utilisé pour la fonction de publication, ce dernier peut être publique ou privé tout dépend du contexte d’utilisation. Déploiement du service Web : le code exécutable pour le service doit être fourni dans l’environnement d’exécution. Création de la définition de l’implémentation du service (la description peut être créé avec WSDL). Cette description peut être créée à partir de la façon et où le service a été déployé. Publication de la définition de l’implémentation du service dans un service d’enregistrement. Exécution : Exécution du service Web : le service Web est maintenant opérationnel, déployé dans l’environnement d’exécution et publié dans un service d’enregistrement. Il peut donc, être invoqué par les consommateurs. 6.1.2 Scénario Top-Down Cette méthode est utilisée lorsqu’un nouveau service Web peut être développé en se conformant à une interface existante. Ce type d'interface de service est habituellement une partie 17 d'une norme d'industrie qui peut être implémentée par n’importe quel nombre de fournisseurs de services. Dans se scénario, le processus de développement est comme suit : Construction : Trouver l’interface du service : cette dernière est supposée existante et publiée dans un service d’enregistrement. Donc, la fonction de recherche est faite au niveau d’un service d’enregistrement (annuaire UDDI, par exemple). Création d’un gabarit (template) de l’implémentation du service : en utilisant la définition de l’interface du service trouvé, un gabarit d’implémentation du service peut être généré. Ce dernier doit contenir toutes les méthodes et les paramètres qui doivent être implémentés par le service Web correspondant à l’interface. Développement d’un nouveau service : Le gabarit créé dans l’étape précédente est utilisé pour concevoir et développer l’application qui représente le service Web. Cette étape inclut le développement et le test du service Web. Déploiement : La phase de déploiement de cette méthode (Top-Down) est presque semblable à la phase de déploiement dans la méthode Green-Field. La seule différence c’est que la description de l’interface est déjà publiée. Déploiement du service Web. Création de la définition de l’implémentation du service. Publication de la définition de l’implémentation du service. Exécution : Exécution du service Web. 6.1.3 Scénario Bottom-Up Cette méthode est utilisée lorsque les fonctionnalités existantes d’une application sont exposées comme un service Web. L’application existante peut être implémentée sous forme d’un EJB (Enterprise Java Beans), servlet, C++, classe java,…etc. Construction: Génération de l’interface du service : l’interface est générée à partir de l’implémentation de l’application qui représente le service Web. Déploiement : Déploiement de service Web. Création de la définition de l’implémentation du service. Publication de l’interface du service. 18 Publication de la définition de l’implémentation du service. Exécution : Exécution du service Web. 6.1.4 Scenario Meet-in-the-Middle Cette méthode est utilisée lorsque la description de l’interface du service existe déjà et l’application qui représente le service existe aussi. Le problème qui peut être posé dans cette situation est que les fonctionnalités de l’application existante ne peuvent pas correspondre exactement à la description de l’interface du service Web désiré. Pour régler ce problème, nous pouvons créer un enveloppe (Wrapper) pour l’application existante qui utilise la définition de l’interface du service. Dans se scénario le processus de développement est comme suit : Construction : Trouver l’interface du service qui sera utilisée pour implémenter le service Web. Création d’un gabarit (template) de l’implémentation du service en utilisant la définition de l’interface du service trouvé Développement du service d’enveloppement (service Warpper). Déploiement : Déploiement de services Web. Création de la définition de l’implémentation du service. Publication de la définition de l’implémentation du service. Exécution : Exécution du service Web. 6.2 Processus de développement des services Web côté consommateur Le demandeur du service exécute les mêmes étapes du cycle de vie que le fournisseur du service. Mais, le demandeur du service exécute des tâches différentes pendant chaque phase. Les tâches du temps de construction (build time) pour le demandeur de service sont basées sur la méthode de liaison au service Web. Il y a deux façons pour se lier à un service donné : liaison statique et liaison dynamique. La liaison statique est utilisée lorsqu’il y a une seule implémentation du service qui peut être utilisée au moment de l’exécution. La liaison dynamique est utilisée quand un demandeur veut invoquer un service Web, mais son emplacement n’est pas connu jusqu’au moment de l’exécution. 19 Un service Proxy est généré à partir de l’interface du service. Il contient le code nécessaire pour accéder et invoquer un service Web. Il y a trois scénarios possibles pour la consommation d’un service Web, selon le type de liaison. La liaison statique est utilisée seulement au temps de constructions, cependant la liaison dynamique peut être utilisée au temps de construction et au temps d’exécution. La liaison statique ne peut être utilisée au temps d’exécution parce que le consommateur du service demande toutes les informations nécessaires au temps de construction. Liaison statique Liaison dynamique Static binding Build-time dynamic binding [Non applicable] Runtime dynamic binding Construction Exécution Tableau 3: Les méthodes de développement des services Web pour un consommateur du service [BRIT 01]. 6.2.1 Scénario Static binding Comme nous l’avons déjà indiqué, la liaison statique (static binding) est utilisée lorsqu’il y a une seule implémentation du service qui peut être invoqué au moment de l’exécution. La liaison statique est édifiée au temps de construction en localisant la définition de l’implémentation du seul service Web qui sera invoqué par le consommateur. La définition d’implémentation du service contient une référence à l'interface de service qui sera utilisé pour générer le code Proxy du service. Le Proxy est déployé avec l'application client. Le consommateur peut invoquer les opérations du service Web. Les étapes suivies dans ce scénario sont : Construction: Chercher la définition d’implémentation du service : durant la construction, l’utilisateur du service doit localiser la description de l’implémentation du service dans un service d’enregistrement (un annuaire UDDI universel ou privé). La description de l’implémentation du service contient une référence à la description de l’interface du service et à l’endroit du fournisseur où le service est accessible. Générer le Proxy : la définition de l’interface et les informations récupérées sur l’endroit du service sont utilisées pour la génération du Proxy d’implémentation. Le Proxy se conformera à l’interface du service et essayera d’accéder au service Web toujours au même endroit. 20 Tester le Proxy : avant le déploiement, le service Proxy devra tester pour vérifier qu’il peut interagir avec le service Web spécifié. Déploiement : Déployer le Proxy : après la phase de test, le Proxy devra être déployé avec l’application cliente dans l’environnement d’exécution. Exécution Invoquer le service Web : exécuter l’application client qui utilisera le Proxy pour appeler le service Web. 6.2.2 Scénario Build-time dynamic binding Ce type de liaisons est utilisé lorsque le demandeur veut invoquer un type particulier de services Web, mais l’implémentation de ce dernier n’est pas connue jusqu'au moment de l'exécution. Le type de services est défini dans une interface de service. Les étapes suivies dans ce scénario sont : Construction: Trouver la définition de l’interface du service : l’interface du service contient seulement la définition abstraite des opérations du service Web (réellement, il y a plusieurs implémentations qui fournissent les mêmes opérations et correspondent à l’interface du service. Mais chaque implémentation a sa propre description). Générer un Proxy générique: en utilisant la définition de l’interface, un Proxy peut être généré. Il peut être utilisé pour accéder à toute implémentation de la même interface. Il contient le code pour localiser une implémentation du service à travers une opération de recherche dans un service d’enregistrement (un annuaire UDDI par exemple). Tester le Proxy : le test peut être accompli en trouvant une implémentation qui correspond à l'interface du service. Déploiement : Déployer le Proxy : le Proxy devrait être déployé avec l’application client dans l’environnement d’exécution, ce dernier a besoin d’accéder au service d’enregistrement au moment de l’exécution pour chercher une implémentation de l’interface du service. Exécution: Trouver la description de l’implémentation du service : avant que le Proxy puisse invoquer le service Web, une implémentation du service doit être localisée dans le service d’enregistrement. Cette opération doit être contenue dans le code du Proxy générique. 21 Invoquer le service Web : après qu’une implémentation de service ait été trouvée, le Proxy peut l’utiliser pour invoquer le service. 6.2.3 Scénario Runtime dynamic binding: Ce type de liaisons est semblable au build-time dynamic binding. Une interface du service est utilisée pour générer un Proxy qui peut être utilisé pour invoquer n’importe quelle implémentation de cette interface. La différence entre ces deux types de liaisons est que dans ce type l’interface du service est trouvée au moment d’exécution. Après que l'interface de service soit trouvée, le Proxy est généré, compilé puis exécuté. Finalement, trois importantes remarques peuvent être ajoutées pour ce qui concerne le cycle de vie de développement des services Web (côté fournisseur et consommateur). Chaque scénario décrit auparavant peut être adapté selon certaines contraintes. Par exemple, nous pouvons éliminer l’étape de publication du service si le développeur ne sera pas utilisé un annuaire UDDI privé. Dans certains environnements, l’interface et l’implémentation du service sont implémentées dans un même fichier (par exemple, l’environnement .NET de Microsoft). Dans ce cas, la création de la définition de l’interface et de l’implémentation du service est effectuée dans une seule étape. Le cycle de vie de développement des services Web cité ci-dessus est basé beaucoup plus sur les aspects techniques. C’est pour cette raison qu’il nécessite une évolution du niveau d’abstraction (aspect conceptuel).
