Modèle et langage de composition de services Philippe Ramadour, Myriam Fakhri LSIS (Laboratoire des Sciences de l’Information et des Systèmes) Université d’Aix-Marseille Domaine universitaire de Saint Jérôme Avenue Escadrille Normandie Niemen 13397 MARSEILLE Cedex 20 {prénom.nom}@lsis.org RÉSUMÉ.
L’évolution récente des systèmes d’information (S.I.) est marquée par des changements profonds d’architectures et d’usages et le paradigme service s’impose dans leur développement. Ce paradigme fait émerger une nouvelle vision du développement des S.I., dans laquelle un système est construit en composant des services. Aussi, définir, concevoir et réaliser une composition de services deviennent des sujets essentiels. Cet article propose une vision orientée ingénierie de la composition de services où une composition est un artefact qui a son propre cycle de vie et qui peut être réutilisé et adapté à tout moment. Cet article présente un modèle de composition à différents niveaux d’abstraction. Basé sur le concept de patron, le modèle associe chaque composition à un but (le but que permet de satisfaire la composition) et un contexte (le contexte dans lequel la composition est adaptée). Un langage pour découvrir, réutiliser et adapter des compositions de services est aussi proposé. ABSTRACT.
The evolution of Information Systems (I.S.) is characterized by major changes in architecture and usages and the service paradigm gains acceptance in their development. This paradigm leads to the emergence of a new vision of development of I.S., in which a system is built by composing services. Thus, specification, design and implementation of a service composition become essential issues. This paper proposes an engineering-oriented vision of service composition where a composition is an artifact that has its own life cycle and can be reused and adapted at any time. The paper presents a model of composition at different levels of abstraction. The model is based on the concept of pattern in order to relate each composition to a goal (the goal that the service composition satisfies) and to a context (the context in which the composition is adapted). Some operators are also defined for supporting discovery, reuse and adaptation during the process of satisfying a requirement. MOTS-CLÉS :
Ingénierie de systèmes d’information à base de services, Composition de services, Patron de composition de services, Orchestration de services KEYWORDS:
Service-Oriented information systems engineering, Service composition, Service composition pattern, Service orchestration
1. Introduction L’évolution des S.I. est marquée par des changements profonds d’architectures et d’usages. Ainsi, dans le domaine de l’ingénierie des S.I., le paradigme service s’impose et son intérêt s’est accru avec l’émergence des services web et de SOA (Papazoglou et al., 2003), (Erl, 2009), (OASIS, 2008). L’approche service considère les services comme des ressources logicielles autonomes qui peuvent être publiées et partagées, découvertes et assemblées dynamiquement pour produire des applications. À la manière de (Dijkman et al., 2004), (Tsai, 2005), (Yanchuk et al., 2005), (Perepletchikov et al., 2008), nous considérons que cette approche vise une plus grande flexibilité, une meilleure réutilisabilité des éléments qui composent un système et un alignement plus fort entre le S.I. et le métier. La mise en œuvre de ce paradigme soulève de nouvelles problématiques. La première concerne le processus de développement d’applications et la remise en cause du cycle traditionnel basé sur la séparation des activités d’ingénierie (« design-time ») et d’exécution (« run-time ») (Tsai, 2005), (Agarwal et al., 2008). Par ailleurs, l’approche service conduit à une nouvelle vision selon laquelle un S.I. est un ensemble de services et de compositions de services. Dans ce contexte, définir, concevoir et réaliser des compositions de services deviennent des sujets essentiels. Dans la littérature, la composition de services est le plus souvent abordée dans le contexte des services web où elle est généralement définie par des signatures de fonctions, des entrées/sorties... Dans cet article, nous défendons une approche, appelée PA! (Pattern-Based Approach for Composition of Services), de type ingénierie de la composition de services où une composition est considérée comme un artefact ayant un cycle de vie et pouvant être décrit à différents niveaux d’abstraction. Cette approche permet d’apporter différentes « vues » d’une composition, notamment au niveau métier (donc sémantique). À partir de besoins métier, il est possible de concevoir une composition de services, c’est-à-dire identifier les services requis et définir l’ordonnancement de ces services en alignement avec la logique des processus du métier. Une composition de services doit pouvoir être implantée et exécutée en invoquant et en exécutant des services existants. Considérées comme des artefacts, les compositions de services sont disponibles, réutilisables et adaptables pour répondre à de nouveaux besoins métier. Afin de mettre en œuvre cette vision, nous proposons un modèle de composition de services ainsi qu’un ensemble d’opérateurs permettant de manipuler des compositions existantes pour satisfaire des besoins métier. L’article est organisé en 5 sections. La section 2 présente un état de l’art sur les méthodes de composition de services. La section 3 définit un cadre général pour l’ingénierie de la composition de services dans la méthode PA!. La section 4 présente le modèle de description de composition de services et la section 5 définit un ensemble d’opérateurs permettant de manipuler des compositions de services.
L’utilisation de ces opérateurs est détaillée dans la section 6 pour construire une composition de services répondant à un besoin métier.
2. État de l’art sur les méthodes de composition de services On définit une composition de services comme un ensemble de services ordonnancés dont l’invocation et l’exécution fournissent un résultat pour répondre à un besoin. Dans le domaine des méthodes de composition de services, deux approches principales sont proposées. L’approche « dynamique », dans laquelle une composition de services est un processus qui est initié par une requête, consiste à découvrir, sélectionner et assembler dynamiquement les services satisfaisant la requête. Cette approche est aussi appelée composition « à la volée » ; elle met en œuvre des techniques de « matching » entre les descriptions des services (fonction, entrée/sortie du service) et la formulation de la requête. Les approches (Bansal et al., 2003), (Brogi et al., 2008) et (Ambite et al., 2002) sont de ce type. L’approche dynamique répond à des besoins de flexibilité et d’adaptation. Elle permet en effet de construire une nouvelle composition adaptée à chaque requête et prenant en compte les services disponibles au moment de la composition. Utilisée principalement dans le contexte des services web, elle devient difficile à mettre en œuvre si l’espace de recherche est important et si la requête initiale exprime un besoin complexe. À l’opposé, l’approche « statique » considère une composition de services comme un artefact prédéfini. Cet artefact décrit l’ordonnancement des services qui doivent être invoqués. Cette approche est aussi appelée approche « workflow » dans la mesure où la composition de services est vue comme un processus dont certaines activités sont réalisées en invoquant des services (Piccinelli et al., 2002), (W3C, 2002) et (IBM, 2003). Cette approche, adaptée à des applications stables, dont la logique métier est complètement définie au moment de la conception, ne permet pas de prendre en compte les spécificités de la requête initiale. Certaines approches ont ainsi introduit des mécanismes d’expression de la variabilité dans la modélisation des processus (Casati et al., 2001), (Benatallah et al., 2003) et (Sirin et al., 2005). Par exemple, dans (Sirin et al., 2005), une composition de services est exprimée à deux niveaux (abstrait et concret). Une composition abstraite est alors réutilisable pour des requêtes similaires et qui présentent par exemple une différence sur les préférences de l’utilisateur. Enfin, certaines approches (Orriëens et al., 2003), (Chun et al., 2004) et (Rolland et al., 2007) adoptent une vision ingénierie de la composition de services mais elles n’exploitent pas les compositions de services comme des artefacts disponibles réutilisables et adaptables. La méthode de composition de services PA! considère une composition de services comme un artefact qui a un cycle de vie, qui peut être décrit et géré à
différents niveaux d’abstraction, qui peut être réutilisé dans d’autres compositions et enfin qui peut être adapté au moment de son utilisation.
3. Ingénierie de la composition de services Nous considérons un système orienté service comme un ensemble de services disponibles et accessibles à travers des annuaires de type UDDI (OASIS, 2005). C’est en composant des services que l’on construit des applications pour répondre aux besoins d’un métier. L’objectif de l’approche PA! est de proposer une méthode pour la composition de services. Cet article présente le modèle de description de composition, les opérateurs et le processus pour la manipulation de ces compositions de services. Dans cette recherche, nous avons une vision « ingénierie de la composition » ; une composition de services peut être ainsi considérée selon deux dimensions : une dimension « produit » où elle est un artefact qui peut être représenté, réutilisé et adapté, et une dimension « processus » où elle est élaborée pour répondre à un besoin selon une démarche mettant en œuvre des activités d’analyse, de conception et d’implantation. Cette vision ingénierie de la composition permet la réutilisation et l’adaptation des compositions de services. Ainsi, à la fois, les services et les compositions de services sont des entités disponibles et accessibles pour répondre à des besoins métier. 3.1. L’orientation but Alors qu’aujourd’hui la recherche de services et la description de compositions se font à un niveau « fonctionnalité » et « entrées/sorties », nous pensons qu’il est nécessaire de raisonner à un niveau intentionnel et métier (Ramadour et al., 2010). Nous utilisons la notion de but (« business goal ») pour formuler les besoins en services. Les buts métier sont intéressants dans le cadre de la composition pour de nombreuses raisons : – Ils permettent l’expression de nombreuses formes de besoins, par exemple des besoins complexes dont la réalisation va nécessiter de nombreux services avec un ordonnancement complexe mais aussi des besoins élémentaires dont la satisfaction ne nécessite qu’un seul service. – Les buts complexes peuvent être décomposés sur plusieurs niveaux pour être réduits en un ensemble de buts plus simples. Ce mécanisme de réduction, appliqué à des buts, permet d’exprimer des alternatives de décomposition de buts, chaque alternative étant plus adaptée qu’une autre à un certain contexte. L’expression de ces alternatives répond au problème de variabilité et de flexibilité inhérent aux systèmes d’information actuels. – Plus spécifiquement au niveau de la composition de services, le processus de réduction d’un but complexe en sous-buts plus élémentaires permet d’identifier
progressivement les services à composer (ce sont les services permettant de réaliser les buts atomiques). 3.2. Cycle de vie de la composition de services Le cycle de vie d’une composition de services est initialisé avec un nouveau besoin. Il comporte quatre phases : – La phase d’analyse de la composition : cette phase est centrée sur l’analyse du besoin exprimé sous la forme d’un but. Les besoins et donc les buts peuvent être complexes ; ils doivent alors être décomposés pour être réalisés. À ce niveau, la composition de services est exprimée par un ensemble de sous-buts à réaliser ; elle est appelée composition abstraite. Elle ne fait référence à aucun service ni à aucune logique métier. Elle est décrite par un graphe de composition qui contient pour un but (le besoin) un ensemble de sous-buts permettant de le réaliser. – La phase de conception de la composition : cette phase définit une orchestration des services requis pour réaliser le besoin. À ce niveau, la composition est exprimée sous la forme d’un « workflow » et elle est appelée une composition orchestrée. Elle ne fait référence à aucun service mais elle décrit un processus avec ses activités, certaines devant être réalisées avec des services. La forme de cette composition est un processus BPMN (White et al., 2008). – La phase d’implantation de la composition : cette phase consiste à décrire un processus exécutable BPEL4WS (IBM, 2003) ou WSBPEL (OASIS, 2007) qui référence sous forme d’entrées/sorties des spécifications de services publiées dans un annuaire de type UDDI (OASIS, 2005). À ce niveau, la composition est dite exécutable. La forme de cette composition est un processus BPEL. – La phase d’exécution de la composition : cette phase exécute une composition en invoquant et en exécutant des services particuliers. L’exécution produit un résultat en réponse au besoin. À ce niveau, la composition est appelée une trace de composition ; elle décrit les services effectivement exécutés ainsi que leurs données effectives d’entrées/sorties. Il est important de souligner qu’au-delà d’organiser le processus d’ingénierie de la composition, ces quatre phases structurent une application à base de services avec quatre niveaux d’abstraction gérés explicitement. Ainsi, tous les types de composition (abstraite, orchestrée, exécutable, trace de composition) sont disponibles et réutilisables. L’intérêt des quatre niveaux d’abstraction est double : – Ils permettent de réduire la distance entre le besoin du demandeur exprimé sous la forme d’un but métier et les services mis à disposition par les fournisseurs. Il s’agit ainsi d’assurer l’alignement entre le métier et les composants logiciels. – Ils permettent d’augmenter le degré d’indépendance d’un besoin avec les services disponibles et donc la flexibilité. Par exemple, une composition abstraite décrit un ensemble de buts à réaliser en faisant abstraction des services existants. Une telle composition autorise au moment de l’exécution plusieurs
ordonnancements, chacun étant contextualisé et permettant de la flexibilité en termes de choix de services. Les quatre niveaux de description de composition avec leurs caractéristiques sont présentés dans le tableau 1 ci-dessous. Phase du cycle de vie
Niveau d’abstraction
Artefact
Notation
Analyse
Abstrait : indépendant des services et indépendant des processus métier
Composition de services abstraite
Graphe de composition de buts
Conception
Orchestré : indépendant des services
Composition de services orchestrée
Processus orchestré (BPMN)
Exécutable : dépendant Composition de spécifications de Implantation de services services publiées dans un exécutable UDDI Exécution
Trace : dépendant des services disponibles à l’exécution
Trace de composition
Processus exécutable (BPEL) Trace de l’exécution d’un processus (ensemble de services exécutés avec les valeurs des entrées/sorties)
Tableau 1. Phases du cycle de vie et niveaux d’abstraction de la composition
3.3. De la composition aux patrons de composition En génie logiciel, les patrons sont définis comme des solutions à des problèmes récurrents de conception (Gamma et al., 94). Nous utilisons des patrons pour rendre les compositions accessibles, réutilisables et adaptables. Un patron de composition fournit une solution, c’est-à-dire une composition de services (qui peut être abstraite, orchestrée, exécutable ou une trace) pour réaliser un certain but dans un certain contexte. Dans l’approche PA!, les compositions de services, sont disponibles, accessibles et réutilisables sous forme de patrons. L’intérêt essentiel des patrons est d’associer à chaque composition le besoin métier auquel elle répond, c’est-à-dire le but qu’elle permet de réaliser, et le contexte dans lequel elle est réutilisable. Le but et le contexte permettent ainsi de décrire les compositions de services du point de vue de l’usage et d’en assurer l’adaptation. En fonction du niveau d’abstraction de la composition fournie par un patron, nous distinguons quatre types de patrons : les patrons de composition abstraite, les patrons de composition orchestrée, les patrons de composition exécutable et les patrons de trace de composition. Nous détaillons et nous illustrons dans la section suivante ces quatre types de patrons.
4. Modèle de patrons de composition de services Tous les types de patrons associent un but et un contexte à une composition. Sur la base du modèle de (Prat, 97), nous structurons un but au moyen d’une action et d’un objet. Par exemple, dans le domaine de la santé : But 1 : (effectuer)action (une radiologie vasculaire)objet But 2 : (interpréter)action (une radiologie vasculaire)objet La notion de contexte a été abordée dans de nombreux travaux (Najar et al., 2009), (Carrillo-Ramos et al., 2009), (Dey, 2001). Dans PA!, l’expression d’un contexte est composée d’assertions contextuelles. Celles-ci sont typées (assertions fonctionnelles, non-fonctionnelles, temporelles, …) et combinées au moyen de connecteurs logiques (AND, pour la conjonction d’assertions contextuelles, et NOT, pour la négation d’assertions contextuelles). Une assertion contextuelle est définie comme suit : AC = (T, F) où T est le type de l’assertion (temporelle, financière, …) et F sa formulation. Ces deux notions sont basées sur des concepts figurant dans une ontologie contextuelle (cf. figure 1). Item contextuel Connecteur contextuel AND NOT Assertion contextuelle
Environnementale
Non-‐fonctionnelle
Culturelle
Qualitative
Spatiale
Disponibilité
Légale
Coût (temps)
Financière
Coût (argent)
Temporelle
Sécuritaire Fonctionnelle
Utilisateur
Règle métier
Rôle Compétence Propriété
Figure 1. Ontologie contextuelle (extrait)
Pour le domaine de la santé, nous donnons deux exemples de contexte : Contexte 1 : (Type de patient = malade admis aux urgences)rôleUtilisateur AND NOT(État = grave)propriétéUtilisateur Contexte 2 : (Type de patient = hospitalisé)rôleUtilisateur AND (État = grave)propriétéUtilisateur Les patrons de composition abstraite fournissent des compositions abstraites, c’est-à-dire des graphes de composition de buts. Un patron de ce type est décrit par un but, un contexte et un graphe de composition satisfaisant ce but. Le graphe définit un ensemble de sous-buts, ceux devant être réalisés pour satisfaire le but du patron, pouvant être atomiques ou complexes. Un sous-but complexe peut être le but d’un autre patron qui fournit alors un graphe de composition le satisfaisant. Plusieurs patrons de ce type peuvent avoir le même but ; ils fournissent alors différents graphes de composition le satisfaisant, chacun étant adapté à un certain contexte. Les patrons de ce type sont particulièrement intéressants lorsque le besoin est exprimé à un haut niveau d’abstraction : ils permettent alors de réduire la complexité de ce besoin et, donc, d’aider à le réaliser avec des services. Par ailleurs, lorsque plusieurs patrons ont le même but, leur contexte guide le choix d’une solution en fonction du contexte courant. Considérons un service d’imagerie au sein d’une clinique. La figure 2 ci-dessous fournit deux patrons ayant le même but « (Prendre en charge)action (une échographie)objet » mais fournissant deux graphes de composition satisfaisant ce but, chacun adapté à un contexte particulier. Dans la représentation graphique, les rectangles ombrés correspondent à des buts complexes et les rectangles simples à des buts atomiques. Patron de composition abstraite #1 (Prendre en charge)action But (une échographie)objet (Type de patient = Contexte hospitalisé)rôleUtilisateur
Patron de composition abstraite #2 (Prendre en charge)action But (une échographie)objet (Type de patient = Contexte externe)rôleUtilisateur
(Émettre)action (la facture)objet
(Diffuser)action (l’interprétation de l’imagerie)objet
(Encaisser)action (le paiement)objet
Figure 2. Deux exemples de patrons de composition abstraite
(Interpréter)action (une imagerie)objet
(Exécuter)action (l’acte d’imagerie)objet
(Fixer)action (un rendez-‐vous)objet
Graphe de composition
(Prendre en charge)action (une échographie)objet
(Transmettre)action (la facture)objet
(Diffuser)action (l’interprétation de l’imagerie)objet
(Interpréter)action (une imagerie)objet
(Exécuter)action (l’acte d’imagerie)objet
(Vérifier)action (la disponibilité d’un service)objet
Graphe de composition
(Prendre en charge)action (une échographie)objet
Les patrons de composition orchestrée fournissent des fragments de processus BPMN, c’est-à-dire des processus composés de tâches (activités atomiques) et de sous-processus (activités complexes). Dans ces processus, les activités sont ordonnancées conformément aux liens définis dans BPMN. Un patron de ce type est décrit par un but, un contexte et un ensemble d’activités. Plusieurs patrons de ce type peuvent avoir le même but et le même ensemble d’activités ; ils fournissent alors des organisations différentes de cet ensemble, chacune étant adaptée à un contexte. Soit le but « (Diffuser)action (l’interprétation de l’imagerie)objet » du domaine de la santé. Il peut par exemple être réalisé par l’ensemble d’activités suivantes : « Envoi du résultat au médecin », « Confirmation de la réception » et « Enregistrement du formulaire d’évaluation ». Cet ensemble peut être organisé de deux façons différentes selon que le médecin recevant les résultats est associé à la clinique ou non. La figure 3 ci-dessous montre les deux patrons de composition orchestrée correspondants. But Contexte Processus orchestré But Contexte Processus orchestré
Patron de composition orchestrée #1 (Diffuser)action (l’interprétation de l’imagerie)objet (Disponibilité de l’interprétation ≥ 30 minutes après l’acte)temporelle AND (Type de médecin = associé à la clinique)propriétéUtilisateur Envoi du résultat au médecin
Confirmation de la réception
Enregistrement du formulaire d’évaluation
Patron de composition orchestrée #2 (Diffuser)action (l’interprétation de l’imagerie)objet (Disponibilité de l’interprétation ≥ 30 minutes après l’acte)temporelle AND NOT(Type de médecin = associé à la clinique)propriétéUtilisateur Envoi du résultat au médecin
Enregistrement du formulaire d’évaluation
Confirmation de la réception
[Si non-‐reçu]
Figure 3. Deux exemples de patrons de composition orchestrée
Les patrons de composition exécutable fournissent des fragments de processus BPEL dans lesquels figurent des activités d’invocation de services. Ces invocations sont caractérisées par l’activité à réaliser et par un ensemble d’entrées/sorties. Les patrons de trace de composition fournissent, sous forme de trace, des compositions de services exécutées. Une trace comprend, entre autres, la liste des services effectivement invoqués ainsi que les valeurs de toutes leurs entrées/sorties. On peut ainsi exploiter ces patrons pour constater que le même processus exécutable BPEL a invoqué deux services différents pour réaliser une même fonctionnalité.
Nous utilisons la définition générale suivante d’un patron :1 P = (B, C, (A+, (ES+, S*)?)?, Sol) où P est un patron de composition, B est un but, C est un contexte, A est une activité, ES est une entrée/sortie, S est un service, Sol est la solution fournie (elle peut-être un graphe de composition GC, un processus orchestré PO, un processus orchestré ne contenant que des activités atomiques et dont tout ou partie des entrées/sorties sont valuées PV ou bien une trace de l’exécution d’une composition de services TC). Ainsi, précisément, la définition d’un patron en fonction du niveau d’abstraction de la composition de services qu’il encapsule est : – Pour les patrons de composition abstraite : (B, C, GC), – Pour les patrons de composition orchestrée : (B, C, A+, PO), – Pour les patrons de composition exécutable : (B, C, A+, ES+, PV), – Pour les patrons de trace de composition : (B, C, A+, ES+, S+, TC). Nous définissons enfin un concept de regroupement de patrons : une classe de patrons de composition de services CP(N, B) regroupe tous les patrons de niveau d’abstraction N satisfaisant le but B. 5. Langage de manipulation de compositions de services Nous venons de voir qu’un patron de composition de services P peut se formuler comme suit : P = (B, C, (A+, (ES+, S*)?)?, Sol). Ces patrons vont être utilisés pour répondre à des besoins métier. Par souci d’homogénéité, un besoin à satisfaire sera formulé comme suit (cf. partie 6) : Bes = (B, C?, A*, ES*, S*). Ainsi, traiter un besoin revient principalement à rapprocher le but et le contexte du besoin avec ceux des patrons disponibles. Nous présentons ainsi dans cette partie les notions de similarité de buts, de compatibilité de contextes ainsi que les opérateurs de manipulation de compositions de services. Il est intéressant de noter que l’usage d’une ontologie linguistique (composée de termes et de liens tels que la synonymie, l’hyperonymie ou l’hyponymie) peut améliorer et simplifier ces calculs de similarité et de compatibilité (Farrar et al., 2003). 5.1. Similarité de buts Nous définissons la similarité de buts comme suit : Soient B1 et B2 deux buts. L’expression de B1 est : ActionB1 ObjetB1. L’expression de B2 est : ActionB2 ObjetB2. Le but B2 est similaire au but B1 si ActionB1 ≡ ActionB2 et ObjetB1 ≡ ObjetB2.
1
Nous utilisons les opérateurs réguliers conventionnels suivants : ? pour l’optionalité (0 ou 1), * pour la répétition optionnelle (0 à ∞) et + pour la répétition obligatoire (1 à ∞).
L’opérateur ≡ résulte de l’usage de l’ontologie linguistique mentionnée plus haut afin de vérifier si 2 termes ou 2 groupes de termes sont sémantiquement équivalents. Selon l’ontologie linguistique utilisée, cet opérateur pourra soit être évalué à {VRAI, FAUX} soit être évalué à [0..1] (retour d’un poids indiquant le taux d’équivalence sémantique). Par exemple, le but « (Effectuer)action (une radiologie vasculaire)objet » est similaire au but « (Réaliser)action (un acte d’imagerie)objet » si l’on suppose que l’ontologie linguistique contient un lien de synonymie entre les termes « effectuer » et « réaliser » et un lien d’hyponymie entre les objets « radiologie vasculaire » et « acte d’imagerie ». En revanche, le but « (Effectuer)action (une radiologie vasculaire)objet » n’est pas similaire au but « (Interpréter)action (une radiologie vasculaire)objet » (les 2 actions n’étant pas liées dans l’ontologie linguistique). 5.2. Compatibilité de contextes Nous définissons la notion de compatibilité de contextes comme suit : Soient C1 et C2, deux contextes. On définit Pos(C1) l’ensemble des assertions contextuelles apparaissant dans C1 et n’étant pas opérandes d’un connecteur NOT. On définit Nég(C1) l’ensemble des assertions contextuelles apparaissant dans C1 et étant opérandes d’un connecteur NOT. On définit de la même façon Pos(C2) et Nég(C2). Par définition, Pos(C1) et Nég(C1) sont disjoints. De même, Pos(C2) et Nég(C2) sont disjoints. C1 est compatible avec C2 si : – ∀A ∈ Pos(C1), ∃A’ ∈ Pos(C2) | A ≅ A’, – ∀A ∈ Nég(C1), ∃A’ ∈ Nég(C2) | A ≅ A’. Cette définition amène plusieurs remarques : – L’opérateur ≅ définit l’équivalence entre assertions contextuelles : A1 = (T1, F1) et A2 = (T2, F2) sont équivalentes si T1 = T2 et F1 ≡ F2 (l’opérateur ≡ étant le même que l’opérateur utilisé pour le calcul de la similarité de buts). – Le contexte C2 peut contenir plus d’assertions que C1 (C1 ⊆ C2). 5.3. Opérateurs de manipulation de compositions de services Les opérateurs de manipulation sont de 3 types : – Opérateurs de recherche : il s’agit ici de rechercher parmi les patrons disponibles ceux qui satisfont un besoin. – Opérateurs d’opérationnalisation : il s’agit ici de rechercher, à partir d’un patron de composition d’un niveau d’abstraction donné, les patrons du niveau d’abstraction immédiatement inférieur qui « l’opérationnalisent ». – Opérateurs de spécialisation : il s’agit ici, à partir de la solution d’un patron, de construire le fragment de processus métier correspondant.
5.3.1. Opérateurs de recherche Un opérateur de recherche est défini comme suit : – Entrée : un besoin Bes = (B, C?, (A+, (ES+, S*)?)?) où B est un but, C un contexte, A une activité, ES une entrée/sortie et S un service. – Sortie : un ensemble (éventuellement vide) de patrons de composition. – Fonctionnement : une recherche est « interprétée » à un certain niveau d’abstraction N en fonction de la formulation du besoin. Les patrons retournés par l’opérateur ont tous un but similaire au but B et un contexte compatible avec le contexte C. De plus, si la recherche est opérée à un niveau autre qu’abstrait, on peut alors être amené à vérifier, en plus, qu’il y a une bijection entre la liste des activités et/ou la liste des entrées/sorties et/ou la liste des services des patrons retournés avec les listes correspondantes formulées dans le besoin. 5.3.2. Opérateurs d’opérationnalisation L’objectif de cet opérateur est de permettre de « descendre » dans les niveaux d’abstraction de la composition. Par exemple, un patron de composition abstraite peut faire apparaître dans sa solution un graphe de composition. Pour opérationnaliser ce graphe, il faut alors l’organiser. Ceci peut être fait en trouvant les patrons d’orchestration permettant d’organiser les sous-buts en son sein. Un opérateur d’opérationnalisation est défini comme suit : – Entrée : un patron P de niveau d’abstraction N. – Sortie : l’ensemble (éventuellement vide) des patrons de niveau d’abstraction N-1 opérationnalisant le patron P. – Fonctionnement : un patron P de composition abstraite est opérationnalisé par les patrons de composition orchestrée tels que ceux-ci ont un but similaire à celui du patron P et un contexte compatible avec celui du patron P et qu’il y a une bijection entre les activités apparaissant dans leur solution et les sous-buts du patron P. Par analogie, on peut définir l’opérationnalisation de patrons de composition orchestrée et de patrons de composition exécutable. 5.3.3. Opérateurs de spécialisation L’objectif de cet opérateur est de permettre l’assemblage de compositions fournies par des patrons d’un même niveau d’abstraction. Par exemple, un patron de composition abstraite peut faire apparaître dans sa solution un graphe de composition dans lequel peuvent éventuellement apparaître des sous-buts étant euxmêmes complexes et qui doivent donc être décomposés. On peut alors spécialiser ce graphe de composition (et donc, par extension, le patron qui le contient) en cherchant les patrons de composition abstraite ayant pour but le sous-but complexe à décomposer.
L’opérateur de spécialisation repose sur les opérateurs de recherche et d’opérationnalisation et est défini comme suit : – Entrée : un patron P. – Sortie : une composition de services spécialisant celle qui est encapsulée dans le patron P. – Fonctionnement : si P est un patron de composition abstraite, on extrait la composition qu’il encapsule. Pour chaque sous-but complexe apparaissant dans cette composition, on va rechercher et spécialiser un patron de composition abstraite dont le but est similaire au sous-but complexe concerné et dont le contexte est compatible avec le contexte de P. Les compositions fournies par ces patrons sont assemblées avec la composition fournie par P. Par analogie, on peut définir l’opérationnalisation de patrons de composition orchestrée, de patrons de composition exécutable et de patrons de trace de composition. 6. Processus de manipulation de compositions de services Le processus de manipulation de patrons de composition de services est défini comme suit : il prend en entrée un besoin que l’on cherche à satisfaire par une composition de services et fournit, en sortie, une composition de services adaptée. Le niveau d’abstraction auquel cette composition est fournie dépend du déroulement du processus ; cependant, l’objectif usuel est d’arriver à l’obtention d’une composition de services de niveau trace (i.e. au résultat de l’exécution de cette composition). Le processus repose sur les 3 familles d’opérateurs présentées précédemment. Un besoin à satisfaire par une composition de services est défini par : Bes = (B, C?, A*, ES*, S*). Cette définition autorise un utilisateur à formuler son besoin de différentes façons. En fonction de cette formulation, on détermine à quel niveau débute le processus de manipulation. Le processus est présenté à la figure 4 et suit globalement la logique de fonctionnement suivante : – Étape 1 : détermination du niveau d’abstraction N auquel le processus « débute ». Le niveau d’abstraction des patrons considérés au départ dépend de la formulation du besoin à satisfaire Bes. Si le besoin est de la forme Bes(B, C?) alors le processus commence par prendre en compte les patrons de composition abstraite. Si le besoin est de la forme Bes(B, C?, A+) alors le processus commence par prendre en compte les patrons de composition orchestrée. Si le besoin est de la forme Bes(B, C?, A*, ES+) alors le processus commence par prendre en compte les patrons de composition exécutable. Enfin, si le besoin est de la forme Bes(B, C?, A*, ES*, S+) alors le processus commence par prendre en compte les patrons de trace de composition.
– Étape 2 : recherche de patrons au niveau d’abstraction N. Le besoin Bes est utilisé pour rechercher au niveau d’abstraction N le ou les patrons de composition de services, s’il y en a, qui satisfont ce besoin. – Étape 3 : sélection d’un patron. Si l’étape précédente ne fournit aucun patron, le processus va proposer à l’utilisateur de créer lui-même le patron de niveau N satisfaisant son besoin et/ou de recommencer le processus depuis le début en remontant d’un niveau d’abstraction (N ← N + 1), après reformulation du besoin à satisfaire. Si l’étape précédente retourne plusieurs patrons, il est demandé à l’utilisateur d’en sélectionner un, désigné PS. Cette sélection est prise en compte dans l’expression du besoin pour la suite du déroulement du processus (il y a union entre, d’une part, le contexte, les activités, les entrées/sorties et les services spécifiés dans le besoin à satisfaire et, d’autre part, ceux qui figurent dans le patron PS). – Étape 4 : spécialisation du patron PS. Si l’utilisateur le souhaite, le patron PS sélectionné à l’étape précédente est spécialisé. Cette étape peut être réitérée tant que l’utilisateur le souhaite (et tant que la composition fournie contient des sous-buts ou des activités complexes). On teste lors de la spécialisation la cardinalité de l’ensemble de patrons utilisés, comme à l’étape 3, en demandant éventuellement à l’utilisateur de sélectionner ou de créer un patron, qui sera utilisé pour élaborer la composition de services produite par la spécialisation.
Recherche
Recherche
❷
❷ ❸
Spécialisation
❹
❺ Opérationnalisation
Patrons de composition abstraite Recherche
❸
Patrons de composition orchestrée Recherche
❶ Besoin
Opérationnalisation ❺
Recherche
Recherche
❷
❷ Utilisateur
❹ Spécialisation
Patrons de trace de composition Recherche
❸
Opérationnalisation
❺
❸
❹ Spécialisation
Composition exécutable (BPEL)
Trace de composition (liste de services et d’entrées/sorties valuées)
Spécialisation
❹
Composition orchestrée (BPMN)
Composition abstraite (graphe de composition)
– Étape 5 : opérationnalisation du patron PS. Si l’utilisateur le souhaite, on opérationnalise alors le patron PS. On teste là encore la cardinalité de l’ensemble de patrons retournés, comme à l’étape 3, en demandant éventuellement à l’utilisateur de sélectionner ou de créer un patron. On peut alors reprendre le processus en prenant pour base ce patron afin de formuler un nouveau besoin, etc.
Patrons de composition exécutable Recherche
Figure 4. Processus de manipulation de patrons de composition de services
Il est intéressant de noter que les sélections réalisées dans les étapes 3, 4 et 5 permettent notamment l’adaptation du produit (i.e. de la composition de services) créé pendant l’exécution du processus. En effet, lorsqu’un ensemble de patrons nonvide et non-singleton est retourné/utilisé par un opérateur (que ce soit la recherche, l’opérationnalisation ou la spécialisation), l’utilisateur doit en sélectionner un. Cette sélection est guidée notamment par le contexte et permet à l’utilisateur d’adapter finement le résultat fourni. En effet, une telle sélection permet implicitement de préciser/spécialiser/compléter le contexte pris en compte dans la suite du déroulement du processus.
7. Conclusion Cet article a présenté une méthode pour l’ingénierie de la composition de services. La méthode est basée sur quatre niveaux d’abstraction permettant à la fois d’organiser le processus d’ingénierie d’une composition et de structurer une application à base de services. Le niveau abstrait décrit une composition en termes de buts à réaliser, le niveau orchestré décrit une composition en termes d’activités ordonnancées, le niveau exécutable décrit une composition sous la forme d’un processus BPEL et le niveau trace décrit une composition en termes de services effectivement invoqués. En associant un but et un contexte à chaque composition, quel que soit son niveau d’abstraction, les patrons permettent la découverte de compositions, leur réutilisation et leur adaptation. Des opérateurs ont été proposés pour mettre en œuvre ces activités durant le processus de satisfaction d’un besoin. Les grands axes de travail entrepris autour de la méthode PA! portent sur deux dimensions : – Une dimension méthodologique : il s’agit de définir une démarche pour aider à identifier les buts du métier, à mettre en avant la variabilité aux quatre niveaux d’abstraction et à spécifier les patrons. – Une dimension usage : il s’agit de développer une architecture permettant la description, la gestion et la manipulation de compositions de services. Cette architecture devra être couplée avec l’architecture SOA pour la gestion des services. Bibliographie Agarwal V., Chafle G., Mittal S., Srivastava B., “Understanding Approaches for Web service Composition and Execution”, Compute’2008, Bangalore, Karmataka, India, 2008. Ambite J., Barish G., Knoblock C., Muslea M., Minton S., “Getting from Here to There: Interactive Planning and Agent Execution for Optimizing Travel”, 2002.
Benatallah B., Sheng Q., Dumas M., “The Self-Serv Environment for Web Services Composition”, IEEE Internet Computing. 7, p. 40-84, 2003. Bansal S., Vidal J., “Matchmaking of Web Services Based on the DAML-S Service Model”. p. 926-927, New York, USA, 2003. Brogi A., Corfini S., Popescu R., “Semantics-Based Composition-Oriented Discovery of Web Services”. p. 1-39, 2008. Carrillo-Ramos A., Kirsch Pinheiro M., Villanova-Oliver M., Gensel J., Berbers Y., “Collaborating agents for adaptation to mobile users”, Chevalier M., Soule-Dupuy C., Julien C. (Eds.), Collaborative and Social Information Retrieval and Access: Techniques for Improved User Modeling, IGI Global (2009), p. 250-276. Casati F., Shan M.C., “Dynamic and adaptative composition of e-services, Information Systems”, 26(3), p. 143-162, 2001. Chun S., Atluri V., Adam N., “Policy-Based Web Service Composition”, p. 85-92, IEEE Computer Society 2004. Dey A.K., “Understanding and using context”, Personal and Ubiquitous Computing, vol. 5, n°1 (2001), p. 4-7. Dijkman R., Dumas M., “Service-oriented Design: A Multi-viewpoint Approach”, Int. Journal of Cooperative Information Systems, 13(4), pp 337-378, 2004. Erl Th., Service-Oriented Architecture : Concepts, Technology and Design, Prentice Hall, 2009. Farrar S., Langendoen T., “A linguistic ontology for the semantic web”, Glot International Vol. 7, No. 3, March 2003 (97–100). Gamma E., Helm R., Johnson R., Vlissides J., “Design Patterns: Elements of Reusable Object-Oriented Software”, 1994. IBM, BEA systems, Microsoft, SAP AG, Siebel Systems: Business Process Execution Language for Web Services version 1.1, http://www.ibm.com/developerworks/library/specification/ws-bpel/, 2003. Najar S., Sadani O., Kirsch Pinheiro M., Souveyet C., Nurcan S.: “Semantic representation of context models: A framework for analyzing and understanding”, 1st Workshop on Context, Information and Ontologies (CIAO'09), 6th European Semantic Web Conference (ESWC 2009), Heraklion, Greece, (2009), ACM, http://doi.acm.org/10.1145/1552262.1552268. OASIS, Web services Business Process Execution Language (WSBPEL), Version 1.1, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel, 2007. OASIS, Reference Architecture for Service Oriented Architecture Version 1.0, Public Review Draft 1, 23 April 2008, http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.html, 2008. OASIS, Universal Description, Discovery and Integration v3.0.2 (UDDI), http://www.oasisopen.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm, 2005.
Orriëens B., Yang J., Papazoglou M., “Model Driven Service Composition”, Trento, Italy 2003. Papazoglou M. P., Georgakopoulos D., “Service-oriented computing”, Communications of the ACM 46(10), p. 24-28, 2003. Perepletchikov M., Ryan C., Frampton K., Schmidt H., “Formalizing Service-oriented Design”, Journal of Software, Vol. 3, N° 2, February, Academy Publisher, 2008. Piccinelli G., Emmerich W., Zirpins C., Schütt K., “Web-Service Interfaces for InterOrganisational Business Processes - An Infrastructure for Automated Reconciliation”, p. 285-292 , Lausanne, 2002. Prat N., “Goal Formalization and Classification for Requirements Engineering”, p. 145-156 Proc. Of the 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality, Barcelona 1997. Ramadour Ph., Cauvet C., Ferrarini A., “Towards services paradigm: Principles and models”, Int. Conf. on Research and Challenges in Information Systems, RCIS’10, Nice, France 2010. Rolland, C., Kaabi, R., Kraeim, N., “Intentional Services Oriented Architecture”, On ISOA Springer-Verlag, Trondheim, Norway, 2007. Sirin, E., Parsia, B., Hendler, J., “Template-Based Composition of Semantic Web Services”, 2005. Tsai W. T., “Service_oriented System Engineering: A New Paradigme”, Proc. Of the IEEE International Workshop on Service-oriented System Engineering, SOSE, 2005. White S.A., Miers D., BPMN, Modeling and Reference Guide, 2008. W3C, Web Service Choreography Interface (WSCI) 1.0, http://www.w3.org/TR/wsci/, 2002. Yanchuk A., Ivanyrukovich A., Marchese M., “A lightweight Formal Framework for serviceOriented Applications”, ISOC, 2005.
