Les services sont aussi utilisés comme axes d’échanges entre les sous-systèmes hétérogènes. Dans ce contexte d’utilisation deux points de vues sont possibles :
– Chorégraphie : spécification externe décrivant l’enchaînement des services ;
– Orchestration : réalisation interne des échanges entre services réalisant la chorégraphie. Notre modèle ne fait pas la distinction entre ces deux formes de composition. Nous nous inté-ressons de manière plus générale à la composition de services.
Nous voyons dans cette partie comment s’effectue la conception d’un service composite à travers les approches statiques de la littérature. Nous proposons alors une approche dynamique de la composition de services qui s’appuie sur un modèle de composant dits légers.
4.2.1 Composition de services
Nous avions précédemment le modèle d’un service à travers son interface. Nous voyons à présent comment construire un service à partir de services existants de l’infrastructure. Ce nouveau service est appelé service composite.
La composition d’une interface (I, O) peut être décrite par une fonction F de l’ensemble des points d’entrée I dans une partie de l’ensemble des événements P(O).
La composition de services mettent en jeu la connaissance et l’entrelacement de services. Les services sont particulièrement difficiles à composer pour prendre en compte la gestion des erreurs, de contextes, d’ordonnancement de l’exécution, etc. Nous pouvons voir la composition sous deux angles :
– considérer les éléments de l’infrastructure (services primitifs et services composites) comme des boîtes noires accessibles uniquement via leur interface ; Dans ce cas, se pose le problème d’exécutions multiples de services communs, d’absence de partage du contexte de gestion des erreurs, etc.
– considérer les orchestrations comme des boîtes blanches ; Ce cas suppose une bonne connais-sance des services et des compositions déjà existantes.
Nous voyons dans la section suivante les approches de la littérature pour la composition de services.
4.2.2 Plusieurs approches dans la littérature
Différents formalismes ont été définis pour la composition des services [182] ayant surtout pour but de minimiser le couplage entre les services composites et les services de l’infrastructure. Le résultat d’une orchestration est un nouveau service, ce qui permet la composition récursive d’orchestrations. Outre les approches ad hoc de construction des services composites, des approches formelles permettent la validation de la composition des services en dérivant du langage BPEL4WS des vé-rifications formelles (voir page 55). D’autres approches consistent à améliorer l’expression de la composition en proposant de regrouper la spécification d’une composition dans un module logi-ciel (AO4BPEL), de construire des connecteurs transverses (JAsCo) ou de spécifier de manière déclarative la composition (Self-Serv), enfin de considérer la composition comme un assemblage de composants (SCA).
Cependant, lorsque les compositions de services sont définies statiquement (cas des approches relatives à BPEL), il n’est pas possible d’adapter la liaison à un service. Or, cette adaptation est nécessaire pour sélectionner le service approprié en fonction des choix de l’utilisateur [183].
Il s’agit alors de définir des règles de sélection des services. Les travaux relatifs au web sémantique abordent cette problématique via l’usage d’ontologies [177] qui permettent de déterminer en fonction d’une tâche les services les mieux adaptés ou en cas d’échec pour substituer de nouveaux services répondant mieux aux exigences utilisateur [184]. En fonction des approches, il s’agit de prendre en compte soit l’adaptation par l’utilisateur, soit l’auto-configuration [178].
4.2.3 Notre modèle de composant léger LCA
L’adaptation réactive en l’informatique ambiante intervient au niveau la distribution et la présence intermittente des dispositifs. Pour garantir et maîtriser le cycle de vie logicielle, il s’agit de ne pas subir directement et sans contrôle à priori les variations de l’environnement et de l’infrastructure.
Pour ce faire, nous interdisons, dans notre modèle de composant, les mécanismes de distribu-tion. Cela implique que les composants sont exécutés dans un même espace d’adressage et dans un même processus. Leurs interactions sont alors réduites aux mécanismes les plus simples et les plus efficaces : flot de contrôle et de données. Les composants n’embarquent alors plus de gestion non-fonctionnelle liée aux intergiciels. Leur impact mémoire est réduite. Nous qualifions pour ces raisons ce modèle de léger.
4.2.3.1 Assemblage de composants légers
Dans notre modèle LCA (Lightweight Component Architecture)1, l’application est un assemblage
de composants.
Structure d’un assemblage de composants. Un assemblage est une entité d’exécution qui
comprend deux ensembles : l’ensemble des composants et l’ensemble des connecteurs. L’ensemble
des composants contient les identifiants des composants participant à l’assemblage.
L’ensemble des connecteurs contient les connecteurs entre ces composants. Chaque connecteur est représentée par un couple de ports (ˆo, i) tel que i soit un point d’entrée et ˆo un événement.
Figure 4.2 – Assemblage de composants
La figure 4.2 représente un exemple d’assemblage. L’assemblage est représenté par un rectangle aux traits discontinus. Il est modélisé par deux ensembles (tel qu’il est illustré à gauche de la figure) : α – qui correspond aux composants participant à l’assemblage –, et β – qui correspond aux connecteurs entre ces composants. Les éléments de l’ensemble α sont des identifiants des composants (A, B, C et D) et ceux de l’ensemble β sont des couples de ports tels que (A.ˆa, B.1), (B.ˆa, D.1) et (B.ˆb, C.1).
Structure d’un composant : Un composant possède une interface (I, O). De la même
ma-nière qu’une interface de service, il existe deux catégories de ports qui constituent l’interface d’un composant :
– les points d’entrées du composant
– les événements qui est une liste de wrappers vers des points d’entrées Un composant léger respecte les trois propriétés suivantes :
– Un composant ne communique avec d’autres composants qu’à travers leur interface et ne contiennent aucune référence directe vers d’autres composants à leur conception. Il respecte à ce niveau la propriété blackbox (approche contraire à MOP ou aux interactions [30]). – La seule gestion non-fonctionnelle présente dans un composant est la gestion des événements.
– Pour réaliser dynamiquement leur interconnexion avec d’autres composants logiciels, nous utilisons une indirection qui associe un pointeur prédéfini dans une blackbox à un pointeur externe que l’on peut modifier. C’est ce que nous appelons wrapper. Lorsqu’un événement est émis, chaque point d’entrée associé est exécuté de manière synchrone et séquentiellement et dans l’ordre de leur abonnement. Nous verrons qu’en ajoutant un composant de séquence, il est possible de rendre la diffusion d’événements complètement déterministe.
Figure 4.3 – Wrapper et événement
Un composant est conforme à une description qui contient les informations nécessaires à son instanciation. Les descriptions sont regroupées dans un dépôt modifiable à l’exécution.
Lorsqu’un service de l’infrastructure est découvert, une ou plusieurs descriptions sont dynami-quement crées à l’image de leurs interfaces. Des composants logiciels sont instanciés immédiatement. Ces composants logiciels sont appelés composants mixtes, car ils ne sont pas purement logiciels et représentent les services de l’infrastructure.
4.2.3.2 Composition par flots d’événements
Les composants d’un assemblage peuvent être composés en les reliant par des connecteurs.
Structure d’un connecteur. Nous avons deux sortes de connecteurs : les connecteurs de base
et les connecteurs complexes. Les connecteurs permettent aux composants de communiquer entre eux. Nous avons deux types de connecteurs : les connecteurs de base et les connecteurs complexes. Connecteur de base. Les connecteurs de base transmettent un flot de contrôle et éventuellement des informations entre un wrapper et un point d’entrée.
Figure 4.4 – Modélisation d’un connecteur
Un connecteur est définie par un couple de ports (A.ˆo, B.i) ∈ OA × IB où i et ˆo désignent
respectivement points d’entrée et les événements qui sont préfixés par l’identifiant du composant auquel ils appartiennent. Comme il est illustré dans la figure 4.4, nous utilisons une notation pointée pour désigner ces ports. Ainsi, la représentation graphique d’un connecteur de base (à gauche de la figure) est modélisée par le couple (A.ˆo, B.i).
Connecteur complexe. Un connecteur complexe met en relation n points d’entrée à m événements où n, m sont des entiers supérieurs strictement à 1. Contrairement aux composants blackbox, notre
modèle se focalise plutôt sur des connecteurs complexes de sémantique connue. Un connecteur complexe est toujours de sémantique connue. Exemple : le parallélisme, la disjonction, etc.
La représentation structurelle de notre modèle est valable pour le flot de contrôle et le flot de données.
Flot de contrôle Dans notre modèle, nous définissons quelques composants qui permettent de
représenter les manipulations du flot de contrôle. Les données transmises à ces composants ne sont pas modifiées.
– Un composant de séquence noté ‘Seq’ où ISeq= {p} et OSeq= {ˆe1, . . . ,ˆen} entre plusieurs
événements est le plus simple : l’exécution du point d’entrée p émet en séquence synchrone
respectivement les événements ˆe1, . . . ,ˆen.
– Nous définissons la concurrence notée P ar (IP ar = {p} et OP ar = {ˆe1, . . . ,ˆen}) entre
plusieurs émissions d’événements : l’exécution du point d’entrée p provoque l’exécution en
synchrone respectivement les événements ˆe1, . . . ,ˆen.
– Un composant de disjonction noté ‘∨’ où I∨ = {p(b ∈ BOOL)} et O∨ = {ˆtrue,ˆf alse}
provoque l’émission de l’événement ˆtrue si la valeur booléenne b est vraie et l’émission de
ˆf alsesinon. Notons que la donnée transmise avec le flot de contrôle n’est pas modifiée.
Flot de données Nous définissons trois composants qui permettent de représenter une
transfor-mation de données (sans modification du flot de contrôle) :
– Un composant de test noté ‘?’ où I?= {p}et O?= {q(b ∈ BOOL)} transforme d’une
infor-mation i en inforinfor-mation booléenne b en fonction de l’égalité avec une donnée interne i0.
– Un composant de mémoire noté ‘µ’ où I∨= {m(val), i1, . . . , in} et O∨ = {ˆo1, . . . ,ˆon} une
information i est mémorisée lors de l’exécution du point d’entrée m(i). Cette information est
ensuite émise par l’un des événements ˆo1, . . . ,ˆon que lorsqu’un des points d’entrée
respecti-vement i1, . . . , in est exécuté.
Composants hybrides contrôle/donnée Nous présentons dans ce paragraphe plusieurs
des-criptions de composants complexes qui s’expriment à partir des flots de contrôle et de données auxquels on se rattache pour nos travaux pour des raisons de flexibilité.
Condition. Voici un exemple de connecteur complexe constitué de composants élémentaires de flot de données et de flot de contrôle. Ce connecteur étend en quelque sorte le composant de
dis-jonction en permettant de émettre un événement ˆo1ou ˆo2 et l’information i associée à l’exécution
du point d’entrée Seq.p respectivement si i = val1 ou i = val2.
4.2.3.3 Container et Designer
L’architecture de notre modèle LCA se compose de deux entités logicielles qui permettent de gérer les assemblages de composants.
Container La première entité logicielle appelée container encapsule l’assemblage de composants.
Un container permet la création et la destruction d’assemblages de composants et la modification des connecteurs.
La figure 4.5 résume et relie les entités du modèle LCA à la notion de container. Les descriptions de composants qui peuvent être ajoutés dans un container dépendent du contenu du dépôt.
Designer Un designer est une entité logicielle qui permet la manipulation interactive/réactive
d’un assemblage de composants.
Nous avons créé plusieurs designers encapsulés dans des services : designer graphique (modifi-cation de l’interface graphique), designer visuel (modifi(modifi-cation interactive de l’assemblage), designer pour les aspects d’assemblage (adaptation réactive des assemblages de composants), etc.