La partie K du langage

La partie Kdu langage consiste en l’introduction d’une nouvelle structure

de composant dans le langage, que nous nommons kell par h´eritage du

kell-calcul. Cette structure vient avec deux ensembles d’op´erateurs permettant de

manipuler les deux s´emantiques ind´ependantes de cette structure.

La s´emantique d’isolation. Les kells forment des fronti`eres entre les

diff´e-rentes parties d’un programme, permettant ainsi de structurer, d’abstraire, et de

contrˆoler les interactions entre les diff´erents constituants un logiciel. Par d´efaut,

les capacit´es de communication d’un kell sont les mˆeme que dans [98] : il ne peut

communiquer qu’avec ses composants proches, c’est `a dire celui qui le contient

(sonp`ere) et ceux qu’il contient (sesfils). Il est toutefois assez facile de voir que

cette isolation forte est extrˆemement p´enalisante lorsque l’on veut

communi-quer avec des composants distants : dans le kell-calcul, il faut encoder une telle

communication distante entre les kellsa et b par une chaˆıne de transmetteurs

qui font passer les messages d’un composant `a un autre, au travers de toute

la structure s´eparant les deux kellsaetb. C’est pourquoi nous avons introduit

dans notre extension desportestr`es similaires `a celles que nous avons pr´esent´ees

dans le Chapitre 3. Leur principe est similaire : elles ouvrent la fronti`ere des

composants pour certains canaux de communication, et les communications

uti-lisant ces canaux ne sont alors plus limit´ees `a ˆetre entre composants p`ere et fils.

N´eanmoins, quelques modifications ont ´et´e apport´ees sur nos portes : dans le

chapitre 3, les communications ´etaient asynchrones et les messages pouvaient

franchir les fronti`eres o`u la porte ´etait ouverte. Ici, la communication est

syn-chrone et, afin de permettre une communication `a la kell-calcul mˆeme lorsque

les portes sont ferm´ees, nous autorisons `a toute communication de franchir au

plus une fronti`ere qui n’est pas ouverte. Nous donnons de plus la capacit´e aux

composants de contrˆoler l’ouverture et la fermeture des portes de leurs

compo-sants fils, rendant dynamique la fronti`ere qui dans notre travail pr´ec´edent ´etait

statique. Enfin, les portes ne sont pas de simples noms ici, comme des atomes,

mais des structures ind´ependantes qu’il faut cr´eer. Ainsi, en cr´eant une porte

personnelle, on peut s’assurer que seul des entit´es de confiance peuvent recevoir

des messages sur ce canal s´ecuris´e o`u peuvent circuler des donn´ees sensibles.

La s´emantique de mobilit´e. Les kells forment aussi des entit´es d’ex´ecution

ind´ependantes que l’on stopper, dupliquer et d´eplacer. Le principe fondamental

de ces diff´erentes op´erations est lapassivation[98]. La passivation est une

com-mande permettant de prendre un kell et de le d´etruire en sauvegardant son ´etat

dans une valeur sp´ecifique. Ainsi, il devient possible de d´etruire cette valeur,

auquel cas le composant est d´efinitivement perdu, ou de l’envoyer vers un autre

kell qui pourra relancer son ex´ecution. Plus pr´ecis´ement, la partieKde notre

langage contient une proc´edure de base,Pack K X, qui prend le contenu du kell

K, et le passive dans une valeur li´ee `a X. Notons que la structure du

compo-sant K est toujours pr´esente, bien que vide, afin que les acc`es ult´erieurs `a la

variableKne causent pas d’erreur. Une telle structure peut de plus ˆetre utilis´ee

de nouveau en y injectant un nouvel ensemble de commande via une proc´edure

de remplacement de kell. Les valeurs issues de la passivation d’un composant,

que nous nommonsvaleurs pack´ees, sont sujettes `a deux types d’op´erations :

des op´erations de modifications et une op´eration de d´eploiement. Cette derni`ere

prend le contenu de la valeur (c’est `a dire tout les processus et les kells fils) et les

places dans le kell courant, prˆet `a ˆetre ex´ecut´e `a nouveau. N´eanmoins afin que

toutes ces structures puissent s’ex´ecuter convenablement, il peut ˆetre n´ecessaire

des les adapter au pr´ealable `a leur nouvel environnement. C’est pourquoi nous

offrons la possibilit´e de modifier les valeurs pack´ees, permettant ainsi de mettre

`a jour certaines r´ef´erences et donn´ees en vu de leur future d´eploiement.

L’en-semble de ces manipulations sur les composants composent uncycle de vie, que

nous r´esumons Figure 5.2. Finalement, un composant poss`ede une variable de

actif passivé K[S1] K[ ] Pack(S1) K[S2] Pack(S! 1) K[S3] K[S3| S! 1] valeur packée

cr´eation d’un kell : kell {K} S1 end passivation : {Pack K X} remplacement du kellK: kell {K} S2 end actif actif actif modification de la valeurX: { Mark X M X’} re-d´eploiement deX: {Unpack X’ Y}

Figure 5.2 – Le cycle de vie d’un composant

statutqui est non li´ee lors de l’ex´ecution normale du kell, et prend une variable

lors de l’arrˆet du composant : soit‘packed’si l’arrˆet est dˆu `a une commande de

passivation, soit‘failed’si l’arrˆet est caus´e par une erreur d’ex´ecution.

Apr`es cette br`eve introduction, nous pr´esentons la syntaxe de notre

exten-sion, qui se limite `a la d´efinition d’une structure de kell, ainsi que diff´erentes

proc´edures de base manipulant portes, kells et valeurs pack´ees.

Nous rajoutons au constructions pr´ec´edentes trois nouveaux ´el´ements : les

kells, lesporteset lapassivation. La syntaxe de ces commandes pour manipuler

ces objets est donn´ee Figure 5.3, o`u les termes K, X, Y, Z, G sont de simples

variables.

Les kells. Ces composants sont cr´e´es avec la commandekell{K} S endo`uK

est la variable li´ee au kell cr´e´e, etS le code ex´ecut´e dans un nouveau processus

par le composant. De plus, la commande {Status K X} permet de monitorer

les composants _Oz/K, et de v´erifier leur ´etat de fonctionnement. Il est ainsi

assez facile de d´etecter une erreur d’ex´ecution dans un kell, et de lancer le

code de gestion d’erreur appropri´e. Toute cette gestion est expliqu´ee plus en

d´etail dans la Partie 5.2. Une des probl´ematique de la structure de composant

vient de sa capacit´e `a ˆetre passiv´e, son ex´ecution momentan´ement suspendue

et reprise dans un environnement pouvant ˆetre totalement diff´erent de celui

S ::= . . .

| kell{K} S end Cr´eation d’un kell

| {NewGate X} Cr´eation de porte

| {Send G X} Envoi d’un message

| {Receive G X} Recpetion d’un message

| {Open K G} Ouvre la porteG

| {Close K G} Ferme la porteG

| {Pack K X} Stoppe l’ex´ecution d’un kell

| {Unpack X Y} Continue l’execution d’un kell

| {Mark X Y Z} Remplacement des portes d’un kell stopp´e

| {Status K X} Lecture du status d’un kell

Figure5.3 – La syntaxeK

d’origine. Une telle op´eration peut alors ˆetre source d’incoh´erences dans l’´etat du

syst`eme lorsque l’ex´ecution du composant passiv´e d´epend de son environnement.

C’est pourquoi nous imposons dans notre approche une isolation forte de nos

composants qui ne peuvent communiquer qu’au travers des portes. Une premi`ere

contrainte que nous avons afin d’assurer cette isolation est que le code S ne

doit pas compoter de r´ef´erence `a des variables non li´ees (`a part K qui sera

li´ee durant la cr´eation du kell). En effet, siS comporte des variables non li´ees

provenant de l’ext´erieur du composant, cela impliquerait que le composant et

son environnement peuvent communiquer via ces variables, empˆechant ainsi tout

contrˆole des communications associ´es aux portes. Notons que cette contrainte

n’est pas difficile `a impl´ementer, car elle demande des structures similaires `a

celles utilis´ees pour l’unification, qui est d´ej`a pr´esente dans_Oz.

Les portes comme outils de communications. La commande {NewGate

G} cr´ee une nouvelle porte (qui est une valeur), et la lie `a la variableG. Cette

variable peut ensuite ˆetre utilis´ee pour les envois de messages ({Send G X}) et

leur r´eception ({Receive G X}). Les ´echanges de messages se font par

rendez-vous atomiques, comme pour le π-calcul synchrone : les envois et r´eceptions

de message sont bloquantes, et ne r´eussissent que lorsqu’une r´eception ou un

envoi correspondant a lieu. Cette s´emantique, avec l’isolation des composants,

permettent d’assurer le bon fonctionnement

3

de la commandePackqui stoppe

un composant et sauvegarde son ´etat dans une variable. Notons que l’isolation

3. En effet, avec une communication asynchrone telle que celle que nous avons dans la Chapitre 3, la commandePack peut capturer un message en cours de transmission et ainsi causer un ´etat incoh´erent dans le syst`eme.

des composants est assur´ee par le fait que leur code ne comporte pas de variable

libre pouvant ˆetre utilis´ee comme moyen de communication vers le reste du

programme. Dans le paragraphe pr´ec´edent, nous avons donn´e une contrainte

dans ce sens, sp´ecifiant que le code initial d’un composant ne pouvait comporter

de variable non li´ee (`a part le nom du composant lui-mˆeme). Et afin de garder

cette propri´et´e au cours de l’ex´ecution du composant, nous contraignons les

portes `a n’´echanger que des valeursstrictes, c’est `a dire ne comportant aucune

variable non li´ee. Ces deux contraintes seront d´ecrites en d´etails dans la partie

discutant de la s´emantique op´erationnelle du langage.

Ainsi, les seules primitives de communication entre composants sont les

portes, et cette communication est de plus contrˆol´ee par les fronti`eres des

compo-sants. Cette nouvelle contrainte a pour but de limiter les capacit´es d’interactions

entre composants, et ainsi de s´ecuriser des portions de programmes traitant des

donn´ees sensibles, ou ayant des fonctions vitales pour l’ensemble de

l’applica-tion (et qui ne doivent alors ˆetre corrompues). Par d´efaut, les communical’applica-tions

directe entre un composant et ses fils, qui ne traversent ainsi qu’une barri`ere

d’isolation, sont les seules `a ˆetre autoris´ees. Cette capacit´e peut ˆetre ´etendue, et

r´eduite par la suite, grˆace au primitives Open et Closequi ouvrent et ferment

des portes sur les fronti`eres des composants : un composant p`ere peut ainsi

ouvrir la porteG d’un composant fils K avec la commande {Open K G}, ou la

refermer avec {Close K G}. Avec ce principe de porte, nous pouvons ´etendre

nos capacit´es initiale, et, lors d’une communication, un message envoy´e sur la

porteGpeut franchir toute fronti`ere ayant cette porte ouverte, plus une unique

fronti`ere avec cette porte de ferm´ee. Les communications distantes, traversant

plusieurs limites de composants, doivent ˆetre autoris´ee par l’ouverture des portes

servant `a la communication. Supposons par exemple que deux composants fr`eres

K1et K2veulent communiquer sur la porteG. Leur ´echange traverse leurs deux

fronti`eres, et il faut donc ouvrir la porteGpour K1 ouK2pour qu’ils puissent

communiquer. Cette op´eration est effectu´ee par le composant p`ere K, avec la

commande{Open K1 G} ou{Open K2 G}. Enfin, les op´erations d’ouverture et

de fermeture de porte sont ´etendues par l’atome‘all’permettant de sp´ecifier tout

les sous-composants d’un composant p`ere, ou toutes les portes. Ainsi,{Open K

‘all’} ouvre toute les portes du composant K, et {Close ‘all’ G} ferme la

porteGde tous les sous-composants du kell courant.

La passivation. La commande{Pack K V} stoppe le composantKainsi que

tout ses sous-composants, et stocke son ´etat (c’est `a dire les diff´erents processus

qu’il ex´ecutait ainsi que les valeurs qu’il utilisait) dans une valeur donn´ee `a la

va-riableV. Cet valeur est appel´e unevaleur pack´ee, et supporte quelque op´eration

de modification via la commande

{Mark V1 R V2}

. Dans cette op´eration,V1est la

valeur pack´ee `a modifier,Rest la commande, etV2est le r´esultat. Il existe trois

formes de commandes : (i) gate(G1 G2) remplace les r´ef´erences vers la porte

G1par des r´ef´erences vers G2 dansV2; (ii)proc(P Q remplace la proc´edureP

parQ; et (iii) top(K)remplace le composant englobant de la valeur pack´ee par

qui sera pris en compte lors du d´eploiement de la valeur pack´ee en un nouveau

composant s’ex´ecutant. En effet, les valeurs pack´ees peuvent ˆetre utilis´ee avec

la commande

{Unpack V R}

, qui cr´ee un nouveau composant similaire `a celui

stock´e dans V, et l’ex´ecute. Afin qu’il n’y ait aucun conflit entre les variables

utilis´ee par le programme, et celles venant du composant d´eploy´e, la proc´edure

Unpack renomme tous les objets contenu dans la valeur pack´ee, sauf ceux qui

ont ´et´e marqu´ees (et qui correspondent donc `a des objets voulus par le

pro-grammeur). Ces nouveaux noms sont aussi mis `a disposition dansR, qui est un

message structur´e, avec comme champs, les anciens noms des diff´erents objets

de la valeur pack´ee, et comme valeurs, les nouveaux noms correspondant.

Dans le document Composants et Typage (Page 126-131)