THÈSE. Une approche orientée domaine pour la composition de services

Transcription

1 UNIVERSITÉ JOSEPH FOURIER (GRENOBLE I) THÈSE pour obtenir le grade de DOCTEUR de l Université JOSEPH FOURIER Discipline : INFORMATIQUE ÉCOLE DOCTORALE Mathématiques Informatique Sciences et Technologies de l Information présentée et soutenue publiquement par CRISTINA MARIN le 30 mai 2008 Une approche orientée domaine pour la composition de services Directeur de thèse : Philippe LALANDA JURY Présidente Joelle Coutaz Professeur à l Université Joseph Fourier Grenoble Rapporteurs Luciano Baresi Professeur à l École Polytechnique de Milan Laurence Duchien Professeur à l Université de Lille Examinateur Didier Pellegrin Responsable de projet Schneider Electric Encadrants Philippe Lalanda Professeur à l Université Joseph Fourier Grenoble Didier Donsez Professeur à l Université Joseph Fourier Grenoble Thèse préparée au sein du Laboratoire Informatique de Grenoble (LIG)

2

3 There are only two ways to live your life. One is as though nothing is a miracle. The other is as though everything is a miracle. Albert Einstein Table des figures 2.1 Exemple d utilisation de l AOS - l agence de voyage Les trois couches de réutilisation - [Ea04] Les acteurs d une architecture à services Environnement d integration de services Service Web simple Service Web composite Les deux parties de la définition WSDL Exemple de description WSDL du service Web Agence de Voyage - l interface Exemple de description WSDL du service Web Agence de voyage - l implémentation Les relations entre les standards UDDI et WSDL Entreprise Service Bus Les étapes d une interaction [Ley05] La plate-forme OSGi L unité de déploiement OSGi Exemple de manifeste Composant Service Binder Unité de déploiement OSGi Fichier métadata Service Binder Rôles dans une approche à services Service-Oriented Modeling and Architecture - IBM [Ars04] Les phases de la méthodologie de développement des services Web La réalisation d une composition de services - étapes Composition structurelle Composition par procédés Orchestration de services Choregraphie de services Liaison directe de type Client/Serveur Liaison indirecte par l intermède d un broker Les différents discriminants des modèles de composition de services Exemple de procédé BPEL Résumé des différents aspects de BPEL Environnement de développement et d exécution de procédés BPEL Exemple d outil de modélisation BPEL Composant SCA Relation composant SCA - implémentation Composition SCA [Gro07] Domaines SCA Copie d ecran de l outil SCA Composite Editor Résumé des différents aspects de SCA Les élements d un composant ipojo Composition structurelle de services avec ipojo Résumé des différents aspects de la composition avec ipojo Interaction "Publish/Subscribe" des services Web Les éléments d une interaction Publication/Souscription Résumé des différents aspects de WADL Synthèse des approches pour la composition de services Les principes d une approche générative

4 4.2 Le processus de développement Ligne de produits Diagramme de features - exemple Les relations entre les concepts de l IDM La principale idée du MDA L ingénierie des domaines - configuration L IDM - transformation Approche générative basée sur un DSL Les approches génératives dans le génie logiciel (après [Cza04]) Approche de développement des compositions de services Service abstrait Connecteur Exemple de composition abstraite Exemple de projection automatisée vers une technologie à services D une composition abstraite vers une application exécutable Les informations données par le modèle du domaine Infrastructure de réutilisation d une ligne de produits SOA Spécialisation de l environnement de développement pour un domaine Développement d une application spécifique à un domaine Approche IDM pour le développement de DoCoSOC Approche IDM pour la spécialisation de DoCoSOC Approche IDM pour le développement des applications Le métamodèle SOA - vue générale La spécification d un service abstrait Le service concret - éléments Les éléments de la description de service Les différentes registres de services Composition de services Les éléments d une composition exprimée par procédé exécutable Le modèle central du projet SeCSE. - [CNP + 05] Le modèle pour la composition de services du projet SeCSE. - [CNP + 05] La relation entre les deux métamodèles de base de DoCoSOC Le métamodèle d une architecture à services spécifique à un domaine La réalisation de la transformation - vue technique Le métamodèle des applications spécifiques au domaine - template La transformation de modèles par exemple L architecture générale de DoCoSOC Le développement d une application à services OSGi - exemple L infrastructure disponible dans le projet PISE L environnement DoCoSOC dans le contexte du projet PISE Une architecture hétérogène à plusieurs couches Le métamodèle conceptuel des applications Les relations entre concepts métier et concepts techniques Sélection de l outil de spécification de domaines L outil Domain Specification Tool - palette La partie données spécifiques au domaine La définition des services abstraits Un template JET pour la configuration d un device Le registre de descriptions de services - Abstract Service repository Le registre de services concrets - Concrete Service repository L architecture de référence des applications Le modèle du domaine est sauvegarder dans le dépôt de modèles Le modèle du domaine permet la génération de l éditeur dédié Génération de l éditeur d applications dédié Choix du modèle correspondant au domaine L éditeur d applications du domaine PISE

5 7.19 Modèle d application - suivi de consommation Modèle d application - remontée d alarme sur dépassement de valeur

6

7 Table des matières 1 Introduction 9 1 Problématique Organisation du manuscrit I État de l art 13 2 Approches à services. Généralités 15 1 Introduction Service. Définitions Architecture à services Technologies à services Services Web OSGi Synthèse La réalisation d une solution à services Les différents acteurs Les méthodologies existantes Obstacles à l adoption de l approche à services Synthèse Composition de services 39 1 Définition Discriminants Le contrôle de la composition Liaisons entre services Caractéristiques complémentaires Synthèse Les modèles de composition de services exprimée par procédés L orchestration de services La chorégraphie de services Modèles de composition structurelle de services Le modèle à composants SCA Le modèle de composants à services ipojo D autres modèles de composition de services Composition de services avec interaction Publication/Souscription Composition sémantique Synthèse Les approches génératives 61 1 Introduction L ingénierie des domaines Domaine. Définitions L approche

8 2.3 Application - Lignes de produits Synthèse L ingénierie dirigée par les modèles Principaux concepts de l IDM MDA, une branche de l IDM L IDM, au-delà du MDA Les relations entre les deux approches Application : Langages spécifiques aux domaines Conclusions II Contribution 75 5 Proposition 77 1 Objectifs Notre approche Approche de développement Approche centrée sur le domaine Environnement de développement spécialisé par un domaine d application Réalisation basée sur une approche IDM Conclusions Réalisation - Métamodèles et architecture 91 1 Les éléments de l approche IDM Le métamodèle SOA Le métamodèle du domaine Transformation de modèles L architecture de DoCoSOC La plate-forme de base - Eclipse L architecture générale de DoCoSOC Approche IDM pour le développement des compositions de services OSGi Conclusions Validation Contexte - Le projet PISE Distribution électrique - présentation du domaine Services à valeur ajoutée pour la distribution électrique Caractéristiques des applications spécifiques au domaine Développement automatisé des applications pour la distribution électrique Définition du modèle du domaine PISE Développement des applications spécifiques au domaine PISE Réponses aux objectifs fixés Conclusions Conclusions et perspectives Besoin d outils pour faciliter l adoption de l approche à services Développement automatisé des compositions de services Approche centrée domaine Application Références 131 8

9 If we knew what it was we were doing, it would not be called research, would it? Albert Einstein 1 Introduction Dans les 40 dernières années, le domaine informatique a beaucoup évolué. Les systèmes logiciels sont devenus indispensables dans de nombreux domaines. La taille et la complexité des logiciels est en croissance continue. Cela est dû à des besoins plus nombreux et complexes, propres aux domaines applicatifs où ces logiciels sont utilisés. Les développeurs doivent ainsi faire face à des nouveaux défis : Évolution qui s exprime comme une combinaison de plusieurs facteurs. En premier, il s agit de l évolution des plates-formes d exploitation et d exécution, mais aussi de celle concernant les technologies d implémentation des logiciels. A cela s ajoute, comme une conséquence, l évolution des outils de développement. Il ne s agit pas seulement d évolutions technologiques. Les exigences des utilisateurs évoluent aussi. Ils désirent que les logiciels soient de plus en plus évolutifs et que ces évolutions soit réalisées le plus rapidement possible ; Complexité - la complexité des logiciels est liée aux besoins propres des domaines applicatifs auxquels ils s intéressent. Un autre facteur qui a une importante influence est la complexité de la plate-forme technologique. C est le cas des applications reparties, où la mise en place de services non-fonctionnels tels que la sécurité, les transactions et la reprise sur panne, s ajoute à la complexité propre aux domaines applicatifs ; Diversité - Un autre défi est de prendre en compte l importante diversité et hétérogénéité qui s expriment, comme dans les deux autres cas, sur plusieurs axes. Tout d abord, l élaboration d un logiciel demande de maîtriser en égale mesure le domaine métier et la dimension technique. Un développeur est confronté aussi avec la diversité d outils, d artéfacts et de technologies d implémentation. Tout au long du cycle de vie d un logiciel, il conçoit un grand nombre de composants, il utilise des outils souvent incompatibles et il doit assurer l intégration des différents composants développés ; Intégration - Pour réduire le coût de développement des logiciels, les clients veulent réutiliser le plus possible les différents artéfacts dont ils disposent. Il s agit, en général, de logiciels propriétaires 1 ou bien des différentes sources de données, des bases de données déjà créées. L intégration des données provenant de sources hétérogènes est un autre grand défi auquel le développeur est confronté. En même temps, les entreprises imposent certains critères stricts pour le développement des logiciels, comme la productivité et l efficacité. Par rapport à la productivité, le besoin est de diminuer de plus en plus les temps de développement. Pour cela, les développeurs deviennent ainsi de plus en plus spécialisés sur un certain aspect lié à un problème technique. Leur niveau d expertise ainsi atteint leur permet de diminuer le temps de développement de nouveaux systèmes dans leur domaine métier. Leur efficacité est augmentée mais ils deviennent trop spécialisés sur le développement d un certain type de logiciel. Une nouvelle tendance dans le génie logiciel consiste à utiliser l expertise de ces développeurs pour automatiser le développement des systèmes logiciels spécifiques à un domaine métier [GS04] [Sel07] [Sel03]. Ainsi, sont apparues des nouvelles approches comme par exemple l ingénierie des domaines [Coo04] et l ingénierie dirigée par les modèles [Béz05]. 1 legacy code 9

10 CHAPITRE 1. INTRODUCTION Face à ce grand nombre de besoins, un développeur doit actuellement faire certains compromis. Souvent, confronté à la complexité du problème et au besoin de réduire le temps de développement et aussi le coût, les solutions proposées par les développeurs forment des architectures monolithiques, avec un fort couplage entre les composants. Ces solutions sont souvent très liées à un certain domaine applicatif [BLB + 00]. De plus, leur utilisation pour un domaine similaire demande souvent une adaptation assez importante. Il s agit donc des solutions qui ne sont pas vraiment réutilisables et flexibles. Cela est en contradiction avec les nouveaux besoins développés avec l avènement de l Internet. Le fait de disposer d une infrastructure qui permet une large connectivité à travers le monde a complètement révolutionné le monde informatique. De nouvelles possibilités sont apparues concernant les besoins d intégration, de flexibilité et de réutilisation. L approche à services est récemment apparue pour répondre à ces besoins. Elle propose de construire des applications à partir d entités logicielles qui peuvent être fournies par des organisations tierces. Ces entités sont nommées services. Un service fournit une fonctionnalité qui, pour être mise à disposition, est spécifiée, de façon syntaxique et/ou sémantique, par une description de services. La description de services permet aux éventuels clients de rechercher, découvrir et par la suite appeler un service. De manière idéale, ce protocole (découverte, sélection, invocation) peut être réalisé à l exécution, cela donnant lieu à la création d applications dynamiques utilisant des services disponibles à un moment précis. Promus principalement avec le développement des services Web, les principes de l approche à services ne sont pas tout à fait nouveaux. Par exemple, le découplage entre le fournisseur et le consommateur (le client d un service) de service trouve ses racines dans l appel de méthodes à distance RPC 2. L intergiciel CORBA permettait avec le langage IDL 3 de réaliser la séparation entre l interface d un objet et son implémentation, en décrivant dans un langage standard, indépendant de la technologie d implémentation, la partie visible d un objet, ses méthodes et propriétés. CORBA Naming Service permettait à un consommateur de service d identifier à l exécution des fournisseurs de services et le mécanisme DDI (Dynamic Invocation Interface) permettait à un client d invoquer à l exécution une méthode sur un objet distant sans connaitre sa signature. L approche à services organise ces principes et mécanismes dans une infrastructure standard, appelée architecture à services, qui permet l intégration des fonctionnalités fournies par des services dans diverses applications. Plusieurs technologies et outils pour l approche à services existent actuellement. Toutefois, le monde industriel est un peu réticent par rapport à cette approche qui re-organisent la manière de construire les applications. Pour l instant, l approche à services n est pas encore utilisée à l échelle préconisée par ses promoteurs. Un rapport de la Commission Européenne datant de Juillet 2005 [ECDG05] chiffre l utilisation de l approche à services dans l industrie au moment de son publication. Le rapport précise que l approche à services est utilisée essentiellement pour l intégration interne des systèmes existants d une entreprise. Par exemple, aux États Unis, 37% d un nombre de 116 compagnies interrogées utilisait une approche à services pour l intégration interne des systèmes, et seulement 15% pour l intégration avec d autres compagnies. La principale raison est la difficulté technique que les développeurs rencontrent en utilisant les technologies à services. Le chiffre bas donné pour l intégration externe des systèmes des différents compagnies représente, en général, la consequence du manque de confiance entre les partenaires mais aussi du coût que l utilisation d une approche à services implique. Nos travaux partent de la conviction que l existence d outils de développement est très importante pour accélérer l adoption de cette approche par le monde industriel. Ces outils doivent aider les développeurs en simplifiant leur travail. La réduction des temps de développement, l augmentation de la productivité des développeurs seront les critères qui détermineront les industriels de prendre en compte cette approche. Dans ce contexte, nos travaux proposent un environnement de développement pour la composition de services qui simplifie le travail des développeurs. De plus, il permet aux experts métier, qui ne possèdent pas forcément une expertise technique dans l approche à services et ses technologies, de spécifier des compositions de services. Le développement est ensuite automatisé par l environnement de développement. La section suivante présente notre problématique et les objectifs de cette thèse. 2 Remote Procedure Call 3 Interface Description Language 10

11 1. PROBLÉMATIQUE 1 Problématique Nos travaux partent du constat qu actuellement l utilisation d une approche à services au sein d une entreprise est un choix difficile à faire. Le développement d une approche à services nécessite l implication de nombreux acteurs ayant des compétences différentes. En plus, aujourd hui nous disposons de peu de méthodologies de développement spécifiques qui guident ces différents acteurs dans la réalisation de la tâche associée à leur rôle et qui valident la solution développée. Parmi les préoccupations impliquées dans une approche à services, nous avons abordé celle relative à la réalisation des applications qui intègrent des fonctionnalités fournies par des services. Le mécanisme permettant la réalisation de ces applications est nommé composition de services. La réalisation d une composition de services est actuellement une activité très technique et de longue durée. Les mécanismes de composition sont étroitement liés à la technologie à services support et leur apprentissage est couteux. Les développeurs d applications à services doivent avoir l expertise technique de ces technologies. Au lieu de se concentrer sur la logique métier de leur application, ils doivent gérer aussi les aspects liés à la découverte, à la sélection et la configuration des services nécessaires. Actuellement, nous disposons d outils de développement pour la réalisation des compositions de services. Mêmes s ils guident le développeur dans les différentes étapes qui interviennent pour accomplir une composition de services, ces outils restent, néanmoins, dédiés à des experts techniques. Un autre inconvénient est leur appartenance à une technologie à services particulière, bien souvent les services Web. Ainsi, on ne peut pas les adapter facilement pour les utiliser à la réalisation des compositions de services avec une autre technologie à services que celle initialement prévue. L objectif principal de nos travaux est la simplification du développement des compositions de services. Nous considérons que le développement d une composition de services doit être simple, rapide et automatisé. Il est donc besoin d éliminer la complexité technique des différentes technologies impliquées mais aussi d éliminer le plus possible la difficulté métier caractéristique du domaine applicatif considéré. Nous proposons de réaliser une composition de services de manière automatique à partir d une spécification abstraite réalisée à un niveau élevé d abstraction qui élimine les détails techniques. Pour cela, nous proposons de réutiliser des principes issues des approches génératives dont la préoccupation principale est la réutilisation de la connaissance métier pour permettre le développement automatisé des applications. Nos travaux proposent donc un environnement de développement de compositions de services, appelé DoCoSOC, qui automatise la réalisation des applications à services en réutilisant l expertise des différents acteurs impliqués. 2 Organisation du manuscrit Ce document est organisé comme suit. Après cette introduction, le manuscrit est divisé en deux grandes parties : l état de l art et la proposition. La première partie présente l état de l art. Les travaux de cette thèse se situent à la convergence de plusieurs domaines, notamment l approche à services et les approches génératives. Pour cela, l état de l art est divisé en trois chapitres : Le chapitre 2 présente, en lignes générales, les principes de l approche à services. Nous introduisons les notions de services et d architecture à services. Parmi les technologies à services disponibles actuellement, nous avons choisi de présenter deux d entre elles comme technologies de référence. Il s agit des services Web, qui représente actuellement la technologie à services la plus populaire, et des services OSGi, une technologie en plein essor. Nous exposons ensuite les motivations de notre travail. Ensuite, nous concentrons notre attention sur un point particulier de l approche à services, celui lié à la réalisation des compositions de services, sujet détaillé dans le chapitre suivant ; Le chapitre 3 focalise notre attention sur un aspect particulier de l approche à services, la composition de services. Nous présentons les différents critères qui nous permettent de caractériser les modèles existants pour la réalisation de la composition de services. Parmi les modèles existants, nous avons choisi de nous concentrer sur deux : la composition exprimée par procédés exécutables et la composition structurelle. Une technologie particulière, parmi celles disponibles actuellement pour les deux technologies de références que nous avons choisi, sera présentée pour illustrer les caractéristiques de chacun. Ce chapitre nous permet de montrer une série de difficultés auxquelles les développeurs de compositions de services sont confrontés. Cela représente la motivation de ces travaux de thèse ; 11

12 CHAPITRE 1. INTRODUCTION Le chapitre 4 présente, assez succinctement, l ingénierie des approches génératives. Plusieurs approches génératives existent aujourd hui. Dans nos travaux, nous présentons l ingénierie des domaines et quelques applications de cette approche : les lignes de produits et les langages spécifiques aux domaines. Nous introduisons ensuite une autre approche, plus générale, l ingénierie dirigée par les modèles (l IDM). Une reflexion est ensuite menée dans le but de présenter les relations entre ces deux approches. La deuxième partie introduit notre contribution, un environnement pour le développement des compositions de services basé sur la connaissance métier. La présentation de notre proposition est aussi divisée en trois chapitres : Le chapitre 5 introduit les principes de notre proposition. Nous proposons d utiliser une approche générative pour le développement des compositions de services afin de simplifier le travail des développeurs qui ne doivent réaliser qu une spécification abstraite de la composition. Pour pouvoir automatiser la réalisation de la composition ainsi spécifiée, nous proposons une approche centrée sur le domaine dont le point central est représenté par le modèle du domaine ; Le chapitre 6 présente la réalisation de nos propositions, l environnement DoCoSOC (Domain Configurable Service-Oriented Computing) ; Nous présentons ensuite dans le chapitre 7 un contexte dans lequel nous avons validé nos propositions. Nous avons utilisé DoCoSOC dans le cadre du projet RNRT PISE (Passerelles Internet Sécurisées et flexibles) pour permettre le développement des applications à services pour le domaine de la distribution électrique. Finalement, le chapitre 8 présente une synthèse des principales idées de notre proposition. A l occasion, nous reprenons certaines réflexions dans le but de mettre en avant les principales contributions, d identifier les questions ouvertes et les perspectives de ce travail. 12

13 Première partie État de l art 13

14

15 The secret to creativity is knowing how to hide your sources. Albert Einstein 2 Approches à services. Généralités 1 Introduction De nouvelles approches sont régulièrement proposées en génie logiciel pour le développement de logiciels, chaque nouveau paradigme essayant de résoudre les limitations des précédents. Bien souvent, un nouveau paradigme ne remplace pas complètement les autres mais essaie de réutiliser certains principes tout en ajoutant de nouveaux. Ainsi on a vu l apparition des approches à objets [Tay97], à composants [Szy98] et dernièrement des approches à services qui possèdent des points communs évidents. L approche orientée objets est basée sur l idée qu une application est construite à l aide d un ensemble d objets travaillant en collaboration. L objet repose sur les notions de classe (représentant un type abstrait), d héritage (mécanisme permettant la réutilisation et l adaptation des types) et de polymorphisme. La pratique a démontré que les applications construites par l approche orientée objets sont difficilement adaptables. La principale cause, qui est en même temps le principal inconvénient de cette approche, est le fait que l adaptation d une application doit être réalisée à un niveau architectural trop bas - celui des classes. L approche à composants [Szy98] est basée sur l idée qu une application est construite en réutilisant des briques logicielles préfabriquées appelées des composants. Cette approche se place à un niveau d architecture supérieur par rapport aux objets et promeut notamment l emploi de la composition comme mécanisme d assemblage des composants. Un composant représente une unité de déploiement qui encapsule un certain nombre d éléments parmi lesquels son implémentation. Pour permettre son utilisation, chaque composant précise quelle est la fonctionnalité qu il réalise mais aussi ses dépendances fonctionnelles. Des modèles spécifiques à composants, comme EJB 1 [Mic01], CCM 2 [Gro99], Fractal [BCS02], définissent la structure standard des composants, la manière de réaliser des assemblages et fournissent les mécanismes nécessaires pour la prise en compte des aspects non-fonctionnels tels que la distribution, la sécurité ou bien encore les transactions. Les modèles à composants sont peu dynamiques, c est-à-dire qu une fois l assemblage de composants crée, les changements dans l architecture sont difficiles en cours d exécution. La principale cause est le fort couplage des composants lies par des dépendances interface requise/interface fournie. Les approches à services essaient d éliminer les dépendances entre les différents éléments d une application et de permettre un faible couplage entre ceux-ci. L approche à services 3 [Pap03] est basée sur l idée qu une application peut être réalisée par composition des services logiciels mis à disposition par des fournisseurs divers ([BLB + 00][TBB03] appellent ce modèle "service-based model of software"). Ceux-ci sont configurés à un certain moment pour répondre à des besoins spécifiques et sont ensuite invoqués. L élément clé est la notion de service, une entité logicielle qui est décrite, publiée, découverte et utilisée. Une application peut être réalisée par la composition des services disponibles à un certain moment. Cette composition peut intégrer des services hétérogènes implémentés avec des technologies différentes, voire même des logiciels propriétaires (ou 1 Enterprise Java Beans 2 Corba Component Model 3 Service-Oriented Computing. 15

16 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS patrimoniaux). Un des principaux bénéfices de l approche à services est le couplage faible entre les différents services réunis dans une même application. Les dépendances fonctionnelles exprimées dans les approches à composants comme un couple interface fournie/interface requise sont éliminées dans l approche à services. La résolution des dépendances dans l approche à services doit être réalisée par le fournisseur du service. Celui-ci doit assurer le bon fonctionnement du service mis à disposition. Le client d un service n a généralement pas de contrôle sur le cycle de vie du service qu il utilise. De plus, le client d un service n a pas besoin de connaitre des détails techniques tels que la technologie d implémentation d un service, la plate-forme d exécution d un service. Cela permet de faciliter l intéroperabilité des plates-formes d exécution et d intégrer dans la même application des services ayant des provenances différentes. Cette intégration de différentes fonctionnalités déjà existantes dans une même application réduit le temps de développement et donc peut réduire les différents couts associés à ce processus. L approche à services est de plus en plus utilisée dans des nombreux domaines d applications parmi lesquels nous mentionnons : Le commerce électronique, plus généralement les solutions B2B 4 (inter-entreprises), qui a été le catalyseur de l approche à services, est un des domaines d application fortement intéressé par les mécanismes d intégration fournis par l approche à services. Prenons l exemple classique d une agence de voyage qui offre à ses clients la possibilité de réserver à l avance tous les services dont ils ont besoin lorsqu ils entreprennent un voyage. Comme on peut l observer sur la figure 2.1, pour la réalisation de ses fonctionnalités, l agence de voyage intègre d autres services - un service de réservation de vols, un autre de réservation d hôtels et un autre pour le paiement en ligne. FIG. 2.1 Exemple d utilisation de l AOS - l agence de voyage Des serveurs d applications dynamiques [Des07] qui hébergent des applications et fournissent les services techniques nécessaires. L utilisation d une approche à services permet de déployer dynamiquement, en fonction des besoins, les services techniques qui sont utilisés par des nouvelles applications afin de fournir le fonctionnement attendu de ces applications. Des applications pour des environnements fortement dynamiques comme par exemple les services à valeur ajoutée pour la télécommunication [GP07] ou pour la gestion de l énergie électrique [PLHM06] [Lal05]. L approche à services n a pas complètement remplacé l approche à composants. IBM [Ea04] propose une architecture en trois couches comme le montre la figure la couche la plus basse est celle des ob- 4 Business to business. 16

17 2. SERVICE. DÉFINITIONS. FIG. 2.2 Les trois couches de réutilisation - [Ea04]. jets utilisés pour la modélisation et l implémentation des solutions, suivie par la couche des composants qui s appuient sur une solution objet pour réaliser leurs fonctionnalités et enfin la troisième couche qui permet d exposer les fonctionnalités fournies par des composants sous la forme de services. Le niveau ajouté est celui dans lequel la fonctionnalité implémentée par des composants est exposée à travers des services. Un service fournit une fonctionnalité à travers une interface qui regroupe un ensemble d opérations et qui réalise en même temps la séparation entre le service et son implémentation. L implémentation d un service est réalisée par un ou plusieurs composants. Grâce à cette séparation entre la fonctionnalité fournie et son implémentation, l approche à services permet une évolution plus rapide voir même transparente des systèmes. Tant que la fonctionnalité du service n est pas modifiée, l implémentation du service peut être modifiée autant de fois que nécessaire. En intégrant des services hétérogènes et la standardisation des mécanismes de collaboration des services, l approche à services essaie de résoudre les problèmes critiques auxquels le génie logiciel doit répondre : l intégration des systèmes hétérogènes et l évolution continue. 2 Service. Définitions. Nous utilisons quotidiennement des services. La plus simple définition que l on puisse donner pour un service, celle donnée par le dictionnaire, est la suivante : une action réalisée par une entité pour une autre. Avant d utiliser un service, il est nécessaire de connaitre ses capacités fonctionnelles (quelle est exactement l action que le service peut réaliser pour nous) et ses caractéristiques non-fonctionnelles (sa disponibilité, le coût de son utilisation, etc.). L utilisation d un service est souvent sujet d une négociation contractualisée par un accord entre l entité fournisseur du service et l utilisateur du service. La négociation peut établir par exemple les conditions tarifaires demandées par le fournisseur du service et des conditions d utilisation imposées par l utilisateur du service (un délai admis de réponse, certaines marges acceptées pour la performance du service rendu et utilisé) [AFM05] [Tou05]. Un type particulier de service est le service logiciel 5. Généralement parlant, un service logiciel représente une entité logicielle qui est mise à la disposition d autres applications. Pour être utilisable, un service est décrit, publié et ses capacités sont ensuite découvertes par ses éventuels utilisateurs. L utilisation du service peut faire l objet d une négociation entre son fournisseur et le client à l issue de laquelle un accord de service est signé. L utilisateur peut ensuite exécuter le service et obtenir la fonctionnalité attendue. Voyons maintenant certaines définitions précises qui ont été données pour le service. "Services are self-describing, platform-agnostic computational elements."[pap03] La définition de Papazoglou présente le service comme une entité logicielle qui peut être utilisée à travers sa description. L utilisateur d un service n a pas besoin de connaitre les éléments concernant la technologie d implémentation du service et sa plate-forme d exécution. De plus, le service lui-même ne connait pas le contexte dans lequel il va être utilisé par un client. Cette indépendance à double sens est une propriété forte des services qui facilite le faible couplage. Elle permet d utiliser dans une application 5 Dans le reste de cette thèse, nous utiliserons le terme service pour désigner un service logiciel. 17

18 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS des services qui sont réalisés avec des technologies d implémentation différentes ou qui s exécutent sur des plates-formes hétérogènes. "A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is accessed by means of a service interface where the interface comprises the specifics of how to access the underlying capabilities. There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider. A service is opaque in that its implementation is typically hidden from the service consumer except for (1) the information and behavior models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs." [OAS06a] OASIS, consortium à but non-lucratif qui pilote le développement et l adoption de standards pour les applications Internet, définit un service comme une fonctionnalité fournie à travers plusieurs opérations. Cette définition ajoute à la précédente les aspects concernant la description d un service. Elle contient la définition des fonctionnalités offertes (exposées au travers d une interface de service) et un ensemble de contraintes et de politiques d accès aux fonctionnalités offertes. Une séparation est réalisée entre la fonctionnalité offerte par le service (son interface) et la réalisation du service (son implémentation). L utilisateur du service ne doit pas connaitre d autres détails que ceux qui peuvent l aider à déterminer si le service correspond à ses besoins, détails qui sont précisés par la description du service. "A service is a software resource (discoverable) with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer. Services should ideally be governed by declarative policies and thus support a dynamically reconfigurable architectural style." [Ars04] La définition d Arsanjani identifie les principales interactions qui permettent l utilisation des fonctionnalités offertes par un service. Une étape de recherche permet à un client de découvrir la description du service correspondant à ses critères. Cette description lui permet de savoir comment réaliser la liaison avec le service et éventuellement de réaliser l invocation du service. L exécution de ces trois étapes peut être différée même au moment de l exécution de l application cliente. Un environnement à services est un environnement dynamique car des descriptions de services peuvent être publiées ou retirées à tout moment. Cette situation est appelée disponibilité dynamique des services car, entre le moment de la spécification de l application cliente et le moment de son exécution, plusieurs services compatibles avec les besoins de cette application peuvent apparaitre ou disparaitre. La réalisation tardive de la liaison entre l application cliente et le service rend l architecture de l application cliente reconfigurable. En effet, d une exécution de l application cliente à une autre l architecture de celle-ci peut être différente car les services utilisés peuvent être, à cause de la disponibilité dynamique, différents. Le modèle conceptuel de [CNP + 05] distingue les services selon leur capacité de sauvegarder leur état entre deux appels d opérations réalisés par le même consommateur de services. Ainsi, deux catégories sont mentionnées : les services qui ne gardent pas d information, appelés services sans état 6, et services qui gardent l information sur leur état pour le même consommateur de services, appelés services avec état 7. Cette capacité est influencée par la modalité de réalisation du service [BBT04] [LF05]. En conclusion, les différents auteurs s accordent sur le fait qu un : "service est un système logiciel fournissant des fonctionnalités décrites par une description de service. La description de service décrit les capacités fonctionnelles et non-fonctionnelles du service. En utilisant cette spécification, les clients du service peuvent rechercher, sélectionner et invoquer le service qui répond mieux à ses critères à ce moment donné." Nous verrons par la suite que les différentes implémentations des principes de l approche orientée services débouchent sur des points de variation, tels que l information utilisée pour la description des services, le traitement de la disponibilité dynamique des services, le moment de réalisation des liaisons entre services, etc. 6 Stateless Service. 7 Stateful Service. 18

19 3. ARCHITECTURE À SERVICES. 3 Architecture à services. L exposition et l utilisation des services se fait dans un contexte particulier qui définit clairement les interactions entre le service et ses utilisateurs. Il s agit d une infrastructure standard qui est appelée architecture à services (SOA 8 ). Microsoft [SW04] propose la définition suivante : "The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface." Une architecture à services est, ainsi, l ensemble des politiques, patrons de conception et environnements qui permettent l intégration des différentes fonctionnalités exposées comme des services. Dans une telle architecture, l utilisation des services suit un protocole bien établi : publication, découverte et invocation. La figure 2.3 présente les principaux acteurs qui interviennent dans une architecture à services. FIG. 2.3 Les acteurs d une architecture à services Le premier acteur est le fournisseur du service. Il représente une personne/une organisation qui fournit des fonctionnalités sous forme de service. Après le développement d un service, un fournisseur doit mettre à disposition des éventuels utilisateurs les informations nécessaires pour pouvoir utiliser le service, c est-à-dire la description du service. La description du service rassemble en premier lieu toutes les informations concernant les fonctionnalités fournies par le service, ainsi que, le cas échéant, ses propriétés non-fonctionnelles et les types de communication acceptés. La description du service est ensuite publiée dans un registre de services (appelé également annuaire de services ou courtier de services) qui sert d acteur intermédiaire entre fournisseurs et consommateurs de services. Un utilisateur de service, nommé consommateur de service, interroge le registre de services pour obtenir les services disponibles qui correspondent à ses besoins. La découverte d un service est réalisée grâce à la description du service disponible dans l annuaire. Après avoir sélectionné le service qu il veut utiliser, le consommateur du service peut, dans certains cas, négocier auprès du fournisseur les termes suivant lesquels il peut utiliser ce service. A la fin de la négociation, un accord de service [AFM05] est réalisé entre le consommateur et le fournisseur. La plupart du temps, cet accord de service contractualise les termes de l utilisation du service par le consommateur sans garantie totale du résultat 9. Grâce aux informations disponibles dans la description du service, le consommateur de service peut, dès lors, réaliser la liaison et appeler les fonctionnalités du service. Ces interactions entre consommateurs et fournisseurs de services sont réalisées dans une architecture à services à travers un environnement d intégration et d exécution de services. Les éléments d un tel environnement peuvent être divisés en deux catégories (comme le montre la figure 2.4) : Les mécanismes de base qui permettent la publication, découverte, composition, négociation, contractualisation, invocation des différents services ; 8 Service-Oriented Architecture 9 Cette technique porte le nom de best-effort 19

20 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS Les mécanismes additionnels qui assurent la prise en charge des besoins non-fonctionnels tels que la sécurité, les transactions, la qualité de service. FIG. 2.4 Environnement d integration de services La partie fonctionnelle d un environnement d intégration de services est composée d éléments nécessaires pour garantir l utilisation des services : L invocation d un service suppose la mise en place d une communication entre le client et le service invoqué. Cette communication est réalisée à l aide d éléments chargés d assurer le transport des requêtes et des réponses modélisant la collaboration entre le client et le service utilisé (Protocole de communication et Transport dans la figure mentionnée) ; La description de service est réalisée en utilisant un langage de description spécifique qui permet aux éventuels consommateurs de services de connaitre les capacités fonctionnelles et nonfonctionnelles d un service mais aussi la manière dont ils doivent l invoquer ; Le registre de services héberge les descriptions des services mis à disposition par divers fournisseurs ; La composition de services fournit les mécanismes nécessaires pour assembler des services au sein d une application. Parmi les éléments non-fonctionnels d un environnement d intégration de services, nous mentionnons : L accord de service (ou contrat de service), représente les termes de l utilisation d un service par un consommateur de services. Les termes spécifient la fonctionnalité fournie et attendue par un consommateur de services mais aussi les aspects non-fonctionnels de l utilisation du service, comme, par exemple, un niveau de performances (temps de réponse, fiabilité) ; Un élément non-fonctionnel important dans un environnement d intégration de services est la sécurité. L utilisation des mécanismes de sécurité peut être demandée par les fournisseurs de services qui veulent gérer l accès aux services qu ils fournissent, ou par des consommateurs de services souhaitant, par exemple, garantir l intégrité des données transmises ; L intégration des services peut nécessiter une gestion de l exécution des divers services qui collaborent. Afin de garantir la cohérence des données, un environnement d intégration de services peut intégrer un élément non-fonctionnel qui traite cet aspect ; Un autre élément non-fonctionnel important est la gestion des services, qui a le rôle d assurer une meilleure administration des ressources, de leur utilisation et de la plate-forme d exécution afin de garantir le bon fonctionnement des applications. Dans cette section, nous avons présenté les principaux éléments présents dans une infrastructure à services. Le grand nombre d éléments augmente la complexité de la réalisation d une solution à base de services mais en même temps garantit un fonctionnement performant des systèmes correspondants dans un contexte opérationnel. Les différentes plates-formes à services disponibles aujourd hui incluent certains de ces éléments. L important intérêt porté aux services Web a conduit actuellement à une petite confusion qui est de rendre synonyme la notion de services Web avec la notion de services et d architecture à services. Même si les standards développés autour des services Web sont très avancés et nombreux aujourd hui, il s agit 20

21 4. TECHNOLOGIES À SERVICES seulement d une implémentation particulière des principes de l approche à services. D autres technologies à services existent Jini [Jin], UPnP 10 [For] utilisé dans les contextes des services repartis dans des réseaux ad-hocs, OSGi 11 pour des services collocalisés sur une même machine virtuelle. Dans cette thèse, nous avons choisi de présenter les technologies des services Web et OSGi que nous considérons comme deux références importantes dans ce domaine. La section suivante présente ces deux technologies. 4 Technologies à services Plusieurs implémentations de l approche à services existent actuellement. Parmi eux, nous avons choisi d en présenter deux : les services Web et les services OSGi. Notre choix a été principalement motivé par l étendue de leur utilisation dans le monde industriel et celui de la recherche. Les services Web représentent actuellement l ensemble de standards les plus connus pour la réalisation des applications Internet. Cette technologie repose sur des standards très populaires, tels que le XML ou le protocole HTTP. Les services OSGi, la deuxième technologie que nous présentons, sont de plus en plus utilisés pour la réalisation des applications à services. 4.1 Services Web Un service Web est une application rendue disponible à travers Internet qui peut être décrite, publiée, découverte et configurée en utilisant des standards reposant sur XML 12. Pour pouvoir être appelé, un service Web se voit attribuer une adresse réseau (URI). Les services Web reposent sur les technologies standards Internet (HTTP, SOAP). Du point de vue d un client, un service Web est une "boite noire" qui ne donne pas de détails sur son implémentation et qui expose, comme le montre la figure 2.5, un ou plusieurs ports (points d accès). Chaque port rassemble un ensemble d opérations qui réalisent la fonctionnalité du service. FIG. 2.5 Service Web simple Un service Web (comme celui présenté dans la figure 2.5) reçoit une requête de la part d un client, traite cette requête et à la fin du traitement envoie sa réponse. Néanmoins, la réalisation interne de cette fonctionnalité peut être plus complexe. Pour cela, le service peut utiliser les fonctionnalités d autres services (voir la figure 2.6), fait dont le client n est pas conscient. Cela nécessite une coordination entre les différents appels des services utilisés. Les services Web acceptent deux styles de communication - synchrone et asynchrone [PD04]. Les clients d un service Web synchrone expriment leur requête comme un appel de méthode avec un ensemble d arguments et attendent, avant de continuer leur exécution, la réponse à cette requête. Ce type de communication demande un couplage plus fort entre le client et le service, car le client attend toujours l obtention de sa réponse. Un deuxième type de communication est la communication asynchrone réalisée avec des messages. Quand un client invoque de manière asynchrone un service, il envoie un message de gros grain (appelé aussi document) au service. Celui-ci le reçoit, le traite et peut décider de répondre ou non. Le client continue son exécution sans attendre la réponse du service invoqué et, de cette manière, il est moins fortement couplé au service invoqué. La réponse peut arriver après une période de temps considérable. C est le cas par exemple d un client qui place une commande auprès d un service Web d un fournisseur et qui recevra sa réponse quelques jours après. 10 Universal Plug and Play extended Markup Language 21

22 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS FIG. 2.6 Service Web composite Afin de permettre le développement des applications distribuées à travers Internet, les services Web utilisent des standards développés autour des standards HTTP et XML. Pour cela, la communication est réalisée en utilisant le standard SOAP [Con07] 13, la description du service est réalisée par le standard Web Services Description Language (WSDL) et les registres de services utilisent le standard Universal Description, Discovery and Intégration (UDDI). Les sections suivantes présentent ces standards. Web Services Description Language (WSDL). La description d un service est la clé de la réalisation du fort découplage entre un consommateur de service et un fournisseur de service. En décrivant dans un format standard les propriétés fonctionnelles d un service, la description de service permet de réaliser l abstraction des différents langages de programmation utilisés pour réaliser les implémentations des services. De plus, le consommateur d un service ne doit pas connaitre des détails relatifs à la plate-forme d exécution qui héberge le service fourni par le fournisseur de service. Pour un service Web, la fonctionnalité est décrite à travers un fichier WSDL (Web Services Description Language) [Con01]. La description WSDL d un service Web est indépendante d une plate-forme et d une technologie donnée et décrit la fonctionnalité du service (ses opérations), la localisation du service (l adresse réseau du service) et comment le service doit être appelé (le type de données et les protocoles d accès). En utilisant la description WSDL, un client peut découvrir un service Web et peut invoquer n importe quelle opération fournie par le service. La description WSDL est divisée en deux parties (figure 2.7) : la définition de l interface du service (service abstrait) et la description de l implémentation (service concret) : La définition de l interface du service décrit les opérations fournies par le service, la définition de leurs paramètres et des types de données ; La description de l implémentation associe l interface abstraite du service avec une adresse réseau et avec un protocole spécifique d accès. La définition du service abstrait (l interface d un service) décrit d une manière indépendante d une plate-forme ou une technologie d implémentation les fonctionnalités fournies par le service. Cette définition abstraite peut ultérieurement être instanciée par plusieurs implémentations concrètes. La définition du service abstrait contient la partie réutilisable de la définition d un service, c est-à-dire les opérations et les messages traités par le service. Les principaux éléments d une description WSDL d une interface de service sont <types>, <message>,<porttype>, <operation>. L élément <types> d un fichier WSDL permet de définir ou de référencer des définitions externes XML des types de données. Pour définir des types de données, les développeurs peuvent utiliser les types primitifs définis par XML (integer, string, float, long, boolean, short) ou définir leurs propres types de données complexes en utilisant ces types primitifs. 13 Simple Object Access Protocol 22

23 4. TECHNOLOGIES À SERVICES FIG. 2.7 Les deux parties de la définition WSDL FIG. 2.8 Exemple de description WSDL du service Web Agence de Voyage - l interface. L élément <messages> permet la définition des structures de données qui vont être échangées dans l utilisation du service. <porttype> est l élément central d un fichier WSDL qui définit l interface du service. Dans un fichier WSDL on peut trouver une ou plusieurs définitions <porttype>. Un élément <porttype> peut contenir plusieurs opérations mais en général on associe une opération à un porttype. Pour chaque <operation> la spécification contient le nom et les messages d entrée (désignés par l élément input) et de sortie (désignés par la balise output), comme dans les langages de programmation. La figure 2.8 présente un exemple d une partie de la description WSDL de l interface d un service Web pour l agence de voyage. La partie centrale de cette définition est la définition de l interface du service - le <porttype> TravelReservationPortType qui expose une opération nommé builditinerary. Cette opération reçoit en entrée un message de type ItineraryIn. L opération retourne un message de type ItineraryIn qui représente le résultat de la réservation. La description WSDL d une interface d un service Web permet de définir quatre types d opérations qui correspondent aux types d interaction des services Web. Ces types présentent des combinaisons différentes des éléments d entrée et de sortie d une opération : Opération à sens unique (one way) - le service reçoit une requête mais n envoie pas de réponse. Pour ce type d opération la définition WSDL contient seulement la définition du message d entrée ; Opération requête/réponse (request/response) - le service reçoit une requête et, après l avoir trai- 23

24 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS tée, retourne une réponse. La définition de l interface contient dans ce cas le message d entrée et le message de sortie ; Opération sollicitation avec demande de réponse (Solicit/response) - le service envoie un message et attend sa réponse. La différence avec le type précédent est dans l initiative de l échange qui est réalisé par le service lui-même ; Opération de notification (notification) - le service envoie un message et n attend pas de réponse - il notifie seulement son client. Ce type d opération peut être utilisé par des services qui nécessitent de notifier leurs clients d un changement intervenu de leur coté, par exemple. La partie abstraite de la définition WSDL d un service Web décrit les fonctionnalités fournies par le service mais ne donne aucune indication sur la réalisation du service. Cette tache est réalisée par la partie concrète de cette description - la description de l implémentation. Cette partie composée des éléments <binding> 14, <port> et <service> donne la localisation du service, plus précisément l URL auquel le message doit être envoyé. Un élément <binding> spécifie le protocole avec lequel les clients peuvent invoquer le service. Pour l exemple présenté dans la figure 2.9, cet élément spécifie l utilisation du protocole SOAP (le standard de communication pour les services Web) comme protocole de transport et de liaison. Un élément <service> contient un ensemble d éléments <port>. Un port réalise une unique association d une adresse réseau et d un élément binding. Un service peut contenir plusieurs ports qui utilisent le même porttype de la définition abstraite de l interface. Cette situation permet d avoir plusieurs implémentations pour la même interface de service fournies éventuellement par des fournisseurs de services différents. FIG. 2.9 Exemple de description WSDL du service Web Agence de voyage - l implémentation La description WSDL permet de définir les fonctionnalités offertes par un service mais malheureusement ne permet pas encore la définition des propriétés non-fonctionnelles d un service. Nous pouvons mentionner plusieurs extensions du standard WSDL qui se proposent de traiter les aspects nonfonctionnels de la description d un service : sécurité (WS Security [OAS06c]), transaction (WS-Transaction [IBM05]). Néanmoins, afin de pouvoir utiliser un service, un client potentiel doit trouver cette information qui lui est nécessaire pour déterminer si le service lui convient. Pour cela, l architecture à services Web utilise le standard UDDI qui est présenté dans la section suivante. UDDI : Universal Description, Discovery and Integration Une des principales raisons qui détermine les entreprises d exposer leurs fonctionnalités à travers Internet ou au travers d un Intranet est la possibilité d utiliser des fonctionnalités fournies par d autres (entreprises) et de développer plus rapidement des applications. Pour pouvoir utiliser des services mis à disposition par d autres fournisseurs de services, les entreprises nécessitent un moyen d identifier leurs potentiels partenaires et de classifier les fonctionnalités offertes par ceux-ci. Pour répondre à ces besoins, l organisation UDDI qui fait partie d OASIS, a développé le standard UDDI qui en est actuellement à sa troisième version [Org04]. 14 Certains auteurs considèrent que cet élément fait partie de la description de l interface. 24

25 4. TECHNOLOGIES À SERVICES UDDI est une initiative industrielle pour la création d un standard pour les registres de services Web. UDDI fournit un canevas indépendant d une plate-forme qui permet aux consommateurs de services de : Obtenir des informations sur les entreprises fournisseurs de services Web ; Découvrir les descriptions des services Web fournis par ces entreprises et déterminer comment ces services doivent être invoqués. Afin de publier les informations concernant les services qu elle met à la disposition des consommateurs de services, une entreprise crée un fichier XML représentant du point de vue d UDDI un enregistrement (Business Registration). L information donnée dans ce fichier est structurée en trois parties : les pages blanches qui donnent des informations sur l entreprise - nom, adresse, contact ; les pages jaunes qui classifient les capacités fonctionnelles de l entreprise en utilisant une taxonomie industrielle standard ; les pages vertes qui précisent les services fournies par l entreprises et donnent des références sur la localisation des descriptions de services. Elles permettent de réaliser la liaison avec la description WSDL (ou autre, selon le cas) d un service Web. Le modèle des données d un registre UDDI est défini par un schéma XML avec quatre éléments principaux (comme le montre la figure 2.10). BusinessEntity donne des informations sur l entreprise, businessservice précise les services fournis par l entreprise, BindingTemplate spécifie la modalité de liaison avec le service et tmodel donne la spécification technique du service. FIG Les relations entre les standards UDDI et WSDL Le standard UDDI réalise aussi une distinction entre le service abstrait et son implémentation (le service concret). Ce fait permet de réaliser une certaine symétrie entre la description WSDL et UDDI (voir la figure). Ainsi, les éléments <porttype> de la description WSDL d un service et <binding> se retrouvent dans l élément <tmodel> d une définition UDDI, le <port> devient <bindingtemplate> dans UDDI et chaque <service> est enregistré comme un <businessservice> [Man03]. Le standard permet la définition de plusieurs types de registres UDDI [Org02] : les registres UDDI publics donnent accès à tous les utilisateurs qui recherchent ou veulent publier des services. Plusieurs registres publics ont déjà été développés et administrés par IBM, Microsoft ou SAP(exemple IBM Universal Business Registry UBR) 15 ; les registres UDDI privés qui appartiennent à une organisation. Ils protègent l information publiée par des droits d accès afin de garantir la cohérence des données publiées. C est, par exemple, le cas d un registre accessible dans un réseau Intranet et qui liste les services disponibles à l intérieur des différentes équipes de développement de l entreprise ; Registres UDDI partagées - par un certain nombre de fournisseurs et de consommateurs de services qui ont signé au préalable un accord. Afin de permettre le développement des applications distribuées à partir des services fournis par différents fournisseurs de services, l architecture des services Web fournit un moyen standard pour la description des services - WSDL - et un standard pour les registres de services (UDDI) qui permet de 15 En 2006 ces compagnies ont annoncé la fermeture des noeuds des registres qu elles avaient en charge 25

26 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS découvrir des fournisseurs qui rendent disponibles les fonctionnalités nécessaires. Ces deux standards permettent de découvrir des fonctionnalités mises à disposition par des fournisseurs de services différents et de savoir comment ces services doivent être invoqués. Avant de pouvoir utiliser ces services, les développeurs ont besoin d une infrastructure d intégration et d exécution de services. Dans le cas des services Web, cette infrastructure peut être un bus de communication appelé Enterprise Service Bus (ESB) que nous allons présenter succinctement dans la section suivante. Enterprise Service Bus - ESB Un ESB est une infrastructure d exécution pour le déploiement, l exécution et l administration des solutions à base de services Web [Cha04]. Un ESB offre un ensemble de fonctionnalités permettant, comme le montre la figure 2.11, l intégration d applications et de sources de données hétérogènes et l exécution de compositions des services. Le but principal d un ESB est d exposer comme des services les principales ressources d une entreprise. De cette manière, la logique métier de l entreprise peut être développée indépendamment de l infrastructure, du réseau et de la réalisation des services métier [Ley05]. FIG Entreprise Service Bus Les principaux services fournis par un ESB sont : Un bus de communication qui supporte plusieurs types de communication, des propriétés de qualité de service (sécurité, transaction, performance) et des protocoles d accès standard ; Un mécanisme pour permettre l injection de traitement dans les requêtes et les réponses des services qui circulent à travers ce bus de communication ; Un ensemble d outils standard pour l intégration rapide des services ; Un système d administration des applications. Le bus de communication d un ESB supporte plusieurs types de communication qui sont impliqués dans une architecture à services [Ka04]. Pour cela un ESB doit assurer d abord le transport des requêtes des consommateurs de services vers leurs fournisseurs. A cela s ajoute le besoin de garantir la livraison des messages envoyés par des applications vers d autres applications. Un troisième type est la communication par événements où les applications génèrent et consomment des événements indépendamment les unes des autres. Dans une architecture à services, les fonctionnalités offertes par différents fournisseurs de services peuvent être découvertes et assemblées dans des applications. Malheureusement, l intégration des services n est pas instantanée car les services sont rarement compatibles et les développeurs sont souvent confrontés aux différences des protocoles de communication, des formats des données et de qualité de services. Un ESB résout ces problèmes en interposant une chaine de médiation entre les consommateurs et les fournisseurs des services [SHLP05] [HTL05]. La médiation est pour l ESB le moyen de garantir la réalisation de la liaison entre un consommateur de service et un fournisseur de service même s ils ne sont pas compatibles. Par exemple, si le format des messages échangés entre le fournisseur et le consommateur est différent, la médiation peut transformer le format du message envoyé pour qu il corresponde au format reconnu par le fournisseur de service. 26

27 4. TECHNOLOGIES À SERVICES Si le fournisseur de service demande des messages cryptés, l ESB peut réaliser le cryptage des messages qu il transmet. Les mécanismes de médiation peuvent être nombreux : filtrage des messages, agrégation, routage des requêtes de services en fonction du contenu 16 vers des fournisseurs compatibles avec les politiques fonctionnelles et non-fonctionnelles du consommateur de service, transformation etc. FIG Les étapes d une interaction [Ley05] La figure 2.12 présente les différentes étapes de l utilisation facilitée par un ESB d un service. Une application qui nécessite d utiliser les fonctionnalités d un service connait seulement la description WSDL d un service et ne connait pas d autres détails relatifs à l implémentation du service. Elle envoie une requête (contenant les données d entrée du service nécessaire) à travers le bus ESB qui se charge de sélectionner le fournisseur de service qui implémente le service qui lui est nécessaire. Pour raffiner la sélection d un fournisseur de service afin de mieux répondre aux besoins fonctionnels et non-fonctionnels de l application client, des politiques peuvent être ajoutées à la requête du client, respectivement à une implémentation de service. Ces politiques décrivent des propriétés fonctionnelles et non-fonctionnelles comme le comportement transactionnel, des aspects relatifs à la sécurité, aux couts etc. L ESB utilise les politiques associées à la requête pour réduire le nombre de fournisseurs de services candidats pour réaliser la fonctionnalité nécessaire. Cette réconciliation permet la mise en place d un contrat de service qui contractualise les termes de l interaction entre ces deux parties. Après avoir sélectionné une implémentation de services, le bus réalise la liaison entre les deux parties. La requête est transmise au service sélectionné qui peut réaliser maintenant ces fonctionnalités. Grâce à ces multiples styles de communication et à l inclusion des notions de médiation, un ESB représente une infrastructure puissante d intégration de services, développée autour des standards des services Web (WSDL, UDDI, HTTP/SOAP, WS-Notification etc). Les mécanismes de médiation qu un ESB peut intégrer garantissent la réussite de l intégration entre services et fournissent aussi une base solide pour la réalisation de l administration de l exécution des services. 4.2 OSGi Une nouvelle technologie à services a émergé au début des années 2000 comme résultat des travaux menées par l Alliance OSGi 17. L alliance OSGi rassemble un nombre important d entreprises comme IBM, Motorola, Alcatel, France Telecom et EDF. Elle propose un ensemble de spécifications qui offrent un environnement de déploiement et d exécution orienté services, un modèle d implémentation orienté composants et un certain nombre de services techniques. Plusieurs versions des spécifications ont été proposées depuis 2000 (version 1). La version la plus récente, la version 4, est disponible depuis octobre Durant ces évolutions, le coeur de la plateforme n a pas énormément évolué mais le spectre de services standard disponibles a grandi. Ceux-ci sont 16 Routage by content. 17 http :// 27

28 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS utilisables au dessus de la plate-forme de base mais ne sont pas nécessaires pour son exécution. La plateforme de base fournit un canevas minimal de services pour assurer leur compatibilité avec les matériels embarqués. En effet, OSGi ciblait initialement des plates-formes telles que les set-top-box ou les passerelles réseaux ou résidentielles qui ont des capacités mémoires et d exécution limitées. Ils ont en plus des contraintes fortes en ce qui concerne le cycle de vie des composants logiciels puisque dans ces domaines, de nouveaux composants doivent pouvoir être déployés et assemblés dynamiquement durant l exécution de la passerelle, sans interruption de l exécution des applications déjà existantes. Avec l émergence de nouveaux domaines, tels que la téléphonie mobile et l informatique embarquée dans les véhicules, la spécification prend aussi en compte ces environnements spécifiques. Les plates-formes OSGi sont devenues le standard de fait des plates-formes orientées services pour le développement d applications Java dynamiquement reconfigurables. FIG La plate-forme OSGi La plate-forme OSGi à été définie au dessus de la plate-forme Java (voir la figure 2.13). La spécification OSGi 18 définit un modèle de conditionnement et de déploiement des services sous forme de bundles. Par rapport aux services Web qui n imposent pas un modèle de réalisation et de déploiement, la plate-forme OSGi impose ce type de conditionnement sous forme de bundles. Un bundle correspond à un fichier JAR augmenté par des métadonnées (figure 2.14). Ces métadonnées décrivent essentiellement les dépendances de code (des packages importés), les fonctionnalités fournies (des packages exportés) dans un fichier manifeste de l archive Java (JAR). Le jar contient également une classe dédiée à la gestion du cycle de vie, appelée l Activateur, les objets implémentant la logique métier du code fourni et des ressources (fichiers de configuration, librairies etc.) FIG L unité de déploiement OSGi FIG Exemple de manifeste Les bundles OSGi permettent de déployer un ou plusieurs services dans la plate-forme d exécution OSGi. Après l installation du bundle dans la plate-forme et la résolution des dépendances que celui-ci peut avoir, la phase d activation permet la publication des services fournis dans un registre de services. Pour chaque service, le registre de services mémorise la fonctionnalité fournie sous la forme du nom de l interface implémentée à laquelle peuvent être ajouté un ensemble de propriétés (clé, valeur). La spécification OSGi définit également un API pour permettre la publication et le retrait d un service, la découverte et la liaison avec un service disponible dans la plate-forme (voir l exemple de code suivant). Les mécanismes de description d un service OSGi sont, dans le cas de la plate-forme OSGi, basics. Lors de la publication d un service, la fonctionnalité fournie est décrite seulement par l intermède d un nom d interface Java auquel s ajoute, comme nous l avons mentionné, un ensemble de propriétés. De plus, le fichier manifeste associé a chaque bundle n indique pas clairement les services fournis mais seulement le nom des packages exportés. Cela implique que les clients d un service OSGi doivent avoir à priori des connaissances sur la sémantique et la syntaxe du service qu ils désirent utiliser. 18 Dans cette thèse nous nous réfèrerons à la version 3 de la spécification OSGi disponible au début de nos travaux. 28

29 4. TECHNOLOGIES À SERVICES Listing 2.1 Exemple d utilisation de l API OSGi pour la publication d un service. // d e s c r i p t i o n de l a f o n c t i o n n a l i t é f o u r n i e i n t e r f a c e TravelAgency { public I t i n e r a r y b u i l d I t i n e r a r y ( I t i n e r a r y data ) ; } // l enregistrement d un s e r v i c e TravelAgency ps=new TravelAgencyImpl ( ) ; D i c t i o n a r y d i c t=new D i c t i o n a r y ( ) ; d i c t. put ( "promotion", "England" ) ; S e r v i c e R e g i s t r a t i o n reg=bundlecontext. r e g i s t e r S e r v i c e ( TravelAgency. c l a s s. getname ( ), // l e nom de l i n t e r f a c e ps, // l o b j e t de s e r v i c e d i c t ) ; // l ensemble des p r o p r i é t é s Listing 2.2 Exemple d utilisation de l API OSGi pour la recherche d un service. // l a découverte d un s e r v i c e S e r v i c e R e f e r e n c e s r e f s []= g e t S e r v i c e R e f e r e n c e s ( TravelAgency. c l a s s. getname ( ), "((promotion=england))" ) ; Une application cliente qui utilise des services disponibles dans un certain contexte (réseau Internet, réseau intranet, espace de travail partagé, etc.) n est pas réalisée par rapport à des fournisseurs de services spécifiques. La composition de services est abstraite et fait seulement référence à des fonctionnalités nécessaires (en termes de dépendances de services). La liaison avec des fournisseurs de services répondant aux critères (fonctionnels et non-fonctionnels) de l application cliente est réalisée seulement à l exécution. L utilisation des services offerts par divers fournisseurs de services - appelés dépendances de services - rend difficile la tache d un consommateur de services. La disponibilité dynamique des fournisseurs de services est une des hypothèses de l approche à services. A tout moment un fournisseur de services peut arrêter de fournir ses services ou bien de nouveaux fournisseurs de services peuvent publier leurs services. Afin d assurer le bon fonctionnement de l application cliente, ses développeurs doivent prendre en compte toutes ces situations qui peuvent avoir une répercussion sur l exécution de l application. L application cliente doit pouvoir dépasser ces problèmes et s adapter à ces situations afin de pouvoir continuer son exécution. La capacité d adapter une application pendant l exécution est appelée adaptation dynamique[hof93]. Si le procédé d adaptation vise à changer l architecture d une application à l exécution, l architecture est dite dynamique [Ore96]. Le modèle de composant à services Service Binder a été proposé afin de diminuer la complexité du développement en prenant en charge la gestion des dépendances de services et leur disponibilité dynamique [Cer04]. Les principales idées que ce modèle à composants propose ont été reprises dans la quatrième spécification OSGi qui a été rendue publique pendant le déroulement de ces travaux de thèse (2005), puis par des nombreux modèles de composants tels que ipojo (qui sera présenté dans le chapitre suivant), Spring/OSGi 19. La section suivante présente Service Binder, un modèle de composants à services. La gestion de la disponibilité dynamique des services OSGi - Service Binder Service Binder est un modèle de composant qui assure la gestion de la disponibilité dynamique dans un environnement d exécution à services. Un composant Service Binder peut implémenter la fonctionnalité qui, après déploiement, sera mise à disposition à travers un service OSGi. Comme on l a précédemment mentionné, dans un environnement à services la disponibilité dynamique est une hypothèse. Donc, 19 http :// 29

30 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS des fournisseurs de services offrant les fonctionnalités nécessaires à la bonne exécution de ce service peuvent, à tout moment, apparaitre et disparaitre. La logique d adaptation nécessaire afin de résoudre le problème de la disponibilité dynamique est assez complexe et rend plus difficile la tache du consommateur de service. Service Binder propose de prendre en charge la réalisation de l adaptation dynamique dans le contexte d un environnement à services. Service Binder ajoute aux principes des modèles à composants des caractéristiques empruntées aux approches à services. Les approches à composants (EJB [Mic01], CCM [Gro99]) permettent la réalisation des applications à travers un assemblage statique de composants, qui est d ailleurs réalisé en phase de conception de l application. Cette solution reste inadéquate lorsqu il s agit de traiter la disponibilité dynamique. Pour résoudre ce problème, Service Binder emprunte une des idées de base de l approche à service : tout composant implémentant un service est considéré comme un fournisseur de service respectivement tout composant utilisant une fonctionnalité implémenté par un autre composant est considéré consommateur de service. En conséquence, un composant Service Binder implémentant une fonctionnalité permet la description abstraite de l architecture de l application, qui va être réalisée seulement à l exécution par le choix des fournisseurs de services disponibles. De plus, Service Binder propose aussi des mécanismes pour gérer lors de l exécution les situations qui peuvent apparaitre à cause de la disponibilité dynamique des fournisseurs de services. La disponibilité dynamique des composants requiert qu une application soit capable de s adapter par rapport aux changements qui ont lieu au niveau des instances de composants pendant l exécution. Ces tâches nécessitent l écriture d une logique d adaptation chargée de réaliser l adaptation. La programmation d une telle logique d adaptation est cependant une tâche complexe car elle nécessite de gérer les aspects concernant la supervision ainsi que la reconfiguration. Service Binder permet de séparer cette logique d adaptation de la logique applicative du composant. De plus, cette logique d adaptation est transparente pour le développeur du composant et est totalement prise en charge par un gestionnaire d instances inclus dans Service Binder. Regardons maintenant les éléments du modèle à composants afin de comprendre comment cela est possible. La figure 2.16 présente de façon schématique les éléments du modèle à composants Service Binder : FIG Composant Service Binder Les interfaces de services fournies - un composant à services déclare un nombre variable (zéro ou plusieurs) de fonctionnalités fournies à travers des services. A l instanciation du composant, les services fournis seront publiés dans le registre de services de l environnement d exécution. Des consommateurs de services pourront ensuite interroger le registre et utiliser par la suite les services disponibles qui répondent à leurs besoins. Dans le cas où le composant ne déclare pas d interface fournie il ne fournit pas des moyens d interaction aux autres entités avec lesquelles il partage l environnement d exécution ; Les interfaces de services requises - un composant à services déclare des interfaces de services requises - dépendances de services - lorsque la fonctionnalité implémentée représente une composition de services. Ces dépendances sont déclarées de façon abstraite car le composant ne fait pas référence aux composants concrets implémentant les fonctionnalités nécessaires. Les liaisons seront réalisées seulement au moment de l exécution en fonction des fournisseurs de services qui seront disponibles. En même temps, à l exécution, le composant est confronté à la disponibilité dynamique des services. Certaines liaisons avec des fournisseurs de services peuvent être mises en danger par cette situation. Dans ce cas, le composant devra s adapter afin de continuer son exécution. Pour cela, un composant Service Binder ajoute à la déclaration de chaque interface requise des informations qui seront utilisées pour configurer la logique d adaptation du composant. Ces 30

31 4. TECHNOLOGIES À SERVICES informations sont : Cardinalité - la cardinalité permet d exprimer le caractère optionnel ou obligatoire de la création d une connexion avec un fournisseur de service ainsi que la multiplicité, c est à dire si une ou plusieurs connexions peuvent être créées (création simple ou multiple) ; Politique - la politique définit si les liaisons aux services requis peuvent être changées (dynamique) ou non (statique) une fois qu elles ont été créées ; Filtre - le filtre permet de contraindre la réalisation de connexions vers un sous-ensemble de fournisseurs de services ou bien vers un fournisseur de services particulier, pour réduire le problème de l imprévisibilité. Le filtre est décrit en termes de propriétés de service associées aux composants. Les informations associées aux interfaces de service requises configurent la logique d adaptation et permettent de réaliser l assemblage et l adaptation dynamiques des applications à travers la création et le changement de connexions ; Les concepts de propriétés de configuration, d interface de contrôle et les propriétés et dépendances de déploiement sont équivalents à ceux d un composant classique. Les interfaces de contrôle permettent notamment aux instances de composants à services de participer dans les activités de reconfiguration dynamique. Les dépendances de déploiement représentent des dépendances envers des ressources telles que des librairies qui sont gérées par l environnement d exécution. 20 Comme tout modèle à composants, le modèle à composants orienté services est associé à un environnement d exécution qui est indépendant de toute application. Service Binder ne modifie en rien les principes de la plate-forme d exécution OSGi. Afin de bénéficier de ses améliorations, un bundle contenant cet environnement d exécution de ServiceBinder doit être déployé dans la plate-forme d exécution. L environnement d exécution est constitué par le gestionnaire d instance et une infrastructure sous-jacente qui contient les éléments d une plate-forme de services, notamment un registre de services et un mécanisme de notification de changements dans le registre. Chaque composant Service Binder déclare une dépendance vers cette fonctionnalité ajoutée à la plateforme de base OSGi. L unité de déploiement reste le bundle, unité de base d OSGi (voir la figure 2.17) avec l ajout d un fichier contenant la description du composant (un exemple de fichier metadata.xml est présenté dans le fig 2.18). Ce fichier contient la spécification des interfaces requises, fournies et de la logique d adaptation désirée pour ce composant. FIG Unité de déploiement OSGi FIG Fichier métadata Service Binder Les informations associées aux interfaces de service requises configurent une logique d adaptation qui fait partie de l environnement d exécution du modèle, qui est bâti sur une plate-forme de services. Cette approche permet de séparer le code applicatif, qui se trouve à l intérieur des composants, du code adaptatif. Pendant l exécution, chaque instance de composant à services est placée dans un gestionnaire d instance qui, d une façon similaire à un conteneur dans un modèle classique, gère le cycle de vie de l instance, ce qui inclut la réalisation de reconfigurations et le maintien de la validité. La reconfiguration de l instance gérée est réalisée à travers la création et la destruction de connexions (opérations bind et unbind de la reconfiguration dynamique). L adaptation réalisée par le gestionnaire est réalisée par rapport à la supervision de changements ayant lieu dans le registre de services qui concernent l arrivée ou le départ des services fournis par les instances. Le maintien de la validité représente le fait que lors de l échec d une reconfiguration, le gestionnaire d instance tente de configurer l instance gérée à nouveau pour la faire retourner à l état valide. Le fait que chaque instance de composant soit gérée de façon indépendante résulte dans des applications à services capables de s assembler et de s adapter dynamiquement et de façon autonome. 20 Les propriétés de configuration ne sont pas encore traitées par l implémentation actuelle de Service Binder. 31

32 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS Le modèle de composants à services Service Binder simplifie la réalisation des applications dynamiques à base de services OSGi. Cela est un avantage par rapport à la technologie des services Web qui ne possède pas encore les mécanismes qui permettent à une composition de services de prendre en compte la disponibilité dynamique des fournisseurs de services. 4.3 Synthèse Dans cette section nous avons présenté deux technologies à services majoritairement utilisées aujourd hui. La technologie des services Web représente actuellement l implémentation la plus connue. Elle permet le développement des applications en réutilisant des briques fonctionnelles, des services Web, mis à disposition à travers un réseau Internet. L interopérabilité des services Web hétérogènes (par rapport à une technologie d implémentation et une plate-forme d exécution) est rendue possible par l utilisation des standards développés autour des technologies Internet (XML, HTTP). Nous considérons les services Web comme un bon exemple pour l introduction des bases de l approche à services. Initialement conçus pour les applications de commerce électronique, les services Web rejoignent aujourd hui de plus en plus de domaines d applications. De nombreuses entreprises investissent dans la réalisation des systèmes logiciels qui réalisent les fonctionnalités métier à travers cette technologie. Toutefois, nous devons mentionner que l adoption d une technologie à base de services Web pose une grande difficulté technique. La principale difficulté provient du grand choix de technologies services Web qui existent aujourd hui (standards propriétaires, implémentations libres ou propriétaires des standards). Le choix d une technologie parmi celles dont on dispose actuellement impose un certain niveau d expertise technique et pose un défi pour les réalisateurs de la solution à base de services Web. Nous avons aussi présenté OSGi, une autre implémentation de l approche à services. Nous avons montré une dimension importante de cette technologie - la possibilité d adapter des applications à services dans l hypothèse de la disponibilité dynamique de services. Cette dimension n est pas, pour l instant, clairement traitée par les services Web. Nous considérons donc que, de ce point de vue, OSGi fait un grand pas en avant. En même temps, nous regrettons l importance faible qu OSGi accorde actuellement à certains aspects spécifiques de l approche à services. Nous pensons en particulier à la description de services qui pour l instant se réduit à un nom d interface de service et un ensemble de propriétés. Afin d utiliser un service, le consommateur doit connaitre a priori les capacités fonctionnelles et non-fonctionnelles du service. Ceci rend difficile la réalisation à un haut niveau de modélisation des applications intégrant des services OSGi et limite pour l instant la réalisation des applications à services par assemblage de composants, comme nous le montrerons dans le chapitre suivant. Les approches à services permettent le développement des applications à partir des services logiciels hétérogènes. En même temps, l adoption d une approche à services reste une étape importante et complexe pour une entreprise. Cette complexité est due, essentiellement, au manque de méthodologies et d outils qui guident le développeur dans la réalisation de la solution à services. 5 La réalisation d une solution à services La réalisation d une solution à base de services pour un domaine métier particulier est une activité complexe et longue qui demande l intervention de nombreux acteurs jouant différents rôles. Ces personnes sont confrontées à une tâche difficile. L adoption d une approche à services pour un domaine particulier ne consiste pas seulement en l adaptation des développements existants pour qu ils s inscrivent dans la logique des architectures à services. Ainsi, selon la stratégie adoptée, des nouvelles analyses doivent être effectuées afin de choisir la meilleure architecture pour le domaine métier considéré, l adaptation de l existant peut ne pas être toujours une solution adéquate, de nouveaux systèmes doivent être développés. Afin de simplifier cette activité, les différents acteurs impliqués ont besoin d aide dans leur démarche de développement afin de garantir que la solution réalisée est viable et correspond aux besoins fonctionnels et non-fonctionnels de leur domaine. Mais voyons d abord quels sont les principaux rôles qui interviennent dans l implémentation d une solution à services. 32

33 5. LA RÉALISATION D UNE SOLUTION À SERVICES 5.1 Les différents acteurs Plusieurs acteurs, avec un rôle bien défini, peuvent intervenir, selon leurs compétences, dans la réalisation d une approche à services dans un domaine particulier. La figure 2.19 présente quelques acteurs importants dans ce contexte. FIG Rôles dans une approche à services Une étape importante dans la réalisation d une solution à base de services est celle d analyse. Lors de cette étape, l expert métier définit le modèle de son domaine qui aide ensuite à identifier les principaux services métier dans ce domaine. Ces services métier réalisent des fonctionnalités caractéristiques pour le domaine en question. Une fois que cette identification est faite, un expert technique peut réaliser une spécification des services métier. Cette spécification précise les fonctionnalités de chaque service métier (opérations, valeurs d entrée/sortie, cas d utilisation, etc.) et représente l information utilisée par un développeur de services pour la réalisation d une implémentation. Une fois cette implémentation réalisée, pour pouvoir utiliser les fonctionnalités du service métier dans un cas concret, le développeur crée et publie la description de service correspondante dans un registre de services. Une fois que les descriptions des services métier sont disponibles, un intégrateur de services peut les utiliser pour spécifier une composition de services. Ces acteurs collaborent pour la réalisation de cette solution à services. Ils partagent donc une vision globale du même système. En même temps, ils doivent remplir une tâche précise qui représente une vue caractéristique sur ce système. Pour le guider dans sa démarche spécifique de développement, chaque acteur a besoin d un ensemble d outils lui fournissant cette vue spécifique : des méthodologies de développement, des environnements spécifiques etc. 5.2 Les méthodologies existantes Aujourd hui il existe peu de méthodologies pour les approches à services. De plus, les méthodologies existantes n ont pas encore été validées en dehors du contexte dans lequel elles ont été définies (les environnements d IBM). Cette section présente les méthodologies qui ont été définies pour la réalisation des architectures à services qui répondent aux besoins d un domaine particulier. SOMA - Service-Oriented Modeling and Architecture IBM introduit en 2004 [Ars04] [Ea04] une méthode pour la mise en place d une approche à services au sein d un domaine métier. SOMA (Service-Oriented Modeling and Architecture) combine une approche descendante pour l identification des services métier avec une approche ascendante pour l intégration des composants fonctionnels existants, des systèmes propriétaires dans l architecture à services mise en place. Elle définit une succession d étapes pour la création d une architecture à services ou la migration d un système existant vers une telle architecture (comme le montre la figure 2.20). Ces étapes peuvent être exécutées d une manière itérative pour affiner la solution tout au long de son élaboration. Comme le montre la figure, trois phases importantes ont été identifiées pour la mise en place d une solution à services : l identification de services, leur spécification et la réalisation des services. 33

34 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS FIG Service-Oriented Modeling and Architecture - IBM [Ars04] La phase d identification permet d identifier les principaux services métier et techniques qui par collaboration pourront réaliser la logique métier du domaine. Il est donc nécessaire d analyser rigoureusement le domaine en question. Une analyse descendante permet d identifier les principales fonctionnalités du domaine et de décomposer ces fonctionnalités en termes de services métier nécessaires. Une analyse ascendante des composants logiciels existants permet éventuellement d en réutiliser (après une éventuelle adaptation) dans la nouvelle architecture à services. Pour compléter ces analyses, SOMA propose un troisième type - la modélisation orientée but - qui permet d identifier d autres services nécessaires qui n ont pas été identifiés par l application des deux autres techniques. La phase de spécification permet de réaliser la spécification des services métier et techniques identifiés au préalable et des composants qui vont les implémenter. La phase de réalisation implante les composants spécifiés lors de la phase précédente. Lors de cette phase, un point important est le choix d une technologie d implémentation pour les composants, des technologies qui vont permettre d exposer les services métier et d une plate-forme d exécution. Elles doivent répondre aux besoins fonctionnels et non-fonctionnels identifiés au préalable. Un autre aspect important est le choix de la stratégie d implémentation utilisée. Une entreprise peut choisir par exemple de réutiliser son patrimoine logiciel et de l adapter/ le réorganiser afin qu il puisse s intégrer dans une architecture à services. Une autre peut décider de développer des nouveaux services et d investir dans cette implémentation. Plusieurs possibilités sont offertes pour la réalisation d une solution à services. Le développement peut être réalisé en interne par une équipe de développeurs de l entreprise ou externalisé, à la charge d une compagnie spécialisée. Une autre solution est d utiliser les services d un fournisseur de services qui offre les services nécessaires pour la mise en place de cette solution. SOMA a été depuis peu (décembre 2006) intégrée dans un des outils de développement fournis par IBM (la suite Rational V7) sous le nom de "IBM Global Services SOA Design method", qui est à notre connaissance, en ce moment, le seul outil commercial disponible. Nous considérons que la plus importante caractéristique de SOMA est l identification du processus itératif composée des trois étapes présentés. SOMA insiste également sur l importance de la phase d identification de services afin de fournir une solution adéquate en respectant les besoins du métier. Pour cela, elle conseille d utiliser conjointement une analyse du domaine avec l analyse du patrimoine logiciel. SOMA indique l importance d une rigoureuse analyse du domaine à partir des modèles métier, des cas d utilisation et des procédés métier. Mais aucune autre précision n est donnée sur la réalisation de cette analyse. Méthodologie de développement des services Web Dans [PH06], les auteurs présentent une méthodologie pour la réalisation d une approche à services en prenant comme cas particulier les services Web. Cette méthodologie souligne également l importance de l analyse du domaine dans la production d une solution à base de services pour produire une architecture conforme aux besoins fonctionnels et non-fonctionnels d un domaine métier. Cette méthodologie est basée sur un procédé itérative et incrémental qui est composée de plusieurs 34

35 5. LA RÉALISATION D UNE SOLUTION À SERVICES étapes, comme le montre la figure Chaque itération permet de compléter la solution développée afin qu elle soit performante et qu elle respecte les besoins métier. Pour chaque étape, les auteurs précisent aussi quelques considérations, quelques conseils qui aideront à obtenir une solution performante, qui peuvent être considérés en même temps comme étant des principes de conception pour les architectures à services Web. FIG Les phases de la méthodologie de développement des services Web La phase de planification est une phase préparatoire qui permet d identifier la faisabilité du projet, les objectives, la nature des problèmes qui doivent être résolus par la solution à services. Un élément clé dans le développement d une architecture à services est la compréhension du métier. Pour cela, les experts métier et les architectes doivent étudier le modèle du domaine, réaliser une décomposition en sous-métiers ou en unités fonctionnelles. En même temps, les solutions existantes sont analysées afin de déterminer de nouveaux besoins ou de prendre la décision de réutiliser l existant dans la nouvelle architecture qui doit être mise en place. L objectif de la phase d analyse est l identification des différentes unités fonctionnelles qui vont être exposées comme des services à partir de l analyse effectuée en préalable dans l étape de planification. La phase d analyse est suivie par la phase de design dans laquelle les services identifiés et les procédés métier que les services réalisent seront spécifiés. Dans la spécification des services, les auteurs soulignent l importance de la granularité de l interface d un service Web - pour les applications Internet mieux vaut disposer des services de gros grain 21 et qui donc exécuteront des procédés métier complexes. La spécification des services doit être faite en suivant un principe de conception significatif pour les approches à services - la généricité. Afin de permettre sa réutilisation dans différentes applications, un service doit être le plus générique et simple possible. Ce service générique doit être personnalisé selon le contexte dans lequel il sera utilisé. La phase de construction réalise le développement des services Web spécifiés dans la phase précédente. Lors de cette phase, la réalisation du service Web peut être faite par la création d un nouveau service, par la composition des services disponibles, par la transformation (adaptation) des applications disponibles en service Web. La phase de test permet de vérifier que les services répondent aux besoins identifiés dans la phase de planification. Un des tests qui peuvent être réalisés consiste d exécuter le service et de comparer son comportement réel avec celui attendu. Ces tests peuvent être des tests fonctionnels, pour vérifier que le service réalise les fonctionnalités attendues, des tests de performance et des tests d assemblage pour vérifier que le système réalisé par la composition de services fonctionne correctement. La phase de provision des services permet de préparer les services pour leur utilisation par d autres services ou applications. La principale préoccupation de cette phase est la mise en place des accords de services et l adoption d une stratégie de facturation de l utilisation d un service si celui-ci est mis à disposition à des clients. Par rapport aux systèmes à composants, la phase de déploiement des architectures à services comporte outre les étapes normales d installation d une implémentation de service, de résolution des dépendances, une étape de publication de la description du service dans un registre de services. Lors de la phase d exécution, les services sont opérationnels, c est-à-dire ils sont correctement déployés, ils peuvent être découverts et invoqués par des clients. Simultanément avec cette phase d exécu- 21 Programming in the very large. 35

36 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS tion est exécutée une phase de supervision. Son but est de garantir le bon fonctionnement du service et de vérifier si les accords de services sont respectés. Cette méthodologie présente un procédé itératif et incrémental composé de plusieurs phases pour le développement des architectures à services. Chaque étape a un rôle important dans cette réalisation. Malheureusement, elle est pour le moment expérimentale. Conclusions Le but d une méthodologie pour la réalisation des solutions à base de services est de définir une démarche de développement spécifique. Une telle méthodologie permet de simplifier le travail des acteurs impliqués dans la réalisation de la solution en identifiant les étapes clés du processus de développement. Même si actuellement on ne dispose pas d une méthodologie pour l approche à services largement utilisée, nous avons présenté deux méthodologies proposées dans ce contexte. Cela nous a permis d observer qu elles soulignent clairement l importance de la phase d analyse du domaine afin d identifier les différents unités fonctionnels qui seront exposés comme des services. Ensuite, la différentiation des diverses étapes de réalisation suggère qu elles font intervenir des acteurs ayant de rôles et des compétences différentes. Nous considérons que, pour faciliter l adoption à échelle industrielle des approches à services, il est nécessaire de disposer d outils qui aident/guident les développeurs tout au long des phases de réalisation de cette approche. Ces outils doivent traiter un certain nombre de limites qui rendent souvent/ actuellement difficile l adoption d une approche à services et qui seront discutées dans la section suivante. 5.3 Obstacles à l adoption de l approche à services Une entreprise qui veut adopter une approche à services est malheureusement confrontée à une tache difficile. La principale cause est l absence d un environnement de développement qui facilite le passage ou le développement d une architecture à services pour un métier considéré. Aujourd hui il existe peu d outils qui guident les développeurs dans leur démarche. De plus, on ne dispose pas d une solution qui puisse intégrer ces outils afin de fournir un suivi tout au long des différentes phases de la réalisation de l approche à services. Mais d abord quels sont les principaux besoins auxquels un environnement de développement d une approche à services doit répondre? Une vue pour chacun. Plusieurs acteurs sont impliqués dans le développement d une architecture à services qui doit répondre à un problème métier concret. Chacun a un rôle bien précis. Par exemple, l expert métier développe le modèle métier et la décomposition du domaine en unités fonctionnelles, l expert technique réalise la spécification de services, le développeur réalise l implémentation des services, l intégrateur de services spécifie les compositions de services, des procédés métier pour le cas de services Web, le déployeur assure le bon fonctionnement des services sur une plate-forme d exécution. Un environnement intégré pour le développement des solutions à services doit offrir à chacun des utilisateurs une vue conforme à son rôle, tout en gardant aussi une vision globale de la solution. Chaque vue spécifique doit fournir les outils dédiés à chaque rôle. Pour faciliter le travail des développeurs, ces outils doivent automatiser le plus possible les différentes tâches imposées par leur rôle. Par exemple, un développeur sera concerné par une vue "développement" qui lui mettra à disposition des outils de développement ; un expert métier nécessitera une vue spécifique qui lui fournit des outils de modélisation et d analyse. En même temps, la vue globale offre une vision sur l ensemble des tâches remplies par chaque utilisateur et l avancée du développement. Faciliter la phase d analyse afin de guider les développeurs dans l identification des services. Durant la phase d analyse, il est important que les expert techniques soient assistés par des experts métier. Le but de cette phase est de définir le catalogue de services qui pourront être utilisés pour réaliser les différentes fonctionnalités spécifiques au domaine métier [Joh05a]. Afin de faciliter la réalisation de cette tache complexe et de garantir l exactitude du résultat, un environnement de travail devra permettre l identification des services à partir du modèle du domaine, des cas d utilisation ou d autres artéfacts disponibles. Le modèle du domaine permettra éventuellement de réaliser la décomposition du métier du 36

37 6. SYNTHÈSE domaine en plusieurs sous-métiers. Les principales unités fonctionnelles nécessaires seront ainsi identifiées et organisées dans un catalogue de services métier. Cet aspect important est actuellement trop peu considéré par les environnements de développement existants. Permettre la spécification de services métier identifiés dans la phase d analyse. Un environnement de développement dédié doit fournir un outil de spécification de services. De plus, la spécification des services doit être faite à un niveau d abstraction élevé indépendant des technologies et des standards existants. Actuellement UML est le langage de spécification généralement utilisé, comme c est par exemple le cas dans [CNP + 05], mais des langages propriétaires peuvent être également utilisés, comme dans [QDvS04]. Faciliter l implémentation des services. L implémentation des services est une tache complexe qui est perçue parfois comme un défi par les développeurs. La difficulté majeure à laquelle ils font face est le grand nombre de standards existants pour les architectures à services. Un développeur d un service dans un métier donné doit gérer, d un coté, la complexité de la logique de son métier et, d un autre coté, la difficulté d une technologies à services particulière. Un environnement de développement doit faciliter la tache d un développeur de services par l automatisation des divers aspects relatifs aux technologies à services. De cette manière le développeur peut se concentrer sur la logique métier du service qu il doit implémenter. Parmi tous les besoins que nous avons identifiés, celui-ci est le plus considéré par les solutions existantes. Plusieurs outils de développement offrent des facilités de développement des services. Malheureusement, ils sont dédiés à une seule technologie à services, plus particulièrement celles des services Web. Automatiser la composition de services. La réutilisation des services dans une application qui fournit une fonctionnalité plus élaborée est une autre tache complexe à laquelle les développeurs sont confrontés. Comme dans le cas précédent, les développeurs sont confrontés à deux niveaux de difficulté : la difficulté technique, liée à la technologie de réalisation de la composition de services, et la difficulté provenant du domaine métier. Afin de leur faciliter la tache, un environnement de développement doit fournir les outils nécessaires pour simplifier la composition de services. Un des aspects actuellement considéré par certains outils existants est la possibilité de spécifier cette composition. Cette spécification est réalisée à un niveau plus élevé d abstraction et souvent est indépendante d une technologie particulière à services. La réalisation de l application ainsi spécifié doit être réalisée avec l aide de l environnement de développement. Pour faciliter davantage la tache des intégrateurs de services, cet environnement doit minimiser l intervention du développeur. Nous avons mentionner les principales besoins auxquels un environnement de développement d une solution à services doit répondre afin de fournir une solution intégrée qui traite tous les aspects du développement de cette solution et qui facilite le travail des différents acteurs impliqués. Bien sûr, d autres besoins existent dans ce contexte, comme par exemple ceux liés à la gestion du déploiement ou à la supervision de l exécution des services, mais nous considérons qu ils apparaissent dans un second temps. Néanmoins, nous ne minimisons pas leur importance, mais nous considérons toutefois qu un environnement pour l implémentation d une solution à services doit considérer en premier les besoins énoncés pour simplifier le travail des différents acteurs impliqués et de réduire ainsi le temps de développement. Selon nous, un temps de développement plus court sera un des facteurs de l accélération de l adoption à large échelle des approches à services. 6 Synthèse Nous avons présenté dans ce chapitre une vision générale sur l approche à services. Au centre de cette approche nous retrouvons le concept de service, une brique fonctionnelle mise à la disposition d autres applications. L utilisation d un service est rendue possible par l intermédiaire d une description de service qui fournit les informations sur les capacités fonctionnelles de celui-ci. Ainsi, une application cliente d un service, appelée consommateur de service, ne doit pas connaitre des détails techniques de l implémentation du service, tels que la technologie d implémentation ou la plate-forme d exécution. 37

38 CHAPITRE 2. APPROCHES À SERVICES. GÉNÉRALITÉS De plus, le service lui même fournit une fonctionnalité sans connaitre le contexte dans lequel celle-ci va être utilisée. Cette indépendance à double sens, appelée faible couplage, est la propriété de base de l approche à services et permet d intégrer dans une application des services hétérogènes, réalisés avec des technologies d implémentation différentes ou qui s exécutent sur des plates-formes d exécution différentes. Pour cela, l approche à services propose d utiliser des standards bien définis, tels que le XML ou le HTTP, pour la description de services ou comme base de communication. Parmi les différentes implémentations de l approche à services, nous avons présenté les services Web, utilisés pour la réalisation des applications qui utilisent les standards Internet, et les services OSGi, utilisés pour la réalisation des applications dynamiques à services. Cette présentation nous a permis de constater la difficulté à laquelle se confronte un développeur d un service. Cette difficulté est liée principalement à la multitude de technologies spécifiques et à leur complexité. Le développement d un service requiert, en plus de l expertise métier, une connaissance approfondie de la technologie d implémentation, de connaitre les mécanismes nécessaires pour la description du service, sa publication dans un registre de services, la découverte d un service et ainsi de suite. L utilisation d une approche à services au sein d une entreprise, qui détient un patrimoine logiciel dédié à la réalisation des fonctionnalités métier spécifiques, est un choix difficile à faire. Le développement d une approche à services nécessite l implication de nombreux acteurs ayant des compétences différentes. Malheureusement, aujourd hui nous disposons de peu de méthodologies de développement spécifiques qui guident ces différents acteurs dans la réalisation de leur rôle et qui valident la solution développée. Nous en avons présenté deux, mais elles ne sont pas à l heure actuelle très répandues et acceptées par la communauté. Nous avons ensuite identifié d autres besoins auxquels un environnement de développement dédié à la réalisation d une solution à services doit répondre. L objectif d un environnement de développement pour une approche à services est de simplifier la réalisation de cette approche au sein d un contexte applicatif particulier. Pour simplifier le travail des acteurs impliqués, il doit fournir à chacun les outils dédiés à la réalisation de leur tâche mais aussi de permettre d avoir à tout moment une vision globale sur la solution qu ils implémentent. Ces outils doivent, par exemple, faciliter le travail des experts métier qui identifient les principales fonctionnalités métier que la solution doit réaliser, ou celui des développeurs de services qui doivent implémenter ou adapter les services métier précédemment identifiés ou des intégrateurs de services qui doivent intégrer les services métier dont ils disposent afin de fournir une fonctionnalité plus complexe. Nos travaux adressent ces derniers besoins. Notre objectif est de proposer une solution pour simplifier la réalisation d une approche à services au sein d une entreprise, en privilégiant plus particulièrement les aspects concernant l intégration des services dans une application à services, mécanisme appelée composition de services. Dans le chapitre 3, nous présentons plus en détail la composition de services. 38

39 3 Composition de services 1 Définition La composition de services est le mécanisme qui permet l intégration des services dans une application [BDDM05]. Le résultat de la composition de services peut être un nouveau service, appelé service composite. Dans ce cas, la composition est dite composition récursive ou hiérarchique. La composition de services est aujourd hui un sujet de grand intérêt autant pour le monde de la recherche que pour le monde industriel. De nombreuses recherches visent à développer des modèles de composition de services et à fournir les outils nécessaires pour la composition de services. Mais regardons d abord en quoi consiste la réalisation d une application par composition de services (voir la figure 3.1). Elle comporte plusieurs étapes qui permettent le passage incrémental d une spécification abstraite vers une composition concrète de services, c est à dire une composition prête à être exécutée [YP04]) : 1. La définition abstraite de la composition de services a comme point de départ l identification des fonctionnalités qui doivent être remplies par l application ainsi créée. Elle demande l identification des fonctionnalités abstraites que les différents participants doivent fournir ainsi que celle des interactions qui auront lieu entre ces participants ; 2. Une phase de planification identifie les fournisseurs mettant à disposition des services compatibles avec les besoins fonctionnels identifiés au préalable. Les fournisseurs ainsi identifiés représentent des candidats pour la réalisation de la composition concrète de services ; 3. La phase de construction sélectionne, selon une stratégie donnée, les fournisseurs qui mettent à disposition les fonctionnalités nécessaires parmi les candidats précédemment identifiés. Cette étape prépare pour l exécution les services concrets correspondants : les services sont configurés et d éventuelles adaptations sont réalisées. Dans le cas d un service composite, la description du service ainsi réalisée est publiée dans un ou plusieurs registres de services ; 4. La phase d exécution de l application ainsi obtenue qui réalise l invocation des services préparés au préalable. La réalisation d une composition de services est pour l instant une activité de longue durée. Chaque étape est composée d une ou plusieurs tâches que les développeurs exécutent parfois manuellement. L identification des fournisseurs de services répondant à certains besoins fonctionnels est seulement un exemple de ce type de tâche. Les développeurs se retrouvent rarement dans la situation idéale où tous les services nécessaires à la réalisation d une composition de services sont compatibles. Dans la majorité des cas, afin de remplir correctement leur tâche, ils doivent résoudre les différentes incompatibilités des services participants, comme par exemple celle des types de données d entrée et de sortie. Deux dimensions de complexité apparaissent dans la réalisation d une composition de services. La première dimension provient de la logique métier de la composition de services. Celle-ci est souvent complexe et sa mise en place demande que les développeurs aient une expertise métier dans ce domaine. 39

40 CHAPITRE 3. COMPOSITION DE SERVICES FIG. 3.1 La réalisation d une composition de services - étapes. A cela s ajoute la deuxième dimension de complexité, celle de la complexité technique de la réalisation de l approche à services. Au lieu de se concentrer sur la réalisation de la logique métier de l application, ils doivent gérer aussi tous les aspects et mécanismes spécifiques à l adoption d une approche à services, respectivement d une technologie à services particulière : description de services, recherche et sélection, invocation etc. Ainsi, actuellement, les développeurs de compositions de services doivent avoir une double expertise, celle du métier dans lequel ils sont impliqués et celle technique, nécessaire pour la réalisation d une composition de services qui emploie une technologie particulière à services. Nous soulignons donc encore une fois le besoin d outils pour la réalisation des compositions de services. Ces outils doivent fournir des langages et des modèles de haut niveau d abstraction pour décrire indépendamment d une technologie donnée une composition de services. Cette description de haut niveau permettra aux développeurs de s abstraire d une technologie donnée et de se concentrer sur la logique métier de l application réalisée par composition de services. Un autre aspect essentiel pour simplifier le travail des développeurs est l automatisation d une partie des tâches associées à la composition de services. Plusieurs manières de réalisation d une composition de services existent actuellement. Nous allons utiliser deux discriminants principaux pour pouvoir distinguer entre ces différentes façons de réaliser une composition de services. La section 2 présente ces deux principaux discriminants mais aussi d autres aspects à considérer par rapport aux modèles de composition de services. Pour les principales manières de réalisation d une composition de services identifiées avec l aide de ces discriminants, nous allons présenter un modèle de composition disponibles en prenant toujours comme technologies de références les services Web et les services OSGi. Nous avons choisi d utiliser les discriminants présentés dans la section suivante pour pouvoir distinguer entre les deux principaux approches qui existent actuellement pour la composition de services. Leur utilisation ne doit pas être considérée comme un critère de qualité, donc ils ne nous permettent pas d affirmer qu une modalité de composer des services est plus performante qu une autre. En effet, le choix de privilégier une manière de réalisation des composition de services qu une autre est très lié au contexte pour lequel la composition de services est réalisée. 2 Discriminants Les modèles de composition de services peuvent être analysés selon plusieurs points de vue. Pour les différencier, nous avons choisi deux principaux discriminants : le contrôle de la composition c est-à-dire tous les aspects liés à la spécification de la réalisation de la fonctionnalité composite. Parmi ces aspects, nous mentionnons l identification des services participants et la description de la logique de coordination ; les liaisons entre services c est-à-dire les aspects liés à la manière dont les services impliqués dans 40

41 2. DISCRIMINANTS la composition interagissent. 2.1 Le contrôle de la composition Une composition de services assemble les fonctionnalités des services pour réaliser une fonctionnalité plus complexe. Un aspect important dans la réalisation d une composition de services est la spécification de la logique de coordination des services impliqués. Le discriminant que nous appelons contrôle de la composition traite cet aspect. Ce discriminant permet de distinguer deux moyens de réaliser le contrôle d une composition de services [FS05] : Composition structurelle - ou par assemblage. La spécification de la composition est réalisée en indiquant clairement les composants qui fournissent les services nécessaires et leurs interactions. Chaque composant déclare les interfaces qu il fournit et celles qu il requiert. L assemblage de services se traduit par un assemblage de composants pour lesquels la paire service fourni/service requis correspond (voir la figure 3.2). L assemblage de composants peut être réalisé par le moyens spécifiques au modèle à composants respectif. La logique de coordination de la collaboration des services, qui définit la manière dont la composition de services fonctionne, est spécifiée par le développeur et livrée avec l assemblage. Par exemple, l exemple de la figure 3.2 montre un assemblage de deux composants à services dont la logique de coordination est réalisée par une classe Java. Composition définie par des procédés 1. Dans ce cas, la composition de services est définie en spécifiant la logique de coordination des services par un procédé (comme le montre la figure 3.3). Un procédé est représenté généralement par un graphe orienté d activités et un flot de contrôle qui donne l ordre d exécution des activités. Chaque activité invoque la fonctionnalité fournie par un service. Cette description est réalisée en utilisant un langage spécifique qui sera ensuite interprété par un moteur d exécution spécifique afin de réaliser l invocation des services correspondants, le routage des événements et des messages d un service à un autre et la gestion des erreurs. FIG. 3.2 Composition structurelle FIG. 3.3 Composition par procédés Nous pouvons également dire que, dans le cas d une composition exprimée par un procédé, il s agit d un contrôle des invocations des services externe et que le flot de contrôle de l agencement des services est explicite. Ce flot de contrôle externe explicite d une composition de services est caractéristique dans les situations dans lesquelles le consommateur des services ne détient pas de contrôle des fournisseurs des services impliqués, comme c est le cas des services Web. Dans une composition structurelle, le contrôle de la composition de services est interne et connu seulement par son développeur. De plus, celui-ci détient un peu plus d informations sur la réalisation des services utilisés, par rapport au réalisateur d une composition par procédés. Pour spécifier une composition structurelle, l intégrateur de services doit connaitre plus de détails techniques, tels que la vue externe des composants impliqués définie par les services fournis et les services requis. Deux catégories de compositions de services exprimés par des procédés ont été identifiées : Orchestration de services - une orchestration (schématisée dans la figure 3.4) décrit l interaction des services impliqués dans la composition, les messages qu ils échangent et l ordre et la manière d invocation des services (par exemple, en séquence, en parallèle ou sous certaines conditions). Une orchestration représente généralement, pour un fournisseur de services, la réalisation du procédé métier qu il expose comme un service, procédé qui peut être de longue durée et avoir un comportement transactionnel. Le fournisseur du service détient l unique point de contrôle de l orchestration ; 1 Workflow 41

42 CHAPITRE 3. COMPOSITION DE SERVICES Chorégraphie de services - Contrairement à l orchestration, la chorégraphie ne centralise pas le contrôle de l invocation des services mais elle présente plutôt la vision globale de tous les participants sur la manière dont ils doivent collaborer à la réalisation d un but commun. La logique de la collaboration est, cette fois-ci, répartie entre les services concernés (voir la figure 3.5). Dans une chorégraphie, chaque participant impliqué joue un rôle attribué. La chorégraphie décrit d une manière globale les échanges de messages (les conversations), les règles auxquelles sont soumises les interactions des différentes parties, respectivement la manière dont les différents services se coordonnent afin de remplir le but de la composition de services. FIG. 3.4 Orchestration de services FIG. 3.5 Choregraphie de services Les notions d orchestration et de chorégraphie de services sont actuellement utilisées seulement pour les compositions de services Web. Elles peuvent être utilisées en conjonction pour permettre l intégration des systèmes des différentes entreprises [DZD06]. Ainsi, la chorégraphie modélise la collaboration entre les différentes partenaires impliqués et l orchestration est utilisée en interne par chaque partenaire pour modéliser la réalisation de la fonctionnalité rendue disponible par ceux-ci. 2.2 Liaisons entre services La réalisation d une composition de services comporte la réalisation des liaisons aux services impliqués, voire même différentes liaisons entre des services qui collaborent. Le discriminant que nous appelons "liaisons entre services" permet de différencier entre : Liaisons directes - de l application cliente aux services impliqués. Celle-ci appelle les services impliqués et récupère leurs réponses, comme le montre la figure Ces liaisons directes correspondent aux liaisons de types client-serveur. FIG. 3.6 Liaison directe de type Client/Serveur. Liaisons indirectes ou via un "broker". L application cliente ne communique pas directement avec les services impliqués mais utilise comme interlocuteur une entité intermédiaire, appelée broker (voir la figure 3.7). Ce type de liaisons correspondent à : La communication par événements - les consommateurs de services publient des événements qui sont reçus par les fournisseurs de services. La réception d un événement déclenche l exécution du fournisseur de service ; Publication/Subscription (Publish/Subscribe) - les consommateurs de services publient des messages qui sont reçus et administrés par une entité centrale. Les fournisseurs de services déclarent leur intérêt dans un certain type de message ou par rapport à leur contenu auprès de cette entité centrale [EFGK03]. Lorsqu un message est disponible, ce gestionnaire de messages l envoie vers tous les consommateurs qui sont intéressés. Les fournisseurs et les consommateurs 42

43 2. DISCRIMINANTS FIG. 3.7 Liaison indirecte par l intermède d un broker. peuvent utiliser des API standards pour envoyer et recevoir les messages de notifications (voir la spécification WireAdmin pour OSGi, WS-Notification pour les services Web [OAS06b], Corba DDS, Corba Event Service). Cela élimine l interaction directe entre les fournisseurs de services et les consommateurs et offre une plus grande flexibilité en réduisant le couplage [HBGS07]. La différence avec le mode de liaison précédant réside dans le fait que les interactions publications/souscriptions demandent une gestion plus avancée des messages reçus, avec, par exemple, une historisation d un certain nombre d entre eux. 2.3 Caractéristiques complémentaires Comme nous l avons déjà mentionné, la réalisation d une composition de services rassemble plusieurs étapes qui permettent le passage incrémental d une spécification abstraite de la fonctionnalité attendue à une application exécutable. Un aspect important est l identification des services concrets appelée, d une manière plus générale, sélection de services. De ce point de vue, la sélection des services concrets peut être faite : Au moment de la conception 2. Dans ce cas, les étapes 2 et 3 (planification, construction) sont réalisées avant l exécution de l application en tenant compte de l état de l environnement d exécution et de diverses stratégies de déploiement. Cela peut donner lieu à une composition statique, avec des participants prédéfinis et des liaisons entre ceux-ci figés ; Au moment du déploiement. En général, les consommateurs de services ne contrôlent pas le cycle de vie des services qu ils utilisent. Néanmoins, si l intégration de services est réalisée à l intérieur d un domaine précis, quand le fournisseur et le consommateur de services coïncident, à l intérieur du même domaine d administration qui leur donne le contrôle sur le cycle de vie des services, on peut envisager des stratégies de déploiement spécifiques. Par exemple, une stratégie de déploiement peut imposer le déploiement de tous les services utilisés pour la construction d une application par composition de services. Dans un autre cas, le déploiement d une telle application peut engendrer le besoin de déployer des services techniques, des médiateurs afin de garantir le bon fonctionnement de la composition de services ; A l exécution - La sélection des participants et la réalisation des liaisons sont retardées jusqu au moment de l exécution. Les étapes de planification et de construction sont réalisées au moment de l exécution en fonction des fournisseurs de services disponibles à ce moment. Ce type de composition est nommé composition dynamique. Le moment de la sélection des services concrets peut engendrer la création de deux types de liaisons entre l application cliente et les services utilisés : des liaisons statiques, définies avant l exécution, et des liaisons dynamiques réalisées à l exécution. Un troisième type de liaison peut être également rencontré dans les compositions de services - la liaison adaptative. Dans ce cas, la composition est réalisée à manière d une composition statique, avec des liaisons décidées avant l exécution, mais qui peuvent être changées si besoin en fonction de certaines stratégies. Si un fournisseur de services n est plus disponible au moment de la réalisation de la liaison avec le service fourni, la composition adaptative peut choisir un fournisseur compatible et se lier au service qu il met à disposition. C est le cas par exemple, des compositions réalisées par Service Binder pour OSGi que nous avons présentées dans le chapitre précédent. Un autre aspect important d une composition de services est le contrôle de l exécution de la composition de services. En fonction de cet aspect, nous distinguons entre : L exécution centralisée est réalisée par une seule entité [CS01]. La composition structurelle et l orchestration de service utilisent une entité centrale pour exécuter et contrôler la logique de 2 Design time 43

44 CHAPITRE 3. COMPOSITION DE SERVICES coordination. Celle-ci gère les interactions des différents services intervenant dans la composition de services ; L exécution distribuée pour laquelle la responsabilité de la coordination de l exécution de la composition est partagée entre les différents fournisseurs des services, comme dans le cas des chorégraphies de services [BDSN02]. Par exemple, une chorégraphie de services a une exécution distribuée ou chaque partie contrôle son exécution mais aussi respecte les règles de collaboration établies. 2.4 Synthèse Plusieurs modèles de composition de services existent actuellement. Pour les différencier nous utilisons deux discriminants principaux : le contrôle de la composition et les types de liaisons aux services. Nous avons aussi énumérer d autres aspects à considérer dans la présentation des modèles de composition à services. La figure 3.8 présente les différents types de composition à services identifiés par l utilisation de nos discriminants. FIG. 3.8 Les différents discriminants des modèles de composition de services. La section suivante présente les principaux modèles de composition de services des deux technologies de référence que nous avons présentées dans le chapitre 2. 3 Les modèles de composition de services exprimée par procédés La composition de services exprimée par les procédés décrit à travers un procédé le comportement de la composition des services. Un procédé est composé d un ensemble d activités et un flot de contrôle. Pour une composition de services, chaque activité composante correspond à l invocation d un service et le flot de contrôle définit les conditions de l exécution de ces activités, c est à dire l ordre d invocation des services participants et les différents interactions entre ces services. Actuellement, ce type de composition de services est utilisé pour les services Web. Deux approches existent actuellement pour ce type de composition de services. L orchestration de services décrit la vision centralisée d une composition de services et la chorégraphie de services décrit, d un point de vue globale, la manière dont un ensemble de services collaborent pour atteindre un but commun. Nous présentons l orchestration de services dans la section 3.1 et la chorégraphie de services dans la section L orchestration de services L orchestration offre une vision centralisée de la logique de coordination d une composition de services Web. Elle présente la vision (interne) du fournisseur du service composite résultant de cette composition. L exécution de l orchestration de services est contrôlée par une entité centrale - appelée moteur d exécution- qui gère l invocation des différents services intervenant dans la composition selon la logique définie par le procédé. 44

45 3. LES MODÈLES DE COMPOSITION DE SERVICES EXPRIMÉE PAR PROCÉDÉS Plusieurs langages d orchestration pour les services Web existent actuellement. Parmi ceux-ci, nous avons choisi de détailler le langage BPEL (Business Process Execution Language) qui est le plus utilisé actuellement. Le langage BPEL BPEL [IBM07] [OAS07], qui est le résultat d une collaboration entre IBM, BEA Systems, Microsoft, SAP AG, Siebel Systems est actuellement la spécification la plus connue pour l orchestration des services Web. Conçu comme les autres standards pour les services Web au dessus du langage XML, BPEL permet la description d une composition de services à travers un procédé. Le résultat de cette composition est un service Web composite dont la description WSDL peut être publiée dans un registre UDDI de services. La spécification BPEL permet de décrire : Un procédé abstrait BPEL qui représente une spécification du service composite qui aidera les clients de celui-ci à comprendre la logique du procédé exposé [CKM + 05]. Il spécifie les échanges des messages entre les différents partenaires sans détailler le comportement interne de chaque participant. Cette spécification n est pas exécutable mais elle peut être utilisée pour produire des implémentations différentes réalisant la même fonctionnalité composite ; Un procédé exécutable qui spécifie l ordre d exécution des activités, identifie les partenaires impliqués dans le procédé (les services concrets) et spécifie le comportement dans le cas d erreurs ou exceptions à l exécution. La définition d une composition de services avec BPEL permet, en premier, d identifier les services participants indiqués par la balise partnerlink. Cette balise permet d indiquer le correspondant porttype de la description WSDL du service participant. En deuxième, un procédé BPEL permet de définir les types de données utilisés par le procédé, indiqués par la balise variables. Le plus important élément d un procédé BPEL est la logique de coordination des invocations des services impliqués. Pour la description de cette logique, BPEL définit un certain nombre d activités possibles (receive, reply, invoke, assign, throw, terminate, wait, empty, sequence, switch, while, pick, flow, scope, compensate). Ces activités de base peuvent être combinées pour modéliser différents types de communication entre les services partenaires 3. La définition d une composition BPEL peut inclure aussi la description du traitement des erreurs - faulthandlers. Un faulthandler définit des activités qui doivent être exécutées si le procédé se termine avec un code d erreur. La figure 3.9 présente le schéma d un procédé BPEL qui réalise une composition de 3 services (servicea, serviceb et servicec). Le procédé démarre avec l invocation synchrone du service A. Le procédé invoque ensuite en parallèle deux services - serviceb et service C. Le procédé attend le résultat de ces invocations et en fonction du résultat prend une certaine décision et retourne le résultat attendu par le client. La spécification BPEL ne demande pas l identification des services partenaires concrets (correspondant aux partenaires spécifiés par la balise partnerlink) durant la phase de conception de la composition de services. Toutefois, ces informations sont nécessaires pour pouvoir exécuter la composition de services correspondante. Pour cela, la déclaration d un procédé BPEL (le fichier.bpel) est accompagnée de la déclaration du service composite exposé (un fichier.wsdl) et aussi d un descripteur optionnel de déploiement (.xml) qui contient les informations permettant de réaliser les liaisons avec les partenaires. Les liaisons du procédé BPEL avec les partenaires impliqués peuvent être réalisées dans la phase de définition du procédé et au déploiement [KKL06]. La spécification BPEL laisse entrevoir aussi la possibilité de réaliser ces liaisons à l exécution mais pour l instant, à notre connaissance, cela n est pas encore possible. La figure 3.10 présente les principales caractéristiques des compositions de services Web réalisées avec BPEL. Les différentes combinaisons des activités de base définies par BPEL permettent la modélisation des interactions de type client/serveur ou par événement mais ne permettent pas encore la réalisation des interactions de type Publication/Sousciption. Les liaisons avec les services partenaires peuvent être statiques, donc la sélection des services concrets partenaires est faite avant l exécution (au moment de la conception ou au déploiement). Dans ce cas, le descripteur de déploiement contient en clair les adresses réseau nécessaires pour réaliser les liaisons aux services partenaires. La spécification BPEL n exclut pas la réalisation des liaisons dynamiques aux services partenaires, mais pour l instant aucun moteur d exécution, l entité qui gère l exécution du procédé BPEL, ne prend pas en compte cet aspect. 3 Les seuls types de communication qui ne peuvent pas être directement modélisés sont le broadcast et le Publish/Subscribe [WvdADH03]. 45

46 CHAPITRE 3. COMPOSITION DE SERVICES FIG. 3.9 Exemple de procédé BPEL. L exécution des procédés BPEL est réalisée par un moteur d exécution spécifique. Plusieurs moteurs d exécutions sont actuellement disponibles. Parmi eux, nous mentionnons le moteur Orchestra de Bull 4, ActiveBPEL 5, Oracle BPEL Process Manager 6, Netbeans BPEL Service Engine 7. FIG Résumé des différents aspects de BPEL. Un moteur d exécution des procédés BPEL gère d une manière centralisée l exécution de la composition de services. Son rôle est d assurer la réalisation des liaisons avec les services partenaires, de réaliser l invocation des fonctionnalités fournies par ces services, de recevoir les réponses et, en fonction de la logique du procédé, d invoquer l activité prochaine. Comme on l a vu, la définition du procédé peut être accompagnée d un descripteur de déploiement qui peut aider le moteur d exécution BPEL à identifier les partenaires impliqués dans la composition de services. Le moteur d exécution doit réaliser les liaisons avec les services partenaires spécifiés dans le descripteur de déploiement. Toutefois, la réalisation de ces liaisons peut échouer car les fournisseurs de services choisis au préalable peuvent ne plus être disponibles à l exécution. Dans ce cas, les moteurs classiques d exécution BPEL ne peuvent pas exécuter la composition de services avec succès. Plusieurs propositions provenant du monde académique ont été faites pour traiter ce problème. Parmi eux, nous mentionnons WSBinder [PEV + 06] un environnement d exécution des procédés BPEL développé dans le cadre du projet européen SecSe 8 qui est capable de réaliser des liaisons adaptatives. WSBinder résout le problème mentionné en permettant l adaptation des compositions BPEL en utilisant des préférences d adaptation qui accompagnent la définition BPEL. Ces préférences sont ensuite utilisées en conjonction avec des critères fonctionnels et non-fonctionnels pour réaliser la liaison avec le partenaire adéquat disponible au moment de l exécution de la composition de services. De la même manière, Dynamo (Dynamic Monitoring) [BG07] [BGG04] augmente les capacités adaptatives de BPEL (limitées seulement aux activités de compensation et de reprise sur panne) avec des 4 http ://orchestra.objectweb.org/xwiki/bin/view/main/webhome 5 http :// 6 http :// 7 http :// 8 http ://secse.eng.it/pls/secse/secse.home 46

47 3. LES MODÈLES DE COMPOSITION DE SERVICES EXPRIMÉE PAR PROCÉDÉS capacités auto-adaptative. Le développeur peut spécifier des règles, qui seront vérifiées à l exécution, et la manière dont le procédé BPEL doit reagir lorsqu une anomalie intervient. Environnements de développement des procédés BPEL Pour faciliter l utilisation du langage BPEL, plusieurs environnements de développement dédiés ont été proposés. La figure 3.11 présente les différents composants d un tel environnement : Un environnement de modélisation (BPEL designer dans la figure) qui permet aux développeurs de spécifier l orchestration de services ; Un moteur d exécution compatible avec un langage d orchestration ; Des outils d administration qui offrent support pour, par exemple, le débogage de l exécution des différents procédés. FIG Environnement de développement et d exécution de procédés BPEL L outil de modélisation BPEL permet la spécification d une orchestration de services. Cette spécification peut être une activité longue qui nécessite une certaine expertise technique. Pour éliminer une partie de la complexité technique impliquée, de plus en plus d environnements de développement propose l utilisation de langages graphiques pour la définition des orchestrations. La traduction de ce langage vers la syntaxe BPEL est ensuite automatisée de manière transparente pour le développeur. Les différents environnements qui existent actuellement incluent, en général, un tel outil de modélisation. Par exemple, parmi les outils mis à disposition par Oracle pour décrire des orchestrations de services on retrouve deux outils graphiques de modélisation qui sont intégrés aux plates-formes de développements OracleJ Developer et Eclipse [JMS06]. Par exemple, JDeveloper BPEL Designer permet aux utilisateurs de spécifier les activités définies par BPEL en utilisant des éléments graphiques correspondants qu ils peuvent sélectionner dans une palette d éléments (la figure 3.12 présente une copie d écran). La définition BPEL correspondante est ensuite automatiquement obtenue. De plus, cet environnement inclut aussi une autre facilité qui simplifie la réalisation des liaisons aux services, un outil pour la recherche de services dans un registre et la sélection des services qui seront utilisés comme partenaires dans l orchestration. Conclusions Le modèle de l orchestration de services permet d exprimer une composition de services comme un procédé. Un procédé spécifie l ordre et les conditions des invocations des services participant à l orchestration de services. Parmi les langages existants, nous avons choisi de présenter le langage BPEL. Le besoin d outils qui simplifient le travail des développeurs est aussi dans le cas des orchestrations de services un fait concret. Le travail des développeurs est simplifié par l utilisation de langages graphiques qui cachent la complexité techniques de la spécification d un procédé, par l automatisation de la traduction de la spécification graphique à la spécification BPEL et par l utilisation d autres outils - des aides. 3.2 La chorégraphie de services La chorégraphie de services décrit la manière dont un ensemble de services collaborent pour atteindre un but commun. Elle spécifie les interactions des services participants et les dépendances entre ces interactions, qui peuvent être des dépendances de flot de contrôle (une interaction doit être précédée par une autre), des dépendances de données (une interaction nécessite la réception d un message 47

48 CHAPITRE 3. COMPOSITION DE SERVICES FIG Exemple d outil de modélisation BPEL avant de débuter) etc. Une chorégraphie ne décrit aucune action interne d un service participant qui n a pas d effet visible à l extérieur (telles que des traitements internes ou des transformations de données, par exemple) [BDO05]. Elle se concentre sur la séquence visible des échanges de messages entre les participants et présente une vision globale externe de la manière dont les participants interagissent. Les différents acteurs impliqués dans une chorégraphie interagissent selon des règles fixées auparavant sans être contrôlés par un point central de contrôle. Le contrôle de l exécution est distribué entre les différents participants. L intérêt principal d une chorégraphie est de vérifier qu à l exécution tous les échanges de messages entre partenaires sont réalisés conformément à cette spécification. Plusieurs propositions de langages pour la chorégraphie de services existent : WS-CDL, WSCI (Web Services Collaboration Interface) [Con02] et ebxml (Electronic Business using extensible Markup Language) 9. WS-CDL (Web Services Choreography Description Language) [Con04] est un langage destiné à la modélisation de chorégraphies de services réalisée par le consortium W3C. La définition WS-CDL d une chorégraphie est divisée, comme la définition d une orchestration, en deux parties. La partie abstraite est utilisée pour identifier les rôles des services impliqués. Ces rôles sont assignés à des participants concrets lors d une étape suivante. La partie concrète d une définition WS-CDL spécifie un procédé, c est à dire un ensemble ordonné d activités. L activité principale d une chorégraphie est nommée interaction et correspond à l invocation d une opération d un service Web exposé par un des rôles. Pour spécifier la collaboration de services Web, WS-CDL utilise des mécanismes pour décrire l alignement sur un type de données spécifiques (par exemple, un acheteur et un vendeur signalent le fait qu une commande a été placée par la modification des variables qui résident des deux cotés), des interactions (un acheteur fait une demande pour obtenir le prix d un produit et reçoit la réponse du vendeur) et de la récupération de l état de la chorégraphie (une activité est démarrée). Le langage WS-CDL n a pas encore été standardisé ; il représente aujourd hui une proposition de langage pour la chorégraphie de services Web et n est pas actuellement très utilisé en pratique. Les outils crées autour du langage BPEL sont actuellement plus nombreux que ceux qui exploitent le langage WS- CDL. Parmi les outils dédies à la spécification des chorégraphies de services, nous pouvons néanmoins mentionner WSCDL-Eclipse 10 et Pi4Soa http ://ebxml.org./ 10 http ://wscdl-eclipse.sourceforge.net/main.htm 11 http :// 48

49 4. MODÈLES DE COMPOSITION STRUCTURELLE DE SERVICES 4 Modèles de composition structurelle de services La composition structurelle permet de décrire une composition de services comme un assemblage. L assemblage est réalisé au niveau des implémentations des services, appelés dans ce cas des composants, en utilisant les mécanismes spécifiques définis par le modèle à composants respectif. Un assemblage est réalisé en configurant et liant les composants qui fournissent les services nécessaires. Chaque composant impliqué spécifie clairement quels sont les services fournis mais aussi quelles sont les diverses dépendances de services qui lui sont nécessaires afin de réaliser sa logique métier. Plusieurs modèles à composants pour la composition de services ont été proposés [Yan03][MM04]. Dans cette section, nous présenterons les modèles pour la composition structurelle de services Web et respectif OSGi, les deux technologies de référence présentées dans le chapitre 2. Il s agit du modèle SCA (Service Component Architecture) pour la composition de services Web et du modèle ipojo (injected POJO) pour la composition structurelle de services OSGi. 4.1 Le modèle à composants SCA Pour faciliter le développement des services, SCA introduit un modèle de composant. La vue externe d un composant SCA est présentée dans la figure Un composant SCA réalise l implémentation d un ou plusieurs services. Cette vue permet de donner la même vision, donc de fournir le même traitement, aux composants qui implémentent et exposent des services, indépendamment de la technologie utilisée pour leur implémentation, qui peut être Java, PHP, C++ etc. La technologie utilisée pour la réalisation d une implémentation est considérée, dans SCA, comme étant un aspect purement technique, donc secondaire [BII + 05]. FIG Composant SCA Un composant SCA implémente une certaine logique métier qu il expose ensuite à travers un ou plusieurs services. Un service fournit des opérations. La description des services fournis peut être réalisée avec une technologie compatible à celle utilisée pour l implémentation du service, voir une interface Java pour un composant implémenté en utilisant du Java, ou WSDL pour un procédés BPEL. Un composant peut également utiliser d autres services pour l implémentation interne des services fournis. Ces dépendances de services sont nommées références de services. Chaque référence définit une interface contenant les opérations que le composant utilise. La réalisation des liaisons effectives aux services référencés est déléguée à l environnement d exécution qui effectuera l injection des dépendances 12. Cela élimine une partie de la complexité technique de la résolution des dépendances, le développeur n ayant plus besoin d écrire le code nécessaire. Un composant SCA est une instance d une implémentation de services qui a été configurée proprement. Une implémentation est le code écrit par un développeur pour remplir certaines fonctions, comme par exemple une classe Java ou un procédé BPEL. La configuration d un composant SCA, définie dans un fichier.scdl, spécifie la manière dont le composant interagit avec le monde extérieur [Cha07], par exemple comment les liaisons entre services seront réalisées. Chaque composant peut déclarer une ou plusieurs propriétés. Les valeurs de ces propriétés sont utilisées pour configurer un composant lors de son instanciation. 12 Dependency injection [Fow04] 49

50 CHAPITRE 3. COMPOSITION DE SERVICES La configuration d un composant permet donc de spécifier des valeurs pour les différentes propriétés qu il expose mais aussi la manière dont les liaisons entre le monde extérieur et le composant seront réalisées, par l intermédiaire des références de services [Cha07]. La configuration des références permet de spécifier clairement le moyen de réalisation de la liaison avec le service référencé. Cette information est ensuite utilisée par l implémentation pour réaliser l invocation du service nécessaire. La configuration d un composant à travers des propriétés et des références permet de réaliser avec une même implémentation plusieurs composants qui ont des configurations différentes. La vue externe d un composant SCA est donc représentée par les services fournis, les références de services et les propriétés associées. Le fait de séparer clairement la vue externe d un composant de sa manière d implémentation permet aux assembleurs (qui ne sont pas toujours des développeurs) d avoir une même vision sur les différents composants qu ils manipulent indépendamment de la technologie utilisée pour leurs implémentations. Les services fournis, les références de services et les propriétés sont donc les aspects configurables, qui constituent dans SCA le type d un composant ( voir la figure 3.14). Le type correspond à une implémentation réalisant, entre autre, la fonctionnalité des services fournis. En indiquant des valeurs concrètes pour les services, les références de services et les propriétés, un composant réalise la configuration d une implémentation, qui se traduira à l exécution par la création des instances d implémentation correspondantes. FIG Relation composant SCA - implémentation A part ce modèle de composant, SCA définit également un modèle de composition structurelle qui permet d obtenir une fonctionnalité plus complexe en utilisant les services fournis par les divers composants impliqués. L assemblage de composants SCA Les composants représentent les unités de composition du modèle défini par SCA. La composition est réalisée par des assemblages de composants SCA. Ces assemblages, appelés composites [Gro07], contiennent des composants et les liaisons qui décrivent les connections entre composants. Un composite SCA peut grouper et lier des composants hétérogènes (crées avec des technologies d implémentations différentes). Le résultat d un assemblage peut ensuite être lui-même utilisée comme composant dans une autre composition, permettant la construction hiérarchique des solutions métier. Les principaux éléments d un composite SCA sont présentés dans la figure L exemple montre l assemblage de deux composants SCA et la liaison crée entre eux. Comme l on peut voir un composite SCA est lui-même un composant SCA donc il a la même vue externe - services, références, propriétés. Les composants contient des implémentations configurées qui réalisent la logique métier du composite. Comme nous l avons précisé, chaque composant précise les services fournis et ses dépendances de services. Ayant la même vue externe, un composant composite fournit des services et exprime des dépendances de services. Les services fournis par un composite se retrouvent parmi les services fournis par un des composants de l assemblage qui sont exportés à l extérieur du composant par un mécanisme appelé promotion. Le même mécanisme est utilisé pour les références. La promotion des références rends visible à l extérieur du composite une dépendance de service d un des composants internes. Ces références représentent maintenant des dépendances de services du composite qui seront résolues par des services exposées par des composants extérieurs du composite. 50

51 4. MODÈLES DE COMPOSITION STRUCTURELLE DE SERVICES FIG Composition SCA [Gro07] Un composite SCA définit également des liaisons entre des composants internes. Ces éléments portent le nom de "wire". Un "wire" connecte une référence de service d un composant et un service fournis par un autre. Une telle liaison est permise si les opérations définies par les deux interfaces des composants sont équivalentes (les mêmes opérations, paramètres, valeurs de retour et exceptions) et cela indifféremment du langage utilisé pour la description des interfaces (Java ou WSDL par exemple). Le même traitement de promotion peut être appliqué aux propriétés des composants internes du composite. Elles deviennent ainsi des propriétés du composite qui aideront à la configuration des composants respectifs. Les composants interne d un composite peuvent être des composants simples ou composites. Un composite utilisé dans une composition SCA est pour l assemblage une boite noire, car ses composants internes ne peuvent pas être directement invoqués par la composition de services. Le composant du plus haut niveau ne peut connecter que les services et les références exposés par le composite interne, la construction interne du composite étant opaque pour lui. Un composite peut être utilisé comme une unité de déploiement. Dans ce cas, il ajoute des éléments fonctionnels, notamment des services, à un domaine. Un domaine rassemble un certain nombre de services qui peuvent s exécuter sur des machines différentes, comme le montre la figure La spécification SCA ne contraint pas la taille d un domaine. En général, un domaine SCA peut rassembler tous les services réalisant la fonctionnalité métier d une organisation. La logique métier d un domaine plus complexe peut être divisée entre plusieurs domaines SCA, chacun correspondant par exemple à un département de l organisation, par exemple. Un domaine SCA définit une frontière de visibilité, car par exemple les liaisons entre composants sont utilisées seulement à l intérieur du domaine. Les seuls points d entrée et de sortie du domaine sont les services et les références des composites qui y sont déployés et les liaisons avec le monde extérieur sont généralement réalisées par les mécanismes de liaisons des services Web. Environnements de développement pour SCA Plusieurs implémentations propriétaires ou logiciel libre ont été réalisées au dessus des spécifications SCA. Parmi les outils commerciaux nous mentionnons celui réalisé par IBM - IBM WebSphere Application Server V6.1 Feature Pack for SOA 13. Cet outil ajoute des facilités de développement, déploiement et d exécution des composants SCA. Parmi les implémentations logiciel libre, une place importante occupe le projet Eclipse SOA Tools Platform (Eclipse STP 14 ). Le but du projet est de développer un ensemble de canevas et d outils pour traiter différents aspects liées à la réalisation des solutions à services : conception, configuration, assem- 13 https ://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/soawas61/ 14 http :// et http ://wiki.eclipse.org/index.php/stp 51

52 CHAPITRE 3. COMPOSITION DE SERVICES FIG Domaines SCA blage, déploiement, monitoring de l exécution. STP utilise comme technologie de base celle définie par les spécifications SCA. STP se propose de faciliter le travail des développeurs des applications à services en fournissant les outils nécessaires pour leur faciliter la tâche. Une proposition récente (juillet 2007) consiste de fournir un éditeur graphique pour aider les développeurs de modéliser et automatiser une partie de la réalisation des composites SCA. La figure 3.17 présente une copie d écran de l outil SCA Composite Editor. FIG Copie d ecran de l outil SCA Composite Editor Par exemple, le travail de celui qui spécifie l assemblage de composants est simplifié par l utilisation d un langage graphique pour la réalisation de la composition structurelle et des différents outils "aide" pour la réalisation des liaisons entre les services fournis et les références de services des différents composants impliqués. La traduction vers les éléments XML correspondants du modèle SCA est automatisée et transparente pour l utilisateur. La figure 3.18 présente le point de vue de SCA sur les différents discriminants que nous avons présenté. La spécification ne précise rien sur les liaisons permises par SCA, mais l utilisation des couples service fourni/service requis permet de déduire l utilisation des liaisons directes entre services. L assemblage est statique à cause du fait que la sélection des services, respectif des composants implémentant ces services, est réalisée avant l exécution. Par rapport au contrôle de l exécution, SCA supporte également l exécution centralisée à l intérieur d un domaine, et l exécution distribuée à l extérieur du domaine. 52

53 4. MODÈLES DE COMPOSITION STRUCTURELLE DE SERVICES FIG Résumé des différents aspects de SCA. 4.2 Le modèle de composants à services ipojo ipojo (injected Plain Old Java Object) 15 est un modèle de composant à services développé au dessus d OSGI dont le but est de simplifier le développement des compositions structurelles de services [EHL07][EH07]. La vue externe d un composant ipojo est présentée dans la figure Comme l on peut observer, il expose des fonctionnalités à travers des services et exprime des dépendances vers d autres services. Ces dépendances sont exprimées comme des services abstraits, fait qui permet de retarder la réalisation des liaisons jusqu à l exécution. En effet, la réalisation des liaisons dynamiques de services représente un des points forts du modèle ipojo. FIG Les élements d un composant ipojo La réalisation des liaisons dynamiques est déléguée au containeur du composant ipojo. De plus, l utilisation d un containeur permet de simplifier le travail des développeurs des composants ipojo, car celui-ci gère des aspects techniques spécifiques aux approches à services (publication de services, découverte et sélection de services). Ainsi, le développeur d un composant ipojo doit seulement implémenter la logique métier de la fonctionnalité publiée par le composant et configurer le containeur de son composant. Les tâches qui sont déléguées au containeur sont multiples. En effet il prend en charge tous les aspects non-fonctionnels. Un containeur est donc composé de plusieurs handlers, chacun d entre eux prenant en charge un aspect non-fonctionnel. Par exemple, les handlers disponibles actuellement sont : Service Requirement qui gère la résolution des dépendances de services, Provided Service qui gère les aspects concernant la publication des services fournis, Lifecycle Callback prenant en charge le cycle de vie des instances de composant, Configuration Handler pour réaliser la configuration des composants, Event Handler pour la gestion de la communication par évènements. De plus, ipojo est un modèle extensible, donc d autres handlers peuvent être associés à un composant ipojo. Pour gérer automatiquement ces aspects, un container utilise l information de configuration exprimée par le développeur sous la forme d une description de composant. Cette descrip-tion identifie le service fourni par le composant, les dépendances de services du composant, les handlers utilisés. A l exécution, le containeur délègue à chaque handler la résolution des différents aspects. Par exemple, Service Requirement utilise les services abstraits spécifiés comme étant des dépendances de services pour sélectionner une implémentation correspondante et réaliser les liaisons avec ces services. Si toutes les dépendances de services obligatoires sont résolues, le handler Service Provided peut publier dans le registre de services de la plate-forme OSGI la fonctionnalité fournie par le composant. Un composant composite ipojo fournissant un service et utilisant d autres services fournis par d autres composants réalise en fait une composition structurelle. La description du composant ipojo représente un ADL (Architecture Description Language) [MT00] pour la spécification des compositions de services qui permet d identifier quels sont les services abstraits participants. La réalisation des liaisons entre services est ensuite déléguée au containeur du composant composite qui les effectue à l exécution. Ces liaisons sont donc dynamiques. La figure 3.20 présente un exemple de composition structurelle de trois ser- 15 http ://cwiki.apache.org/confluence/display/felix/ipojo 53

54 CHAPITRE 3. COMPOSITION DE SERVICES vices abstraits [EHL07]. Similaire au modèle SCA (avec qui ipojo a des nombreux points en commun), le résultat de la composition de services peut être publié comme un service. Une autre ressemblance avec SCA est la possibilité de créer des compositions hiérarchiques en utilisant des services composites fournis à travers d autres compositions structurelles. Un composite introduit une limite de visibilité avec l extérieur et rend opaque tout ce qu il contient. Le seul élément visible est représenté par le service qu il fournit. En utilisant ce système de visibilité, ipojo élimine un certain niveau de complexité qui peut apparaitre lors d une composition hiérarchique. FIG Composition structurelle de services avec ipojo De l exemple présenté, nous pouvons observer que la composition structurelle n est pas exprimée au niveau des composants mais en termes de services abstraits. Cela présente un avantage car dans le cas d ipojo la composition se concrétisera à l exécution. Ainsi, le résultat de la composition n est pas un ensemble de composants travaillant en collaboration mais un ensemble de services qui travaillent en collaboration. L ADL d ipojo ne permet pas l identification des types d interactions entre les services participants. Cette information est déduite en utilisant la description des services participants, appelée par ipojo spécification de services. L utilisation de handlers spécifiques rend théoriquement possibles les interactions par événements ou de type Publish/Subscribe. En réalité, actuellement seulement le handler pour la communication par événements est disponible. Le modèle ipojo ajoute au-dessus de la plate-forme d exécution d OSGi son propre runtime, qui assure le fonctionnement des composants ipojo. L exécution des composants ipojo est donc contrôlée par une entité centrale, le containeur du composant. FIG Résumé des différents aspects de la composition avec ipojo ipojo est dans un processus continu d évolution, donc aujourd hui plusieurs points ouverts ont été identifiés afin d être investigués. Parmi ces points, nous pouvons mentionner le besoin d une spécification de services qui fournit plus d informations que la description de services actuellement utilisée par OSGi (nom d interface du service et un ensemble de propriétés). Une autre perspective est de fournir un environnement de développement pour la réalisation des composants ipojo. Les auteurs proposent un outil minimal de développement sous la forme d un plugin Eclipse (disponible à http ://cwiki.apache.org/confluence/display/felix/ipojo+eclipse+plug-in). Cet outil est destiné aux développeurs connaissant le modèle ipojo. Il facilite le travail des développeurs en automatisant des tâches telle que la création automatique du fichier contenant la description d un composant et la création du bundle contenant le composite. 5 D autres modèles de composition de services Actuellement, l orchestration de services et la composition structurelle sont les plus utilisées modèles pour la composition de services Web. D autres modèles de composition existent pourtant mais ils sont actuellement peu répandus. Il s agit de la de la composition sémantique de services et des approches permettant la composition par mécanismes de type Publication/Souscription. Dans cette section, nous présenterons succinctement ces approches. 54

55 5. D AUTRES MODÈLES DE COMPOSITION DE SERVICES 5.1 Composition de services avec interaction Publication/Souscription Une autre possibilité de réalisation des compositions de services Web est celle par l intermède d un patron d interaction asynchrone de type Publication/Souscription. La spécification d OASIS récemment apparue, appelée Web Services Notification[OAS06b] [Pap04], et la spécification Wire Admin d OSGi, récemment améliorée par le modèle WADL, sont les modèles que nous présentons succinctement dans cette section. Une approche pour les services Web - WS Notification La spécification Web Services Notification est dédiée aux services Web qui interagissent selon le patron de communication Publish/Subscribe. Les principales entités sont présentes dans la figure Le patron d interaction Publish/Subscribe utilise des notifications (Notifications) pour réaliser le découplage entre des producteurs de données (Publisher) et des consommateurs de données (Notification Consumer). Lorsqu un producteur enregistre une situation particulière (Situation), qui peut être par exemple la production d une donnée ou un changement de valeur d une donnée, il publie une notification. Cette notification est publiée vers une entité spéciale, appelée Notification Producer. En même temps, les consommateurs de données utilisent une entité appelée Subscriber pour enregistrer auprès du Notification Producer leur intérêt particulier de recevoir des notifications d un certain type. Le rôle du Notification Producer est de gérer la liste des abonnements (Subscription) des consommateurs et de transférer ces notifications auprès des consommateurs abonnés. FIG Interaction "Publish/Subscribe" des services Web. L utilisation de WS-Notification comme protocole de communication entre les services Web permet de réaliser un fort découplage entre les services Web représentés comme producteurs, respectivement consommateurs. De plus, les liaisons un à un (1..1) crées avec les interactions classiques de type requête/ réponse peuvent être remplacées, en utilisant ce type d interaction, par des liaisons un à plusieurs (1..n) ou plusieurs à un (n..1). Une utilisation signifiante des capacités de ce patron spécifique est réalisée par les ESB, qui combine les interactions Requête/Réponse et les interactions Publish/Subscribe [NG05] dans une seule infrastructure. Le résultat est un environnement qui permet l exécution de différents types d applications, qui peuvent combiner les deux types d interactions. Cette composition de services est caractérisée par un fort découplage entre les services impliqués entre lesquels n existe aucune dépendance. La communication asynchrone entre ces services est rendu possible par une entité centrale, qui gère la réception des messages et les dirige vers les services intéressé. Ce type de communication est adressé par la spécification OSGI dans la spécification du service Wire Admin qui représente l entité centrale que nous avons mentionné. Le modèle Wire Admin Wire Admin gère les interactions de type Publish/Subscribe entre services OSGi (voir la figure 3.23). Dans ce type d interaction deux rôles ont été distingués : le producteur et le consommateur. Le producteur est un service OSGi qui génère des données. La description du service producteur contient l annonce des types de données (wireadmin.producer.flavors) produites. De la même manière, le rôle 55

56 CHAPITRE 3. COMPOSITION DE SERVICES d un consommateur est assuré par un service qui annonce son intérêt vers des types spécifiques de données (wireadmin.consumer.flavors). Un service peut jouer les deux rôles, producteur et consommateur de données. FIG Les éléments d une interaction Publication/Souscription Wire Admin connecte un producteur à un consommateur à travers un objet appelé Wire. Dès que les services producteurs et consommateurs sont enregistrées dans le registres de services de la plateforme OSGi, la communication entre eux est possible. Cette communication peut être réalisée à double sens, c est-à-dire le producteur peut envoyer à travers le Wire des nouvelles données (mode push) et le consommateur peut lui aussi demander des nouvelles données (mode pull). Plusieurs limitations du service Wire Admin ont été identifiées : La liaison (un Wire) crée entre un producteur et un consommateur est statique à cause de l utilisation des identificateurs (pid) des services comme informations d identification ; La notion d architecture de la composition de services n existe pas, car elle est cachée dans le code écrit par un développeur pour la création des liaisons entre services. Pour résoudre ces limitations, [CDT08] propose un ADL 16 pour la spécification des compositions de services qui interagissent par des mécanismes de Publication/Souscription et un moteur qui interprète cet ADL et permet la création des liaisons dynamiques entre les producteurs et les consommateurs de données. Ces deux propositions font l objet de la section suivante. Le modèle WADL WADL (Wired Application Description Language) permet la description de l architecture des compositions de services OSGi conçues par interactions de type Publication/Souscription. Il permet la spécification des liaisons entre producteurs et consommateurs de données. Ces liaisons sont dynamiques, donc elles seront crées à l exécution. De plus, par rapport à la spécification Wire Admin, WADL permet la création des liaisons flexibles car il ne restreint pas l identification des services impliqués à leurs identificateurs. Pour cela, il utilise un système de filtres pour l identification des services. Ainsi, WADL permet, par exemple, la création des liaisons entre services en fonction d un certain type de données produites et/ou consommées. L exemple présenté contient deux liaisons pour lesquelles seulement l identité du consommateur compte. Listing 3.1 Exemple de spécification WADL <?xml v e r s i o n="1.0" encoding="utf -8"?> <wireapp i d=" building. FireCentral" d e s c r i p t i o n="a Fire central wired application" a c y c l i c="true"> <! a many to one w i r e s e t without wire p r o p e r t i e s > <! connects temperature s e n s o r s to the f i r e c e n t r a l > <! + keepalive remove p o l i c y > <w i r e s e t i d=" temperature2central" d e s c r i p t i o n="temperatures consumed by the fire central" producers f i l t e r="(&( ( wireadmin.producer.flavors= * org. osgi. util. measurement. Measurement) ( wireadmin. producer. flavors =* javax. measure. Measure)) (unit=si.k))" 16 Architecture Description Language 56

57 5. D AUTRES MODÈLES DE COMPOSITION DE SERVICES /> c o n s u m e r s f i l t e r="(service.pid=building.firecentral.temperature)" mandatory=" false" removepolicy=" KEEP_ALIVE" <! c u r r e n t rooms smoke l e v e l to the f i r e c e n t r a l > <! + whileconsumer remove p o l i c y > <w i r e s e t i d=" smoke2central" d e s c r i p t i o n=" smoke level producers consumed by the fire central" producers f i l t e r="( wireadmin. producer. flavors =* com. acme. data. SmokeLevel)" consumers f i l t e r="( service. pid=building. firecentral. smoke)" removepolicy=" WHILE_CONSUMER" mandatory=" true" > <property name=" wireadmin. filter" value="( wirevalue. elapsed >=2000)" type=" java. lang. String" /> </wireset> </wireapp> A l aide de quelques stratégies, WADL permet également de contrôler le cycle de vie des liaisons entre services participants. Par exemple, la disponibilité dynamique des services peut invalider une liaison, cas dans lequel plusieurs stratégies peuvent être envisagées : persistance de la liaison (KEEP_ALIVE), persistance de la liaison tant que le producteur, respectivement le consommateur restent valides (WHILE_- PRODUCER, WHILE_CONSUMER) ou destruction de la liaison (IF_DISCONNECTED). La spécification WADL d une application est ensuite interprétée par un moteur spécifique appelé WireAdminBinder. Ce moteur reçoit cette spécification et produit ensuite les liaisons nécessaires pour que les services impliqués puissent communiquer. FIG Résumé des différents aspects de WADL L utilisation de WADL pour la description des applications à services qui interagissent par des mécanismes Publish/Subscribe élimine les limites de la spécification OSGi Wire Admin (la figure 3.24 présente le sommaire des différents capacités de WADL). WADL permet donc à l exécution la création des liaisons entre services producteurs et consommateurs de données et offre un aperçu de l architecture de la composition de services ainsi crée. 5.2 Composition sémantique La composition de services est le procédé de sélection, combinaison et exécution de services Web afin de remplir un certain objectif. "Achète-moi un Apple iphone au meilleur prix" est un exemple d objectif. A travers Internet, des utilisateurs humains exécutent manuellement une composition de services pour remplir ce but en utilisant des services offerts par des sites Internet en conjonction avec les connaissances qu ils ont acquis en utilisant ces pages Internet (par exemple, le fait que utilise un service de paiement sécurisé qui débitera la carte de crédit et un service de courrier suivi pour l expédition du colis). Pour automatiser cette composition, les connaissances implicites des utilisateurs doivent être utilisés et décrites d une manière interprétable par un ordinateur ou programme. Le Web sémantique propose d ajouter plus d information à la description des services Web afin d automatiser plusieurs tâches comme la découverte de services, la négociation, la composition et l invocation de services [KRMF06]. La description WSDL d un service Web permet de décrire la fonctionnalité remplie par le service. Elle spécifie d un point de vue syntaxique les opérations du service, les types de données d entrée et 57

58 CHAPITRE 3. COMPOSITION DE SERVICES de sortie, les différents points d entrées du service et le moyen de réaliser la liaison avec le service. Le Web sémantique ajoute à cette description syntaxique la description sémantique des capacités du service. En général, le modèle sémantique d un service est réalisé en ajoutant un autre niveau à la pile de protocoles standard des services Web qui permet d exprimer la sémantique des aspects fonctionnels, nonfonctionnels et comportementaux d un service. Les liaisons entre les données sémantiques d un service et sa syntaxe sont réalisées par une transformation qui porte le nom de "grounding" [KRMF06]. Actuellement, plusieurs propositions de descriptions sémantiques ont été proposées : Web Service Modeling Ontology (WSMO) [dbbd + 05], OWL-S [Ma04] and WSDLS [POSV04]. Les éléments principaux du Web sémantique sont les ontologies. Une ontologie permet de standardiser le modèle d information d un métier. Elle définit et classifie la terminologie d un domaine. Cela permet de réaliser la liaison entre les concepts concrets, familiers aux différents acteurs humains d un domaine, et leurs correspondants abstraits du système d information du domaine [FB02]. La terminologie définie par une ontologie est ensuite utilisée pour la représentation des ressources ou de l information que les services du domaine manipulent [VMK + 07]. L approche sémantique permet de décrire de façon abstraite une application en termes des buts (Goals) à atteindre. Cette description est bien sûr réalisée à travers des données sémantiques. Une application modélisée avec WSMO spécifie les objectifs que l utilisateur veut remplir. L expression des objectifs est composée de critères fonctionnels (Capability) ou comportementaux (Interface). Cette spécification est ensuite utilisée pour sélectionner parmi les services Web disponibles dans des registres de services ceux qui correspondent mieux aux critères énoncés. Le résultat de cette phase de découverte et sélection peut être un service Web élémentaire ou composite. La réalisation de cette étape et l invocation des différents services ainsi sélectionnés peuvent être totalement transparents pour l utilisateur. Le Web sémantique propose une nouvelle approche pour la réalisation des solutions à services en utilisant un modèle plus riche d informations - les ontologies. Toutefois, pour l instant, la réalisation des objectifs de l adaptation sémantique n est pas encore tout à fait acquise, le Web sémantique restant un point ouvert dans le domaine de la recherche. 6 Synthèse Ce chapitre a présenté un aspect complexe des approches à services - la composition de services - auquel nous nous intéressons dans ces travaux. La composition de services permet l intégration et la réutilisation des services dans diverses applications. Avant de présenter les principaux types de composition de services, nous avons identifié deux discriminants importants qui nous ont aidés à distinguer plusieurs types de composition de services. Ils nous ont donc permis d identifier deux approches pour la composition de services : la composition par procédés et la composition structurelle. Nous mentionnons une nouvelle fois le fait que ces discriminants n ont pas été utilisés pour faire une distinction qualitative entre les modalités de réalisation des compositions de services. Nous ne considérons donc pas une des deux approches identifiées meilleure qu une autre. Le choix de privilégier une approche par rapport à l autre est influencé par le contexte du métier pour lequel la composition de services est réalisée. L utilisation des compositions réalisées par procédés est, par exemple, plus adéquate pour les applications s exécutant à travers Internet où le développeur de la composition de services ne détient aucun contrôle sur le cycle de vie du service qu il réutilise. La composition structurelle est adéquate pour la construction des applications dans des domaines assez fermés, où le contrôle sur le cycle de vie des services leur appartient. Nous avons ensuite présenté quelques modèles de composition de services caractéristiques aux deux approches identifiées. Ces modèles appartient aux deux technologies de référence que nous avons présenté dans le chapitre 2. La figure 3.25 présente un résumé des capacités des modèles présentés. Cette présentation nous a permis d illustrer la complexité à laquelle les développeurs des compositions de services sont confrontés. Aujourd hui, ceux-ci disposent, comme nous l avons montré, de nombreux langages pour réaliser la spécification des compositions de services. Le choix d un langage spécifique est, en lui-même, un choix difficile, car le développeur doit connaitre les détails techniques des langages et leurs capacités avant de déterminer lequel utiliser. Ces langages sont souvent difficiles, donc le développeur doit suivre au préalable un processus d apprentissage, coûteux souvent en temps. Une fois le choix d une technologie de composition de services fait, le développeur est confronté à deux niveaux de difficulté, qu il doit gérer simultanément. Le premier est celui de la logique métier de la composition de services et le second est celui des différents aspects techniques de la technologie choisie. Nous concluons donc ce chapitre en soulignant une nouvelle fois le besoin d outils pour la composi- 58

59 6. SYNTHÈSE FIG Synthèse des approches pour la composition de services tion de services. Le but de ces outils est de simplifier le travail des développeurs en prenant en charge au moins le deuxième niveau de difficulté mentionné. Nous considérons que, de point de vue d un développeur, le choix d une technologie pour la composition de services doit être transparent. En traitant automatiquement les différents aspects techniques, les développeurs pourront se concentrer sur la logique métier de l application qu ils doivent concevoir et les temps de développement seront diminués. Cela profitera aux développeurs mais aussi au domaine du génie logiciel, qui, une fois ces outils de développement disponibles verra une plus large utilisation des approches à services. Des outils qui essaient de faciliter le développement des compositions de services, respectivement des services existent actuellement. Malheureusement, ils sont souvent dédiés à un technologie à services particulière qui est celle des services Web. De plus, leurs utilisateurs doivent être des développeurs ayant une expertise dans cette technologie. L utilisation de ces environnements demande un temps d apprentissage assez important. De plus, tout nouveau projet démarre de zéro sans réutiliser l expertise acquise lors des projets passés par des développeurs Nous considérons que, pour faciliter l utilisation des approches à services, des outils de développement des compositions de services plus avancés sont nécessaires. Parmi les besoins que ces outils doivent remplir, nous mentionnons : Rendre transparente l utilisation d une technologie particulière à services, c est à dire prendre automatiquement en charge les aspects techniques de la réalisation d une composition de services, comme la recherche, la sélection des services qui seront utilisés, la création de la spécification de la composition des services dans le langage correspondant ; Les développeurs doivent pouvoir réaliser d une façon simple et rapide des compositions de services en se concentrant sur la logique métier de celle-ci ; L utilisation de l environnement de développement doit être facile et ne doit pas nécessiter des temps d apprentissage importants. 59

60

61 4 Les approches génératives 1 Introduction Le génie logiciel doit actuellement répondre à des demandes importantes comme l augmentation de la productivité et la diminution des temps de développement. Les approches génératives sont apparues pour répondre à ces besoins. Elles fournissent les outils visant l automatisation du développement des logiciels. Les approches génératives se basent sur l expertise métier et/ou technique des experts du domaine pour fournir des outils de développement spécifiques au domaines métier. Comme le montre la figure 4.1, les approches génératives fournissent, en premier, un ensemble d artéfacts réutilisables. Cette base d artéfacts réutilisables, construite à partir de l expertise dans le domaine, peut contenir des modèles, des spécifications, des documents et des composants logiciels. Ils seront réutilisés dans la construction des nouvelles applications pour le contexte considéré. FIG. 4.1 Les principes d une approche générative Le développement d applications pour un contexte donné avec l aide d environnements de développement génériques, comme Eclipse, est un processus de longue durée. Chaque projet concernant le développement d une nouvelle application pour un domaine repart de "zéro". Les développeurs doivent prendre en charge tous les aspects du cycle de développement de l application. Souvent, un développeur refait les mêmes erreurs qu un de ces collègues précédemment impliqué dans un projet dans le même contexte et, ainsi, des leçons qui devraient faire partie de l expertise dans le domaine sont réapprises. Les approches génératives proposent de changer ce style de développement en privilégiant des environnements de développement dédiés. Ces environnements dédiés capitalisent l expertise du domaine et fournissent un ensemble de facilités de développement. Ils contiennent, en général, des éditeurs d applications, qui permettent de décrire 61

62 CHAPITRE 4. LES APPROCHES GÉNÉRATIVES une application en utilisant des abstractions spécifiques au domaine, et des générateurs de code qui automatisent une partie ou la totalité du développement d application. Selon le degré d automatisation, le développement des applications peut être réalisé par : Assemblage (manuel) des composants réutilisables - le développeur réutilise pour réaliser son application les composants logiciels fournis, mais il doit les assembler manuellement selon la documentation fournie ; Assemblage assisté des composants - le développement des applications est assisté par l infrastructure de réutilisation ; Assemblage automatisé - le développement des applications est entièrement automatisé. L utilisateur réalise une spécification de l application qui doit être développée et l infrastructure prend totalement en charge la génération de l application. Cependant la réalisation d une approche générative, qui suppose le développement des artéfacts réutilisables et de l environnement dédié de développement, a un coût de développement en aval significatif. La mise en place de la base d artéfacts réutilisables et le développement des environnements dédiés représentent un investissement qui peut représenter un frein important pour une entreprise. Ce type d investissement dans une telle solution de réutilisation devient avantageux (rentable) après un certain nombre d utilisations des outils fournis pour la construction d applications dans un domaine précis. C est pour cela que les approches génératives connaissent un vrai succès pour le développement de familles de produits, caractérisées par un grand nombre de produits partageant des problèmes et des solutions. Le seuil de rentabilité des approches génératives, c est-à-dire le nombre optimal d applications construites pour que le cout de développement de l approche soit amorti, ne peut pas être évalué, pour l instant, de façon générale. Cependant, il peut être influencé par d autres considérations. Pour cela, l étape de construction de l approche est très importante et son cout assumé, car elle permet de décider si l approche générative peut être envisagée. Quand l objectif consiste de la construction automatique d une seule application pour un domaine, ou quand les temps de développement sont très courts, il est donc conseillé de ne pas investir dans le développement des artéfacts réutilisables et des environnements dédiés. Toutefois, les approches génératives sont très intéressantes pour un domaine complexe dans lequel une entreprise veut être active à long terme et lorsque le temps de développement est un facteur important. Plusieurs approches génératives existent aujourd hui. Parmi celles-ci nous présentons l ingénierie des domaines et quelques applications de cette approche : les lignes de produits et les langages spécifiques aux domaines. Nous présentons ensuite une autre approche, plus générale, l ingénierie dirigée par les modèles (l IDM) qui peut être utilisée pour la réalisation des approches génératives. 2 L ingénierie des domaines L ingénierie des domaines consiste à identifier, capturer et structurer l expérience acquise dans le développement des solutions dans un domaine métier particulier et de fournir les moyens pour la réutilisation de ces informations lors des futurs développements [CE00]. L objectif principal est d utiliser ces informations pour faciliter le développement des nouveaux systèmes dans le même contexte. Ces informations structurées caractérisent le domaine en question. La structure qui rassemble ces informations porte le nom de modèle du domaine. Dans le cadre de l ingénierie des domaines, le concept de domaine définit un cadre de réutilisation. 2.1 Domaine. Définitions. Plusieurs définitions et interprétations existent pour le concept de domaine [Har02] : Un champ d expertise dans un métier ; Une collection de problèmes - le domaine du problème ; Une collection de solutions - le domaine de la solution ; Un champ de connaissances avec une terminologie commune. La cause de ces différentes interprétations est le point de vue selon lequel la notion de domaine est considérée : Un domaine modélise conceptuellement le monde réel (d un métier) avec ses phénomènes, ses processus et ses problèmes ; 62

63 2. L INGÉNIERIE DES DOMAINES Un domaine modélise un ensemble ou une famille de systèmes qui partagent des problèmes et des solutions [Veg05]. Le premier point de vue est caractéristique aux approches conventionnelles de développement qui visent le développement d un système pour un contexte donné 1. Le modèle du domaine est réutilisable, car ses concepts sont souvent stables par rapport aux évolutions des besoins des applications. La deuxième vision élargit le spectre ciblé vers le développement des systèmes en prenant en considération des utilisateurs et des contextes d utilisation différents. Cette vision est centrée sur la notion de famille de systèmes 2. Du point de vue de la réutilisation, le domaine caractérise un ensemble de systèmes avec un nombre suffisant de problèmes communs, et vraisemblablement une solution commune. Ces systèmes appartiennent à la même famille définie par le modèle du domaine. Le développement n est plus centré sur une seule application mais vers un ensemble d applications. L ingénierie des domaines consiste, dans ce cas, de la production d une infrastructure de réutilisation qui permet l automatisation du développement des systèmes appartenant à cette famille. L utilisation de cette interprétation du concept de domaine est très importante dans le cadre de l ingénierie des domaines. Ainsi, en plus des informations sur le monde réel, le domaine contient aussi la collection de solutions, donc le savoir-faire du développement des systèmes dans ce contexte. Dans ce cas, l ingénierie des domaines permettra la mise en place d un outillage pour l automatisation du développement de plusieurs applications. La section suivante présente l approche de développement proposée par l ingénierie des domaines. 2.2 L approche L ingénierie des domaines a pour objectif de fournir une infrastructure pour le développement des applications dans un domaine particulier. Cette infrastructure doit remplacer les environnements génériques de développement par des environnements spécialisés qui guident et facilitent le travail des développeurs. Le processus de développement standard est légèrement modifié afin d inclure aussi l étape de réalisation des environnements de développement spécialisés. Cette nouvelle étape, ajoutée en amont du processus standard comme un processus différent, porte le nom de l ingénierie du domaine. Le résultat consiste en une approche de développement divisée en : l ingénierie des domaines 3 - qui a pour but de développer l infrastructure de réutilisation, c est-àdire les artéfacts réutilisables qui seront utilisés pour la construction des applications. Cette phase réalise le développement de la base d artéfacts réutilisables et l environnement de développement dédiés. On parle dans ce cas de développement pour la réutilisation [Har02] ; l ingénierie des applications 4 - qui correspond au processus standard de développement d une application. Dans ce cadre, les environnements de développement génériques ont été remplacés par l environnement dédié produit dans l étape précédente. On parle dans ce cas de développement avec réutilisation [McG04]. L ajout de l ingénierie des domaines en amont de l ingénierie des applications permet le développement d outils réutilisables pour la construction d un type particulier d applications. L élément principal utilisé lors de ce processus est le domaine, l expertise acquise lors des expériences passées dans le même contexte. Le but de ce processus est de fournir un ensemble d outils dédiés pour la construction des applications appartenant au domaine considéré. Ces outils peuvent être par exemple des éditeurs graphiques pour la spécification des applications, des générateurs de code pour l automatisation du développement des applications et des composants logiciels implémentant des fonctionnalités importantes pour le domaine. L utilisation de la connaissance sur le domaine pour produire ces outils de développement dédies aux applications du domaine permettra à la fois de raccourcir le temps de développement des applications, de diminuer aussi les coûts de développement et de garantir une meilleure qualité du logiciel. Différentes structurations de ces deux processus de développement ont été proposées avec différentes phases à effectuer et différents éléments d entrée et de sortie. Cependant, elles sont suffisamment proches pour pouvoir s accorder sur le schéma présenté dans la figure 4.2 qui identifie les principales phases de développement de chaque processus et leurs échanges. Comme l on peut voir, l ingénierie des applications reste relativement standard. La nouveauté repose sur trois étapes de l ingénierie du domaine nécessaires 1 Single system development 2 Product family. 3 Domain engineering. 4 Application engineering. 63

64 CHAPITRE 4. LES APPROCHES GÉNÉRATIVES FIG. 4.2 Le processus de développement. pour réaliser les artéfacts réutilisables qui sont délivrés pour être utilisés dans le cadre de l ingénierie des applications. L ingénierie du domaine L ingénierie du domaine est donc le processus qui : permet de collecter, organiser et utiliser l expérience acquise dans le développement d applications pour un domaine particulier sous la forme d artéfacts réutilisables ; fournit les moyens pour réutiliser ces artéfacts lors de futurs développements. L ingénierie du domaine est réalisée en trois étapes principales : l analyse du domaine, la conception du domaine et l implémentation du domaine. L analyse du domaine Cette étape permet de structurer l information disponible sur le domaine dans un modèle de domaine [PD90]. L information utilisée comme entrée peut provenir des systèmes disponibles dans le domaine (des développements passés), de l analyse des besoins pour ces systèmes ou pour des futurs développements identifiés, du savoir-faire des experts du domaine ou des experts techniques. Le résultat est un modèle du domaine qui permet d expliciter les propriétés des différentes applications du domaine, la sémantique des concepts, leurs propriétés et leurs relations. Cette phase d analyse permet donc d obtenir : La définition du domaine - qui identifie la portée du domaine, les fonctionnalités (applications) qui appartiennent au domaine et ceux qui ne lui appartiennent pas, la portée de la réutilisation des composants du domaine ; Le vocabulaire du domaine - qui définit les concepts caractéristiques et leur relations ; L identification de la variabilité dans le domaine, des différents points qui peuvent configurer un système lors de son utilisation dans divers contextes. Ces points de configuration d un système sont appelés features. La couleur de la carrosserie ou le type de combustible sont par exemple les features du domaine véhicule. Cela suppose l identification des caractéristiques partagées par toutes ou une majorité des applications du domaine et de ceux qui permettent de distinguer et de caractériser, à part, chaque application. Les formalismes et les notations utilisés pour la modélisation du domaine différent selon la démarche concrète utilisée. Par exemple, pour les lignes des produits (que nous présenterons dans la section 2.3), un formalisme qui est utilisé est le diagramme de features. Cette étape a une réelle importance qui n est pas toujours perceptible à première vue. Dans le processus de développement traditionnel, la portée du domaine coïncide avec celle du système développé. Dans l ingénierie des domaines, l étape d analyse est complexe et importante, car souvent le contexte du domaine est très flou. L analyse du domaine est un processus progressifs d apprentissage et acquisition d expérience qui permet au fur et à mesure de clarifier les concepts du domaine jusqu à ce qu ils deviennent suffisamment concrets pour pouvoir être traduits en artéfacts réutilisables. La conception du domaine Le but de cette étape et de concevoir l architecture du domaine et de produire les spécifications pour l étape suivante, celle de l implémentation du domaine. L architecture d un système comporte la description des éléments constituants, la spécification des interactions entre ces éléments, des patrons de composition pour ces éléments et des contraintes de 64

65 2. L INGÉNIERIE DES DOMAINES composition [SG96]. Dans le cas de l ingénierie des domaines, l architecture du domaine décrit les composants réutilisables identifiés au préalable, leurs dépendances, des cas d utilisation etc. Lors de cette étape on spécifie aussi le plan de production des applications, c est-à-dire la manière dont les composants fonctionnels réutilisables du domaine vont être assemblés pour réaliser une application. La conception du domaine comporte aussi la spécification de l environnement dédié de développement qui sera utilisé par l ingénierie des applications pour développer une application du domaine. Un composant important de l environnement de développement est l éditeur d applications. Lorsqu on spécifie cet outil, une attention particulière doit être accordée aux concepts manipulés par le développeur. C est pour cela, que dans certains cas, la phase de conception du domaine contient aussi la définition du langage manipulé par les développeurs et, en conséquence, par les outils dédiés au développement des applications. Ce langage porte le nom de langage spécifique au domaine (plus de détails dans la section 4.1). L implémentation du domaine Cette étape réalise l implémentation du framework d accueil des composants fonctionnels réutilisables et des outils fournis aux développeurs en respectant les spécifications du plan de production. L ingénierie des applications L ingénierie des applications reste un processus standard de développement avec trois phases : analyse, spécification et implémentation. Cependant, l ingénierie des domaines lui impose l utilisation des outils dédiés qui ont été produits. Par exemple, elle peut imposer l utilisation d une architecture ou d un canevas spécialement conçu pour le domaine considéré. La phase d analyse permet l identification des besoins qui doivent être remplis par une application. Elle permet, parfois, l identification de nouveaux besoins qui n ont pas encore été détectés par l ingénierie des systèmes. Dans ce cas, l ingénierie des applications doit les prendre en compte. Elles doivent aussi être signalées au processus de l ingénierie des domaines pour étendre la base de composants réutilisables, par exemple. Finalement, après la réalisation de la spécification de l application, celle-ci peut être obtenue par assemblage manuel, assisté ou automatique, selon le plan de production défini par l ingénierie du domaine et implémenté par le générateur inclus dans l environnement de développement dédié. 2.3 Application - Lignes de produits Nous avons présenté les principes généraux des démarches de développement basées sur l ingénierie des domaines. La démarche nommée Lignes de Produits 5 est une application réussie de ces principes dans le développement industriel de logiciels. L idée des lignes de produits n est pas nouvelle. Elle a été utilisée avec succès depuis un certain nombre d années dans l industrie pour l automatisation de la production. L industrie automobile est un bon exemple de cas d utilisation. Appliquée au génie logiciel, l approche de ligne de produits permet le développement d une infrastructure pour l automatisation des systèmes appartenant à la même famille de produits. Une famille de produits, appelée également ligne de produits, est composée d un ensemble de systèmes logiciels, avec des points communs et des différences, qui répondent à un problème particulier dans un domaine particulier, d un certain nombre de composants fonctionnels réutilisables et des règles de réutilisation de ces composants. Dans une famille de produits, les applications sont construites par la réutilisation systématique d un ensemble de composants réutilisables [CN01]. Comme le montre la figure 4.3, une ligne de produits correspond à un ensemble d applications qui répondent à des besoins spécifiques dans un domaine particulier, qui partagent une architecture et qui sont construits par la réutilisation systématique d un ensemble de composants réutilisables. Ces composants réutilisables peuvent être les besoins du domaine, les modèles du domaine, l architecture, des composants logiciels. Comme nous l avons dit, les lignes de produits représentent une application industrielle des principes de l ingénierie de domaines. Les étapes de l ingénierie des domaines sont appelées également analyse (de la ligne de produit), conception (de ligne de produits) et implémentation. L étape d analyse permet donc d identifier la portée du domaine de la ligne de produits, les applications qui appartient à la famille de 5 Product Line. 65

66 CHAPITRE 4. LES APPROCHES GÉNÉRATIVES FIG. 4.3 Ligne de produits. produits, le vocabulaire du domaine. Un aspect important est l identification des différentes propriétés de configuration des différentes applications, appelées features. Les features peuvent être aussi définies comme des caractéristiques d un système visibles pour un utilisateur final. Dans le cas concret des lignes de produits, ces points de configuration sont modélisés par des diagrammes de features. La figure 4.4 présente un exemple de diagramme de features qui modélise quelques caractéristiques d une voiture. Une diagramme de features est, en général, une structure hiérarchique. La racine représente le concept qu elle décrit et les noeuds représentent des features. Sur le diagramme, on peut spécifier aussi des règles d inclusions des différentes features. Dans l exemple présenté, la transmission, la puissance et le combustibles sont obligatoires et la climatisation est optionnelle. La transmission manuelle et celle automatique représentent des features alternatives, c est-à-dire qu un choix exclusif doit être fait pour eux. FIG. 4.4 Diagramme de features - exemple. L étape de conception permet de spécifier l architecture de la ligne de produits. L architecture d une ligne de produit, appelée architecture de référence, identifie et explicite tous les systèmes qui appartiennent à la famille de produits et leurs interactions. Ainsi, tout système appartenant à la ligne de produit est conforme à cette représentation. L étape d implémentation réalise l infrastructure de réutilisation pour la ligne de produits considérée, c est à dire l implémentation des composants réutilisables et de l environnement d assemblage dédié. Le résultat de l étape de l ingénierie du domaine est ensuite mis à la disposition des développeurs des systèmes. Ceux-ci utilisent par exemple l éditeur d applications pour spécifier une application de la ligne de produits. Le développement de celle-ci sera automatisée en partie, ou en totalité en réutilisant des composants logiciels provenant de la base d artéfacts réutilisables de la ligne de produits. L utilisation à échelle industrielle des approches de lignes de produits a permis de mesurer des réels gains de productivité. Nokia, qui a utilisé cette approche pour le développement de certains téléphones portables 6, General Motors 7, Ericsson et bien d autres entreprises ont rapporté des gains significatifs 6 http :// 7 http :// 66

67 3. L INGÉNIERIE DIRIGÉE PAR LES MODÈLES dans la productivité (jusqu à 10 fois), dans la qualité (jusqu à 10 fois), des réductions des temps de développements (jusqu à 98%) et des couts associés au développement (jusqu à 60%). 2.4 Synthèse L ingénierie des domaines est une approche de développement qui met en premier plan la réutilisation. Il s agit d abord de capitaliser l expérience acquise dans le développement des systèmes d un domaine afin d augmenter la productivité, de diminuer le temps de développement et de réduire les coûts du développement des applications à venir. Pour cela, cette approche propose d abord de réutiliser et de structurer l information du domaine dans une base d artéfacts réutilisables. Ces artéfacts peuvent être des canevas de développement dédiés, des générateurs de code, des composants logiciels implémentant diverses fonctionnalités du domaine, des modèles et des documents. Le but est de permettre la réutilisation de l expertise métier et techniques dont le domaine dispose afin de réduire le temps de développement des nouveaux systèmes pour ce domaine et augmenter la qualité. L ingénierie des domaines peut être utilisée dans divers contextes, voire même pour produire une infrastructure d automatisation du développement d une simple application. Toutefois, les plus intéressants résultats sont obtenus si l approche est appliquée pour l automatisation du développement d une famille de produits. Les chiffres, que nous avons présentés pour des cas d utilisation réels des approches de lignes de produits, montrent les bénéfices de l ingénierie des domaines et incitent de nombreuses entreprises à s intéresser cette approches. 3 L ingénierie dirigée par les modèles L ingénierie dirigée par les modèles (l IDM) 8 [Sch06] vise à fournir un cadre pour le développement de logiciels, qui est vu comme une série de raffinements entre modèles du même système à divers niveaux d abstraction. L IDM part de l idée que les systèmes logiciels peuvent être décrits par un ou plusieurs modèles, chacun présentant un point de vue sur le système considéré. Cela augmente le niveau d abstraction et sert de base pour la communication entre les différents acteurs qui s approprient ces différents vues du système. Le développement est automatisé par cette série de raffinements, appelés transformations de modèles. Au coeur de l IDM se trouve le concept de modèle, mais aussi les concepts de langage, de méta-modèle et de transformation de modèles, que nous introduirons dans la section suivante. 3.1 Principaux concepts de l IDM Actuellement il n existe pas vraiment de définition universellement acceptée par rapport à ce qu est un modèle. Il existe cependant un consensus sur une caractéristique fondamentale d un modèle : "Un modèle est une abstraction... une représentation... une simplification d un système étudié." [FEBF06] Dans le cadre de l IDM, les modèles sont des artéfacts productifs qui sont utilisés pour produire les systèmes qu ils représentent. Pour être manipulés par une machine, ces modèles doivent être exprimés en utilisant des langages de modélisation précis et biens-définis. Pour définir ces langages de modélisation, tous les aspects du langage doivent être spécifiés. Le langage de modélisation devient ainsi lui-même sujet de modélisation. Cette idée introduit la notion de méta-modèle, qui représente le modèle d un langage de modélisation [Fav04]. Si nous nous rapportons à la théorie des langages, qui définit un langage comme un ensemble de phrases et introduit la notion de grammaire qui représente un modèle de langage, nous retrouvons le concept de méta-modèle dans celui de grammaire. Cela introduit la relation de conformité (voir la figure 4.5) entre un modèle et son méta-modèle. Cette relation assure qu un modèle est bien construit de point de vue théorique mais surtout opérationnel et les transformations automatisées peuvent lui être appliquées afin de produire le système correspondant. De la même manière qu un modèle est conforme à un méta-modèle, il est possible de considérer le méta-modèle comme un modèle conforme à son méta-modèle, appelé méta méta-modèle. Ce méta langage de modélisation est unique et offre un cadre unifié pour la définition de multiples langages de 8 Model Driven Engineering 67

68 CHAPITRE 4. LES APPROCHES GÉNÉRATIVES FIG. 4.5 Les relations entre les concepts de l IDM modélisation. De plus, la possibilité de décrire tous les méta-modèles dans un langage unique assure l interopérabilité entre les différents outils de l IDM. La première architecture de méta-modélisation est celle proposée par l OMG qui, dans le cadre du MDA (Model Driven Architecture), propose un ensemble de standards industriels pour la modélisation des systèmes logiciels. 3.2 MDA, une branche de l IDM L idée initiale du MDA [OMG03] est apparue du constat que l évolution continue des plates-formes entrainait le besoin de changer constamment la réalisation des applications existantes. L objectif du MDA est de fournir les outils nécessaires pour pouvoir produire une application spécifique à une plate-forme à partir d un modèle stable, c est-à-dire qui ne change pas une fois que la plate-forme ait changée. Il était donc besoin de découpler la réalisation d une application de son plate-forme technologique. Pour cela, le MDA propose de décrire séparément les parties d une application qui sont indépendantes et/ou spécifiques de la plate-forme technologique. Cela donne lieu à des spécifications du même système, réalisées à des niveaux d abstraction différents. La terminologie MDA appelle ces deux modèles le modèle indépendant de la plate-forme (PIM 9 ) et le modèle spécifique à la plate-forme (PSM 10 ). Le passage d un PIM vers un PSM est réalisé par une ou un ensemble de transformations 11. Cette transformation est mise en oeuvre, comme le montre la figure 4.6, par l introduction des considérations techniques dépendantes d une plate-forme qui constituent le modèle dépendant de la plate-forme (PDM 12 ). FIG. 4.6 La principale idée du MDA L idée initiale de l OMG était de s appuyer sur le standard UML pour la description des modèles. Cette idée a ensuite évolué vers l utilisation du MOF (Meta Object Facility) comme langage de méta-méta modélisation, qui est utilisé pour la description de plusieurs méta-modèles, dont UML fait partie. Pour la réalisation des transformations de modèles, OMG a dernièrement proposé MOF/QVT 13, une technologie qui est actuellement en cours de standardisation. 9 Platform Independent Model 10 Platform Specific Model 11 Plusieurs PIM ou PSM peuvent être réalisés pour le même système, en fonction du niveau d abstraction auquel on se situe. 12 Platform Dependent Model 13 Queries, Views, Transformations 68

69 4. LES RELATIONS ENTRE LES DEUX APPROCHES La proposition de l OMG a beaucoup contribué à la prise de conscience de l importance des modèles dans le développement de logiciels. Le résultat de cette proposition s est concrétisé dans un ensemble de standards industriels qui ont été proposés et utilisés dans un certain nombre de projets, tant industriels que de recherche. Malheureusement, cette proposition n a pas connu un vrai succès dans le monde académique. Certains lui reprochent l ambigüité des concepts (par exemple, quels sont les concepts qui devront être considérés comme spécifiques à une plate-forme ou dépendants d une plate-forme) et des solutions proposées [Fav04] [FEBF06]. Une autre critique est l utilisation d UML comme seul langage de modélisation, fait qui restreint l interopérabilité des outils (cet aspect a été amélioré avec l utilisation du MOF comme méta-méta modèle). La majorité reconnait, néanmoins, que le MDA a donné lieu à une réflexion plus large autour des approches génératives. Ainsi, le MDA est considéré comme étant le point de départ et comme s intégrant dans une approche générative plus ambitieuse et plus large, qu est l IDM. 3.3 L IDM, au-delà du MDA Le monde académique propose d étendre l idée du MDA à toutes les étapes du développement de logiciels (analyse, développement, test, débogage etc). L élément central reste le modèle mais l étendue du langage de modélisation n est plus restreinte au couple UML/MOF. L IDM généralise les propositions du MDA d abord par la généralisation des langages de modélisation. Ainsi, plusieurs langages de modélisation sont permis en fonction de l espace technique du problème en question. Par exemple, MOF et Ecore sont propres à l espace des modèles 14, les langages de définition tels que BNF sont propres à l espace des grammaires 15 et XML est le langage de description pour l espaces des documents 16. Le développement de logiciels implique la considération de plusieurs espaces techniques à la fois. Chaque espace technique a développé un savoir-faire et des technologies propres. L IDM permet de prendre en compte plusieurs espaces techniques par la capacité de développer plusieurs modèles pour le même système, un modèle par espace technique par exemple. Pour pouvoir les intégrer dans le processus de développement de la même application, il est donc nécessaire de permettre leur interopérabilité. Cela nécessite des outils pour transformer un modèle d un espace technique vers un autre pour profiter des moyens techniques de chaque espace. La réalisation de ces traitements automatiques de modèles (tissage, vérification, transformation) est faite en s appuyant sur des standards précis, limités en taille et spécialisés. L IDM accorde une importance particulière à la notion de langage spécifique à un domaine (DSL), que nous détaillerons dans la section 4.1. Les DSL sont des langages spécialisées de plus petite taille. Leur utilisation permet d éviter les problèmes d UML (complexité croissante du standard, manque de définition rigoureuse pour quelques concepts). L idée d un langage monolithique unique est remplacée par l IDM avec la définition de multiples langages de petite taille, facilement manipulables, transformables, combinables etc. L IDM doit être vue comme une intégration, une continuation et un renforcement des approches déjà connues. Il ne s agit pas d une approche nouvelle mais d une évolution qui utilise l existant. L élément originel n est pas l utilisation des modèles mais surtout l utilisation systématique des méta-modèles, de transformations pour rendre les modèles productifs. Un autre point essentiel de l IDM est son ambition d être une approche unificatrice qui promeut la convergence des résultats d un grand nombre de disciplines du génie logiciel. 4 Les relations entre les deux approches L objectif des approches génératives est l automatisation du développement de logiciel. Pour cela, elles peuvent être vues comme des approches permettant le passage automatique d un problème, défini en utilisant des abstractions spécifiques au domaine auquel il fait partie, vers une solution, réalisée avec des abstractions spécifiques à une technologie d implémentation. Nous avons présenté deux approches génératives dont le but est de simplifier le développement des logiciels par automatisation : l ingénierie des domaines et l ingénierie dirigée par les modèles. L idée commune de ces approches est l utilisation de connaissances relatives au problème que le logiciel doit résoudre. 14 Modelware 15 Grammarware 16 Docware 69

70 CHAPITRE 4. LES APPROCHES GÉNÉRATIVES Ces deux approches ont en commun leur objectif : automatisation du développement de logiciels. L ingénierie des domaines essaie de capitaliser la spécificité d un domaine, appelé souvent domaine métier, l expertise des utilisateurs afin de produire tout un outillage pour automatiser le développement. L IDM fournit le cadre adéquat pour le développement de ces outils. L ingénierie des domaines propose une approche méthodique pour l automatisation du développement d applications d un domaine particulier. L espace de la solution est maintenant élargi à une famille de produits et non seulement à un seul produit, comme c est souvent le cas général de l IDM. Étant dédiée non plus au développement d une seule application pour un seul contexte, mais à un ensemble d applications qui ont des propriétés en commun mais aussi des différences, l ingénierie des domaines propose de tirer profit de l expertise dans le développement de ces systèmes. Le résultat est un modèle de domaine qui contient non seulement des abstractions spécifiques au problème mais aussi d informations sur la modalité de développement des solutions dans l espace considéré : des combinaisons incorrectes de composants logiciels, des valeurs par défaut, des dépendances de composants, des règles de construction et d optimisation, etc. Comme le montre la figure 4.7, dans l ingénierie des domaines, le passage de l espace du problème vers celui de la solution peut être vu comme une configuration. L utilisateur spécifie un système en sélectionnant un ensemble de caractéristiques (features) qu il configure. Cette configuration est ensuite automatiquement transformée dans une configuration de composants de l espace de la solution, qui représente une application appartenant à la famille de produits. L IDM propose d utiliser l expertise métier pour créer un modèle du problème afin d automatiser le passage direct ou incrémental de ce modèle abstrait vers un modèle concret, spécifique à une plateforme par l application des règles de transformation bien définies, comme le montre la figure 4.8. Elle propose de modéliser un système logiciel par un ensemble de modèles. Ces modèles peuvent représenter différents aspects du problème considéré à différents niveaux d abstraction. Des règles de transformations permettent de changer par exemple le niveau d abstraction (de s approcher plus de l espace de la solution) ou d échanger des informations entre les modèles du même niveau d abstraction. Au coeur de l approche IDM se trouve des concepts tels que modèle, méta-modèle ou langage de modélisation, transformation de modèles. La transformation des modèles est la principale fonctionnalité qui est à la base de la capacité générative de l IDM. FIG. 4.7 L ingénierie des domaines - configuration FIG. 4.8 L IDM - transformation Toutefois, ces deux approches ne sont pas totalement disjointes. Nous considérons l IDM comme un bon instrument pour la réalisation de l ingénierie des domaines [VG07]. L ingénierie des domaines peut tirer profit de l attention accordée dans l IDM à la modélisation. Les principes de l IDM peuvent être un bon moyen pour la réalisation des modèles utilisés par l ingénierie des domaines. Elles peuvent être employés pour la définition du langage spécifique au domaine. Des outils comme EMF 17 /GMF 18, issus des projets d IDM, peuvent être utilisés pour la génération d outils dédiés pour l ingénierie des applications. De plus, les transformations de modèles, propres à l IDM, peuvent également être utilisées dans la spécification et la réalisation des différents générateurs ou compilateurs utilisés dans l ingénierie des applications. Une application intéressante de l utilisation de l IDM dans ce contexte est la création d une approche générative basée sur un langage spécifique au domaine. La section suivante présente quelques caractéristiques des langages spécifiques au domaines (DSL). 4.1 Application : Langages spécifiques aux domaines L objectif des approches génératives est l automatisation du développement de logiciels. La vision idéale promue par ces approches est l utilisation d une spécification de haut niveau d abstraction pour la description d une application, suivie d une étape de génération qui permet le développement de l application. Certains approches génératives utilisent pour la modélisation d une application un langage plus res- 17 Eclipse Modeling Framework - http :// 18 Graphical Modeling Framework - http :// 70

71 4. LES RELATIONS ENTRE LES DEUX APPROCHES treint, dédié à un contexte particulier, appelé langage spécifique au domaine (DSL 19 ) [vdkv00]. Souvent déclaratif, un DSL permet d identifier les principales abstractions du domaine, c est-à-dire les concepts spécifiques au domaine et leurs relations. L identification de ces concepts est le résultat d une phase d analyse du domaine et donc, souvent, ces concepts coïncident avec les principaux concepts utilisés par les développeurs dans le domaine. De plus, un DSL fournit souvent un ensemble de notations graphiques ou textuelles pour ses concepts. En fournissant des concepts proches du mode de raisonnement des développeurs et des notations graphiques, un DSL est plus expressif et plus facile à utiliser par rapport à un langage général. Cela réduit également le temps d apprentissage de l outillage fournit par l approche générative utilisant le DSL. En général, comme le montre la figure 4.9, l outillage fourni par une approche générative basée sur un DSL contient : Éditeur d applications qui permet de réaliser la spécification abstraite de l application en utilisant les concepts, les notations définis par le DSL ; Compilateur de DSL qui permet d automatiser le développement de l application correspondant à la spécification utilisée comme point d entrée. Cet outil est aussi appelé générateur d applications, ou interpréteur de DSL ; Un framework spécifique au domaine, contenant par exemple un ensemble de composants implémentant des fonctionnalités correspondant aux concepts du domaine. FIG. 4.9 Approche générative basée sur un DSL. Souvent, l utilisation d un DSL peut être décidée lors du processus de réalisation de l ingénierie des domaines. La phase d analyse du domaine permet, comme nous l avons vu, d identifier le domaine et de spécifier le DSL. La phase d implémentation réalise l implémentation du langage et de l outillage correspondant, l éditeur permettant la spécification des applications, le compilateur qui traduit cette spécification vers une application exécutable, le framework contenant les composants spécifiques au domaine. L utilisation des principes de l IDM et de ces outils dans le cadre d une approche basée sur un DSL s avère, des dernières années, très propice. Ainsi, on utilise actuellement des méta-modèles pour définir le DSL et des transformations de modèles pour le développement des applications. Un avantage de l utilisation de l IDM pour la réalisation des approches DSL est la gamme d outils issus des travaux autour de l IDM qui peuvent faciliter le développement de l environnement dédié. Ainsi, des environnements dédiés à la réalisation des approches DSL comme GME (Generic Modeling Environment) [Env], l outil DSL de Microsoft [GS04] permettent la génération d un outil basique de développement correspondant à un DSL. Les principaux bénéfices d une approche basée sur des DSL sont [Cza04] [MHS05] : Un DSL fournit une notation familière, des notations et des abstractions spécifiques au domaine, qui représente des concepts spécifiques au domaine. Ce facteur ne doit pas être sous-estimé, car son effet direct se mesure dans le gain de productivité des approches basées sur DSL par rapport aux approches générales de développement. De plus, le temps d apprentissage de l utilisation de l environnement dédié est réduit par le fait que les utilisateurs manipulent des concepts qui leur sont familiers ; Abstraction de haut niveau : un DSL propose au développeur d une application directement des abstractions représentant les concepts du domaine. Par sa manière d être construit, un DSL garantit la concision des spécifications, ce qui augmente leur compréhension et garantir leur exactitude ; Un bénéfice très important est que l expert du domaine peut écrire directement la spécification d un système sans faire appel aux connaissances des programmateurs [Wil01] ; 19 Domain Specific Language 71

72 CHAPITRE 4. LES APPROCHES GÉNÉRATIVES Une approche basée sur un DSL permet l optimisation du code obtenu pour une application en réutilisant l expertise du domaine, information qui n est généralement pas disponible dans le cas d un langage général ; Un outillage spécifique avec une utilisation facile. Toutefois, les approches génératives basées sur des DSL ont quelques désavantages. Le développement d un DSL est difficile car cela demande d avoir une expertise dans le domaine mais aussi dans le développement de langages. Le DSL peut être développé seulement si le domaine est assez mature pour qu on puisse abstraire les concepts essentiels. De plus, le domaine ne doit pas évoluer trop souvent, car cela nécessite de faire évoluer le DSL et l outil associé aussi et augmente les couts de production. 5 Conclusions Ce chapitre a été dédié aux approches pour l automatisation du développement de logiciels, appelées approches génératives. L automatisation du développement de logiciel permet d accroitre la productivité des développeurs, de réduire les couts et le temps de développement et améliore la qualité du résultat. Nous avons présenté deux approches génératives : l ingénierie des domaines et l ingénierie dirigée par les modèles. L idée de base dans ces deux approches est de réutiliser la connaissance qu on détient dans un domaine pour automatiser le développement des logiciels dans ce domaine. Cette automatisation réalise le passage de l espace du problème, qui est caractérisé par des abstractions spécifiques au domaine, vers l espace de la solution, caractérisé par des abstractions spécifiques à une technologie d implémentation. Ce passage peut être vu comme une transformation, dans le cas de l IDM, ou comme une configuration des différents composants fonctionnels réutilisables dans le cas de l ingénierie des domaines. Cette vision en trois espaces, problème, transformation et solution, permet de situer les approches génératives par rapport aux autres préoccupations du génie logiciel. Cela nous permet également de voir quelles sont les technologies qu une approche générative peut utiliser. Comme le montre la figure 4.10, la caractérisation de l espace du problème peut impliquer des techniques comme la modélisation, la modélisation des features dans le cas des lignes de produits et la construction des DSLs. L espace de la transformation emploie des générateurs de code ou des transformateurs de modèles. Finalement, les modèles de composants, les architectures et la programmation générique sont des moyens techniques caractéristiques à l espace de la solution. La programmation orientée aspects (l AOP) couvre une partie de l espace de la transformation et celui de la solution. Nous pouvont donc observer la complexité de la réalisation d une approche générative, qui emploie une multitude de technologies spécifiques du génie logiciel. FIG Les approches génératives dans le génie logiciel (après [Cza04]) Malgré la complexité de la réalisation d une approche générative, l utilisation d une telle approche permet de faciliter le travail des développeurs, de réduire le temps et le cout de développement des applications. Un aspect important des approches présentées est la réutilisation de l expertise métier pour 72

73 5. CONCLUSIONS fournir des environnements de développement dédiés à un domaine. En fonction du degré d automatisation du développement permis par cet environnement, les utilisateurs doivent avoir des compétences différentes, qui varient de compétences techniques et métier pour les environnements réalisant le développement manuel de nouvelles applications à des compétences métier pour les environnements prenant en charge la totalité du processus de développement. Ainsi, on met à disposition des experts métier des outils puissants qui leur permettent de réaliser eux mêmes des applications spécifiques à leur domaine. 73

74

75 Deuxième partie Contribution 75

76

77 5 Proposition 1 Objectifs Ces travaux de thèse s intéressent à la composition de services. L état de l art, que nous avons présenté dans la première partie de ce document, nous a permis de faire quelques constatations qui sont à la base de nos travaux : De nombreux modèles à services existent actuellement. Les mécanismes de composition sont étroitement liés à la technologie à services support. Cela nécessite un apprentissage couteux en temps et ressources ; La construction des applications par composition de services est ainsi réservée aux développeurs ayant une expertise technique importante liée aux diverses technologies à services ; L adoption de l approche à services pour la réalisation des applications dans un domaine particulier rend plus difficile la tâche des développeurs. Ceux-ci doivent gérer, à la fois, deux dimensions de complexité : technique, due à l adoption de l approche à services, et métier, provenant de la difficulté spécifique au contexte d application ; Actuellement, nous disposons d outils de développement pour la réalisation des compositions de services. Ces outils guident le développeur dans les différentes étapes qui interviennent pour accomplir une composition de services. Ils restent, néanmoins, dédiés à des experts techniques qui réalisent manuellement une partie de leur travail. Un autre inconvénient est leur appartenance à une technologie à services particulière, bien souvent les services Web. Ainsi, on ne peut pas les adapter facilement pour les utiliser à la réalisation des compositions de services avec une autre technologie à services que celle initialement prévue. Notre objectif est de simplifier le travail des développeurs lors de la réalisation d applications par composition de services. Nous considérons que le développement d une composition de services doit être simple et rapide. Pour cela, les développeurs doivent disposer d environnements de développement qui les aident le plus possible dans la réalisation de leur travail. Pour permettre à ces utilisateurs de développer d une façon simple une application à services, nous pensons qu un environnement de développement doit remplir les objectifs suivants : 1. Permettre la spécification des applications. Cette spécification doit être réalisée d une manière abstraite, simple et naturelle, pour le développeur et sans trop de détails techniques. Ainsi, les développeurs pourront se concentrer sur la logique métier que l application réalise. 2. Automatiser la réalisation de la composition de services ainsi spécifiée avec un minimum d intervention de la part de l utilisateur. Ainsi, le traitement des détails techniques est à la charge des outils et non plus des développeurs. 3. Intégrer la dimension domaine. Ce dernier objectif est d offrir aux experts métier les moyens nécessaires pour développer rapidement des applications par composition de services. Pour l instant, 77

78 CHAPITRE 5. PROPOSITION le développement des applications à services est une tâche accessible seulement aux développeurs ayant une expertise technique dans les approches à services et les technologies existantes. En permettant aux experts métier de développer des applications à services, nous considérons que l approche à services deviendra plus populaire et son adoption par le monde industriel sera acceleré. Ces deux premiers objectifs visent l élimination de la complexité technique d une composition de services. Ils sont traités, en partie, par la plupart des environnements de développement à services existants aujourd hui, comme ceux que nous avons mentionné dans la partie état de l art de ce document. Dans la section suivante, nous présentons l approche adoptée dans notre environnement de développement pour répondre à ces objectifs. 2 Notre approche Nos travaux proposent un environnement de développement de compositions de services. Cet environnement, appelé DoCoSOC (Domain Configurable Service Oriented Computing), permet le développement automatisé des compositions abstraites de services et la prise en compte des informations liées au domaine applicatif. L emploi d informations sur le domaine permet de fournir aux utilisateurs qui n ont pas des connaissances techniques les moyens nécessaires pour développer rapidement des applications à base de services. Notre environnement de développement des applications à services est construit selon une approche dont les points principaux sont : Une approche de développement en deux étapes. La première étape consiste en la spécification abstraite de la composition de services. La seconde étape consiste en la projection automatisée de cette spécification vers une technologie à services particulière. Une approche centrée sur le domaine de façon à guider le développeur lors de la spécification de la composition abstraite afin de garantir sa correction et automatiser la réalisation des compositions de services. 2.1 Approche de développement L approche de développement des compositions de services que nous proposons est composée de deux étapes (comme le montre la figure 5.1). FIG. 5.1 Approche de développement des compositions de services La première étape vise la spécification abstraite d une composition de services. Celle-ci doit être réalisée à un niveau élevé d abstraction afin de permettre aux développeurs de se concentrer sur la logique métier de l application et non sur les détails techniques nécessaires pour la réaliser. La deuxième étape est celle de la création proprement dit de la composition. La spécification de la composition de services est le point d entrée d un générateur qui automatise la réalisation de la projection de cette spécification vers une application exécutable avec le minimum d intervention de la part du développeur. Composition abstraite de services Nous proposons de réaliser la spécification d une composition de services d une manière indépendante d une technologie donnée. La spécification de la composition de services, que nous appelons composition abstraite de services, désignera d une manière indépendante d une technologie, voire même d une 78

79 2. NOTRE APPROCHE technologie d implémentation, les fonctionnalités qu elle utilisera et la logique métier de leur utilisation. Ainsi, tout détail technique est éliminé et l accès est mis sur la logique des différentes interactions des services réalisant la logique métier de la composition. Une composition abstraite de services identifie ainsi, d une manière équivalente à un ADL 1 [MT00] [WMD07], les services abstraits qu elle utilise et leurs interactions. Service Abstrait - Nous définissons un service abstrait comme la spécification d un service. Cette spécification définit la fonctionnalités fournie par un service au moyen de la signature d une interface Java. La figure 5.2 présente sous une forme graphique un service abstrait. Un service abstrait peut être utilisé par les consommateurs de services pour exprimer une requête par rapport aux fonctionnalités qui lui sont nécessaires. Un fournisseur de service peut utiliser également un service abstrait comme spécification qui sera la base de la réalisation de l implémentation de ces fonctionnalités. Tout en restant indépendant par rapport à une technologie à services mais aussi par rapport à une technologie d implémentation, le service abstrait définit : Des propriétés identifiées par un nom et un type de données. Nous avons distingué deux catégories de propriétés de services : Des propriétés de service utilisées, par exemple, pour caractériser le service d un point de vue fonctionnel ou non-fonctionnel ; Des propriétés de configuration qui sont utilisées pour préparer le service pour être utilisé par un consommateur de service. La modalité de configuration du service - Nous utilisons pour la configuration d un service un fichier dont la syntaxe est définie par un template attaché au service abstrait. Ce template va être utilisé par la suite, lors de l étape de construction de l application, pour produire automatiquement la configuration du service. FIG. 5.2 Service abstrait. Connecteur - Un connecteur représente une liaison entre services. Pour rester au même niveau d abstraction que le service abstrait, un connecteur est décrit indépendamment d une technologie. Il est caractérisé par un type d interaction (publication/souscription ou événements) et un type de liaison (statique ou dynamique). Son rôle est de contrôler la communication entre les services qu il connecte. Cependant il peut être utilisé également pour exprimer des requêtes de médiation qui résolvent des différentes incompatibilités entre services. Pour pouvoir spécifier des propriétés non-fonctionnelles pour la composition de services (telles que la distribution et la sécurité), un connecteur peut être annoté avec les propriétés non-fonctionnelles. La figure 5.3 présente sous une forme graphique un connecteur. Une composition abstraite, telle que celle présentée en exemple dans la figure 5.4, permet donc d indiquer les services abstraits nécessaires et leurs interactions, sous la forme des connecteurs. Lors de la spécification de la composition abstraite, le développeur indique les services abstraits impliqués, donne des valeurs pour les propriétés de configuration du service abstrait et spécifie également les différentes 1 Architecture Description Language 79

80 CHAPITRE 5. PROPOSITION FIG. 5.3 Connecteur. interactions entre ces services. L utilisation des services abstraits et des connecteurs lui permet de s abstraire de toute technologie. FIG. 5.4 Exemple de composition abstraite. Le passage de la spécification abstraite à une application concrète est ensuite réalisé de façon transparente pour le développeur. La spécification de la composition abstraite ne lui demande plus de connaître des détails techniques propres à l approche à services et plus particulièrement à une technologie à services, tels que les services Web ou OSGi. Ces aspects sont gérés par l environnement de développement utilisé. Avant de réaliser le développement de la composition ainsi spécifiée, l environnement effectue une vérification de sa correction. Par exemple, pour un connecteur de type Publication/Souscription le type de données produites (dataproduced) doivent être compatibles à la fois avec les types de données utilisés par le services jouant le rôle de consommateur (dataconsumed) et les données transportées par le connecteur. Développement automatisé Le résultat du développement automatisé de l application ainsi spécifiée doit être une application exécutable qui permet l invocation des implémentations des services disponibles, par exemple, via un registre de services. Ces implémentations ne sont plus indépendantes d une technologie à services. Elles sont très liées à la technologie à services utilisée pour, par exemple, leur description et leur publication. De plus, la projection de la spécification d une composition abstraite vers une technologie à services est très dépendante de cette technologie (voir la figure 5.5). Le résultat de cette projection vers deux technologies à services diffère à cause des modalités spécifiques à la technologie. Pour désigner ces entités spécifiques à une technologie à services nous introduisons le concept de service concret. Un Service concret représente une implémentation d un ou plusieurs services abstraits. Un service 80

81 2. NOTRE APPROCHE FIG. 5.5 Exemple de projection automatisée vers une technologie à services. concret n est plus indépendant d une technologie à services. Il constitue la partie spécifique d une technologie à services. L étape de projection automatisée est transparente pour le développeur, c est-à-dire que toutes les étapes intermédiaires sont réalisées avec le minimum d intervention de sa part (les différentes étapes sont représentées sur la figure 5.6) : Interrogation des registres de services pour déterminer les services concrets disponibles qui correspondent aux services abstraits de la spécification de l application, mais également à la technologie à services choisie. La modalité de réalisation de ces requêtes est très fortement liée à cette technologie à services. Les descriptions de services ainsi découvertes sont aussi spécifiques à cette technologie ; Le résultat de l étape précédente est une liste de services concrets répondant aux critères fonctionnels de la composition abstraite. Un choix doit être fait ensuite pour sélectionner les services concrets appropriés. Ce choix peut être fait en fonction de diverses stratégies liées ou non à l état de la plate-forme de l exécution ou aux besoins non-fonctionnels de l application ; Configuration des services concrets sélectionnés ; Réalisation des connecteurs entre services, si besoin est. Cette étape suppose la résolution des diverses incompatibilités entre services ou la génération des entités permettant l interaction entre services. FIG. 5.6 D une composition abstraite vers une application exécutable. Dans notre démarche de développement nous pouvons retrouver des principes du monde de l IDM. La spécification de la composition abstraite réalisée en faisant abstraction d une technologie à services 81

82 CHAPITRE 5. PROPOSITION particulière est très proche du concept de modèle indépendant d une plate-forme (PIM). La notion de service concret, qui est spécifique à une technologie à services, est l équivalent du modèle spécifique à une plate-forme. La projection de la composition abstraite vers une application exécutable réalisée avec une technologie à services bien déterminée retrouve aussi son équivalent dans la notion de transformation de modèles de l IDM. 2.2 Approche centrée sur le domaine Nous considérons que, pour apporter une solution fiable aux objectifs précédemment énoncés, nous devons tenir compte de la spécificité du domaine d application. En effet, une architecture à services mise en place pour répondre aux besoins fonctionnels et non-fonctionnels d un domaine d application est très liée à celui-ci. Les services disponibles et utilisés pour la construction des applications à services sont différents d un domaine d application à un autre. De même, la construction des applications à services est caractéristique au domaine. Par exemple, due à la spécificité d un domaine, les applications peuvent être construites en privilégiant les modèles adéquats pour la construction des applications dynamiques et faiblement couplées, tels que le modèle Publication/Souscription. Notre approche centrée sur le domaine propose de considérer une architecture mise en place dans un contexte applicatif particulier comme faisant partie d une ligne de produits. Pour cela, elle propose de réutiliser les connaissances déjà existantes sur ce contexte applicatif, que nous réunissons sous le terme d expertise métier, pour fournir un environnement de développement dédié qui réalise l automatisation des compositions de services. L utilisation de ces connaissances permet de restreindre l étendue d une architecture à services aux limites définies par le domaine applicatif. Le principal avantage de notre approche centrée sur le domaine est la garantie de la correction des compositions de services qui sont réalisées. La limitation définie par le domaine permet d utiliser, lors du développement d une composition de services, seulement les services ayant une sémantique particulière dans le domaine. Ainsi nous assurons que les applications réalisées par compositions de services répondent aux besoins du domaine. Ligne de produits et expertise métier pour les architectures à services Nous proposons de considérer une architecture à services spécifique à un domaine comme faisant partie d une ligne de produits. L objectif principal des approches lignes de produits est de fournir une infrastructure de réutilisation pour permettre le développement automatisé d applications au sein d une famille de produits. Une famille de produits est composée d un ensemble d applications qui partagent une série de propriétés et dont les points de variabilités sont bien identifiés. La distinction des parties communes et variables des différentes applications appartenant à une famille de produits est possible grâce à l expertise métier des experts du domaine. L expertise métier permet d identifier, par exemple, les besoins fonctionnels et non-fonctionnels du domaine, les différents types de systèmes logiciels disponibles et les éventuels besoins pour des nouveaux développements. Elle rassemble également des connaissances de nature technique, comme la modalité d implémentation des systèmes disponibles. Cette expertise métier réunit donc la connaissance des experts métier mais aussi celle des développeurs techniques impliqués dans les différents développements qui ont eu lieu dans ce contexte. L expertise des experts métier permet de connaître la logique métier du domaine, celle des développeurs techniques donne des informations sur la réalisation des systèmes logiciels. L expertise métier est un élément essentiel du patrimoine d un domaine. Son importance devient claire lorsque des nouveaux besoins apparaissent et que le développement de nouveaux systèmes logiciels est nécessaire. La connaissance des systèmes déjà disponibles, de leurs capacités fonctionnelles et non-fonctionnelles, mais également de la manière dont ils ont été réalisés permet de réduire le temps de développement de nouveaux systèmes. Les experts du domaine peuvent décider de réutiliser des composants fonctionnels et de développer les fonctionnalités manquantes. De plus, le développement de ces nouvelles fonctionnalités peut être réduit en connaissant les principes de développement utilisés dans le domaine. Transposés dans le cadre d une architecture à services spécifique à un contexte applicatif, les principes d une approche ligne de produits permettent d obtenir une infrastructure dédiée au développement des applications caractéristiques du domaine. L expertise métier est utilisée pour définir le modèle du domaine, qui représente le point central de notre approche. 82

83 2. NOTRE APPROCHE L utilisation de l expertise métier Pour permettre l automatisation du développement des compositions de services, notre approche est basée sur l expertise métier des experts du domaine. Cette expertise métier permet d identifier les différents éléments impliqués dans l architecture à services mise en place dans un contexte applicatif. Ces différents éléments permettent de construire le modèle du domaine, une spécification abstraite d une architecture à services particulière. Comme le montre la figure 5.7, le modèle du domaine permet de définir une architecture à services spécifique par : FIG. 5.7 Les informations données par le modèle du domaine. Un ensemble de spécifications de services, que nous avons appelés, comme nous l avons déjà indiqué, services abstraits ; Un ensemble d implémentations de services, appelées services concrets, qui réalisent, selon une technologie à services particulière, les spécifications données par les services abstraits ; Les différents types d applications qui peuvent être réalisées avec les services disponibles dans le domaine, appelés architectures de références. Un domaine applicatif correspond généralement à plusieurs fonctionnalités spécifiques. Chaque fonctionnalité métier utilise une partie des services abstraits disponibles dans le domaine. Nous définissons donc chaque fonctionnalité par un type d application défini à travers son architecture de référence. Une architecture de référence spécifie d une manière abstraite toutes les fonctionnalités susceptibles d être utilisées pour la réalisation de l application, en termes de services abstraits, et toutes les interactions qui peuvent avoir lieu entre ceux-ci. Les types de données spécifiques du domaine que les services et les différentes applications manipulent. Un élément très important que ce modèle permet d identifier est représenté par l architecture de référence des applications spécifiques au domaine en question. Dans notre cas, l architecture de référence d une application spécifique à un domaine identifie tous les applications pouvant être créés par l intégration de services abstraits disponibles dans le domaine. Elle identifie les services abstraits pouvant intervenir dans la réalisation d applications et tous les différentes interactions pouvant avoir lieu entre ceux-ci. Une architecture de référence représente la spécification de toutes les applications qui peuvent être instanciées dans ce contexte. Une application particulière appartenant à cette famille respecte les contraintes exprimées par son architecture de référence, c est à dire qu elle utilise les services abstraits mentionnés par l architecture de référence qui interagissent selon les modalités d interactions spécifiés. Notre approche utilise l architecture de référence pour faciliter la spécification des compositions abstraites. Nous utilisons cet élément pour guider le développeur dans la spécification d une application en lui proposant seulement les éléments corrects, c est-à-dire en assurant le fait que la composition abstraite utilise des services abstraits et des interactions spécifiés par l architecture de référence correspondante. La composition abstraite de services et le développement automatisé permettent d éliminer la complexité technique des compositions de services. L utilisation de l architecture de référence nous permet d éliminer également l autre dimension de complexité à laquelle les développeurs sont confrontés - la complexité métier. En effet, l architecture de référence définit la logique métier des compositions de services en identifiant au préalable les services impliqués et leurs interactions. Lors de la spécification de la composition abstraite, elle guide le développeur. En effet, nous utilisons l architecture de référence comme un patron d architecture pour chaque application, qui prédéfinit l ensemble de services abstraits 83

84 CHAPITRE 5. PROPOSITION et d interactions de services que le développeur peut sélectionner. Le travail du développeur est réduit à la sélection des services abstraits intervenant dans la liste des services abstraits définis par l architecture de référence, à leur configuration et à la spécification des interactions correspondantes entre les services, conformément aux informations données au préalable. L infrastructure de réutilisation d une ligne de produits pour une architecture à services Comme le montre la figure 5.8, notre infrastructure de réutilisation d une ligne de produits pour une architecture à services est composée d une base d artéfacts réutilisables, d un éditeur d applications spécifique au domaine et d un générateur de code qui automatise le développement des applications en réutilisant des artéfacts de la base. FIG. 5.8 Infrastructure de réutilisation d une ligne de produits SOA Les intérêts de cette approche pour les applications à base de services sont : L utilisation d un environnement de spécification dédié au domaine en question qui restreint les concepts manipulés par les développeurs aux concepts ayant une signification particulière pour eux dans le domaine considéré ; La possibilité de permettre le développement d applications aux autres utilisateurs que les développeurs de logiciels ; La garantie de la correction des compositions de services ainsi développées. Une ligne de produits restreint l étendue des services utilisés pour la réalisation des applications aux composants spécifiques au domaine, retrouvés dans la base d artéfacts réutilisables. Ainsi, la spécification d une composition de services utilise seulement les services disponibles dans la base d artéfacts réutilisables. De plus, l approche garantit que le résultat du développement automatisé correspond aux besoins du domaine. Notre approche de développement des applications réutilise cette base d artéfacts dans un environnement de développement dédié composé d un éditeur de compositions de services spécifique au domaine et d un générateur d applications. Nous allons expliquer la manière dont cet environnement réutilise les connaissances provenant de la base d artéfacts réutilisables. Le développement d une application à services débute par la spécification de la composition abstraite. Cette étape est réalisée par un développeur avec l aide d un éditeur d applications. Cet outil utilise la base d artéfacts réutilisables afin de permettre seulement la spécification des compositions abstraites correctes correspondant aux types d applications spécifiques au domaine. Ainsi, la spécification d une composition abstraite implique des services abstraits disponibles dans la base d artéfacts. De plus, les interactions de ces services correspondent aussi aux différentes interactions identifiées pour un type d application du domaine. De la même manière, le générateur d applications, qui doit produire l application qui correspond à la composition abstraite spécifiée dans l étape précédente, utilise la base d artéfacts réutilisables. Il doit d abord réaliser la sélection des services concrets correspondant, les configurer de la manière caractéristique au service abstrait correspondant et réaliser les connections entre les services concrets respectifs. 84

85 3. ENVIRONNEMENT DE DÉVELOPPEMENT SPÉCIALISÉ PAR UN DOMAINE D APPLICATION 3 Environnement de développement spécialisé par un domaine d application Nous avons choisi d adopter une approche ligne de produits pour permettre le développement automatisé des compositions de services dans un domaine particulier. Cette approche permet de construire une infrastructure de développement dédiée à un domaine qui réutilise l expertise métier pour réaliser l automatisation du développement des applications appartenant à la ligne de produits. L infrastructure de développement d une approche ligne de produits pour une architecture à services est spécifique à la ligne de produits, donc au domaine d application pour lequel elle est crée. Cependant, nous sommes intéressés par l utilisation de cette approche dans divers domaines d applications. En conséquence, notre environnement de développement doit pouvoir être spécialisé en fonction de la spécificité de chaque nouveau domaine d utilisation. La spécialisation de l environnement est réalisée en utilisant le modèle du domaine. Les experts techniques (métier) disposent d un outil de spécification qui permet la définition du modèle du domaine. Comme le montre la figure 5.9, le modèle du domaine est utilisé pour produire automatiquement la partie spécifique au domaine de notre environnement de développement. Ainsi, le modèle du domaine permet de définir la base d artéfacts réutilisables du domaine mais aussi de produire un éditeur d applications dédié. Ce dernier outil sera par la suite utilisé par les experts métier pour réaliser la spécification des compositions abstraites de services qu ils désirent développer. FIG. 5.9 Spécialisation de l environnement de développement pour un domaine. Notre environnement de développement contient une partie générale, composée d un éditeur d applications et d une générateur de code, et une partie spécifique pour chaque domaine d utilisation, produite en utilisant le modèle du domaine. La partie générale représente le noyau fonctionnel de cet environnement car elle contient les mécanismes nécessaires pour le développement automatisé des compositions de services. L éditeur d applications permet la spécification des compositions abstraites de services. Le générateur d applications automatise le développement des applications ainsi spécifiées en prenant en charge tous les aspects techniques provenant du choix d une technologie à services particulière. La spécialisation de cet environnement doit fournir aux développeurs d un domaine des outils spécifiques pour leur domaine. L éditeur d application doit être spécialisé afin de permettre la spécification des applications spécifiques au domaine. Ainsi, ils pourront spécifier des compositions abstraites dont la correction est garantie et manipuler ainsi seulement des services appartenant au domaine. A partir de cette spécification, l environnement de développement doit automatiquement produire l application correspondante. La manière dont cette application est construite est aussi spécifique au domaine considéré. Ainsi, le générateur doit lui aussi être spécialisé en fonction du domaine d application. Le modèle du domaine définit la base d artéfacts réutilisables spécifiques à l architecture à services d un domaine. Il permet donc d identifier les services abstraits spécifiques du domaine, les implémentations de services disponibles, c est-à-dire les services concrets, les types de données caractéristiques au 85

86 CHAPITRE 5. PROPOSITION domaine et les types d applications qui peuvent être construites dans le domaine par composition de services. De la même manière qu une approche ligne de produits, nous proposons donc d utiliser l information contenue par le modèle du domaine pour automatiquement obtenir un éditeur d applications pour ce domaine. L éditeur ainsi obtenu se substitue à celui fourni par l environnement de développement général. Le générateur d applications à services de l environnement de développement général reçoit en entrée la spécification de la composition abstraite et réalise le développement automatisé de l application (le processus à été décrit dans la section 2.1). Sa spécialisation pour un domaine d application particulier implique l utilisation de la base d artéfacts réutilisables lors du développement automatisé de la composition abstraite. Ainsi, le générateur d applications doit être adapté afin d utiliser les services abstraits et concrets s y retrouvant. Le résultat de la spécialisation de l environnement de développement par un domaine particulier est schématisé dans la figure 5.9. La partie générale est donc représentée par les deux composants initiaux de l environnement général - l éditeur d applications et le générateur d applications. Pour un domaine particulier, cet environnement est spécialisé par un éditeur d applications spécifique au domaine et un adaptateur qui spécialise le générateur d applications afin d utiliser les informations spécifiques au domaine considéré, c est-à-dire la base d artéfacts réutilisables propre au domaine. Ainsi, nous faisons intervenir deux types d utilisateurs. Comme le montre la figure 5.9, les experts techniques interviennent pour réaliser la spécialisation de l environnement de développement pour le domaine d application. Ils définissent le modèle de l architecture à services du domaine, appelé modèle du domaine, qui permet de construire automatiquement les composants spécifiques au domaine, c est-àdire la base d artéfacts réutilisables, l éditeur dédié et l adaptateur du générateur d applications. La spécialisation de l environnement de développement général permet ensuite aux experts métier de réaliser eux-mêmes la spécification des applications du domaine (voir la figure 5.10). L éditeur d applications permet d éliminer la complexité technique en utilisant des concepts familiers pour eux. Cette spécification est ensuite le point d entrée du générateur d applications qui est maintenant adapté pour permettre la génération de l application spécifique au domaine. FIG Développement d une application spécifique à un domaine. 3.1 Réalisation basée sur une approche IDM Notre approche a été intégrée dans l environnement DoCoSOC. Au centre de cet environnement, nous avons intégré une approche IDM dont les principaux principes sont présentés dans la section suivante. Principes Notre approche IDM repose sur l utilisation des métamodèles. Les raisons de l utilisation des métamodèles sont multiples. La définition des métamodèles nous a aidé, en premier lieu, à définir, à un niveau 86

87 3. ENVIRONNEMENT DE DÉVELOPPEMENT SPÉCIALISÉ PAR UN DOMAINE D APPLICATION élevé d abstraction les principales entités des architectures à services et leurs relations. Ainsi, nous avons une vision de plus haut niveau et, plus important, indépendante de toute technologie à services, sur les entités essentielles d une architecture à services. Une deuxième raison est le fait que nous utilisons ces métamodèles pour générer des éditeurs qui permettent la spécification de modèles conformes. Pour cela, nous utilisons la technologie EMF 2 qui est le résultat des travaux menés sous l égide de la plate-forme Eclipse par d importants acteurs du génie logiciel, tels que IBM. Comme le montre la figure 5.11, DoCoSOC s appuie sur la définition de deux métamodèles : Un métamodèle décrivant les principales entités des architectures à services - appelé MM SOA général. Ce métamodèle décrit d une manière générale et indépendamment de toute technologie à services les concepts essentiels d une architecture à services et définit leurs relations ; Un métamodèle spécifiant une architecture à services pour un domaine d application particulier - appelé MM SOA du domaine. Il spécialise le métamodèle précédent pour décrire la spécificité d une architecture à services d un domaine. Ce métamodèle reste à un niveau élevé d abstraction car il conserve les propriétés de généricité et d indépendance d une technologie à services. FIG Approche IDM pour le développement de DoCoSOC Comme l indique la figure 5.11, les deux métamodèles ont été utilisés, lors du développement du prototype DoCoSOC, pour produire automatiquement, par génération EMF, les éditeurs correspondants. Le métamodèle MM SOA général est utilisé pour générer l éditeur d applications à services appartenant à la partie générale de DoCoSOC. Cet éditeur permet la spécification des compositions abstraites de services. La réalisation des applications exécutables conformes à ces spécifications est à la charge du générateur de code. Toutefois, comme nous l avons déjà mentionné, la propriété de généricité du métamodèle correspondant ne garantit pas le résultat de cette étape de génération de l application. En effet, la spécification de la composition abstraite est trop générique et pour cela rien ne peut garantir que l application automatiquement obtenue correspond aux besoins. En effet, les services automatiquement sélectionnés peuvent ne pas répondre aux besoins fonctionnels et non-fonctionnels spécifiques d un domaine d application ou à la sémantique propre au domaine. De plus, rien ne garantit leur compatibilité et donc le résultat de l étape de développement automatisé est incertain. Le deuxième métamodèle, MM SOA du domaine, est aussi utilisé pour générer un éditeur. Cette fois il s agit d un composant de l outil de spécialisation, qui permet la définition du modèle du domaine. Le modèle du domaine est ensuite utilisé pour réaliser la spécialisation de DoCoSOC pour le domaine considéré, c est-à-dire pour produire la base d artéfacts réutilisables, pour mettre à la disposition des 2 Eclipse Modeling Framework 87

88 CHAPITRE 5. PROPOSITION experts métier un éditeur d applications dédié au domaine et pour adapter la génération de code. Un des points forts de DoCoSOC est qu il permet aux experts métier de réaliser le développement des applications. DoCoSOC utilise à cette fin la connaissance du domaine exprimée sous la forme du modèle du domaine. En effet, le processus de spécialisation que nous avons présenté dans une section précédente, utilise le modèle du domaine pour produire, pour chaque domaine, un éditeur d applications dédié aux experts métier du domaine. Cet éditeur doit simplifier la spécification d une composition abstraite en éliminant la complexité technique mais également celle métier. N ayant pas de connaissances techniques, l expert métier doit utiliser des concepts simples, familiers lors de la spécification d une application. De plus, il doit être guidé le plus possible dans la réalisation de cette spécification. Pour répondre à ces besoins, DoCoSOC utilise une nouvelle fois une approche IDM, qui est schématisée dans la figure Cette approche emploie le modèle du domaine, définit par un expert technique, afin d automatiquement produire, par transformation de modèles, un troisième métamodèle, appelé MM des applications spécifiques au domaine. Cette transformation, qui sera décrite dans la section 1.3, utilise l information définie par le modèle du domaine afin de fournir une spécification simplifiée des différentes applications spécifiques au domaine. Le rôle de ce dernier métamodèle est, donc, de simplifier la spécification des applications du domaine. Il est ensuite utilisé, de la même manière que les deux autres métamodèles, pour automatiquement produire, par génération EMF, un éditeur d applications qui fait partie de la partie spécifique de DoCoSOC. FIG Approche IDM pour la spécialisation de DoCoSOC DoCoSOC permet le développement automatisé des applications à base de services spécifiques à un domaine applicatif. Pour permettre l automatisation du développement, DoCoSOC utilise également une approche IDM, schématisée dans la figure Celle-ci consiste, en premier, en la définition d une composition abstraite. Celle-ci est réalisée, comme nous l avons déjà mentionné, à un haut niveau d abstraction et indépendante d une technologie particulière. Le passage de cette spécification abstraite vers une application prête d être exécutée, qui utilise des services disponibles dans le domaine applicatif, est pris un charge par un générateur de code. Celui-ci gère tous les aspects spécifiques à l utilisation d une technologie à services. Le prototype actuel de DoCoSOC réalise le passage automatique d une composition abstraite de services vers une application exécutable sur une plate-forme à services OSGi. 88

89 4. CONCLUSIONS FIG Approche IDM pour le développement des applications 4 Conclusions Nos travaux proposent un environnement de développement pour simplifier le développement des applications par composition de services dans un contexte particulier. Cet environnement est basé sur une démarche nouvelle pour le développement des compositions de services. Pour simplifier le travail des développeurs, nous introduisons la notion de composition abstraite. Une composition abstraite représente une spécification d une composition de services qui identifie d une manière indépendante d une technologie les fonctionnalités nécessaires, que nous avons appelé services abstraits, et les interactions survenant entre ses services abstraits. La réalisation de la composition de services ainsi spécifiée est automatisée par l environnement DoCoSOC et réalisée d une manière similaire à une transformation de modèles. Afin d automatiser le développement des applications à services, nous proposons aussi d utiliser une approche ligne de produits pour les applications à services. Ainsi, nous proposons de regarder une architecture à service d un domaine particulier comme une ligne de produits. Cela nous permet de réutiliser les connaissances acquises dans le domaine afin de mettre à la disposition des développeurs d applications un environnement de développement dédié à leur domaine. Cet environnement de développement permet le développement automatisé et rapide des applications réalisées par composition de services. L environnement DoCoSOC est un environnement pour le développement automatisé des compositions de services qui peut être spécialisé pour un domaine d application particulier. Cette spécialisation est automatiquement réalisée en utilisant ce que nous appelons le modèle du domaine, qui représente une spécification des éléments de l architecture à services caractéristique au domaine. Le modèle spécialise la partie générale de DoCoSOC, composé d un éditeur d applications et un générateur de code, pour permettre le développement des applications spécifiques au domaine considéré. Cela permet de mettre à la disposition des experts métier un éditeur d applications dédié au domaine, qui leur permet de spécifier des compositions abstraites en utilisant seulement les services disponibles dans le contexte défini par le domaine. La spécialisation consiste aussi de l adaptation du générateur de code afin de permettre d automatiser le développement de ces applications. Les environnements de développement des compositions de services disponibles aujourd hui sont généralement dédiés aux développeurs techniques ayant une expertise dans les technologies à services. Le travail des développeurs est guidé et partialement simplifié par l utilisation de ces outils. Par l adoption d une approche centrée sur le domaine, DoCoSOC élargit le spectre des utilisateurs qui peuvent développer des applications à base de services. Ainsi, les outils dédiés que DoCoSOC produit pour chaque domaine d application peuvent être utilisés par des utilisateurs experts métier. Ceux-ci réalise la spécification de la composition abstraite, en manipulant des concepts familiers pour eux à l intérieur du domaine. La réalisation de l application exécutable est totalement prise en charge par un générateur de code qui permet ainsi d éliminer la complexité technique de cette tache. Pour valider nos propositions, nous avons développé un prototype de l environnement DoCoSOC, que nous présenterons plus en détail dans le chapitre suivant. DoCoSOC est basé sur une approche 89

90 CHAPITRE 5. PROPOSITION IDM, que nous avons employé pour son développement mais aussi pour la réalisation automatisée des compositions de services. Nous avons également validé l environnement DoCoSOC dans un contexte industriel précis, qui fait l objet du chapitre 7. Notre environnement a été utilisé dans le cadre d un projet RNRT pour faciliter le développement des applications dans le domaine de la distribution électrique. 90

91 6 Réalisation - Métamodèles et architecture Les principes promus par l IDM sont donc au centre de nos travaux. Nous les avons utilisé pour le développement proprement dit de composants de DoCoSOC, pour obtenir des éditeurs intégrés à DoCoSOC mais aussi pour automatiser le développement des compositions de services. La section suivante présente les principaux éléments qui constituent cette approche IDM, plus précisément les métamodèles qui sont à la base de DoCoSOC et la transformation de modèles qui nous permet de simplifier la spécification des applications spécifiques à un domaine. Nous présentons ensuite l architecture de l environnement ainsi realisé. 1 Les éléments de l approche IDM Pour la mise en pratique de cette approche IDM, nous avons défini les deux métamodèles mentionnés. Nous avons utilisé pour la définition de nos métamodèles le langage de modélisation UML (Unified Modeling Language) version 1.1. Les sections 1.1 et 1.2 introduisent ces deux métamodèles. L approche IDM présentée dans la section précédente inclut aussi une transformation de modèles. Celle-ci est exécutée pour permettre la simplification des concepts manipulés par les experts métier pour réaliser la spécification des applications. La section 1.3 présente la réalisation de cette transformation de modèles. 1.1 Le métamodèle SOA Le métamodèle SOA général décrit d une manière abstraite une architecture à services. Il définit les entités qui interviennent dans une architecture à services et les relations entre ces concepts. Même si ces concepts sont indépendants d une technologie à services, notre métamodèle peut ensuite être décliné dans plusieurs technologies à services. Ces concept sont suffisamment généraux pour permettre cette abstraction mais, en même temps, peuvent être retrouvés dans presque toutes les technologies à services existantes. La figure 6.1 présente la vue générale du métamodèle SOA général. Elle identifie d abord plusieurs "préoccupations" qui peuvent apparaître dans une architecture à services. Pour cela il est divisé en plusieurs packages : Service Specification - qui introduit le concept de service abstrait (AbstractService) correspondant, comme nous l avons dit, à une spécification abstraite et indépendante d une technologie à services des capacités d un service ; Service Implementation - qui définit le concept de Service Concret (ConcreteService), représentant l implémentation d un ou plusieurs services abstraits ; Service Description - définit la manière de décrire un service ; Service Registries - introduit le concept de registre de services ; Service Composition - définit la spécification d une composition abstraite de point de vue structurel ; 91

92 CHAPITRE 6. RÉALISATION - MÉTAMODÈLES ET ARCHITECTURE Business Process - représente la spécification de point de vue comportemental d une composition abstraite. FIG. 6.1 Le métamodèle SOA - vue générale. La spécification d un service abstrait La figure 6.2 présente la définition d un service abstrait. Comme nous l avons dit, un service abstrait représente une spécification des capacités d un service. Ces capacités sont définies par une interface de service (Service Interface). Cette interface peut être représentée comme une interface Java, avec un ensemble d opérations. La signature d une opération est définie par le nom de l opération, ses arguments d entrée et de sortie et l exception levée en cas d échec de l exécution. FIG. 6.2 La spécification d un service abstrait. Nous avons également associé aux services abstraits deux propriétés dérivées représentant les messages d entrée (dataflavorin) et les messages de sortie (dataflavorout). Ces propriétés sont automatiquement calculées pour chaque service abstrait en fonction des arguments d entrée (inargument) et de sortie (outargument) des opérations. Ces deux propriétés sont automatiquement exposées dans la description d un service. Leur rôle est de permettre la validation de la réalisation, lors de la spécification d une composition de services, des 92

93 1. LES ÉLÉMENTS DE L APPROCHE IDM liaisons entre deux services. Ainsi, pour permettre une liaison (de type événements ou publication/souscription) entre deux services abstraits, les messages d entrée, respectivement de sortie des deux messages doivent être compatibles. Plusieurs propriétés (ServiceProperty) sont associées à un service abstrait. Ces propriétés, identifiées par un nom et un type de données, peuvent être utilisées, comme nous le verrons par la suite, dans la description du service pour préciser ses capacités. Par exemple, pour un service Mail qui envoie des messages électroniques par , une propriété de service peut déclarer le type de protocole utilisé pour l envoi des messages, disons SMTP. Cette propriété est ensuite exposée dans la description du service Mail qui est publiée dans un registre de services. Un consommateur de service peut ensuite effectuer une recherche sur les services de type Mail qui utilisent le protocole SMTP pour l envoi des messages. Un type spécial de propriété est représenté par les propriétés de configuration (ConfigurationProperty). Ces propriétés permettent de préparer le service pour l utilisation dans un contexte particulier. Si nous reprenons l exemple précédent, le service Mail peut être configuré par plusieurs propriétés de configuration : l adresse de l émetteur et le serveur sortant. L approche à services permet l utilisation des fonctionnalités fournies par divers fournisseurs de services et ne nécessite pas de connaître des détails techniques regardant leur implémentation. Un service peut être découvert, configuré et utilisé. Pour permettre cela, mais aussi pour permettre l automatisation du développement des compositions de services, nous avons choisi de définir la modalité de configuration d un service à travers un template de configuration (Configuration Template) associé au service abstrait. Ainsi, nous faisons deux hypothèses : Nous considérons d abord que la configuration d un service est réalisée à travers un fichier de données ; Nous considérons aussi qu un service abstrait est configuré toujours de la même manière et que toutes les implémentations fournissant ce service respectent cette spécification réalisée au niveau du service abstrait. Le fichier de définition de la configuration attaché au service abstrait définit la syntaxe du fichier proprement dit utilisé dans ce but. Dans DoCoSOC, nous avons choisi de définir cette syntaxe à travers un template JET (Java Emitter Template), technologie intégrée à EMF. Ce template utilise les propriétés de configuration du service abstrait. Cette spécification reste suffisamment générale pour pouvoir être conforme aux technologies à services existantes. Par exemple, un service abstrait, qui sera ensuite implémenté et exposé comme un service Web, déclare son interface qui sera son unique point de sortie (porttype), ses propriétés seront exposées. De même, un service abstrait qui sera implémenté et exposé ensuite comme un service OSGi, déclare l interface fournie et des propriétés de services. Ces propriétés seront ensuite utilisées lors de l enregistrement du service comme propriétés de description. Les éléments de l implémentation d un service Comme nous l avons précisé, nous utilisons le terme service concret (Concrete Service) pour désigner une implémentation réalisant la spécification d un service abstrait. La figure 6.3 présente les différents éléments appartenant à un service concret. Nous avons défini pour un service concret des attributs qui sont utilisés pour l identifier : son nom (name), la version d implémentation (version), le fournisseur (provider) et la type d implémentation (implementationtype) représentant la technologie utilisée pour son implémentation. L implémentation d un service abstrait peut utiliser des fonctionnalités exposées à travers de services. Ainsi, un service concret définit ses dépendances de services à travers des références vers des services abstraits (servicereferences). Le choix de définir ces dépendances de services à travers des services abstraits nous permet d avoir une flexibilité assez grande dans le choix des implémentations de services qui seront utilisées. Un service concret contient un ensemble d artéfacts : Au moins une interface (Interface) représentant l interface du service abstrait qu il réalise ; Des classes d implémentation (ImplementationClass) parmi lesquelles au moins une implémentant l interface de service ; Le fichier utilisé pour la configuration du service (ConfigurationFile) qui respecte la syntaxe définie par le template de configuration (ConfigurationTemplate) associé au service abstrait ; Un descripteur de déploiement (DeploymentManifest) ; D autres ressources, telles que des pages Web, des images etc. 93

94 CHAPITRE 6. RÉALISATION - MÉTAMODÈLES ET ARCHITECTURE FIG. 6.3 Le service concret - éléments. Les éléments de la description de service Un service concret implémente la spécification d un service abstrait. Pour le mettre à la disposition des éventuels utilisateurs, le service doit être publié. Sa publication est réalisée à travers une description de services. Les éléments d une description de service (ServiceDescription) sont présentés dans la figure 6.4. La description de service décrit les capacités fonctionnelles (FunctionalDescription) et non-fonctionnelles (NonFunctionalDescription) d un service. La partie fonctionnelle de la description de service comporte la description des fonctionnalités fournies (ServiceSignature) et les propriétés de services (ServiceProperty). La signature du service et les propriétés de services sont calculées à partir de l information fournie par la spécification du service, c est-à-dire le service abstrait. La partie non-fonctionnelle de la description de service fournit des informations sur ce type de capacités que le service fournie. Parmi les propriétés non-fonctionnelles classiques, nous nous sommes limités à celles liées à la sécurité et à l historisation (log). L utilisation d un service par un éventuel consommateur de service peut être réalisée sous certaines conditions de sécurité imposées soit par le fournisseur de service, soit par le consommateur. Ainsi, nous associons à la description non-fonctionnelle d un service une partie liée à la sécurité : Un service peut avoir un certificat de sécurité (Certificate) qui garantit, par exemple, la provenance du service ; L accès aux fonctionnalités fournies par un service peut imposer une authentification des utilisateurs (Authorization). Une autre propriété non-fonctionnelle prise en compte par notre métamodèle est celle liée à l historisation. Dans certains domaines d application, l historisation des accès aux services est d une très grande importance. Pour cela, nous considérons nécessaire de spécifier dans la description du service l historisation des accès aux opérations du service. Les registres de services Les descriptions de services sont généralement publiées dans un registre de services. Celui-ci a un double rôle - il permet aux fournisseurs de rendre disponibles leurs services et aux consommateurs de découvrir des fonctionnalités qui leur sont nécessaires. Généralement, une architecture à services détient un seul type de registre de services qui liste les descriptions des services disponibles. Notre métamodèle définit deux types de registres de services, comme montré dans la figure 6.5. Le registre appelé AbstractServiceRepository publie les descriptions de services disponibles et le registre ConcreteServiceRepository représente un dépôt contenant les implémentations de services, c est-à-dire les services concrets. 94

95 1. LES ÉLÉMENTS DE L APPROCHE IDM FIG. 6.4 Les éléments de la description de service. La principale raison de l ajout du dépôt de services concrets comme partie intégrante d une architecture à services est la suivante. Le développement automatisé d une composition de services nécessite l exécution de plusieurs étapes, parmi lesquelles la découverte de descriptions correspondant aux fonctionnalités nécessaires, la sélection de services concrets réalisant ces fonctionnalités et leur configuration. Les services concrets jouent donc un rôle important dans ce processus, et donc ils doivent être facilement découverts. Le dépôt de services concrets sert donc à mémoriser les services concrets disponibles qui sont donc facilement localisés. Nous considérons que leur localisation et utilisation sont ainsi facilitées. La composition de services La partie du métamodèle SOA général liée à la composition de services est présentée dans la figure 6.6. Ainsi, une composition abstraite de services représente une application et identifie les services abstraits utilisés et les connecteurs créées entre ceux-ci, qui sont représentés par le concept ServiceBinding. Nous avons identifié deux types de connecteurs de services : PublishSubscribeConnector - représente une liaison asynchrone de type publication/souscription dans laquelle un service fournit un type de données et un autre l utilise ; EventConnector - représente une liaison asynchrone réalisée par l intermède d événements. Ces deux types de connecteurs ne limitent pas les liaisons entre services aux liaisons un-à-un (1 to 1). De plus, les liaisons de type événementielles et publication/souscription sont plus adéquates pour des liaisons "n to m". Pour cela, chaque connecteur définit le nombre d instances de services (ayant le même type) pouvant se connecter du coté émetteur, respectivement récepteur. Les propriétés leftmincard, leftmaxcard, rightmincard respectivement rightmaxcard sont utilisées à cet effet. 95

96 CHAPITRE 6. RÉALISATION - MÉTAMODÈLES ET ARCHITECTURE FIG. 6.5 Les différentes registres de services. Chaque connecteur déclare le type de données qu il transporte (dataflavor). L attribut bindingtype définit la modalité de réalisation des liaisons entre services. Ainsi, une liaison de type STATIC définit avant l exécution les services qui sont connectés des deux cotés du connecteur. Une liaison dynamique est réalisée à l exécution et permet la connexion de nouveaux services des deux cotés du connecteur tant que les limites supérieures définies par les propriétés du connecteur ne sont pas atteintes. Les services abstraits connectés aux deux extrémités d un connecteur jouent le rôle de producteur, respectivement de consommateur de données (événements ou messages typés). Le connecteur lui-même déclare le type de données qu il transporte. Une validation peut être faite pour garantir que la composition peut être réalisée : les types de données produits, transportés et consommés doivent être compatibles. Une application réalisée par composition de services peut exposer elle aussi des services déclarés sous la forme de services abstraits. La composition est, dans ce cas, une composition récursive. Cette partie du modèle relative à la composition de services définit la vue structurelle d une composition de services. Pour des compositions qui sont définies par des procédés exécutables, nous pouvons donc ensuite expliciter l enchainement des invocations des services par un procédé, représenté dans notre métamodèle par l élément BusinessProcess. Les procédés exécutables Une composition de services décrite par l intermèdiaire d un procédé exécutable utilise les concepts présentés dans la figure 6.7. Cette partie de notre métamodèle est très simple car nous nous sommes concentrés plus sur la réalisation des compositions structurelles, le modèle de composition de services étant déjà traité par suffisamment d outils disponibles aujourd hui. Un procédé (BusinessProcess) est composé d un ensemble d activités (ActivitySet), simples (AtomicActivity) ou composites (ComplexActivity). Chaque activité simple effectue un traitement qui consiste de l invocation d une opération fournie par un service. Conclusions Cette section a présenté notre métamodèle général des architectures à services. Il définit les principales entités qui peuvent intervenir dans une architecture à services, comme service abstrait, description de service, implémentation de services, composition de services etc. En même temps, il identifie les différentes relations entre ces concepts. La vue générale de notre métamodèle correspond aux différentes activités impliquées dans la réalisation d une approche à services : spécification, implémentation, description de services, publication, composition de services. Nous avons ensuite détaillé les différentes parties de notre métamodèle correspondantes à ces activités. Nous avons défini ce métamodèle pour deux raisons. Nous avons voulu, d abord, clairement définir les principaux concepts d une architecture à services. De ce point de vue, notre métamodèle représente 96

97 1. LES ÉLÉMENTS DE L APPROCHE IDM FIG. 6.6 Composition de services. un métamodèle conceptuel qui nous aide à mieux réfléchir sur ce problème. Ensuite, ce métamodèle représente le point de départ de DoCoSOC. Il ne reste donc pas seulement un métamodèle conceptuel mais devient productif, car nous l avons utilisé pour générer certains composants fonctionnels de DoCoSOC. Plusieurs propositions de modélisations des architectures à services ont été faites ces dernières années. Ces propositions représentent des métamodèles conceptuels, comme par exemple le modèle crée dans le cadre du projet européen SeCSE 1, et productifs, comme celui d IBM qui est utilisé dans les outils dédiés commercialisés par IBM. Le but du projet SeCSE est de développer des outils pour faciliter l adoption de l approche à services. Le rôle initial du métamodèle SOA qui a été proposé dans le cadre du projet, dont le coeur est représenté dans la figure 6.8, était conceptuel. Il a été crée afin de permettre aux différents participants au projet de mieux comprendre et communiquer sur les différents aspects liées aux architectures à services. Le modèle représenté dans la figure identifie aussi les principaux acteurs intervenant dans la réalisation d une approche à services. Chaque préoccupation de ces acteurs est ensuite détaillée par un modèle spécifique. Par rapport à notre métamodèle, le métamodèle de SeCSE détaille des activités liées à une approche à services, que nous ne traitons pas encore, comme par exemple la surveillance de l exécution des services. Nos deux métamodèles ont certains points en commun (par exemple la définition du service abstrait et de la description de service) mais aussi des différences. Une des différences est représentée par la manière dont une composition de services est définie. Par rapport au modèle de SeCSE, représenté dans la figure 6.9, qui demeure relativement général, nous donnons une définition plus précise d une composition de services car le modèle d interaction est clairement défini par les connecteurs de services (ServiceBinding). Du fait qu il reste général, ce métamodèle SOA ne peut pas encore servir comme modèle productif. D autres métamodèles pour les architectures à services ont été proposés. Le métamodèle d IBM, appelé UML 2.0 Profile for Software Services [Joh05b], celui proposé par W3C, appelé Web Service Architecture (WSA) [W3C] ou ceux définis dans le cadre des approches à services sémantiques, comme le langage WSMO (Web Services Modeling Ontology) [dbbd + 05] sont seulement quelques-uns. Une question peut être posée face à cette multitude de métamodèles. Pourquoi ne pas réutiliser un métamodèle existant? Pourquoi en avoir défini un autre? Certains de ces métamodèles ont été définis seulement pour des raisons conceptuelles, afin de permettre de clarifier certains concepts ou de servir comme langages de communication dans un contexte précis. Le principal problème est qu ils sont assez 1 http ://secse.eng.it 97

98 CHAPITRE 6. RÉALISATION - MÉTAMODÈLES ET ARCHITECTURE FIG. 6.7 Les éléments d une composition exprimée par procédé exécutable. généraux ou bien, très liés au contexte pour lequel ils ont été définis. A notre connaissance, peu sont utilisés à des fins productives, et, malheureusement, leur définition n a pas encore été rendue publique. 1.2 Le métamodèle du domaine Le métamodèle SOA général définit les éléments essentiels d une architecture à services. Toutefois, il ne permet pas de définir en quoi consiste la caractéristique d une architecture à services utilisée dans un domaine applicatif particulier. Pour pouvoir clairement identifier les éléments d une architecture à services qui sont dépendants d un domaine applicatif, nous avons défini un deuxième métamodèle, appelé MM SOA du domaine. Ce deuxième métamodèle identifie clairement les éléments d une architecture à services qui changent en fonction d un domaine d application. Ainsi, il réutilise la définition des concepts généraux réalisée par le MM SOA général (voir la figure 6.10). Nous considérons ce deuxième métamodèle comme une spécialisation qui identifie clairement les éléments d une architecture à services qui sont spécifique à un domaine d application. Nous considérons que plusieurs éléments d une architecture à services changent en fonction du contexte dans lequel cette architecture est utilisée. Il s agit d abord des fonctionnalités disponibles à l intérieur d un domaine qui sont ensuite utilisées pour la construction des applications. Un domaine est, ainsi, d abord caractérisé par un ensemble de fonctionnalités réalisant sa logique métier. La modalité de description et d implantation de ces fonctionnalités est aussi très liée à la pratique du domaine. La logique métier manipule des types de données caractéristiques au domaine d application. Le plus important élément spécifique à un domaine, dans notre cas, est représenté par les différentes applications spécifiques du domaine. Ces applications sont créées par composition de services et utilisent les services spécifiques du domaine qui sont disponibles à l intérieur du domaine. De plus, les différentes interactions entre services utilisés pour la réalisation de la fonctionnalité avancée d une application sont eux aussi spécifiques au domaine, respectivement aux applications du domaine. Ainsi, la spécialisation d une architecture à services pour un domaine doit préciser ses éléments. La figure 6.11 présente le MM SOA du domaine et ses éléments. L architecture SOA d un domaine, appelée plus simplement modèle du domaine (Domain Model) identifie comme éléments spécifiques à un domaine applicatif : Les services abstraits (Abstract Service) qui remplissent des fonctionnalités utilisées pour la création des applications du domaine ; Les registres de services qui publient les descriptions correspondant aux services abstraits (AbstractServiceRepository) et les services concrets implémentant leurs fonctionnalités (ConcreteServiceRepository) ; Les types d applications spécifiques du domaine (Application) qui sont réalisées par composition de services. Ces applications sont spécifiées par l intermédiaire des architectures de référence. Comme nous l avons déjà indiquer, une architecture de référence d une application réalisée par composition de services identifie les services abstraits pouvant être impliqués dans la réalisation de sa fonctionnalité et les différentes interactions pouvant avoir lieu entre ceux-ci ; 98

99 1. LES ÉLÉMENTS DE L APPROCHE IDM FIG. 6.8 Le modèle central du projet SeCSE. - [CNP + 05] Les types de données spécifiques au domaine (DomainSpecificData) qui sont manipulés par les services du domaine. 1.3 Transformation de modèles DoCoSOC utilise les deux métamodèles de base que nous avons présentés pour permettre le développement automatisé des compositions de services dans un contexte applicatif précis. Toutefois, les concepts définis par ces deux métamodèles sont assez techniques et peuvent être compris seulement par des utilisateurs techniques. En même temps, un des objectifs de nos travaux de permettre aux utilisateurs experts métier de développer des applications spécifiques à leur domaine métier. Ces utilisateurs doivent manipuler des concepts qui leur sont familiers, qui sont simples et faciles à comprendre. Pour leur fournir une simplicité de spécification d une application propre à leur domaine applicatif, DoCoSOC utilise une approche IDM basée sur une transformation de modèles. Cette transformation de modèles reçoit en entrée le modèle du domaine et actionne comme un filtre sur celui-ci afin de fournir, en sortie, un métamodèle décrivant d une manière simplifiée les applications du domaine, comme le montre la figure Ainsi, pour chaque domaine applicatif nous produisons, par génération, un nouvel métamodèle décrivant ses applications. Ce nouveau métamodèle est ensuite utilisé pour générer un éditeur dédié à la réalisation des spécifications abstraites décrivant des applications dans le domaine considéré. La définition de ce métamodèle est propre à chaque domaine d application. Il est, quand même, composé d une partie générale de base présente dans chaque domaine sur laquelle les éléments caractéristiques de chaque domaine sont définis. La figure 6.13 présente cette partie de base et schématise la manière dont les éléments caractéristiques sont attachés sur cette partie générale. Cette partie générale définit une application comme un ensemble de services, représentés par le concept de DSAbstractService, et des connecteurs, représentés par le concept DSConnector. Chaque service contient un ensemble de propriétés de configuration. Ainsi, la transformation de modèles, que nous employons, complète cette définition du métamodèle par des éléments concrets provenant du modèle du domaine. Ces éléments correspondent aux services abstraits du domaine, aux propriétés de configuration des services abstraits et aux différents connecteurs spécifiés par le modèle du domaine. Les services abstraits du domaine se retrouvent inclus dans ce métamodèle sous la forme de sous-classes du la classe abstraite 99

100 CHAPITRE 6. RÉALISATION - MÉTAMODÈLES ET ARCHITECTURE FIG. 6.9 Le modèle pour la composition de services du projet SeCSE. - [CNP + 05] FIG La relation entre les deux métamodèles de base de DoCoSOC. DSAbstractService. Ainsi, chaque service abstrait retrouvé dans la spécification de l architecture de référence d une application est ensuite introduit par héritage dans ce métamodèle. Le même traitement est appliqué aux différents connecteurs. De plus, le processus continue avec la simplification des éléments de ces concepts. Nous retrouvons dans ce nouveau métamodèle seulement les éléments nécessaires au moment du développement d une application, respectivement les différents services, leurs propriétés de configuration et leurs interactions. Comme le montre la figure 6.13, chaque service contient un ensemble de propriétés de configuration, correspondant aux propriétés de configuration définies, pour chaque service abstrait, par le modèle du domaine. L architecture de référence d une application contient aussi la définition des interactions entre les services impliqués, sous la forme des connecteurs. Le métamodèle SOA général définit, comme nous l avons mentionné, pour chaque connecteurs la définition des nombres de services pouvant être connectés de chaque coté du connecteur. Ces propriétés sont utilisées par notre transformation de modèles pour restreindre, comme attendu, le nombre de services connectés aux différents connecteurs, pour que la spécification d une application reste toujours conforme à la spécification du modèle du domaine. La figure 6.14 présente l architecture de référence d un type d application spécifique au domaine de la distribution électrique - la surveillance de la consommation électrique. Le schéma est beaucoup simplifié pour faciliter la compréhension de la transformation. Ce type d application utilise deux services 100

101 2. L ARCHITECTURE DE DOCOSOC FIG Le métamodèle d une architecture à services spécifique à un domaine. FIG La réalisation de la transformation - vue technique abstraits spécifiques au domaine : Appareil Electrique et Affichage Navigateur. Ces services interagissent à travers une liaison de type publication/souscription qui permet à n services de type Appareil Electrique de se connecter de coté fournisseur de données et à un seul service Affichage Navigateur d utiliser les données transportées par la liaison. Chaque service abstrait fournit une propriété de configuration que nous illustrons dans l exemple. La transformation de modèles utilise cette spécification pour produire un deuxième métamodèlereprésenté dans le coté bas de l image Comme nous pouvons le constater, les principaux concepts correspondent maintenant aux services abstraits mentionnés dans la spécification de l architecture de référence de l application. Les propriétés de configuration des services sont maintenant représentées comme des attributs du service abstrait. Lors de la spécification d une application de ce type, l utilisateur expert métier doit simplement préciser une valeur pour ce type de données. De plus, la transformation utilise les attributs de la classe PublishSubscribeConnector pour définir les cardinalités des associations d un connecteur, assurant ainsi l exactitude de la spécification réalisée par l utilisateur. 2 L architecture de DoCoSOC Le prototype actuel de DoCoSOC a été développé sous une plate-forme de base Eclipse ( Cette plate-forme est une plate-forme ouverte qui permet le développement et l intégration des outils provenant des fournisseurs divers, grâce au mécanisme de plug-ins. 2.1 La plate-forme de base - Eclipse Eclipse est une plate-forme ouverte de développement ouverte qui connait dernièrement une très large utilisation, fait prouvé par le fait que des compagnies comme IBM l utilise comme plate-forme de 101