Mélusine: un environnement de modélisation et de coordination de services Sonia Sanlaville — Jacky Estublier LSR-IMAG 220, rue de la Chimie BP53 38041 Grenoble Cedex 9 France {Sonia.Sanlaville, jacky.estublier }@imag.fr RÉSUMÉ.

La construction de logiciels à partir de plusieurs applications différentes et hétérogènes est de plus en plus fréquente. Cependant, il n’existe pas à présent une méthodologie de construction pour de tels logiciels. Dans cet article, nous proposons une architecture qui permet de créer des logiciels en faisant collaborer plusieurs services et applications différentes et hétérogènes, utilisant des moyens de communication hétérogènes. Nous présentons notre plate-forme Mélusine, qui est à la fois un environnement de conception, permettant de construire des applications respectant cette architecture et un environnement d’exécution offrant un moteur pour exécuter ces applications. ABSTRACT.

Building software applications based on a number of existing and heterogeneous applications is becoming common. Nevertheless there is not any systematic approach to design and build such applications. In this paper we propose an architecture and tools for software applications that must manage collaboration between different and heterogeneous applications and services, using heterogeneous communication means. We present our Melusine platform, which is both a design and an execution environment specialized for this king of composed software application.

MOTS-CLÉS : KEYWORDS:

coordination de services et de services web, orchestration, procédé, workflow. services and web services coordination, orchestration, process, workflow.

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

2

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

1. Introduction Les industriels développent des logiciels de plus en plus gros, couvrant différents domaines de compétence. Pour construire de tels logiciels, il est indispensable d’utiliser le savoir-faire des spécialistes de ces différents domaines, et donc d’utiliser des services développés par ces spécialistes. Ces services peuvent être des applications patrimoniales, des applications commerciales (COTS: Commercial Off The Shelf Software), des services web, des applications locales ou distantes, développés par l’entreprise elle-même ou par des partenaires. Les services utilisés sont souvent conçus pour être autonomes : ils ne se connaissent pas entre eux. Ils peuvent également être écrits dans des langages différents, s’exécuter sur différents systèmes d’exécution, et utiliser différents moyens de communication. La construction de ces logiciels complexes nécessite une méthodologie claire, permettant de composer, de contrôler et de coordonner de manière flexible les services différents et hétérogènes formant ces logiciels. Etant donnée l’importance commerciale de ces logiciels complexes, plusieurs travaux de recherche ont abordé ce thème (Arkin 2002, Andrews et al. 2003, Arkin et al. 2002, Satish 2001, Leymann 2001). La solution proposée par la plupart de ces travaux consiste à modéliser le logiciel à réaliser par un procédé gérant la coordination des tâches et des opérations fournies par ce logiciel. La technologie des procédés logiciels a été un thème de recherche très actif dans les années 90 (Bandinelli et al. 1994, Bolcer et al. 1996, Conradi et al. 1992, Heimbigner 1992, Estublier et al. 1997, Leymann et al. 1997, Workflow Management Coalition), et a graduellement été adoptée par les entreprises, sous le nom de workflow1, au cours des dernières années. Cependant, les solutions proposées pour gérer la coordination des services à travers un procédé se limitent souvent à la coordination de services web. Elles ne permettent pas de construire un système complet et stable, et le couplage entre le workflow et les services qu’il coordonne est rigide, ce qui complique considérablement le remplacement d’un service par un autre. S’ajoute à cela la difficulté de manipulation, car ces solutions sont souvent de bas niveau, et ne contiennent pas un niveau conceptuel permettant de séparer le procédé de coordination des relations de couplage le liant aux services. Dans cet article, nous présentons une architecture pour la construction de logiciel gérant la collaboration entre plusieurs services différents et hétérogènes, liés à ce logiciel par des moyens de communication hétérogènes. Nous présentons notre plate-forme Mélusine qui permet de construire et d’exécuter de tels logiciels en utilisant cette architecture.

1. Dans la suite de l’article, nous utiliserons indifféremment le terme procédé et workflow.

Mélusine: un environnement de modélisation et de coordination de services

3

La section 2 présente la coordination de services. Elle introduit l’interopérabilité entre services et explique l’importance des workflows pour coordonner les services. La section 3 présente la plate-forme Mélusine développée au sein de notre équipe. La section 4 présente notre proposition d’introduire une couche conceptuelle dans l’architecture du système de coordination, ainsi que le parallèle entre cette couche et l’approche MDA/MDE. Cet article se termine par une présentation des travaux similaires et par une conclusion. 2. La coordination de services Dans ce chapitre, nous présentons l’interopérabilité entre services et la coordination de services à l’aide d’un workflow. 2.1. L’interopérabilité entre services L’interopérabilité est la capacité pour deux ou plusieurs logiciels ou composants, se trouvant éventuellement sur différentes machines, de communiquer, d’échanger des données et d’utiliser les données échangées (IEEE 1990). Les industriels ont besoin de faire interopérer plusieurs services afin d’automatiser la production. Auparavant, cette interopérabilité se limitait aux logiciels d’une même société. Aujourd’hui, elle a besoin de s’étendre afin de faire interopérer des services appartenant à différentes sociétés. La technologie des services web, qui permet de communiquer entre services à travers le web, a été développée dans cet objectif. Néanmoins, la gestion de l’interopérabilité entre services doit permettre la communication entre de multiples services utilisant des technologies différentes, comme des services locaux à l’entreprise ou des services distants basés sur différents protocoles (RMI, JNDI, services web,…). Ces services doivent cependant rester inchangés. Nous pouvons, par exemple, imaginer un scénario de gestion de voyages, ce scénario fait interopérer plusieurs services appartenant à : (1) une agence de voyage, (2) une compagnie aérienne, (3) une réservation de logements et (4) une location de voitures. Ces services peuvent être hétérogènes, et se baser sur des moyens de communications hétérogènes. L’interopérabilité entre ces services doit permettre la communication entre eux, tout en gardant l’indépendance et la cohérence de chacune d’eux. 2.2. Un workflow pour coordonner des services Les procédés logiciels ont pour objectif la modélisation et l’automatisation partielle d’activités2 au travers desquelles les logiciels sont conçus, développés et maintenus ; c’est-à-dire des activités créatives complexes incluant des acteurs humains. Les concepts et la technologie des procédés logiciels fut un sujet de recherche actif au 2. Une activité est une étape du procédé lors de laquelle une action est exécutée.

4

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

début des années 90 (Bandinelli et al. 1994, Bolcer et al. 1996, Conradi et al. 1992, Heimbigner 1992). Un modèle de workflow est une description abstraite et de haut niveau de la coordination, elle est souvent graphique. Cette description de haut niveau permet, même à des non-spécialistes, de comprendre facilement la coordination modélisée, de la modifier et de la faire évoluer. Le moteur de workflow se charge d’exécuter le modèle, tout en tenant compte des contraintes de la plate-forme sous laquelle il s’exécute. Pour exécuter un modèle le moteur crée une instance de modèle de workflow. Le moteur de workflow peut gérer l’exécution simultanée de plusieurs instances du même modèle de workflow, ce qui permet le passage à l’échelle ainsi qu’une bonne réutilisation des modèles de workflow. Un système de workflow est un ensemble d’outils, contenant au moins un éditeur de modèles et un moteur. Définitions 1. Quelques concepts essentiels dans le domaine des procédés Sous une forme simplifiée (enchaînement rigide d’activités simples), et sous le nom de workflow, cette technologie est utilisée pour l’automatisation de tâches, d’opérations et de transactions internes à une entreprise, ce qui simplifie et rationalise le procédé de production. Sous cette forme, les workflows furent graduellement adoptés par les entreprises pour automatiser le procédé d’exécution et le rendre plus efficace (Leymann et al. 1997, Estublier et al. 1997, Workflow Management Coalition). Récemment, plusieurs travaux de recherche ont abordé le thème de la coordination de services (Arkin 2002, Andrews et al. 2003, Arkin et al. 2002, Satish 2001, Leymann 2001). La plupart de ces travaux ont proposé d’utiliser des workflows pour gérer la collaboration entre services, ce qui a introduit le concept d’orchestration de services. L’orchestration permet de définir l’enchaînement de services selon un canevas prédéfini, et de les exécuter à travers des « scripts d’orchestration ». Ces scripts sont souvent représentés par des procédés métier ou des workflows inter/intra-entreprise. Ces scripts décrivant souvent l’interaction entre services en identifiant les messages échangés et les séquences d’invocation de service (Service Oriented Enterprise, Peltz 2003). Les formalismes de description de modèle de workflow proposent le plus souvent des constructions permettant de décrire des flots de contrôle séquentiels et parallèles, gérés à l’aide de structures de contrôle variées (if, for, switch, repeat…). Un modèle de workflow peut donc décrire l’orchestration de services, et séparer ainsi la logique d’exécution à gros grain (le modèle) de son implémentation (Figure 1). L’implémentation de ce workflow est réalisée par les services, orchestrés par ce workflow. Le modèle de workflow peut facilement être modifié ou étendu sans réécrire la totalité du code applicatif de bas niveau.

Mélusine: un environnement de modélisation et de coordination de services

Procédé de gestion de voyages workflow

services

Commander un voyage

Donner les disponibilités

Service Web Agence de voyage

Annuler l’opération Choisir un itinéraire ou annuler

Service Web Compagnie aérienne

Réserver les places

5

Réserver logement Louer une voiture

Service Location de Voitures

Figure 1. Orchestration de services à l’aide d’un workflow. Les workflows ont eu un certain succès dans les entreprises grâce aux avantages qu’ils offrent, tels que : la possibilité de modifier facilement le modèle de procédé à l’aide d’un éditeur de modèles ; l’intégration de services hétérogènes ; la réutilisation de l’implémentation d’activité et du procédé d’exécution ; le passage à l’échelle pour le logiciel de gestion de collaboration entre services. Si auparavant les workflows étaient suffisants pour des services internes à une entreprise, aujourd’hui, les systèmes d’information d’entreprise à base de workflow doivent s’étendre pour couvrir la collaboration entre entreprises (Hu et al.2003). Il existe aujourd’hui plusieurs formalismes de modélisation de workflow. La plupart de ces formalismes définissent un workflow comme un enchaînement d’activités simples ou complexes, une activité complexe étant une activité composée d’autres activités simples ou complexes. Certains formalismes ne couvrent que l’orchestration des services web, d’autres permettent d’orchestrer plusieurs types de services. Dans certains formalismes il est possible de spécifier statiquement ou dynamiquement les services orchestrés. Pour les services statiques, l’identité et le comportement sont connus à l’avance et figés dans la description du workflow. Les services dynamiques permettent la prise en compte d’acteurs découverts et intégrés au workflow au moment de l’exécution. Rares sont les formalismes qui couvrent la persistance et la reprise sur panne ou qui permettent la supervision (monitoring) de l’exécution du procédé afin de voir l’état d’avancement. Il est rare également de trouver un formalisme de modélisation de workflow permettant la modification dynamique du procédé en cours d’exécution, ce qui nous donnerait la possibilité de modifier l’orchestration des services durant l’exécution du modèle de procédé. Un des problèmes majeurs de ces formalismes est la rigidité du couplage entre le workflow et les services orchestrés, ce qui complique beaucoup le remplacement d’un service par un autre. Dans la section suivante nous abordons ce problème, et nous présentons notre solution en décrivant l’architecture que doit respecter un système de coordination de services hétérogènes. Pour cela nous présentons notre plate-forme Mélusine, qui est à la fois un environnement de conception, permettant de construire des logiciels respectant cette architecture et un environnement d’exécution offrant un moteur pour exécuter ces logiciels.

6

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

3. La plate-forme Mélusine Nous présentons dans ce chapitre notre plate-forme Mélusine, qui est une plateforme permettant de concevoir et d’exécuter des systèmes de coordination de services hétérogènes via un workflow. A la différence des autres formalismes, Mélusine nous permet d’orchestrer plusieurs types de services et pas seulement des services web. Dans Mélusine, un service peut être local ou distant, et peut même être un autre procédé. Ces services peuvent être spécifiés statiquement ou dynamiquement en cours d’exécution. La plate-forme Melusine couvre la persistance et la reprise sur panne. Elle contient des outils de visualisation permettant la supervision de l’exécution, ainsi que la modification dynamique de l’orchestration pendant l’exécution. Mélusine nous permet de concevoir des logiciels ayant une architecture composée de trois couches principales : la couche de coordination, la couche médiateur, et la couche services. Nous décrivons dans ce chapitre cette architecture, et nous expliquons les raisons qui nous ont amenés à une telle architecture, et notre conviction à proposer cette architecture à l’ensemble des systèmes de coordination de services hétérogènes. 3.1. La couche de coordination Mélusine sépare la couche de coordination de la couche services. La couche de coordination définit l’enchaînement des services participants, elle se divise en une couche de workflow contenant un modèle de workflow exécutable, et une couche d’adaptateurs qui se chargent de faire le lien entre les activités du workflow et les services chargés de l’exécution (dans la Figure 2 nous n’avons pas représenté l’adaptateur correspondant à chacune des activités pour simplifier l’image). Procédé de gestion de voyages couche de coordination

workflow

adaptateurs

Commander un voyage

Donner les disponibilités

Adaptateur

couche services

Service Web Agence de voyage

Annuler l’opération Choisir un itinéraire ou annuler

Réserver les places

Adaptateur

Service Web Compagnie aérienne

Réserver logement Louer une voiture Adaptateur

Service Location de Voitures

Figure 2. La couche de coordination Notre workflow est modélisé dans un langage de description graphique APEL (Estublier et al. 1998, Estublier et al. 1996, Estublier et al. 1999). Ce langage nous permet de décrire les procédés en décrivant les activités et la façon dont elles s’enchaînent, les produits3 utilisés par les activités, les responsables de chaque

3. Un produit est une donnée virtuelle, produite, transformée et consommée par les activités.

Mélusine: un environnement de modélisation et de coordination de services

7

activité, les flots de données et les ports4. Dans la Figure 3, nous présentons à droite un exemple de procédé modélisé en APEL, et à gauche le méta modèle d’APEL. +subActivities 0..n Activity

+entryPort

Port

0..n Role

1

DataFlow

1 0..n

+exitPort 0..n +desktop 1

0..n

0..n 0..n Product

0..n Attribute 0..n

0..n 1 Product Type

Figure 3. Le méta modèle d’APEL et un exemple de procédé modélisé en APEL Dans notre équipe, nous avons défini un langage qui nous permet de décrire les adaptateurs (Lestideau 2003). Les adaptateurs ont pour fonction de décrire en quoi consiste une activité du workflow en terme d’exécution des services, et de permettre aux services d’agir sur l’instance du workflow en manipulant le procédé, les activités et les produits. Ainsi, une activité du workflow peut, à travers l’adaptateur, lancer l’exécution d’un ou de plusieurs services. Un service peut, à travers l’adaptateur, créer, détruire ou modifier un produit du workflow, ou modifier le modèle de workflow, comme par exemple ajouter une activité et la lier par des flots de données aux activités du processus, ou supprimer une activité du processus ainsi que son flot de données. La Table 1 donne un sous-ensemble des instructions de notre langage de construction d’adaptateurs. Création de produit Destruction de produit Modification de produit Création d’activité Suppression d’activité Création de flot de données Suppression de flot de données Création de procédé Envoie d’un produit entre deux ports

newProduct(nomProduit, nomTypeProduit); destroyProduct(nomProduit,nomPort); $activity.port.produit.attribut = "nouvelle valeur"; newActivity(nomActivité, typeActivité); destroyActivity(nomActivité); newDataFlow(nomPortDepart, nomActivitéDépart, nomPortArrivé, nomActivitéArrivée); destroyDataFlow(nomPortDepart, nomActivitéDépart, nomPortArrivé, nomActivitéArrivée); newProcess(nomProcess, nomPortEntrée, listeProduit); $(nomActivité). sendTo($nomActivité.nomPortDepart.nomProduit, $nomActivité.nomPortArrivé);

Table 1. Un sous-ensemble d’instructions du langage de construction d’adaptateurs Mélusine permet la supervision de l’exécution, ainsi que la modification dynamique du procédé, grâce à la réflexivité de ses éléments, ce qui nous facilite la gestion des 4. Les ports sont les interfaces de l'activité, ils définissent et contrôlent la communication entre l'activité et le monde extérieur.

8

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

erreurs. Nous pouvons par exemple, en cas de problème lors de l’exécution, vouloir ajouter une activité de débogage (“Interroger Administrateur”) entre les deux activités A et B (Figure 4). Cet ajout d’activité se traduit dans notre langage par les lignes : $activity = newActivity(“Interroger Administrateur”, InterractionAct); newDataFlow($A.end, $A, $activity.begin, $activity); newDataFlow($activity.end, $activity, $B.begin, $B);

Figure 4. Exemple de l’ajout d’une activité de débogage Ainsi, notre couche de workflow peut être modifiée dynamiquement, ce qui la rend très flexible. 3.2. Le médiateur L’utilisation des workflows pour gérer la collaboration entre services permet, d’automatiser le procédé d’exécution. Plusieurs langages, tels que BPML - Business Process Modeling Language (Arkin 2002), BPEL4WS - Business Process Execution Language for Web services (Andrews et al. 2003), WSCI - Web Services Choreography Interface (Arkin et al. 2002), ont été proposés pour orchestrer les services web. Ces langages ne couvrent que la partie modélisation du procédé du logiciel. Les liens entre ce procédé et les services web participant au logiciel se font manuellement au moment de la construction du logiciel, ce qui demande beaucoup de temps et d’effort, ainsi que beaucoup de connaissance (Orriëns et al.2003). Ces liens sont alors codés dans le modèle de procédé, ce qui rigidifie la liaison entre le procédé et les services participants. Le besoin d’implémenter une activité par un nouveau service implique de modifier le modèle de procédé. L’utilisation des services distants et des services web impose de nouvelles contraintes sur les logiciels de collaboration entre services, tels que la gestion de la disponibilité des services et de la fiabilité de la connexion réseau. Les logiciels de collaboration entre services ont, en conséquence, besoin de contrôler dynamiquement les liens entre le procédé et les services qui l’implémentent, afin de pouvoir substituer un service par un autre en cas de besoin (Hu et al. 2003). La substitution d’un service par un autre n’est pas une opération évidente, surtout quand les services utilisés n'emploient pas les mêmes moyens de communication. La collaboration devrait alors être gérée en faisant abstraction des moyens de communication, ce qui signifie la séparation entre la couche de coordination et la communication avec les services utilisés.

Mélusine: un environnement de modélisation et de coordination de services

9

Pour répondre à ces besoins, nous avons identifié dans notre proposition une couche médiateur, qui permet de faire le lien entre les activités du workflow et leurs implémentations en terme de services réalisant ces activités (Figure 5). Procédé de gestion de voyages couche de coordination

workflow

adaptateur couche médiateur

couche services

Commander un voyage

Donner les disponibilités

Adaptateur

Annuler l’opération Choisir un itinéraire ou annuler

Réserver les places

Réserver logement Louer une voiture Adaptateur

Adaptateur

rôles Service Location de Voitures

proxies wrappers services

Service Web Agence de voyage

Service Agence de voyage

Service Web Air France

Service Web Compagnie aérienne

Figure 5 : Les trois couches : coordination, médiateur, et services Nous identifions dans la couche médiateur les « rôles » et les « proxies ». Un rôle est un service abstrait offrant un certain nombre de fonctionnalités. Il peut être vu comme la description d’un service requis par le logiciel. Chaque activité du workflow peut appeler un adaptateur à un moment donné. L’adaptateur contient la séquence d’appels de fonctionnalités des rôles qui sont sensés implémenter l’activité (Figure 5). Les contrats de coordination s’appuient donc sur les rôles, et non pas directement sur les services ce qui rend l’évolution du logiciel global plus facile.

Figure 6. Procédé de gestion de voyages modélisé en APEL Le Code 1 illustre un exemple d’adaptateur, cet adaptateur définit deux rôles : "airline" et "travelAgency". Lorsque l’activité "ReserverPlaces" démarre (Figure 6), l’adaptateur récupère le produit "itineraireID" du poste de travail (desktop) de l’activité, il invoque la méthode "reserveSeat" du rôle travelAgency, en lui passant en paramètre le produit récupéré. Le résultat de cette méthode est envoyé par la

10

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

méthode "reserveSeat" au rôle "airline". Cette méthode retourne un résultat qui est stocké dans la variable "detailsValue". L’adaptateur crée alors un nouveau produit "detailsVoyage" dans le poste de travail (desktop) de l’activité, à qui il affecte la valeur de "detailsValue". Et finalement il envoie ce nouveau produit du desktop vers le port "end" de l’activité, afin que cette activité se termine en envoyant ce produit à l’activité suivante. activity ReserverPlaces { components { airline: airlineRole at SERVER ; travelAgency: travelAgencyRole at SERVER ; } case $(this).isActive( ) : { Vector reservationID = travelAgency.reserveSeat($this.desktop.itineraireID); String detailsValue = airline.reserveSeat(reservationID); $this.desktop.detailsVoyage = $newProduct("detailsVoyage", "detailsType" ); $this.desktop.detailsVoyage.value = detailsValue; $(this).sendTo( $this.desktop.detailsVoyage, $this.end); } }

Code 1. Adaptateur se déclenchant lorsque l’activité ReserverPlaces devient active Chaque rôle est lié à un service (local ou distant : RMI, services web…) implémentant les fonctionnalités offertes par ce rôle. Lorsque le service est distant, cette liaison entre le service et le rôle est faite à travers un « proxy » et un « wrapper » qui se chargent d’adapter les fonctionnalités offertes par le service aux fonctionnalités demandées par le rôle (« Service Agence de voyage » dans la Figure 5). Dans le cas des services web, la liaison se fait directement entre le proxy et le service web, dans ce cas là pas besoin de wrapper. Quand le service est local, et fait sur mesure, il n’a pas besoin d’intermédiaire pour adapter ses fonctionnalités à celles demandées par le rôle. Ce service est alors directement lié au rôle, c’est le cas du service « Service Location de Voitures » dans la Figure 5. La communication entre le proxy et le wrapper, et entre le proxy et le service web est géré par la plateforme Mélusine. Ainsi, le concepteur du logiciel de collaboration entre services n’a pas à gérer cette communication. Un rôle définit, de manière abstraite, les fonctionnalités d’une catégorie de services. Le concept de rôle permet donc de regrouper les services similaires, et en fonction du contexte d’exécution, il est possible de choisir l’exécutant le plus adéquat. Cette structure permet la substitution d’un service implémentant ce rôle par une autre, et cela sans modifier le modèle de procédé ni les adaptateurs, il suffit de

Mélusine: un environnement de modélisation et de coordination de services

11

préciser, à l’exécution, lequel des services implémentera le rôle. Dans le cas des services web, chaque service est décrit par une interface (en WSDL) différente et suppose que l’utilisateur du service web envoie des messages conformes à sa spécification en WSDL, et selon le protocole de communication spécifié. Le changement de service web, même pour un service équivalent, mais décrit par une interface WSDL différente, impose la réécriture du service, ce qui est très coûteux (Aragao et al. 2003). L’utilisation des adaptateurs pour appeler les fonctionnalités des rôles implémentant l’activité permet également une grande flexibilité, du fait qu’on peut employer le rôle dans plusieurs adaptateurs, et qu’on peut modifier l’adaptateur facilement pour avoir une exécution différente. Nous avons présenté dans ce chapitre l’architecture à trois couches des systèmes de coordination de services, conçus à l’aide de notre plate-forme Mélusine. Néanmoins, notre expérience nous a montré que cette architecture, bien que très puissante pour la construction de logiciels de coordination de services hétérogènes, n’est pas suffisante pour gérer les applications à base de procédé métier. Dans la section suivante, nous expliquons les raisons de cette insuffisance, et nous présentons notre solution qui consiste a ajouter une quatrième couche à notre architecture. Nous présentons également le parallèle entre cette couche et l’approche MDA/MDE. 4. La couche conceptuelle et les Domaines Métiers Imaginons une entreprise de fabrication d’appareils électriques. Pour gérer la production d’un nouvel appareil A1, l’entreprise a mis en place un BPM (Business Process Model) modélisant le procédé métier de cette entreprise. Ce procédé est interne à l’entreprise, il contient les concepts et le « savoir-faire » de l’entreprise : il ne doit pas être visible à l’extérieur de l’entreprise. Dans la Figure 9 nous trouvons, dans le procédé métier de l’entreprise, le concept de « décision », qui se traduit dans l’application par l’organisation d’une réunion entre les directeurs des différents services de l’entreprise, pour décider de la spécification de l’appareil. Ceci exige de lancer un procédé de disponibilité de ces directeurs, et un procédé de gestion de voyages, ces deux procédés ne font pas partie du procédé métier de l’entreprise. Nous voyons à travers cet exemple que les workflows dont nous avons parlé dans la section précédente, et qui gèrent la collaboration entre services, ne sont pas nécessairement des procédés métiers. Certains de ces procédés servent uniquement à spécifier la composition et les échanges de données entre les différents services. Nous appelons ces workflows « les procédés élémentaires », car ils sont destinés à réaliser une fonction précise ; ils peuvent être publiés et réutilisés par des entreprises même si elles sont concurrentes.

12

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

Il s’agit donc de deux niveaux différents, le niveau conceptuel ou métier, contenant la logique de l’application, et le niveau coordination, contenant les procédés élémentaires, implémentant cette logique. Il est donc important de séparer ces deux niveaux, afin d’extraire la partie conceptuelle du logiciel. Ceci nous permet de créer un espace métier réduit à l’essentiel, moins sensible aux évolutions, et donc très stable. Pour cela, nous avons identifié une couche située au-dessus de la couche des procédés élémentaires, nous appelons cette couche « la couche conceptuelle » ou « la couche métier ». Ce qui nous donne une architecture constituée de quatre couches : la couche conceptuelle (métier), la couche de coordination, la couche du médiateur, et la couche des services (Figure 9). Cette vision nous permet de suivre une approche MDA (Model Driven Architecture), de relever le niveau d’abstraction, d’analyser les besoins et de modéliser le domaine métier de l’entreprise. 4.1. L’approche dirigée par les modèles (MDE : Model Driven Engineering) Le but de l’approche MDA (Model Driven Architecture) / MDE est de se concentrer sur l’élaboration de modèles de haut niveau d’abstraction et de favoriser les approches transformationnelles paramétriques vers les « plates-formes techniques ». Les modèles manipulés dans le MDE sont de natures très diverses. Afin d’organiser et de structurer tous ces modèles, l’OMG a défini une architecture appelée « Architecture à quatre niveaux » (Bézivin et al. 2002, D’Souza 2001, Siegel 2002, Siegel et al. 2001, Soley et al. 2000). 4.2. Parallèle entre notre niveau conceptuel et l’approche MDA/MDE Notre niveau métier est structuré selon les quatre niveaux de l’OMG (Figure 7). Chaque niveau se compose de deux parties : procédé et application. Dans la partie application, nous avons le modèle de l’application qui se place au niveau modèle (niveau M1 de l’OMG). Le modèle de l’application contient les concepts de l’entreprise, tels que le concept d’appareil, d’équipe, de réunion. Ces concepts sont modélisés conformément à un méta-modèle décrit en UML (niveau M2 de l’OMG). Les instances de ces concepts sont des entités abstraites qui représentent les objets réels de l’entreprise, tels que l’appareil A1, la réunion des responsables d’équipes pour la production de A1, l’équipe A, l’équipe B… Dans la partie procédé, nous avons le modèle de procédé, qui se place au niveau modèle (niveau M1 de l’OMG). Il est modélisé conformément au méta-modèle de procédé décrit en UML (niveau M2 de l’OMG). Dans notre exemple (Figure 7), le niveau M1 contient le modèle de procédé de production d’un nouvel appareil. Le « procédé de production du nouvel appareil A1 » (niveau M0 de l’OMG) est une instance du modèle de procédé. Ce procédé pilote les instances de l’application.

Mélusine: un environnement de modélisation et de coordination de services

13

niveau métier niveau MOF « M3 »

Le MOF Le méta-modèle de procédé

Le méta-modèle UML

+subActivities 0..n Act ivity

+entryPort

Port

0..n Role

niveau méta-modèle « M2 »

1

ModelElement

DataFlow

1

ElementOwnership

0..n

Visibility : VisibilityKind

+exitPort

Names pace

0..n +desktop

0..n

1

0..n 0..n

ElementReference Visibility : VisibilityKind alias : Name

Product

GeneralisableElement

Generalisation

0..n 0..n

Attribute 0..n

1 Product Type

est conforme à

Package

Modèle de l’application

Production d’un nouvel appareil Décision

est conforme à

synchroniseurs

Modèle de procédé

niveau modèle « M1 »

0..1

Employé nom

Reunion date lieu

Production

Equipe nom

appareil Responsable nom

LAppareil

est instance de est instance de

est instance de

Instance de l’application

Instance de procédé Production du nouvel appareil A1

Réunion

niveau instances du modèle (le monde réel) « M0 »

Décision pilotage pour la Production A1 production A1 A1 correspondance

appareil A2 Réunion

appareil A1

équipe A

définition appareil A2

équipe B

appareil A3 appareil A2

équipe C

appareil A1

synchroniseurs

Figure 7 : Architecture à 4 niveaux de la couche conceptuelle 4.3. Pilotage via des synchroniseurs Le procédé pilote l’application à travers des « synchroniseurs ». Ces relations de pilotage entre l’instance procédé et l’instance de l’application sont des instances des relations établies entre le modèle de procédé et le modèle de l’application. Mélusine offre une interface permettant d’établir les correspondances au niveau modèle entre le procédé et l’application. Chaque synchroniseur est lié à une relation de correspondance. Un langage a été défini pour éditer les synchroniseurs qui précisent la sémantique du pilotage (Figure 8). Ce langage permet au synchroniseur de créer, détruire ou modifier un ou plusieurs objets. Il permet également de préciser à quel moment le synchroniseur sera exécuté (au moment d’invoquer une certaine méthode, par exemple). Dans notre exemple (Figure 7 et Figure 9), un synchroniseur a été conçu pour préciser la manière dont l’activité « Décision pour la production A1 » pilote l’application. Ce synchroniseur est appelé lorsque cette activité démarre, il crée dans l’application un objet réunion, représentant la réunion dans laquelle la production de l’appareil A1 va être discutée. Dans le procédé, l’activité « Décision pour la production A1 » crée un produit « A1 » qui est un objet Java envoyé à l’activité suivante. Une correspondance est

14

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

établie entre ce produit « A1 » du procédé, et l’objet « appareil A1 » de l’application, qui contient tous les paramètres nécessaires à la production de A1 ; ces paramètres sont spécifiés lors de la réunion. Cette correspondance au niveau M0, est une instance de la correspondance établie au niveau modèle M1, entre l’objet « L’appareil » appartenant au procédé, et la classe « appareil » appartenant à l’application. Cette correspondance est gérée par un synchroniseur, qui traduit les changements effectués sur « A1 » par ce qui leur correspond dans « appareil A1 ». Notamment l’envoie de A1 au responsable de l’activité de « Production A1 » dans le procédé, se traduit par l’envoie d’une copie de l’objet appareil A1 à travers le réseau vers le poste de travail de la personne responsable de la production de ce produit.

Figure 8. Edition d’un synchroniseur 4.4. Adaptateurs Les objets de l’application disposent d’adaptateurs similaires à ceux de la couche de coordination. A travers ces adaptateurs chaque objet du domaine métier peut agir sur les services participants, soit en exécutant les procédés élémentaires, soit en appelant directement un rôle afin de lancer l’exécution de ses fonctionnalités. Nous avons vu dans notre exemple (Figure 9), que grâce aux synchroniseurs, l’activité « Décision pour la production A1 » a créé un objet « Réunion appareil A1 ». Pour organiser cette réunion, la méthode de création de l’objet « Réunion appareil A1 » lance un adaptateur, qui démarre le procédé élémentaire de gestion de disponibilité des employés, afin de préciser la date de la réunion en fonction des disponibilités des participants. Ensuite, il démarre le procédé élémentaire de gestion de voyages, afin d’organiser les voyages des participants vers le lieu de la réunion.

Mélusine: un environnement de modélisation et de coordination de services

15

Nous avons vu également dans l’exemple qu’une correspondance a été établie entre « A1 » du procédé et « appareil A1 » de l’application. Grâce à cette correspondance, le transfert de A1 entre les deux activités engendre l’envoie d’une copie de l’objet « appareil A1 » à travers le réseau vers le poste de travail du responsable de production de cet appareil. La réception de l’objet « appareil A1 » sur ce poste lance un adaptateur qui démarre le procédé de production qui coordonne le service de production propre a l’entreprise. Le même adaptateur pourrait toutefois démarrer un service de production local, en appelant directement les fonctionnalités du rôle représentant le service de production, comme cela est illustré dans la Figure 9 pour la production d’un autre type d’appareils « appareil A2 ». procédé

synchroniseurs

Production du nouvel appareil A1 Décision pilotage pour la Production A1 production A1 A1 correspondance

application Réunion

appareil A2 Réunion

équipe A

définition appareil A2

équipe B

appareil A3 appareil A2

appareil A1

équipe C

Métier

appareil A1

adaptateurs

Procédé de gestion de Procédé de gestion de disponibilité des employés voyages

Procédé de production

coordination adaptateurs

Adaptateur

rôles Service Agenda

Service de Production

médiateur proxies wrappers

services Service Web Agence de voyage

Service Web Compagnie aérienne

Service de Production

services

Figure 9 : Architecture à quatre couches de Melusine 4.5. Evaluation de notre approche Dans notre proposition nous avons séparé « l’application », constituée des éléments qui constituent le métier de l’entreprise, des éléments qui implémentent certaines des activités métier. L’application est un noyau minimal qui ne contient que les concepts métier de l’entreprise. Nous avons défini également « le procédé » qui pilote les concepts métier se trouvant dans l’application. Le procédé n’a pas d’autre fonction que de manipuler les concepts contenus dans l’application, il est donc à son tour minimal. Nous avons défini le niveau métier comme étant constitué de l’application et du procédé. Le niveau métier, bien que réduit à l’essentiel, est exécutable indépendamment des autres couches. Il peut s’exécuter en mémoire, en créant des instances de concepts, pilotées par le procédé, c’est une exécution abstraite.

16

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

Nous avons réalisé dans notre équipe différents logiciels basés sur l’architecture proposée (Figure 9), à l’aide de l’outil Mélusine. L’un de ces logiciels est APEL V6. APEL est un environnement de gestion de procédé qui est utilisé dans notre équipe pour toutes les applications guidées par un procédé (Estublier et al. 1998). Le travail de notre équipe autour d’APEL a commencé au début des années 90. Six versions successives ont été construites. La version APEL V5 a été construite au début des années 2000, en combinant des services à travers un système de messagerie JMS (Java Message Service), la Figure 10 illustre cette architecture. Dans cette version il y a, au total, 968 classes avec environ 160K lignes de code. M o te u r d e p ro c é d é G e s tio n n a ire d e re s s o u rc e

S y s tè m e d e c o m m u n ic a tio n à m e s s a g e (J M S )

G e stio n n a ire d e s d o c u m e n ts

G e s tio n n a ire des agendas

E d ite u r d e docum ent

agenda

Figure 10. Architecture d’APEL V5 APEL V6 est basée sur l’architecture proposée dans cet article (Figure 11), il est composé d’un niveau conceptuel (métier) contenant 16 classes, et un ensemble de services participants constitués de 362 classes. p ro céd é

ressou rce

D esk to p

P erso n n e

co u ch e co n cep tu elle : D om ain es M étiers

A c tiv ité

G e stio n n a ir e d e re sso u r ce

G e stio n n a ire d es a g e n d a s

co u ch e serv ices

D o n n ée

A d a p ta teu r

A d a p ta teu r

co u ch e m éd ia teu r

R esp o n sab le

G e stio n n a ir e d es d o cu m en ts

M o te u r d e p r o c éd é

A genda

E d ite u r d e d o c u m en t

Figure 11. Architecture d’APEL V6 Ceci s’explique par le fait qu’APEL V6 est exécuté sur le moteur de Mélusine, qui propose beaucoup de services de base. APEL V6 peut évoluer beaucoup plus facilement qu’APEL V5, car les services sont indépendants, il est simple de changer un service par un autre à condition qu’il réponde au même contrat fonctionnel (implémente le même rôle). Nous voyons à travers cette comparaison que la construction de logiciels en respectant l’architecture proposée dans cet article, permet de créer un espace métier,

Mélusine: un environnement de modélisation et de coordination de services

17

très évolutif et de taille considérablement inférieure à celle des logiciels habituels gérant le travail des grandes entreprises. Ce qui rend cet espace métier moins sensible aux évolutions, et donc très stable. 5. Travaux similaires Divers langages sont actuellement en cours de développement pour répondre aux besoins d’implémentation des procédés collaboratifs intra ou inter entreprises. Les principaux standards que l’on peut citer comme candidats sérieux à la normalisation de l’orchestration des procédés collaboratifs sur le web sont : XLANG de Microsoft, WSFL (Web Services Flow Language), et BPML (Kadima et al. 2003). Cependant, ces formalismes ne sont pas exécutables. XLANG (Satish 2001) et WSFL (Leymann 2001) ne couvrent que l’orchestration de services web, BPML (Arkin 2002) permet d’orchestrer plusieurs types de participants. WSFL ne couvre pas la persistance et la reprise sur panne, XLANG le fait dans son implémentation BizTalk Server. BPQL est une interface pour contrôler l’exécution et interroger l’état d’instances de procédé métier écrit en BPML ; XLANG et WSFL ne permettent pas la supervision de l’exécution du procédé pour voir l’état d’avancement. Aucun de ces formalismes ne couvre la modification dynamique du procédé en cours d’exécution. Ces formalismes de modélisation de workflow, et d’autres tels que BPEL4WS (Andrews et al. 2003), et WSCI (Arkin et al. 2002), ne couvrent que la partie modélisation du procédé du logiciel. Les liens entre ce procédé et les services participant au logiciel se font manuellement. Ces liens sont alors codés dans le modèle de procédé, ce qui rend la liaison entre le procédé et les services participants rigide. Le besoin d’implémenter une activité par un nouveau service implique de modifier le modèle de procédé. Nous avons présenté dans cet article notre plate-forme Mélusine, qui est une plateforme permettant de concevoir et d’exécuter des systèmes de coordination de services hétérogènes via un workflow. Mélusine est une plate-forme exécutable, elle gère la persistance et la reprise sur panne, et permet la supervision de l’exécution du workflow ainsi que sa modification dynamique. Nous avons montré la structure que devrait avoir un tel logiciel, cette structure est composée de trois couches principales : la couche de coordination, la couche médiateur, et la couche services. Nous avons présenté par la suite une quatrième couche, qui est la couche conceptuelle (la couche métier), et nous avons expliqué l’importance de cette couche dans les systèmes de coordination utilisant le savoir-faire de plusieurs entreprises différentes. Les liens entre le procédé et les services participant au logiciel se font via une couche de médiateur, ce qui ajoute beaucoup de flexibilité. Nous avons présenté également le langage que nous avons défini afin de faciliter la réalisation des adaptateurs qui lient la couche de coordination et la couche conceptuelle à la couche de médiateur. Pour exécuter ces adaptateurs, la plate-forme Mélusine utilise la machine à objets étendus (Duclos et al. 2002, EOM), développée

18

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

dans notre équipe. La machine à objets étendus se base sur la technologie de la Programmation Orientée Aspect (Kiczales et al. 1997, Lieberherr et al.2002). Il existe des travaux introduisant la couche médiateur (Hu et al.2003), mais ces travaux sont en cours d’implémentation. L’idée du niveau conceptuel a été évoquée dans un article disant que le modèle conversationnel n’impose pas une architecture précise au procédé métier qui prend les décisions pilotant la conversation. Cet article explique que la gestion de conversation ne fait pas partie du workflow gérant le procédé métier, c’est un sous-système séparé, couplé au workflow (Hanson et al. 2002). Nous prônons de séparer le domaine conceptuel de l’implémentation, en proposant une technologie composant les domaines au niveau conceptuel. Ces travaux sont une généralisation de l’approche des synchroniseurs qu’on utilise pour coupler le procédé et l’application, ils sont présentés dans (Estublier et al. 2003). 6. Conclusion Nous avons présenté dans cet article nos travaux sur la coordination de services via un workflow. Les systèmes existants de coordination de services via un workflow se limitent souvent à la coordination de services web. Ils ne permettent pas de construire un système complet et stable, et le couplage entre le workflow et les services qu’il coordonne est rigide. Nous proposons une architecture et un environnement permettant de réaliser des logiciels via la collaboration de plusieurs services différents et hétérogènes, liés à ce logiciel par des moyens de communication hétérogènes. Pour cela nous avons présenté notre plate-forme Mélusine, qui est à la fois un environnement de conception, permettant de construire des logiciels respectant cette architecture et un environnement d’exécution offrant un moteur pour exécuter ces logiciels. Nous avons utilisé notre plate-forme Mélusine pour développer différents logiciels pour plusieurs entreprises. Notre environnement est utilisé industriellement depuis des années. Les expériences accumulées prouvent la validité de notre approche, en particulier l’intérêt de séparer le niveau métier de l’implémentation et le gain considérable en matière de réutilisation. 7. Bibliographie Andrews T., Curbera F., Dholakia H., Goland Y., Klein J., Leymann F., Liu K., Roller D., Smith D., Thatte S., Trickovic I., Weerawarana S., IBM specification: Business Process Specification Language For Web Services, version 1.1, 2003. Aragao V., Fernandes A., « Conflict Resolution in Web Service Federations », ICWS-Europe, 2003, LNCS2853 (109-122) Arkin A., Askary S., Fordin S., Jekeli W., Kawaguchi K., Orchard D., Pogliani S., Riemer K., Struble S., Takacsi-Nagy P., Trickovic I., Zimek S., Web Services Choreography Interface (WSCI) 1.0, W3C, 2002.

Mélusine: un environnement de modélisation et de coordination de services

19

Arkin A., Intalio, Business Process Modeling Language, November 13, 2002. Bézivin J. et Blanc X., MDA : vers un important changement de paradigme en génie logiciel, Développeur Référence, Juillet 2002. Bézivin J. et Blanc X., Promesses et interrogations de l'approche MDA, Développeur Référence, Septembre 2002. Bandinelli S., Barga M., Fuggetta A., Ghezzi C., Lavazza L., SPADE: An Environment for Software Process Analysis, Design and Enactment, Software Process Modeling and Technology, Research Studies Press, Taunton, 1994. Bolcer G., Taylor. R., « Endeavors: A Process System Integration Infrastructure », 4th. Int’l Conference on Software Process ICSP4, December 2-6, 1996. Conradi R., Fernstrom C., Fuggetta A., Snowdown B., « Towards a Reference Framework for Process Concepts », EWSPT’92, 2nd European Workshop on Software Process Technology, Trondheim, Norway, September 1992. D’Souza D., « Model-Driven Architecture and Integration: Opportunities and Challenges », February 2001, Available at www.kinetium.com Duclos F., Estublier J., Sanlaville R., « Une Machine à Objets Extensibles pour la Séparation des Préoccupations », Journées Systèmes à Composants Adaptables et extensibles, Grenoble, France, October 2002 Estublier J., Amiour M., Dami S., « Building a Federation of Process Support System », Conference on Work Activity Coordination and Cooperation (WACC), ACM SIGSOFT, Vol. 24, No. 2, San Francisco, USA, February 1999. Estublier J., Cunin P.Y., Belkhatir N., « Architectures for Process Support System Interoperability », ICSP 5, pp. 137-147, Chicago, Illinois, USA, June 1998. Estublier J., Dami S.,Amiour M., « APEL: a Graphical Yet Executable Formalism for Process Modeling », Automated Software Engineering, ASE journal. Vol. 5, Issue 1, 1998. Estublier J., Dami S.,Amiour M., « High level process modelling for SCM », 7th. International Workshop on Software Configuration Management (SCM7), Boston, 19-20 May 1997 Estublier J., Dami S., « Process Engine Interoperability: An experiment », In C. Montangero, editor, European Workshop on Software Process Technology (EWSPT5), LNCS, Nancy, France, October 9-11 1996. Springer Verlag, pages 43--61. Estublier J., Villalobos J., Le A.T., Sanlaville S., Vega G., « An Approach and Framework for Extensible Process Support System », 9th European Workshop on Software Process Technology (EWSPT 2003), September 2003, Helsinki, Finland. EOM (Extended Object Machine): http://www-adele.imag.fr/EOM/ Heimbigner D., « The ProcessWall: a Process State Server Approach to Process Programming », ACMSDE, December 1992. Hu J., Grefen P., « Conceptual framework and architecture for service mediating workflow management », Information & Software Technology, 45 (13): 929-939, 2003.

20

Revue d'Ingénierie des Systèmes d'Information. Volume 12, Numéro 3/2005

Hanson J., Nandi P., Levine D., « Conversation-enabled Web Services for Agents and eBusiness », IC, 2002 (791-796). Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. Kadima H., Monfort V., Les Web services - Techniques, démarches et outils : XML-WSDLSOAP-UDDI-Rosetta-UML, Dunod/01 Informatique, 2003. Kiczales G., Lamping J., Mendhekar A., Maeda C., Lopes C.V., Loingtier J.-M., Irwin J., « Aspect-Oriented Programming », Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP ‘97), Lecture Notes in Computer Science vol.1241, Springer-Verlag, June 1997. Le A.T., Fédération : une architecture logicielle pour la construction d'applications dirigée par les modèles, Thèse de doctorat, Université Joseph Fourier, Janvier 2004. Lestideau V., Modèles et environnement pour configurer et déployer des systèmes logiciels, Thèse de doctorat, Université de Savoie, Decembre 2003. Leymann F., Roller D., « Workflow-based application », IBM System Journal, vol.36, No.1, pp102-123, 1997 Leymann F., « Web Services Flow Language (WSFL 1.0) », IBM Software Group, May 2001 Lieberherr K., Orleans D., Ovlinger J., « Aspect-Oriented Programming with Adaptive Methods », Communications of the ACM, Vol. 44, No. 10, pp. 39-4 1, October 2001. Orriëns B., Yang J., Papazoglou M., « Model Driven Service Composition », ICSOC, 75-90, 2003. Peltz C., « Web services orchestration, a review of emerging technologies, tools, and standards », Hewlett Packard, Co. January 2003 Satish T., « XLANG: Web Services for Business Process Design », Microsoft, 2001. Service Oriented Enterprise, http://www.serviceoriented.org/web_service_orchestration.html Siegel J., « Making the Case: OMG's Model Driven Architecture », Available at http://www.sdtimes.com/news/064/special1.htm, October 2002 Siegel J. and the OMG Staff Strategy Group, « Developing in OMG's Model Driven Architecture (MDA) », Available at ftp://ftp.omg.org/pub/docs/omg/01-12-01.pdf, November 2001 Soley R. and the OMG staff, « Model-Driven Architecture », White paper, Draft 3.2. Available at www.omg.org, November 2000 Workflow Management Coalition, Interface 1: Process Definition Interface, WfMC TC-1016, August 1996