Perspectives

Les perspectives qui suivent seront développées dans d’autres cadres que celui d’ISL. En effet, si lors de l’invention du langage, la démarche était originale, aujourd’hui de nom-breux travaux traitent de ce problème, le plus souvent sous la forme d’aspects au niveau des classes. Nous ne pensons pas qu’il s’agisse de la même solution. Notre démarche recherche une composition indépendante langage, intègre l’interopérabilité et surtout repose sur des mécanismes de composition associatifs et commutatifs. Néanmoins, nous nous intéressons aujourd’hui à d’autres aspects de la composition en particulier dans le cadre des workflows et des transformations de modèles. Nous avons donc fait le choix de stopper le développement de Noah et le langage a été repris dans plusieurs domaines (IHM, aspects d’assemblages) pour être adapté sous d’autres formes. Pour ma part, j’ai fait le choix de me concentrer sur les modèles de composition (la partie modélisation présentée précédemment est originale en ce sens) et d’appliquer ces modèles à d’autres domaines que les composants.

Dans ce contexte, parmi les extensions des travaux sur les interactions, nous nous inté-ressons à l’introduction d’autres activités pivots qui offriraient donc des comportements différents lors de la composition, avec comme objectif de préserver les propriétés de com-position et de ne pas introduire de redondance. En particulier, la nécessité de pouvoir retourner une valeur à l’appelant alors que la résolution d’une interaction n’est pas terminée, nous amène à introduire une activité "reply". Celle-ci sera étudiée dans un contexte un peu différent dans l’application suivante sur les compositions d’orchestra-tion (cf. §7), mais son exploitation dans un contexte incluant les conditionnelles est une de nos perspectives. De même la gestion des exceptions est une extension que nous envi-sageons par une extension du métamodèleMM4CA.

La formalisation de la composition des aspects selon notre démarche de métamodélisa-tion a été amorcée en associant aux activités les informamétamodélisa-tions "before" ou "after" et en gérant des priorités.

Nous n’avons pas abordé l’appariement entre les points de coupe et leur composition. Or, c’est un des points difficiles de la programmation par aspects qui, de notre point de vue, induit une partition de l’espace en fonction des recouvrements entre les aspects, comme nous l’avons abordé dans la thèse d’Olivier Nano. De récents travaux étendent la défini-tion des points de coupe en introduisant les nodéfini-tions de signatures fournies et requises lors de la définition des advices around[FSJ08]. Nous intégrerions ces points dans notre algorithme au niveau des informations portées par les activités et par la construction d’activités explicitant le partitionnement.

Dans sa thèse Pessemier montre combien le séquencement d’aspects est problématique [Pes07, chapitre 8] ce qui rejoint le besoin de commutativité et d’associativité que nous défendons. Il propose une approche basée sur la structuration des aspects sous la forme de composants et une approche programmative de l’introduction des aspects. De même

6.5. Conclusion et perspectives 121

Nous représentons le code initial de la méthode itsMe par "It’s me".

La composition en AspectJ utilise l’ordre des déclarations (à gauche, le deuxième aspect en jaune est considéré comme prioritaire) tandis que l’approche ISL (à droite) n’introduit pas d’ordre entre les aspects. En particulier, la décomposition proposée pour

ISL ici ne tient pas compte de la précédence d’un before sur un around. Pour cela nous aurions dû écrire une seule règle pour définir l’aspect du haut, par exemple :

X.before1() ;X.a_b1() ;_call ;X.a_a1() ;X.after1()

FIGURE6.12: COMPARAISON DES COMPOSITIONS PAR L’EXEMPLE ENTRE ASPECTJ ET ISL (proceed)

L’absence deproceed dans une partie around d’un advice en AspectJ interdit l’exécution des autresaround.

- Dans cet exemple, nous visualisons en rouge l’absence deproceed dans le 1eraspect en haut, qui est interprété à droite comme l’utilisation d’undelegate. L’absence du proceed dans l’aspect de priorité moindre conduit à la seule disparition de l’appel à la méthode initial. Le comportement dudelegate joue le même rôle quelque soit l’ordre des aspects. - L’absence duproceed dans le deuxième aspect, donc celui de plus forte priorité, a pour conséquence d’"absorber" le premier aspect. Seul les activités du deuxième aspect sont exécutées. Ce comportement est pris en charge par l’opérateurabsorb dans ISL.

Tandis qu’en AspectJ, l’ordre des aspects permet d’exprimer différentes compositions, en ISL, nous avons fait le choix d’une définition d’opérateurs autorisant une composition indépendante des ordres de composition.

FIGURE6.13: COMPARAISON DES COMPOSITIONS PAR L’EXEMPLE ENTREASPECTJETISL (de-legateET ORDRE DE COMPOSITION)

6.5. Conclusion et perspectives 123

dans [PDS05], les auteurs proposent d’expliciter des contraintes sur les aspects et l’ordre entre les aspects et de vérifier que cet ordre respecte bien les contraintes. Est-il possible de concilier une approche déclarative et automatique de composition telle que nous la proposons et impérative comme proposée par FAC-AOKell ou CompAr ? Ce point fait l’objet de nos perspectives en étudiant le même exemple mais dans un monde workflow. Les travaux sur les connecteurs [Car03] mettent en avant la nécessité d’une sépara-tion entre la mise en œuvre des composants et les communicasépara-tions du composant avec son environnement. Jusqu’à présent, les interactions sont basées sur un protocole par envoi de message. Une extension du modèle pour intégrer une communication par évé-nement, sans perdre les propriétés de composition, est à l’étude dans l’équipe autour de Wcomp [CFWBFT+05].

A l’instar des travaux sur les ADLs, il nous semble important de vérifier la cohérence glo-bale du graphe de propagation. Pour l’instant nous ne vérifions que la cohérence locale du graphe des interactions (toutes les interactions locales à un composant sont " compa-tibles "). L’étude sur la cohérence du graphe d’interactions a été amorcée en supposant le graphe d’interaction stabilisé à un moment donné. Les résultats issus des ADLs de-vraient être applicables. Nous nous intéressons à ces problèmes actuellement dans les workflows par transformation vers des algèbres de processus [Pou07] ; ce travail est une de nos perspectives à court terme.

CHAPITRE 7

Composition d’orchestrations

Contexte de recherche et contributeurs

Ce travail a été commencé par le DEA de Clémentine Nemo[Nem06,NBFKR07]. Une ap-proche différente est aujourd’hui suivie par Sébastien Mosser[MBFR08]. Son travail est présenté en perspective de ce chapitre. Une application qui a guidé la réalisation de ce travail vient d’une collaboration avec Johan Montagnat et Tristan Glatard[NGBFM07]. Enfin notons que les origines de ce travail remontent à des remarques de Yves Caseau sur le rapprochement des interactions avec des workflows lors de la revue du projet Rain-bow en 2002 et des réflexions de David Emsellem sur l’application des interactions aux orchestrations de web services. La problématique et les esquisses de solutions propo-sées ici sont issues de nos collaborations dans le cadre de différents projets industriels (Thèse avec DCNS Toulon, Projet RNTL FAROS . . . ). Une plate-forme est en cours de développement pour étayer ces différents points [JMBF07,JMBFN07]. J’ai volontaire-ment circonscrit ce domaine au travail mené dans le cadre du DEA de Clévolontaire-mentine Nemo pour ne pas interférer avec la thèse en cours. Ce domaine est donc plus prospectif que le précédent.

Plan de ce chapitre

Dans un premier temps (cf. §7.1), nous précisons nos objectifs relativement à la compo-sition dans le cadre d’orchestrations ayant des invocations en commun.

La composition d’orchestrations constitue un domaine de composition que nous formali-sons relativement àMM4CA(cf. §7.2).

Nous formalisons alors la composition dans le domaine des orchestrations et développons les propriétés respectées par cette composition (cf. §7.2.8). Nous présentons ensuite la mise en œuvre de cette modélisation (cf. §7.3).

Enfin nous concluons ce chapitre par un retour sur expérimentation et le positionnement de notre travail vis-à-vis d’autres travaux, ce qui nous amène à expliciter nos perspec-tives relativement à ce travail.

7.1 Domaine applicatif et objectifs

Le concept de service est le sujet de définitions très variées. Nous reprenons ici la défi-nition donnée par le consortium Oasis dans [MLM+06]1 : 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 ser-vice description. . . A serser-vice 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. . .

Les interfaces et les données exhibées par le service sont exprimées en termes métiers. Les aspects technologiques ne sont plus essentiels car les services sont autonomes, c’est-à-dire qu’ils sont indépendants du contexte d’utilisation ainsi que de l’état des autres services, et interopèrent via des protocoles standardisés. Un service définit une entité logicielle (e.g., ressource, application, module, composant logiciel, etc.) qui communique via un échange de messages et qui expose un contrat d’utilisation. De façon similaire aux approches par objet ou par composant, l’approche service cherche à fournir un ni-veau d’abstraction encore supérieur, en encapsulant des fonctionnalités et en permettant la réutilisation de services déjà existants. La propriété de couplage faible que cette ap-proche induit est à l’origine des architectures agiles que sont les architectures orientées services.

Les architectures orientés Services (SOA, [MLM+06]) facilitent l’exposition, l’intercon-nexion, la gestion et l’évolution d’applications à base de services. Les orchestrations sont au cœur de ces architectures en supportant la construction d’applications à partir de fonctionnalités de base. Créer des compositions de services signifie ordonner les invo-cations aux opérations, router les messages, modifier les paramètres et gérer les excep-tions. Plusieurs langages de composition de composition de services sont définis (WSCI

[SISM02], WSBPEL [JEA+07], SCUFL [OAF+04]).

Dans le cadre des Services Web, nous nous intéressons plus particulièrement aux orches-trations. Les orchestrations sont définies par le consortium W3C(W3C Glossary) comme "le modèle des interactions que doit respecter un agent Service Web pour atteindre son but". Cependant, même si les orchestrations sont un support à une programmation incré-mentielle par la construction de nouveaux services par assemblages [CP05,BJPK+05], elles n’offrent pas de support à leur propre composition. Ce point est d’autant plus cri-tique que les applications à base de services évoluent très rapidement et que le dévelop-pement collaboratif, en particulier par séparation des préoccupations est indispensable à l’élaboration des gros projets.