Gestion de transactions en environnement mobile

Transcription

1 Thèse e octorat e l Unversté e Versalles Sant Quentn en Yvelnes Spécalté : Informatque Présenté par : Chrstophe Bobneau Pour obtenr le ttre e : Docteur en scences Geston e transactons en envronnement moble Soutenue evant un jury composé e : Chrstne Collet Jean Ferré Pascal Moll Phlppe Pucheral Pascal Uren Patrck Valurez rapporteur rapporteur examnateur recteur e thèse examnateur examnateur

2 2

3 3 Table es Matères CHAPITRE 1 : INTRODUCTION MOTIVATION ET OBJECTIFS CONTRIBUTIONS DE LA THÈSE PLAN...13 PROBLÉMATIQUE DES TRANSACTIONS EN ENVIRONNEMENT MOBILE INTRODUCTION ARCHITECTURE CONSIDÉRÉE Calculateurs mobles Archtecture réseau Archtectures logcelles Clent/Serveur classque Clent/Agent/Serveur Clent/Agent/Agent/Serveur ou Clent/Intercepteur/Serveur Serveur/Serveur APPLICATIONS MOBILES Dffuson nformatons Hôte moble ntateur e transactons Serveur moble en moe connecté Serveur moble en moe éconnecté MODÈLES DE TRANSACTION ACID Atomcté AtomctÈ locale AtomctÈ globale Cohérence Isolaton Moes e propagaton RÈplcaton synchrone RÈplcaton asynchrone Moes e contrôle Moe asymètrque Moe symètrque Durablté...36

4 4 CHAPITRE 2 : PICOSGBD INTRODUCTION APPLICATIONS POUR CARTES À PUCE Besons en geston e bases e onnées L applcaton carte santé RÈGLES DE CONCEPTION Contrantes es cartes à puce Impact sur l archtecture u PcoSGBD Poston u problème MODÈLE DE STOCKAGE Stockage plat Stockage en omane Stockage en anneau Evaluaton u coût e stockage MODÈLE D EXÉCUTION Exécuton e requêtes smples sans RAM Exécuton e requêtes complexes sans RAM Optmsaton e requête GESTION DE TRANSACTIONS Atomcté locale Evaluaton u coût es transactons CONCLUSION...61 CHAPITRE 3 : PROTOCOLES DE VALIDATION ATOMIQUE INTRODUCTION APPLICATIONS EXEMPLES LE TWO PHASE COMMIT Protocole Tolérance aux pannes PC et moblté PROTOCOLE UNILATERAL COMMIT FOR MOBILE Protocoles e valaton atomque à une phase Descrpton u protocole UCM Reprse après panne Applcaton pratque Tratement hors-lgne Serveurs lègers...74

5 Serveurs mobles CONCLUSION...77 CHAPITRE 4 : DURABILITÉ DES DONNÉES EMBARQUÉES INTRODUCTION TECHNIQUES DE DURABILITÉ Génératon u journal Stockage es journaux Restauraton es onnées TRANSFORMÉES OPÉRATIONNELLES CAS SIMPLE : LES CHAÎNES DE CARACTÈRES Smplfcatons opératons OpÈratons entques OpÈratons ffèrentes Défnton es transformées Algorthme optmsaton u journal GÉNÉRALISATION Relatons entre opératons Algorthme e canonsaton Premère phase Secone phase Algorthme e compresson Applcaton aux collectons DÈveloppement Factorsaton TransformÈes opèratonnelles CONFIDENTIALITÉ DES DONNÉES DURABLES CONCLUSION CHAPITRE 5 : CONCLUSION ET PERSPECTIVES RÉFÉRENCES...105

6 6

7 7 Table es Fgures FIGURE 2.1 : ARCHITECTURE MATÉRIELLE DES RÉSEAUX SANS FIL...19 FIGURE 2.2 : STRUCTURE D'UN COMPACT...27 TABLEAU 2.3 : COMPATIBILITÉ ENTRE VERROUS...29 FIGURE 2.4 : SÉRIALISABILITÉ À UNE COPIE...30 FIGURE 2.5 : RÉPLICATION SYNCHRONE...31 FIGURE 2.6 : RÉPLICATION ASYNCHRONE...31 FIGURE 2.7 : MODE DE CONTRÔLE ASYMÉTRIQUE...32 FIGURE 2.8 : MODE DE CONTRÔLE SYMÉTRIQUE...34 TABLEAU 3.9 : PROFILES D'APPLICATIONS TYPES...41 TABLEAU 3.10 : PERFORMANCE DES MÉMOIRES STABLES POUR CARTES À PUCE...44 FIGURE 3.11 : STOCKAGE EN DOMAINES...49 FIGURE 3.12 : STOCKAGE EN ANNEAU...49 FIGURE 3.13 : COMPARAISON DES MODÈLES DE STOCKAGE...52 FIGURE 3.14 : DIFFÉRENTS PLANS D'EXÉCUTION POUR LA REQUÊTE R FIGURE 3.15 : QUATRE PLANS D'EXÉCUTION DE REQUÊTES COMPLEXES...55 FIGURE 3.16 : PERFORMANCE D'UNE TRANSACTION DE MISE À JOUR TYPE...61 FIGURE 4.17 : PROTOCOLE TWO-PHASES COMMIT...66 FIGURE 4.18 : UNE CONFIGURATION TYPE POUR L'UCM...70 FIGURE 4.19 : SCÉNARIO DE VALIDATION PRODUIT PAR LE PROTOCOLE UCM..71 FIGURE 4.20 : CONFIGURATION UCM POUR L'APPLICATION DE COMMERCE ÉLECTRONIQUE...74

8 8 FIGURE 4.21 : CONFIGURATION UCM POUR L'APPLICATION DU PORTE- MONNAIE ÉLECTRONIQUE...75 TABLEAU 4.22 : UCM VERSUS 2PC...77 FIGURE 5.23 : UTILISATION DES TRANSFORMÉES OPÉRATIONNELLES...84 FIGURE 5.24 : RÈGLES DE PERMUTATION D'OPÉRATIONS DISJOINTES...87 FIGURE 5.25 : TRANSFORMÉES OPÉRATIONNELLES EN ARRIÈRE POUR L'ÉDITEUR SIMPLE...89 FIGURE 5.26 : CAS DE GAIN EN TAILLE DE JOURNAL OU COMPLEXITÉ DES OPÉRATIONS...89 FIGURE 5.27 : ALGORITHME DE CANONISATION DE JOURNAL...90 FIGURE 5.28 : ALGORITHME GÉNÉRIQUE DE CANONISATION...93 FIGURE 5.29: DÉCOMPOSITION POUR LES COLLECTIONS...95 TABLEAU 5.30 : COMPOSITION D'OPÉRATIONS SUR LES COLLECTIONS...96 TABLEAU 5.31 : FACTORISATION D OPÉRATIONS SUR LES COLLECTIONS...96

9 9

10 10 Chaptre 1 : Introucton 1. Motvaton et objectfs Les progrès technques rèalsès sur les archtectures matèrelles ont perms une mportante mnatursaton es calculateurs et, ans le même temps, une rèucton consèrable e leur consommaton Èlectrque. Cec a conut à une prolfèraton e calculateurs mobles ont l autonome ne cesse e croître (e quelques heures à quelques semanes). La lo e Moore s applquant auss à ces technologes, les calculateurs mobles sont evenus e plus en plus pussants (e pussance Èquvalente à es PC e bureaux pour certans), et onc e plus en plus polyvalents. De plus, les rèseaux sans fl se sont largement ÈveloppÈs u fat u succès es rèseaux e tèlèphone moble (GSM, GPRS, UMTS ) et es rèseaux locaux sans fl. Ces rèseaux permettent aux calculateurs mobles e communquer entre eux ou avec autres calculateurs connectès à un rèseau fxe. Les rèseaux cellulares, e type tèlèphonque, permettent même e mantenr la communcaton lorsque le calculateur se Èplace e cellule en cellule. De nouvelles applcatons utlsant ces mobles connectès à un rèseau voent le jour. Les applcatons mobles ntales utlsaent es protocoles e communcaton smples basès sur le transfert e fchers (exemple : applcaton nventare où es mobles sont utlsès ans les entrepôts pour Èvaluer les stocks, pus ces mobles envoent leurs onnèes à un serveur entreprse qu les ntègre ans une base e onnèes). Aujour hu, la polyvalence es calculateurs mobles et la performance et la fabltè e leur connexon au rèseau permet aux applcatons mobles e se tourner vers es protocoles e communcaton stanar exstants ou aaptès à l envronnement moble (comme le protocole WAP pour les connexons à l Internet). Avec la gènèralsaton es applcatons fasant nteragr es calculateurs mobles et fxes, le beson e technques transactonnelles se fat sentr pour pouvor assurer la cohèrence es onnèes. Les besons en fonctonnaltès transactonnelles e ces applcatons varent en foncton e leur moe e fonctonnement : les applcatons où le calculateur moble effectue unquement la geston e la prèsentaton es onnèes ffusèes sur le rèseau sans fl (le trafc router, par exemple) ou tèlèchargèes epus un ste stant sans sesson e communcaton (comme la navgaton Web) ne nècesstent peu ou pas e fonctonnaltès transactonnelles. Par contre, toute les applcatons manpulant es onnèes hèbergèes sur un ste stant, même s les calculs sont effectuès sur ce ste stant (s le calculateur moble est utlsè comme termnal accès à une base e onnèes stante, par exemple), ou manpulant es onnèes stockèes sur le moble lu-même (Èplacement

11 11 e renez-vous sur un agena Èlectronque) mposent l utlsaton e transactons pour assurer la cohèrence es onnèes. Par alleurs, e plus en plus applcatons effectuent es transactons strbuèes entre ffèrents mobles et/ou serveurs fxes. C est le cas par exemple es applcatons bancares e type porte-monnae Èlectronques embarquès sur cartes à puce, ou encore es applcatons e prses e renez-vous automatques entre ffèrents agenas hèbergès sur les calculateurs mobles e leurs porteurs. Ces applcatons mposent, non seulement la geston e transactons locales sur les calculateurs mobles, mas auss la partcpaton e ces mobles à es transactons strbuèes. Les calculateurs mobles ont es caractèrstques physques qu ne sont pas sans consèquences sur le fonctonnement es technques transactonnelles classques. Ces calculateurs vont e la carte à puce à es PC portables. A ttre exemple, les cartes à puce prèsentent une pussance e calcul relatvement mportante (comparable aux PC l y a x ans), mas une mèmore e traval (RAM) extrêmement rèute qu mpose es technques spècfques e geston e onnèes et une mèmore persstante e technologe EEPROM gènèrant es coûts Ècrture consèrables. Ces caractèrstques ntrousent es contrantes fortes sur la mse en œuvre e technques transactonnelles. D autre part, les rèseaux sans fl, malgrè les progrès technques contnus, ntrousent autres contrantes sur la geston e transactons. En effet, la bane passante sponble est plus fable un ou eux orres e graneur que celles es rèseaux flares (e quelques Kbts/s à quelques Mbts/s pour les rèseaux sans fl pour une bane passante e quelques zanes e Mbts/s à quelques Gbts/s pour les rèseaux flares), ce qu a pour consèquence e remettre en cause les protocoles e communcaton gourmans (comme ceux qu prèsentent un rapport sgnalsaton/nformaton mportants). De plus, l exste es zones ombres ans la couverture es rèseaux sans fl (ans les tunnels, par exemple) ans lesquelles toute communcaton est mpossble. Lorsqu un moble entre ans une telle zone, l se trouve brutalement ÈconnectÈ u rèseau. Ces Èconnexons sont gènèralement perçues comme une panne par les protocoles classques e geston e transactons, ce qu entraîne un taux abanon e transactons mportant. Enfn, pour permettre le traval ÈconnectÈ à partr e calculateurs mobles, on a recours à la rèplcaton es onnèes. S les onnèes rèplquèes sont partagèes par pluseurs mobles travallant hors connexon, l est très ffcle Èvter une vergence es copes qu conura gènèralement à l abanon une parte es transactons concurrentes. En effet, les technques classques e rèplcaton, qu assurent la cohèrence es copes en applquant les mses à jour smultanèment sur l ensemble es rèplquas, ne peuvent être applquèes en envronnement moble car, u fat es Èconnexons, tous les rèplquas ne sont pas nècessarement jognables en même temps. DffÈrents protocoles ont ÈtÈ proposès pour assurer les proprètès ACID (AtomctÈ, CohÈrence, Isolaton et DurabltÈ) es transactons ans un envronnement moble. Par exemple, pour assurer

12 12 l atomctè es transactons rèpartes (la transacton est exècutèe en tout ou ren) en envronnement moble, le protocole ben connu Two-Phase Commt (2PC) a ÈtÈ aaptè en Ètermnant la urèe maxmale e Èconnexon avant l abanon e la transacton en cours. Cela permet e rèure le taux abanon es transactons mas cela ne change ren u pont e vue u coût e communcaton nut par le 2PC, coût qu reste ÈlevÈ avec les rèseaux sans fl. La cohèrence (respect es contrantes ntègrtè) peut être assurèe e façon classque, mas s les mobles travallent en moe ÈconnectÈ, elle ne peut être assurèe qu à la reconnexon (ce qu peut entraîner un traval nutle). Une soluton proposèe est e transfèrer vers le moble non seulement les onnèes ont l aura beson pour travaller en moe ÈconnectÈ, mas auss les routnes permettant e vèrfer les contrantes ntègrtè en local. L solaton, qu assure que es transactons concurrentes ne voent pas les rèsultats ntermèares es autres, pose un problème mportant. En effet, les technques pessmstes comme le verroullage (qu assurent l solaton au fur et à mesure e l exècuton es transactons) sont trop contragnantes car ren ne garantt qu un utlsateur qu se Èconnecte se reconnectera ans un Èla bornè afn e relâcher les verrous qu l Ètent. Là encore ce protocole a ÈtÈ aaptè en jouant sur les Èlas e gare. Même s une telle soluton rèut le taux abanon es transactons, elle rèut auss le nveau e concurrence supportè par le système. Pour augmenter ce taux e concurrence, on a recours aux protocoles e contrôle e concurrence optmstes (le contrôle n est effectuè qu à la fn e la transacton) mas cela augmente le taux abanon (crèaton e conflts accès entre transactons concurrentes). On a recours auss à la rèplcaton es onnèes permettant à pluseurs mobles e travaller sur les mêmes onnèes Èventuellement en moe ÈconnectÈ. Se pose alors le problème e la synchronsaton es rèplquas qu ne peut se fare e façon synchrone u fat es Èconnexons. D autres solutons utlsent la sèmantque es onnèes pour les fragmenter, chaque fragment Ètant sous la responsabltè un moble, mas cette soluton n est pas gènèrale (l faut que les onnèes s y prêtent). La ernère proprètè, la urabltè, ne peut être assurèe sur un moble. En effet, elle assure que les effets es transactons ne seront jamas perus, or les mobles peuvent faclement être perus, enommagès ou volès. Les effets es transactons ovent onc être transfèrès sur un serveur u rèseau fxe, ce qu mplque un coût e communcaton mportant. 2. Contrbutons e la thèse Dans cette thèse, nous analysons tout abor les caractèrstques es calculateurs mobles et es rèseaux sans fl pour Èfnr les contrantes mposèes par l envronnement moble aux technques e geston e transactons. Nous analysons ensute les famlles applcatons fasant ntervenr es mobles pour Ètermner leurs besons en fonctonnaltès transactonnelles. Ensute, nous analysons les technques transactonnelles exstantes (classques utlsèes ans le care es rèseaux fxes, et spècfques aux rèseaux sans fl), pour chacune es quatre proprètès ACID (AtomctÈ,

13 13 CohÈrence, Isolaton et DurabltÈ), afn Ètuer comment elles s aaptent à l envronnement moble et à ses contrantes. Par la sute, nous nous ntèressons à tros es aspects pour lesquelles les technques classques e geston e transactons rèponent mal aux contrantes e la mobltè : 1. Exécuton e transactons locales sur es calculateurs mobles ultra-légers : Nous avons conçu un système e geston e bases e onnèes ÈÈ aux cartes à puce (qu consttuent un système matèrel moble fortement contrant u fat e sa talle rèute et u nveau e sècurtè ÈlevÈ à mantenr). Ce PcoSGBD evat pouvor effectuer es tratements relatvement complexes et gèrer es transactons locales. Nous avons onc Èfn un moèle e stockage, un moèle exècuton e requêtes et es technques spècfques pour gèrer l atomctè locale es transactons. 2. Atomcté globale pour es transactons mplquant es mobles : Nous avons Èfn un protocole e valaton atomque aaptè à la mobltè, nommè Unlateral Commt for Moble an Dsconnecte Computng (UCM). Ce protocole e valaton atomque permet : () e gèrer les Èconnexons e partcpants penant le Èroulement u protocole, () e rèure le coût e communcaton û au protocole et () la partcpaton aux transactons strbuèes es système hèrtès n offrant pas nterface stanar pour la valaton atomque (par exemple : les cartes à puce). 3. Durablté es transactons locales exécutées sur es calculateurs ultra-légers : Nous avons Èfn es technques e canonsaton et e compresson hstores (sèquence opèratons logques) permettant e rèure le coût es technques e urabltè basèes sur les journaux logques. Ces technques e compresson et e canonsaton peuvent avor un prolongement sur les technques e synchronsaton e rèplquas entre stes mobles et fxes. 3. Plan La sute e cette thèse se Ècoupe comme sut : Le chaptre 2 prèsente la problèmatque es transactons en envronnement moble. Nous ntrousons tout abor une archtecture moble e rèfèrence et entfons les contrantes spècfques e cette archtecture au regar es caractèrstques es ffèrents types e calculateurs mobles et es nfrastructures rèseaux et logcelles consèrèes. Nous entfons es classes applcatons types mplquant es mobles, ans que leurs besons en fonctonnaltès transactonnelles. Nous verrons ensute quelles sont les technques utlsèes pour assurer les proprètès transactonnelles et comment ces

14 14 technques s aaptent à l envronnement moble et à ses contrantes. Enfn, nous prèsenterons les contrbutons e cette thèse. Le chaptre 3 abore le problème e la geston e transactons locales sur un calculateur moble fortement contrant. Nous prèsentons un système e geston e bases e onnèes estnè aux cartes à puce. Ce système, appelè PcoSGBD, nècesste l utlsaton e technques e stockage, exècuton e requêtes et e geston e transacton spècfques pour rèponre aux fortes contrantes ntroutes par les caractèrstques matèrelles e la puce et par le nveau e sècurtè evant être assurè sur les onnèes embarquèes. Ce PcoSGBD ot pouvor exècuter es transactons locales comprenant es requêtes relatvement complexes et ot être capable e partcper à es transactons strbuèes. Dans le chaptre 4, nous Ètuons les protocoles e valaton atomque et leur utlsaton en envronnement moble. Nous constatons que le protocole le plus utlsè, le Two-Phase Commt, s aapte mal aux contrantes e cet envronnement et nous proposons un nouveau protocole e valaton atomque, nommè Unlateral Commt for Moble an Dsconnecte Computng, spècfquement conçu pour l envronnement moble. Ce protocole permet la geston es Èconnexons es partcpants urant son exècuton, rèut le coût e communcaton û à la termnason es transactons et permet à es calculateurs lègers ne prèsentant pas nterface stanar e valaton atomque e partcper à es transactons rèpartes. Le chaptre 5 abore le problème e la urabltè es onnèes embarquèes sur es calculateurs mobles. En effet la urabltè ne peut être assurèe sur le moble et nècesste onc un transfert nformaton u moble vers un serveur stuè sur le rèseau fxe. Dans ce chaptre nous proposons es technques e canonsaton et e compresson e journaux ans le but optmser la geston e la urabltè. Ces technques peuvent auss avor es prolongements sur les technques e synchronsaton e rèplquas en envronnement moble. Et enfn, nous prèsentons, ans le chaptre 6, la synthèse e nos contrbutons et les perspectves es travaux rèalsès ans le care e cette thèse.

15 Problématque es transactons en envronnement moble 4. Introucton La gènèralsaton et les progrès technques es rèseaux sans fl font le succès es calculateurs mobles. De nouvelles famlles applcatons pour ces calculateurs voent le jour. Certanes e ces applcatons s exècutent unquement en local sur es mobles, mas, e plus en plus, autres applcatons font nteragr es calculateurs mobles avec es machnes fxes (un smple navgateur web, par exemple), vore même avec autres calculateurs mobles (comme la synchronsaton agena entre un assstant personnel et un ornateur portable). Du fat e ces nteractons, et e la complextè crossante e ces applcatons, le beson e technques transactonnelles se fat sentr. Une transacton [GrRe93] est un ensemble opèratons respectant les proprètès suvantes : L Atomcté : cette proprètè assure que les opèratons sont toutes exècutèes ou aucune ne l est, c est-à-re que, s une transacton est abanonnèe, toutes les opèratons ayant ÈtÈ exècutèes seront annulèes. La Cohérence : cette proprètè assure que toutes les opèratons une transacton respectent les contrantes ntègrtè Èventuellement Èfnes sur les onnèes. L Isolaton : cette proprètè assure que l exècuton e transactons concurrentes est Èquvalente à une exècuton en sère e ces transactons. Cela veut re notamment qu aucune transacton ne ot pouvor vor les rèsultats ntermèares es autres. La Durablté : cette proprètè stpule que les effets une transacton valèe ne seront jamas perus, même en cas e panne matèrelle. Ces proprètès sont notèes ACID. S une seule e ces proprètès n est pas respectèe pour une transacton, celle-c ot être mpèratvement abanonnèe. Mas quelle est l nfluence e la mobltè sur les technques transactonnelles? En fat, l y a pluseurs aspects à consèrer : La nature es calculateurs mobles : en effet, leurs caractèrstques technques peuvent nfluencer la manère assurer les proprètès transactonnelles.

16 16 L archtecture es réseaux mobles : e la même façon, les rèseaux peuvent eux auss nure e nouvelles contrantes. Le Èploement archtectures logcelles spècfques peut être nècessare. La nature même es applcatons : toutes les classes applcaton n ont peut-être pas les mêmes besons transactonnels. En effet, certanes applcatons vont avor beson e toutes les proprètès ACID, alors que autres pourront se passer e une ou pluseurs e ces proprètès. Ce chaptre se Ècoupe e la manère suvante : la secton 2 prèsente l archtecture e rèfèrence un envronnement moble, es caractèrstques es calculateurs mobles aux archtectures logcelles, en passant par les archtectures es rèseaux mobles ; la secton 3 caractèrse es famlles applcatons pour mobles et leurs besons concernant les transactons ; ans la secton 4, nous montrons comment les proprètès ACID es transactons en envronnement moble sont assurèes ans les moèles exstants ; et enfn, la secton 5 prèsentera les contrbutons e cette thèse. 5. Archtecture consérée Dans cette secton, nous allons vor quelles sont les contrantes matèrelles nutes par les calculateurs mobles, comment ls sont connectès à un rèseau sans fl et quelles sont les archtectures logcelles utlsèes ans ce contexte Calculateurs mobles Il exste une grane varètè e calculateurs mobles, prèsentant e granes ffèrences u pont e vue e leurs caractèrstques. Ils vont u PC portable à la carte à puce, en passant par les assstants personnels (PDA, pour Personal Dgtal Assstant) et les tèlèphones mobles. Ils peuvent être classfès en foncton e leurs prncpales ressources, qu sont : La pussance e calcul : Les PC portable sont es machnes e bureau mobles, ls offrent onc la même pussance e calcul que ces ernères car ls ntègrent les mêmes processeurs, en verson à fable consommaton (jusqu à 64 bts à quelques GHz). Les PDA, eux, possèent es processeurs spècfques très pussants (32 bts à quelques centanes e MHz) car ls sont prèvus pour exècuter es versons allègèes es logcels tratonnels (tratements e texte, tableurs, gestonnares e bases e onnèes, ). Par contre, les cartes à puce ont es processeurs e pussance relatvement fables (8 à 32 bts à es frèquences e 10 à 100 Mhz) et ce sont souvent es versons aaptèes e mcrocontrôleurs classques. Les tèlèphones mobles vont e la pussance une carte à puce à celle un PDA (certans tèlèphones mobles ne sont

17 17 que es PDA communcants). Il faura onc prèvor es algorthmes aaptès à la pussance e calcul sponble. La capacté e stockage : Là auss, l y a e granes spartès. Les PC portables sposent e granes mèmores RAM, comparables à celles es machnes e bureau (128 Mo à quelques Go), et e sques urs e grane capactè (pluseurs zanes e Go). La capactè e stockage ne consttue onc pas une contrante pour les PC portables. La mèmore e stockage es PDA se trouve sous forme e RAM e grane capactè (32 à 128 Mo) almentèe en permanence, ont une parte sert e mèmore e traval, et le reste sert e système e fchers. Leur capactè e stockage (systèmes e fchers) peut être Ètenue à l ae e cartes e mèmore Flash (mèmore persstante sans almentaton) allant jusqu à 512 Mo, ou e sques urs mnatursès (jusqu à 2 Go). Les cartes à puce, quant à elles, ne sposent que e quelques Ko e RAM (juste pour les ples exècuton) et jusqu à quelques Mo e mèmore stable non almentèe, comme e l EEPROM ou e la Flash. Les tèlèphones mobles, là encore, vont e la capactè une carte à puce à celle un PDA. Certanes applcatons très consommatrces espace e stockage, comme les bases e onnèes, evront utlser es structures e onnèes spècfques très compactes. Le moe e connexon réseau : Les calculateurs mobles se stnguent les uns es autres par leur moe e connexon rèseau. Certans, comme les tèlèphones mobles sont connectès au rèseau en permanence (sauf lorsqu ls sont Ètents ou lorsqu ls sont hors e la zone e couverture rèseau), alors que autres, comme les PC portables ou les PDA, ne sont connectès que par ntermttence. En effet, leur Èconnexon peut ntervenr e façon prèvsble, pour Èconomser les batteres, par exemple, ou e façon complètement nattenue, comme lorsque l on qutte brutalement la zone e couverture (entrèe ans un tunnel). Les cartes à puce se stnguent es autres car elles ne peuvent fonctonner que s elles sont connectèes à un termnal, qu peut être fxe ou moble (l peut onc être ÈconnectÈ u rèseau). Les protocoles utlsès ans l nformatque moble evront onc gèrer la Èconnexon es mobles, qu est plus ou mons frèquente suvant les termnaux mobles. L autonome : Une autre caractèrstque varable suvant les calculateurs est l autonome. En effet, l autonome es calculateurs mobles peut varer e quelques heures (pour les PC portables) à quelques semanes (pour les PDA et tèlèphones mobles). Ils peuvent onc contnuer leurs tratements tout en Ètant hors connexon. Les cartes à puce se stnguent encore car elles n ont aucune autonome. Elles ne peuvent fonctonner que lorsqu elles sont connectèes à un termnal (qu, lu, peut être autonome). Il faura onc auss prèvor la possbltè e tratement en moe ÈconnectÈ.

18 18 L nterface utlsateur : Les calculateurs mobles prèsentent auss une grane verstè quant à leur nterface utlsateur. Les PC portables ont la même nterface que les machnes e bureau (Ècran e haute rèsoluton, claver et sours), les PDA et les tèlèphones mobles sposent un Ècran e pette menson et, quelques fos, ne sposent pas e claver (comme les PalmPlot) ou e sours (comme les tèlèphones). Même s cela n a pas e consèquence sur la geston e transacton, le portage une applcaton pour machnes e bureau sur un moble entraînera souvent la rèècrture une parte e l applcaton (l nterface utlsateur). Les protocoles transactonnels evront onc s aapter aux contrantes es calculateurs mobles, c est-à-re gèrer la Èconnexon et le traval en moe ÈconnectÈ tout en mnmsant la consommaton es ressources crtques, comme la mèmore e stockage sur les cartes à puce. Les ressources comme la pussance e calcul ne sont pas consèrèes comme crtques car, même sur les cartes à puce, la pussance e calcul est consèrable, vu la capactè e stockage sponble Archtecture réseau Il y a tros granes famlles e rèseaux sans fl : les rèseaux locaux sans fl [GBPK02], les grans rèseaux e communcaton hertzens [MP92] et les rèseaux satelltares [Lo91]. Les rèseaux locaux sans fl ont une portèe très rèute (ls sont conçus pour couvrr un bâtment ou un campus) mas une bane passante relatvement mportante (quelques zanes e Mbts par secone), alors que les grans rèseaux sont conçus pour couvrr un plus gran terrtore (une règon ou un pays) mas ont une bane passante beaucoup plus fable (e quelques Kbts par secones à quelques Mbts par secone). Les rèseaux satelltares ont ÈtÈ crèès pour couvrr toute la planète et ont une bane passante comparable à celle es grans rèseaux terrestres. Dans tous les cas, la bane passante un rèseau sans fl est beaucoup plus fable que celle un rèseau fxe (e quelques centanes e Mbts par secone à quelques Gbts par secone). DffÈrents supports e transmsson sont utlsès par les rèseaux locaux sans fl : l nfrarouge et les ones hertzennes. L nfrarouge permet un Èbt plus mportant mas est lmtè par sa portèe. En effet, les clents u rèseau ovent être «à vue» e l Èmetteur nfrarouge, et le rayonnement ne peut traverser les obstacles non transparents. Les ones hertzennes, par contre, permettent e traverser les murs mas ont une bane passante plus fable que l nfrarouge. Dans les eux cas, la portèe es Èmetteurs ne permettent pas e couvrr toute la surface voulue (tout un bâtment ou tout un campus). On a onc recours à la multplcaton es Èmetteurs. Chaque Èmetteur couvrant une cellule. Les rèseaux locaux sans fl permettent rarement e conserver la connexon en changeant e cellule.

19 19 Les grans rèseaux e communcaton sont tous basès sur les ones hertzennes. Même s leur portèe est ben plus grane que celle es rèseaux locaux, un même Èmetteur ne permet pas e couvrr toute la surface voulue (tout une règon ou tout un pays). On a onc, là auss, recours à la multplcaton es cellules, mas comme ce sont, à la base, es rèseaux e tèlèphone moble, la connexon ot être conservèe même en cas e changement e cellule. Les rèseaux satelltares sont, eux-auss, basès sur les ones hertzennes. Quelques satelltes gèostatonnares permettent e couvrr un large terrtore, mas leur très haute alttue (un peu plus e km) gènère une latence 1 mportante (quelques secones). De plus, un pett nombre e satelltes mplque qu ls ovent gèrer un nombre très mportant e connexons smultanèes. Pour rèure la complextè es satelltes et la latence, on a recours à toute une flotte e satelltes en orbte basse (vers 800 km) tournant autour e la terre. Les cellules sont onc elles auss mobles. En fat, tous ces types e rèseaux sans fl ont la même archtecture [PSa98] : ce sont tous es rèseaux cellulares (vor Fgure 2.1). Dans cette archtecture, les Hôtes Mobles (HM) sont connectès à un rèseau fxe va une Staton e Base (SB). Les hôtes mobles peuvent être un PC portable, un PDA, un tèlèphone ou même une carte à puce. Dans ce erner cas, la carte peut être sot nsèrèe ans un termnal moble (TM), qu lu est connectè au rèseau va une staton e base, sot nsèrèe ans un termnal fxe (TF) connectè rectement au rèseau flare. Chaque staton e base est responsable une cellule rao ou nfrarouge, et, le cas ÈchÈant, u protocole e changement e cellule. Un rèseau rape rele toutes les statons e base et Èventuellement es Hôtes Fxes (HF) et les termnaux e cartes à puce fxes. RÈseau Fxe HF HM SB HF SB TM TF Fgure 2.1 : Archtecture matèrelle es rèseaux sans fl. Les caractèrstques gènèrales es rèseaux sans fl sont onc : Un coût e communcaton ÈlevÈ, u pont e vue e la bane passante et, accessorement, u pont e vue e la tarfcaton, beaucoup plus ÈlevÈe que pour une communcaton passant par un rèseau flare. 1 C est le temps ms entre l Èmsson un message et sa rècepton par son estnatare.

20 20 Une latence mportante, comparatvement à celle un rèseau fxe, car plus le rèseau compren e cellules, plus l faut e temps pour localser l hôte moble ÈsrÈ. Les communcatons sans fl sont souvent asymètrques (la bane passante est plus fable u moble vers la staton e base, que ans l autre sens). Il exste es zones ombre, c est à re es zones ans lesquelles la connexon au rèseau sans fl est mpossble (les tunnels, par exemple). Cela peut entraîner es Èconnexons non prèvues s un moble entre ans un telle zone. Comme ls explotent es ones rao, les rèseaux sans-fl sont ben aaptès à la ffuson. Les protocoles transactonnels evront onc s aapter à la fable bane passante et la grane latence, et evront supporter es Èconnexons ntempestves pour être effcace en envronnement moble. En revanche, ls pourront profter u moe e communcaton par ffuson offert par les rèseaux sans fl Archtectures logcelles IntÈressons nous mantenant aux archtectures logcelles pouvant être mses en place pour gèrer la mobltè es calculateurs. Nous nous ntèressons c à la geston e la communcaton entre calculateurs fasant ntervenr es lens e communcaton sans fl (entre eux hôtes mobles ou entre un hôte moble et un hôte fxe) Clent/Serveur classque La premère soluton consste à utlser le moèle clent/serveur ben connu. Dans une telle archtecture, le clent se connecte rectement à un serveur. Le problème c est qu une Èconnexon u clent est consèrèe par le serveur comme une panne, ce qu peut entraîner l abanon es transactons en cours. On ne peut onc pas utlser rectement une archtecture clent/serveur classque applquèe ans le care es rèseau sans fl Clent/Agent/Serveur Comme les calculateurs mobles ont une nterface utlsateur rèute, les applcatons clentes ovent souvent être rèècrtes. Mas, par contre, le serveur n a aucune rason être mofè. C est pourquo une premère amèloraton u moèle clent/serveur a consstè en l ntroucton un agent sur le rèseau fxe [ZeDu97]. Cet agent reprèsente le clent auprès u serveur e façon à masquer la Èconnexon u clent. La communcaton entre le serveur et l agent peut onc se fare

21 21 à l ae e protocoles stanars, alors que la communcaton entre le clent et son agent emane es protocoles partculers (pour gèrer la Èconnexon). L agent pren onc en charge une fle attente e messages à estnaton u clent moble. Cette archtecture, nommèe Clent/Agent/Serveur, permet onc e renre la Èconnexon u clent moble transparente pour le serveur. Elle est ben aaptèe aux clents lègers, même s elle mplque la rèècrture e l applcaton clente pour pouvor gèrer es protocoles spècfques Clent/Agent/Agent/Serveur ou Clent/Intercepteur/Serveur Pour les clents sposant e plus e ressources, ou voulant smplement contnuer à utlser les protocoles Èfns entre clent et serveur, une autre soluton s mpose [SaP97]. Elle consste à ajouter un nouvel agent, sur le clent moble, reprèsentant le serveur. Cet agent a un rôle symètrque à celu u clent sur le rèseau fxe. De cette façon, le clent a, lu auss, l mpresson être toujours connectè au serveur. Les agents u clent et u serveur sont responsables e la geston e la communcaton sur le rèseau moble (fles attente e messages, protocoles partculers, ). Cette soluton a onc l avantage e renre la Èconnexon complètement transparente auss ben pour le serveur que pour le clent, elle n mpose onc aucune mofcaton en profoneur es applcatons clentes et serveur. Mas c est une soluton assez loure qu nècesste es ressources mportantes sur le moble Serveur/Serveur IntÈressons nous mantenant au tratement coopèratf entre pluseurs serveurs mobles. Dans les rèseaux cellulares, la communcaton recte entre mobles est mpossble, ls ovent toujours passer par la staton e base e la cellule ans laquelle ls se trouvent. Pour gèrer leur Èconnexon, l va fallor placer un agent sur chaque serveur. Cet agent est responsable e la fle attente es messages Èms par le serveur sur lequel l se trouve. Mas s un serveur moble veut communquer avec un autre serveur moble, l faut qu ls soent connectès smultanèment, ce qu n est pas toujours possble. Pour rèsoure ce problème, l n y a autre soluton que e placer, sur le rèseau fxe, pour chaque serveur moble, un agent responsable e la fle attente e messages reçus. Cette archtecture ressemble à un servce postal. Chaque moble, lorsqu l se connecte au rèseau, consulte sa bote postale pour rècupèrer ses messages, et poste les messages qu l avat ms en attente lorsqu l Ètat ÈconnectÈ. Dans le contexte e la communcaton entre serveurs mobles, cette archtecture nècesste non seulement es ressources sur les mobles, mas Ègalement sur le rèseau fxe.

22 22 6. Applcatons mobles Dans cette secton, nous scutons es classes applcatons pour mobles. Nous classons ces applcatons en foncton e leur moe e communcaton (avec ou sans sesson e communcaton avec un ou pluseurs serveurs partculers) et u rôle es mobles (smples clents ou serveurs) Dffuson nformatons La premère classe regroupe toutes les applcatons basèes sur la ffuson nformatons telles que les applcatons nformatons boursères, mètèorologques ou e conton e crculaton. Un ou pluseurs serveurs basès sur le rèseau fxe Èmettent règulèrement es onnèes estnèes aux clents mobles. Les clents mobles ont juste à se mettre à l Ècoute et sèlectonner les nformatons qu les ntèressent. La communcaton se fat le plus souvent en sens unque, un serveur vers ses clents. Il n y a onc pas beson c e mantenr une sesson e communcaton entre un clent moble et un serveur fxe. Les applcatons mobles e cette classe font peu ou pas e tratement sur les onnèes ffusèes. La plupart u temps, elles ne font que prèsenter ces nformatons e façon comprèhensble à l utlsateur, mas ans certans cas, un calcul sur les nformatons reçues peut être nècessare, comme l explotaton es nformatons e conton e crculaton pour chosr le melleur tnèrare sur une carte Èjà embarquèe sur le moble. Pour supporter la Èconnexon un moble, par exemple lorsqu l entre ans une zone ombre, l sufft à ce erner e mantenr en cache les ernères nformatons reçues. Le Èfaut un telle stuaton event le manque e fraîcheur es nformatons prèsentèes à l utlsateur. Comme l n y a pas e sesson e communcaton ans cette classe applcaton, l n y a pas non plus beson e technques transactonnelles Hôte moble ntateur e transactons La euxème classe applcatons mobles regroupe celles ont le clent est moble mas où l ntègraltè es tratements sont effectuès sur un serveur fxe. L applcaton clente n est onc consttuèe que e l nterface utlsateur. Les applcatons e type navgateur Web ou termnal accès à es bases e onnèes entrent ans cette classe. Ic, la communcaton se fat ans les eux sens, mas une sesson e communcaton n est pas oblgatore. En effet, la consultaton e serveurs Web se fat en moe ÈconnectÈ, ans le sens où la connexon entre le navgateur et le serveur n est pas mantenue après le tèlèchargement complet e la page Web concernèe. Par contre, les applcatons e consultaton e bases e onnèes nècesstent une sesson e communcaton urant laquelle l utlsateur est authentfè pour la geston es rots accès sur les onnèes. Dans ce contexte, la geston e transacton est nècessare pour assurer la cohèrence e

23 23 onnèes. Comme le clent moble n effectue aucun tratement sur les onnèes, les transactons sont onc locales au serveur fxe. Le prncpal problème pour cette classe applcaton est la geston e la connexon. En effet, en cas e Èconnexon, l ne faut pas que la transacton en cours sot abanonnèe, l faut onc utlser une archtecture e type Clent/Agent/Serveur ou Clent/Intercepteur/Serveur. De plus, lorsque le clent est ÈconnectÈ et s le serveur fxe utlse un protocole e contrôle e concurrence pessmste (ce qu est gènèralement le cas), les onnèes accèèes par la transacton en cours ne seront pas accessbles à autres utlsateurs avant sa termnason. Il faura onc Èfnr es protocoles transactonnels permettant un bon nveau e concurrence tout en mnmsant le taux abanon es transactons Serveur moble en moe connecté Une autre classe applcatons ntèressante est celle es serveurs mobles. Dans cette classe, les clents, qu ls soent mobles ou fxes (e toute façon, ls passent par les statons e base) accèent à es onnèes embarquèes sur un calculateur moble. Ben sûr, ces onnèes ne sont accessbles que urant la connexon u serveur moble au rèseau. Les applcatons reprèsentatves e cette classe sont les applcatons carte à puce comme le porte-monnae Èlectronque, où, lors un paement avec la carte ou lors un crèt pour la recharger, une transacton strbuèe se Èroule alors entre le porte-monnae Èlectronque et une banque. Une autre applcaton e ce type, plus complexe, est la geston es agenas mobles. Par exemple, une secrètare peut voulor nsèrer ou mofer un renez-vous ans l agena hèbergè sur le PDA e son patron. S le renez-vous ot être ÈplacÈ, cette opèraton ot être exècutèe ans le care une transacton pour assurer la cohèrence es onnèes. Ce renez-vous peut même être prs rectement entre les agenas Èlectronques es ffèrents partcpants, ce qu emane là encore, une transacton rèparte. Il y a onc beson e gèrer es transactons locales sur le moble, ans que e permettre à celu-c e partcper à es transactons rèpartes Serveur moble en moe éconnecté Les calculateurs mobles autonomes peuvent contnuer à travaller même lorsqu ls sont hors connexon. Cela veut re qu un serveur moble peut trater les emanes e ses clents alors qu l n est plus connectè au rèseau, pus lu renvoyer les rèsultats au moment e la reconnexon. De même, un calculateur moble, s l veut contnuer à travaller tout en Ètant hors connexon, evra rèplquer les onnèes nècessares u (ou es) serveur(s) corresponant(s) avant e se Èconnecter u rèseau, pus les rèntègrer sur ce(s) même(s) serveur(s) à la reconnexon. Dans ce cas, l peut y avor partage e onnèes entre ffèrents clents, ce qu nècesste es technques transactonnelles

24 24 pour assurer la cohèrence es onnèes lors es accès concurrents. La ffcultè, pour les clents, est e prèvor e quel ensemble nformatons l aura beson pour contnuer à travaller. Un exemple e ce type applcaton est celle u reprèsentant e commerce. Avant e commencer sa tournèe, l tèlècharge sur son moble les fches e ses clents et es prouts qu l est sensè venre. Ensute, lors e sa tournèe, où l peut être ÈconnectÈ u rèseau, l enregstre les ffèrentes commanes e ses clents, qu seront rèntègrèes ans la base e onnèes e son entreprse ès son retour. Le calcul en moe ÈconnectÈ nècesste onc es technques e rèplcaton et e transacton pour assurer la cohèrence e l ensemble es onnèes (celles u serveur et auss celles es ffèrents rèplquas). Un autre problème concerne la capactè e stockage sur les calculateurs mobles. En effet, rèplquer une parte es onnèes pour pouvor contnuer à travaller tout en Ètant ÈconnectÈ suppose qu l y at suffsamment e place sur le moble. Cec peut être une contrante forte sur certans types e calculateurs mobles. 7. Moèles e transacton ACID Dans cette secton, nous allons aborer les moèles e transactons pour mobles respectant l ntègraltè es proprètès ACID. Les caractèrstques e l envronnement moble sont les suvantes : Des ressources locales lmtèes sur les mobles (pussance e calcul, capactè e stockage, ) ; Un coût e communcaton très ÈlevÈ (auss ben en terme e bane passante que e coût fnancer); Une latence es communcatons mportante ; Des Èconnexons u rèseau sans fl qu peuvent être frèquentes (hors zone e couverture, pour Èconomser les batteres, ) Nous allons Ètaller, proprètè par proprètè, quels sont les problèmes exacts posès par la mobltè, et quels sont les avantages et nconvènents es ffèrentes solutons possbles Atomcté Comme nous l avons vu plus tôt, la proprètè atomctè assure que les opèratons effectuèes ans le care une transacton seront toutes exècutèes correctement, ou ben aucune ne sera

25 25 exècutèe. Les transactons rèpartes sont consttuèes e ffèrentes branches e transactons (sous-ensembles opèratons) exècutèes sur es stes ffèrents. La proprètè atomctè ot être assurèe, sur chaque ste, pour chaque branche e transacton nvuellement (atomcté locale), mas auss pour l ensemble es opèratons e la transacton rèparte (atomcté globale) Atomcté locale Pour assurer l atomctè locale, l faut être capable annuler les opèratons effectuèes ans le care une transacton. En effet, la règle or e l atomctè est que toute la transacton ot être annulèe s une seule e ses opèraton gènère une erreur. S, au cours e l exècuton e la branche e transacton, une opèraton ne s exècute pas correctement (en volant une autre es proprètès ACID, par exemple), alors tous les effets es opèratons prècèentes ovent être annulès. De plus, même s toute la branche e transacton s exècute correctement, la transacton peut être abanonnèe pour un problème exècuton sur une autre branche e transacton, ce qu entraîne, là encore, l annulaton es effets es opèratons correctement exècutèes sur le ste local. Il y a eux solutons pour pouvor annuler es opèratons exècutèes [BCF97] : sot on conserve les valeurs avant mofcaton es onnèes mses à jour par la branche e transacton (journal mages avant ou traval sur une cope es onnèes), sot on est capable e compenser chaque opèraton (c est-à-re trouver, pour chaque opèraton e la branche e transacton, une opèraton qu a exactement l effet nverse). Il sufft onc, ans ce erner cas e conserver l hstorque es opèratons e la branche e transacton. Plaçons nous ans le contexte es transactons en envronnement moble. Le plus gros problème est la Èconnexon. En effet, un calculateur moble ot être capable annuler une branche e transacton e façon complètement autonome (en moe ÈconnectÈ). Les nformatons nècessares pour l annulaton ovent onc être stockèes sur le moble, ce qu consomme es ressources locales. Dans le cas e l utlsaton un journal mages avant, la consommaton espace peut être relatvement mportante. En effet, une opèraton e mse à jour ensemblste peut entraîner la journalsaton e nombreuses valeurs. Il peut onc être plus ntèressant e ne journalser que les opèratons et e les compenser. Mas toutes les opèratons ne peuvent être compensèes. Par exemple, une opèraton e mse à jour arbtrare, comme celle qu force la valeur un attrbut, ou une opèraton e suppresson ne peut être annulèe sans connaître l ancenne valeur. La compensaton es opèratons, même s elle consomme mons e ressources sur le moble, ne peut être avantageusement utlsèe que pour certanes classes applcaton partculères (comme les applcatons fnancères où les opèratons sont es Èbts ou es crèts). La journalsaton es

26 26 valeurs es onnèes avant mofcaton est applcable ans tous les cas mas elle a le Èsavantage e consommer es ressources plus mportantes Atomcté globale L atomctè globale concerne l ensemble es branches e transacton. Le but c est e synchronser tous les partcpants une transacton pour qu ls valent tous ou qu ls abanonnent tous la transacton. Comme chaque partcpant assure l atomctè locale, l sufft e valer la transacton s tous les partcpants ont correctement exècutè leur branche e transacton, ou annuler s au mons un es partcpants a û annuler sa branche, grâce à un protocole e valaton atomque. La geston e l atomctè globale est confèe à un Coornateur qu est chargè e se rensegner sur l exècuton es ffèrentes branches e transacton et e Ècer s l ensemble e la transacton ot être valèe ou abanonnèe. Le protocole e valaton atomque le plus utlsè est le Two- Phase Commt (2PC) [Gray78]. Comme son nom l nque, le 2PC est consttuè e eux phases. Lors e la premère phase (la phase e Vote), le coornateur contacte tous les partcpants e la transacton pour savor comment s est ÈroulÈe l exècuton e sa branche e transacton. Cette phase a gènèralement pour but e forcer les partcpants à se mettre ans un Ètat prêt à valer (c est-à-re que toutes les proprètès ACID sont assurèes localement). Un partcpant qu arrve à se mettre ans cet Ètat rèpon Prêt au coornateur. Un partcpant ne pouvant pas se mettre ans cet Ètat rèpon Abanon. A la fn e cette phase, le coornateur a toutes les nformatons nècessares à sa Ècson ans sa possesson. S un seul es partcpants ne peut pas valer (volaton es proprètès ACID locales ou panne), la Ècson est l abanon pour tous les partcpants. La euxème phase u 2PC est la ffuson aux partcpants e la Ècson u coornateur. Ce qu a pour effet e fare valer ou abanonner Èfntvement les partcpants. Le coornateur atten la confrmaton e tous les partcpants avant e pouvor oubler la transacton. En effet, en cas e panne un partcpant lors e la secone phase, le coornateur pourra renvoyer la Ècson à ce partcpant lorsqu l revenra. L utlsaton un tel protocole ne convent pas ans le contexte es transactons en envronnement moble. En effet, ans ce type e protocole la Èconnexon un partcpant est vue comme une panne, ce qu a pour effet l annulaton e la transacton. Même s ce protocole est mofè pour supporter les Èconnexons, sa latence reste mportante : un partcpant ne peut pas valer ou abanonner une branche e transacton localement sans avor reçu la Ècson u coornateur, qu lu ot avor reçu les votes e tous les partcpants. Tant qu une transacton est en attente, les ressources qu elle moblse ne sont plus sponbles pour autres transactons, ce qu rèut le

27 27 nveau e concurrence possble. De plus, le coût es communcatons en envronnement moble est hancapant pour les eux phases Èchanges e messages u 2PC Cohérence La cohèrence est une proprètè locale. Elle assure que les contrantes ntègrtè Èventuellement Èfnes sur les onnèes sont vèrfèes. Les contrantes ntègrtè peuvent être vèrfèes mmèatement ou à la fn une transacton (contrante ntègrtè ffèrèe). La vèrfcaton es contrantes ntègrtè Èfnes sur un ensemble e onnèes peut fare ntervenr un sur-ensemble nformatons, comme ans le cas es contrantes ntègrtè rèfèrentelles. La vèrfcaton es contrantes ntègrtè, s elle ot être rèalsèe sur un calculateur moble ÈconnectÈ u rèseau, suppose que toutes les nformatons nècessares soent stockèes sur celuc. Le moèle PRO-MOTION [WaCh99] propose ce type e soluton. Pro-moton est un système e geston e transactons, supportant la Èconnexon, basè sur la noton e Compact. Le compact est l untè Èchange e onnèes entre les hôtes mobles et les hôtes fxes. Comme le montre la Fgure 2.2, un compact est un ensemble cohèrent e onnèes. C est à re qu en plus es onnèes et es mèthoes et varables e geston u compact et e son Ètat, l nclut es nformatons sèmantques sur les onnèes, comme les mèthoes accès spècfques à celles-c, ans que les mèthoes permettant e vèrfer leur ntègrtè (l content onc toutes les nformatons nècessares). Les compacts sont nègocès entre les serveurs fxes et les mobles pour une urèe ÈtermnÈe, pouvant Èventuellement être prolongèe (au elà, toute les transactons accèant aux onnèes u compact seront abanonnèes). Les contrantes ntègrtè peuvent être vèrfèes pour chaque opèraton ou au moment e la valaton. Ce moèle gère onc les contrantes ntègrtè mmèates et ffèrèes. ealne Contrantes ntègrtè nqure () notfy () spatch () commt () abort () DONNEES MÈthoes spècfques Etat Fgure 2.2 : Structure 'un compact

28 28 Un tel moèle permet onc assurer la cohèrence es onnèes sur le moble mas, en revanche, l nut une forte consommaton e ressources sur le moble. Ce qu peut être un hancap pour certans calculateurs mobles. Une autre soluton est e ne vèrfer les contrantes ntègrtè qu au moment e la reconnexon u moble au rèseau. Le moèle es Tentatve Transactons [GHOS96] sut cette Èe. Dans ce moèle, le calculateur moble embarque une cope es onnèes provenant un ou pluseurs serveurs fxes. Une transacton peut être localement valèe (sous rèserve e cohèrence es onnèes). Pus, au moment e la reconnexon, la transacton est rè-exècutèe sur le rèseau fxe pour s assurer e la prèservaton e la cohèrence. S le rèsultat est le même, alors la transacton est Èfntvement valèe sur le moble, snon, la transacton peut être sot annulèe, sot fare l objet une rèconclaton. Le problème e ce moèle est qu l peut entraîner es abanons e transactons en cascae. En effet, s, sur un moble, une transacton ot être annulèe après reconnexon et vèrfcaton es contrantes ntègrtè sur le ou les serveur(s) fxe(s) alors que autres transactons ont effectuè es tratements sur ses rèsultats locaux, ces ernères ovent auss être annulèes. En rèsumè, sot les contrantes ntègrtè sont vèrfèes sur le moble, ce qu peut entraîner une sur-consommaton e ressource e stockage sur le moble, sot elles sont vèrfèes sur le rèseau fxe, ce qu peut entraîner es annulatons en cascae e transactons exècutèes en moe ÈconnectÈ Isolaton L solaton consste à fare en sorte que l exècuton concurrente e transactons sot Èquvalente (c est-à-re onne le même rèsultat) que l exècuton e ces mêmes transactons les unes après les autres (cette proprètè est auss appelèe séralsablté). Il exste eux classes e mèthoes e contrôle e concurrence pour assurer la sèralsabltè es transactons concurrentes sur un ste: les mèthoes pessmstes et les mèthoes optmstes. Les mèthoes pessmstes effectuent un contrôle contnu en Ètectant les conflts au fur et à mesure e leur apparton. Pour cela, es crtères e séralsablté sont Èfns. Ces crtères sont es contons nècessares pour assurer la sèralsabltè es transactons. Ils sont vèrfès pour chaque nouvelle opèraton entrant en conflt avec une es prècèentes. S le crtère n est pas vèrfè la transacton concernèe est sot mse en attente, sot abanonnèe. Un exemple e contrôle e concurrence pessmste est le protocole Two-Phases Lockng (2PL) [EGLT76] ben connu. Le 2PL repose sur l utlsaton e verrous. A chaque objet est assocè eux types e verrous : les verrous en lecture et les verrous en Ècrture. Verrou Ce protocole e contrôle e concurrence est composè Verrou Ètenu emanè Lecture Écrture Lecture Ou Non Écrture Non Non

29 29 en eux phases, pour chaque transacton : une premère phase acquston e verrous et une euxème phase e lbèraton e verrous. Dans le cas e la verson strcte u 2PL, la euxème phase ot se Èrouler à la valaton e la transacton. Toute transacton evant accèer à un objet ot, au prèalable, poser un verrou corresponant au type opèraton sur cet objet. Les conflts ntervennent lorsque eux transactons veulent poser un verrou sur un même objet. Les crtères e sèralsabltè sont les règles e compatbltè entre les ffèrents verrous (vor Tableau 2.3). S le crtère est vèrfè, la transacton obtent mmèatement le verrou, ans le cas contrare, elle est mse en attente jusqu à la lbèraton u (ou es) verrou(s) bloquant(s), c est à re la termnason e la (ou es) transacton(s) bloquante(s). Verrou Verrou Ètenu emanè Lecture Lecture Ou Écrture Non Écrture Non Non Tableau 2.3 : CompatbltÈ entre verrous. Les mèthoes e contrôle e concurrence optmstes, elles, lassent s exècuter lbrement les transactons et ne vèrfent les crtères e sèralsabltè qu au moment e la valaton es transactons (c est la phase e certfcaton). S une transacton ne vèrfe pas un es crtères, elle ot être abanonnèe et rejouèe. Ces mèthoes msent sur un taux e conflts fable. En effet, le rsque que les transactons ne soent pas sèralsables augmente avec le nombre e conflts. Les transactons evant être abanonnèes consomment alors nutlement es ressources. La certfcaton par ensemble objets est une mèthoe optmste e contrôle e concurrence. Dans cette mèthoe, nous allons vèrfer qu une transacton entrant en phase e certfcaton n entre en conflt avec aucune es transactons concurrentes Èjà valèes. Pour cela, nous mantenons l ensemble E val es objets Ècrts par les transactons Èjà valèes, concurrentes avec la transacton en cours T. Pour la transacton T, nous mantenons les ensembles L T et E T es objets lus et Ècrts par T respectvement, l ensemble E T servant à gènèrer E val pour les futures certfcatons. Le crtère e sèralsabltè est l absence objets communs entre E val et L T, c est à re que la transacton T ne ot pas avor lu objets mofès par une es transactons concurrentes valèes. S l exste une ntersecton à ces eux ensembles, la transacton T ot être abanonnèe. Le problème en envronnement moble est que, pour pouvor travaller en moe ÈconnectÈ, la rèplcaton es onnèes partagèes est nècessare. En effet, l ne sufft pas assurer la sèralsabltè sur chaque rèplqua. Dans l exemple e la Fgure 2.4(a), eux objets logques A et B sont rèplquès sur eux stes S 1 et S 2. les objets A 1, A 2, B 1 et B 2 sont les objets physques rèsultant e cette rèplcaton. Deux transactons T 1 et T 2 accèent à ces ffèrents rèplquas : T 1 mofe les

30 30 valeurs es objets logques A et B sur S 1 pus sur S 2, alors que T 2 lt les valeurs e A sur S 1 et e B sur S 2. T 1 Wrte(A 1 ) Wrte(B 1 ) Wrte(A 2 ) Wrte(B 2 ) T 1 Wrte(A) Wrte(B) T 2 Rea(A 1 ) Rea(B 2 ) (a) Exécuton réelle T 2 Fgure 2.4 : SÈralsabltÈ à une cope Rea(A) Rea(B) (b) Exécuton équvalente à une cope Dans l exècuton es transactons prèsentèe en Fgure 2.4(a), les transactons sont sèralsables sur les stes S 1 (T 1 mofe A 1 et B 1, pus T 2 lt A 1 ) et S 2 (T 2 lt B 2 pus T 1 mofe A 2 et B 2 ). On peut vor que T 2 lt la valeur e B sur S 2 avant que la mofcaton effectuèe par T 1 ne sot reportèe, alors qu elle a vu la valeur e A mofèe. Cette exècuton n est onc pas sèralsable globalement car T 2 vot un Ètat ntermèare es onnèes. Pour être sûr qu une exècuton sot globalement sèralsable, l faut que l exècuton Èquvalente sur les objets logques A et B sot elle-même sèralsable (c est la séralsablté à une cope). La Fgure 2.4(b) reprèsente cette exècuton logque. Elle n est clarement pas sèralsable. L solaton Èpen onc es technques utlsèes pour assurer la cohèrence es ffèrents rèplquas, c est-à-re u moe e propagaton es mses à jour effectuèes sur un es rèplquas, ans que u moe e contrôle e copes choss Moes e propagaton La propagaton es mses à jour effectuèes sur les rèplquas peut se fare e eux façons : sot les mses à jour sont reportèes sur l ensemble es rèplquas ans une même transacton strbuèe (rèplcaton synchrone), sot elles sont reportèes ans le care une autre transacton (rèplcaton asynchrone) Réplcaton synchrone Dans le cas e la rèplcaton synchrone (Fgure 2.5), les mses à jour sont effectuèes sur tous les rèplquas ans la même transacton. L avantage est que l on est sûr que tous les rèplquas ont la même valeur à la fn une transacton. Mas l faut que tous les serveurs contenant es rèplquas soent accessbles pour pouvor termner la transacton (ls partcpent tous à la même transacton rèparte), ce qu ne peut être garant ans le contexte es transactons en envronnement moble et peut onc entraîner l abanon e nombreuses transactons, ou smplement augmenter le temps nècessare à leur valaton (ce qu nut à la sponbltè es onnèes).

31 écrre A1 écrre A2écrre A3 écrre B1 écrre B2écrre B3 valer valer valer 31 Ce moe e propagaton n est onc pas ben aaptè à la mobltè. Transacton T ste S1 ste S2 ste S3 Fgure 2.5 : RÈplcaton synchrone Réplcaton asynchrone La rèplcaton asynchrone (Fgure 2.6) reporte les mses à jour effectuèes par une transacton T ans le care une autre transacton T nèpenante (et onc en ffèrè). Le prncpal avantage est que tous les rèplquas n ont pas à être accessbles en même temps. Par contre, à la fn e la transacton T, tous les rèplquas n ont pas nècessarement la même valeur. Toute transacton s exècutant sur les ancennes valeurs es objets mofès par T après sa valaton evront être abanonnèes. La cohèrence es rèplquas Èpen onc un autre crtère : le moe e contrôle es copes. T1 sur S1 écrre A1 écrre B1 valer T2 sur S2 écrre A2 écrre B2 valer T3 sur S3 écrre A3 écrre B3 valer Fgure 2.6 : RÈplcaton asynchrone.

32 Moes e contrôle Moe asymétrque Dans le moe e contrôle asymètrque, toutes les mses à jour un objet rèplquè sont effectuèes sur un seul ste (le ste maître), tous les autres stes sont en lecture seule (Fgure 2.7). Le ste maître est onc chargè assurer la sèralsabltè es transactons (à l ae e protocoles e contrôles e concurrence, qu ls soent pessmstes ou optmstes). Cepenant, la cope maître ot être accessble pour qu une transacton pusse fare es mses à jour, ce qu ntert le traval en moe ÈconnectÈ. Pour supporter la Èconnexon ue à l envronnement moble, l fat onc pouvor ÈlÈguer le rot e mse à jour sur les onnèes. Mofer A Mofer A Mofer A A1 A2 A3 Fgure 2.7 : Moe e contrôle asymètrque. La premère Èe consste à lasser fare les protocoles classques (comme le verroullage à eux phases), qu vont consèrer une Èconnexon e plus une certane urèe comme une panne. Cela veut re qu un moble ot se reconnecter règulèrement au ste maître pour ne pas vor sa transacton abanonnèe. La ffcultè est e chosr la urèe maxmale e Èconnexon [Kum00]. S elle est prse trop courte, le rsque abanon e transactons va augmenter. S elle est chose trop longue, cela pose es problèmes u pont e vue e la concurrence (les ressources restent naccessbles aux autres transactons). De plus cette urèe maxmale Èpen u protocole e contrôle e concurrence et non es onnèes (une onnèe manpulèe frèquemment par es transactons sera plus pènalsante, au nveau e la concurrence, qu une onnèe peu mofèe). Une amèloraton consste en la nègocaton entre le ste maître et le rèplqua e la ate lmte à laquelle la transacton ot être termnèe, cette ate evant Èpenre es onnèes concernèes ans que e leur contexte utlsaton (nveau e concurrence, entre autres). De plus, le moble ne evra se reconnecter qu une seule fos (à la termnason e la transacton) avant la ate lmte, et non à ntervalles règulers. Le moèle Pro-Moton [WaCh99], prèsentè plus haut, fournt ce type e servce (les compacts ont une urèe e ve lmtèe au-elà e laquelle les transactons les manpulant evront être abanonnèes). Le problème ans ces eux types e solutons, c est que les onnèes ne sont mofables que par une seule transacton à la fos, ce qu lmte la concurrence. Une autre Èe est utlser la sèmantque es onnèes pour permettre es accès smultanès sur es fragments une même

33 33 onnèe. Par exemple, pour une applcaton e geston e commanes, les reprèsentants e commerce vont vrtuellement se partager les stocks e prouts (par exemple, s l y a 200 exemplares un prout à venre pour 10 reprèsentants, on peut attrbuer 20 exemplares par reprèsentant). Le moble emporte et trate ses fragments et evra les rèntègrer sur le ste maître à la fn e ses tratements. L ntèrêt est augmenter le nveau e concurrence sans voler les contrantes ntègrtè (on ne peut pas venre plus e prouts qu l n y en a en stock). Le protocole Ste Escrow [KrBe92] propose ce type e soluton, mas gare la rèpartton es fragments au nveau u ste maître (ce sont onc les mêmes contrantes ntègrtè, qu ne sont contrôlèes que sur le ste maître). Une amèloraton, nommèe Reservaton Algorthm [EJB95], transfère rèellement les fragments vers le moble en mofant les contrantes ntègrtè sur le moble et sur le ste maître. Le moble event onc ste maître pour son fragment et est onc responsable u respect es contrantes ntègrtè Èfnes sur les fragments. S un moble sparaît (se Èconnecte pour une longue urèe), ses fragments sparassent avec lu, mas ce n est trop contragnant pour les autres transactons car elles sposent es autres fragments pour effectuer leurs tratements. Ce type e soluton permet onc accroître la concurrence mas n est pas applcable ans tous les cas : l faut que les onnèes gèrèes pussent être ÈcoupÈes en fragments (une aresse, par exemple, n est pas fragmentable). Un autre problème se pose ans le cas e la rèplcaton asymètrque : les mofcatons n Ètant effectuèes que sur un seul ste, l faut que les autres rèplquas (qu n ont qu un accès en lecture seule) sache quan mettre à jour leur cope. Il exste eux classes e mèthoes pour rèsoure ce problème : sot le ste maître prèvent les rèplquas es mofcatons, sot les rèplquas ovent eux-même vèrfer qu ls sont à jour. La premère soluton est ben aaptèe à l envronnement moble car elle fat ntervenr la ffuson. Le ste maître peut ffuser, à ntervalles règulers, les valeurs es objets ayant ÈtÈ mofès, mas cela revent cher car les communcatons sans fl sont coûteuses. Une alternatve consste à ffuser plus smplement les entfants es objets mofès [BaIm94], les mobles evant alors rècupèrer la valeur auprès u ste maître. Lorsque les onnèes sont souvent mofèes, le volume nformatons à ffuser event mportant. Le moble evra onc rester plus longtemps à l Ècoute u ste maître pour recevor les entfants es objets qu l hèberge, ce qu augmente autant le coût u protocole. Une soluton à ce problème est e ffuser non pas les entfants es objets mofès, mas es sgnatures numèrques (obtenues par hachage) e ces entfants [BaIm94]. L avantage est ouble : une part, les nformatons à transmettre sont plus courtes ; autre part, les sgnatures peuvent être agrègèes par combnason logque, ce qu permet e compresser les nformatons à ffuser. Par contre, ce genre e procèè ajoute un certan «brut» : les mobles peuvent crore qu une parte es objets qu ls hèbergent ont ÈtÈ mofès car ls vèrfent la sgnature reçue, alors que ce n est pas le cas. Ce brut entraîne une

34 34 augmentaton es chargements e valeurs par les mobles. Le rapport sgnal/brut peut être ajustè en foncton u nombre e sgnatures agrègèes avant ffuson. Dans la euxème approche, ce sont les mobles qu se reconnectent au ste maître pour vèrfer que leurs rèplquas sont à jour. Cec peut être faclement rèalsè en plaçant es estamplles (ate e ernère mofcaton) sur les onnèes u ste maître. Le moble, lorsqu l se reconnecte, envoe au ste maître les estamplles obtenues lors e la rèplcaton, ce erner renvoe alors les valeurs es objets mofès avec leur nouvelle estamplle. Dans cette mèthoe le ste maître fat onc tout le traval, mas par contre, les mobles rsquent apprenre plus tar que les onnèes sur lesquelles l travallent ne sont plus à jour. En effet, ans le cas e la ffuson, les mobles peuvent savor très rapement quelles sont les onnèes evant être actualsèes et ne plus les utlser en attenant le transfert u ste fxe, alors que ans l autre cas, l ot se connecter au ste maître pour obtenr les valeurs es onnèes mofèes sans savor lesquelles à pror. S le moble se Èconnecte avant que le ste maître n at tout transfèrè, le moble ne peut pas savor quelles onnèes l ne evra plus utlser Moe symétrque Dans le moe e rèplcaton symètrque, tout ste peut mettre à jour sa cope locale sans prèvenr les autres (Fgure 2.8). Il assure la sèralsabltè locale es transactons mas peut entraîner es vergences entre les rèplquas, vergences qu ovent être contrôlèes. L ntèrêt e ce type e rèplcaton est que tous les stes sont autonomes (l n y a pas à se connecter sur un ste partculer pour fare e mofcaton e onnèes rèplquèes), ce qu augmente largement le nveau e concurrence, ans que la possbltè e traval en moe ÈconnectÈ. Il est onc ben aaptè aux envronnements mobles. Par contre, s l on veut assurer l solaton strcte es transactons globales (sèralsabltè à une cope), une seule es transactons conflctuelles (c est-à-re manpulant les mêmes objets en même temps sur es rèplquas ffèrents) peut être valèe, toutes les autres evant être abanonnèes. Le ste qu vale sa transacton ot onc ausstôt sgnaler aux autres rèplquas les mofcatons qu ont ÈtÈ valèes, car toute transacton s exècutant sur les ancennes valeurs ot être abanonnèe et rejouèe. Mofer A A1 A2 Mofer A Mofer A A3 Fgure 2.8 : Moe e contrôle symètrque.

35 35 Pour lmter le taux abanon es transactons concurrentes, nous pouvons lasser les transactons concurrentes s exècutant sur es rèplquas ffèrents valer localement. Cec peut entraîner une vergence entre rèplquas. Il faura ensute utlser es technques e rèconclaton pour assurer la convergence es copes (proprètè plus fable que la sèralsabltè à une cope). C est à re que les ffèrents rèplquas ovent fnr par converger vers un Ètat unque, ce qu ne convent pas à certanes classes applcaton (toute applcaton fasant ntervenr es paements ot assurer la sèralsabltè à une cope). La rèconclaton peut être : Manuelle : en cas e constat une vergence lors e la propagaton es mofcatons effectuèes par une transacton valèe vers les autres rèplquas, les ffèrents utlsateurs sont averts et ovent se contacter pour se mettre accor sur un Ètat commun. Ce type e rèconclaton permet que l Ètat fnal es rèplquas fasse l unanmtè, mas peut être coûteuse car l faut que tous les utlsateurs se contactent, ce qu peut être très long en envronnement moble u fat es Èconnexons. Automatque : l Èe c est e ne pas fare ntervenr utlsateur pour obtenr une vtesse e convergence maxmale. La soluton la plus smple consste à applquer successvement les mses à jour un même objet. Dans ce cas, la ernère transacton à valer Ècrase les mses à jour es prècèentes. On arrve onc rapement à la convergence es copes mas au rsque e perre l effet e certanes transactons. D autres solutons, venant es systèmes e traval collaboratf [SJYZ97][VCFS00] utlsent la sèmantque es opèratons pour rèsoure plus fnement les conflts. Ces technques permettent e converger rapement tout en conservant, autant que possble, l effet e toutes les transactons valèes, mas elles font es chox arbtrares pour rèsoure les conflts, ce qu peut ne pas convenr aux ffèrents utlsateurs (l y a rsque e convergence vers un Ètat napproprè). Sem-automatque : ces technques combnent la rèconclaton manuelle et la rèconclaton automatque. Les cas smples sont rèsolus automatquement, les cas plus complquès sont soums aux utlsateurs. Le moèle e rèplcaton asynchrone/symètrque est onc le meux aaptè à l envronnement moble, mas c est auss celu qu prèsente le rsque abanon e transactons le plus gran s l on veut assurer l solaton strcte (sèralsabltè à une cope). Dans le cas contrare, ce moèle e rèplcaton nècesste l utlsaton e technques e rèconclaton pour assurer la convergence es copes. Lorsque les onnèes le permettent, le moe asynchrone/asymètrque, en utlsant la fragmentaton sèmantque, convenra meux car l permet assurer la sèralsabltè à une cope tout en mnmsant le taux abanon es transactons concurrentes.

36 Durablté La urabltè est la proprètè qu assure que les effets es transactons valèes ne seront jamas perues, même en cas e panne matèrelle. Le problème ans le care es tratements en envronnement moble est que la urabltè ne peut être garante sur un moble. En effet, les mobles Ètant lègers et compacts, ls sont faclement sujet à une perte, un vol ou es ommages. La urabltè ot onc être assurèe sur le rèseau fxe. Une premère soluton consste à mantenr une mage physque complète, sur le rèseau fxe, es onnèes embarquèes sur le moble. Pour cela, les technques e rèplcaton en moe asymètrque (avec la cope maître sur le rèseau fxe) peuvent être utlsèes. Les technques e transfert mages physques comme le moèle Pro-moton, ou e rè-exècuton sur l mage u rèseau fxe, comme le moèle es Tentatve Transactons convennent très ben. L nconvènent e telles technques est qu elles sont assez loures : le transfert mage physque gènère un volume e communcaton mportant, très coûteux en envronnement moble. La rè-exècuton es opèratons effectuèes par une transacton augmente la urèe e la valaton, car l faut que la urabltè sot assurèe pour pouvor valer une transacton. Une autre classe e technques envsage la rèexècuton es transactons valèes ont les rèsultats ont ÈtÈ perus u fat une panne. Pour cela, l faut journalser toutes les opèratons effectuèes par les transactons (c est onc un journal logque). La urabltè est onc smplement assurèe : le journal ot être transfèrè sur un serveur stuè sur le rèseau fxe qu pourra le renre urable, ce qu ne nècesste aucun calcul, n sur le moble, n sur le serveur fxe, et a un coût e communcaton relatvement fable. Le problème est alors le volume e stockage nècessare pour ce journal qu ne fat que granr. Pour rèsoure ce problème, l faut envsager es solutons mxtes qu journalsent les opèratons effectuèes par les transactons epus la consttuton une mage physque et, lorsque le journal logque event trop volumneux, recalculent une nouvelle mage physque. Dans les chaptres suvants, nous nous ntèressons à tros es aspects pour lesquelles les technques classques e geston e transactons rèponent mal aux contrantes e la mobltè : () la geston e transactons locales sur es calculateurs mobles prèsentant es lmtes matèrelles mportantes : nous aborons ce problème sous l angle e la concepton un système e geston e bases e onnèes estnè aux cartes à puce ; () la geston e l atomctè globale es transactons rèpartes lorsque au mons l un es partcpants est moble : pour cela, nous Ètuons en Ètal le protocole e valaton atomque le plus utlsè actuellement, nous Ètermnons prècsèment ses lacunes ans un envronnement moble et nous Èfnssons un nouveau protocole permettant e rèponre aux besons es applcatons mobles tout en respectant les contrantes e l envronnement ; () la urabltè es onnèes embarquèes sur un calculateur moble : nous proposons c es technques e manpulaton e journaux logques permettant optmser la geston e la urabltè en

37 37 rèusant autant que possble la consommaton rèseau, l espace e stockage consommè et la pussance e calcul nècessare sur le moble.

38 Chaptre 2 : PcoSGBD 1. Introucton La carte à puce est consèrèe aujour hu comme l un es calculateurs les plus sècursès. La premère carte à puce a ÈtÈ ÈveloppÈe par Bull pour le système bancare franças pour rèure les pertes ues à la fraue assocèe aux cartes e crèt à pste magnètque. Depus, les cartes à puce ont ÈtÈ utlsèes avec succès ans toutes sortes applcatons fasant ntervenr es paements et es onnèes personnelles (cartes bancares, entfcaton es usagers e la tèlèvson à pèage ou es tèlèphones GSM, cartes e fèltè, cartes santè, assurances, etc.). Tans que les cartes actuelles n ont à gèrer qu une seule applcaton proprètare, la tenance se tourne aujour hu vers les cartes mult-applcatons 2. Les stanars pour le support e multples applcatons, comme JavaCar [Sun99] et SmartCar for Wnows e Mcrosoft [Mc00], assurent que les cartes seront unversellement acceptèes et qu elles seront capables nteragr avec e nombreux fournsseurs e servce. Tout cela fat e la carte à puce le plus gros marchè monal e sem-conucteurs [DQ98]. Comme les cartes à puce evennent e plus en plus polyvalentes et pussantes (processeurs 32 bts, plus e 1 Mo e stockage), le beson e technques avancèes e geston e onnèes se fat sentr. ConsÈrons une carte santè contenant un osser mècal complet comprenant les mèecns u porteur, son groupe sangun, ses allerges, ses prescrptons, etc. Le volume e onnèes peut être mportant et les requêtes assez complexes (sèlecton, jonture, agrègats). Une geston sophstquèe e rots accès utlsant es vues et es fonctons agrègats est requse pour prèserver la confentaltè es onnèes u porteur. L atomctè et la urabltè transactonnelles sont auss requses pour assurer la cohèrence es onnèes. Plus gènèralement, la geston e bases e onnèes ae à sèparer le coe e geston e onnèes u coe e l applcaton, cec afn e smplfer et e rèure le coe e l applcaton. Fnalement, e nouvelles applcatons peuvent être envsagèes, comme le calcul strbuè et asynchrone e statstques sur e nombreuses cartes à puce. Supporter la geston e bases e onnèes sur la carte elle-même plutôt que sur un calculateur externe est le seul moyen assurer un très haut nveau e sècurtè, un haut nveau e sponbltè (n mporte où, n mporte quan, epus n mporte quel termnal) et un nveau e performance acceptable. NÈanmons, les cartes à puce ont e sèvères lmtatons matèrelles qu vennent es contrantes Èventes e talle (pour tenr sur une carte en plastque flexble et pour augmenter la sècurtè) et e coût (pour être venues en volumes très mportants). Les mcrocontrôleurs aujour hu 2 Tout le mone ot apprècer e transporter mons e cartes

39 39 contennent un processeur, e la mèmore ncluant 96 Ko e ROM, 4 Ko e RAM et jusqu à 128 Ko espace e stockage comme l EEPROM, et es moules e sècurtè [Tual99]. L EEPROM est utlsèe pour stocker les nformatons persstantes, elle a un temps accès en lecture très rape (60 à 100 ns par mot) comparable à e la RAM l y a quelques annèes, mas un temps accès en Ècrture très lent (plus 1 ms par mot). Suvant la lo e Moore pour les processeurs et la capactè mèmore, les cartes à puce evenront rapement plus pussantes. Les prototypes exstants, comme la carte Pnoccho e Gemplus [Gem99], Ètenent la capactè mèmore en connectant une secone puce comprenant 2 Mo e mèmore Flash au mcrocontrôleur. MalgrÈ les progrès sgnfcatfs effectuès sur les cartes actuelles, elles sont très restrentes comparèes aux autres calculateurs portables, mons sècursès, comme les Assstants Personnels (PDA). De plus, les cartes à puce ne sont pas autonomes, c est-à-re qu elles n ont pas leur propre almentaton Èlectrque, ntersant e ce fat les calculs asynchrones et ÈconnectÈs. Ces lmtatons (RAM mnuscule, peu e stockage stable, Ècrtures très chères et manque autonome) renent les technques e geston e bases e onnèes tratonnelles naèquates. Typquement, les SGBD tratonnels explotent es quanttès sgnfcatves e RAM et utlsent es technques e cache et es entrèes/sortes asynchrones pour rèure l accès aux sques autant que possble. Avec les contrantes extrêmes e la carte à puce, le problème majeur est e ramener à l Èchelle les technques e geston e bases e onnèes. Tans qu l a ÈtÈ fat un traval Ènorme pour gèrer e très volumneuses bases e onnèes, comme l utlsaton u parallèlsme, l aaptaton à e très pettes bases e onnèes n a pas reçu la même attenton. NÈanmons, rèure l Èchelle en gènèral event très mportant pour l nformatque embarquèe et est une tâche ffcle [Grae98]. Quelques concepteurs e SGBD ont aressè le problème e la rèucton à l Èchelle. Des versons lègères es SGBD populares, comme l Aaptatve Server Anywhere e Sybase [Syb99], Oracle 8 lght [ORA99] ou DB2 Everywhere IBM [IBM99], on ÈtÈ conçus prncpalement pour les ornateurs portables et les PDA. Ils ont une pette emprunte mèmore qu ls obtennent en smplfant et en moularsant le coe u SGBD. NÈanmons, ls utlsent une quanttè relatvement mportante e mèmore RAM et espace e stockage et n aressent pas les lmtatons sèvères es cartes à puce. Le SGBD SQLJava Machne e ISOL [Car99] consttue la premère tentatve e SGBD sur carte à puce et SCQL [ISO99], le stanar pour les langages e bases e onnèes pour cartes à puce, Èmerge. Comme ces eux moèles sont lmtès aux sèlectons smples, ls montrent le beson un SGBD ÈÈ aux cartes à puce. Dans ce chaptre, nous aressons le problème e la rèucton es technques e bases e onnèes à l Èchelle e la carte à puce et nous proposons un moèle e ce que nous appelons un PcoSGBD.

40 40 Ce moèle a ÈtÈ conçu pour les cartes à puce, mas l peut s aapter à tout calculateur ultra-lèger basè sur une puce monolthque sècursèe. Ce chaptre apporte les contrbutons suvantes : Nous analysons les besons un PcoSGBD en se basant sur une applcaton type (la carte santè) et nous justfons ses fonctonnaltès mnmales. Nous onnons une analyse en profoneur u problème en consèrant les lmtatons matèrelles es cartes à puce et nous en Èrvons es règles e concepton pour un PcoSGBD. Nous proposons un nouveau moèle e stockage, basè sur es ponteurs, qu ntègre les onnèes et les nex ans une même structure e onnèes. Nous proposons es technques exècuton e requêtes qu autorsent es plans exècuton complexes (comprenant es jontures et es calculs agrègats) tout en mnmsant la consommaton e RAM. Nous proposons es technques transactonnelles pour assurer l atomctè locale qu ramènent le coût e journalsaton à sa borne nfèreure et permettent la partcpaton une carte à puce à es transactons strbuèes. Ce chaptre est organsè comme sut. La secton 2 llustre l utlsaton e bases e onnèes portables ans ffèrentes classes applcatons et Ètalle les besons e l applcaton carte santè. La secton 3 analyse les contrantes matèrelles e la carte à puce et onne la Èfnton u problème. Les sectons 4 à 6 prèsentent respectvement les moèles e stockage, exècuton e requêtes et e transacton. Et enfn, la secton 7 conclut. 2. Applcatons pour cartes à puce Dans cette secton, nous scutons es applcatons Èmergentes pour cartes à puces et leurs besons en terme e fonctonnaltès bases e onnèes. Pus, nous llustrons plus en Ètal ces besons avec l applcaton carte santè, que nous utlserons comme exemple e rèfèrence pour la sute u chaptre Besons en geston e bases e onnées Le Tableau 3.9 rèsume les besons en termes e fonctonnaltès bases e onnèes es classes applcatons types pour cartes à puce suvantes.

41 41 Applcatons Volume SÈlecton/Projecton Jonture Group by/dstnct Drots accès/vues AtomctÈ DurabltÈ Statstques Ientfcaton et Paement Mnuscul e Bases e onnèes TÈlÈchargeables Important Envronnement Utlsateur Moyen Dosser Personnel Important Tableau 3.9 : Profles 'applcatons types. Ientfcaton et Paement : Nous trouvons ans cette catègore les cartes e crèt, les portemonnae Èlectronques, les cartes SIM pour les tèlèphones mobles, les cartes e tèlèphone prèpayèes, les cartes e transport. Elles sont reprèsentatves es applcatons actuelles, avec très peu e onnèes stockèes (l entfant e l utlsateur et quelques nformatons Ètat). L nterrogaton n est pas un problème, et les rots accès sont nutles car les cartes sont protègèes par un coe PIN (Personal Ientfcaton Number). Leur unque beson en fonctonnaltès bases e onnèes est l atomctè es mses à jour. Bases e onnées Téléchargeables : l s agt e onnèes confentelles (comme, par exemple, es onnèes plomatques, mltares ou commercales) qu peuvent être tèlèchargèes ans la carte (par exemple avant un voyage) et peuvent être accèèes epus n mporte quel termnal. La sponbltè et la sècurtè es onnèes sont les prncpaux objectfs. Le volume es onnèes peut être mportant et les requêtes complexes. Les onnèes sont gènèralement en lecture seule. Envronnement utlsateur : l objectf c est e stocker sur la carte un profl Ètenu u porteur e la carte. Ce profl peut nclure, entre autres, es onnèes concernant son envronnement nformatque (confguraton, mots e passe, cookes, sgnets, lcences e programmes ), son carnet aresse, ans que son agena. L envronnement utlsateur peut onc être ynamquement retrouvè à partr u profl sur n mporte quel termnal. Comme les onnèes ne sont pas corrèlèes, les requêtes restent smples. Toutefos, une parte es onnèes est hautement confentelle et ot être protègèe par es rots accès sophstquès (par exemple, le porteur e la carte peut voulor partager un sous-ensemble e son carnet aresses ou e ses sgnets avec un ensemble e personnes). L atomctè et la urabltè transactonnelles sont auss nècessares.

42 42 Dossers personnels : les ossers personnels peuvent être e ffèrentes natures : scolares, santè, hstorque e mantenance e vèhcule, programmes e fèltè. Ils partagent les mêmes besons que nous llustrerons avec l exemple e la carte santè. Remarquons que es requêtes fasant ntervenr ffèrents ossers personnels ont un sens. Par exemple, on peut être ntèressè par la recherche assocatons entre une malae et le nveau scolare u porteur e carte. Cela soulève l ntèressant problème e la mantenance e statstques sur une populaton e cartes, ou e l analyse e leur contenu e façon asynchrone L applcaton carte santé La carte santè est une applcaton e type osser personnel très reprèsentatve et a e forts besons en fonctonnaltès bases e onnèes. Pluseurs pays (la France, l Allemagne, les USA, la Russe, la CorÈe ) ont ÈveloppÈ es applcatons e cartes santè [BSB99]. L Èe ntale Ètat e strbuer à chaque ctoyen une carte à puce contenant son entfcaton et ses onnèes assurance. Comme la capactè e stockage es cartes à puce augmente, les nformatons stockèes ans la carte peuvent s Ètenre aux mèecns u porteur, aux onnèes urgence (groupe sangun, allerges, vaccns ), aux opèratons chrurgcales, aux prescrptons, aux onnèes assurance et même à es lens vers es onnèes plus volumneuses (par exemple : es raographes, mages e scanner ) stockèes sur les serveurs hôptaux. DffÈrents utlsateurs peuvent nterroger, mofer ou ajouter es onnèes ans le osser u porteur : les mèecns qu consultent les antècèents u patent et prescrvent es mècaments, les chrurgens qu pratquent es examens et es opèratons, les pharmacens qu Èlvrent les mècaments, la sècurtè socale et les mutuelles qu remboursent le patent, les organsmes publcs qu mantennent es statstques ou Ètuent l mpact e la corrèlaton e mècaments sur es populatons e patents, et fnalement, le porteur e carte lu-même. Nous pouvons faclement observer que : () le volume e onnèes est sgnfcatf (plus en terme e carnaltè que e volume car la plupart es onnèes peuvent être encoèes), () les requêtes peuvent être assez complexes (par exemple, un mèecn emane les ernères prescrptons antbotques fates au patent ans les tros erners mos), () une geston e rots accès sophstquèe utlsant es vues et es fonctons agrègats est hautement nècessare (par exemple, un organsme e statstques peut accèer à es valeurs agrègats mas pas aux onnèes brutes), (v) l atomctè ot être assurèe (comme quan le pharmacen Èlvre es mècaments) et (v) la urabltè est oblgatore, sans compromettre la confentaltè es onnèes (les journaux stockès à l extèreur e la carte ovent onc être protègès). On peut se emaner pourquo les onnèes e santè u porteur ne sont pas plutôt stockèes ans une base e onnèes centralsèe. Il y a tros bènèfces à la strbuton e la base e onnèes e

43 43 santè sur es cartes à puce. Premèrement, les onnèes e santè ovent être hautement sponbles (n mporte quan, n mporte où, epus n mporte quel termnal et sans beson e connexon à un rèseau). Deuxèmement, stocker es onnèes sensbles sur un serveur centralsè peut nure à la confentaltè. Trosèmement, mantenr une base e onnèes centralsèe est extrêmement complexe, et cec à cause e la varètè es sources e onnèes. Supposant que les onnèes e santè sont stockèes sur une carte à puce, la queston suvante est pourquo les fonctonnaltès bases e onnèes ovent être hèbergèes sur la carte et non sur le termnal. La rèponse est, là encore, la sponbltè (les onnèes ovent pouvor être explotèes sur n mporte quel termnal) et la confentaltè. En ce qu concerne la confentaltè, comme les onnèes ovent être confnèes sur la carte à puce, l en va e même pour le moteur exècuton et le gestonnare e vues. La carte Ètant l unque ste e confance u système, les rots accès et la geston e transactons ne peuvent être ÈlÈguÈes à un termnal non sûr. 3. Règles e concepton Dans cette secton, nous clarfons les contrantes es cartes à puce e sorte à en Èrver es règles e concepton pour le PcoSGBD. Notre analyse est basèe sur les caractèrstques es cartes actuelles, ans que celles e prototypes e laboratore [Gem99][Tual99], et onc, evrat être vales pour quelques temps. Nous scutons auss e l Èvoluton possble es prncpales contrantes es cartes à puce Contrantes es cartes à puce Les cartes à puce actuelles comprennent, ans une puce monolthque, un processeur e technologe RISC 32 bts (envron 30 MIPS), es moules mèmore (jusqu à 96 Ko e ROM, 4 Ko e RAM statque et 128 Ko EEPROM), es composants e sècurtè (pour prèvenr les attaques physques) et prennent leur almentaton Èlectrque u termnal [Tual99]. La ROM est utlsèe pour stocker le système explotaton, la machne vrtuelle JavaCar, es onnèes fxes et es routnes stanars. La RAM est utlsèe comme mèmore e traval pour mantenr une ple exècuton et le calcul e rèsultats. L EEPROM est utlsèe pour stocker les nformatons persstantes. L EEPROM prèsente un temps accès en lecture très rape (60 à 100 ns par mot) comparable aux RAM ancenne gènèraton, mas un temps accès en Ècrture ramatquement long (plus 1 ms par mot). Les prncpales contrantes es cartes à puce actuelles sont onc : () l espace e stockage très lmtè, () le temps Ècrture en EEPROM très long, () la talle extrêmement rèute e la RAM, (v) le manque autonome et (v) un haut nveau e sècurtè qu ot être conservè ans

44 44 toutes les stuatons. Ces contrantes stnguent fortement les cartes à puce e tout autre calculateur, y-comprs les ornateurs lègers comme les PDA. ConsÈrons mantenant comment les avancèes matèrelles peuvent mofer ces contrantes, en partculer la capactè mèmore. Les cartes à puce actuelles sont construtes ans une technologe ben Ètable et lègèrement ÈpassÈe (0,35 µm) e façon à rèure le coût e proucton (mons e cnq ollars) et augmenter la sècurtè [ScSh99]. De plus, l n y a pas eu e rèel beson e grane capactè mèmore ans les applcatons actuelles es cartes à puce (par exemple : l entfcaton u porteur). D après les fournsseurs e cartes, la presson u marchè gènèrèe par l Èmergence es applcatons emanant e granes capactès vont conure à une hausse rape e la capactè e stockage es cartes à puce. Cette Èvoluton est cepenant lmtèe par la talle rèute e la puce, fxèe à 25 mm² par le stanar ISO [ISO98], qu pousse vers une plus forte ntègraton. Cette lmte e talle est ue à es consèratons e sècurtè (pour mnmser le rsque attaque physque [AnKu96]) et es contrantes pratques (comme, par exemple, la rèsstance e la puce aux flexons e la carte). Une autre soluton pour relâcher la lmte e stockage est Ètenre la capactè e stockage avec es moules e mèmore externes. Cela a ÈtÈ expèrmentè par Gemplus avec leur carte Pnoccho [Gem99], une carte à puce ÈqupÈe e 2 Mo e mèmore Flash relèes au mcrocontrôleur par un bus. Comme la sècurtè matèrelle ne peut plus être assurèe ans cette mèmore, son contenu ot être sot non sensble, sot chffrè. Type e MÈmore EEPROM FLASH FeRAM Temps e lecture (/mot) 60 à 150 ns 70 à 200 ns 150 à 200 ns Temps Ècrture (/mot) 1 à 5 ms 5 à 10 µs 150 à 200 ns Temps effacement (/banc) Aucun 500 à 800 ms Aucun DurÈe e ve* (/cellule) 10 5 cycles 10 5 cycles à cycles Ècrture effacement Ècrture * une cellule mèmore ne peut être rèècrte qu un nombre fn e fos. Tableau 3.10 : Performance es mèmores stables pour cartes à puce. Un autre problème mportant est la performance es mèmores stables. Les alternatves possbles à l EEPROM sont la mèmore Flash et la mèmore ferroèlectrque (FeRAM) [Dp97] (vor le Tableau 3.2 pour la comparason e performance). La mèmore Flash est plus compacte qu l EEPROM et reprèsente onc un bon canat pour les cartes à puce e grane capactè [Gem99]. NÈanmons, les bancs e mèmore Flash ovent être effacès avant être rèècrts, ce qu est extrêmement lent. Cec ren la mèmore Flash approprèe unquement pour les applcatons ayant un rato lecture/ècrture ÈlevÈ (comme les carnets aresses). La FeRAM est ncontestablement une opton ntèressante pour les cartes à puce car elle prèsente es temps e lecture et Ècrture très courts. Même s les fonements thèorques e la FeRAM atent es annèes 1950, elle Èmerge seulement comme une soluton nustrelle. De plus, la FeRAM est chère, mons sure que l EEPROM ou la Flash, et son ntègraton avec les technologes tratonnelles (comme les

45 45 processeurs) reste un problème. Donc la FeRAM peut être consèrèe comme une alternatve sèreuse seulement à très long terme [Dp97]. Etant onnè ces consèratons, nous supposerons ans ce chaptre une carte à puce avec une capactè rasonnable e stockage stable (quelques Mo EEPROM 3 ) et une pette capactè e RAM (quelques Ko). En fat, l n y pas ntèrêt clar à avor une large RAM, Ètant onnè que la carte n est pas autonome, ntersant e ce fat les Ècrtures ffèrèes. De plus, plus e RAM sgnfe mons EEPROM car la talle e la puce est lmtèe Impact sur l archtecture u PcoSGBD Nous analysons mantenant l mpact es contrantes e la carte à puce sur l archtecture u PcoSGBD, justfant onc pourquo les technques tratonnelles e bases e onnèes, et même les technques e SGBD lègers, sont naaptèes. Les proprètès es cartes à puce et leurs mpacts sont : Haute sécurté : la sècurtè matèrelle offerte par la carte à puce en fat le support e stockage Èal pour les onnèes confentelles. Le PcoSGBD ot contrbuer à la sècurtè es onnèes en fournssant une geston e rots accès et un mècansme e vues permettant la Èfnton e vues complexes (c est-à-re supportant la composton et l agrègaton e onnèes). Le coe u PcoSGBD ne ot pas prèsenter e falles e sècurtè ues à l utlsaton algorthmes sophstquès 4. Haute portablté : la carte à puce est nubtablement le plus portable es ornateurs personnels (l tent ans le portefeulle). Les onnèes stuèes sur la carte sont onc hautement sponbles. Elles sont auss hautement vulnèrables car la carte à puce peut être perue, volèe ou Ètrute accentellement. La prncpale consèquence est que la urabltè ne peut être assurèe localement. Ressources e stockage lmtées : malgrè la crossance e capactè vue prècèemment, la carte à puce reste le plus lèger reprèsentant es ornateurs personnels, et cec pour longtemps. Cela veut re que es moèles e stockage spècfques et es technques exècuton ovent être trouvèes pour mnmser la talle es onnèes persstantes (la base e onnèes) et la consommaton e mèmore penant l exècuton. De plus, les fonctonnaltès u PcoSGBD ovent être juceusement sèlectonnèes et leur mplantaton ot être auss lègère que 3 ConsÈrer e la Flash au leu e l EEPROM ne changera pas nos conclusons. Cela ne fera que les exacerber. 4 La plupart es trous e sècurtè sont us à es erreurs e programmaton [ScSh99].

46 46 possble. Plus le coe u PcoSGBD sera pett, plus le volume e onnèes embarquèes sera gran. Le stockage stable est la mémore prncpale : la mèmore e stockage e la carte à puce offre la raptè e lecture et la granulartè accès une mèmore RAM. Donc le PcoSGBD peut être consèrè comme un SGBD mèmore. NÈanmons, le coût ramatque es Ècrtures le stngue es autres SGBD mèmore. Cela a un mpact auss ben sur les mèthoes e stockage et accès u PcoSGBD, que sur la façon assurer l atomctè transactonnelle. Non autonome : comparèe aux autres ornateurs, la carte à puce n a pas almentaton Èlectrque nèpenante, ntersant e ce fat les tratements ÈconnectÈs et asynchrones. Donc, toutes les transactons ovent être termnèes penant que la carte est nsèrèe ans un termnal (contrarement aux PDA, les opèratons Ècrture ne peuvent être cachèes en RAM et reportèes sur un support e stockage stable e façon asynchrone) Poston u problème En rèsumè, notre but est e concevor un PcoSGBD comprenant les composants suvants : Gestonnare e stockage : gère le stockage e la base e onnèes et les nex assocès. Gestonnare e requêtes : calcule es plans exècuton e requêtes composès e sèlectons, projectons, jontures et agrègats. Gestonnare e transactons : assure les proprètès ACID et partcpe aux transactons strbuèes. Gestonnare e rots accès : fournt es rots accès sur les onnèes e base et sur les vues utlsateur. Donc, le PcoSGBD hèbergè sur la puce fournt le sous-ensemble mnmal e fonctonnaltès strctement nècessares pour gèrer, e façon sècursèe, les onnèes partagèes par toutes les applcatons embarquèes sur la carte. Les autres composants (comme l nterface utlsateur, l opèrateur e tr ) peuvent être hèbergès sur le termnal ou être ynamquement tèlèchargès lorsque nècessare, sans que la sècurtè es onnèes ne sot compromse. Dans le reste e ce chaptre, nous nous concentrerons sur les composants qu nècesstent es technques non conventonnelles (gestonnares e stockage, e requêtes et e transactons) et gnorerons le gestonnare e rots accès pour lequel les technques tratonnelles peuvent être utlsèes.

47 47 Lorsque nous concevons les composants u PcoSGBD, nous evons suvre certanes règles e concepton Èutes es proprètès es cartes à puce : Compactness Rule : mnmser la talle es structures e onnèes et le coe u PcoSGBD pour tenr ans la mèmore e stockage stable lmtèe (quelques Mo). RAM Rule : mnmser l utlsaton e la RAM Ètant onnè sa talle très lmtèe (quelques Ko). Wrte Rule : mnmser les opèratons Ècrture Ètant onnè leur coût ramatque (envron 1 ms par mot). Rea Rule : exploter l avantage e la raptè es opèratons e lecture en mèmore stable (envron 100 ns par mot). Access Rule : exploter l avantage e la fable granulartè et la possbltè accès rect e la mèmore stable auss ben pour les lectures que pour les Ècrtures. CPU Rule : exploter la très grane pussance u processeur, relatvement à la talle mèmore. Securty Rule : ne jamas externalser e onnèes confentelles hors e la puce et mnmser la complextè es algorthmes pour Èvter les trous e sècurtè. 4. Moèle e stockage Dans cette secton, en suvant les règles e concepton pour un PcoSGBD, nous scutons es problèmes e stockage et nous proposons un moèle très compact basè sur une combnason e stockage plat, en omane et en anneau. Nous Èvaluons auss le coût e stockage e notre moèle Stockage plat La façon la plus smple organser les onnèes est le stockage plat (SP), où les tuples sont stockès sèquentellement et les valeurs attrbuts sont stockèes ans les tuples. Même s l ne l mpose pas, le stanar SCQL [ISO99] consère le stockage plat comme moèle e rèfèrence pour les cartes à puce. Le prncpal avantage u stockage plat est la localtè accès. NÈanmons, ans notre contexte, le stockage plat a eux prncpaux Èfauts : Consommaton espace : tans que les règles e normalsaton ntersent la reonance e conjonctons attrbuts, elles n Èvtent pas les uplquas e valeurs attrbuts (par exemple, l attrbut (Docteur.Spécalté peut contenr e nombreux uplquas).

48 48 Ineffcace : en l absence e structures nex, toutes les opèratons sont calculèes sèquentellement. Même s cec convent pour les cartes à puce ancenne gènèraton (quelques Ko e stockage et un opèrateur e sèlecton mono-table), cela n est plus acceptable pour les cartes futures où la capactè e stockage Èpasse le Mo et où les requêtes peuvent être relatvement complexes. Ajouter es structures nex au stockage plat peut rèsoure le secon problème tans que cela aggraverat le premer. Donc, le stockage plat seul n est pas approprè pour un PcoSGBD Stockage en omane BasÈ sur la crtque u stockage plat, l en Ècoule qu un moèle e stockage pour PcoSGBD ot garantr la compactè es onnèes et es nex. ConsÈrons ans un premer temps la compactè es onnèes. Comme la localtè n est plus un problème ans notre contexte, les moèles e stockage basès sur les ponteurs, nsprès es SGBD mèmore [AHK85][MSc83][PTV90] peuvent nous permettre e rèure le coût e stockage es onnèes. L Èe e base est nterre toute rèplcaton e valeur. Cela peut être obtenu en regroupant les valeurs en omanes (ensemble e valeurs non reonantes). Nous appelons ce moèle Stockage en Domane (SD). Comme nous le voyons en Fgure 3.11, les tuples rèfèrencent leurs valeurs attrbuts grâce à es ponteurs. De plus, un omane peut être partagè entre pluseurs attrbuts. Cela est partculèrement effcace pour les types ÈnumÈrÈs, qu ne varent que sur un pett ensemble ÈtermnÈ e valeurs 5. On peut s nterroger sur le coût es opèratons e crèaton, mse à jour et suppresson e tuples, car elles peuvent gènèrer es nsertons et suppressons e valeurs ans les omanes. Même s ces actons sont plus complexes que leurs contrepartes en stockage plat, leur mplantaton reste plus effcace ans le contexte es cartes à puce, smplement parce que le volume e onnèes evant être Ècrtes est ben plus pett. Pour amortr le lèger surcoût u stockage en omane, nous ne stockons en omane que les onnèes attrbuts longs (c est-à-re plus gran qu un ponteur) contenant es uplquas. Evemment, les attrbuts sans uplqua (comme les clès) n ont pas beson être stockèes en omanes mas en stockage plat. Les attrbuts e talle varable (gènèralement plus granes qu un ponteur) peuvent auss être avantageusement stockès en omanes, même s elles ne contennent pas e uplquas. Le bènèfce n est pas en Èconome e stockage, mas en smplctè e geston e mèmore (tous les tuples e toutes les relatons evennent e talle fxe) et e compactè e journaux (vor la Secton 6). 5 Des technques e compresson peuvent avantageusement utlsèes en conjonctons avec le stockage en omane pour augmenter la compactè [Grae93]. On peut alleurs consèrer que le stockage en omane s apparente lu-même à un mècansme e compresson à base e ctonnare.

49 49 Relaton S Valeur 1 Valeur 2 Valeur n Fgure 3.11 : Stockage en omanes Stockage en anneau IntÈressons-nous mantenant à la compactè es nex en plus e la compactè es onnèes. Contrarement aux SGBD basès sur es sques qu prvlègent les nex prèservant la localtè, les cartes à puce ovent fare une utlsaton ntensve es nex seconares (c est-à-re basès sur es ponteurs). Le problème c est e renre ces nex auss compacts que possble. ConsÈrons premèrement les nex e sèlecton. Un nex est gènèralement consttuè e eux partes : une collecton e valeurs et une collecton e ponteurs relant chaque valeur à tous les tuples la partageant. En supposant que l attrbut nexè vare sur un omane, la collecton e valeurs e l nex peut être ÈconomsÈe car elle correspon exactement à l extenson u omane. Le coût supplèmentare nut par l nex est alors rèut aux ponteurs relant les valeurs aux tuples. Inex sur Relaton S att Relaton S Relaton R S.att S.b R.a tuple k (a) Inex en anneau sur un attrbut (b) nex en anneau sur une clè Ètrangère Fgure 3.12 : Stockage en anneau. Allons une Ètape plus lon et essayons e rèure le coût e ces ponteurs. L Èe est e stocker ces ponteurs valeur vers tuple à la place es ponteurs tuples vers valeurs ans les tuples (c est-àre les ponteurs stockès ans les tuples pour rèfèrencer leurs valeurs attrbuts ans les omanes). Cela consttue une structure nex qu forme un anneau relant la valeur e omane aux attrbuts partageant cette valeur. Nous appelons cette structure un Inex en Anneau (vor Fgure 3.12(a)). Mas l nex en anneau peut auss être utlsè pour accèer aux valeurs e omane epus les tuples et onc servr comme moèle e stockage e onnèes. Donc nous appelons Stockage en anneau (RS) le stockage un attrbut en omane nexè par un anneau. Le coût e

50 50 stockage e l nex est rèut à sa plus smple expresson : un ponteur par valeur e omane, quel que sot la carnaltè e la relaton nexèe. Cette mportante Èconome e stockage est obtenue au prx un traval supplèmentare pour projeter l attrbut corresponant, car retrouver la valeur un attrbut stockè en anneau mplque, en moyenne, la traversèe e la motè e l anneau (c està-re jusqu à retrouver la valeur e omane). Les nex e jonture [Val87] peuvent être tratès e la même manère. Un prècat e jonture e la forme (R.a = S.b) suppose que les eux attrbuts R.a et S.b varent sur le même omane. Stocker R.a et S.b avec es anneaux revent à Èfnr un nex e jonture. De cette façon, chaque valeur e omane est relèe par eux anneaux à tous les tuples e R et S partageant la même valeur attrbut e jonture. Toutefos, la plupart es jontures sont exècutèes sur es attrbuts clè, R.a Ètant la clè prmare et S.b Ètant la clè Ètrangère rèfèrençant R.a. Dans notre moèle, les attrbuts clè ne sont pas stockès en omane mas en stockage plat. NÈanmons, s R.a est la clè prmare e R, son extenson forme prècsèment un omane, même s l n est pas stockè à l extèreur e R. Comme l'attrbut S.b pren ses valeurs ans le omane R.a, ls rèfèrencent les valeurs R.a par le bas e ponteurs. Donc, le moèle e stockage basè sur es omanes mplante naturellement et gratutement un nex unrectonnel e jonture e S.b vers R.a (c est-à-re que chaque tuple e S est lè par un ponteur à chaque tuple e R corresponant). S la traversèe e R.a vers S.b ot être auss optmsèe, un nex e jonture b-rectonnel est nècessare. Cec peut être obtenu smplement en Èfnssant un nex en anneau sur S.b. La Fgure 3.12(b) montre la stuaton rèsultante où chaque tuple e R est relè par un anneau à tous les tuples e S corresponant et rècproquement. Le coût un nex e jonture b-rectonnel est rèut à un seul ponteur par tuple e R, quel que sot la carnaltè e S. Remarquons que cette stuaton ressemble au moèle Coassyl ben connu Evaluaton u coût e stockage Notre moèle e stockage combne le stockage plat (SP), le stockage en omane (SD) et le stockage en anneau (SA). La ffcultè est onc e Ètermner le melleur stockage pour chaque attrbut. S l attrbut n a pas à être nexè, le chox ot se fare, ben Èvemment, entre stockage plat et en anneau. Dans le cas contrare, le chox ot se fare entre stockage en anneau et stockage plat avec un nex tratonnel. Donc, nous comparons le coût e stockage pour un seul attrbut, nexè ou non, pour chaque alternatve. Nous ntrousons les paramètres suvants : CarRel : la carnaltè e la relaton contenant l attrbut a : la talle moyenne un attrbut (exprmèe en octets)

51 51 p : la talle un ponteur (l faura tros octets pour aresser les «granes» mèmores es futures cartes) S : le facteur e sèlectvtè pour l attrbut. S = CarDom/CarRel, où CarDom est la carnaltè e l extenson u omane e l attrbut (ans tous les moèles). S mesure la reonance es valeurs un attrbut (c est-à-re que la même valeur attrbut apparaît ans 1/S tuples). Coût(SP) = CarRel * a Coût(SD) = CarRel * p // coût e stockage un attrbut ans la relaton // coût e stockage e l attrbut ans la relaton + S * CarRel * a // coût e stockage e la valeur ans le omane Coût(SP nexé) = Coût(SP) // coût e stockage plat + S * CarRel * a // coût e stockage e la valeur ans l nex + CarRel * p // coût e stockage un ponteur ans l nex Coût(SA) = Coût(SD) // coût e stockage e l attrbut en omane + S * CarRel * p // coût e stockage un ponteur ans l nex L ÈgaltÈ e coût entre le stockage plat et le stockage en omane onne : S = (a p)/a. Pour un même coût pour les stockages plat nexè et stockage en anneau, on a : S = a/p. La Fgure 3.5(a) onne les ffèrentes valeurs e S et e a pour lesquelles le stockage plat et le stockage en omane sont Èquvalents. Cette courbe vse onc le plan en une règon où le stockage plat est melleur (au-essus e la courbe) et une autre règon où le stockage en omane est melleur (en essous e la courbe). Pour les valeurs e a nfèreures à 3 (la talle un ponteur), le stockage plat est Èvemment toujours plus compact que le stockage en omane. Pour les valeurs supèreures e a, le stockage en omane event rapement melleur que le stockage plat, sauf pour les granes valeurs e S. ConsÈrons que S = 0,5, ce qu veut re que la même valeur n est partagèe que par eux tuples, le stockage en omane Èpasse le stockage plat pour tout a supèreur à 6 octets. Plus a est gran et S est pett, plus le stockage en omane est performant. Le bènèfce u stockage en omane est onc partculèrement mportant pour les attrbuts e type ÈnumÈrÈ. La Fgure 3.5(b) compare le stockage plat nexè et le stockage en anneau. La supèrortè u stockage en anneau est Èvente, sauf pour les attrbuts clès un ou eux octets e

52 52 longueur. Donc, la Fgure 3.5 est un gue pour le concepteur e bases e onnèes pour Ècer comment stocker chaque attrbut, en consèrant sa talle et sa sèlectvtè. S S 1 1 SP 0,8 0,8 0,6 SP 0,6 SA plus compact 0,4 SD plus compact 0,4 0,2 0,2 0 0 Talle en octets (a) sans nex Talle en octets (b) avec nex Fgure 3.13 : Comparason es moèles e stockage. 5. Moèle exécuton L exècuton e requêtes tratonnelle à tenance à exploter les granes mèmores pour stocker es structures e onnèes temporares (comme es tables e hachage) et es rèsultats ntermèares. Lorsque la mèmore prncpale n est pas assez grane pour stocker certanes onnèes, les algorthmes les melleurs (comme le hybr hash jon [SDW89]) ont recours à la matèralsaton sur sque pour Èvter les Èborements e mèmore. Ces algorthmes ne peuvent être utlsès pour un PcoSGBD car : Etant onnè la Wrte Rule et la urèe e ve e la mèmore stable, les Ècrtures en mèmore stable sont proscrtes, même pour es matèralsatons temporares ; DÈer une zone e RAM spècfque n ae pas non plus, car nous ne pouvons pas estmer sa talle à pror. La chosr trop pette augmente le rsque e Èborement e mèmore, conusant e ce fat à es Ècrtures en mèmore stable. La chosr trop grane rèut la zone e mèmore stable, Èjà lmtèe ans une carte à puce (RAM Rule). De plus, même une grane zone e RAM ne peut garantr que l exècuton e requête ne proura pas un Èborement e mèmore [BKV98] ; Ces algorthmes sont très sophstquès, ce qu ntert leur mplantaton ans un PcoSGBD ont le coe ot être smple, compact et sûr (Compactness Rule et Securty Rule). Pour rèsoure ce problème, nous proposons es technques exècuton e requêtes qu n utlsent aucune zone e RAM e traval, et n occasonnent aucune Ècrture en mèmore stable. Dans la

53 53 sute, nous Ècrvons ces technques pour les requêtes smples et complexes (ncluant es agrègats et la suppresson e oublons) Exécuton e requêtes smples sans RAM Nous consèrons l exècuton e requêtes e SÈlecton/Projecton/Jonture (SPJ). Le tratement e requêtes est classquement vsè en eux Ètapes. L optmseur e requêtes gènère tout abor un plan exècuton e requête «optmal». Le plan exècuton est ensute exècutè par le moteur exècuton, qu mplante un moèle exècuton et utlse une lbrare opèrateurs relatonnels [Grae93]. L optmseur peut consèrer pluseurs moèles e plan exècuton : le left eep tree (arbre gauche), le rght eep tree (arbre rot), ou le bushy tree (vor Fgure 3.14). Dans un left eep tree, les opèrateurs sont exècutès sèquentellement et chaque rèsultat ntermèare est matèralsè. Au contrare, un rght eep tree exècute les opèrateurs en ppelne, n entraînant aucune matèralsaton. NÈanmons, l mplque la matèralsaton en mèmore e toutes les relatons stuèes sur les fls gauches. Les bushy trees offrent l opportuntè e fare un comproms entre la talle es rèsultats ntermèares et la consommaton e mèmore [SYT93]. σ rug σ presc oc vst vst σ Schéma e la base e onnées : MatÈralsaton Ppelne σ oc rug presc Left eep tree Bushy tree Rght eep tree Extreme rght eep tree oc vst rug presc Doctor(DocI, Specalty, ) Vst(VstI, DocI, Date, Dagnostc, ) Prescrpton(VstI, DrugI, Qty, ) Drug(DrugI, Name, Type, ) Requête R1 : Qu a prescrpt es autbotques en 1999 σ σ oc σ vst presc σ rug Fgure 3.14 : DffÈrents plans 'exècuton pour la requête R1. Dans un PcoSGBD, l optmseur e requêtes ne evrat consèrer aucun e ces arbres exècuton car ls mplquent e la matèralsaton. La soluton est e n utlser que u ppelne avec es extreme rght eep trees où tous les opèrateurs (y-comprs la sèlecton) sont en ppelne. Comme toutes les opèranes e gauche sont es relatons e base, elles sont Èjà matèralsèes en mèmore stable, nous permettant onc exècuter un plan sans consommaton e RAM. L exècuton ppelne peut être faclement obtenue en utlsant le Moèle ItÈrateur [Grae93] ben connu. Dans ce moèle, chaque opèrateur est un tèrateur qu supporte tros appels e procèure : open pour prèparer un tèrateur à proure un rèsultat, next pour proure un rèsultat, et close pour

54 54 fare le nettoyage fnal. Un plan exècuton e requête est actvè en commençant par la racne e l arbre opèrateurs et progresse en suvant les branches jusqu aux feulles. Le flux e onnèes ans ce moèle se fat à la emane : un opèrateur fls passe un tuple à son parent en rèponse à un appel next venant e celu-c. DÈtallons mantenant comment les opèrateurs e sèlecton, e jonture et e projecton fonctonnent. Ces opèrateurs peuvent être exècutès sèquentellement ou avec un nex en anneau. Etant onnè l Access Rule, l utlsaton es nex semble toujours être le bon chox. NÈanmons, l extreme rght eep tree ne permet accèlèrer par nex qu une sèlecton sur la premère relaton e base (Drug.Type ans notre exemple), par alleurs, l utlsaton un nex en anneau sur les autres attrbuts sèlectonnès (comme Vst.Date) peut ralentr l exècuton car l ot être traversè pour retrouver sa valeur. Les opèrateurs e projecton sont repoussès en haut e l arbre car l n y a aucune matèralsaton. Remarquons que la projecton fnale vot son coût augmenter ans le cas attrbuts stockès en anneau. Sans nex, la jonture e relatons se fat par un algorthme en boucles mbrquèes, car aucune autre technque e jonture ne peut s applquer sans structures ahoc (comme les tables e hachage) ou une zone mèmore e traval (comme le tr). Le coût es jontures sur nex Èpen e la façon ont l nex est traversè. ConsÈrons la jonture nexèe entre Doctor (n tuples) et Vst (m tuples) sur leur attrbut clè. Supposons que sons avons un nex unrectonnel, le coût est proportonnel à n * m s l on commence par Doctor, et proportonnel à m s l on commence par Vst. Supposons mantenant que nous sposons un nex brectonnel, le coût e jonture event proportonnel à n + m s nous commençons par Doctor, et à m²/2n ans le cas contrare (retrouver le octeur assocè à chaque vste mplque la traversèe e la motè e l anneau, en moyenne). Dans ce erner cas, un algorthme naïf en boucles mbrquèes peut être plus effcace s la carnaltè e l anneau est plus grane que la carnaltè e la relaton cble (c est-à-re lorsque m > n²). Dans ce cas, le concepteur e la base e onnèes ot chosr un nex unrectonnel entre ces eux relatons Exécuton e requêtes complexes sans RAM ConsÈrons mantenant l exècuton es opèrateurs agrègats, e tr et e suppresson e oublons. A premère vue, l exècuton ppelne n est pas compatble avec ces opèrateurs qu, classquement, sont exècutès sur es rèsultats ntermèares. Une telle matèralsaton n est pas possble ans une carte à puce à cause e la RAM Rule, n sur le termnal à cause e la Securty Rule. Remarquons que le tr peut s effectuer sur le termnal car l orre e sorte es tuples rèsultat n est pas sgnfcatf (l Èpen e l algorthme u SGBD) et ne peut onc être explotè pour mener une attaque.

55 55 Nous proposons une soluton à ce problème en explotant eux proprètès : () les agrègats et la suppresson e oublons peuvent être obtenus en ppelne s les tuples entrant sont Èjà groupès par valeurs stnctes et () les opèrateurs ppelne conservent l orre es tuples car ls consomment (et prousent) les tuples ans leur orre arrvèe. Donc, assurer un orre e consommaton aèquat aux feulles e l arbre opèrateurs permet l exècuton en ppelne es calculs agrègats et e la suppresson es oublons. Dans notre exemple e la Fgure 3.14, l extreme rght eep tree Èlvre es tuples naturellement groupès par Drug.DrugI, permettant e ce fat es requêtes groupèes sur cet attrbut. ConsÈrons mantenant la requête R2 e la Fgure Comme nous le voyons, exècuter R2 en ppelne mplque le rèarrangement e l arbre exècuton e sorte que la relaton Doctor sot explorèe en premer. Comme Doctor content es mèecns stncts, les tuples arrvant à l opèrateur count sont naturellement groupès par mèecns. count σ count count stnct rug presc σ presc rug presc vst rug presc vst R2 vst oc rug R3 rug.typ R4 oc rug.type R5 oc rug.type R2 : Nombre antbotques prescrts par octeur en 1999R3 : Nombre e prescrptons par type e mécamentsr4 : Nombre e prescrptons par octeur et par type e mécamentr5 : Docteurs et types e Fgure 3.15 : Quatre plans 'exècuton e requêtes complexes. Le cas e la requête R3 est plus Èlcat. Comme les onnèes ovent être groupèes par type e mècament au leu e Drug.DrugI, une jonture supplèmentare est nècessare entre la relaton Drug et le omane Drug.Type. Les valeurs e omane Ètant unques, cette jonture prout les tuples ans l orre recherchè. S le omane Drug.Type n exste pas, un opèrateur ot être ntrout pour trer la relaton Drug en ppelne. Cela peut être fat en effectuant n passes sur la relaton Drug, où n est le nombre e valeurs stnctes e Drug.Type. Etant onnè la CPU Rule, cette technque est tout à fat applcable. Le cas e la requête R4 est encore plus ffcle. Le rèsultat ot être groupè sur eux attrbuts (Doctor.DocI et Drug.Type), ntrousant le beson e commencer l arbre par ces eux relatons! La soluton est nsèrer un opèrateur e prout cartèsen au nveau es feulles e l arbre pour proure les tuples oronnès par Doctor.DocI et Drug.Type. Dans ce cas, le temps e rèponse e

56 56 la requête evrat être approxmatvement n fos plus gran que la même requête sans la clause group by, où n est le nombre e valeurs stnctes e Drug.Type. La requête R5 retrouve les couples stncts e mèecns et e types e mècaments. Cette requête peut être renue smlare à la requête R4 en exprmant la clause stnct comme un agrègat sans foncton (c est-à-re que la requête «select stnct a 1,, a n from» est Èquvalente à «select a 1,, a n from group by a 1,, a n»). L unque ffèrence est que le calcul pour un groupe onnè (tuple rèsultat stnct) peut s arrêter ausstôt qu un tuple a ÈtÈ consommè Optmsaton e requête L optmsaton par heurstques est attractve. NÈanmons, les heurstques ben connues, comme calculer les projectons et les sèlectons en premer, ne fonctonnent pas ans le contexte un PcoSGBD. L utlsaton extreme rght eep trees ren la premère mpossble et nvale la euxème. Les heurstques pour l oronnancement es jontures sont encore plus rsquèes vu nos structures e onnèes. En fat, l y a e nombreux arguments pour la recherche exhaustve u melleur plan exècuton. Premèrement, l espace e recherche est lmtè car : () l n y a qu un seul algorthme par opèrateur, Èpenant es nex exstants ; () on ne consère que es extreme rght eep trees ; et () les requêtes typques ne font pas ntervenr beaucoup e relatons. Deuxèmement, la recherche exhaustve en utlsant es algorthmes en profoneur abor ne consomment pas e RAM. Fnalement, les algorthmes exhaustfs sont smples et compacts (même s ls font e nombreuses tèratons). En supposant que l optmsaton e requêtes est nècessare ans un PcoSGBD, les remarques prècèentes plaent en faveur une stratège e recherche exhaustve. 6. Geston e transactons Comme n mporte quel serveur e onnèes, un PcoSGBD ot assurer les proprètès ACID [BHG87] ben connues pour garantr la cohèrence es onnèes locales qu l gère, ans que pour être capable e partcper à es transactons strbuèes. Nous scutons par la sute e ces proprètès ans le care un PcoSGBD. Atomcté : l atomcté locale sgnfe que l ensemble es opèratons effectuèes par le PcoSGBD ans le care une transacton sont renues persstantes suvant le schèma tout ou ren. L atomcté globale sgnfe que tous les serveurs e onnèes (y-comprs le PcoSGBD) accèès par une transacton strbuèe soent accor sur la termnason e la transacton (que ce sot valer ou annuler). Les proprètès stnctves un PcoSGBD u pont e vue

57 57 e l atomctè est qu l n y a aucune Èmarcaton entre la mèmore prncpale et le stockage persstant, le coût ramatque es Ècrtures et le fat qu elles ne peuvent pas être ffèrèes. Cohérence : cette proprètè assure que les actons fates par le PcoSGBD satsfont toutes les contrantes ntègrtè Èfnes sur les onnèes locales. ConsÈrant que la geston e contrantes ntègrtè tratonnelle peut être utlsèe, nous n rons pas plus lon sur cette proprètè. Isolaton : cette proprètè garantt la sèralsaton es exècutons es transactons concurrentes. Un PcoSGBD gère es onnèes personnelles et est typquement monoutlsateur 6. De plus, les systèmes explotaton es cartes à puce ne supportent pas le multthrea. De ce fat, l solaton est nutle ans ce contexte. Durablté : la urabltè sgnfe que les mses à jour valèes ne ovent jamas être perues quel que sot la stuaton (même ans le cas une panne matèrelle). La urabltè ne peut être assurèe sur le PcoSGBD car la carte à puce peut être plus faclement volèe, perue ou Ètrute qu un ornateur tratonnel. En fat, la mobltè et la mnatursaton jouent contre la sècurtè. En consèquence, la urabltè ot être assurèe à travers le rèseau. Le prncpal problème est alors e prèserver le confentaltè es onnèes lorsque nous ÈlÈguons la urabltè à un agent externe. La sute e cette secton aresse l atomctè locale en Ètal. L atomctè globale et la urabltè seront ÈtallÈes ans les chaptres suvants Atomcté locale Il y a eux façons effectuer es mses à jour ans un SGBD. Les mses à jour peuvent être effectuèes sot sur es objets ombre (shaow upates), qu sont atomquement ntègrès ans la base e onnèes à la valaton, sot sur place (upate n place), c est-à-re que la transacton mofe rectement la cope partagèe es objets e la base e onnèes [BHG87]. Nous scutons c-essous ces eux moèles tratonnels. Shaow upate : Ce moèle est rarement employè ans les SGBD sur sque car l Ètrut la localtè es onnèes sur sque et augmente les mses à jour concurrentes sur le catalogue. Dans un PcoSGBD, la localtè sur sque et la concurrence ne sont pas un problème. Ce moèle s est montrè convenable pour les cartes à puce ÈqupÈes une pette mèmore Flash [LeTr97]. NÈanmons, l est peu aaptè aux moèles e stockage basès sur es ponteurs 6 Même s les onnèes gèrèes par le PcoSGBD sont partagèes entre pluseurs utlsateurs (comme pour la carte santè), le PcoSGBD ne sert qu un seul utlsateur à la fos.

58 58 comme le stockage en anneau, car l objet change e place à chaque mse à jour. De plus, le coût nut par les onnèes ombre augmente avec la talle e la mèmore. En fat, sot la granulartè es onnèes evant être uplquèes augmente, sot le catalogue event plus gran. Dans les eux cas, le coût Ècrture (qu est le facteur omnant) augmente. Upate n Place : La journalsaton avant Ècrture (Wrte-Ahea Loggng) [BHG87] est nècessare ans ce moèle pour Èfare les effets une transacton abanonnèe. Malheureusement, le coût relatf u Wrte-Ahea Loggng est ben plus gran ans un PcoSGBD que ans les SGBD sur sque tratonnels qu utlse un cache pour mnmser les EntrÈes/Sortes. Dans une carte à puce, le journal ot être Ècrt pour chaque mse à jour car chaque mse à jour event mmèatement persstante. Ce qu ouble ou presque le coût es Ècrtures. MalgrÈ ses Èfauts, le moèle Upate n place est meux aaptè que le moèle Shaow Upate pour un PcoSGBD car l s accommoe aux moèles e stockage basès sur es ponteurs et que son coût est nsensble à la rape augmentaton e la capactè e stockage stable. Nous proposons auss eux optmsatons au moèle Upate n place : Journal basé sur les ponteurs : la journalsaton tratonnelle enregstre les valeurs e toutes les onnèes mofèes. Le stockage en anneau permet une granulartè plus fne en enregstrant les ponteurs à la place es valeurs. Plus les enregstrements u journal sont petts, mos la journalsaton est chère. Le processus e journalsaton ot consèrer eux types nformaton : o o Les valeurs : ans le cas e la mse à jour un tuple, l enregstrement u journal ot contenr l aresse u tuple et l ancenne valeur e l attrbut, qu est un ponteur pour tous les attrbuts stockès en omane ou en anneau, ou une valeur pour les onnèes stockèes à plat. Dans le cas une nserton ou une suppresson un tuple, en supposant que chaque entête e tuple a un bt e statut (mort ou vf), seule l aresse u tuple ot être journalsèe e façon à restaurer son Ètat. Les anneaux : l nserton, la suppresson ou la mse à jour ( un attrbut stockè en anneau) mofe la structure e chaque anneau traversant le tuple t corresponant. Comme un anneau est une chaîne crculare e ponteurs, restaurer son Ètat veut re retrouver le ponteur suvant u prèècesseur e t (appelons-le t pre ). L nformaton à restaurer ans t pre.next est sot l aresse e t, s t a ÈtÈ ms à jour ou supprmè, ou t.next s t a ÈtÈ nsèrè. L aresse e t appartent Èjà au journal (vor c-essus) et t.next ne ot pas être journalsè car le contenu e t exste toujours en mèmore stable

59 59 au moment e la reprse. Le problème est entfer t pre à la reprse. Journalser cette nformaton peut être ÈvtÈ au prx e la traversèe e tout l anneau en partant e t, jusqu à attenre t une nouvelle fos. Donc, la restauraton es anneaux peut se rèalser gratutement en terme e journalsaton. Récupératon es valeurs perues : l nserton et la suppresson e valeurs e omanes (elles ne sont jamas mofèes) ovent être journalsèes comme toutes les autres mses à jour. Ce surcoût peut être ÈvtÈ en mplantant un ramasse-mettes ffèrè qu supprme toutes les valeurs e omanes qu ne sont plus rèfèrencèes par aucun tuple. Le ramasse-mettes applquè sur un omane mplque l exècuton un opèrateur a-hoc e sem-jonture entre les valeurs u omane et toutes les relatons varant essus et supprme les valeurs qu ne sont plus rèfèrencèes 7. Le bènèfce e cette soluton est trple : () la suppresson ffèrèe es valeurs non rèfèrencèes n entache pas la cohèrence u moèle e stockage ; () la rècupèraton e ces valeurs est nècesstèe e toute façon par le stockage en anneau (même en l absence e contrôle transactonnel) et () un ramasse-mettes peut être mplantè sans compteur e rèfèrence, Èconomsant e ce fat e l espace e stockage. Le ramasse-mettes ffèrè ne peut pas travaller en arrère plan car les cartes à puce ne supportent pas encore le mult-tâches. Une soluton possble est e le lancer manuellement lorsque la carte est pratquement plene. Une alternatve à cette procèure manuelle est exècuter le ramassemettes automatquement, à chaque connexon e la carte, sur un très pett sous-ensemble e la base e onnèes (pour que le coût reste cachè à l utlsateur). Nettoyer la base e onnèes e cette façon (ncrèmentale) ne pose aucun problème car les valeurs e omanes sont examnèes les unes après les autres. Le moèle Upate n place avec une journalsaton basèe sur les ponteurs et un ramasse-mettes ffèrè rèut le coût e journalsaton à sa borne nfèreure, qu est l aresse es tuples nsèrès et supprmès, et les valeurs es attrbuts ms à jour (là encore, un ponteur pour les attrbuts stockès en omane ou en anneau) Evaluaton u coût es transactons Le but e cette secton est e fare une approxmaton u temps requs par une transacton e mse à jour reprèsentatve. L objectf est e confrmer s la performance en Ècrture une carte à puce supposèe ans ce chaptre est acceptable ou non pour une applcaton e base e onnèes comme la carte santè. Pour ce fare, nous estmons le temps requs pour crèer un tuple ans une relaton, 7 Contrarement aux algorthmes attegnabltè qu commencent par les racnes e persstance et nècesstent un marquage [AFG95], le ramasse-mettes proposè Èmarre par les feulles persstantes (les valeurs e omane) et les explotent les unes après les autres, en ppelne (onc conforme à la RAM Rule).

60 60 en ncluant la crèaton es valeurs e omane, l nserton u tuple ans les anneaux potentellement Èfns sur cette relaton et le temps e journalsaton. Introusons les paramètres suvants, en complèments e ceux Èjà Èfns en secton 4.4: NbAttSP : nombre attrbuts stockès à plat. NbAttSD : nombre attrbuts stockès en omane. NbAttSA : nombre attrbuts stockès en anneau. w : talle un mot (4 octets pour une carte 32 bts) t : temps ms pour Ècrre un mot en mèmore stable (prenons 5 ms) Coût(nserton tuple) = ([(NbAttSP * a + NbAttSD * p + NbAttSA * p)/w] // Talle u tuple + (NbAttSA + NbAttSD) * S * (a/w) // talle es valeurs en omane 8 + NbAttSA * (p/w) // ponteurs anneau mofès + (p/w) // talle un enregstrement e journal ) * t // temps Ècrture ConsÈrons une transacton reprèsentatve exècutèe sur la carte santè. Cette transacton nsère un nouveau tuple ans les relatons Doctor et Vst et cnq tuples ans les relatons Prescrpton et Drug. C est en quelque sorte un pre cas pour cette applcaton car le mèecn vstè est nouveau et qu l a prescrt cnq nouveaux mècaments. La strbuton attrbuts consèrèe est la suvante : Doctor (NbAttSP = 3, NbAttSD = 4, NbAttSA = 0), Vst (NbAttSP = 2, NbAttSD = 3, NbAttSA = 2), Prescrpton (NbAttSP = 1, NbAttSD = 1, NbAttSA = 2), Drug (NbAttSP = 2, NbAttSD = 4, NbAttSA = 0). La talle moyenne es attrbuts est fxèe à 10 octets. La Fgure 3.16 montre le temps exècuton e la transacton e mse à jour en foncton e la sèlectvtè S (S = 0 sgnfe que toutes les valeurs 8 S est la probabltè e crèer une nouvelle valeur e omane.

61 61 s attrbuts exstent Èjà ans les omanes, tans que S = 1 sgnfe que toutes ces valeurs ovent être nsèrèes ans les omanes). Fgure 3.16 : Performance 'une transacton e mse à jour type. La fgure s explque elle-même. Remarquons que la journalsaton reprèsente mons e 3% u coût total. Cette smple analyse montre que le temps attenu pour ce type e transacton (mons une secone) est compatble avec les besons e l applcaton carte santè. 7. Concluson Comme les cartes à puce evennent e plus en plus polyvalentes, mult-applcatons et pussantes, le beson e technques e bases e onnèes Èmerge. NÈanmons, les cartes à puce ont e sèvères lmtatons matèrelles qu renent les technques tratonnelles e geston e bases e onnèes naèquates. Le prncpal problème est e rèure à l Èchelle les technques base e onnèes pour qu elles fonctonnent ben sous ces contrantes. Dans ce chaptre, nous avons aressè ce problème et proposè un moèle e PcoSGBD, en se concentrant sur les composants qu ont beson e technques non tratonnelles (gestonnares e stockage, e requêtes et e transactons). Ce chaptre apporte pluseurs contrbutons. Premèrement, nous avons analysè les besons un PcoSGBD en se basant sur une applcaton e carte santè qu est reprèsentatve es applcatons e osser personnels et qu ont e forts besons en base e onnèes. Nous avons montrè que les fonctonnaltès mnmales evaent nclure la sèlecton/projecton/jonture/agrègats, la geston e rots accès et e vues, ans que l atomctè transactonnelle. Deuxèmement, nous avons onnè une analyse en profoneur u problème en consèrant les lmtes matèrelles e la carte à puce. En se basant sur cette analyse, nous avons supposè une carte à puce avec une mèmore e stockage stable rasonnable e quelques Mo et une pette RAM e

62 62 quelques Ko, et nous en avons ÈrvÈ es règles e concepton pour une archtecture e PcoSGBD. Trosèmement, nous avons proposè une moèle e stockage très compact combnant le stockage plat, le stockage en omanes, et le stockage en anneaux. Le stockage en anneaux rèut le coût nexaton à sa borne nfèreure. En se basant sur une Èvaluaton e performance, nous avons onnè es gues pour Ècer quelle est la melleure façon e stocker un attrbut. Quatrèmement, nous avons proposè es technques e tratement e requêtes qu permettent exècuter es requêtes complexes sans consommaton e RAM. Cec est obtenu en ne consèrant que es extreme rght eep trees où tous les opèrateurs, y comprs les agrègats, s enchaînent en ppelne. Nous avons auss montrè que, s une optmsaton e requêtes evat être nècessare, elle evrat utlser une stratège e recherche exhaustve. Fnalement, nous avons proposè es technques pour assurer l atomctè transactonnelle. L atomctè locale est obtenue en fasant les mses à jour en place avec eux optmsatons qu explotent le moèle e stockage : la journalsaton basèe sur es ponteurs et un ramasse-mettes ffèrè pour les valeurs e omane. Nous avons montrè que les performances une transacton e mse à jour type sont acceptables pour les applcatons reprèsentatves comme la carte santè. Les travaux prèsentès ans ce chaptre ont onnè leu à eux publcatons ans es confèrences natonales et nternatonales [BBPV00a][BBPV00b], ans que ans la revue VLDB Journal [PBVB01]. Un prototype a ÈtÈ ÈveloppÈ au laboratore et a ÈtÈ ÈmontrÈ lors e la confèrence VLDB en 2001 [ABBPV01].

63 Chaptre 3 : Protocoles e valaton atomque 1. Introucton Le tratement moble et ÈconnectÈ consttue l un es problèmes les plus ffcles pour les futurs systèmes e geston e bases e onnèes (notès SGBD). Les bases e onnèes personnelles sont couramment hèbergèes sur es ornateurs portables pour permettre le traval en moe ÈconnectÈ. Plus rècemment, es systèmes e geston e bases e onnèes sont apparus pour es calculateurs lègers comme les PDA, tèlèphones cellulares, ornateurs e bor et, comme nous venons e le vor, les cartes à puce. Ces calculateurs peuvent auss ben être es clents mobles accèant à es bases e onnèes stuèes sur es serveurs fxes (comme, par exemple, es serveurs Web accèès va un tèlèphone portable), que es serveurs e onnèes mobles hèbergeant es onnèes personnelles (exemple : carnet aresse, osser mècal, agena, porte-monnae Èlectronque, ). Ce chaptre trate es proprètès transactonnelles ans ce contexte. Plus prècsèment, nous proposons un protocole e valaton atomque qu faclte l ntègraton es bases e onnèes sur calculateurs lègers ans une transacton strbuèe. Les protocoles tratonnels e valaton atomque (comme le Two Phases Commt, notè par la sute 2PC) souffrent es fablesses suvantes lorsqu ls sont applquès aux tratements mobles et ÈconnectÈs : Tratement hors-lgne : une transacton exècutèe sur un moble ÈconnectÈ ne peut valer localement. Donc elle reste une tentatve e transacton jusqu à ce que le moble se reconnecte et que le 2PC sot entèrement exècutè sur les serveurs fxes. Capactés lmtées es mobles : les serveurs lègers (comme les cartes à puce, les tèlèphones cellulares, ) ovent fournr une nterface stanar pour partcper au protocole 2PC. Cela ntert l ntègraton es systèmes hèrtès ans une transacton strbuèe. Actuellement, la norme ISO Èfnt une nterface transactonnelle pour assurer les proprètès ACID ans une carte à puce, mas elle ne couvre pas les besons es transactons strbuèes [ISO99]. En plus, partcper au protocole 2PC oblge à construre un Ètat e prèparaton local sur chaque serveur, ce qu consomme es ressources utles (sur les cartes à puce, par exemple). Partcpants mobles : le protocole 2PC mplque un coût mportant en nombre e messages (eux Ètapes e communcaton entre les partcpants et le coornateur). Les communcatons

64 64 sans-fl sont ben mons effcaces que les communcatons sur un rèseau fxe. Cec peut gènèrer un coût prohbtf s le coornateur est stuè sur un moble ou s les partcpants euxmême se Èplacent. De plus, les partcpants mobles peuvent se Èconnecter faclement urant l exècuton même u 2PC (par exemple, une carte à puce peut être extrate e son lecteur, ou un tèlèphone cellulare peut être ms hors-servce ou être temporarement njognable) entraînant l abanon e la transacton. Pour rèsoure cette stuaton, une nouvelle forme e protocole e valaton atomque est nècessare. Ce chaptre prèsente le Unlateral Commt Protocol for Moble (UCM), un protocole e valaton atomque qu offre les proprètès suvantes : Une transacton s exècutant hors-lgne peut valer ausstôt que son journal a ÈtÈ transfèrè sur le rèseau fxe et sans attenre l accusè e rècepton es serveurs fxes. Le protocole ne emane pas la prèsence e tous les serveurs au moment e la valaton. Le protocole est composè une seule Ètape e communcaton, rèusant ans le coût en communcatons sans-fl. Le protocole ne emane pas Ètat prêt à valer, n l nterface corresponante au nveau u serveur. Dans ce chaptre, nous allons prèsenter les applcatons types effectuant es transactons rèpartes nècesstant une phase e valaton atomque. Nous rappellerons auss le fonctonnement u protocole 2PC et nous prèsenterons ses lmtatons en envronnement moble. Nous prèsenterons ensute en Ètal le protocole UCM, et enfn, nous conclurons. 2. Applcatons exemples Cette secton prèsente tros applcatons types mobles, llustrant les ffèrents besons en terme e valaton atomque. La premère applcaton se place ans le care e l e-busness. Le commerce Èlectronque va l Internet est populare aujour hu et peut être effectuè en utlsant n mporte quel calculateur, fxe ou moble. Le commerce Èlectronque peut être effectuè en moe ÈconnectÈ pour rèure le coût e communcaton. Pour cela, l utlsateur Ètablt une connexon avec le supermarchè e son chox et tèlècharge son catalogue et les quanttès sponbles en stock pour chaque prout. Le supermarchè se connecte à la banque e l utlsateur et nègoce un plafon pour les achats e l utlsateur. Ce plafon est renvoyè à l utlsateur, qu peut se Èconnecter à partr e ce moment.

65 65 L utlsateur procèe mantenant hors-lgne (c est-à-re en moe ÈconnectÈ), chost les prouts qu l ntèressent en respectant le plafon, et vale sa transacton localement. La valaton globale est retarèe jusqu à la reconnexon, vu que la banque, le supermarchè et Èventuellement l ornateur e l utlsateur s l gare trace es achats, sont concernès. Donc, le melleur protocole e valaton atomque pour le tratement ÈconnectÈ est celu qu mnmse le rsque abanon au moment e la reconnexon. ConsÈrons mantenant l utlsaton u porte-monnae Èlectronque. Une transacton normale ans ce contexte consste à transfèrer une somme onnèe un compte bancare vers un porte-monnae Èlectronque hèbergè sur une carte à puce. Ce transfert ot être renu atomque pour es rasons Èventes. Ic, le protocole e valaton atomque ot rèsoure eux mportants problèmes : () l ot permettre aux systèmes hèrtès e partcper aux transactons, consèrant que les cartes à puce actuelles sont ncapables e partcper à un protocole e valaton atomque, et () l ot mnmser les ressources locales nècessares pour partcper au protocole, car les ressources es cartes à puce sont extrêmement lmtèes. La ernère applcaton consste à organser un renez-vous entre ffèrentes personnes ayant toutes un agena stuè sur leur moble (comme un PDA ou un tèlèphone cellulare). ConsÈrons que ces personnes sont frèquemment, mas pas en permanence, connectès au rèseau. Le protocole e renez-vous est lancè et la ate chose (s elle exste) ot être rèservèe atomquement ans tous les agenas. Le protocole e valaton atomque utlsè ans ce contexte ot : () mnmser le nombre e messages ÈchangÈs, vu le coût et la latence ÈlevÈs es communcatons sans-fl, et () supporter la Èconnexon u partcpant pour Èvter l annulaton e la transacton chaque fos que l un es agenas est njognable. 3. Le Two Phase Commt Le protocole e valaton atomque le plus largement utlsè est le two-phase commt (2PC) [Gray78]. Le 2PC est supportè aujour hu par tous les systèmes e geston e bases e onnèes commercaux et tous les monteurs transactonnels. Il a ÈtÈ stanarsè par l ISO [ISO92], le consortum X/Open [X/OP91] et l Object Management Group [OMG94]. Même s l est ben connu, nous rappelons c les bases e ce protocole car une comprèhenson prècse e ses prncpales Ètapes est nècessare ans la sute e ce chaptre Protocole Comme Ècrt ans la Fgure 4.17, le protocole 2PC est consttuè une phase e Vote et une phase e Décson. Durant la phase e vote, le coornateur envoe une Requête e vote (auss

66 66 appelè message Prépare) à tous les partcpants e la transacton. Un vote Ou (ou Prêt) un partcpant nque que l exècuton e la branche locale e la transacton s est ben ÈroulÈe et que le partcpant est capable e renre ses mses à jour permanentes, même en cas e panne. En autres termes, le partcpant peut garantr localement les proprètès ACID pour sa branche e transacton. Ce partcpant est t être ans un état prêt. Un vote Non (ou Abanon) nque que, û à certans problèmes locaux (volaton e contrante ntègrtè, problème e contrôle e concurrence, erreur mèmore ou e sque), le partcpant ne peut garantr une ou pluseurs es proprètès ACID pour sa branche e transacton. Un partcpant votant Non peut annuler unlatèralement sa branche e transacton. S un partcpant vote Ou, l ne peut n valer n annuler tant qu l n a pas reçu la Ècson fnale u coornateur. Durant la phase e Ècson, le coornateur Èce e la termnason e la transacton et l envoe à tous les partcpants. La Ècson u coornateur est Valer s tous les partcpants ont votè ou. Dans l autre cas, la Ècson est Annuler (c est-à-re s au mons un es partcpants a votè non ou est manquant û à une erreur e tratement ou une panne e communcaton). Quan un partcpant reçot la Ècson fnale, l renvoe un accusè e rècepton au coornateur. Cet accusè e rècepton est une promesse u partcpant qu l ne emanera jamas au coornateur quelle Ètat sa Ècson pour cette transacton. Une fos que tous les accusès e rècepton ont ÈtÈ reçus, le coornateur peut oubler cette transacton (c est-à-re ver le journal la concernant). P1 P2 P3 Prepare B Vote R/A Decson C/A Ack_DecsonC/A Prepare R Vote P R/A Decson C/A Ack_Decson : Force-Wrte : Non-Force Wrte B : Begn C : Commt A : Abort R : Reay E : En transacton R/A : R ou A C/A : C ou A E Fgure 4.17 : Protocole Two-Phases Commt 3.2. Tolérance aux pannes La tolèrance u 2PC aux pannes est assurèe par l enregstrement u Èroulement u protocole ans les journaux u coornateur et es partcpants. Comme les pannes peuvent arrver n mporte quan, certanes es nformatons stockèes ans les journaux ovent être forcèes (c est-à-re Ècrtes par une entrèe/sorte bloquante sur un système e stockage stable et tolèrant aux pannes).

67 67 En fat, le coornateur force l Ècrture e sa Ècson avant e l envoyer aux ffèrents partcpants. Cec assure que la Ècson ne sera pas perue, même en cas e panne u coornateur. Chaque partcpant force l Ècrture e : () son vote avant e l envoyer au coornateur, et () la Ècson fnale avant envoyer l accusè e rècepton au coornateur. En rèaltè, un partcpant votant ou force l Ècrture e son vote en même temps que toutes les mofcatons effectuèes par sa branche e transacton. Cec assure que le partcpant est capable e renre ses mses à jour permanentes même en cas e panne (c est à re pour assurer la urabltè) PC et moblté Même s l est largement acceptè et supportè, le protocole 2PC a e fortes Èfcences lorsqu l est applquè aux tratements mobles et ÈconnectÈs. Revenons aux tros applcatons ntroutes ans la secton 2 et regarons comment se comporte le 2PC ans ces cas e fgure. S le 2PC est utlsè pour valer la transacton e commerce Èlectronque, cela veut re qu l est lancè à la reconnexon et que la valaton e la transacton ne sera effectve que lorsque tous les partcpants (la banque, le supermarchè et le moble) auront accusè e rècepton e la Ècson u coornateur. Le moble ot onc conserver sa connexon jusqu à la termnason u protocole. Malheureusement, la transacton peut être annulèe même s elle a ÈtÈ correctement exècutèe sur le moble, en cas e panne e communcaton ou un partcpant. La transacton peut même être abanonnèe en l absence e panne. En fat, la phase e vote u 2PC autorse un partcpant à abanonner unlatèralement une transacton s l ne peut pas assurer localement au mons une es proprètès ACID. C est pourquo les transactons mobles sont souvent appelèes es tentatves [GHOS96] jusqu à la reconnexon. L Èe gènèrale est e satsfare quelques-unes es proprètès ACID sur le moble (hors-lgne). Comme nous l avons vu ans la secton 4.3 u chaptre 2, l solaton peut être assurèe sur le moble e ffèrentes façons (bal, rèservaton, ). La cohèrence peut auss être assurèe sur le moble en rècupèrant les contrantes ntègrtè assocèes aux onnèes en même temps que celles-c (moèle PRO-MOTION [WaCh99]). Même s ces mèthoes mnuent la probabltè abanon à la reconnexon, une transacton peut toujours être abanonnèe urant la phase e vote s l un es partcpants ne peut assurer l atomctè ou la urabltè. Le protocole 2PC ne convent pas non plus ans le contexte e l applcaton u porte-monnae Èlectronque pusqu l mpose à chaque partcpant externalser un Ètat prêt. Cela veut re que chaque partcpant ot offrr une nterface 2PC stanar (par exemple : l nterface Xa e l X/Open [X/OP91]), ce qu n est pas le cas es cartes à puce actuelles. De plus, chaque partcpant ot

68 68 mantenr un journal local pour pouvor se conformer à la Ècson u coornateur ans n mporte quelle stuaton. Ce journal consomme mportantes ressources ans une carte à puce (la capactè une carte à puce est actuellement e l orre e 128 Ko). Dans la trosème applcaton (le renez-vous strbuè), les prncpales fablesses u protocole 2PC sont les suvantes. Premèrement, le 2PC ne supporte pas la Èconnexon un partcpant. Une Èconnexon urant la phase e vote est tratèe comme une panne et conut à l abanon e la transacton (même s elle aurat pu être valèe ultèreurement). Deuxèmement, le protocole 2PC nècesste eux Ètapes e communcaton (une par phase) et 4p messages, où p est le nombre e partcpants. Dans un envronnement moble, ce coût est beaucoup plus contragnant s l on consère le coût ÈlevÈ et la latence es communcatons sans-fl. Ces tros exemples sont reprèsentatfs une large classe applcatons. Ils Èmontrent l ncapactè u protocole 2PC à supporter le tratement moble et ÈconnectÈ, les partcpants lègers et les serveurs hèrtès. Ils permettent auss e montrer que son coût est amplfè ans le care un rèseau sans-fl. Cec Èmontre le beson mportant un nouveau protocole e valaton atomque ÈÈ au tratement moble et ÈconnectÈ. 4. Protocole Unlateral Commt for Moble L Èe e base sur laquelle repose notre protocole UCM, est l Èlmnaton e la phase e vote u 2PC, en vèrfant certanes proprètès sur le partcpant penant l exècuton e la transacton. De ce fat, le protocole e valaton atomque se rèut à une seule phase, qu est la ffuson à tous les partcpants e la Ècson u coornateur. Vu e lon, le coornateur agt comme un ctateur qu mpose sa Ècson à tous. S une panne empêche un es partcpants e se conformer à la Ècson u coornateur, le coornateur fat smplement rè-exècuter la branche e transacton corresponante au partcpant. Le gan en terme e performance (entèes/sortes bloquantes, latence et nombre e messages) est Èvent et peut largement être explotè ans un rèseau e communcaton sans-fl. De plus, nous montrerons que le protocole UCM onne la possbltè au coornateur mposer sa Ècson même e façon asynchrone, rèponant e ce fat aux besons u tratement en moe ÈconnectÈ Protocoles e valaton atomque à une phase L Èe e protocoles e valaton atomque à une phase (1PC) a ÈtÈ suggèrèe la premère fos par Jm Gray [Gray78] et pluseurs varatons ont ÈtÈ proposèes plus rècemment [AP98b]. Le protocole Early Prepare [StCr90] force chaque partcpant à se mettre en Ètat prêt après l exècuton e chaque opèraton. Un partcpant est onc prêt à valer une transacton n mporte

69 69 quan, renant e ce fat son vote mplcte. Le prncpal Èfaut vent u fat que chaque opèraton ot être enregstrèe ans le journal u partcpant sur sque, cela veut re une Ècrture forcèe par opèraton. Le protocole Coornator Log [StCr90] explote l Èe u Early Prepare et Èvte l entrèe/sorte bloquante sur le partcpant en centralsant les journaux es partcpants sur le coornateur. Toutefos, l autonome es stes est volèe en forçant les partcpants à externalser leurs journaux. Le protocole Implct Yes-Vote [AlCh95] aapte le protocole Coornator Log au cas es bases e onnèes connectèes à es rèseaux très rapes (quelques Gbts/s). Fnalement, le protocole NB-SPAC [AP98a], ÈveloppÈ au laboratore PRSM, propose une verson non bloquante u Coornator Log qu prèserve l autonome es stes en journalsant sur le coornateur les opèratons logque plutôt que les journaux physques es partcpants. MalgrÈ leur effcactè, les protocoles e valaton atomque à une phase ont ÈtÈ largement gnorès es mplèmentatons es systèmes transactonnels strbuès, cec car ls mplquent e fortes hypothèses sur le fonctonnement es partcpants. Ces hypothèses ont ÈtÈ clarement entfèes et formalsèes ans [AGP02]. En smplfant, les protocoles e valaton atomque à une phase Èlmnent la phase e vote u 2PC, qu est le moyen, pour le coornateur, e vèrfer s les partcpants une transacton peuvent garantr localement les proprètès ACID e leurs branches e transacton. L Èe e base est e renre cette vèrfcaton nutle penant l exècuton u protocole en fasant en sorte que ces proprètès soent Èjà garantes au moment u lancement e la valaton sur chaque partcpant. Cec ntrout les hypothèses suvantes sur la façon e gèrer les transactons sur les partcpants : 1. Les protocoles à une phase supposent que toutes les opèratons une transacton aent ÈtÈ confrmèes (c est-à-re qu elles ont ÈtÈ correctement exècutèes jusqu à leur termnason) avant que le protocole ne sot lancè. L atomctè e toutes les branches e transacton est onc assurèe au moment e la valaton. 2. Les protocoles à une phase supposent que les contrantes ntègrtè sont vèrfèes mmèatement après chaque opèraton e mofcaton et avant e confrmer l opèraton. La cohèrence est onc assurèe, pour toutes les branches e transacton, au moment e la valaton (l ne ot pas y avor e contrantes ntègrtè ffèrèes, c est-à-re ne pouvant être vèrfèes qu à la fn e la transacton). 3. Les protocoles à une phase supposent que tous les partcpants sèralsent leurs transactons en utlsant un protocole e contrôle e concurrence pessmste qu empêche les abanons en cascae (vor la secton 4.3 u chaptre 2). De cette façon, la sèralsabltè (l solaton) e toutes les branches e transacton est Èjà assurèe au moment e la valaton.

70 70 4. Les protocoles à une phase supposent qu au moment e la valaton, les effets e toutes les branches e transacton sont journalsèes sur un support stable, la proprètè e urabltè est onc assurèe. Cela se traut par l Ècrture forcèe, sur le coornateur, u journal contenant toutes les opèratons logques e mofcaton e onnèes effectuèes par la transacton, avant que le protocole ne sot ÈclenchÈ. Le contenu e ce journal et la manère ont l est explotè pour la reprse après une panne ffère fortement suvant les protocoles. Nous montrerons que ces hypothèses ne sont pas s contragnantes, vore même oblgatores, ans le care es tratements mobles et ÈconnectÈs. Nous Ètallons ans la sute le protocole Unlateral Commt for Moble (UCM) avant e vor comment l rèpon aux besons e nos tros applcatons exemple Descrpton u protocole UCM Pour ben comprenre le protocole UCM, la phase exècuton et la phase e termnason une transacton ovent être consèrèes ensemble. Cnq types e composants ntervennent pour l exècuton et la termnason une transacton : L Applcaton qu emane l exècuton e la sèquence opèratons, Le Log Agent, qu journalse chaque opèraton avant son exècuton, Les Partcpants qu exècutent ces opèratons, Le Coornateur qu rge le protocole e termnason, Les PAgents (un par partcpant) qu reprèsentent les partcpants ans le protocole e termnason et jouent un rôle actf pour la reprse après panne. P APA P APA Fxe Network Commt C C LA App C Commt App : Applcaton LA : Log Agent C : Coornateur P : Partcpant PA : Pagent Fgure 4.18 : Une confguraton type pour l'ucm

71 71 Ces composants peuvent être co-localsès ou non, suvant les confguratons matèrelles et logcelles. Mas le coornateur ot toujours être stuè sur le rèseau fxe et le PAgent ot toujours être stuè sur le moble partcpant, alors que tous les autres composants peuvent être stuès auss ben sur le rèseau fxe que sur un moble. La Fgure 4.18 reprèsente une confguraton type, où l applcaton, le LogAgent et le Coornateur sont stuès sur le rèseau fxe, alors que les Partcpants sont mobles et hèbergent leur PAgent. L applcaton e renez-vous ntroute ans la secton 2 s applque sur cette confguraton, s l on suppose que l algorthme e renez-vous s exècute sur le rèseau fxe. Le scènaro e valaton prout par le protocole UCM est Ècrt ans la Fgure Pour smplfer, nous montrons les actons exècutèes par un seul partcpant P k. Dans la sute, T k reprèsente la branche locale e la transacton T exècutèe par le partcpant P k. Applcaton op Log Agent Partcpant P k Etape 1 ack Écrture non forcèe ans T op ack T k exècute op Coornator PAgent k Etape 2 commt(t ) Écrture forcèe u journal e T Écrture forcèe e la Ècson Etape 3 commt(t ) wrte recor<commt > ack T k exècute le wrte commt (T k ) ack ack Écrture non forcèe e ack k (commt ) Lorsque tous les ack ont ÈtÈ reçus, Ècrture non forcèe e ack Co-localsÈs T k exècute commt en et on ouble T Fgure 4.19 : ScÈnaro e valaton prout par le protocole UCM Dans la Fgure 4.19, l Ètape 1 reprèsente la sèquence opèratons exècutèes ans le care e T k. Le LogAgent enregstre ans son journal chaque opèraton evant être exècutèe. Cet enregstrement est effectuè par une Ècrture non forcèe. Ce type Ècrture est ms en cache en mèmore et ne gènère pas entrèe/sorte bloquante. Les opèratons sont ensute envoyèes et exècutèes localement sur le partcpant P k. Chaque opèraton est ensute confrmèe à l applcaton.

72 72 L Ètape 2 correspon à la termnason e la transacton u pont e vue e l applcaton. Une fos que toutes les confrmatons ont ÈtÈ reçues par l applcaton, elle envoe une emane e valaton. A ce moment, les proprètès ACI sont garantes localement par les partcpants pour toutes les branches e transacton 9. Toutefos, comme les partcpants ne peuvent savor que la transacton est termnèe, ls ne peuvent garantr la proprètè e urabltè. La urabltè est assurèe par le coornateur lu-même, qu rècupère le journal e T prout par le LogAgent et l Ècrt sur un support e stockage stable (c est une Ècrture forcèe). Une fos que l Ètape 2 est achevèe, les proprètès ACID sont garantes pour chaque branche e transacton. Donc, le coornateur pren la Ècson e valer et Ècrt cette Ècson sur support stable (c est là auss une Ècrture forcèe). Remarquons que pour rason e performance, le journal e T et la Ècson e valaton peuvent être Ècrts en même temps, gènèrant e ce fat une seule Ècrture bloquante. Ensute, le coornateur ffuse la Ècson e valaton à tous les partcpants et atten leur accusè e rècepton. Lorsque tous les accusès e rècepton sont reçus, le coornateur peut oubler la transacton. Le rôle es PAgents penant l Ètape 3 sera ÈtallÈ ans la secton suvante. S la transacton ot être abanonnèe, les Ètapes 2 et 3 sont beaucoup plus smples. Le coornateur supprme le journal e T et ffuse la Ècson abanon à tous les partcpants. Nous supposons que la Ècson par Èfaut est l abanon (Presume Abort), les messages abanon ne sont onc pas confrmès et cette Ècson n a pas à être enregstrèe ans le journal u coornateur Reprse après panne S un partcpant tombe en panne penant l Ètape 1 e l UCM, la proprètè atomctè est volèe et le coornateur ffuse smplement la Ècson abanon. Supposons mantenant que le partcpant P k tombe en panne penant l Ètape 2 ou l Ètape 3 e l UCM. S le coornateur n a pas reçu la confrmaton e P k e la Ècson e valaton, l se peut que toutes les branches e la transacton aent ÈtÈ valèes sauf T k. Le partcpant P k est supposè garantr localement les proprètès ACID e T k. Donc, une fos que P k a termnè sa reprse locale, sot T k a ÈtÈ annulèe s P k est tombè en panne avant avor exècuter la valaton e T k, sot T k a ÈtÈ valèe localement s la panne e P k est ntervenue juste avant l envo e la confrmaton e la Ècson au coornateur. Ces eux stuatons ovent être tratèes ffèremment. En effet, la rè-exècuton e T k ans le erner cas peut conure à es ncohèrences s T k content es opèratons non empotentes (c est-à-re que la euxème exècuton une même opèraton ne onne pas le même rèsultat, comme, par exemple, une opèraton ncrèmentaton). Donc, s T k a ÈtÈ 9 Les partcpants sont sensès satsfare les hypothèses onnèes ans la secton 4.1

73 73 correctement valèe par P k, le coornateur ne ot ren fare. Dans l autre cas, T k est rè-exècutèe grâce au journal u coornateur qu content toutes les opèratons e T k. Grâce aux hypothèses fates en secton 4.1, la rè-exècuton e T k (comme une nouvelle transacton locale) est toujours possble et proura exactement le même Ètat e la base e onnèes que celu prout par l exècuton ntale. Le protocole UCM partage la même procèure e reprse que NB-SPAC, la preuve formelle e sa valtè peut être trouvèe ans [AGP02]. Le rôle e PAgent k penant la procèure e reprse est e Ètermner s T k ot être rè-exècutèe ou non. Pour cela, quan le PAgent e P k reçot la Ècson e valaton u coornateur (Ètape 3 e l UCM), l gènère une nouvelle opèraton «wrte recor <commt >» ans la branche e transacton T k avant e emaner à P k e valer T k. Cette opèraton va être tratèe par P k e la même manère que les autres opèratons e T k, qu sont toutes sot valèes, sot annulèes atomquement. Pour connaître l Ètat e la branche e transacton T k après une panne, PAgent k vèrfe smplement l exstence e l entrèe <commt > sur P k (ce qu peut être fat par une classque opèraton select). L exstence e cette entrèe prouve que T k a ÈtÈ correctement valèe sur P k avant la panne. Snon, T k a ÈtÈ annulèe à la reprse et elle ot être rè-exècutèe Applcaton pratque Tratement hors-lgne Revenons à l applcaton e commerce Èlectronque ntroute en secton 2Le but c est exècuter la transacton achat hors-lgne (c est-à-re en moe ÈconnectÈ) tout en mnmsant le rsque abanon à la reconnexon. La confguraton logcelle nècessare à cette applcaton est Ècrte en Fgure La transacton se Èroule comme sut : 1. L applcaton s exècute sur le moble ÈconnectÈ, où se trouve le LogAgent qu construt un journal contenant toutes les opèratons effectuèes par l applcaton e commerce Èlectronque (Etape 1 e l UCM). 2. A la reconnexon, le journal est transfèrè au Coornateur, hèbergè par une staton e base, qu force son Ècrture sur sque (Etape 2 e l UCM). 3. Le coornateur ffuse la Ècson e valaton à tous les PAgents (Etape 3 e l UCM). Le moble (qu joue les rôles u clent et un partcpant ans cet exemple) peut se Èconnecter u rèseau ès qu l a reçu la Ècson e valaton u coornateur, sans attenre les confrmatons es autres partcpants. La latence u protocole (qu Ètermne la urèe e connexon mnmale pour le moble) correspon au temps ms par le coornateur pour forcer

74 74 l Ècrture u journal. C est la borne nfèreure pour valer une transacton exècutèe hors-lgne car la proprètè e urabltè ne peut être assurèe que sur le rèseau fxe (un moble pouvant être peru ou volè). UCM est le protocole qu offre la plus fable probabltè abanon à la reconnexon. En fat, les hypothèses fates par l UCM sur les partcpants sont celles Ètables en secton 4.1. Donc les proprètès ACI sont assurèes rectement sur le moble tout au long e l exècuton e la transacton. La transacton ne peut être abanonnèe unquement en cas e panne u coornateur penant le laps e temps où l Ècrt ses journaux sur sque. S un es partcpants tombe en panne après cela, la procèure e reprse ÈtallÈe en secton 4.3 est actvèe. Log P APA CApp LA C C Log APA P P APA Supermarch Èt Banque Fgure 4.20 : Confguraton UCM pour l'applcaton e commerce Èlectronque Il est ntèressant e remarquer que l UCM et le tratement hors-lgne conusent aux mêmes contrantes pour les partcpants. En fat, les hypothèses les plus contragnantes fates par l UCM est le contrôle e concurrence pessmste et la vèrfcaton mmèate es contrantes ntègrtè pour Èvter tout contrôle à la fn e la transacton. Ces hypothèses sont prècsèment garantes par les technques ntroutes ans la secton 4.3 u chaptre 2 (par exemple : la rèservaton ou le bal) pour augmenter la probabltè e valer une transacton exècutèe hors-lgne Serveurs légers ConsÈrons mantenant l applcaton u porte-monnae Èlectronque (vor secton 2). Le but un protocole e valaton atomque ans ce contexte est accepter la partcpaton e systèmes hèrtès (c est-à-re ne supportant aucune nterface 2PC stanar) et e mnmser les ressources consommèes sur les partcpants lègers. Le melleur exemple e système lèger hèrtè est la carte à puce. La confguraton logcelle nècessare à cette applcaton est Ècrte en Fgure Dans cette confguraton, le porte-monnae Èlectronque peut se connecter au rèseau fxe auss ben par un termnal fxe que par un termnal moble. La transacton s exècute comme sut : 1. L applcaton s exècute sur le ste e la Banque, où se trouvent auss le LogAgent et le Coornateur. Les opèratons bancares sont exècutèes sur le porte-monnae Èlectronque (le

75 75 crèt) et sur le serveur e la banque (le Èbt) et sont journalsèes par le LogAgent (Etape 1 e l UCM). 2. A la fn e la transacton, le coornateur force l Ècrture u journal construt par le LogAgent sur sque (Etape 2 e l UCM). 3. Ensute, le coornateur ffuse sa Ècson aux PAgents (Etape 3 e l UCM). P Log App LA C PA PA P Banque P P PA PA Fgure 4.21 : Confguraton UCM pour l'applcaton u porte-monnae Èlectronque Les PAgents ont la charge e traute la emane e valaton venant u coornateur vers l nterface transactonnelle fourne par chaque partcpant. Le serveur e bases e onnèes e la banque ot normalement supporter l nterface 2PC stanar (c est-à-re X/Open Xa [X/OP91]). Dans ce cas, la emane e valaton peut être traute par la sèquence opèratons Xa_Prepare mmèatement suve par Xa_Commt ou par l opèraton Xa_CommtOnePhase. La commane Xa_CommtOnePhase a ÈtÈ conçue pour optmser la valaton e transactons mono-ste. Elle n a onc ren à vor avec les protocoles e valaton atomque à une phase mas peut être ÈtournÈe e son rôle ntal pour servr ans ce cas. A notre connassance, aucun fournsseur e cartes à puce n mplèmente nterface 2PC pour Èventes rasons e complextè. Le stanar ISO pour les cartes à puce [ISO99] Èfnt une nterface transactonnelle basque permettant e commencer, valer ou abanonner une transacton locale sur une carte à puce. La corresponance entre la emane e valaton UCM et l nterface e valaton offerte par la carte à puce est recte. Donc, les PAgents masquent l hètèrogènètè es partcpants au coornateur et permettent à tous types e serveurs (offrant une nterface 2PC ou non) e partcper au protocole UCM. Remarquons que s la carte à puce est extrate e son termnal urant le tratement e la transacton, le protocole e reprse ÈtallÈ en secton 4.3 est nvoquè à la reconnexon pour rejouer les opèratons sur le porte-monnae Èlectronque grâce au journal u coornateur. Comme nous le sons plus haut, la corresponance entre la emane e valaton e l UCM et l opèraton e valaton e la carte à puce est recte. Cela veut re qu aucun Ètat prêt ne ot