Algèbres de processus

Les algèbres de processus sont des formalismes de description formelle pour la spécifica-tion de systèmes logiciels, en particulier pour les systèmes concurrentiels. Elles fournissent des outils pour la description de haut niveau des interactions et des synchronisations entre les processus. Plusieurs algèbres de processus ont été décrites. Parmi les plus anciennes on peut citer CSP qui a été présenté par Hoare dans [Hoa78] et CCS qui a été proposé par Milner [Mil82, Mil89]. D’autres algèbres ont vu le jour plus récemment tels que LO-TOS [BB89] et π-calcul [MPW92] qui sont tous les deux inspirés de CCS. LOLO-TOS est un standard ISO utilisé pour la spécification formelle des protocoles dans les standards OSI. π-calcul est une continuation de CCS par Milner et al. ayant pour objectif de pouvoir exprimer la mobilité des processus. Pour ce faire, π-calcul prend en charge le passage de canaux de communication (channels) en tant que données à travers d’autres canaux de communication. La structure du système concurrentiel peut alors changer en cours d’exé-cution. π-calcul possède cependant l’inconvénient de ne pas pouvoir traiter explicitement des données. A la place, π-calcul prend simplement en compte des noms (ex : x, y, z), qui sont des représentations abstraites susceptibles de représenter n’importe quel type d’information.

Les algèbres de processus utilisent des structures simples telles que l’émission ou la réception de message par un processus, le séquencement de processus, le choix non dé-terministe ou encore l’exécution parallèle de processus. Par exemple, π-calcul comprend des processus, des canaux de communication et des opérateurs tel qu’indiqué dans la définition 2.2.2.1.

Définition 2.2.2.1 Un processus est défini en π-calcul par : P ::= 0 | π.P | P + Q | P |Q | (νz)P |!P , où :

2.2. Modélisation de systèmes concurrentiels 31 – 0 est un processus inerte, qui ne réalise aucune tâche

– le préfixe π ::= c < y >| c(z) | τ

– c < y > .P envoie le nom y sur le canal c and avant de continuer en tant que P – c(z).P reçoit n’importe quel nom depuis le canal c et l’attache au nom z avant de

continuer en tant que P

– τ.P exécute une action interne avant de continuer en tant que P – P + Q réalise un choix non déterministe entre P et Q

– P |Q exécute les processus P et Q en parallèle – (νz)P déclare le nom z au sein du processus P

– !P est un processus qui est toujours capable de créer une copie de P ( réplication) Récemment, plusieurs travaux de recherche ont utilisés ces formalismes pour la compo-sition de services, avec pour principal objectif de vérifier formellement que la compocompo-sition respecte les propriétés demandées. Par exemple, une technique de formalisation basée sur CCS pour la chorégraphie de service avec WSCI a été proposée dans [CCCV06]. En d’autres termes, des règles ont été présentées pour traduire en CCS des chorégraphies de services écrites en WSCI pour ensuite vérifier la compatibilité de deux services. Deux ser-vices sont considérés compatibles si tous les messages échangés sont mutuellement compris et si leur communication est sans blocage. Dans [LSZ+06], l’algèbre CCS a été utilisée pour la modélisation et la spécification des services Web afin de raisonner sur les propriétés comportementales de la composition. Les auteurs de cet article ont étendu le travail réalisé dans [CCCV06] afin de prendre en compte la composition asynchrone de services. Une fois la composition décrite avec CCS, des outils de vérification tels que CWB-NC [CLS00] peuvent être utilisés.

Dans [KB04], la sémantique du langage de chorégraphie WS-CDL est décrite à l’aide de CSP pour permettre la vérification automatiques de propriétés. Un travail similaire est réalisé dans [LHZP07] où des règles sont présentées pour traduire chaque construction syntactique de WS-CDL en CSP.

Le langage de spécification formel LOTOS a également été considéré, notamment par Ferrara dans [Fer04]. Dans cet article, des règles sont présentées pour traduire un processus BPEL en spécification LOTOS et inversement. La conversion d’un processus BPEL en LOTOS permet de le valider avec des outils tels que CADP [FGK+96]. A l’inverse, il est utile de pouvoir générer automatiquement du code exécutable à partir d’une spécification de composition en LOTOS. Cette manière de procéder est plus fidèle à l’ingénierie dirigée

par les modèles (MDE).

Dans [LM06], la sémantique du langage d’orchestration BPEL est cette fois-ci spécifiée en utilisant π-calcul. Les auteurs n’ont cependant pas étudié la totalité de BPEL mais plutôt un sous-ensemble, c’est à dire les activités simples et structurées et la gestion d’erreurs. D’autres parties de BPEL telles que la gestion des données ne sont pas traitées, ce qui n’est pas surprenant car π-calcul ne permet pas la manipulation de données. Ce travail a été mené afin de permettre l’analyse formelle de BPEL qui n’est pas possible directement du fait du manque de formalisme de BPEL.

Une approche pour modéliser et vérifier la composition de services Web à l’aide de FSP est proposée dans [FUMK03]. FSP est une algèbre de processus proposée par Magee et Kramer [MKG99] conçue pour spécifier des workflows de manière abstraite tout en étant facilement lisible par une machine. Dans [FUMK03], les auteurs partent d’un processus BPEL pour l’exprimer d’abord sous la forme d’un diagramme de séquence UML, avant de le spécifier à l’aide de FSP. Les notations FSP sont facilement traduisibles en système de transition d’états (LTS) afin de vérifier l’exactitude du modèle ainsi que certaines propriétés telles que la vivacité.

Les algèbres de processus présentent l’avantage d’être très expressives et de prendre en charge des opérateurs et structures adéquats pour spécifier la composition de services. Elles permettent ainsi d’exprimer notamment la séquentialité, le parallélisme et l’exécution conditionnelle [BS05, BBG07]. Pour illustrer l’utilisation des algèbres de processus pour la spécification de services composés, nous fournissons un exemple basé sur π-calcul dans la figure 2.4. Cette représentation adopte l’approche événement-condition-action (ECA), comme préconisé par Puhlmann et Weske dans [PW05]. Chaque activité du workflow est ainsi représentée par un processus indépendant. Les processus utilisent des événements, sous la forme d’échange de messages, pour coordonner le comportement du workflow. L’échange de messages s’effectue au niveau de canaux de communication dont le nom a été précisé sur le modèle dans la partie gauche de la figure, afin de faciliter la compréhension. En π-calcul, le parallélisme est exprimé par | et le choix exclusif par +. Nous définissons τi comme la tâche réalisée en interne par le service i. c.X indique l’émission d’un message sur le canal "c" (ex: s1_to_s2 dans la figure) avant de continuer en tant que processus X. c.X (sans ligne supérieure) indique au contraire l’attente en réception d’un message sur le canal "c". Le processus "0" est un processus inerte, indiquant la fin de l’exécution du service.