THÈSE. présentée à. par Nicolas Palix. DOCTEUR Spécialité: INFORMATIQUE. Langages dédiés au développement de services de communications

Transcription

1 N o d'ordr: 3623 THÈSE présnté à L'UNIVERSITÉ BORDEAUX 1 Écol Doctoral d Mathématiqus t Informatiqu par Nicolas Palix pour obtnir l grad d DOCTEUR Spécialité: INFORMATIQUE Langags dédiés au dévloppmnt d srvics d communications Thès dirigé par Charls Consl Soutnu l : 17 sptmbr 2008 Dvant la commission d'xamn présidé par Danil Hagimont t formé d : MM. : Pirr Coint Profssur à l'écol ds Mins d Nants Rapporturs Danil Hagimont Profssur à l'enseeiht, INP d Toulous MM. : Rnaud Marlt Chargé d rchrch à l'inria, Bordaux Examinaturs Charls Consl Profssur à l'enseirb, Bordaux M. : Touk Ahmd Maîtr d conférnc à l'enseirb, Bordaux Invité Univrsité Bordaux 1 Ls Scincs t ls Tchnologis au srvic d l'homm t d l'nvironnmnt

2

3 Thès réalisé au sin d l'équip-projt INRIA Phonix INRIA Bordaux Sud-Oust Bâtimnt A cours d la libération F Talnc Cdx LaBRI Unité Mixt d Rchrch CNRS (UMR 5800) 351 cours d la libération F Talnc cdx

4

5 à Auror t Aymi,

6

7 Rmrcimnts J tins tout d'abord à rmrcir ls mmbrs d mon jury : Danil Hagimont t Pirr Coint qui ont assumé la charg d rapportur, lurs avis t commntairs furnt un aid précius dans ls drnièrs smains t ls drnirs jours. J rmrci plus particulièrmnt Danil Hagimont qui m'a égalmnt fait l'honnur d présidr c jury, Rnaud Marlt dont la lctur minutius d ctt thès a prmis d corrigr t d précisr d nombrux détails, y compris dans ls annxs, Touk Ahmd d'avoir lu n détail c documnt. J tins nsuit à rmrcir mon dirctur d thès, Charls Consl, qui m'a accuilli au sin d l'équip projt INRIA Phonix. Grâc à ss rmarqus t ss consils, j'ai pu mnr à trm cs travaux. Laurnt Révillèr t Julia Lawall ont égalmnt participé aux succès d cs travaux. Lur aid t lur savoir-fair m'ont indéniablmnt prmis d progrssr. Laurnt Burgy, avc qui j'ai partagé quatr buraux diérnts au cours d cs quatrs annés, m'a prmis d surmontr ls instants d douts. J n'oublirai pas non plus nos discussions autour d'un café t son aid précius tout au long d ma thès, t plus particulièrmnt pndant la rédaction d c manuscrit. Il a n t été l prmir lctur d c manuscript. J'avais un collégu, j'ai trouvé un ami. Wilfrid Jouv, a.k.a Wiwi, qui a égalmnt partagé mon burau. Sans rancun, j'spèr! J m souvindrai d sa compagni apprécié lors d nos voyags n Allmagn t n Holland. Mêm si son nivau d'allmand st... disons scolair, nous somms malgré tout arrivr à bon port. Enn, si vous pouvz lir cs ligns, c'st grâc à lui t j l'n rmrci. J rmrci égalmnt ls autrs mmbrs d l'équip avc qui j'ai partagé ds momnts agréabls autour d'un café ou d'un baby-foot. J rmrci actuusmnt ms parnts, Moniqu t Michl, pour m'avoir prmis ds étuds aussi longu. Lur soutin indéfctibl a rndu possibl ma réussit scolair. J rmrci égalmnt ma s ur, Ann-Gaëll, t lui souhait d réussir dans sa nouvll vi n frlanc. J rmrci ms baux-parnts, Ann-Mari t Hubrt, dont j'ai rspctivmnt apprécié la cuisin t ls consils. J n'aurais put-êtr jamais commncé d thès sans ls ncouragmnts d mon bau-pèr. J rmrci nn ma fmm, Auror, t notr ll, Aymi. L soutin d'auror dans ls instants d dout, t plus particulièrmnt lors d la rédaction st instimabl. J'spèr pouvoir lui apportr un soutin aussi fort tout au long d notr vi. J lui dois aussi notr ll, Aymi. Ss nombrux sourirs t sa tndrss m'ont prmis ds instants d rpos salutair pndant la rédaction. Enfant modèl, j'ai pu avoir ds nuits prsqu normal. Qu la vi t'apport santé, bonhur t joi Aymi, gard c sourir qui t va si bin. Nicolas Palix, Copnhagu (Købnhavn), l 1 r novmbr 2008

8

9 Résumé Langags dédiés au dévloppmnt d srvics d communications Ls srvics d téléphoni IP xploitnt ds rssourcs résaux pour automatisr l traitmnt ds stimuli d communication. Cpndant, l'ajout d srvics rnd vulnérabl un systèm d téléphoni t put intrrompr son fonctionnmnt nominal. Pour présrvr un systèm d téléphoni, il faut garantir crtains propriétés d fonctionnmnt ds srvics déployés. Il xist ds solutions d dévloppmnt d srvics garantissant ds propriétés d fonctionnmnt mais lur xprssivité st réduit, limitant grandmnt lur utilisation. Ctt thès propos un approch fondé sur l concpt ds langags dédiés pour dévloppr ds srvics d communications. Ls langags dédiés (Domain-Spcic Languags) prmttnt d répondr au bsoin d dévloppmnt dans un domain particulir. Ils introduisnt un xprssivité t un dgré d vérication adaptés t spéciqus à un domain. Ls propriétés critiqus d'un domain sont vériés statiqumnt par l compilatur du langag. Dux nouvaux langags dédiés au domain ds communications ont été dévloppés : SPL (Sssion Programming Languag) t Pantaxou. L langag SPL srt à traitr ds mssags d signalisation pour la téléphoni IP. SPL or ds abstractions spéciqus pour garantir ls propriétés critiqus d la téléphoni IP. L langag Pantaxou généralis la notion d srvics d communications introduit par SPL n prmttant la coordination d'ntités communicants. C langag s décompos n dux partis : la prmièr consist à décrir un nvironnmnt d'ntités communicants, tandis qu la scond prmt d'xprimr ds logiqus d coordination pour cs ntités. Cs logiqus d coordination doivnt rspctr ls contraints xprimés par la dscription d'nvironnmnt. Ls contributions d ctt thès sont ls suivants : Nous avons ctué un analys ds srvics d communications. Ctt analys s concntr sur ls srvics d communications fondés sur l protocol SIP. Ls approchs xistants pour l dévloppmnt d srvics d communications fondés sur SIP sont notammnt présntés. Nous avons conçu un langag, nommé SPL, prmttant d dévloppr ds srvics d routag. Divrss analyss pour c langag garantissnt ds propriétés critiqus du protocol SIP sous-jacnt. Nous avons généralisé l dévloppmnt d srvics d communications. Nous avons dans c cadr conçu un langag, nommé Pantaxou, qui propos un concption d srvics d coordination n dux étaps prmttant ds vérications n amont du procssus d dévloppmnt. La concption t l'implémntation d cs langags améliornt l procssus d dévloppmnt ds srvics d communications t notammnt lur abilité. L'approch fondé sur l'utilisation ds langags dédiés qu nous proposons dans ctt thès ouvr, au dlà ds srvics d téléphoni, d nouvlls prspctivs quant au dévloppmnt d systèms distribués comm ls systèms ubiquitairs. Mots clés Langags dédiés, srvics d communications, téléphoni IP, géni logicil

10

11 xi Domain-Spcic Languags for Dvloping Communication Srvics Abstract IP tlphony srvics us ntwork rsourcs to automat communication stimuli procssing. Howvr, dploying srvics on a tlphony systm lads to safty issus, and programmrs nd to nsur som safty proprtis on thir srvics. Svral approachs allowing srvic dvlopmnt hav mrgd. Som of thm nsur safty proprtis by rstricting xprssivnss, limiting th scop of usag. This thsis proposs a nw approach that rlis on domain-spcic languags (DSL) to dvlop communication srvics. A domain-spcic languag is a programming languag ddicatd to a particular domain. Thir xprssivnss and vriability ar adaptd and spcic to a domain. A compilr statically chcks critical domain proprtis. Two nw DSLs hav bn dsignd for communication srvics, namly SPL (Sssion Procssing Languag) and Pantaxou. Th SPL languag allows dvloprs to spcify routing logic that procsss IP tlphony signaling. SPL ors abstractions spcic to mssag procssing that guarant th safty proprtis of IP tlphony. Th Pantaxou languag gnralizs th communication srvic concpt introducd by SPL allowing th coordination of communicating ntitis. Th languag consists of two parts: th rst on nabls th dscription of an nvironmnt of communicating ntitis; th scond on xprsss th coordination scnarios btwn ths ntitis. Ths scnarios must nsur som constrains with rspct to th nvironmnt dscription. Two compilrs nsur th nvironmnt consistncy and th scnarios consistncy rgarding th nvironmnt. Th contributions of this thsis ar as follows: ˆ W carry out an analysis of communication srvics. This analysis focuss on communication srvics basd on th SIP protocol. Existing approachs for dvloping SIP-basd communication srvics ar prsntd. ˆ W prsnt th dsign and implmntation of a languag, namd SPL, for programming routing srvics. Various analyss for this languag nsur critical proprtis of th SIP protocol. ˆ W gnraliz th srvic dvlopmnt to ntity srvics. W hav dsignd a languag, namd Pantaxou, that introducs a two-stp procss for th dvlopmnt of coordination srvics, nabling arly vrication during th dvlopmnt procss. ˆ Th dsign and implmntation of ths languags improv th dvlopmnt procss of communication srvics and spcially thir safty. Byond th domain of tlphony srvics, our DSL-basd approach opns up nw possibilitis for th dvlopmnt of distributd srvics in th ld of ubiquitous computing. Ky words Domain-Spcic Languags, Communication Srvics, IP Tlphony, Softwar Enginring

12

13 Tabl ds matièrs Rmrcimnts vii Résumé ix Abstract xi Tabl ds matièrs xiii Tabl ds gurs xix List ds tablaux xxi 1 Introduction Thès Contributions Organisation du documnt I Contxt 5 2 Srvics d communications Caractérisation ds communications Typs d donnés Mods d communications Entités communicants Caractérisation ds srvics d communications Srvics d routag Srvics ntités Bilan Srvics d téléphoni IP Téléphoni IP Introduction aux résaux informatiqus Introduction à la téléphoni Protocols binairs d téléphoni IP Protocols txtuls d téléphoni IP SIP n détail Srvics Opportunité Dévloppurs Contraints Bilan xiii

14 xiv Tabl ds matièrs 4 Langags dédiés Analys d domain Sourcs d'informations Points communs Variations Dénition d'un cahir ds chargs Risqus potntils Avantags scomptés Dénition d'un langag dédié Syntax Sémantiqu statiqu Sémantiqu dynamiqu Implémntation Couch d'abstraction Outils associés Bilan Solutions xistants Langags généralists Supports protocolairs Intrgicils Langags dédiés Langags XML Langags non-xml Bilan Démarch suivi Problématiqu Démarch global Un langag pour ls srvics d routag Un langag pour ls srvics ntités II Approch proposé 61 7 SPL Analys du domain Sourcs d'information Points communs Variations Cahir ds chargs Dénition du langag Syntax Sémantiqu statiqu Sémantiqu dynamiqu Bilan

15 Tabl ds matièrs xv 8 Mis n uvr d SPL Domain d l'étud Procssus d dévloppmnt Chaîn d compilation Analysur Génératurs d cod t intrprèts Machin virtull Dévloppmnt d srvics Bilan Pantaxou Analys du domain Sourcs d'information Points communs Variations Cahir ds chargs Dénition du langag Syntax Sémantiqu statiqu Sémantiqu dynamiqu Bilan Mis n uvr d Pantaxou Domain d l'étud Procssus d dévloppmnt Chaîn d compilation DiaGn Intrgicil généré Compilatur d logiqus Pantaxou Dévloppmnt d srvics Bilan III Bilan Apports Géni logicil Abstractions Évolutivité Portabilité ds srvics t réutilisation Fiabilité Bilan Conclusion Contributions Prspctivs Rmarqus nals

16 xvi Tabl ds matièrs Publications 127 Bibliographi 129 IV Annxs 139 A SPL Syntax 141 A.1 Lxical Convntions A.2 SPL Program A.3 Typ Exprssions A.4 Function Call A.5 Known URI Kinds A.6 Dclarations A.7 Statmnts A.8 Mssag Modication A.9 Exprssions A.10 SIP Hadrs A.11 Constant Rsponss B SPL Smantics 151 B.1 Simplid Syntax B.2 Static Smantics B.3 Addrsss B.4 Global Stat B.5 Usful Functions B.6 Sssion Managmnt B.7 Cor Languag Constructs B.7.1 Environmnts B.7.2 Judgmnts for Dclarations, Statmnts and Exprssions B.7.3 Entry Point of th Smantics B.7.4 Smantics of Handlr Bodis B.7.5 Smantics of Statmnts B.7.6 Smantics of Exprssions B.7.7 Smantics of Dclarations C Srvic d l d'attnt n SPL 175 D Pantaxou Languag 179 D.1 Domain Syntax D.2 Domain Static Smantics D.2.1 Static Smantics D.3 Srvic Syntax D.4 Srvic Static Smantics D.4.1 Static Smantics D.5 Dynamic Smantics D.5.1 Smantics of Top Lvl Dclarations and Handlr Paramtrs D.5.2 Smantics of Placs

17 Tabl ds matièrs xvii D.5.3 Smantics of Statmnts D.5.4 Smantics of Exprssions D.5.5 Smantics of Dclarations D.5.6 Ruls Rlativ to th Domain D.6 SIP Virtual Machin API E Gstionnair d lumièr 213

18 xviii Tabl ds matièrs

19 Tabl ds gurs 3.1 L modèl TCP/IP Exmpl d rquêt SIP Exmpl d répons SIP Architctur d'un résau SIP Dévloppmnt par décisions abstraits Exmpl d rprésntation graphiqu pour ls fonctionnalités d'un voitur Exmpl d rprésntation txtull pour ls fonctionnalités d'un voitur Notation BNF du langag Tiny Exmpl d programm valid pour la grammair du langag Tiny Exmpl d programm invalid syntaxiqumnt corrct pour l langag Tiny Règl d réécritur n sémantiqu opérationnll Règl d typag pour l'opératur + n Tiny Règl pour l'opératur + n Tiny Procssus d dévloppmnt d'un DSL Rdirction d'appls n SIP srvlt Rdirction d'appls n CPL Rdirction d'appls n LESS Rdirction d'appls n CCXML Rdirction d'appls n MSPL Rdirction d'appls n OpnSER Procssus d dévloppmnt d srvics d routag Procssus d dévloppmnt d srvics ntités Srvic comptur n SPL Srvic d manipulation d'n-têts n SPL Flot d contrôl intra-méthods Flot d contrôl intr-méthods Syntax abstrait du langag SPL fwd Méthod INVITE du srvic comptur n SPL fwd Vérication ds typs pour l langag SPL fwd Sémantiqu statiqu du langag SPL fwd Procssus d dévloppmnt d srvics d routag n SPL Architctur du srvur d'applications xix

20 xx Tabl ds gurs 8.3 Princip du srvic d l d'attnt Scénario d rdirction n fonction d la localisation Déclaration ds typs d donnés du modèl d'nvironnmnt Déclaration ds commands du modèl d'nvironnmnt Srvics d'un modèl d'nvironnmnt Gstionnair d la présnc Blutooth Agnt d présnc Srvic d rdirction d'appls (Téléphon virtul) Approch Pantaxou Domain pour la gstion d lamps n fonction d la luminosité Exmpl d gstionnair d lamps Invocation d la méthod pour un prmir INVITE

21 List ds tablaux 3.1 Srvics possibls n fonction d lur mplacmnt Classication ds événmnts SIP ranés En-têts accssibls par mots-clés Conguration d'un sssion n fonction d son typ Valur d la prsistanc n fonction d la trminaison d sssion Comparaison ds implémntations O'Caml t Java Ratio d génération pour l compilatur d modèls (implémntation pour la cibl ds srvics Wb Amigo) xxi

22 xxii List ds tablaux

23 Chapitr 1 Introduction La démocratisation d'intrnt t la récnt convrgnc ds résaux d télécommunications t ds résaux informatiqus ont prmis un ssor spctaculair ds communications d tous typs. La convrgnc d résaux d touts naturs, vrs un uniqu résau informatiqu, s'st accompagné d la création d protocols pour ls communications audio t vidéo, historiqumnt dévolus aux résaux d télécommunications. L protocol SIP occup aujourd'hui un plac prépondérant parmi cs protocols ; il st déployé par ls principaux opératurs téléphoniqus. Pour répondr à un volum d communications d plus n plus important, l'automatisation d lur traitmnt dvint un priorité. Pour répondr à c bsoin, l'émrgnc du protocol SIP s'st accompagné d la concption d'approchs pour l dévloppmnt d srvics d communications. Cs approchs protnt d la convrgnc ds résaux t prmttnt d fournir d nouvaux srvics aux utilisaturs. Ls srvics d communications puvnt êtr catégorisés slon dux classs : ls srvics d routag t ls srvics ntités. Ls srvics d routag intrcptnt ls stimuli d communications ntr dux ntités communicants. Ils modint évntullmnt cs stimuli an d rdirigr ls appls par xmpl. Ls srvics ntités sont ds ntités communicants. Cs srvics rçoivnt ds stimuli d communication t ls traitnt. Mais contrairmnt aux srvics d routag, ils puvnt aussi générr d tls stimuli. Par xmpl, un srvic d rappls automatiqus mt n rlation dux intrlocuturs dès qu'ils sont disponibls. Ls approchs xistants pour dévloppr ds srvics sont d dux ordrs : ls approchs fondés sur ls langags généralists t ls approchs fondés sur ds langags dédiés. Un langag dédié st un langag d programmation spécialisé pour un domain ou un class d problèms. La spécialisation d'un langag à un domain s matérialis par ds abstractions t ds notations spéciqus à c domain. L'introduction d cs abstractions t notations s'accompagn généralmnt d rstrictions prmttant d garantir ds propriétés critiqus du domain. Cpndant aucun solution n'st actullmnt approprié. D'un coté, ls solutions généralists sont complxs t nécssitnt ds compétncs multipls notammnt n programmation, télécommunications t résaux. Cs solutions n prmttnt pas un dévloppmnt simpl t sûr d srvics. D'un autr coté, ls approchs dédiés xistants sont haut nivau mais lorsqu'lls sont xprssivs, lls n sont plus sûrs. À l'invrs, ls approchs sûrs n fournissnt plus autant d'xprssivité, rstrignant ainsi ls possibilités orts. Il st donc souhaitabl qu ls dévloppurs d srvics d communications puissnt concvoir lurs srvics à l'aid d'un nouvll approch haut nivau, sûr t xprssiv. 1

24 2 Introduction 1.1 Thès C documnt propos un approch pour l dévloppmnt d srvics d communications. Ctt approch rpos sur l'introduction d dux langags dédiés prmttant l dévloppmnt d srvics d routag d'un part, t d srvics ntités d'autr part. La concption d cs langags dédiés s'st focalisé sur l compromis ntr xprssivité t sûrté qu ds abstractions haut nivau prmttnt. Ls propriétés critiqus du domain sont garantis par construction du langag ou analys ds programms. La faculté d'analysr ls programms pour garantir ds propriétés prmt d déclr ds rrurs ou ds incohérncs très tôt dans l procssus d dévloppmnt. Notr approch s fond sur l'introduction d dux langags dédiés aux srvics d communications. Un prmir langag, nommé SPL, prmt l dévloppmnt d srvics d routag. C langag st fondé sur l protocol d communications SIP, utilisé notammnt pour la téléphoni IP. Un scond langag, nommé Pantaxou 1, généralis l dévloppmnt d srvics d communications aux srvics ntités. Dans ls dux cas, ls srvics dévloppés à l'aid d cs langags sont analysés an d rjtr ls programms rronés ou incohérnts. Ls srvics valids sont nsuit déployés dans un nvironnmnt d'xécution ad hoc pour y êtr xécutés. 1.2 Contributions Ls contributions d ctt thès comportnt dux volts : l'analys d domain ds srvics d communications t dux langags pour l dévloppmnt d tls srvics. Ls langags proposés concrnnt d'un part ls srvics d routag avc SPL, t d'autr part ls srvics ntités, avc Pantaxou. Nous montrons dans chacun d cs dux cas la faisabilité t l'intérêt d'un approch langag. Analys d domain Nous présntons un analys ds srvics d communications. Ctt analys s'attach plus spéciqumnt aux srvics d communications fondés sur l protocol SIP. Nous étudions notammnt ls approchs xistants pour l dévloppmnt d srvics d communications fondés sur SIP. Sssion Procssing Langag (SPL) Nous avons conçu l langag SPL pour spécir ds srvics d routag. C langag intègr ds abstractions proprs aux srvics d routag t au protocol SIP. Cs abstractions nous prmttnt d raisonnr sur ls srvics dévloppés. Il st ainsi possibl d détctr ds rrurs ou incohérncs proprs aux srvics d routag fondés sur l protocol SIP. Pantaxou Nous avons généralisé l dévloppmnt d srvics aux srvics ntités. Ctt généralisation nous a conduit à concvoir l langag Pantaxou dédié à la coordination d'ntités communicants. Pantaxou s compos d dux langags complémntairs : l prmir prmt d décrir un nvironnmnt d'ntités communicants où ls srvics sont déployés ; l scond langag s'appui sur ctt dscription pour facilitr l dévloppmnt d logiqus d coordination. Nous décrivons l procssus d dévloppmnt n Pantaxou qui rpos sur un génératur d'intrgicil dédié à un nvironnmnt donné t sur un compilatur d logiqus d coordination pour ct intrgicil. 1 Pantaxou vint du grc Pantaqou qui signi partout. Pantaxou (ou Pantachou) s prononc [pãtaku]

25 Organisation du documnt Organisation du documnt Ctt thès comprnd trois partis principals : la présntation du contxt t d la problématiqu, la dscription d notr solution fondé sur un approch langag t nn ls apports d notr solution. Contxt La prmièr parti port sur l'étud du contxt dans lqul nous nous plaçons. L chapitr 2 présnt ls communications t ls srvics d communications dans ls résaux d télécommunications t ls résaux informatiqus. L chapitr 3 s'intérss plus particulièrmnt aux communications t aux srvics dans l cadr d la téléphoni IP. L chapitr 4 présnt l'approch ds langags dédiés sur laqull rpos notr solution. L chapitr 5 décrit ls solutions xistants pour l dévloppmnt d srvics d communications fondés sur SIP t lurs limitations. Dans l chapitr 6, nous présntons la démarch qu nous avons adopté pour répondr aux problèms posés par l dévloppmnt d srvics d communications. Ctt démarch décrit notr approch, d la problématiqu à la mis n uvr d'un implémntation. Approch proposé Dans la duxièm parti, nous décrivons ls dux composants d notr approch. Ls chapitrs 7 t 8 s'intérssnt aux srvics d routag. Cs chapitrs présntnt rspctivmnt la concption du langag SPL t la mis n uvr d c langag. La concption du langag SPL comprnd l'analys d domain t la dénition du langag. La mis n uvr du langag présnt l procssus d dévloppmnt d srvic à l'aid d SPL. L dévloppmnt d'un srvic SPL st notammnt présnté. Ls chapitrs 9 t 10 généralisnt l'approch du langag SPL aux srvics ntités. Cs chapitrs présntnt rspctivmnt la concption du langag Pantaxou t sa mis n uvr slon la mêm démarch qu l langag SPL. Bilan Dans la drnièr parti d c documnt, nous rprnons ls apports ds approchs langags SPL t Pantaxou au chapitr 11. Cs apports sont d dux ordrs : géni logicil t abilité. Enn, l chapitr 12 conclut n récapitulant nos diérnts contributions t présnt divrss prspctivs d rchrch.

26 4 Introduction

27 Prmièr parti Contxt 5

28

29 Chapitr 2 Srvics d communications L'invntion du télégraph élctriqu puis cll du téléphon ont accompagné la mis n plac ds prmirs résaux d télécommunications à l'échll mondial. Cs résaux, d'abord analogiqus, ont progrssivmnt migré vrs ds résaux dits numériqus. La numérisation d l'information consist à codr l'information sous la form d'un ux binair, c'st-à-dir un succssion d 0 t 1. La communication s'établit ntr dux partis situés à ds xtrémités du résau. Ls dux partis partagnt un algorithm qui cod l'information sous un form numériqu. L récptur put donc décodr l ux binair qu'il rçoit t rconstitur l'information d'origin. L'émttur t l récptur puvnt alors échangr t partagr d l'information. Ls résaux d télécommunications sont constitués d'équipmnts élctroniqus prmttant l transport du ux binair sur diérnts média tls qu ds onds radios, ds ls d cuivr ou d la br optiqu. An qu l ux binair puiss êtr transporté d façon optimal, n un minimum d tmps t sans dégradation, il st souvnt comprssé puis codé pour l médium utilisé. Parallèlmnt aux résaux d télécommunications, la démocratisation d l'ordinatur a prmis l'avènmnt ds résaux informatiqus. L'agrégation ds résaux informatiqus form l résau Intrnt. Intrnt st ainsi un résau d résaux informatiqus à l'échll mondial. C résau st très similair dans sa structur aux résaux d télécommunications t rpos sur ls mêms média d communications. La diérnc principal ntr cs résaux s situ dans ls protocols mis n uvr, c'st-à-dir l'nsmbl ds règls t ds mssags à rspctr lors ds communications, t la capacité d contrôl ds équipmnts au sin du résau. Ls résaux d télécommunications sont standardisés par l'uit, Union Intrnational ds Télécommunications. Ls résaux informatiqus sont ux standardisés par l'ietf, Intrnt Enginring Task Forc. Il n résult dux typs d résaux très hétérogèns n prmttant pas l'intropérabilité. D plus, il y a un diérnc fondamntal d concption ntr cs dux typs d résaux. D'un côté, ls équipmnts ds résaux d télécommunications sont complxs t contrôlnt ds trminaux basiqus tls qu ds téléphons. D l'autr côté, ls équipmnts ds résaux informatiqus ctunt ds tâchs simpls, s contntant ssntillmnt d'achminr l'information, tandis qu ls trminaux, comm ds ordinaturs par xmpl, sont complxs t contrôlnt ls communications. Cs drnièrs décnnis sont apparus ls téléphons mobils, ls assistants numériqus prsonnls (PDA pour Prsonal Digital Assistant) t la téléphoni via Intrnt. À chaqu nouvll génération, d nouvlls fonctionnalités sont ajoutés à cs périphériqus. D'un côté ls trminaux d télécommunications s complxint t prmttnt désormais l'nvoi d mssags 7

30 8 Srvics d communications txtuls, la navigation sur l Wb, l'utilisation du courrir élctroniqu. D l'autr côté, ds protocols informatiqus prmttnt d rmplir la fonction historiqu ds résaux d télécommunications grâc à la téléphoni via Intrnt. On obsrv un convrgnc ds fonctionnalités d cs dux grands résaux avc un migration progrssiv vrs un résau uniqu t informatiqu. L'utilisation, dpuis d nombruss annés, d cs résaux a profondémnt boulvrsé ls habituds t ls communications ntr êtrs humains. Ls communications jount désormais un rôl cntral dans ls sociétés qu c soit pour ds communications prsonnlls d'ordr privé ou profssionnl, pour ds communications lors d'échangs économiqus (bancairs ou boursirs par xmpl), ou ncor pour ds communications militairs (ntr ds troups t lur état major par xmpl). C nouvau rôl ds communications tnd à multiplir ls échangs d donnés t rndr omniprésnts ls communications. Ainsi, nous somms d plus n plus sollicités au téléphon, par courrir élctroniqu, par mssagri instantané, par mssags courts (SMS). Un assistanc dvint nécssair pour fair fac à la multiplication ds moyns d communications t à l'augmntation d lur usag. Ctt assistanc doit facilitr la gstion ds communications n automatisant crtains traitmnts d l'information t ainsi rndr un srvic à l'utilisatur. Par xmpl, un srvic d ltrag d courrirs élctroniqus prmt d rjtr automatiqumnt ls courrirs indésirabls. Nous nous attachrons dans c chapitr à caractérisr ls communications ainsi qu ls srvics d communications associés. L'objctif st d pouvoir ls catégorisr an qu lur hétérogénéité n soit plus un frin à lur compréhnsion. 2.1 Caractérisation ds communications Ls communications sont caractérisés par plusiurs critèrs : la variété ds typs d donnés échangés t ls diérnts façons d réalisr ls échangs ; nous parlrons d mods d communications. Enn, ls communications s dénissnt n fonction ds ntités communicants miss n jux lors d la communication Typs d donnés L but d'un communication st d'échangr d l'information ntr l'émttur t l récptur. L'information échangé put êtr un txt, d la voix, un vidéo mais aussi un msur numériqu, nvoyé par xmpl par un captur d tmpératur. Lorsqu l'information st un txt, clui-ci put prndr plusiurs formats, plus ou moins structurés allant du txt brut à du LaTX [MGB + 04] ou d l'odf (Opn Documnt Format) [OAS07] n passant par du HTML (HyprTxt Markup Languag) [W3C02] ou du XML (Xtnsibl Markup Languag) [BPSM + 06]. D la mêm manièr, il xist plusiurs formats pour ls autrs typs d donnés comm la vidéo, l son ou ls imags. Ls ux multimédia, souvnt audio t vidéo, sont particulièrmnt voluminux. An d réduir l'spac disqu ou l tmps d transfrt, il st courant d ls comprssr. Il xist pour cla plusiurs dizains d méthods. Chaqu méthod d comprssion st bin évidmmnt révrsibl an d pouvoir rstitur l'information d'origin, évntullmnt dégradé. On parl d'ncodur pour l logicil réalisant la comprssion t d décodur lors d la décomprssion. Un codc, contraction ds trms codur t décodur, fait référnc à l'nsmbl ds dux logicils. Pour qu dux intrlocuturs soint capabls d communiqur, ils doivnt préalablmnt convnir du format ds donnés à échangr t donc du codc à utilisr.

31 Caractérisation ds communications 9 Dans ls résaux téléphoniqus historiqus, il n'xist qu dux norms, l'ncodag utilisant la loi A, G.711 A-law, t clui utilisant la loi µ, G.711 µ-law. La prmièr st utilisé n Europ tandis qu la scond st utilisé n Amériqu du nord t au Japon. L'intropérabilité ds résaux prmttant à un français d téléphonr à un américain ou à un japonais n'st donc pas compliqué puisqu'il n'y a qu dux formats utilisés. Dans la téléphoni via Intrnt, il xist un multitud d formats utilisabls tls qu Spx [Spa], ilbc [ADA + 04], G.729, GSM ou ncor l format G.711 sous ss dux variants. Il dvint alors baucoup moins facil d garantir l'intropérabilité du systèm. Crtains codc, comm l G.729, sont protégés par ds brvts t lur utilisation rquirt l vrsmnt d royaltis. D'autrs n'ont pas lur spécication publiqu. D fait, crtains codc n sont pas ou n puvnt pas êtr présnts sur l'nsmbl ds téléphons utilisés pour la téléphoni via Intrnt. Il dvint dans cs conditions plus dicil d pouvoir garantir ls communications ntr ds intrvnants. On rtrouv l problèm d'intropérabilité pour d'autrs typs d donnés. L mécanism d codc st n t égalmnt utilisé pour comprssr ls imags, qu'il s'agiss d'imag uniqu ou d séqunc d'imags, c'st-à-dir d vidéo. Ls imags puvnt êtr stockés, par xmpl, sous ds formats tls qu BitMaP (BMP), JPEG Fil Intrchang Format (JFIF), Graphics Intrchang Format (GIF), Portabl Ntwork Graphics (PNG), Scalabl Vctor Graphics (SVG), Windows Mta Fil (WMF), Taggd Imag Fil Format (TIFF). Ls vidéos quant à lls sont ncodés avc ds formats tls qu Cinpak, H.263, MPEG-2, MPEG-4, RalVido, Thora, Windows Mdia Vido. Cs lists n sont absolumnt pas xhaustivs t évolunt avc l'apparition d nouvaux codc. Chaqu typ d rprésntation d l'information présnt ds avantags t ds inconvénints. Tous cs formats sont donc utilisés, mêm si n pratiqu qulqus uns dominnt n trm d'usag. Il st vital dans un société fondé sur ls communications t ls échangs d garantir l plus tôt possibl la compréhnsion par l récptur d l'information émis t c malgré l'abondanc ds typs d donnés t d lur format. Garantir l succès d'un communication prmt d'évitr ls échangs inutils. La congstion du résau t ls traitmnts inutils d la part ds intrvnants sont ainsi éludés Mods d communications L'échang d donnés lors d'un communication put s'ctur d plusiurs manièrs. Ls donnés puvnt êtr nvoyés spontanémnt par l'initiatur d la communication, ou au contrair, réclamés par clui-ci. Dans ls dux cas, il put poursuivr d'autrs traitmnts n attndant un répons, ou au contrair, attndr un répons an d pouvoir poursuivr son propr traitmnt. Il y a donc dux plans à distingur, chacun ayant un rôl particulir : l plan d contrôl, qui gèr la communication, t l plan d donnés, qui achmin d l'information. Nous allons à présnt voir ls diérnts possibilités qui xistnt pour chacun d cs dux plans Plan d contrôl L plan d contrôl gèr l cycl d vi ds communications plutôt qu lur contnu, c.-à-d. ls donnés qui circulnt. L plan d contrôl prmt d'idntir : l'initiatur d'un communication, ls princips régissant l'échang d donnés, t si l'opération d communication st bloquant ou pas. Il xist dux typs d contrôl, ls communications synchrons t ls communications asynchrons.

32 10 Srvics d communications Communications synchrons Lorsqu'un rsponsabl dmand un rnsignmnt à un mployé, il contrôl la communication mais l'information st donné par l'mployé. Dans l cas d'un information simpl t connu d l'mployé, l rsponsabl st n attnt d'un répons immédiat. L'mployé doit alors fournir l'information dmandé avant d pouvoir rprndr sa tâch précédnt. D manièr similair, lors d'un appl téléphoniqu, c'st l'applant qui initi la communication. Ls dux intrlocuturs puvnt nsuit convrsr t, dans la plupart ds cas, n font rin d'autr n mêm tmps. À la n d la convrsation, ls intrlocuturs raccrochnt. Chacun put alors rprndr un autr activité. Lorsqu, comm dans cs dux xmpls, un intrvnant, ou l'nsmbl ds intrvnants, st monopolisé par la communication, on parl d communications synchrons, ou bloquants. Communications asynchrons Lorsqu'un rsponsabl souhait diusr un not d srvic, il a l'initiativ d la communication t n s'assur pas qu la not st bin lu par ls mployés. D mêm, lors d l'nvoi d'un courrir élctroniqu, l'xpéditur n'attnd pas d rtour pour savoir si l courrir élctroniqu st bin arrivé. Dans cs dux cas, l'initiatur d la communication n rst pas n attnt d'un répons. On parl dans c cas d communications asynchrons, ou non bloquants. Nous allons à présnt voir un autr xmpl d communication asynchron. La diérnc résid dans l fait qu l'information n'st pas émis par l'initiatur d la communication mais au contrair, l'information st réclamé par clui-ci. Lorsqu'un rsponsabl dmand un rapport à un mployé, il contrôl la communication mais l'information st donné par l'mployé. L rapport doit préalablmnt êtr réalisé c qui put prndr un crtain tmps. L rsponsabl n s'attnd donc pas à rcvoir immédiatmnt l rapport. Lorsqu l'mployé st n msur d fournir l rapport dmandé, il l transmt à son rsponsabl. Dans un situation tll qu cll décrit ci-dssus, on parl égalmnt d communications asynchrons. En t, l rsponsabl n'attnd pas oisivmnt l rapport mais put s'aairr à d'autrs tâchs. L'mployé l notira plus tard, lorsqu l rapport sra prêt. L fait qu l'mployé noti son rsponsabl, alors qu c'st c drnir qui a initié la communication, constitu un invrsion du contrôl. C'st n t l'mployé qui acquirt, dans un crtain msur, l contrôl d la communication t du momnt où il fournira l rapport. Ls communications synchrons caractérisnt l fait qu l'intrvnant qui initi la communication rst n attnt d la répons d son intrlocutur. Tandis qu ls communications asynchrons caractérisnt l fait qu l'intrvnant qui initi la communication, put xécutr d'autrs tâchs immédiatmnt. Lorsqu l'initiatur d la communication souhait rcvoir un information, il dmand à êtr notié a postriori Plan d donnés Nous allons à présnt analysr commnt circulnt ls donnés ntr ls intrvnants n fonction ds diérnts typs d contrôl idntiés précédmmnt. Communications synchrons Lorsqu l rsponsabl dmand un information à l'mployé, ls donnés circulnt d l'mployé vrs l rsponsabl. Toutfois, il st fréqunt qu ds donnés provinnnt du rsponsabl. C drnir fournit un contxt à l'mployé. Si l rsponsabl dmand l nombr d participants à un réunion, il st probabl qu'il donn égalmnt

33 Caractérisation ds communications 11 un information d contxt comm un dat t évntullmnt un horair. D c simpl xmpl, nous pouvons déduir qu ls donnés puvnt circulr dans ls dux dirctions ntr ls intrvnants. Lors d'un appl téléphoniqu, ls donnés circulnt égalmnt d façon bidirctionnll. Mais contrairmnt à l'xmpl précédnt où ls échangs s suivaint n séqunc, l'échang d'information form dux ux d donnés audio, c'st-à-dir un succssion d'échantillons d voix. Cs dux ux sont simultanés t d sns opposé. Ls dux intrlocuturs puvnt parlr n mêm tmps. Mêm si, dans l cas d'intrlocuturs humains, cla présnt pu d'intérêt, dans l cas d communications ntr dux équipmnts élctroniqus, ctt capacité à communiqur simultanémnt dans ls dux sns prmt d'optimisr la communication. Par xmpl, lors d la synchronisation ntr dux systèms, chacun put nvoyr ls nouvlls informations pndant qu'il rçoit clls d l'autr. Nous rtindrons d cs xmpls trois princips. L plan d donnés st orinté ntr un émttur t un récptur. L'initiatur d la communication put fournir un contxt s'il n'st pas l'émttur. Et, lors d communications d ux d donnés, ls dux intrvnants puvnt êtr à la fois émttur t récptur. Communications asynchrons Nous avons précédmmnt vu trois xmpls d communications asynchrons, la diusion d'un not d srvic, l'nvoi d'un courrir élctroniqu t la dmand d'un rapport. Dans ls dux prmirs xmpls, ls donnés sont émiss par l'initiatur d la communication. Au contrair, dans l troisièm xmpl, ls donnés, c'st-à-dir l rapport, n sont pas émiss par l'initiatur mais par son intrlocutur, l'mployé. L plan d donnés st orinté d l'émttur vrs l récptur, comm c'st l cas avc un communication synchron. D plus, l'initiatur put êtr égalmnt l'émttur ds donnés. Ls donnés puvnt donc êtr échangés dans ls dux sns vis à vis d l'initiatur d la communication lors d communications asynchrons. Nous rtindrons égalmnt qu'il n'xist pas d communication asynchron pour l'échang d ux d donnés car l'échang d'un ux d donnés nécssit un synchronisation ntr ls intrlocuturs an qu'ils négocint ls paramètrs du ux. Nous pouvons à présnt classr ls communications n dux grands famills : d'un part ls communications synchrons t d'autr part ls communications asynchrons. An d bin idntir l mod d communications utilisé lors d'un échang d donnés, nous ranrons la dscription n orintant l plan d donnés Entités communicants Dans la sction 2.1.1, nous avons vu ls diérnts typs d donnés échangés t dans la sction précédnt, commnt cs donnés sont échangés. Nous allons à présnt caractérisr ls intrvnants. Cs intrvnants ont vocation par natur à communiqur, nous utilisrons égalmnt à partir d maintnant l trm d'ntités communicants pour ls désignr. Il xist dux typs d'ntités communicants, ls êtrs humains t ls machins. La modélisation ds communications humains sortant du cadr d ctt étud, nous ls prndrons n compt grâc à la modélisation ds dispositifs qui intragissnt avc ds êtrs humains. Nous modélisons indirctmnt ls communications humains n modélisant ds dispositifs comm ls téléphons, ls écrans, ls caméras t ls imprimants.

34 12 Srvics d communications Caractérisr ls ntités communicants rvint alors à caractérisr ls dispositifs matérils t logicils qui communiqunt. Pour caractérisr ls ntités, il faut êtr capabl d ls décrir n trm d propriétés t d moyns d communications. Nous utilisrons l trm d fonctionnalité pour fair référnc aux divrs moyns d communications Propriétés ds ntités Tous ls dispositifs ont ds caractéristiqus, ds spécications qui ls diérncint ls uns ds autrs. Tous ls ordinaturs n'ont pas forcémnt la mêm capacité d mémoir viv. La résolution, ls codc ou la profondur d'imag d'un caméra sont autant d'élémnts qui la caractérisnt. Cs propriétés sont ds donnés décrivant ls ntités. Il st possibl d'utilisr ls typs d'informations présntés dans la sction pour rprésntr ls donnés. Ls propriétés rprésntnt ds caractéristiqus statiqus ds ntités comm la vitss du procssur pour un ordinatur ou ls codc disponibls sur un caméra. Toutfois crtains sont dynamiqus. Un PDA par xmpl st un périphériqu mobil, d mêm qu'un téléphon GSM ou WiFi (Wirlss Fidlity). Il st intérssant d pouvoir localisr cs objts. Il st ainsi possibl d localisr indirctmnt lur propriétair ou d'indiqur à clui-ci où s trouv son bin. La propriété indiquant la localisation put donc êtr dynamiqu pour crtains ntités. Nous rtindrons qu ls ntités communicants sont caractérisés à l'aid d propriétés. Ls propriétés sont ds donnés dont la rprésntation st détrminé par un typ. D mêm qu l'ntité évolu dans l tmps, crtains d ss propriétés évolunt. Il y a donc ds propriétés statiqus t d'autrs dynamiqus Fonctionnalités Nous avons vu commnt dénir ls caractéristiqus d'un ntité à l'aid d propriétés. Il rst cpndant ds caractéristiqus primordials à dénir pour chaqu ntité. Il s'agit d ss moyns d communications. Commnt communiqu un ntité? Qu'échang-t-ll comm donnés? Un fonctionnalité st l'association d'un mod d communications t d'un typ d donnés. Ell décrit ainsi commnt un crtain typ d donnés st échangé. Un ntité dispos d plusiurs fonctionnalités. Il st ainsi possibl d'échangr diérnts donnés d diérnts façons. Un ordinatur put ainsi êtr vu à la fois comm un ntité d'achag pour ds imags ou ds vidéos, un ntité d captur audio, un ntité d rndu audio t un ntité d stockag. L corollair st qu'il st possibl d'échangr la mêm donné d diérnts façons. Un captur d tmpératur put ainsi êtr consulté à la dmand, d manièr synchron, ou émttr d lui-mêm ds msurs d tmpératur à ds ntités qui n auraint fait la dmand. Il s'agirait alors d'un communication asynchron. Enn, un captur put communiqur un ux d msurs à un ntité, pour réalisr un assrvissmnt par xmpl. Nous pouvons dénir ls communications slon trois critèrs : (i) l typ ds donnés échangés, (ii) l mod d communications utilisé t (iii) ls ntités qui communiqunt. Ls ntités communicants sont d typ très diérnts : téléphons, capturs d msur, caméras, écrans, équipmnts élctroménagrs. Il y a donc un problèm pour ls modélisr t pouvoir suivr lur évolution. L'apparition constant d nouvlls ntités st un factur aggravant. Ctt pléthor d'ntités communicants induit un augmntation ds communications. Nous

35 Caractérisation ds srvics d communications 13 pouvons caricaturr n disant qu tous ls objts communiqunt tout l tmps. Nous nous approchons chaqu jour un pu plus d ctt caricatur. 2.2 Caractérisation ds srvics d communications Pour fair fac à l'xplosion du nombr d communications t d sollicitations, l'automatisation d crtains tâchs dvint impérativ. Un solution pour automatisr ds traitmnts consist à dévloppr ds srvics d communications. Ls srvics d communications s distingunt n dux classs d srvics. D'un côté, la class ds srvics d routag rgroup ls srvics qui modint la communication pndant son transit dans l résau. D'un autr côté, la class ds srvics ntités rgroup ls srvics qui ont l rôl d'un intrvnant dans la communication. Ls srvics ntités sont ainsi capabls d réagir t traitr ls stimuli d communications. Ils puvnt d plus générr ds communications vrs d'autrs srvics Srvics d routag La caractéristiqu principal d la class ds srvics d routag st qu l'initiatur d la communication n'a pas connaissanc d lur présnc. Il n put d'aillurs pas, dans la plupart ds cas, la soupçonnr. La notion d srvic d routag st transvrsal par rapport aux typs d donnés. On trouv ainsi ds srvics d routag dans ds domains aussi variés qu l courrir élctroniqu t la téléphoni. Courrir élctroniqu Qui voudrait ncor ltrr son courrir élctroniqu indésirabl, ou spam, manullmnt? Il st déjà d plus n plus dicil d fair fac aux courrirs traditionnls. Pour luttr contr l problèm du courrir indésirabl, il xist ds solutions prmttant d trir, t évntullmnt supprimr c courrir automatiqumnt [Spa]. Cs srvics antispam sont souvnt réalisés au nivau du srvur d courrir élctroniqu dans l résau pour l'nsmbl ds usagrs d'un organisation. C typ d srvics agit sur un communication initialmnt prévu ntr l'xpéditur du courrir t l'un ds dstinatairs. L srvic d ltrag du courrir n fait qu modir la communication n déplaçant l spam n dhors du courrir ntrant, c'st-à-dir dans un autr boît aux lttrs. Ctt opération qui consist à groupr t trir l courrir n fonction d'un critèr, s'appll l routag. On utilis par xtnsion l trm routag pour touts ls opérations qui consistnt à détrminr la dstination d'un information. Il xist ainsi l routag d paquts IP ou ncor l routag d'appls. Un autr xmpl d srvic d routag du courrir concrn l'utilisation ds lists d diffusion. Il st fréqunt d'êtr mmbr d'un list d diusion t d rcvoir ainsi ds courrirs élctroniqus dstinés, par xmpl, à l'nsmbl d'un srvic administratif dans un organisation. Il st alors pratiqu d séparr c typ d courrir, du courrir plus prsonnl, n l plaçant dirctmnt dans un autr boît aux lttrs qu cll du courrir ntrant. Il xist, pour facilitr t prmttr aux utilisaturs d prsonnalisr l routag d lurs courrirs, ds solutions comm Siv [GS08]. Il s'agit d'un ptit langag à script prmttant d routr l courrir n fonction ds propriétés d clui-ci. Il st ainsi possibl d routr tous ls mssags provnant d'un prsonn, ou ayant un thématiqu commun, dans un boît aux lttrs particulièr. Téléphoni Il xist l mêm gnr d srvic d routag pour ls appls téléphoniqus. Il st ainsi possibl d systématiqumnt rfusr ls appls anonyms ou d rdirigr ls appls n

36 14 Srvics d communications cas d'absnc ou d non répons vrs un autr numéro. Enn, dans ls ntrpriss disposant d lur propr résau téléphoniqu pour ls appls intrns, il st possibl d prndr ls appls d'un téléphon qui sonn, à partir d'un autr téléphon ou d fair sonnr l'nsmbl ds téléphons d'un burau (bin qu chacun d'ux ait son propr numéro) Srvics ntités La class ds srvics ntités idnti ls srvics qui s comportnt comm un ntité communicant. Ils puvnt nvoyr un courrir élctroniqu ou répondr au téléphon comm c'st l cas avc un répondur téléphoniqu. Enn, dans ls systèms ubiquitairs, touts ls ntités sont communicants t capabls d'intragir avc lur nvironnmnt. Courrir élctroniqu Il xist ds srvics d courrir élctroniqu qui agissnt comm un ntité. Lorsqu'un prsonn part n vacancs, ll put congurr sa boît aux lttrs pour qu'un courrir, indiquant par xmpl sa dat d rtour, soit automatiqumnt nvoyé aux prsonns qui lui écrivnt. L srvic gérant l'nvoi du courrir automatiqu n cas d'absnc s comport comm un ntité communicant. Il xist d'autrs srvics utilisant l courrir élctroniqu comm moyn d communications. Par xmpl, il xist ds logicils pour la gstion d list d diusion tl qu Mailman [Mai] ou Majordomo [Maj]. La particularité d cs gstionnairs st qu'ils autorisnt la gstion ds lists d diusion par un adrss d courrir élctroniqu particulièr. Il st ainsi possibl d'administrr la list malist@mondomain.com via ds courrirs nvoyés à l'adrss malist-rqust@mondomain.com. L logicil d gstion ds lists st alors un ntité à doubl titr. D'un part, il répond aux courrirs sur l'adrss ds rquêts, t d'autr part, il copi ls courrirs adrssés à la list à chacun ds mmbrs. Téléphoni D manièr similair, il xist ds srvics d téléphoni qui s comportnt comm ds ntités communicants. C'st l cas notammnt avc, par xmpl, un répondur vocal. Il décroch automatiqumnt, évntullmnt après un délai d'attnt, puis fait un annonc. Enn, il nrgistr l mssag d l'applant t raccroch. Il a fallu attndr près d soixant ans après l'invntion du téléphon pour voir apparaîtr l prmir répondur n Près d soixant ans après, d nouvaux srvics apparaissnt ncor. Dpuis qulqus annés, il st fréqunt d trouvr un mnu vocal lorsqu l'on téléphon au srvic clint d'un ntrpris ou à un organism publiqu. Plus récmmnt, cs mnus vocaux s sont nrichis d synthès vocal. Il st désormais possibl d'écoutr son courrir élctroniqu grâc à un srvic téléphoniqu. Systèms informatiqus ubiquitairs Ls systèms informatiqus ubiquitairs sont ds systèms composés d'un multitud d périphériqus élctroniqus. Cs périphériqus sont disprsés dans ls nvironnmnts qui nous ntournt, la maison, l burau, l'atlir d'usin, la ru, la voitur, tc. Ils ont la particularité d pouvoir communiqur. Ils utilisnt pour cla diérnts média, résaux lairs t non-lairs. Cs périphériqus sont donc ds ntités communicants au sns où nous l'avons déni. Cs ntités puvnt allr d'un simpl lamp à l'élctroménagr, n passant par ls équipmnts multimédia. Un pléthor d srvics st alors possibl comm survillr la cuisson du rôti dpuis sa télévision pndant qu l'on rgard un lm ou mttr automatiqumnt sur paus un lm avant mêm qu l téléphon n sonn t prndr l'appl sur son télévisur. L réfrigératur put

37 Bilan 15 diusr ds mssags d'alrt sur un écran indiquant ls produits périmés ou n pass d l'êtr. Il put égalmnt fair l'invntair ds produits à n pas oublir lors ds prochains courss voir mêm passr command automatiqumnt sur un sit Intrnt marchand via l'ordinatur. Tous cs scénarios ncor futurists sront très prochainmnt possibls. Il convint d s'y préparr au miux t d'appréhndr l plus tôt possibl ls problèms qui vont survnir. L'nsmbl ds ntités présntés communiqunt ds informations d natur très diérnt. L dévloppmnt d srvics prmttant la coordination d cs ntités st un vrai dé. En t, la programmation d tls srvics nécssit d pouvoir manipulr ds typs d donnés arbitrairs. D plus, ls donnés sont échangés slon ls diérnts mods d communications qu nous avons vus. Enn, ls ntités disposnt d fonctionnalités spéciqus pour communiqur qui dépndnt d lur natur intrinsèqu. Actullmnt, l dévloppmnt d srvics ubiquitairs st ad hoc. L'approch actull n prmt pas la réutilisation ds srvics déjà écrits, ni la coopération d cs drnirs pour fournir d nouvaux srvics plus richs. Il st important d bin idntir t diérncir cs dux typs d srvics : ls srvics d routag t ls srvics ntités. En t, ls srvics d routag opèrnt lors d la communication ntr ds ntités t utilisnt pour prndr lur décision ds caractéristiqus d la communication tls qu l'xpéditur, l dstinatair, l sujt, l'hur. Généralmnt, ils n'utilisnt pas t n savnt pas manipulr ls donnés qui transitnt lors d la communication. Ls srvics ntités sont ds ntités communicants t sont donc à c titr n msur d'utilisr, d manipulr ou d'émttr ds donnés pndant la communication. 2.3 Bilan Ls communications prnnnt un plac prépondérant dans notr société. Tandis qu ls communications s multiplint t s complxint, il faut pouvoir ls maîtrisr. Il st donc nécssair d'automatisr crtains traitmnts. L traitmnt automatiqu ds communications constitu un srvic. L dévloppmnt d tls srvics pos plusiurs problèms. Il faut pouvoir tnir compt d la grand hétérogénéité ds communications tant au nivau ds ntités communicants qu d lurs fonctionnalités, c'st-à-dir ds typs d donnés t ds mods d communications. D plus, ls communications qu nous considérons s'ctunt par natur ntr ds ntités distants. Ells formnt un systèm distribué, construit autour d'un résau. La programmation d srvics d communications doit facilitr la coordination ntr ls srvics présnts dans l résau. L modèl d programmation doit abstrair ls problèms liés à la distribution ds donnés ainsi qu'à l'hétérogénéité ds communications. Enn, n fonction d l'objctif d'un srvic, un dévloppur doit mttr n uvr, soit un srvic d routag ds communications, soit un srvic ntité qui s comport comm un ntité communiquant. Ls résaux informatiqus fournissnt un srvic d transport d donnés. C transport ds donnés constitu l support d bas ds communications. Pour prmttr ds communications particulièrs sur un tl résau, ds protocols applicatifs ont été dénis. Ils normalisnt ls échangs n fonction d l'objctif d'un application donné. La normalisation ds protocols applicatifs fournit aux utilisaturs un minimum d'intropérabilité ntr ls systèms. Dans l chapitr suivant, nous allons présntr qulqus uns d cs protocols résaux prmttant d gérr ds communications au nivau applicatif.

38 16 Srvics d communications

39 Chapitr 3 Srvics d téléphoni IP L domain d la téléphoni a vécu un révolution avc la convrgnc ds résaux d télécommunications t ds résaux informatiqus. Ls fonctionnalités d la téléphoni IP dépassnt désormais un simpl appl téléphoniqu. La téléphoni IP intègr ds fonctionnalités d présnc t d mssagri instantané ainsi qu l support d la vidéo. D fait, la téléphoni IP illustr parfaitmnt la divrsité ds typs d communications qu nous vnons d voir. D plus, à l'instar d la téléphoni traditionnll, il s'agit d'un domain où d nombrux srvics sont possibls. L dévloppmnt d cs srvics pos cpndant plusiurs problèms. Ls srvics doivnt-ils êtr déployés dans l résau ou sur ls trminaux? L'ajout d programms utilisatur dans l systèm d téléphoni st un sourc d'rrur. Commnt présrvr l comportmnt nominal d'un systèm d téléphoni n présnc d srvics? Tout n présntant diérnts systèms d téléphoni IP, nous chrchrons clui capabl d'orir l'nvironnmnt l plus propic au dévloppmnt d srvics. 3.1 Téléphoni IP Ls systèms d téléphoni IP sont fondés sur ls résaux informatiqus. Après un court introduction aux résaux informatiqus t à la téléphoni, nous vrrons divrs protocols d téléphoni IP. À l'instar ds protocols n général, ils s répartissnt n dux grands catégoris, d'un part ls protocols binairs t d'autr part ls protocols txtuls. Nous trminrons ctt sction par la présntation d'un protocol particulir d téléphoni, l protocol SIP (Sssion Initiation Protocol) Introduction aux résaux informatiqus Dès ls prmirs systèms informatiqus, un ds prmièrs préoccupations fut d ls intrconnctr. Ds nsmbls d règls t d convntions ont donc été formalisés pour dénir ls mssags échangés, t notammnt lur format. Cs nsmbls d règls t d convntions formnt ds protocols. Chaqu protocol rmplit un fonction particulièr qui srt d fondation à un autr protocol. On obtint ainsi un mpilmnt protocolair. L modèl TCP/IP, voir Figur 3.1, st l'mpilmnt protocolair d référnc pour Intrnt. Il st fondé sur ls protocols du mêm nom, TCP [Pos81b] (Transmission Control Protocol) t IP [Pos81a] (Intrnt Protocol). La prmièr couch, la couch d'accès au résau physiqu, s décompos n dux fonctionnalités. D'un part, ll dénit l protocol codant l signal sur l médium, par xm- 17

40 18 Srvics d téléphoni IP pl ds ls d cuivr ou un br optiqu. D'autr part, ll assur la gstion d la connxion ntr dux équipmnts dirctmnt rliés par c médium, par xmpl un ordinatur t un commutatur. L protocol Ethrnt [Ass05] st un xmpl connu d protocol d la couch d'accès au résau. L protocol IP st un protocol d la scond couch, la couch résau. Il assur la connxion ntr ds domains, par xmpl inria.fr t labri.fr. Ls machins sont idntiés par un adrss IP. Enn, l protocol TCP st un protocol d la couch transport. Il fournit un connxion d bout n bout, ntr dux systèms informatiqus d'un résau informatiqu, ou résau IP. Un connxion st caractérisé localmnt par un port d communication. Ctt connxion d bout n bout st ainsi déni par quatr élémnts : dux adrsss IP t dux ports d communication. L résau Intrnt st fondé sur l'mpilmnt d la couch transport TCP au-dssus d la couch résau IP. Au-dssus d la couch transport s trouv la couch application. L rôl d ctt couch st d fournir un srvic spéciqu tl qu l courrir élctroniqu, l Wb ou la téléphoni. An d rndr ds srvics spéciqus, un protocol applicatif, c'st-à-dir un protocol d la couch application, st déni pour chaqu srvic. On trouv ainsi ls protocols SMTP, POP t IMAP [Pos82, MR96, Cri96] pour l courrir élctroniqu. Chacun rmplissant un tâch particulièr dans l'achminmnt du courrir ntr l'xpéditur t l dstinatair. L srvic du Wb st réalisé grâc au protocol HTTP [FGM + 97]. Enn, dpuis la convrgnc ds résaux d télécommunications t ds résaux informatiqus, la téléphoni st assuré par ds protocols applicatifs. Application HTTP, FTP, DNS Transport TCP, UDP, SCTP Résau IP, ARP, RIP, OSPF Accès résau physiqu Modèl TCP/IP Ethrnt, Tokn Ring Exmpls d mpilmnt d protocols Fig. 3.1: L modèl TCP/IP Introduction à la téléphoni Ls résaux d télécommunications ornt historiqumnt l srvic téléphoniqu grâc à ds protocols patrimoniaux tls qu l Résau Téléphoniqu Commuté (RTC) ou l Résau Numériqu à Intégration d Srvics (RNIS). L dévloppmnt d cs tchnologis a prmis d caractérisr un appl téléphoniqu. Un appl téléphoniqu st constitué d dux plans : un plan d contrôl qui gèr l'appl, c'st-à-dir son établissmnt t sa trminaison, t un plan usagr qui transport ls donnés d'un intrlocutur à l'autr. Ls opérations du plan d contrôl formnt la signalisation. La signalisation prmt d construir un circuit virtul ntr l'applant t l'applé. C circuit virtul véhicul nsuit ls donnés d l'appl. Au début d la téléphoni, ls dux plans n'étaint pas disjoint t la signalisation était mélangé aux

41 Téléphoni IP 19 donnés audio. On parl dans c cas d signalisation n band. Pour ds raisons pratiqus, cs dux plans sont désormais disjoints t la signalisation st décorrélé ds donnés d l'appl. On parl alors d signalisation hors band. La convrgnc ds résaux d télécommunications t ds résaux informatiqus a été l'occasion d voir apparaîtr ds protocols d signalisation fonctionnant sur ls résaux IP Protocols binairs d téléphoni IP Ls protocols binairs sont plus compacts t proch d l'ordinatur. Ls informations t ls opérations sont rprésntés sous un form binair, c'st-à-dir un succssion d 0 t d 1 facilmnt manipulabl par un machin. Ls protocols binairs sont ls prmirs à êtr apparus. Ils répondnt aux forts contraints historiqus n trm d puissanc d calcul t d'spac mémoir disponibl. Bin qu ls procssurs modrns prmttnt d s'n aranchir, ils rstnt prtinnts dans ds contxts d hauts prformancs, par xmpl lorsqu l nombr d'appls st important. Ls principaux protocols d téléphoni binairs sont H.323 [MMS00], Skyp [Sky] t IAX [SCG + 08] H.323 L protocol H.323 st un standard d l'uit-t, l group d travail dédié à la téléphoni au sin d l'union Intrnational ds Télécommunications. Il rgroup un nsmbl d protocols prmttant l déploimnt d'un systèm téléphoniqu au-dssus d'un résau IP. Chacun ds protocols qu'il rgroup, a un tâch spéciqu allant du contrôl d la communication à l'ncodag d la voix, ou d la vidéo n passant par l'échang d'autrs typs d donnés. L'utilisation d crtains d cs protocols sont optionnls, par xmpl cux traitant d la qualité d srvic, tandis qu d'autrs sont obligatoirs an d'avoir un systèm fonctionnl. L protocol H.323 st dédié à la téléphoni t n'or pas d possibilité simpl d'xtnsions n vu d supportr un grand variété d srvics d communications. D plus, sa mis n uvr st complx. L'utilisation d'un protocol binair nécssit n t d maintnir ds outils spéciqus pour l dévloppmnt t la mis au point du protocol t d ss xtnsions. Maintnir d tls outils st aussi complx qu d dévloppr ls clints t ls srvurs dénis par l protocol Skyp Skyp st l nom d'un logicil édité par la société Skyp Tchnologis. C logicil a donné son nom au protocol applicatif qu'il implémnt. L protocol Skyp st un protocol pair à pair. C'st-à-dir qu'il fonctionn d manièr fortmnt distribué : la présnc d srvurs administrés par la société st minim t la majur parti du résau fonctionn grâc aux utilisaturs ux-mêms. En t, l simpl fait d'xécutr l logicil, an d pouvoir êtr joint, transform l'ordinatur d l'utilisatur n plat-form téléphoniqu capabl d routr ds appls t d rlayr ds communications audio t vidéo. L protocol Skyp st un protocol frmé, il n'xist aucun spécication publiqu. D plus, l'uniqu implémntation disponibl st protégé par ds tchniqus prmttant d'obscurcir l cod binair du programm t ainsi limitr la rétro-analys du protocol. D fait, il st actullmnt impossibl à ds partis tircs non accrédités d'utilisr l résau Skyp. L'ajout d srvics par l'utilisatur ou un tirs qulconqu n'st donc pas possibl dans c contxt.

42 20 Srvics d téléphoni IP Intr-Astrisk Xchang Astrisk [Spb] st un commutatur téléphoniqu logicil. Il st capabl d gérr à la fois ds protocols d téléphoni patrimoniaux t ds protocols d téléphoni IP. Ctt doubl compétnc lui confèr égalmnt un fonctionnalité d passrll ntr diérnts résaux d téléphoni. En plus d protocols xistants, Astrisk propos son propr protocol d téléphoni, IAX. Il a été conçu an d fonctionnr simplmnt, y compris n présnc d traduction d'adrsss résaux (n anglais Ntwork Addrss Translation ou NAT), t d'utilisr au miux la band passant du résau. C'st pour cs raisons qu'il s'agit d'un protocol binair fonctionnant sur un uniqu port utilisé à la fois pour la signalisation t l transport du ux multimédia. C choix d concption limit l'xtnsibilité. L nombr d codc dénis st limité par la structur mêm du protocol. D plus, ls codc utilisabls pour un communication sont cux disponibls sur l'nsmbl ds n uds travrsés par la signalisation d'un appl. Enn, l'utilisation d'un port uniqu, d'un protocol uniqu pour la signalisation t l transport ds média, ainsi qu la présnc d'un srvur dans crtains cas pndant ls communications pos un problèm fac aux attaqus d déni d srvic t limit l passag à l'échll. IAX st un protocol binair d téléphoni supportant la voix t la vidéo. Il st cpndant dicilmnt xtnsibl t n'st pas ncor un standard. Il n'st donc pas adapté pour l dévloppmnt d srvics d communications t l transport d'un typ arbitrair d donnés Protocols txtuls d téléphoni IP Ls protocols txtuls sont plus prochs d'un rprésntation humain. Ls informations t ls opérations sont rprésntés par du txt clair t lisibl par un humain. Ainsi, ls protocols txtuls procurnt un grand souplss lors d lur mis au point. D plus, ils sont par natur baucoup plus facilmnt xtnsibls qu ls protocols binairs. En contrparti, ils nécssitnt plus d puissanc d calcul t d'spac mémoir. Ls protocols txtuls MSNP [MSN06], XMPP [SA04] t SIP [RSC + 02] ornt ds fonctionnalités d téléphoni IP Microsoft Notication Protocol L protocol MSNP, MicroSoft Notication Protocol, st l protocol utilisé dans Windows Liv Mssngr, ancinnmnt MSN Mssngr. Il s'agit initialmnt d'un protocol d mssagri instantané. Microsoft l'a fait évolur pour ajoutr ds fonctionnalités d convrsation audio t vidéo ainsi qu du partag d'applications. L protocol MSNP st un protocol frmé, il n'xist pas d spécication publiqu of- cill. Cpndant, il xist plusiurs implémntations aux sourcs ouvrts mais aucun n support l'un ds trois drnièrs vrsions du protocol. L'absnc d cod t d spécications à jour présnt un risqu d pérnnité pour un projt souhaitant utilisr c protocol. Il n'st donc pas un candidat adapté au dévloppmnt ds srvics d communications nvisagés Xtnsibl Mssaging and Prsnc Protocol L protocol XMPP, Xtnsibl Mssaging and Prsnc Protocol, st un protocol d mssagri instantané t d présnc, ancinnmnt nommé Jabbr avant sa normalisation qui a débuté n Il fonctionn sur un modèl clint/srvur mais d manièr décntralisé. En t, chaqu utilisatur d'un mêm domain, par xmpl inria.fr, utilis l mêm

43 Téléphoni IP 21 srvur, par xmpl jabbr.inria.fr. Ls communications ntr utilisaturs d domains diérnts sont assurés par ds échangs ntr lur srvur rspctif. Chaqu srvur n gèr ainsi qu ls communications liés à ss utilisaturs t il n'y a pas d srvur cntral utilisé par l'nsmbl ds utilisaturs, tout domain confondu. L protocol XMPP st par natur xtnsibl t utilis un rprésntation XML pour ss mssags. Cla pos un problèm pour l'échang d donnés binairs. L protocol XMPP utilis alors un ncodag n bas64 [Jos03] qui prmt l'échang d donnés binairs au prix d'un mssag particulièrmnt vrbux. Il xist un xtnsion, Jingl [XEP08], prmttant d réalisr ds convrsations audio, fondé sur XMPP. Cpndant ctt xtnsion n'st pas ncor un norm t il n'xist pas d'implémntation mttant n uvr la vidéo. L protocol XMPP présnt d nombrux avantags pour l dévloppmnt ds srvics d communication. Il st ouvrt t fait parti ds standards Intrnt d l'ietf. Il prmt l'échang d mssags ntr utilisaturs ainsi qu ds événmnts comm la présnc ds utilisaturs. Il sour cpndant d'un crtain immaturité dans l domain ds communications audio t vidéo, t plus généralmnt d l'échang d donnés binairs Sssion Initiation Protocol L protocol SIP, Sssion Initiation Protocol, st égalmnt un protocol ouvrt t standard. Il st déni par l'ietf sous la RFC 3261 [RSC + 02]. À l'instar d XMPP, il st xtnsibl t d nombruss autrs RFC n étndnt ls prérogativs. Il s'agit initialmnt d'un protocol d signalisation utilisé ssntillmnt pour la téléphoni IP. L protocol SIP nécssit plus d rssourcs matérills qu'un protocol binair. Cpndant, il support assz simplmnt l passag à l'échll. En t, il put fonctionnr n pair à pair, ntr dux clints, un fois la communication établi. L'établissmnt d'un communication put nécssitr un ou plusiurs srvurs an d fair aboutir l'appl. L ux d donnés binairs d la convrsation multimédia st nsuit transporté n tmps rél par l protocol RTP [SCFJ03] (Ral-tim Transport Protocol). Ctt décorrélation, ntr un protocol d signalisation t un protocol d transport n tmps rél ds donnés binairs st parfaitmnt adapté au bsoin ds communications multimédia n général t a fortiori d la téléphoni IP. Ls dux protocols fonctionnnt n symbios an d fournir à l'utilisatur l srvic d téléphoni IP. C découpag rspct la séparation d'un plan d contrôl gérant ls communications t d'un plan usagr transportant ls donnés. C'st l prmir standard txtul d signalisation a avoir été normalisé par l'ietf t l'itu. Il a ainsi été rtnu dans ls architcturs ds opératurs d télécommunications qui opèrnt n téléphoni lair traditionnll, cllulair ou ncor n voix sur IP. La plupart d'ntr ux déploint un architctur IMS, IP Multimdia Systm, fondé sur SIP n intégrant lurs systèms t srvics patrimoniaux. Ctt utilisation massiv par ds industrils a mis n évidnc ls lacuns du protocol. Ils xistnt désormais d nombruss xtnsions prmttant d'améliorr la qualité d srvic, la sécurité t ls fonctionnalités. L'xtnsion SIMPLE [SIM] prmt par xmpl d'intégrr ds fonctionnalités d mssagri instantané t d présnc. L protocol SIP st à c jour l protocol l plus abouti t adapté pour gérr ls communications dans lur divrsité ; il or, n plus d l'échang d mssags sans état à la HTTP, ds mécanisms pour ls sssions t ls événmnts. En s limitant à la signalisation, c protocol st indépndant du typ d donnés qui transitnt dans ls communications qu'il mt n uvr. Enn, l'utilisation conjoint du protocol RTP pour ls ux tmps rél binairs n fait un solution parfaitmnt adapté au bsoin d prformanc lié à c typ d'applications.

44 22 Srvics d téléphoni IP SIP n détail Ctt étud st fondé ssntillmnt sur l protocol SIP. Nous allons n détaillr ls princips d bas, puis l'architctur d'un résau SIP t son fonctionnmnt. Enn, nous abordrons qulqus xmpls d'xtnsions Princips d bas L protocol SIP dénit un protocol d signalisation. Nous parlrons par abus d langag d téléphoni SIP par la suit pour désignr un systèm d communications fondé sur l protocol SIP. L protocol SIP réutilis ls concpts introduits par ls protocols HTTP t SMTP [LCLL04]. Un rprésntation ASCII (Amrican Standard Cod for Information Intrchang) st utilisé pour ls mssags SIP qui sont donc lisibls dirctmnt par un humain. L protocol SIP st fondé sur l modèl d communications clint/srvur décntralisé. Ls mssags SIP sont donc d dux typs, diérnciés par la prmièr lign, soit ds rquêts, soit ds réponss. La prmièr lign d'un rquêt commnc par un méthod suivi d'un adrss Intrnt, URI (Uniform Rsourc Idntir) comm l'illustr la gur 3.2. L protocol SIP réutilis égalmnt l modèl ds cods d réponss HTTP tl qu l'rrur 404 Not found. Il étnd ls cods d réponss avc ds cods dédiés à la téléphoni tl qu 486 Busy hr. La gur 3.3 illustr un xmpl d répons. Un rquêt t ss réponss associés formnt un transaction. L mécanism ds n-têts ds protocols HTTP t SMTP a égalmnt été consrvé. Ls n-têts prmttnt d dénir ds coupls nom/valur prmttant d caractérisr l'appl. Parmi ls n-têts obligatoirs dans ls mssags SIP, on trouv notammnt ls n-têts To t From, élémnts hérités du protocol SMTP. À la suit ds n-têts s trouv la charg util, par xmpl un pag HTML dans l cas du protocol HTTP. La charg util utilisé avc l protocol SIP vari n fonction d l'utilisation. Dans l cas d'un appl téléphoniqu, l protocol SDP (Sssion Dscription Protocol) st communémnt utilisé an d décrir ls capacités d communications ds périphériqus, c'st-à-dir ls codc audio t vidéo supportés. L protocol SIP s limit à la signalisation t d nouvaux protocols, tls qu SDP, sont mis n uvr pour décrir ls typs d donnés. L'idntiant d lign téléphoniqu courammnt utilisé st un numéro, l numéro d téléphon. Si l'utilisation d'un numéro st particulièrmnt pratiqu pour ls commutaturs téléphoniqus patrimoniaux, il n'st jamais facil d'n mémorisr soi-mêm un quantité important. Enn l dévloppmnt ds trminaux d téléphoni, t plus particulièrmnt d lur intrfac Homm-machin, rnd l'utilisation d'un idntiant numériqu obsolèt. L protocol SIP rmplac ls idntiants numériqus par ds URI. Il réutilis ainsi un mécanism d'idnti- cation déjà largmnt déployé t éprouvé dans l Wb t l courrir élctroniqu. Un idnti- ant SIP a donc la mêm rprésntation qu'un adrss d courrir élctroniqu, par xmpl alic@inria.fr. Pour ds raisons d'intropérabilité avc ls systèms téléphoniqus xistants, il st égalmnt possibl d'utilisr ds URI d la form sip: @inria.fr Architctur Avant tout chos, ls utilisaturs d'un résau SIP doivnt s'nrgistrr auprès d'un srvur d'nrgistrmnt grâc à la méthod REGISTER. Ls utilisaturs informnt via ctt rquêt quls sont l'adrss IP t l port où ils puvnt êtr contactés. Si l port n'st pas xplicitmnt

45 Téléphoni IP 23 1 INVITE sip:bob@labri.fr SIP/2.0 2 Via: SIP/2.0/UDP alicpc.inria.fr;branch=z9hg4bk776asdhds 3 Max-Forwards: 70 4 To: Bob <sip:bob@labri.fr> 5 From: Alic <sip:alic@inria.fr>;tag= Call-ID: a84b4c @alicpc.inria.fr 7 CSq: INVITE 8 Contact: <sip:alic@alicpc.inria.fr> 9 Contnt-Typ: application/sdp 10 Contnt-Lngth: (Charg util SDP d Alic non rprésnté) Fig. 3.2: Exmpl d rquêt SIP 1 SIP/ OK 2 Via: SIP/2.0/UDP sip.labri.fr;branch=z9hg4bknashds8 3 Via: SIP/2.0/UDP sip.inria.fr;branch=z9hg4bk77f4c Via: SIP/2.0/UDP alicps.inria.fr;branch=z9hg4bk776asdhds 5 To: Bob <sip:bob@labri.fr>;tag=a6c85cf 6 From: Alic <sip:alic@inria.fr>;tag= Call-ID: a84b4c @alicpc.inria.fr 8 CSq: INVITE 9 Contact: <sip:bob@ > 10 Contnt-Typ: application/sdp 11 Contnt-Lngth: (Charg util SDP d Bob non rprésnté) Fig. 3.3: Exmpl d répons SIP indiqué, l port 5060 st utilisé par défaut. Par xmpl, dans l cas illustré par la gur 3.4, Alic s'nrgistr avc son ordinatur portabl sur l srvur d'nrgistrmnt du domain inria.fr. Bob fait d mêm avc son téléphon Wi t son ordinatur x auprès du srvur d'nrgistrmnt du domain labri.fr. Lorsqu'Alic souhait contactr Bob, ll nvoi un rquêt INVITE, tll qu cll d la gur 3.2, à son srvur mandatair à l'inria. Cluici transmt la rquêt au srvur mandatair du domain labri.fr, c'st-à-dir l srvur mandatair du dstinatair. Enn, l srvur mandatair du LaBRI transfèr un copi d la rquêt vrs chaqu téléphon nrgistré d Bob. Ils s mttnt à sonnr à la récption d la rquêt. Lorsqu Bob décroch avc son téléphon Wi, c drnir nvoi un répons tll qu'illustré par la gur 3.3. La répons pass rspctivmnt par ls srvurs mandatairs du LaBRI t d l'inria puis arriv sur l'ordinatur d'alic. L protocol SIP établit un sssion slon la méthod dit d la poigné d mains n trois tmps (thr-way handshak). Après un acquittmnt émis par Alic (méthod ACK), un communication st établi ntr l'ordinatur d'alic t l téléphon Wi d Bob. La méthod ACK st la sul méthod n'ayant pas d répons associé. Ctt méthod appartint à la transaction INVITE. À un momnt arbitrair, l'un ds dux raccroch mttant n à la convrsation. Il émt un rquêt BYE t la sssion audio s'arrêt. An d c prémunir contr ls panns d'équipmnts résaux, d srvurs ou d clints, l protocol SIP dénit ds alarms protocolairs. Cs alarms sont associés aux divrs nvois

46 24 Srvics d téléphoni IP Srvur mandatair inria.fr Srvur d nrgistrmnt inria.fr Srvur mandatair labri.fr Srvur d nrgistrmnt labri.fr Srvurs d applications labri.fr Intrnt alicpc.inria.fr sip:alic@inria.fr sip:bob@labri.fr sip:scrtary@labri.fr Fig. 3.4: Architctur d'un résau SIP d mssags. Ls transactions doivnt s trminr avant l'xpiration ds alarms. C'st-à-dir qu'un répons doit êtr rçu n un tmps borné. Lors d l'établissmnt d'un sssion, l'intrlocutur n décroch pas immédiatmnt. Son téléphon émt ds réponss provisoirs qui réinitialisnt ls alarms n attndant Extnsions Ls xtnsions ls plus connus sont clls qui ajoutnt ds fonctionnalités pour l'utilisatur comm la mssagri instantané [CRS + 02] (rquêt MESSAGE) ainsi qu clls qui gèrnt la présnc [Roa02, Ni04]. La présnc prmt d connaîtr l'état d ss contacts. Il st ainsi possibl d savoir si un corrspondant st conncté ou non avant d'applr. Il st nécssair pour cla d souscrir à l'état d chacun d ss contacts grâc à la méthod SUBSCRIBE. À chaqu changmnt d'état, ls utilisaturs publint lur nouvl état (par xmpl, libr, au téléphon ou occupé) grâc à un rquêt PUBLISH. Ctt rquêt st nvoyé au srvur d présnc qui noti alors chaqu souscriptur avc un rquêt NOTIFY. La dénition d cs quatr méthods dans l protocol SIP st génériqu t n précis pas la charg util ou la valur d crtains n-têts. Cs méthods fournissnt ainsi ds mécanisms d communications génériqus t réutilisabls. La mssagri instantané t la présnc, fondés sur cs mécanisms génériqus, sont dénis séparémnt. La méthod MESSAGE fournit un fonctionnalité similair à cll ds méthods GET t POST du protocol HTTP. La diérnc principal résid dans l fait qu l'échang d donnés à liu ntr dux intrlocuturs t non pas ntr un utilisatur t un srvur. Ls trois autrs méthods SIP, SUBSCRIBE, NOTIFY t PUBLISH fournissnt un mécanism génériqu d communications asynchrons fondé sur ls événmnts. En plus d la présnc qu nous vnons d voir, il st utilisé pour notir d l'accomplissmnt d'un transfrt d'appls, d mssags n attnt, ou d'un saisi n cours au clavir. C mécanism srt égalmnt à la signalisation prmttant d gérr ds conférncs. La téléphoni st un application multimédia gourmand n band passant malgré la mis n uvr d tchniqus d comprssion. Cci st particulièrmnt vrai n visiophoni où la convrsation inclus un ux vidéo. Un xtnsion d SIP prmt d'ctur d la résrvation d rssourcs an d garantir l bon fonctionnmnt d la communication lorsqu cll-ci sra

47 Srvics 25 établi. La résrvation d rssourcs consist à rfusr un connxion s'il n rst plus assz d band passant à un instant donné t à bloqur l'utilisation d band passant disponibl lors d l'initialisation d'un communication. C mécanism garantit ainsi qu pour touts sssions établis, l ux d donnés associé sra corrctmnt achminé ntr ls partis. Pour fair fac à l'augmntation ds xtnsions t ds fonctionnalités, il st nécssair qu ls clints SIP connaissnt ls caractéristiqus ds srvurs qu'ils utilisnt t ds clints avc lsquls ils communiqunt. Par xmpl, la dscription d'un ux n trm d typ d donnés st vital pour établir l'intropérabilité d dux intrlocuturs t doit prndr n compt ls diérnts codc possibls. La découvrt ds fonctionnalités st réalisé avc la méthod OPTIONS. L'xtnsibilité ayant été un critèr d concption du protocol SIP, ctt méthod a été introduit dès l début t fait parti d la spécication d bas. Il st important d rtnir qu'il n'y a pas d nouvll méthod SIP standardisé dpuis octobr L protocol SIP a désormais attint un suil n trm d'xprssivité pour la signalisation. Ls xtnsions s focalisnt désormais sur ds nouvlls chargs utils, ds nouvaux n-têts t ds nouvlls valurs pour ls diérnts paramètrs. Cs xtnsions ds chargs utils ont pour but d'intégrr d nouvaux périphériqus t d nouvlls fonctionnalités sur un résau SIP Srvics t srvurs d'applications An d fournir ls mêms fonctionnalités qu ls systèms d téléphoni patrimoniaux, il st possibl d mttr n plac ds srvurs d'applications SIP (Figur 3.4, à droit) sur lsquls ls utilisaturs puvnt activr ds fonctions comm un boît vocal ou un rdirction d'appls. L'utilisatur Bob put par xmpl congurr un rdirction vrs un scrétariat pour ls appls qu'il n put pas prndr. Il lui suivit d'indiqur l'uri sip:scrtay@labri.fr dans son srvic d rdirction. 3.2 Srvics La téléphoni SIP, avc ss nouvlls xtnsions, ouvr la voi à un profusion d nouvaux srvics. L dévloppmnt d cs srvics nécssit cpndant ds compétncs crtains sans lsqulls la abilité du systèm d téléphoni put êtr compromis Opportunité Ls plats-forms téléphoniqus sont historiqumnt frmés t propriétairs. Dans c contxt, l'ajout d nouvaux srvics st long t coûtux. Un fois l choix d'achat d'un commutatur téléphoniqu (PABX Privat Automatic Branch Xchang) réalisé, l clint st contraint d s'adrssr à son prstatair d srvic pour tout modication ou activation d srvics mêm basiqus. Dans l cas d srvics innovants comm cux dévloppés dans l cadr d'un Couplag Téléphoni Informatiqu (CTI) l clint doit bin souvnt s'adrssr au fabriquant du systèm. L fabriquant dévlopp alors un srvic ad hoc t prot d son monopol pour facturr au prix fort c dévloppmnt. L couplag téléphoni informatiqu rstait d fait, soit un concpt pour la plupart ds ntrpriss, soit un réalité coûtus résrvé aux grands ntrpriss ou aux ntrpriss spécialisés. L'apparition d'implémntations d systèm d téléphoni aux cods sourcs ouvrts rnforc la position ds utilisaturs. Tous ls programmurs puvnt désormais, moynnant ls

48 26 Srvics d téléphoni IP compétncs tchniqus nécssairs, ajoutr ds srvics à un systèm d téléphoni. La supprssion d la position d monopol ds fabriquants d PABX, accompagné d la simplication du dévloppmnt ds systèms d téléphoni, favoris l'innovation t l dévloppmnt ds srvics d téléphoni. Enn, l fait qu la téléphoni dvinn un application sur IP, au mêm titr qu l courrir élctroniqu ou l Wb, or un simplication pour ls intractions avc ls autrs applications. D plus l protocol SIP épous la structur t la philosophi ds autrs protocols txtuls sur IP. Par xmpl, l'utilisation ds URI SIP facilit l'intégration avc l courrir élctroniqu ; il st possibl d'nvoyr un courrir au dstinatair d'un appl n'ayant pas pu répondr. Un évntul mssag vocal put égalmnt êtr mis n pièc joint. La convrgnc ds résaux d télécommunications t ds résaux informatiqus or un opportunité historiqu pour l dévloppmnt d srvics d téléphoni. En t, ls srvics d téléphoni puvnt désormais aisémnt xploitr ls rssourcs d'un résau informatiqu tl qu ls srvurs d courrir élctroniqu ou ls bass d donnés. L procssus d dévloppmnt d systèms d téléphoni t ds srvics d téléphoni st désormais l mêm qu clui ds autrs systèms informatiqus. L dévloppmnt d srvics d téléphoni st donc simplié par rapport à cux dstinés aux PABX patrimoniaux. C dévloppmnt n'st pas pour autant simpl t ls dévloppurs doivnt possédr un larg domain d compétncs Dévloppurs La simplication du dévloppmnt ds srvics pour la téléphoni sur IP st un réalité. Toutfois, ls domains d compétncs nécssairs d la part d'un dévloppur rstnt importants. Il lui faut connaîtr ds domains aussi variés qu ls télécommunications, ls résaux informatiqus t la programmation distribué. L'utilisation d nombrux srvics, tls qu ds annuairs, ds bass d donnés, l Wb t l courrir élctroniqu, élargit ncor l champ ds compétncs nécssairs au dévloppmnt d srvics. Paradoxalmnt, l'utilisatur nal, qui n'a généralmnt pas cs compétncs, st motur dans l'xprssion du bsoin d srvics. Son objctif st d facilitr son quotidin. Dans ls faits, l'utilisatur nal doit passr par un tirs compétnt pour l dévloppmnt d ss srvics. En fait, il st intérssant d'élargir la bas ds dévloppurs n facilitant l dévloppmnt d srvics t n limitant l'xprtis nécssair. Toutfois, l'administration d'un systèm xécutant du cod dévloppé par ds tirs ou ds utilisaturs naux pos un crtain nombr d problèms, notammnt d sécurité. L'ouvrtur ds plats-forms d téléphoni n doit pas s fair au détrimnt d la sécurité du systèm Contraints An d présrvr la abilité ds systèms d téléphoni, y compris n présnc d srvics, il st important d bin concvoir ls srvics. Rosnbrg t coll. [RLS99] dénissnt un cahir ds chargs précisant où doivnt êtr déployés ls srvics dans l résau [WS00], qul st l cycl d vi ds programms, c'st-à-dir la prsistanc d l'état ds srvics, qulls doivnt êtr ls rstrictions d'accès aux rssourcs du résau t nn, qulls sont ls possibilités d'intrfacs ntr un srvur d'applications t la logiqu d'un application.

49 Srvics Emplacmnt ds srvics Ls srvics puvnt êtr déployés soit dans l résau, sur ds srvurs d'applications, soit sur ls trminaux. Slon l'option rtnu, ls possibilités d srvics dièrnt comm l mntionnnt Wu t Schulzrinn [WS00]. L Tablau 3.1 indiqu qulqus xmpls d srvics t l'mplacmnt où ils puvnt êtr déployés. Nous pouvons rmarqur dux points importants. D'un part, tous ls srvics utilisant ou manipulant l ux multimédia, à l'xcption du srvic d sonnri diérncié t du srvic d transfrt, nécssitnt d'êtr déployés sur un trminal ou sur un srvur capabl d gérr l média. D'autr part, ls srvics d routag puvnt êtr déployés sur un srvur dans l résau. On rtrouv dans l'mplacmnt ds srvics, la dichotomi ntr srvics d routag t srvics ntités qu nous avons vu à la sction 2.2. Ls srvics ntités nécssitnt la gstion du média. Typ d srvics Srvic d routag Srvics ntités Emplacmnt du srvic Srvic C ur d résau (Srvur) Trminal Srvur Srvur avc mandatair gstion du média Rdirction sur occupation oui oui oui Rdirction sur non répons oui oui oui Rdirction sur absnc non oui oui Anonymisation non oui oui Sonnri diérncié oui non non Appl n attnt oui non oui Transfrt oui non non Conférnc oui non oui Boît vocal oui non oui Tab. 3.1: Srvics possibls n fonction d lur mplacmnt D'autrs préoccupations doivnt êtr priss n compt lors d l'analys du tablau 3.1. Si à prmièr vu, l déploimnt d srvic sur ls trminaux smbl intérssant, ls administraturs ds systèms d'information n puvnt pas, pour ds raisons d sécurité, lur fair conanc. Il st n t facil pour un attaquant d connctr un trminal xécutant du cod malvillant. Ls trminaux n puvnt donc pas n général accédr à touts ls rssourcs du résau. Ls srvics tirant parti d'annuairs ou d'agndas partagés sont alors impossibls. D plus, ls trminaux ont par ssnc un connctivité volatil. Par xmpl, un srvic déployé sur l téléphon Wi d'un usagr n srt à rin si l téléphon st n dhors d la zon d couvrtur Wi. Enn, l déploimnt d srvics dans l résau présnt l'avantag d simplir lur gstion. Il n'st alors plus nécssair d gérr l'hétérogénéité ds trminaux t l comportmnt st plus prévisibl lorsqu l'utilisatur dispos d plusiurs trminaux (par xmpl, téléphon lair, téléphon GSM t ordinatur) pour gérr ss appls. Bin qu l résau soit l'mplacmnt idéal pour l déploimnt ds srvics d routag, un tl déploimnt put toutfois fragilisr l résau. An d résoudr c conit d'intérêts, l'architctur ds résaux SIP prévoit l déploimnt ds srvics sur ds srvurs dédiés, ls srvurs d'applications, comm c'st l cas notammnt dans ls architctur IMS. Ainsi, n cas d'arrêt d'un ou d plusiurs srvurs d'applications, l fonctionnmnt nominal du systèm d téléphoni st présrvé. La contrparti st un latnc supplémntair du aux échangs

50 28 Srvics d téléphoni IP résaux ntr l srvur mandatair d c ur t ls srvurs d'applications. Ctt latnc n pos pas d problèm n pratiqu car la duré prçu par l'usagr lors d l'établissmnt d'un appl n vari pas Invocation du programm t prsistanc d l'état Tous ls srvics n nécssitnt pas d'êtr invoqués à chaqu événmnt d signalisation, c'st-à-dir à chaqu mssag résau ou événmnt protocolair tl qu'un alarm (timr). Par xmpl, ls srvics d rdirction d'appls n'ont bsoin qu d la méthod INVITE pour s'activr. C typ d srvic st dit sans état (statlss). Pour un srvic d rdirction sur non répons, il st nécssair d'avoir un répons négativ ou aucun répons d la part d l'applé. Un fois la répons nvoyé à l'applant, l'xécution put s'arrêtr. On parl d srvic avc état associé à un transaction (transaction statful) car un état st maintnu durant l'nsmbl d la transaction INVITE. Il xist cpndant d nombrux autrs srvics qui utilisnt davantag d'événmnts d signalisation. Un srvic nrgistrant la duré ds appls à ds ns statistiqus utilis non sulmnt l'initialisation d l'appl avc la méthod INVITE, mais égalmnt l'acquittmnt t la trminaison avc, rspctivmnt, ls méthods ACK t BYE. Lorsqu'un état st maintnu durant l'nsmbl d l'appl, on parl d srvic avc état associé à un appl (call statful). L typ d srvic dévloppé a un impact sur l'utilisation mémoir, t donc sur l passag à l'échll d'un srvic. Il st donc important d minimisr l'état au strict nécssair Accès aux rssourcs Ls systèms d téléphoni patrimoniaux sont abls t l téléphon st désormais un commodité à laqull ls usagrs font conanc. Il n faut pas qu l passag à la téléphoni IP t l'ajout d srvics compromttnt la abilité du systèm. La compromission du systèm put n t conduir, d'un simpl intrruption d'un srvic d'un utilisatur, à l'arrêt complt t brutal d la plat-form d téléphoni, mpêchant d c fait tout communication. L'intégration ds fonctionnalités ntr ls diérnts applications disponibls sur l résau nécssit d'autorisr ls srvics à accédr à ds rssourcs jusqu là protégés. L'accès à cs rssourcs rnd l systèm propic aux attaqus t au vol d donnés. Ls srvics d téléphoni doivnt donc fair l'objt d'un validation avant lur déploimnt dans l systèm d'information Environnmnt d dévloppmnt L princip d'un srvic d téléphoni st d manipulr l protocol d signalisation sousjacnt, n l'occurrnc l protocol SIP. Cpndant, xposr l'nsmbl ds informations ds mssags SIP aux dévloppurs t lur prmttr ds modications arbitrairs, mpêch tout garanti quant au rspct du protocol SIP. Il convint donc d dénir l'nsmbl ds modications possibls prmttant d crér un maximum d nouvaux srvics, tout n présrvant la abilité du systèm. Ls srvics d téléphoni puvnt êtr plus ou moins génériqus. Crtains s'appliqunt à l'nsmbl d'un ntrpris ou d'un group dans l'ntrpris, tandis qu d'autrs n s'appliqunt qu'à un individu. Dans ls dux cas, il st intérssant d réutilisr du cod dévloppé dans d'autrs systèms d téléphoni. Il dvint alors possibl d déployr dans d'autrs ntrpriss ls diérnts srvics, indépndammnt du systèm téléphoniqu d clls-ci. La

51 Bilan 29 portabilité ds srvics st un avantag pour ls sociétés d srvics n ingéniri informatiqu dans l cas d srvics génériqus. Ells puvnt ainsi factorisr lur coût d dévloppmnt ntr plusiurs clints. La portabilité ds srvics st égalmnt un avantag pour l'usagr qui put ainsi déployr son srvic à son domicil, chz son opératur t à son travail. Il st important d fournir aux dévloppurs un nvironnmnt d dévloppmnt adapté. Clui-ci doit lur prmttr d s concntrr sur c qu doit fair un srvic, plutôt qu commnt il l fait. D plus, un nvironnmnt adapté doit facilitr, voir mêm automatisr, la réutilisation d l'xistant. 3.3 Bilan Après ds décnnis d séparation, ls résaux d télécommunications t ls résaux informatiqus ont maintnant convrgé. Ctt convrgnc a prmis la mutualisation ds résaux physiqus t donc un réduction ds coûts. Un autr t a été l dévloppmnt d protocols d téléphoni IP an d'assurr la continuité d srvic ntr ls résaux. La téléphoni IP n général, t l protocol SIP n particulir, or un nouvau paradigm aux communications sur ls résaux informatiqus au moins aussi révolutionnair qu ls protocols SMTP t HTTP n lur tmps. Un fois la plat-form d téléphoni fonctionnll, sa valur ajouté provint d l'ajout d srvics. La diculté d dévloppmnt d srvics dans ls systèms patrimoniaux d téléphoni st pourtant un frin important à l'apparition d srvics innovants. L'ouvrtur ds plats-forms d téléphoni a simplié c dévloppmnt. Il n'n dmur pas moins ncor complx t d nombrux dés doivnt êtr rlvés par ds dévloppurs aux compétncs multipls. An, d garantir la abilité du systèm, il st important d vérir ls srvics avant lur déploimnt dans l systèm. Toutfois, la abilité n doit pas êtr attint au détrimnt ds fonctionnalités fournis par l langag. Un compromis doit êtr trouvé. Nous proposons d mttr n uvr l'approch ds langags dédiés an d détrminr c compromis.

52 30 Srvics d téléphoni IP

53 Chapitr 4 Langags dédiés L'ingéniri logicill consist à concvoir t dévloppr ds programms informatiqus. D nos jours, ls programms dévloppés couvrnt un larg spctr d problèms. Ls problèms puvnt êtr rgroupés n diérnts domains. On put alors s'intérssr à la dénition d'un langag dédié (n anglais DSL pour Domain-Spcic Languag) pour la résolution ds problèms d'un domain particulir. Parmi ls domains ayant déjà fait l'objt d'un étud conduisant à la création d'un langag dédié, on trouv la nanc [vd97], ls systèms d'xploitation [LMB02, MRC + 00, Thi98], ls protocols résaux applicatifs [Bur08], ls bass d donnés [KT03], ls documnts structurés [MGB + 04, W3C02], ls imags [Kr82], la musiqu [Lan90], la chimi [Bn86], ls srvics Wb [ABBC99, BMS02, CM02], ou ncor la concption matérill [Ash02]. Enn, l'étud t l dévloppmnt ds langags n général, t ds langags dédiés n particulir, a donné liu à plusiurs langags dédiés tls qu BNF [Knu64], SDF [HHKR89], Lx [LS75], Yacc [Joh75]. C chapitr présnt succinctmnt plusiurs méthodologis t outils associés qui sont disponibls pour facilitr la création d langags dédiés [CM98, BPM04, BKVV08]. La prmièr étap d la concption d'un langag dédié nécssit d délimitr t d'analysr l domain auqul il st dédié. À la suit d l'analys d'un domain, il st nécssair d dénir ls objctifs du DSL. Cs objctifs puvnt êtr consignés dans un cahir ds chargs. Un langag st nsuit déni n rspctant ls contraints du domain t ls objctifs ds concpturs. La dénition d'un langag comprnd un syntax t un sémantiqu. Cs élémnts prmttnt d réalisr ds analyss sur ls programms écrits à l'aid du DSL an d'idntir ls programms valids. Après avoir été déni, l langag st implémnté. L'implémntation d'un DSL comport généralmnt un analysur, un compilatur ou un intrprèt t évntullmnt un nvironnmnt d'xécution. 4.1 Analys d domain L'évolution d'un programm n fonction ds nouvaux bsoins, d modications d l'nvironnmnt d'xécution ou d'améliorations conduit à d multipls vrsions. Pour limitr l coût d dévloppmnt global d cs vrsions, Parnas [Par76] propos d s'intérssr d'abord à un nsmbl d programms apparntés qu'il nomm famill d programms. Un nsmbl d programms form un famill lorsqu'il st plus util d'étudir ls programms d ct nsmbl n étudiant d'abord lurs propriétés communs puis n détrminant ls propriétés spéciqus d chaqu mmbr d la famill. 31

54 32 Langags dédiés L concpt d famill d programms a dpuis été rpris pour dénir un domain. L trm d'analys d domain a été introduit par Nighbors [Ni80] comm l'activité d'idntication ds objts t opérations d'un class d systèms similairs (un famill d programms) dans un domain particulir d problèms. La concption d'un langag dédié à un domain st guidé par l'idé qu la spécialisation d'un langag, pour manipulr ls objts t opérations d'un domain, prmttra d facilitr l dévloppmnt d nouvaux mmbrs d la famill associé à c domain. Czarncki t Eisnckr [CE00] précisnt la dénition d'un domain comm étant un sphèr d connaissancs. Ctt sphèr d connaissancs s'étnd jusqu'à maximisr la satisfaction ds bsoins ds intrvnants. Ell inclut l'nsmbl ds concpts t d la trminologi utilisés par ls xprts d ctt spécialité ainsi qu ls connaissancs nécssairs au dévloppmnt d systèms logicils dans ctt spécialité. Malgré ctt dénition plus précis, lorsqu l domain st vast, ls xprts l décomposnt n plusiurs sous-domains. Prito- Díaz [PD90] dénit un domain comm un résau dans ds structurs smi-hiérarchiqus. En bas d la hiérarchi, s trouvraint d ptits domains contnant ds primitivs comm ds langags assmblurs t ls opérations arithmétiqus, t n haut d la hiérarchi, ls domains plus largs t plus complxs. La complxité d'un domain st alors lié au nombr d sous domains nécssairs pour l dénir. L'étud d'un domain st la pirr angulair d la construction d'un DSL. D nombruss méthodologis ont été dévloppés pour caractérisr t modélisr ls domains tlls qu FODA (Fatur- Orintd Domain Analysis) [KCH + 90], FAST (Family-Orintd Abstractions, Spcication, and Translation) [Wi98, Wi96], DARE (Domain Analysis and Rus Environmnt) [FPDF98], DSSA (Domain- Spcic Softwar Architcturs) [Tra95] ou ODE (Ontology-basd Domain Enginring) [dafgd02] pour n'n donnr qu qulqus uns. Ds outils prmttnt d'assistr l'analyst d domains dans la formalisation d'un domain. Nous pouvons par xmpl citr DOMAIN [TTC95], DARE [FPDF98] ou FDL [vdk02]. L'analys d domain n'st pas résrvé à la concption d DSL, ll st égalmnt utilisé lors d la concption d ligns d produits. En t, bin qu'il s'agiss d nalités diérnts comm la concption d ligns d produits ou la concption d langags dédiés, ls approchs présntés partagnt l mêm princip général : lls sont basés sur ds informations provnant d'xprts t d'utilisaturs d'un domain. Cs informations sont triés n dux catégoris : d'un part, ls points communs ntr ls mmbrs d'un famill d programms dans un domain donné, t d'autr part ls variations ntr cs mmbrs. On parl d'analys d points communs Sourcs d'informations La dénition d'un domain commnc par un analys ds bsoins. Dans l cas d'un langag, il faut aussi qu ls concpturs du langag s'approprint la trminologi du domain étudié. Un analys précis ds bsoins prmt d'évitr l'écuil d la surconcption, qui consist à ajoutr ds fonctionnalités concptullmnt intérssants mais n présntant aucun utilité dans la pratiqu. L'appropriation du jargon d'un domain par ls concpturs du langag lur prmt d dénir ls concpts t la trminologi proprs au domain [Wil04]. Ls sourcs d'informations sont liés à ds échangs ntr ls xprts d'un domain t ls xprts langags. L procssus d dénition du domain st souvnt basé sur ds échangs n langu naturll sous form écrit ou oral. Il s'agit donc d'un procssus où l factur humain st important. La dénition d'un domain put êtr longu t comportr ds lacuns. La dénition d'un domain s fait n pratiqu conjointmnt avc la concption du langag lors d'un procssus itératif [Wi98, damc + 06]. C procssus prmt d validr l'analys d

55 Analys d domain 33 domain. En l'absnc d'un DSL, ds programms écrits à l'aid d langags généralists, sont mis n uvr pour résoudr ls problèms du domain. Ls programms ainsi produits constitunt un bas d connaissancs qui put êtr xploité. Cs programms sont ds mmbrs d la famill d programms qu cibl l futur DSL. L'étud d cs programms t lur comparaison prmttnt d'n dénir ls points communs t ls variations Points communs L'objctif d l'analys d domain consist ntr autr à dénir ls points communs d'un famill d programms. Wiss [Wi98] dénit ls points communs comm la list ds postulats qui sont vrais pour tous ls mmbrs d la famill. Parnas [Par76] propos un procssus d dévloppmnt fondé sur ds décisions abstraits. Il consist à concvoir d façon abstrait l'architctur d'un systèm par ranmnts succssifs. À chaqu étap, l systèm st un pu plus déni jusqu'à obtnir un systèm complt. Un systèm complt st fonctionnl t put donc êtr xécuté. Un nouvll vrsion du systèm abstrait st créé à chaqu nouvll altrnativ possibl lors d la concption. Lors d'un tl procssus d dévloppmnt, l'analys d points communs doit dénir l plus récnt ancêtr commun d la famill. L procssus d dévloppmnt proposé par Parnas st illustré à la gur 4.1. L plus récnt ancêtr commun dans l'illustration présnté st clui où l systèm st déni à 33% (troisièm n ud). Fig. 4.1: Dévloppmnt d famill d programms par décisions abstraits [Par76] (illustration adapté d [Rév01]) Ls n uds ls d ct ancêtr présntnt tous ds variations ntr ux, y compris ls fuills rprésntant ls mmbrs fonctionnls d la famill. Un fois ls points communs d'un famill d programms idntiés, l'analys d domain s'intérss aux variations qu présntnt ls mmbrs d ctt famill.

56 34 Langags dédiés Variations L'étud ds variations ds mmbrs d'un famill st d dux typs. Il faut d'un part idntir ls variations d fonctionnalités t d'autr part idntir ls paramètrs d variation. L'étud d cs variations dénit l'xprssivité du futur DSL Variations d fonctionnalités L'étud ds variations d fonctionnalités corrspond à l'étud ds fonctionnalités dans ls ligns d produits [vdk02]. Un diagramm graphiqu d fonctionnalités (Graphical Fatur Diagram) put êtr mis n uvr pour dénir ls diérnts fonctionnalités d'un lign d produits. Il st possibl d'appliqur ct outil pour caractérisr ls variations ntr ls mmbrs d'un famill d programm. La gur 4.2 illustr l'application d ct outil sur l cas d'un voitur [vdk02]. Un notation graphiqu prmt d'xprimr divrss possibilités : ls fonctionnalités optionnlls (rond vid), ls fonctionnalités à choix uniqu (triangl vid) t ls fonctionnalités à choix multipl (triangl plin). Il st possibl d'utilisr ds outils tls qu FaturIDE [LAMS05] fournissant du support aux utilisaturs pour réalisr c typ d diagramm. Car carbody pullstrailr Transmission Engin HorsPowr automatic manual lctric gasolin lowpowr mdiumpowr highpowr Fig. 4.2: Exmpl d rprésntation graphiqu pour ls fonctionnalités d'un voitur Figur 1: Fatur diagram for a simpl car La rprésntation b xprssd in a graphical graphiqu faturprésnt diagram (andl'avantag mor). Nxt, w d'êtr introduc facil in Sction t rapid 3 a fatur àdiagram lir par un humain. Ell algbra that allows th normalization of fatur diagrams. In addition, w introduc a notion of satisfaction thatfournit nabls us to unanswr support th following auxqustion: discussions givn a fatur ntrdiagram ls xprts and a list oflors usr rquirmnts, d la concption dos d'un DSL. An, thisd fatur pouvoir diagramcontrôlr contain softwar automatiqumnt configurations that satisfy lath validité usr rquirmnts? d modèls In thisplus way, acomplxs, fatur un diagram can b activly qurid and th initial invstmnts in its construction start to pay off. Implmntation rprésntation txtull équivalnt st utilisé comm l'illustr la gur 4.3. van Dursn issus ar addrssd in Sction 4. W show how fatur diagrams can b mappd to UML and Java classs. t Klint In [vdk02] Sction 5 w proposnt prform a cas ds study règls and dscrib d réécritur how th variability prmttant of xistingd commrcial normalisr, productd'étndr for t d contraindr documntation un gnration dscription can b modld fonctionnalités. using FDL. Conclusions Ils proposnt in Sction 6 complt d'appliqur th papr. cs règls an d générr un dscription UML (Unid Modling Languag) [UML] puis un implémntation abstrait2d'un Fatur systèm Diagrams n Java. Ils conclunt sur l'utilisation d la dscription d fonctionnalités pour2.1 dénir Graphical la grammair Notation for d'un Fatur DSL. Diagrams Un génératur pour c DSL pourrait alors produir du cod utilisant un instanc du systèm généré via la dscription UML. Figur 1 shows a fatur diagram for a simpl car inspird by [19, 5]. Th diagram stats that a car consists of a carbody, Transmission, Engin and HorsPowr. Ths four faturs ar mandatory as indicatd by th closd dot on top of ach fatur. Th last fatur of th car is pullstrailr. It is optional as indicatd by th opn dot. carbody and pullstrailr ar atomic faturs which cannot b furthr subdividd in othr faturs. In th squl, w will call faturs that ar dfind in trms of othr faturs composit faturs. W will us th convntion that nams of atomic faturs start with a lowr cas lttr and nams of composit faturs start with an uppr cas lttr. Not that atomic and composit faturs ar calld faturs, rspctivly, subconcpts in [5]. Th Transmission may b ithr automatic or manual. Th opn triangl joining th lins from

57 Dénition d'un cahir ds chargs 35 1 Car: all( carbody, Transmission, Engin, HorsPowr, pullstrailr? ) 2 Transmission: on-of( automatic, manual ) 3 Engin: mor-of( lctric, gasolin ) 4 HorsPowr: on-of(lowpowr, mdiumpowr, highpowr) Fig. 4.3: Exmpl d rprésntation txtull pour ls fonctionnalités d'un voitur Paramètrs d variation Ls variations d fonctionnalités corrspondnt soit à ds opérations qui puvnt êtr invoqués ou non par l dévloppur, soit à ds motifs d cod [GHJV95] qu l dévloppur mt n uvr. Dans ls dux cas, il st fréqunt qu'un parti vari n fonction du mmbr d la famill qu l dévloppur programm. Ctt parti variabl corrspond, soit à ds paramètrs ds opérations invoqués, soit à ds paramètrs d'un motif d cod. L'étud d cs paramètrs d variation st lié à la formalisation ds concpts t ds objts d'un domain. Dans l'xmpl présntant ls fonctionnalités d'un voitur, il st possibl d précisr, par xmpl, l nombr d rapports d la transmission, ou l'autonomi d'énrgi, c'stà-dir la capacité ds accumulaturs ou la taill du résrvoir slon l mod d'alimntation d la voitur, élctriqu ou ssnc. Il st important d bin caractérisr ls paramètrs d variation, notammnt lur typ t lur domain d valurs. Par xmpl, la taill d'un résrvoir put êtr déni par un ntir naturl dans un intrvall borné t êtr xprimé n litr ou n gallon. L drnir aspct ds paramètrs d variation st l'instant où lur valur st connu. On parl d tmps d liaison. Ls paramètrs d variation sont ainsi dénis plus ou moins tôt dans l cycl d vi d'un application : à la concption, au déploimnt ou à l'xécution. Plus la valur d'un paramètr st connu tard, plus un valur rroné aura un impact important car ll aura fait l'objt d moins d vérication t aura moins d chanc d'êtr détcté. Un valur rroné à l'xécution put, par xmpl, causr l'arrêt inopiné d'un application. L'analys d'un domain st un phas crucial pour la concption d'un DSL. C'st lors d ctt analys qu tous ls concpts t la trminologi d'un domain sont xplicités. Ils sront nsuit rpris lors d la concption du DSL. Il xist cpndant d'autrs facturs ayant un impact sur la concption d'un DSL. Cs autrs facturs puvnt êtr xprimés sous la form d'un cahir ds chargs qu doivnt rspctr ls concpturs du DSL. 4.2 Dénition d'un cahir ds chargs Lors d la concption d'un DSL, il st primordial d motivr la concption du DSL. Qul st l bsoin d ss futurs utilisaturs? Qulls sont ls dicultés du dévloppmnt logicil avc ls solutions actulls dans l domain considéré? L'utilisation d l'approch DSL put égalmnt comportr ds risqus. Il convint d ls connaîtr t d'n msurr l'impact. Pour répondr à cs qustions t évalur ls risqus, un approch possibl consist à dénir un cahir ds chargs pour la concption d'un DSL. C cahir ds chargs xprim ls objctifs qu doit attindr l DSL. La dénition d cs objctifs st propr à chaqu DSL. Ell doit prmttr d réalisr ls arbitrags qui auront liu lors du dévloppmnt du DSL. Ls objctifs sont d dux ordrs : d'un part ls objctifs rlatifs aux risqus d dévloppmnt

58 36 Langags dédiés t d'utilisation ds DSL, t d'autr part ls objctifs rlatifs aux gains induits par l'utilisation d'un DSL Risqus potntils L'approch ds DSL sour d problèms ou d risqus chroniqus : ls coûts initiaux, liés au dévloppmnt t au déploimnt du DSL, la maintnanc, lié à l'évolution du DSL, la communauté ds utilisaturs, t nn la prformanc ds programms Coûts initiaux L'analys d domain t l dévloppmnt d'un DSL sont consommaturs d rssourcs humains t d tmps. Il y a donc un coût nancir associé à la création d'un DSL. Toutfois, l'xpérinc montr qu l surcoût initial put êtr rapidmnt amorti. Dans l cas d l'utilisation d la méthod FAST [Wi98, Wi96], l coût d production d'un nouvau mmbr d la famill st réduit d'nviron quatr fois t l surcoût initial lié à l'analys du domain st amorti au troisièm mmbr d la famill dévloppé. Ctt étud s cantonn à l'analys d domain t n concrn pas l dévloppmnt d'un DSL. Toutfois d'autrs étuds tlls qu la comparaison réalisé par van Dursn [vd97] montr ls avantags à disposr d'un DSL pour accédr à un intrgicil. Hudak [Hud96] propos un approch prmttant d limitr l coût initial. Ctt approch st fondé sur ls langags dédiés nchâssés. L princip st d protr d l'infrastructur t ds outils d l'nvironnmnt d dévloppmnt d'un langag généralist. Un DSL a un cycl d vi similair aux autrs approchs n géni logicil. Un fois conçu, il doit êtr maintnu t évolur au gré ds bsoins qui n'ont pas été idntiés lors d l'analys d domain Maintnanc d'un DSL Si pour la concption initial, il paraît évidnt qu'un xprt du domain t un spécialist langag doivnt êtr impliqués, lur présnc durant la maintnanc d'un DSL t d ss outils (c.-à-d. éditur, déboguur, compilatur, intrprèt) n'st malhurusmnt pas souvnt planié. Ls compétncs nécssairs à la maintnanc d'un DSL doivnt êtr priss n compt au mêm titr qu ls autrs compétncs très spéciqus qui puvnt êtr nécssairs dans un ntrpris. La maintnanc d'un DSL st alors à un problèm d gstion ds rssourcs humains au sin d'un ntrpris. D plus, il st possibl d'xtrnalisr ls compétncs nécssairs t d fair appl à ds sociétés d srvic n ingéniri informatiqu, par xmpl. Il faut alors disposr ds documnts d travail utilisés t produits lors d l'analys d domain an d n pas avoir à supportr un scond fois l coût d l'analys d domain Utilisaturs Un autr obstacl signicatif à l'utilisation d'un DSL st lié à sa communauté d'utilisaturs. L'adoption d'un DSL par la plus larg communauté possibl st un factur décisif pour l succès d'un DSL. L'adoption d'un DSL dépnd principalmnt d dux points : ls solutions altrnativs xistants t la facilité d'apprntissag du nouvau langag. Dans l cas du dévloppmnt d srvics Wb, l langag PHP [LTM06] st apparu très tôt t st dvnu un standard d facto. Il possèd désormais un larg communauté d'utilisaturs

59 Dénition d'un cahir ds chargs 37 t d nombruss bibliothèqus d fonctions. Bin qu ds langags dédiés [ABBC99, BMS02, CM02] proposnt ds solutions plus sûrs t plus cacs pour l dévloppmnt d srvics Wb, lur utilisation rst ancdotiqu. Pour qu'un communauté s cré autour d'un langag, il faut qu clui-ci soit facil d'accès. Étant dédiés à un domain, ls DSL ont sur c point l'avantag d'êtr généralmnt plus ptits n trm d concpts. Un nouvl utilisatur a crts bsoin d'un crtain tmps d'adaptation t d'apprntissag mais il st rapidmnt productif [SKG + 07]. L'utilisation ds concpts t d la syntax d'un domain, dont ls utilisaturs sont déjà familirs, st égalmnt un avantag indéniabl. Enn, l'implication ds utilisaturs, dès l'analys d domain, st un factur détrminant pour l succès d'un DSL [Wil04] Prformancs Un ds critiqus dont ls DSL sont la cibl st qu ls programms ainsi produits sraint moins prformant qu lurs homologus écrits à l'aid d langags généralists. Dans la pratiqu, ls dux approchs utilisnt généralmnt l mêm intrgicil dédié au domain. D plus, l'analys d'abstractions haut nivau prmt aux compilaturs d systématisr ds optimisations indépndammnt du nivau d compétnc d'un dévloppur. Bin qu'il n'xist pas d'étud théoriqu sur l sujt, d nombruss xpérincs montrnt mpiriqumnt qu ls prformancs sont comparabls [MP99, Thi98, RM01, BRLM07, Bur08]. L'idé qu'un DSL st moins prformant provint d l'usag fréqunt d'un intrprèt pour ls programms du langag plutôt qu'un compilatur. En t, l dévloppmnt d'un intrprèt st plus simpl t plus rapid qu clui d'un compilatur pour un mêm langag. Toutfois, l surcoût d'un intrprèt à l'xécution put êtr supprimé n utilisant par xmpl l'approch Sprint [Thi98, CM98]. Malgré l coût initial t l risqu lié à la maintnanc, l'approch ds langags dédiés présnt ds avantags qui n font un solution attractiv. Nous allons à présnt voir ls principaux avantags d ctt approch Avantags scomptés L larg spctr d domains auqul l'approch a été appliqué, montr mpiriqumnt qu l'utilisation d'un DSL st un plus valu pour ls usagrs. Plusiurs facturs xpliqunt l'intérêt pour ls DSL. Tout d'abord, ils prmttnt un dévloppmnt plus simpl t plus rapid qu'un approch généralist pour résoudr ds problèms d'un domain. D plus, ils systématisnt la réutilisation d l'intrgicil sur lqul ils puvnt êtr fondés ainsi qu ls bonns pratiqus d concption d'un domain. Enn, grâc aux abstractions qu'ils fournissnt aux dévloppurs, ils rndnt ls programms dévloppés plus abls car vériabls automatiqumnt Programmation plus facil L'utilisation ds DSL, dans ds domains très variés, comm la nanc [vd97], la musiqu [Lan90], ls imags [Kr82] ou la concption d circuits élctroniqus [Ash02], induit qu ls utilisaturs n sont pas forcémnt ds programmurs informatiqus. Il faut donc qu l langag, s'adapt à lur xprtis. Pour cs utilisaturs, l'utilisation d l'outil informatiqu n'st qu'un moyn pour ctur plus facilmnt un tâch lié à lur profssion ; l'adoption d'un DSL n st donc facilité. Ls utilisaturs puvnt alors s concntrr sur lur métir

60 38 Langags dédiés t résoudr lurs problèms plus simplmnt. Par xmpl, grâc au DSL Eon [SKG + 07], ls programmurs d'applications mbarqués sont à mêm d dévloppr nviron quatr fois plus vit qu lurs homologus utilisant l langag C. L DSL Risla, dans l domain d la nanc, prmt d réduir la duré ds projts, d'nviron trois mois à au plus trois smains [vd97] Réutilisation systématiqu L'analys d domain st un prérquis à la concption d'un DSL t constitu un valur ajouté. Ell put êtr utilisé par ls futurs xprts du domain qu'll décrit ainsi qu par ls nouvaux utilisaturs. Cs dux typs d'intrvnants protnt ainsi d l'ort d concptualisation qui a été fait. Il lur st ainsi plus simpl t donc plus rapid d'acquérir un xprtis dans un domain donné. L'utilisation d'un DSL favoris intrinsèqumnt la réutilisation d cod. En t, la réutilisation d cod (par xmpl, intrgicils, bibliothèqus d fonctions) n'st plus à la charg du dévloppur mais d la rsponsabilité ds outils implémntant l DSL. La réutilisation st alors systématiqu t indépndant du nivau d'xprtis du dévloppur. Grâc aux abstractions fournis par un DSL, ls programms dévloppés sont généralmnt plus concis qu lurs homologus écrits avc ds langags généralists. D plus, ils appartinnnt à la mêm famill d programms. Il st donc plus aisé d dérivr un programm xistant n un nouvau mmbr d la famill. La réutilisation d cod st donc égalmnt facilité au sin d la famill d programms Fiabilité amélioré À caus d la généricité ds langags généralists, nombr d propriétés sont indécidabls. Ls DSL introduisnt ds abstractions t ds rstrictions qui rndnt décidabls ds propriétés spéciqus à un domain. Cs propriétés puvnt alors êtr vériés automatiqumnt par ds outils dédiés au langag. Il st ainsi possibl d détctr ds programms n rspctant pas ds contraints du domain. Par xmpl, l langag <BigWig> [BMS02] srt au dévloppmnt d sit Wb. Pour qu'un programm <BigWig> soit valid, il faut qu'il produis un pag HTML valid, c'st-à-dir rspctant un nchvêtrmnt corrct d baliss HTML. Ctt contraint st vérié par l compilatur. Ainsi suls ls srvics valids sont déployés sur l srvur Wb. Un tll garanti st impossibl n utilisant un langag généralist comm PHP [LTM06]. Enn, l'utilisation d'abstractions d haut nivau prmt au dévloppur d n pas avoir à s soucir ds détails d'implémntation. Par xmpl, l'utilisation d langags tls qu Bossa ou Dvil [LMB02, RM01], dédiés rspctivmnt à l'ordonnancmnt d procssus t au dévloppmnt d pilots d périphériqus, prmt d s'aranchir d dévloppmnts C particulièrmnt bas-nivau. D tls dévloppmnts sont ds sourcs d'rrurs non négligabls alors qu'ils ont un impact sur la stabilité du systèm car ils s'agit d programms s'xécutant avc ls privilègs du noyau dans l systèm d'xploitation. 4.3 Dénition d'un langag dédié Un fois l'analys d'un domain réalisé t ls objctifs du DSL spéciés dans un cahir ds chargs, ls xprts langags dénissnt, n coopération avc ls xprts du domain, l langag dédié. An d dénir un langag, un méthodologi éprouvé t faisant consnsus

61 Dénition d'un langag dédié 39 consist à l formalisr. Ctt formalisation s décompos n plusiurs phass : la dénition d la syntax du langag, la sémantiqu statiqu t la sémantiqu dynamiqu Syntax La syntax ds langags informatiqus st déni à l'aid d grammairs. Il xist plusiurs notations pour rprésntr un syntax. Ls plus répandus sont la BNF, Backus-Naur Form [Knu64], t SDF, Syntax Dnition Formalism [HHKR89]. L princip st d décrir la grammair sous la form d règls d dérivation xprimant ls variations du domain. La gur 4.4 illustr l'utilisation d la notation BNF sur un langag d manipulation d'ntirs t d chaîns d caractèrs qu nous nommrons Tiny. Un règl comport dux typs d'élémnts : ls trminaux t ls non-trminaux. Ls prmirs sont soit ds mots clés du langag (par xmpl, comput, lngth ou ls opératurs mathématiqus) soit ds paramètrs d variation tls qu ds chaîns d caractèrs, ds ntirs, ds idntiants. Ls trminaux sont détrminés par la trminologi idntié lors d l'analys d domain. Ls sconds élémnts, ls non-trminaux, référncnt ls règls d production d la grammair t dénissnt ls dérivations possibls par un combinaison d trminaux t d non-trminaux. program xprssion ::= comput xprssion ::= intgr string (xprssion) xprssion + xprssion xprssion - xprssion xprssion * xprssion xprssion / xprssion lngth xprssion substr xprssion xprssion xprssion Fig. 4.4: Notation BNF du langag Tiny Un programm st syntaxiqumnt valid s'il xist un arbr d dérivations 1 rspctant ls règls d la grammair. L programm d la gur 4.5 st ainsi un programm valid dont l résultat st la chaîn "Hllo". An d construir l'arbr décrivant un programm, ds outils génératifs tls qu Lx [LS75] t Yacc [Joh75] ou Stratgo/XT [BTKVV06], puvnt êtr utilisés pour produir un programm réalisant l'analys lxical t syntaxiqu d programms vis à vis d'un grammair. comput lngth substr 1 (2*3) "Hllo world!" Fig. 4.5: Exmpl d programm valid pour la grammair du langag Tiny 1 L'unicité d l'arbr st obtnu grâc à un grammair non ambiguë. On utilis pour cla ds règls d'associativité t d précédnc.

62 40 Langags dédiés Sémantiqu statiqu L'analys syntaxiqu n'st toutfois pas susant pour dir qu'un programm st valid. Si l'on considèr qu l'opératur + du langag Tiny n s'appliqu qu'à dux ntirs, l programm d la gur 4.6 st alors invalid bin qu syntaxiqumnt corrct. comput "Hllo " + 1 Fig. 4.6: Exmpl d programm invalid syntaxiqumnt corrct pour l langag Tiny Un aspct important ds langags st d formllmnt dénir l sns ds constructions proposés. An d dénir la sémantiqu d'un langag, diérnts notations puvnt êtr utilisés. On trouv, d la plus concrèt à la plus abstrait, la notation opérationnll [Plo81], dénotationnll [Sch86] t axiomatiqu [Hoa69]. La sémantiqu axiomatiqu n'st pas adapté pour dénir complètmnt la signication d'un programm contrairmnt aux sémantiqus opérationnll t dénotationnll. Ell put êtr utilisé pour l'analys d propriétés sur ds programms. La sémantiqu opérationnll présnt l'avantag d dénir d façon précis la signication d'un langag. Ell put êtr un étap ntr la dénition d'un sémantiqu dénotationnll t son implémntation [Sch86]. Nous nous intérssons dans la suit d c documnt uniqumnt à la sémantiqu opérationnll. Il sra ainsi plus rapid d produir un implémntation. La sémantiqu opérationnll st fondé sur un systèm d réécritur illustré par la gur 4.7. Lorsqu un motif pattrn, rprésntant un construction syntaxiqu d'un langag, st rncontré lors du parcours d l'arbr syntaxiqu, ls propositions conditions sont évalués n considérant l'nvironnmnt nv. Si touts ls propositions sont valids, alors l'nvironnmnt nv st produit. conditions nv pattrn nv Fig. 4.7: Règl d réécritur n sémantiqu opérationnll Si l'on considèr la sémantiqu statiqu d l'opératur + dans l langag Tiny, la règl, Figur 4.8, prmt d dénir qu l'opératur + n fonctionn qu'avc ds ntirs, dénotés par l typ Intgr. Ctt règl indiqu donc qu l'xprssion rprésnté par l'opératur st d typ ntir si t sulmnt si ls dux xprssions utilisés avc l'opératur sont d typ ntir. Ctt règl n put êtr satisfait si l'un ds xprssions st un chaîn d caractèrs t l programm d la gur 4.6 st ainsi rjté avant qu'il n soit xécuté. Nous vnons d présntr la vérication d typs à l'aid d'un sémantiqu statiqu. Il st égalmnt possibl d dénir d'autrs sémantiqus statiqus prmttant d'analysr d'autrs propriétés ds programms. Lors d l'analys d domain, il st important d dénir qulls sont ls propriétés importants, voir critiqus, du domain. En t, ls propriétés rtnus ont un impact sur la structur du DSL an qu lur analys conduis à un résultat décidabl.

63 Implémntation 41 xprssion 1 Intgr xprssion 2 Intgr xprssion 1 +xprssion 2 Intgr Fig. 4.8: Règl d typag pour l'opératur + n Tiny Sémantiqu dynamiqu Nous vnons d voir commnt formllmnt dénir l sns statiqu ds constructions an d validr un programm par rapport à crtains propriétés comm l typag. Un programm a vocation à êtr xécuté. Il st donc important d dénir égalmnt son comportmnt à l'xécution. L comportmnt global d'un programm put êtr déni n fonction d chacun ds constructions du langag. Enn, l comportmnt d chaqu construction put êtr déni d manièr plus ou moins détaillé. On put par xmpl xplicitr l'ordr d'évaluation ds paramètrs d'un fonction. On parl alors d sémantiqu à ptits pas par opposition à un sémantiqu à grands pas où l'évaluation ds paramètrs st atomiqu. La sémantiqu opérationnll dénit ls opérations réalisés par un construction d'un langag. Dans l langag Tiny, l'opératur + put ainsi êtr déni comm produisant l'addition d cs dux opérands, valu 1 t valu 2. La gur 4.9 illustr la sémantiqu dynamiqu d l'addition d dux ntirs à l'aid d'un sémantiqu à grands pas. valu 1 v 1 valu 2 v 2 valu := v 1 + v 2 valu 1 +valu 2 valu Fig. 4.9: Règl pour l'opératur + n Tiny L'avantag d formalisr la sémantiqu opérationnll résid dans l fait qu l dévloppmnt d'un intrprèt st alors dirct. D plus, l'ort consnti à produir un sémantiqu indépndant d'un tchnologi st égalmnt récompnsé lorsqu'un nouvll implémntation du langag doit êtr réalisé dans un nouvl nvironnmnt logicil. 4.4 Implémntation La drnièr étap d concption d'un DSL st son implémntation. Plusiurs systèms ont été proposés pour facilitr la tâch ds dévloppurs. Ils rposnt généralmnt sur la transformation d programms. C'st notammnt l cas ds approchs DMS (Dsign Maintnanc Systm) [BPM04], Stratgo/XT [BKVV08] ou Sprint [CM98]. Ells dièrnt cpndant dans lur fonctionnmnt. Ls dux prmièrs utilisnt ds règls d réécritur xprimés par l dévloppur du DSL. La méthodologi Sprint propos quant à ll d dévloppr un intrprèt fondé sur un machin abstrait. L'utilisation d'un intrprèt st plus xibl car plus simpl à dévloppr t à maintnir. Cpndant, l'utilisation d'un compilatur st souvnt plus

64 42 Langags dédiés prformant. Pour orir un approch à la fois xibl t prformant, la méthodologi Sprint utilis l'évaluation partill an d spécialisr l'intrprèt pour un programm donné, orant ainsi à la fois la xibilité d'un intrprèt t ls prformancs d'un compilatur [Thi98]. Nous avons vu, lors d l'analys d domain, qu cll-ci utilis ds systèms xistants ou conduit à la dénition d'un nouvau systèm tl qu décrit par ls points communs t ls variations idntiés. L'analys d domain spéci un couch d'abstraction [Con04]. Cll-ci put êtr implémnté, slon la complxité du domain, sous la form d'un ou plusiurs bibliothèqus d fonctions, d'un intrgicil ou d'un machin virtull. Ls outils d'un langag dédié n'ont alors plus qu'à transposr ls constructions du langag vrs ls abstractions fournis Couch d'abstraction Un couch d'abstraction prmt d s'aranchir ds détails ds tchnologis sous-jacnts. Ainsi, ll masqu aux dévloppurs qui l'utilisnt ls préoccupations liés au résau ou à un protocol résau, par xmpl. Slon l domain d'un systèm informatiqu auqul un DSL st dédié, ctt couch st plus ou moins important t plus ou moins complx. Ainsi dans l langag Dvil [Rév01], la couch d'abstraction sous-jacnt st quasi-inxistant puisqu clui-ci srt au dévloppmnt d pilots d périphériqus t la majur parti d la couch bass ds pilots st généré à partir d la spécication Dvil. À l'opposé, l langag Visu- Com [Lat07], utilisé pour l routag d'appls téléphoniqus, rpos sur un srvur d'applications d téléphoni IP. C srvur d'applications st lui-mêm fondé sur un pil protocolair SIP. Consl [Con04] présnt un méthodologi pour passr d'un famill d programm à un bibliothèqu d fonctions puis d'un bibliothèqu à un machin abstrait. Ls outils prmttant l'xécution ds programms écrits à l'aid d'un DSL n'ont alors plus qu'à l transformr n un programm écrit avc un langag généralist. L programm ainsi généré consist n un succssion d'appls aux primitivs qu la machin abstrait fournit. L'analys d domain a un rôl crucial dans ls opérations qu fournit la machin abstrait. Tout rrur lors d l'analys d domain put avoir un impact négatif sur la machin abstrait, la rndant évntullmnt inutilisabl. An d'évitr ct écuil, il st important d réalisr l'analys d domain d façon itérativ. Un bonn analys d domain conduira alors à un machin abstrait orant ds abstractions idéals pour résoudr ls problèms du domain Outils associés Un langag informatiqu présnt pu d'intérêt s'il n'st pas associé à ds outils. Cs outils puvnt êtr d natur diérnt : éditur, analysur, visionnur, compilatur ou intrprèt. Crtains d cs outils puvnt êtr dévloppés pour tous ls typs d DSL (par xmpl, éditurs) tandis qu d'autrs comm ls compilaturs t ls intrprèts sont résrvés aux DSL xécutabls. Dans l contxt du dévloppmnt d srvics d communications, nous nous limitons ici à la dscription ds approchs prmttant d'xécutr ds srvics : l'intrprétation t la compilation Intrprétation L'intrprétation st l'implémntation la plus simpl d'un langag. L dévloppmnt d'un intrprèt put êtr aisémnt réalisé un fois la sémantiqu dynamiqu déni. D plus, tstr un intrprèt st facilité par l fait qu'il produit un résultat immédiat lors du traitmnt d'un programm.

65 Bilan 43 L'architctur d'un intrprèt put rndr ncor plus xibl ctt approch. Par xmpl, l'utilisation d monads [Hud98, ADM05] prmt d modularisr l dévloppmnt d l'intrprèt, favorisant ainsi ls modications t l'ajout d constructions dans l langag a postriori améliorant ainsi la maintnabilité. La souplss d dévloppmnt d'un intrprèt facilit donc la mis au point d'un langag. Ctt souplss st particulièrmnt intérssant lors du dévloppmnt d'un DSL. L dévloppmnt itératif d'un DSL impliqu n t ds changmnts dans la syntax ou la sémantiqu. Cs changmnts sont validés n ls réprcutant dans l'intrprèt. L'inconvénint majur d ctt approch st l surcoût d l'intrprétation. An d'évitr c surcoût structurl, il st nécssair d'utilisr un approch par compilation Compilation Un compilatur transform un programm d'un langag haut nivau vrs un langag présntant ds abstractions moins richs. Par xmpl, lors d la compilation d'un programm écrit n C vrs du cod machin, l compilatur réécrit l programm avc ds opérations disponibls sur un procssur particulir. D manièr similair, un compilatur Java produit du cod binair pour un machin virtull Java à partir d cod sourc. Dans l cas ds DSL, l compilatur put transformr un programm écrit à l'aid d'un DSL n un programm équivalnt dans un langag généralist. C programm généralist put alors utilisr ls opérations fournis par la couch d'abstraction précédmmnt décrit à la sction La complxité lié aux diérncs structurlls ntr un programm écrit dans un DSL, t son programm équivalnt écrit dans un langag généralist, st ainsi réduit. La réduction du pas d compilation, grâc à l'utilisation d'un couch d'abstraction, prmt d facilitr l dévloppmnt d'un compilatur pour un DSL. Ls programms générés par l compilatur sont alors aussi prformants qu lur équivalnt écrit à la main, sans l DSL, t utilisant la mêm couch d'abstraction. 4.5 Bilan L procssus d dévloppmnt d'un DSL, Figur 4.10, st un procssus itératif qui comprnd un analys d domain, la dénition du langag t son implémntation. Fig. 4.10: Procssus d dévloppmnt d'un DSL Pour limitr l coût du dévloppmnt logicil sur l long trm, il st possibl d concvoir un DSL lorsqu'un famill d programms doit êtr dévloppé. L DSL facilitra l dévloppmnt d mmbrs d la famill, systématisra la réutilisation d cod t améliorra la abilité ds systèms sur lsquls ls programms s'xécutront. L succès d'un DSL

66 44 Langags dédiés dépnd cpndant d'un bonn analys d domain. D'un point d vu architctur logicill, ctt analys prmt d'xprimr ls élémnts pour dévloppr un couch d'abstraction (non rprésnté sur la gur) idéal t adapté pour résoudr ls problèms du domain considéré. D'un point d vu langag d programmation, ls concpts t propriétés du domain prmttnt d concvoir ds éditurs t d dénir ls analyss à réalisr sur ls programms écrits dans un DSL. Ls pratiqus proprs au domain ainsi qu ls points communs, ls variations t ls paramètrs prmttnt quant à ux d dénir un syntax t un sémantiqu. Ls langags dédiés introduisnt ds constructions syntaxiqus pour accédr à la couch d'abstraction. La formalisation d la sémantiqu du langag prmt quant à ll d dénir sans ambiguïté la signication ds constructions du langag. Ds propriétés, parfois critiqus, du domains sont alors prouvés sur ls programms grâc aux abstractions t à lur sémantiqu. Cs propriétés sont généralmnt indécidabls si un langag généralist st utilisé. D plus, cs analyss prmttnt d'automatisr ds optimisations dans l cod généré indépndammnt d l'xprtis du dévloppur. Divrss analyss pouvant êtr réalisés statiqumnt sur ls programms avant lur xécution, ls programms dévloppés avc un approch DSL sont plus abls qu lur homologus écrits à la main. Il st égalmnt possibl d réalisr systématiqumnt ds vérications dynamiqus dans l cod généré lorsqu ls rrurs provinnnt d donnés qui n sront connus qu'à l'xécution.

67 Chapitr 5 Solutions xistants L protocol SIP présnt l'avantag d'êtr un standard ouvrt pour réalisr ds communications sur un résau IP. Il s concntr sur la signalisation n prmttant d'émttr ds mssags, d souscrir t rcvoir ds événmnts t d'établir ds sssions. Il délègu au protocol RTP l transport ds ux multimédia. SIP st un protocol txtul facilmnt xtnsibl. D nombruss implémntations pour l support protocolair d SIP sont disponibls. Dans c chapitr, nous présntons ls diérnts solutions xistants pour l dévloppmnt d srvics d téléphoni IP fondés sur SIP. Nous étudions d'un part ls approchs fondés sur ds langags généralists, t d'autr part ls approchs fondés sur ds langags dédiés. Lorsqu cla sra prtinnt, nous illustrrons ls approchs présntés par un srvic d rdirction sur non répons. C srvic consist à rdirigr ls appls n'ayant pas abouti au propriétair du srvic vrs un scrétair. Nous considérons l'utilisatur sip:boss@xampl.com comm l propriétair du srvic. S'il n répond pas ou rfus ls appls qui lui sont adrssés, ss appls sont rdirigés vrs sa scrétair. Sa scrétair st idntié sur l résau SIP par l'uri sip:scrtary@xampl.com. 5.1 Langags généralists Ls prmièrs méthods d dévloppmnt qu nous allons voir consistnt à utilisr un bibliothèqu d fonctions ou un intrgicil fondé sur SIP. Cs bibliothèqus t intrgicils sont écrits dans diérnts langags d programmation généralists t fournissnt ds nivaux d'abstraction variabls Supports protocolairs L'apparition d'un nouvau protocol impliqu l dévloppmnt d cod fournissant du support protocolair, on parl communémnt d pils d protocol. L'objctif d'un pil st d réalisr l'analys t la construction ds mssags du protocol tlls qu dénis dans l standard. Un pil protocolair véri égalmnt crtains propriétés d cohérnc ds mssags. Il st fréqunt qu l nivau d'abstraction fourni rst rlativmnt bas. Ls dévloppurs ajoutnt alors un surcouch logicill prmttant d disposr d fonctions plus abstraits. Ctt surcouch, d plus haut nivau d'abstraction, trait automatiqumnt crtains opérations sur ls mssags comm la construction d'un répons typ pour un rquêt donné. Il xist d fait un variété d supports protocolairs orant divrs nivaux d'abstraction t mod- 45

68 46 Solutions xistants èls d programmation. Nous pouvons ainsi catégorisr ls pils SIP n fonction du paradigm d programmation ort. D'un côté, ls pils osip [Moi01], XoSIP [Moi03], PJSIP [Pri] t soa-sip [Nok] sont dévloppés à l'aid du langag C t ornt donc un paradigm procédural. D'un autr côté, ls pils JAIN SIP [JSR06], dissipat [Big], rsiprocat [rs] ou OpnSip- Stack [Opb] sont dévloppés à l'aid d langags orinté objts, Java t C++ n l'occurnc, t ornt donc un paradigm orinté objts Supports protocolairs procéduraux La pil osip [Moi01] fournit un intrfac d programmation (n anglais API pour Application Programming Intrfac) prmttant d manipulr ls mssags SIP n langag C. L dévloppmnt d tous ls typs d n uds SIP, d'un clint à un srvur mandatair n passant par un srvur d'nrgistrmnt, st possibl avc la pil osip. La pil XoSIP [Moi03] élèv ls abstractions fournis par la pil osip, sur laqull ll rpos, pour simplir l dévloppmnt d clints SIP. Ell fournit pour cla du support pour ds tâchs spéciqus aux clints SIP. Parmi ls opérations qui sont facilités, on trouv par xmpl l'nrgistrmnt sécurisé auprès d'un srvur d'nrgistrmnt, ou l maintin à jour d l'nrgistrmnt. L'utilisation d'un API n langag C prmt d'écrir ds programms cacs mais rquirt baucoup d compétncs t d riguur d la part du dévloppur. Par xmpl, il doit gérr ls allocations t ls libérations d mémoir rlativs à chaqu élémnt d'un mssag SIP. Il s'agit d'un aspct critiqu pour du cod dstiné à s'xécutr sur un srvur durant d longus périods inintrrompus. Dans c contxt qui rquirt un important xprtis, il st impossibl d garantir la validité ds programms fondés sur un API C t a fortiori l rspct ds contraints du protocol SIP. Par xmpl, il n'st pas possibl d garantir qu'un répons st rtourné à l'émttur d'un rquêt. Il s'agit là d'un lacun structurll propr aux langags généralists Supports protocolairs orintés objts L'API JAIN SIP [DRM04, JSR06], Java Advancd Intllignt Ntwork SIP, prmt aux dévloppurs Java d manipulr ds mssags SIP à l'aid d'un modèl à événmnts. L'architctur logicill, ntr un application t un pil implémntant l'api JAIN SIP, rspct l motif d cod d'un écoutur (listnr pattrn). Un application implémnt un intrfac d l'api. Chaqu méthod d ctt intrfac srt d point d rappl à un pil. L'application souscrit auprès d'un pil an d'êtr notié à chaqu événmnt protocolair. L cod utilisatur d'un application st ainsi invoqué, par xmpl, à la récption d mssags résaux ou à l'xpiration d'alarms protocolairs. L'API JAIN SIP 1.2 st constitué d 102 classs Java, totalisant plus d 500 méthods auxqulls il faut ajoutr crtains classs t méthods spéciqus à un implémntation. Par aillurs, l'implémntation d référnc comport plus d 300 classs totalisant près d méthods. Bin qu la programmation orinté objt facilit l dévloppmnt par rapport à un pil C, son usag n'n dmur pas moins résrvé à un public avrti. L'utilisation d cs pils protocolairs oblig ls dévloppurs à avoir un connaissanc parfait du protocol SIP. D plus, ils ont accès à l'intégralité du mssag sans limitation sur ls opérations possibls. Il lur st ainsi possibl d modir l mssag, d'ajoutr ds n-têts ou d'n supprimr. Si cs opérations sont nécssairs, lur utilisation doit êtr ncadré car lls puvnt compromttr la validité du mssag. Un mssag invalid put corrompr un plat-

69 Langags généralists 47 form d communications conduisant au miux à un xécution dégradé d la plat-form ou au pir à son arrêt inopiné. C problèm d vérication ds programms st inhérnt à touts pils protocolairs car lls sont fondés sur ds langags généralists. Ells doivnt orir un larg panl d fonctionnalités aux dévloppurs mais cla s fait au détrimnt d la abilité d l'application ainsi dévloppé. La abilité rpos alors sur l'xprtis t la binvillanc du dévloppur Intrgicils Ls pils protocolairs fournissnt un srvic d bas pour l support d'un protocol. L protocol SIP st utilisé par un nombr limité d typ d'ntités utilisant ds fonctionnalités spéciqus. On trouv dans un résau SIP, outr ls clints, ds srvurs d'nrgistrmnt, ds srvurs mandatairs, ds srvurs d rdirction t ds srvurs d'applications. Ls bsoins d cs diérnts typs d'ntités varint. Dans un souci d simplication du dévloppmnt, l nivau d'abstraction fourni par l support protocolair a été élvé pour facilitr l dévloppmnt d logiqus spéciqus à un ntité SIP. Ls intrgicils répondnt à c bsoin n fournissant un nvironnmnt d dévloppmnt contrôlé pour l dévloppmnt d srvurs d'applications. Nous allons voir dux paradigms rposant sur l'api JAIN SIP pour l dévloppmnt d srvurs d'applications SIP Srvlts L protocol SIP partag la mêm structur d mssags qu l protocol HTTP. À l'instar ds srvlts HTTP [Micf], l paradigm d programmation ds srvlts SIP [JSR03] associ un méthod Java à chaqu typ d mssags SIP. Nous illustrons la tchnologi ds SIP srvlts à l'aid d l'xmpl introduit n têt d chapitr t qui réalis un rdirction d'appls sur non-répons (Figur 5.1, pag suivant). Après ls méthods prmttant d gérr l srvic par invrsion d contrôl (ligns 6 à 13), nous trouvons la méthod doinvit pour la gstion ds nouvaux appls. Ls appls sont marqués comm nécssitant un rdirction n cas d'rrur (lign 19), puis la méthod st rlayé normalmnt (lign 20). Si l'appl st rjté, la méthod doerrorrspons st invoqué. Si l'appl était marqué (lign 31), un rdirction a liu (ligns 32 à 40) t l marquur st supprimé (lign 41). Par défaut, la répons st rlayé normalmnt (ligns 43 t 47). D manièr général, à la récption d'un mssag SIP, la méthod Java corrspondant st invoqué. La corrspondanc s fait sur la méthod pour un rquêt (par xmpl, méthod SIP INVITE t méthod Java doinvit lign 16) ou sur l cod d rtour pour un répons (par xmpl, cod d'rrur t méthod Java doerrorrspons lign 27). L'API ds SIP Srvlts or ds fonctions plus abstraits qu clls fournis par l'api JAIN SIP. Il st ainsi possibl d dirctmnt manipulr t congurr un objt mandatair, émttant t rlayant ds mssags SIP (ligns 35, 36 t 40). Enn, il st possibl d'instancir ds objts d typ SipApplicationSssion prmttant d crér ds sssions SIP. Ils puvnt êtr utilisés pour manipulr la signalisation. L modèl d programmation d SIP srvlts st proch du protocol SIP. À chaqu mssag SIP st associé un méthod Java. Il st adapté au dévloppmnt d prototyps car il propos un modèl simpl dont la mis n uvr st rapid. Comm l'illustr la gur 5.1, un srvic n SIP srvlts présnt d nombrux détails d'implémntation comm ls appls à supr (ligns 7, 12 t 20) qui n sont pas spéciqus

70 48 Solutions xistants 1 packag fr.inria; 2 3 public class RdirToSc xtnds SipSrvlt { 4 5 /** This is calld by th containr whn starting up th srvic. */ 6 public void init() throws SrvltExcption { 7 supr.init(); 8 } 9 10 /** This is calld by th containr whn shutting down th srvic. */ 11 public void dstroy() { 12 supr.dstroy(); 13 } /** This is calld by th containr whn an INVITE mssag arrivs. */ 16 protctd void doinvit(sipsrvltrqust rqust) 17 throws SrvltExcption, IOExcption { rqust.gtsssion().stattribut("rdir", Boolan.TRUE); 20 supr.doinvit(rqust); 21 } /** 24 * This is calld by th containr whn an rror is rcivd 25 * rgarding a snt mssag, including timouts. 26 */ 27 protctd void doerrorrspons(sipsrvltrspons rspons) 28 throws SrvltExcption, IOExcption { SipSssion sssion = rspons.gtsssion(); 31 if((boolan)sssion.gtattribut("rdir") { 32 SrvltContxt sc = gtsrvltcontxt(); 33 SipFactory factory = 34 (SipFactory)sc.gtAttribut("javax.srvlt.sip.SipFactory"); 35 Proxy p = rspons.gtproxy(tru); 36 p.stsuprvisd(tru); try { 39 SipURI sc = factory.cratsipuri("scrtary", "xampl.com"); 40 p.proxyto(sc); 41 sssion.stattribut("rdir", Boolan.FALSE); 42 } catch(excption ) { 43 supr.doerrorrspons(rspons); 44 } 45 } 46 ls { 47 supr.doerrorrspons(rspons); 48 } 49 } 50 } Fig. 5.1: Rdirction d'appls n SIP srvlt

71 Langags dédiés 49 à la logiqu du srvic mais prmttnt l'intégration du srvic dans l'intrgicil ds SIP srvlts. L dévloppur doit d plus gérr xplicitmnt l'état pour savoir si la rdirction vrs la scrétair a déjà u liu ou pas (ligns 19, 30, 31 t 41). L'adrss d la scrétair st un chaîn d caractèrs (lign 39) qui provoqura un rrur dynamiqu si ll n rprésnt un URI SIP valid (lign 42). Enn, l srvic s'accompagn d'un dscription XML d 28 ligns (non rprésnté) pour l déploimnt du srvic. Ctt dscription prmt d fair l lin ntr l srvic t l contxt d'invocation. Dans l cas présnté, l srvic st déclnché lorsqu'un appl, c.-à-d. un rquêt INVITE, st à dstination d l'utilisatur du srvic JAIN Srvic Logic Excution Environmnt L'intrgicil JAIN SLEE [JSR04] fournit aux dévloppurs un cadr d programmation plus génériqu qu ls SIP srvlts. Ct intrgicil n'st pas spéciqu au protocol SIP t support d'autrs protocols d télécommunications. L modèl d programmation st un modèl à composants, SBB (Srvic Building Block), similair à clui ds EJB, Entrpris Java Bans [Mic]. L'intraction avc l résau st réalisé grâc à ds adaptaturs d rssourc. Chaqu adaptatur prmt d'accédr à un résau d télécommunications particulir n fournissant l support protocolair nécssair. L'intrgicil JAIN SLEE or l'avantag d fournir un modèl d programmation indépndant du protocol d communications sous-jacnt. Ct intrgicil fournit égalmnt ds srvics annxs comm la gstion d'alarms, d la journalisation t d la gstion d srvics. Malhurusmnt, cla s traduit par un modèl d programmation baucoup plus complx à mttr n uvr pour ls dévloppurs. La documntation st quatr fois plus voluminus qu cll ds SIP srvlts t n facilit pas l'accès aux dévloppurs occasionnls qui voudraint, par xmpl, rapidmnt disposr d'un srvic d rdirction. Ls dévloppurs doivnt non sulmnt avoir d très bonns connaissancs n télécommunications, t n SIP n particulir, mais égalmnt n programmation Java dans un nvironnmnt à composants similair aux EJB. D plus, pour l dévloppmnt d srvics SIP, l dévloppur doit manipulr ls mssags SIP avc l'api JAIN qu nous vnons d présntr. Il n'y a alors qu pu d'intérêt à utilisr l'intrgicil JAIN SLEE si l'uniqu adaptatur d rssourcs actif st l'adaptatur SIP. Enn, comm touts ls autrs approchs fondés sur ds langags généralists, il n'st pas possibl d garantir qu ls programms dévloppés rspctnt ds propriétés critiqus d la téléphoni. Par xmpl, il n'st pas possibl d vérir qu'un srvic JAIN SLEE trait corrctmnt un appl, soit n rnvoyant un répons d'rrur, soit n rlayant la rquêt. D manièr général, il n'st pas possibl d garantir la corrction d'un programm, écrit dans un langag généralist, vis à vis d propriétés spéciqus à un domain tl qu la téléphoni SIP. Pour favorisr l dévloppmnt d srvics d téléphoni tout n présrvant ds propriétés critiqus du domain, ds approchs fondés sur ls langags dédiés ont été dévloppés. 5.2 Langags dédiés L'altrnativ aux intrgicils consist à dénir un langag dédié au dévloppmnt d srvics d communications. Nous allons à présnt voir cinq langags qui ont été dévloppés an d facilitr l'écritur d srvics d téléphoni. Ils sont d dux typs diérnts. On trouv d'un côté ls langags XML comm CPL [LWS04], LESS [WS03] ou CCXML [Aub07], t d'un autr côté ls langags non-xml comm MSPL [Micd] ou SER [POJK03].

72 50 Solutions xistants Langags XML L'avantag ds langags XML tint au fait qu d nombrux outils sont disponibls pour manipulr ls programms. Il st ainsi aisé d réalisr l'analys syntaxiqu d'un chir XML ainsi qu l parcours d l'arbr abstrait généré. Ls outils d'analys syntaxiqu d chir XML s'appuint sur la grammair du chir à analysr. Ctt grammair put êtr écrit indiérmmnt à l'aid d'un DTD [DTD] (Documnt Typ Dnition) ou d'un schéma XML [XSL]. La scond approch st toutfois à privilégir car ll prmt d'xprimr ds contraints supplémntairs sur la grammair du langag. La validation st ainsi plus précis t il y a donc moins d programms rronés considérés comm valids, on parl d faux positifs. Un fois l'analys syntaxiqu réalisé, l parcours d'un arbr abstrait prmt, par xmpl, l'intrprétation ds programms. Ainsi, l'utilisation ds tchnologis XML facilit l dévloppmnt ds outils d'un langag dédié tl qu'un éditur, un compilatur ou un intrprèt. En rvanch, l dévloppmnt ds srvics s'avèr plus fastidiux car ls programms sont vrbux CPL Pu après la standardisation d SIP, l langag CPL [LWS04] (Call Procssing Languag) a été déni pour dévloppr ds srvics d routag. Il st conçu avc un objctif d simplicité t d grand robustss ds srvics an qu tous ls utilisaturs d téléphoni SIP soint n msur d dévloppr lurs srvics, évntullmnt avc l'aid d'éditurs graphiqus. Bin qu CPL n soit pas xplicitmnt dépndant d SIP, ls abstractions qu'il or sont clls d SIP (par xmpl, ls mssags d'rrurs). Dans la pratiqu, CPL n'st pas utilisé n dhors du cadr ds communications à bas du protocol SIP. La gur 5.2 implémnt un rdirction d'appls sur non répons. Un appl ntrant (lign 4) st tout d'abord rlayé d manièr standard (lign 5). Si l'intrlocutur décroch, un répons d succès, c.-à-d. d la class 200, st rtourné t l srvic s'arrêt. Sinon, qulqu soit la caus d'échc (lign 6), un nouvll dstination st sélctionné (lign 7) t l'appl st transféré (lign 8). L langag CPL st déni par un grammair DTD. Un srvic CPL st donc syntaxiqumnt valid s'il rspct la DTD du langag CPL (lign 2). L langag CPL or ds abstractions pour la rdirction d'appls (ligns 7 t 8), l'nrgistrmnt d mssags dans un journal t l rfus d'appls. Cs abstractions dénissnt ds actions qui puvnt êtr appliqués sur un communication. L langag CPL dénit égalmnt ds conditionnlls modiant l routag ds appls sur ds critèrs tls qu la sourc d'un appl, la dstination d'un appl, l'hur d'un appl. Ls srvics CPL s'xécutnt sur un srvur dans l résau [POJK03] plutôt qu sur ls téléphons clints. D c fait, l langag CPL n'or pas d fonctionnalité prmttant d mttr un intrlocutur n attnt par xmpl. Enn, ls srvics CPL n s'appliqunt qu'à l'initialisation ds appls. Un fois qu l'applant a rçu un répons dénitiv, c'st-à-dir qu son appl st un succès ou un échc, l srvic CPL s'arrêt (ligns 5 t 8). Il n'st donc pas possibl d'nrgistrr la duré d'un appl par xmpl. D manièr général, l langag CPL a été conçu pour éliminr tout problèm potntil pouvant corrompr la plat-form d téléphoni. Malhurusmnt, cla s'st fait au détrimnt d l'xprssivité du langag qui n propos pas d variabl par xmpl. D fait, il n'st pas possibl d'écrir un srvic qui nrgistr ls domains applés. Il n'st égalmnt pas possibl d'utilisr d l'information xtériur à l'appl comm un bas d donné par xmpl. Sul un parti ds informations issus d'un rquêt INVITE ou d'un d ss réponss nals sont

73 Langags dédiés 51 1 <?xml vrsion="1.0" ncoding="utf-8"?> 2 <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFC3880 CPL 1.0//EN" "cpl.dtd"> 3 <cpl> 4 <incoming> 5 <proxy> 6 <dfault> 7 <location url="sip:scrtary@xampl.com" clar="ys"> 8 <proxy /> 9 </location> 10 </dfault> 11 </proxy> 12 </incoming> 13 </cpl> Fig. 5.2: Rdirction d'appls n CPL xploitabls par un srvic CPL. L'xploitation d donnés issus du systèm d'information d'un ntrpris prmttrait d'avoir un routag plus n t ds srvics plus génériqus car n'xprimant qu la logiqu. L'adrss d la scrétair (lign 7) n srait alors plus forcémnt un constant du srvic LESS Fac aux limitations du langag CPL concrnant la création d'appls ou la gstion d la présnc, l langag LESS [WS03], Languag for End-Systm Srvics, a été conçu. L langag LESS hérit du langag CPL sa rprésntation XML, ainsi qu la plupart ds concpts. Il s'adrss égalmnt au mêm public d'utilisaturs non-xprts t non-programmurs. Mais contrairmnt à CPL, l langag LESS st prévu pour s'xécutr sur un trminal. C positionnmnt ouvr un nouvau spctr d srvics comm nous l'avons vu dans la sction L langag LESS st nrichi avc ds concpts prmttant d contrôlr l trminal. Un srvic LESS put ainsi crér t accptr ds appls, transférr un appl n cours, crér un conférnc téléphoniqu, nvoyr ds mssags instantanés ou ncor achr un fnêtr graphiqu sur l post clint. Enn, un schéma XML srt à la validation ds srvics. La validation st ainsi plus précis qu'n CPL t il y a donc moins d programms rronés considérés comm valids. La gur 5.3 présnt l srvic d rdirction n cas d'rrur vrs la scrétair. L srvic s'xécutant sur l clint, un parti ds rrurs gérabls n CPL (par xmpl, clint non présnt, rrur résau) n l sont plus dans c contxt. L'rrur s limit donc à un nonrépons modélisé par l status busy. L'appl ntrant st traité par la lign 2. Si l'intrlocutur n'st pas disponibl (lign 3 t 4), un nouvll dstination st sélctionné (lign 5) t l'appl st transféré (lign 6). L langag LESS a cpndant la mêm limitation qu l langag CPL. Il n'st pas possibl d dénir ds variabls utilisaturs t ds intractions avc ds systèms xtériurs. Un autr inconvénint du langag LESS st qu'il st conçu pour fonctionnr sur l post d l'utilisatur. Comm nous l'avons vu à la sction , l'mplacmnt d prédilction pour ls srvics rst l résau. L comportmnt du systèm, vis à vis d l'utilisatur, st ainsi plus prévisibl t l'administration plus simpl.

74 52 Solutions xistants 1 <lss> 2 <incoming> 3 <status-switch status-nam="activity"> 4 <status is="busy"> 5 <location url="sip:scrtary@xampl.com"> 6 <rdirct/> 7 </location> 8 </status> 9 </status-switch> 10 </incoming> 11 </lss> Fig. 5.3: Rdirction d'appls n LESS CCXML Pour dépassr ls limitations du langag CPL, l consortium W3C st n train d dénir l langag CCXML [Aub07], égalmnt fondé sur un rprésntation XML. Ls programms CCXML sont validés syntaxiqumnt grâc à un schéma XML. La gur 5.4 implémnt l srvic d rdirction. Un appl ntrant déclnch l'évaluation du bloc lié à l'événmnt connction.alrting pour l'état courant du srvic, c.-à-d. init (lign 6). L'appl st transmis sur l téléphon d Bob (lign 7). Si Bob décroch, l srvic s'arrêt. Sinon la rdirction échou t ls ligns 10 à 13 sont évalués. Un rdirction st alors réalisé vrs la scrétair (lign 11) t l'état du srvic prnd la valur rdir (lign 12) an qu c bloc d cod n soit pas réévalué n cas d'échc d la rdirction vrs la scrétair. L modèl d programmation du langag CCXML st un automat à état, géré d manièr xplicit par ls dévloppurs. Ls ligns 3 t 12 illustrnt la gstion d l'état par un dévloppur. La variabl utilisatur stat0, déclaré à la lign 3, prmt d modélisr l'état d l'automat. Ds événmnts (ligns 6 t 11) prmttnt d fair évolur l'état du srvic tout n ctuant ds actions (ligns 7, 12 t 13). Un événmnt st émis vrs un srvic à chaqu modication d l'état d'un communication, par xmpl un appl ntrant, ou au contrair la n d'un appl. Ls dévloppurs dénissnt ds fragmnts d cod qui sront xécutés lorsqu ls diérnts événmnts survindront. L langag CCXML or ds fonctionnalités prmttant d gérr ds conférncs an d connctr nsmbl plusiurs intrlocuturs. L'utilisation d'un rprésntation XML facilit l traitmnt ctué au nivau du srvur car il st possibl d réutilisr ds outils génériqus pour la manipulation du XML. Malhurusmnt, cla rnd égalmnt l dévloppmnt d srvics plus dicil. En t, il st moins facil pour un programmur d prcvoir t d vérir la logiqu d son application lorsqu cll-ci st noyé dans l'nchvêtrmnt ds baliss XML. Il xist bin qulqus éditurs graphiqus mais, un rprésntation graphiqu st pu adapté pour rprésntr la logiqu d srvics complxs. Enn, comm l'illustr l'xmpl d la gur 5.4, l'état du srvic st xplicitmnt modié par l dévloppur pour fair évolur l'automat sous-jacnt. Ctt gstion xplicit, n plus d'êtr un charg conséqunt pour l dévloppur, st sourc d'rrurs dans ls srvics. En t, il st facil d commttr un rrur typographiqu modiant l comportmnt d l'automat sans qu'aucun alrt n vinn évillr ls soupçons du dévloppur.

75 Langags dédiés 53 1 <?xml vrsion="1.0" ncoding="utf-8"?> 2 <ccxml vrsion="1.0" xmlns=" 3 <var nam="stat0" xpr=" init "/> 4 5 <vntprocssor statvariabl="stat0"> 6 <transition stat="init" vnt="connction.alrting"> 7 <rdirct dst="sip:bob.phon@xampl.com"/> 8 </transition> 9 10 <transition stat="init" vnt=connction.rdirct.faild> 11 <rdirct dst="sip:scrtary@xampl.com"/> 12 <assign nam="stat0" xpr=" rdir " /> 13 </transition> 14 </vntprocssor> 15 </ccxml> Fig. 5.4: Rdirction d'appls n CCXML Langags non-xml Ls langags non-xml nécssitnt un ort plus conséqunt lors du dévloppmnt d'outils pour l langag. La grammair du langag doit, par xmpl, êtr annoté avc ds attributs. Cs attributs sont liés à un langag d programmation. La spécication d la grammair st alors xprimé sous un form dépndant d'un langag d'implémntation comm C pour Yacc [Joh75] ou ls outils XT[BKVV08] pour Stratgo [Kal06]. En contrparti d l'ort initial, l dévloppmnt d srvics st par la suit baucoup plus simpl t ls srvics sont plus aisés à maintnir qu lurs équivalnts XML. Nous présntons ici l langag d ltrag MSPL [Micd] t l langag d conguration d'un srvur SER [POJK03] MSPL Microsoft dispos dans son or logicill d srvurs d communications implémntant un systèm d téléphoni SIP, Rspons Point [Micc] t Oc Communications Srvr [Mica]. An d facilitr l dévloppmnt d srvics d téléphoni, l langag d ltrag MSPL [Micd] st fourni. Lorsqu'un opération n'st pas disponibl via l langag MSPL, la command MSPL Dispatch (Figur 5.5, lign 30) prmt d fair appl à du cod écrit n C# (ligns 41 à 48) t ainsi d'accédr au cadr d programmation.net [Micb]. L langag MSPL st cpndant très rstrint dans ss objctifs. Il n'st ainsi pas possibl d'écrir l srvic d rdirction vrs la scrétair ntièrmnt n MSPL comm l'illustr la gur 5.5. En t, un srvic MSPL n prmt pas d modir t émttr un rquêt pndant l traitmnt d'un répons. Il n'st ainsi pas possibl d rdirigr la rquêt initial vrs la scrétair lorsqu l srvic trait la prmièr répons nal t qu cll-ci st un échc. D plus, il n'st pas possibl pour un dévloppur d présrvr un état ntr dux invocations d'un srvic car l langag MSPL n prmt d'avoir qu ds variabls locals au script. Cs variabls sont donc volatils t lur valur st prdu chaqu fois qu l srvic st intrrompu. L srvic d rdirction n MSPL commnc par ltrr ls rquêts INVITE (lign 5 t 13). La rquêt st marqué (lign 17) puis transmis à tous ls trminaux où l dstinatair st nrgistré (ligns 18 à 22). En cas d'échc (ligns 25 à 28) t si la rdirction n'a pas ncor u liu (lign 29), l traitmnt d la rdirction st délégué au cod C# (ligns 41 à 48). Après avoir conguré un rdirction (ligns 42 à 44), t modié l marquag d la rquêt (lign 45)

76 54 Solutions xistants an qu la rdirction n'ait liu qu'un fois, la nouvll dstination st sélctionné (lign 46) t la rquêt émis (lign 47). 1 <?xml vrsion="1.0"> 2 <lc:applicationmanifst 3 lc:appuri=" 4 xmlns:lc=" 5 <lc:rqustfiltr mthodnams="invite" 6 strictrout="fals" 7 rgistrargnratd="tru" 8 domainsupportd="tru"/ > 9 <lc:rsponsfiltr rasoncods="all" /> 10 <lc:proxybydfault action="tru" /> 11 <lc:splscript><![cdata[ if(siprqust) { 14 touri = GtUri( siprqust.rqusturi); 15 tousrathost = Concatnat( GtUsrNam( touri ), "@", GtHostNam( touri ) ); siprqust.stamp = "normal"; 18 BginFork(fals,0); 19 forach (dbendpoint in QuryEndpoints( tousrathost)) { 20 Fork(dbEndpoint.ContactInfo); 21 } 22 EndFork(); 23 } if(siprspons) { if (siprspons.statusclass!= StatusClass._1xx) { 28 if (siprspons.statusclass!= StatusClass._2xx) { 29 if (siprspons.stamp == "normal") { 30 Dispatch("toScrtary"); 31 rturn; 32 } 33 } 34 } 35 ProxyRspons(); 36 } ]]></lc:splscript> 39 </lc:applicationmanifst> public void toscrtary (objct sndr, RsponsRcivdEvntArgs rsponsargs) { 42 SrvrTransaction st = rsponsargs.clinttransaction.srvrtransaction; 43 ClintTransaction ct = st.cratbranch(); 44 Rqust rq = st.rqust.clon(); 45 rq.stamp = "scrtary"; 46 rq.rqusturi = "sip:scrtary@xampl.com"; 47 ct.sndrqust(rq); 48 } Fig. 5.5: Rdirction d'appls n MSPL SER t OpnSER Ls srvurs SER [POJK03] t OpnSER [Opa] sont ds srvurs mandatairs SIP. L srvur OpnSER st historiqumnt fondé sur SER. SER st réputé pour sa stabilité. OpnSER quant à lui privilégi l'innovation t propos d nombruss xtnsions, parfois au

77 Langags dédiés 55 détrimnt d la abilité. Grâc à l'ajout d moduls écrits n C, il st possibl d'étndr ls fonctionnalités orts par cs srvurs. Ls moduls xportnt ds fonctions. Lorsqu'un modul st chargé à la dmand du chir d conguration (Figur 5.6, ligns 4 t 5), ls fonctions qu'il xport, puvnt alors êtr invoqués par l'administratur du srvur dans l rst du chir d conguration. Ctt architctur modulair prmt par xmpl d'xploitr d manièr uniform plusiurs implémntations d bas d donnés, d gérr la présnc, d fournir l'intropérabilité avc ls résaux XMPP. Il xist égalmnt un modul CPL prmttant aux utilisaturs d déployr lurs srvics mpath="/usr/local/lib/opnsr/moduls" loadmodul "rgistrar.so" 5 loadmodul "sl.so" 6 loadmodul "tm.so" rout { if(ismthod("invite")) { 12 lookup("location"); 13 if (sarch("(t To):boss@xampl.com")) { 14 t_on_failur(1); 15 } 16 if(!t_rlay()) { 17 sl_snd_rply("500", "rlaying faild"); 18 brak; 19 } 20 } } failur_rout[1] { 25 appnd_branch(); 26 rwrituri("sip:scrtary@xampl.com"); 27 lookup("location"); 28 if(!t_rlay()) { 29 sl_snd_rply("500", "rlaying faild"); 30 } 31 } Fig. 5.6: Rdirction d'appls n OpnSER La gur 5.6 illustr ds xtraits d'un chir d conguration d'un srvur OpnSER qui réalisnt l srvic d rdirction vrs la scrétair. L chir s décompos n dux partis : d'un part un préambul prmt la conguration du srvur t ds moduls, d'autr part un nsmbl d blocs d cod xprimant la logiqu d routag ds mssags SIP. Touts ls rquêts SIP rçus par l srvur sont traités n prmir liu par l bloc rout (ligns 9 à 22). Lorsqu la méthod d la rquêt st un INVITE (lign 11), l srvur d'nrgistrmnt st consulté (lign 12). Dans l cas où l dstinatair st concrné par l srvic (lign 13), la transaction SIP st annoté (lign 14) an qu l bloc d rdirction n cas d'rrur (ligns 24 à 31) soit ultériurmnt invoqué si nécssair. L traitmnt d la rquêt INVITE s trmin nsuit normalmnt t cll-ci st transmis (lign 16) au contact fourni par l srvur d'nrgistrmnt. Si l'appl échou, l bloc failur_rout précédmmnt sélctionné st xécuté.

78 56 Solutions xistants Après avoir initialisé la rdirction (lign 25), la nouvll dstination st déni (lign 26), t l'appl émis (lign 28). C mod d dévlopppmnt d srvics présnt d nombrux inconvénints. Tout d'abord, un très grand xprtis st nécssair tant sur SIP qu sur l'implémntation du srvur t son API. Ensuit, l'nsmbl ds srvics st fusionné dans un sul t uniqu chir dont sul l'administratur du srvur possèd ls droits d'accès. Enn, aucun garanti n'st fourni au dévloppur concrnant la validité d la logiqu d son application. Finalmnt, lorsqu'aucun modul n prmt d résoudr un problèm, il st possibl d dévloppr son propr modul d'xtnsion. Toutfois, ctt solution présnt, n plus ds mêms défauts, l bsoin d'un xprtis n programmation bas-nivau C t un connaissanc ncor plus grand d l'implémntation du srvur. 5.3 Bilan Il xist dux typs d solutions au dévloppmnt d srvics d communications fondés sur l protocol SIP. D'un part, ls approchs généralists prmttnt d programmr ds srvics arbitrairs grâc aux langags généralists t à d vasts API. Cpndant, cs approchs n garantissnt pas la abilité ds srvics. La corrction ds programms st ntièrmnt à la charg ds dévloppurs. Cux-ci doivnt disposr d'un grand xprtis couvrant plusiurs domains comm ls télécommunications, ls systèms distribués t la programmation informatiqu. D'autr part, ls approchs langags dédiés actulls n'ornt pas d'altrnativ conciliant abilité ds srvics, xprssivité t concision. En t, l langag MSPL n'st prévu qu pour l ltrag d mssags t délègu la logiqu ds srvics à l'api généralist du srvur. Ls dévloppurs font alors fac à l'écuil ds approchs généralists. L langag CPL or un nivau d garanti intérssant mais au détrimnt d l'xprssivité ds srvics qui n tirnt pas parti ds rssourcs du résau. L langag LESS st quant à lui dstiné aux trminaux t non pas aux srvurs d'applications. L langag CCXML fournit un bonn xprssivité mais pas d vérication autr qu syntaxiqu. D plus, il st particulièrmnt vrbux t or un modèl d programmation propic aux rrurs. Enn, ls scripts d conguration ds srvurs SER ou OpnSER n prmttnt pas un dévloppmnt t un déploimnt simpl ds srvics car l'intrvntion d l'administratur du srvur st rquis t l rdémarrag du srvur nécssair. Par rapport à la dichotomi ds typs d srvics (ls srvics d routag t ls srvics ntités), ls approchs généralists sont plus soupls t prmttnt l dévloppmnt ds dux typs d srvics. Ells n'ornt cpndant aucun support pour gérr la divrsité ds typs d donnés t pu ou pas d support pour gérr ls mods d communications. Quant aux approchs dédiés, ls possibilités sont variabls. Ls srvurs SER t OpnSER n prmttnt d réalisr qu du routag. L langag CPL st égalmnt résrvé aux srvics d routag tandis qu l langag CCXML prmt d dévloppr ds srvics ntités, notammnt grâc à cs fonctionnalités d conférnc. L langag LESS prmt quant à lui d dévloppr ds srvics ntités mais uniqumnt sur ls trminaux, c qui limit ls possibilités orts. Finalmnt, aucun approch dédié n prnd n compt la divrsité ds typs d donnés. D'un point d vu géni logicil, aucun approch dédié n fournit d sémantiqu formll du langag qu'll propos. Ls subtilités d'implémntation sont ainsi laissés à la discrétion ds dévloppurs t à lur compréhnsion d la documntation n langag naturl, parfois soumis à intrprétation.

79 Chapitr 6 Démarch suivi Dans l chapitr 2, nous avons caractérisé ls communications informatiqus t mis n évidnc l bsoin d srvics pour ls gérr. Nous avons égalmnt vu l'xistnc d dux typs d srvics, d'un part ls srvics d routag t d'autr part ls srvics ntités. La téléphoni SIP, présnté dans l chapitr 3, fournit un cadr ouvrt nglobant l'nsmbl ds mods d communications pour divrs typs d donnés. C cadr ouvrt t programmabl prmt l dévloppmnt d srvics d communications. D plus, il put êtr étndu aisémnt à d nouvaux typs d donnés facilitant l'intégration d futurs ntités communicants. Ls approchs xistants pour l dévloppmnt d srvics d communications, présntés au chapitr 5, n'ornt cpndant aucun solution satisfaisant. Aucun n'st à la fois simpl, sûr t xprssiv. L'approch ds langags dédiés a prouvé son cacité sur cs points dans d nombrux domains comm l montrnt ls xmpls présntés au chapitr 4. Nous récapitulons, dans c chapitr, ls problèms auxquls doit fair fac un dévloppur d srvics d communications. Nous présntons nsuit l'approch langag, fondé sur l concpt ds langags dédiés qu nous préconisons d'adoptr. 6.1 Problématiqu Nous avons vu qu ls communications n cssaint d s multiplir (Chapitr 2). D nouvlls ntités communicants apparaissnt ainsi régulièrmnt. Ells dénissnt parfois d nouvaux typs d donnés. L protocol SIP, initialmnt conçu pour la téléphoni IP, prmt plusiurs mods d communications : ls communications synchrons, qu'lls soint sporadiqus ou par ux d donnés, t ls communications asynchrons. D plus, l protocol SIP st xtnsibl par natur. Il st donc parfaitmnt adapté comm support ds communications t d lur évolution. An d fair fac à l'augmntation ds communications t d facilitr lur gstion, il st nécssair d'automatisr l traitmnt grâc au dévloppmnt d srvics d communications. L'importanc ds communications impos cpndant qu la abilité ds srvics d communications soit garanti avant lur xécution. La plat-form d communications st ainsi protégé contr ls rrurs qu la logiqu ds srvics applicatifs put introduir. Toutfois, il n'xist aucun solution satisfaisant pour l dévloppmnt d srvics d communications. D'un côté, ls solutions généralists sont complxs à mttr n uvr. D plus, lls n prmttnt pas d garantir ds propriétés critiqus d la plat-form d communications sous-jacnt. D'un autr côté, ls solutions dédiés xistants n'ornt pas d compromis sat- 57

80 58 Démarch suivi isfaisant ntr ls vérications possibls, l'xprssivité t la simplicité d dévloppmnt. Il st ainsi nécssair d choisir, par xmpl, ntr CPL pour la simplicité t ls vérications, t CCXML pour l'xprssivité. L bsoin urgnt d srvics, ainsi qu ls conséquncs qu put avoir l déploimnt d'un srvic rroné, justint l dévloppmnt d'un nouvll approch à la fois simpl, xprssiv t sûr. Nous préconisons la mis n uvr d'un approch fondé sur l concpt ds langags dédiés. En t, l'xpérinc montr qu grâc aux rstrictions t aux abstractions qu'ils proposnt, ls langags dédiés prmttnt d spécir ds solutions à un famill d problèms, tout n rndant décidabl ds propriétés spéciqus au domain pour lqul ils sont dédiés. Nous présntons maintnant la démarch suivi pour la concption t la réalisation d ctt nouvll approch dans l cadr ds srvics d communications. 6.2 Démarch global L'approch qu nous proposons pour facilitr l dévloppmnt d srvics d communications st fondé sur l'utilisation ds langags dédiés, tls qu présntés dans l chapitr 4. Comm nous l'avons vu (Sction 2.2), il xist dux typs d srvics : d'un part ls srvics d routag, t d'autr part ls srvics ntités. La prmièr étap d notr démarch a donc consisté à dénir un langag dédié au dévloppmnt ds srvics d routag. Par la suit, nous avons généralisé l dévloppmnt d srvics aux srvics ntités n dénissant un scond langag. Chacun d cs dux langags a fait l'objt d'un étud d domain avant sa concption. Ds sémantiqus statiqus ds langags ont été dénis t prmttnt diérnts analyss n fonction du typ d srvics. Enn, un sémantiqu dynamiqu pour chacun d cs dux langags n dénit l comportmnt à l'xécution. L'nsmbl ds sémantiqus a été utilisé pour l dévloppmnt d'un implémntation d chacun ds langags Un langag pour ls srvics d routag La gur 6.1 illustr l procssus d dévloppmnt ds srvics d routag. Un srvic st tout d'abord analysé an d déclr d'évntulls rrurs ou incohérncs qui pourraint compromttr la plat-form SIP. Ctt phas d'analys détct, par xmpl, ls srvics qui n rtournnt pas d répons à la suit d'un rquêt ou ls srvics suscptibls d violr un règl du protocol SIP. L'objctif st d rjtr lors d l'analys ls srvics qui risqunt d placr la plat-form d communications dans un état incohérnt. Enn, si l srvic st corrct, clui-ci st déployé sur l srvur d'applications après un phas d transformation. Il st alors possibl lors d ctt transformation d réalisr automatiqumnt crtains optimisations. Cs optimisations puvnt, par xmpl, prmttr d minimisr l'spac mémoir nécssair pour un srvic donné ou d'agir sur ds paramètrs du protocol SIP an d facilitr l passag à l'échll du srvur d'applications Un langag pour ls srvics ntités La gur 6.2 illustr l dévloppmnt ds srvics ntités. Un xprt modélis un nvironnmnt comm par xmpl un ntrpris, un maison, un administration ou un hôpital. Slon l'nvironnmnt, divrs scénarios puvnt êtr nvisagés, survillanc d'un patint dans

81 Démarch global 59 Fig. 6.1: Procssus d dévloppmnt d srvics d routag Fig. 6.2: Procssus d dévloppmnt d srvics ntités

82 60 Démarch suivi un hôpital, localisation d bins ou d prsonns dans un bâtimnt, rdirction d'appls intllignt dans un administration. La modélisation d'un nvironnmnt consist à dénir ls srvics présnts t nécssairs pour ds scénarios d'applications. Un srvic abstrait dénit un class d srvics ntités similairs. Chaqu dénition abstrait indiqu ls fonctionnalités qui prmttnt d communiqur t ls propriétés qui caractérisnt un class d srvics. L'nsmbl ds srvics abstraits constitu l modèl d'un nvironnmnt. Un modèl d'nvironnmnt, ou par abus d langag un nvironnmnt, spéci égalmnt ls communications ntr ls srvics abstraits t ls typs d donnés mis n uvr par ss communications. Il st ainsi possibl d dénir un variété d'nvironnmnts où ds srvics distribués communiqunt ntr ux. Nous nous intérssrons plus particulièrmnt à la dénition d'un nvironnmnt pour la téléphoni incluant, par xmpl, ds annuairs, ds boîts vocals, ds bass d donnés t ds téléphons. Un fois un nvironnmnt modélisé, un ou plusiurs srvics ntités sont dévloppés pour ds srvics abstraits. Cs srvics ntités spécint ds logiqus d coordination ds communications ntr ls srvics d'un nvironnmnt. Cs logiqus sont xprimés à l'aid d'un langag dédié qui réutilis ls dénitions d'un nvironnmnt t partag ds concpts liés au domain avc l langag d modélisation. Après avoir vérié la cohérnc d'un nvironnmnt t ds communications ntr ss srvics, un prmir compilatur génèr un intrgicil dédié à la spécication d'un nvironnmnt donné. Ct intrgicil or du support d programmation spéciqu aux srvics t aux typs d donnés dénis dans l'nvironnmnt. C support facilit l dévloppmnt manul, dans un langag généralist, d srvics communicants d l'nvironnmnt. Un scond compilatur prmt d générr ds srvics pour ct intrgicil à partir d srvics ntités écrit à l'aid du langag d logiqu d coordination qu nous proposons. L scond compilatur prmt d vérir ls srvics ntités vis à vis du srvic abstrait qu'ils implémntnt. Ils doivnt notammnt rspctr ls contraints du srvic n trm d fonctionnalités t d propriétés tl qu dénis par l modèl d l'nvironnmnt. Dans la suit d c documnt, nous détaillons ls diérnts étaps d la démarch qu nous vnons d présntr. Tout d'abord, nous décrivons la concption d'un langag dédié pour l dévloppmnt d srvics d routag. Nous présntons l'analys d domain, qui rprnd ls élémnts principaux déjà abordés dans l'nsmbl d ctt parti, puis l'analys d propriétés du domain, t nn l'implémntation t la mis n uvr d la solution. D manièr similair, nous présntons nsuit la généralisation qui consist à dénir un langag pour l dévloppmnt d srvics ntités.

83 Duxièm parti Approch proposé 61

84

85 Chapitr 7 SPL Notr objctif st d concvoir un langag dédié au dévloppmnt d srvics d routag. La concption du langag dédié SPL (Sssion Procssing Languag) suit la variant d la méthodologi Sprint [CM98] présnté au chapitr 4 t fondé sur l'utilisation d'un sémantiqu opérationnll t d'un machin virtull. Après un étud du domain ds srvics d routag dans ls systèms d communications SIP, nous dénissons l langag SPL. La dénition d c langag comprnd, outr la syntax, ds analyss fondés sur un sémantiqu statiqu ainsi qu'un sémantiqu dynamiqu décrivant l comportmnt ds programms. Ctt sémantiqu dynamiqu srt d fondation à l'implémntation d'intrprèts pour l langag SPL Analys du domain La concption d'un DSL nécssit un étap préliminair t crucial : l'étud du domain qu'il cibl. Nous allons dans ctt sction récapitulr ls élémnts spéciqus aux srvics d routag fondés sur l protocol SIP. Cs élémnts dénissnt l domain du futur langag. Ils sont abordés au travrs d'un étud qui présnt ls sourcs d'information, ls points communs t ls variations du domain. Ctt étud s trmin par un cahir ds chargs pour la concption du langag Sourcs d'information An d mnr à bin l'analys du domain, divrss sourcs d'information ont été utilisés. Nous avons notammnt rcnsé ls srvics d routag xistants dans ls solutions patrimonials. Nous avons nsuit étudié plus n détail l'nsmbl ds approchs d dévloppmnt logicil rposant sur l protocol SIP ainsi qu ls srvics fondés sur cs approchs (Chapitr 5). L'analys d cs élémnts nous a prmis d détrminr la trminologi, ls points communs t ls variations du domain. Enn, l'étud approfondi ds diérnts RFC [Ni04, RSC + 02, 1 Illustration d Pssin tiré d l'articl sur SPL dans l'inédit nº51, novmbr 2005, INRIA 63

86 64 SPL Roa02, CRS + 02, SIM] spéciant l protocol SIP t ss xtnsions a prmis d dénir ls contraints imposés par l protocol t dvant êtr rspctés par ls srvics Points communs L'objctif d l'analys d points communs st d détrminr ls concpts rlatifs au domain étudié. Cs concpts sront présnts dans l'nsmbl ds programms sous la form d motsclés ou d constructions du langag. Nous pouvons distingur dux typs d concpts : ls objts t ls opérations. Un objt st utilisé pour modélisr ds donnés du domain, comm un mssag SIP dans notr cas. Ls opérations dénissnt ls manipulations possibls sur un objt, comm l routag d'un mssag par xmpl Objts Ls objts rprésntnt ls concpts du domain qui sont xplicités. Ls mssags constitunt ls objts d bas d notr domain. Ils puvnt êtr soit ds rquêts, soit ds réponss. Ls mssags sont composés d'n-têts suivis d'un charg util. Ls n-têts sont richs d'informations rnsignés par ls n uds SIP t constitunt ds objts qu'il st important d pouvoir manipulr. Enn, SIP st un protocol txtul inspiré du protocol HTTP qui rpos sur un usag important ds URI. En t, l routag ds mssags SIP consist à manipulr t réécrir ds URI. Ls URI constitunt donc ds objts qui doivnt pouvoir êtr manipulés d façon sûr par un dévloppur an d n pas compromttr l routag. Événmnts Dans ls approchs xistants, tous ls événmnts protocolairs pris n compt, sont modélisés par un événmnt au nivau programmation. La récption d mssags (ds rquêts ou ds réponss), ainsi qu l'xpiration d'alarms protocolairs, provoqunt l'xécution d la logiqu corrspondant, déni par l'utilisatur. Dans l cas d JAIN SIP par xmpl, l dévloppur st notié d trois typs d'événmnts : la récption d rquêts, la récption d réponss t l'xpiration d'alarms. Ls événmnts ds SIP srvlts sont plus précis t il st ainsi possibl d'avoir un événmnt pour chaqu typ d rquêt (par xmpl, INVITE, ACK, BYE). Toutfois, c nivau d'abstraction manqu ncor d nss t d précision. En t, un rquêt INVITE put êtr émis à la fois pour crér un communication mais égalmnt pour modir ls propriétés d'un communication xistant (par xmpl, pour ajoutr d la vidéo). D mêm, un rquêt REGISTER srt à la fois à l'nrgistrmnt initial auprès du résau SIP mais égalmnt au maintin d'un nrgistrmnt xistant. Enn, l désnrgistrmnt st égalmnt réalisé via un rquêt REGISTER. Nous proposons donc d ranr ls événmnts protocolairs n fonction d lur signication. Lorsqu qu'il s'agit d la prmièr transmission, l'événmnt port l mêm nom qu la rquêt. Lors ds transmissions suivants, sa signication dièr t il st préxé par RE ; on parl d'événmnts ranés. Nous avons ainsi ls événmnts REREGISTER t REINVITE qui rannt, rspctivmnt, ls événmnts protocolairs d récption d rquêts REGISTER t INVITE. Lorsqu l'on considèr ls approchs généralists, clls-ci xposnt égalmnt ds événmnts d la plat-form, comm ls méthods init t dstroy pour ls SIP srvlts (Figur 5.1, pag 48), prmttant à l'utilisatur d'initialisr ou détruir un état rlatif au srvic. Ct état put allr d'un simpl variabl, comm un comptur, à un référnc sur un bas d donnés ou un annuair pour réalisr ds intrrogations ultériurs. En plus ds événmnts

87 Analys du domain 65 plats-forms pour l'administration ds srvics, nous proposons d modélisr ls événmnts protocolairs d trminaison ds communications par ds événmnts plats-forms. Cs événmnts sont déclnchés systématiqumnt à la n d'un communication, qu cll-ci soit dû à l'xpiration d'un alarm ou à un trminaison normal à l'aid d'un rquêt SIP. Nous introduisons ainsi ls événmnts uninvit t unrgistr marquant rspctivmnt la n d'un convrsation t la n d'un nrgistrmnt. Partitionnmnt ds événmnts n sssions Qu l'on considèr ls concpts d srvic, nrgistrmnt ou dialogu, c.-à-d. un convrsation, un notion d cycl d vi st présnt. Nous utilisrons par la suit l trm d sssion pour désignr un cycl d vi. Il st à notr qu nous avons généralisé l trm d sssion qui, dans la RFC dénissant SIP, n fait référnc qu'à un sssion dialogu. Un sssion commnc par un phas d'initialisation qui cré un instanc d sssion particulièr. À la suit d ctt création, un phas intrmédiair prmt la modication d la sssion. Enn, la sssion s trmin par un événmnt nal. Ls événmnts puvnt ainsi êtr partitionnés n trois nsmbls slon lur rôl : création, modication t trminaison. L tablau 7.1 montr l partitionnmnt ds événmnts ranés slon lur rôl vis à vis d la sssion à laqull ils s rapportnt. Nous dénissons quatr typs d sssions : srvic, rgistration, dialog t vnt. Ls sssions srvic nglobnt l'intégralité du cycl d vi d'un srvic d son activation à son arrêt. D manièr similair, ls sssions rgistration rgroupnt ls opérations ayant liu ntr l prmir nrgistrmnt d l'utilisatur sur l résau SIP t son désnrgistrmnt. Ls sssions dialog t vnt corrspondnt rspctivmnt aux sssions pour ls communications par ux d donnés t aux communications par événmnts. Un sssion vnt s'activ lorsqu'un ntité SIP souscrit à un événmnt. Ell comprnd ls notications ds événmnts qui s'n suivnt jusqu'à l'arrêt d la souscription. Ls rquêts MESSAGE, PUBLISH t OPTIONS font l'objt d'un traitmnt particulir. La rquêt MESSAGE st utilisé pour ls communications synchrons sans ux d donnés t prmt l'échang sporadiqu d donnés ntr dux ntités. La rquêt PUBLISH prmt l'émission d'événmnts SIP. Cpndant, ctt rquêt n'appartint pas à un sssion événmnt vnt t st transformé n rquêt NOTIFY par l srvur d notication auqul ll st adrssé. La rquêt OPTIONS prmt, quant à ll, d découvrir ls fonctionnalités orts par un clint ou un srvur SIP. Cs trois méthods font l'objt d'un traitmnt particulir car il n'y a pas d sssion associé. En-têts La prmièr lign ds mssags SIP st suivi d'n-têts puis d'un charg util. Ls n-têts continnnt ds informations qui doivnt êtr accssibls par un srvic. Par xmpl, un srvic d ltrag d'appls nécssit d pouvoir détrminr l'origin d'un appl, sa dstination initial ou si un rdirction a u liu. Ls mssags SIP sont ds mssags txtuls t chaqu n-têt st donc rprésnté par un chaîn d caractèrs. Il st toutfois plus pratiqu pour un dévloppur d'avoir un vu structuré ds n-têts. L'n-têt Max-Forwards, qui évit ls boucls innis ntr srvurs mandatairs, put ainsi êtr vu comm un ntir non signé sur 8 bits, par xmpl. Uniform Rsourc Idntir (URI) Ls URI rprésntnt un concpt clé dans ls protocols informatiqus tls qu SMTP ou HTTP. L protocol SIP réutilis égalmnt c concpt.

88 66 SPL Concpts Événmnts Création Modication Trminaison srvic dploy rfrsh undploy rgistration REGISTER REREGISTER unrgistr CANCEL BYE dialog INVITE ACK uninvit REINVITE vnt SUBSCRIBE RESUBSCRIBE NOTIFY unsubscrib Sans sssion MESSAGE PUBLISH OPTIONS Tab. 7.1: Classication ds événmnts SIP ranés L routag ds mssags SIP st ainsi fondé sur la réécritur d'uri. Il st donc important d pouvoir garantir qu ls URI présnts dans un srvic sont bin formés t rspctnt la RFC 3986[BLFM05]. Bin qu l protocol SIP manipul ssntillmnt ds URI SIP, il st possibl d'utilisr égalmnt ds URI d courrirs élctroniqus ou ds URI Wb. Par xmpl, si l dstinatair d'un appl n put répondr, il put rdirigr son intrlocutur vrs un pag Wb ou sa boît d courrirs élctroniqus. Un srvic d routag SIP doit donc êtr capabl d gérr ds URI arbitrairs. État An d prsonnalisr l routag d mssags SIP, ls srvics doivnt s'appuyr sur l'état du systèm pour prndr ds décisions d routag. L'état du systèm st déni par l'état ds communications t l'état du systèm d'information. Il n'st cpndant pas nécssair d dénir l routag n fonction d l'état complt du systèm t ls dévloppurs puvnt dénir un modèl d ct état au sin d'un srvic grâc à ds variabls. Cs variabls constitunt un état associé au srvic, qu l'nvironnmnt d'xécution doit manipulr automatiqumnt an d facilitr la tâch ds dévloppurs Opérations L'opération fondamntal pour ls srvics d routag consist à routr ls mssags. Il st toutfois nécssair, pour rndr l langag xprssif, d complétr ls opérations d signalisation par ds opérations plus standards, d calculs arithmétiqus par xmpl. Opérations d signalisation Touts ls approchs proposnt ds opérations prmttant d rlayr ls mssags. Nous pouvons toutfois distingur dux opérations élémntairs pour l routag : la prmièr consist à rlayr un rquêt vrs l dstinatair, tandis qu la scond srt à rtournr un répons vrs l'initiatur d la communication. L'opération d routag st primordial, il st toutfois nécssair d disposr d'autrs opérations an d manipulr ls mssags SIP. L'un ds principals caractéristiqus du protocol SIP st d'êtr inspiré du protocol HTTP. Un mssag SIP possèd, n plus d la prmièr lign dédié au routag, ds n-têts. Il nécssair qu l langag dispos d'opératurs prmttant d manipulr cs n-têts.

89 Analys du domain 67 Opérations standards An d rndr xprssif l langag, il st important qu'il comport ds opérations standards, non dédiés à la signalisation. Cs opérations doivnt prmttr d réalisr, par xmpl, ds calculs arithmétiqus t logiqus. An d tirr parti du systèm d'information, l langag doit égalmnt prmttr d'invoqur ds méthods xtrns au srvic t au langag Variations Lors d'un analys d domain, il faut étudir ls points communs, mais égalmnt ls variations. Nous vnons d voir ls points communs ds srvics d routag. Nous allons à présnt voir ls variations qui diérncint cs srvics, d'un part clls concrnant ls objts précédmmnt décrits, t d'autr part clls concrnant ls opérations Objts Pour chacun ds objts communs aux srvics d routag, nous pouvons dénir un dimnsion slon laqull l'objt vari. Nous allons voir qulls sont ls variations qui intrvinnnt sur ls événmnts, ls sssions, ls n-têts t l'état ds srvics. Événmnts Tous ls événmnts n nécssitnt pas d traitmnt particulir pour un srvic donné. Par xmpl, ls srvics CPL prmttnt uniqumnt l routag d'appls t dénissnt donc un logiqu d routag uniqumnt pour ls rquêts INVITE. Ls srvics équivalnts dans notr langag s doivnt d'êtr aussi simpls. Ls événmnts nécssairs à un srvic varint n fonction d l'objctif du srvic. Suls ls événmnts nécssairs à ct objctif doivnt donc êtr xplicités t un logiqu particulièr lur êtr associé. L traitmnt d'un répons protocolair vari égalmnt. Ls approchs généralists assocint un méthod spéciqu pour l traitmnt ds réponss. Ctt approch nécssit généralmnt qu l dévloppur fass xplicitmnt l'association avc la rquêt qui a généré la répons. Au contrair, CPL captur cs événmnts comm un sous-traitmnt qui s'xécut dans la continuité d l'opération ayant rlayé la rquêt rndant ainsi linéair la logiqu d routag. Ctt approch présnt l'avantag d présrvr l contxt du traitmnt d l'appl t évit la gstion xplicit d l'état d'un transaction par l dévloppur. Ls réponss présntnt égalmnt ds variations. Ls réponss sont caractérisés par un cod d rtour variant d 100 à 699. L chir ds cntains indiqu un class d réponss. Il n xist donc six : provisoir, succès, rdirction, rrur clint, rrur srvur, rrur global. À l'xcption ds réponss provisoirs, touts ls autrs trminnt un transaction. Sssions Nous avons précédmmnt vu qu ls événmnts sont rgroupés au sin d sssions. Un sssion dénit l cycl d vi rlatif à un srvic, un nrgistrmnt, un dialogu. Nous pouvons constatr qu'il xist un ordr ntr ls sssions. Un srvic st ainsi présumé actif pndant qu ls usagrs s'nrgistrnt. Enn, un appl n put aboutir qu si son dstinatair st nrgistré. La structur d'un srvic doit rétr ctt hiérarchi ntr ls sssions. Cpndant, la hiérarchi d sssions nécssair pour un srvic donné vari n fonction d l'objctif du srvic. Par xmpl, un sssion rlativ à l'nrgistrmnt n'st pas toujours nécssair t put êtr omis. La sssion dialogu put alors êtr dirctmnt déclaré dans la sssion srvic.

90 68 SPL En-têts Crtains n-têts du protocol SIP sont obligatoirs n touts circonstancs, tandis qu d'autrs sont obligatoirs uniqumnt dans crtains contxts. La plupart ds n-têts sont cpndant facultatifs. Un dévloppur doit n conséqunc vérir la présnc d la plupart ds n-têts avant d ls lir ou d ls modir. L langag doit prmttr aux dévloppurs d minimisr ls opérations d contrôl. Lorsqu'un n-têt st obligatoir, son accès doit êtr simpl t dirct. En rvanch, il st nécssair d'imposr un phas d vérication d la présnc ds n-têts optionnlls. État L'état global d'un srvic a plusiurs nivaux d granularité. L'état global d'un srvic st ainsi divisé n plusiurs partis. Chaqu parti rspct un cycl d vi idntiqu aux sssions srvic, rgistration, dialog t vnt. Au sin d cs sssions, il st possibl d dénir un état lié à un transaction SIP (c.-à-d. un rquêt t sa répons rtourné). Ct état st alors créé pndant l traitmnt d'un rquêt puis libéré un fois la répons associé rtourné. L langag doit facilitr t vérir la gstion d l'état global Opérations Nous vnons d voir ls variations qui xistnt sur ls objts manipulés par un srvic d routag. Nous allons à présnt voir qulls sont ls variations ds opérations qu doit fournir l langag. Opérations d signalisation Ls événmnts ranés n sont pas tous issus d rquêts SIP. Ls événmnts d la plat-form qui corrspondnt à la sssion d'un srvic (par xmpl, dploy ou undploy) ou à la n d'un sssion (par xmpl, unrgistr ou uninvit), n sont pas l ranmnt d'un rquêt. Ls opérations d signalisation n'ont alors pas d sns dans c contxt particulir t doivnt êtr proscrits. Dans l cadr ds événmnts ranés issus d'un rquêt, plusiurs situations puvnt s présntr. Tout d'abord, si l'événmnt cré un sssion (par xmpl, REGISTER ou INVITE), l srvic put alors librmnt choisir ntr l comportmnt par défaut qui consist à rlayr la rquêt vrs sa dstination d'origin ou un rdirction vrs un ou plusiurs nouvaux intrlocuturs, ou ncor un rdirction vrs plusiurs intrlocuturs simultanémnt ; on parl alors d rdirction n parallèl. Finalmnt, l srvic put rjtr la rquêt t produir un répons d'rrur. Ls événmnts intrmédiairs t trminaux pour ls sssions, comm ls événmnts ACK ou BYE, n puvnt pas tous êtr rjtés, n produisant un répons d'rrur, ou routés vrs un nouvll dstination. Dans ls dux cas, cla mttrait ls clints SIP ds intrlocuturs dans un état incohérnt l'un vis à vis d l'autr. Cs événmnts doivnt donc êtr analysés an d garantir qu'ils rlaynt bin la rquêt sous-jacnt à son dstinatair initial. Enn, ls événmnts indépndants ds sssions (par xmpl, MESSAGE ou OPTIONS) puvnt êtr routés comm ls événmnts d création d sssions. Ils puvnt ainsi êtr rlayés soit à la dstination d'origin, soit vrs un nouvll dstination ou ds dstinations multipls t simultanés, ou tout simplmnt rjtés par l srvic. Opérations standards Ls méthods xtrns aux srvics sont soit locals au srvur d'applications, soit distants, via ds appls d méthod à distanc. Parmi ls opérations locals, nous pouvons citr ls opérations liés à l'hur du systèm ou à l'accès à ds chirs locaux. Quant aux méthods distants, lls prmttnt d'intégrr, dans l procssus d routag, d

91 Analys du domain 69 l'information issu par xmpl d bass d donnés, d'annuairs ou d'agndas. En t, cs srvics sont généralmnt déployés sur ds srvurs dédiés pour ds raisons divrss (par xmpl, sécurité, passag à l'échll ou abilité) Cahir ds chargs Nous vnons d voir ls points communs t ls variations qu présnt l domain ds srvics d routag. Il convint à présnt d dénir ls objctifs du langag avant d dénir clui-ci Programmation plus facil Nous avons vu qu l dévloppmnt d srvics d routag était rarmnt simpl avc ls approchs xistants. Par xmpl, sul l langag CPL propos un modèl d programmation où la logiqu d routag st linéair. En t, l traitmnt d'un mssag INVITE déclnch l'xécution du srvic. Lorsqu'un n ud proxy st rncontré, l'xécution st suspndu jusqu'à la récption d'un répons trminal. La programmation d'un transaction rspct ainsi un modèl d programmation impératif souvnt plus simpl à appréhndr par un programmur qu'un modèl événmntil comm n CCXML, n JAIN SIP ou n SIP srvlts. Nous avons égalmnt vu qu la gstion d l'état d'un srvic était rarmnt simpl pour un dévloppur. L'un ds objctifs du langag doit êtr d simplir la gstion d l'état. L langag qu nous concvons doit donc proposr un modèl d programmation familir, gérant automatiqumnt l'état lorsqu cla st possibl. An d facilitr ncor un pu plus l dévloppmnt, ls objts t opérations du domain qu nous vnons d dénir, doivnt êtr xplicits t dirctmnt xploitabls par ls dévloppurs Réutilisation systématiqu L'un ds objctifs ds langags dédiés st d favorisr la réutilisation du cod. Notr langag prmt d dénir ds srvics d haut nivau d'abstraction par rapport au systèm d'xploitation t au protocol SIP. Il st donc intérssant qu'il s'appui sur un intrgicil srvant d'nvironnmnt d'xécution pour ls srvics. Ct nvironnmnt d'xécution doit prmttr au langag d capitalisr sur ls blocs logicils qu'il fournit. Chaqu srvic d routag capitalis ainsi sur ct nvironnmnt grâc à un compilatur ou un intrprèt pour l langag. Tout modication, ajoutant ds nouvlls fonctionnalités ou ds optimisations, prot alors à l'nsmbl ds srvics y compris ls srvics déjà dévloppés Fiabilité amélioré Nous avons à plusiurs rpriss mntionné l'aspct critiqu ds communications t l'importanc d présrvr la plat-form d communications, y compris n présnc d srvics. Bin qu l choix d'un architctur résau prmtt n parti d'améliorr la abilité n séparant physiqumnt, par xmpl, ls srvurs mandatairs SIP t ls srvurs d'applications, il st égalmnt nécssair d rndr abl ls srvics ux-mêms. Il st ainsi possibl d déployr plusiurs srvics sur un mêm srvur d'applications, tout n garantissant l bon fonctionnmnt d c drnir. An d garantir lur abilité, ls srvics doivnt fair l'objt d'analyss pour prouvr qu'ils n transgrssnt pas ls règls imposés par l protocol. Nous avons ntr autrs idntié qu

92 70 SPL chaqu événmnt lié à un rquêt doit conduir à un action d signalisation. La rquêt st soit rlayé à son dstinatair d'origin ou à un ou plusiurs nouvaux dstinatairs, soit rjté par l srvic. Slon l'événmnt, touts cs altrnativs n sont cpndant pas possibls comm nous l'avons vu précédmmnt (Sction ). Enn, nous avons égalmnt vu qu l'accès aux n-têts st problématiqu. L'un ds objctifs du langag st d'imposr aux dévloppurs ls tsts d présnc ds n-têts facultatifs Prformancs L drnir point d notr cahir ds chargs consist à fournir ds prformancs n tmps t n mémoir comparabl à un implémntation manull. L'objctif st d réalisr, d manièr automatiqu, ls optimisations actullmnt réalisés manullmnt. Ls opportunités d'optimisation doivnt donc êtr détctabls grâc à l'analys ds srvics. Un génératur d cod pour l langag a nsuit la rsponsabilité d'appliqur ls optimisations possibls. Un dé majur consist à minimisr n prmannc l'spac mémoir nécssair à un srvic. Un tll optimisation favoris l passag à l'échll ds srvurs d'applications. Dans ctt optiqu, il faut par xmpl détrminr si l'état d'un srvic st prsistant, n totalité ou n parti, durant un transaction, un sssion ou l'nsmbl d'un srvic. Il st alors possibl d libérr automatiqumnt ls composants d l'état dvnus inutils. 7.2 Dénition du langag Un fois l'analys d domain réalisé, ls points communs t ls variations idntiés srvnt à dénir la syntax du langag. Nous dénissons nsuit la sémantiqu statiqu. L'analys ds srvics sra par la suit fondé sur ctt sémantiqu. Nous trminons la dénition du langag par la sémantiqu dynamiqu. L'objctif st alors d dénir l comportmnt d'un srvic à l'xécution Syntax La syntax détrmin la structur ds srvics t ls agncmnts possibls ds constructions du langag ls uns par rapport aux autrs. Un dévloppur dénit ainsi un logiqu donné par un agncmnt particulir. La syntax du langag SPL st décrit d manièr informll, illustré par ds xmpls. La dénition complèt n notation BNF st donné n annx A. Nous illustrons dans ls paragraphs suivants l'utilisation ds objts précédmmnt décrits (c.-à-d. ls événmnts, ls sssions, ls n-têts, ls URI, l'état) ainsi qu l'utilisation ds opérations d signalisation t ds opérations standards Événmnts La gur 7.1 montr l'xmpl d la rdirction vrs un scrétair n cas d'échc d'un appl. L srvic a été complété par un comptur du nombr d rdirctions ayant u liu pndant l'nrgistrmnt d l'utilisatur du srvic, typiqumnt un journé. C comptur illustrra ds fonctionnalités proprs à SPL par la suit. À chaqu événmnt d récption d'un rquêt, l langag SPL fait corrspondr un méthod (ligns 17 à 24). La diérnc notabl vis à vis d solutions tlls qu ls SIP srvlts,

93 Dénition du langag 71 résid dans l fait qu la méthod couvr l'intégralité d'un transaction, c'st-à-dir d la récption d'un rquêt par l srvic jusqu'à l'émission d'un répons n rtour. L'opération d signalisation forward (ligns 9, 18 t 21) rlai la rquêt associé à l'événmnt n cours d traitmnt. Un rdirction d la rquêt st alors possibl comm l montr la lign 21. Lorsqu'un répons st rtourné, l'xécution rprnd son cours. La n du traitmnt d'un événmnt s trmin par l'opération rturn qui rnvoi un répons vrs l'émttur initial (ligns 9, 21 t 23). La répons rtourné put êtr produit par l srvic, par xmpl dans l cas d'un srvic d ltrag d'appls. L dévloppur pass alors n argumnt d l'opération rturn un cod d'rrur SIP, par xmpl /ERROR/CLIENT/BUSY_HERE. Il st à notr qu SPL or un vu hiérarchiqu ds cods d rtour. À l'instar d CPL, ls mssags provisoirs n sont pas modélisés n SPL car ils n'ont pas ou pu d'impact sur l déroulmnt d la communication t n'inunt pas sur son aboutissmnt. Au prmir nivau d la hiérarchi ds réponss, SPL dénit dux catégoris, /SUCCESS t /ERROR qui corrspondnt rspctivmnt aux classs d cods d rtour 200 t 300 à 600. La scond catégori st rané par quatr sous-catégoris : /REDIRECTION, /CLIENT, /SERVER t /GLOBAL pour chaqu class d 300 à 600. Finalmnt, ls cods d'rrur sont organisés slon lur class, aux fuills d ctt hiérarchi. L cod 486 st ainsi associé à la fuill /ERROR/CLIENT/BUSY_HERE d ctt hiérarchi. L'nsmbl complt d la hiérarchi st donné n annx à la pag 149 t rprnd ls diérnts cods d'rrur dénis dans ls RFC rlativs au protocol SIP. 1 srvic sc_cpt_calls { 2 xtrn void log (int); 3 4 rgistration { 5 int cnt; 6 7 rspons outgoing REGISTER() { 8 cnt = 0; 9 rturn forward; 10 } void unrgistr() { 13 log (cnt); 14 } dialog { 17 rspons incoming INVITE() { 18 rspons r = forward; 19 if (r!= /SUCCESS) { 20 cnt++; 21 rturn forward sip:scrtary@xampl.com ; 22 } ls 23 rturn r; 24 } 25 } 26 } 27 } Fig. 7.1: Srvic comptur n SPL

94 72 SPL Sssions La structur hiérarchiqu ds sssions s rtrouv dans l'inclusion ds blocs d cod n SPL comm l'illustr notr xmpl. Nous pouvons ainsi constatr qu l bloc dialog, rgroupant ls événmnts d'un appl, st inclus dans l bloc rgistration. C drnir st lui-mêm inclus dans l bloc d méthods srvic. Ctt structur hiérarchiqu prnd tout son sns lorsqu l'on considèr l'ajout du comptur cnt déclaré à la lign 5. Ctt déclaration dénit un état associé à la sssion rgistration t à cs sous-sssions, c.-à-d. la sssion dialog. La déclaration st fait à l'xtériur d'un méthod événmntill. Sa porté st donc global au sin d la sssion t st disponibl durant l'intégralité d l'nrgistrmnt d l'utilisatur du srvic sur l résau SIP. L comptur st ainsi accssibl dpuis la méthod unrgistr (lign 13) mais égalmnt dpuis la méthod INVITE (lign 20) dans la sssion dialog. L'avantag d'un tll organisation du cod tint à la gstion automatiqu d l'état qu'll prmt. L'allocation mémoir ds variabls d'un sssion st ainsi réalisé lors du traitmnt d l'événmnt créant la sssion (par xmpl, REGISTER). La sauvgard t la rstauration d l'état ntr ls événmnts sont égalmnt assurés par l'nvironnmnt d'xécution du srvic. Enn, la mémoir put êtr rlâché d façon sûr après l'événmnt d n d sssion (par xmpl, la libération d l'allocation du comptur après l'xécution d la méthod unrgistr) En-têts Nuf n-têts sont obligatoirs dans au moins un typ d rquêt. Nous dénissons un motsclés pour chacun d'ux. L tablau 7.2 récapitul cs nuf mots-clés ainsi qu ls rquêts où ils puvnt êtr mployés. À l'xcption ds mots-clés CONTACT t MAX_FORWARDS, l'accès n'st possibl qu'n lctur. Mot-clés pour ls n-têts CALL_ID CONTACT CSEQ EVENT FROM MAX_FORWARDS SUBSCRIPTION_STATE TO VIA Rquêts où l'n-têt st obligatoir touts INVITE, SUBSCRIBE, NOTIFY touts SUBSCRIBE, NOTIFY, PUBLISH touts touts NOTIFY touts touts Tab. 7.2: En-têts accssibls par mots-clés L'xmpl d la gur 7.2 prmt à son utilisatur d n prndr qu ls appls provnant d sa fmm n vériant la valur d l'n-têt FROM (ligns 5 t 6). Sinon l'appl st rjté avc l cod BUSY_HERE (lign 13). Dans c cas, la présnc d'un n-têt précisant l sujt d l'appl st vérié (construction whn, lign 10). Si l sujt d l'appl st présnt, sa valur st accssibl via la variabl sub déclaré à la lign 10. Un nouvau sujt st construit n concaténant à la chaîn d caractèrs "[Missd Call]" l'évntul sujt actul (ligns 9

95 Dénition du langag 73 t 11). La répons rtourné st prsonnalisé avc un raison particulièr (lign 14), l'adrss d courrir élctroniqu d l'utilisatur (lign 15) t l sujt précédmmnt construit (lign 16). 1 srvic hadr_fild { 2 dialog { 3 rspons incoming INVITE() { 4 5 if (FROM == sip:wif@xampl.com ) { 6 rturn forward; 7 } 8 ls { 9 string obj = "[Missd Call]"; 10 whn this (subjct: string sub) { 11 obj += sub; 12 } 13 rturn /ERROR/CLIENT/BUSY_HERE 14 with { rason = "I m not availabl. Plas, lav m a mssag.", 15 contact: mailto:m@xampl.com, 16 subjct: obj 17 }; 18 } 19 } 20 } 21 } Fig. 7.2: Srvic d manipulation d'n-têts n SPL En plus d l'accès par mot-clé pour ls n-têts obligatoirs, SPL fournit ls constructions whn (lign 10) t with (lign 14) qui prmttnt d'accédr aux autrs n-têts rspctivmnt n lctur t écritur aussi bin pour ls rquêts qu pour ls réponss Uniform Rssourcs Idntir An d pouvoir raisonnr sur ls URI, clls-ci sont diérnciés ds chaîns d caractèrs par l'utilisation du caractèr n liu t plac du caractèr " qui délimit ls chaîns d caractèrs. L'xmpl précédnt (Figur 7.2) montr l'utilisation ds URI t ds chaîns d caractèrs (ligns 5, 9, 14 t 15). Ls URI sont ainsi clairmnt idntiés t lur analys st possibl statiqumnt État L langag SPL or dux mécanisms complémntairs pour facilitr la gstion d l'état. L prmir facilit la gstion d l'état au sin d'un méthod événmntill. L scond facilit la gstion d l'état ntr ls méthods. État intra-méthod L'opération d signalisation forward intrrompt l'xécution d la méthod n cours t émt la rquêt courant. L'état du srvic st alors sauvgardé. Il st rstauré lorsqu'un répons à la rquêt st rçu. La gur 7.3 illustr c comportmnt pour un appl ntrant t l traitmnt d la méthod INVITE. La récption d la rquêt déclnch l'xécution d la méthod corrspondant dans l srvic. L'opération forward intrrompt l'xécution, sauvgard l'état du srvic t transmt la rquêt vrs l dstinatair d l'appl. Lorsqu clui-ci répond, n décrochant ou n rfusant

96 74 SPL l'appl, sa répons rstaur l'état du srvic qui rprnd son xécution. L'opération rturn rnvoi nalmnt un répons à l'émttur d l'appl. INVITE INVITE Intrnt Intrnt forward rturn Fig. 7.3: Flot d contrôl intra-méthods État intr-méthod Un sssion rprésnt un cycl d vi. C cycl impos un crtain ordr ntr ls événmnts. Un ot d contrôl ntr ls événmnts st ainsi déni par l protocol. Dans l cas d'un appl, nous avons par xmpl la séqunc INVITE, ACK, BYE. Il st intérssant pour un dévloppur d ranr c ot d contrôl n fonction d'élémnts connus dynamiqumnt. Il st ainsi possibl d précisr un comportmnt particulir pour ls méthods qui suivnt la rquêt INVITE. An d simplir l ranmnt, SPL fournit la construction branch. Ell prmt d passr ds informations sur l ot d contrôl d'un méthod à la suivant. Ls branchs sont sélctionnés par l dévloppur à la n d'un méthod. L'nvironnmnt consrv alors l'information sur la branch sélctionné t l'associ à la sssion. Un branch particulièr, nommé dfault, st initialmnt sélctionné. Quand un méthod d'un sssion srvic ou nrgistrmnt st invoqué, l cod d la branch courant st xécuté ou clui d la branch par défaut si aucun branch déclaré n corrspond. La branch par défaut prmt alors un traitmnt commun à un ou plusiurs branchs. Ls sssions d'appls t d souscription sont traités d manièr similair, xcpté qu la nouvll branch hérit d la branch actull au liu d la rmplacr. Un pil prmt d mémorisr ls branchs hérités t d'ajoutr la nouvll branch. Lors d l'invocation d'un méthod, l cod corrspondant à la plus récnt branch dans la pil st xécuté. C mécanism st illustré à la gur 7.4 par l'xtrait d'un srvic. L'utilisatur st rsponsabl d'un scrétariat accssibl via l'uri sip:scrtary@xampl.com qui st un alias pour sa propr URI. Ls appls ntrants sont catégorisés comm étant dstinés au scrétariat (branch scrtary, lign 10), provnant d'un proch d l'utilisatur (branch privat, lign 14). Ls autrs appls n sont pas diérnciés t consrvnt la branch par défaut (lign 18). Ctt information contxtull st automatiqumnt associé à la sssion à la n d la méthod INVITE. Ell st rstauré lors d la récption d l'événmnt ACK (ligns 22 t 25). La branch par défaut st égalmnt xécuté si la branch st marqué comm privé car aucun traitmnt particulir n'st déclaré pour l typ d branch privat. Enn, lorsqu l'un ds intrlocuturs raccroch, l'un ds trois branchs st xécuté n fonction d la branch activ (ligns 28 à 30).

97 Dénition du langag 75 1 srvic branch_xampl { 2 [...] 3 dialog { 4 [...] 5 rspons incoming INVITE() { 6 rspons rsp = forward; 7 if (TO == sip:scrtary@xampl.com ) { 8 [...] 9 // Sssion taggd as "scrtary" 10 rturn rsp branch scrtary; 11 } ls if(from == [...]){ 12 [...] 13 // Sssion taggd as "privat" 14 rturn rsp branch privat; 15 } ls { 16 [...] 17 // Sssion kp its dfault tag 18 rturn rsp; 19 } 20 } 21 rspons incoming ACK() { 22 branch scrtary { // Spcific tratmnt for scrtary sssions 23 [...] 24 } 25 branch dfault {[...]} // Spcific tratmnt for privat and dfault sssions 26 } 27 rspons BYE() { 28 branch scrtary { [...] } 29 branch privat { [...] } 30 branch dfault { [...] } 31 } 32 } 33 } Fig. 7.4: Flot d contrôl intr-méthods Opérations d signalisation SPL fournit dux opérations d signalisation, un pour ls rquêts t un pour ls réponss. L'opération forward srt à rlayr ls rquêts. Un URI put êtr fourni à ct opératur an d modir l routag d la rquêt courant. Dans l cas d'un rdirction vrs plusiurs dstinatairs, un séqunc d'uri st fourni au liu d'un uniqu URI. L'nsmbl ds dstinatairs put êtr contacté soit l'un après l'autr, jusqu'à obtnir un répons positiv, soit simultanémnt. L modicatur paralll préx alors l'xprssion forward. Qulqu soit l'utilisation d l'opératur, il rtourn un uniqu répons nal, c'st-à-dir un répons dont l cod d rtour st supériur ou égal à 200. Dans l cas d'un rdirction vrs plusiurs utilisaturs, plusiurs réponss sont rtournés, l'un ds millurs st alors rtnu comm valur d l'xprssion forward. Un répons st millur qu'un autr si ll st plus précis ou qu'll prmt un progrès dans la communication. Un répons 501, indiquant qu'un fonction n'st pas implémnté sur un srvur, st par xmpl plus précis qu l'rrur 500, indiquant un rrur intrn au srvur. D mêm, un répons suggérant un rdirction, st millur qu'un répons avc un signal d'occupation car l srvur put utilisr la rdirction pour détrminr un nouvau dstinatair. Enn, un signal d'occupation st lui-mêm millur qu'un répons signalant un utilisatur inconnu ou un rrur intrn sur un srvur, car il suggèr d rapplr ultériurmnt. Si ls réponss sont équivalnts, l'un d'ntr lls st

98 76 SPL choisi d manièr non détrminist. La scond opération, rturn, consist à rtournr un répons vrs l'émttur d la rquêt initial. Ctt répons put soit provnir d'un précédnt forward, soit d'un répons nal constant déclaré dans l srvic. An d facilitr la production d répons d'rrur, l'nsmbl ds réponss possibls st fourni par l langag. Un dévloppur put ainsi navigur dans la hiérarchi ds cods d rtour d manièr symboliqu, par xmpl /ERROR/CLIENT/BUSY_HERE. Il st égalmnt possibl d'utilisr ctt hiérarchi d façon partill, par xmpl /ERROR/CLIENT/ ou mêm /ERROR. Un dévloppur put ainsi très facilmnt rtournr un rrur ou comparr un répons rçu avc un class d'rrur Opérations standards En plus ds opérations arithmétiqus t logiqus d bass, l langag SPL prmt d'invoqur ds méthods xtériurs aux srvics. Cs méthods doivnt avoir été préalablmnt chargés t êtr disponibls dans l'nvironnmnt d'xécution. Dans l'xmpl SPL d rdirction vrs la scrétair (Figur 7.1, pag 71), un modul d gstion d journal st chargé (lign 2). Il st invoqué par la suit (lign 13) an d'nrgistrr la valur du comptur. Nous pouvons notr l modicatur xtrn lors d la déclaration. C modicatur indiqu qu la méthod st xtériur au srvic Sémantiqu statiqu An d déclr ls srvics syntaxiqumnt corrcts mais sémantiqumnt faux, nous dénissons plusiurs analyss. Cs analyss s concntrnt sur la signalisation. Nous dénissons n conséqunc un syntax abstrait du langag SPL qui s concntr sur ls aspcts d signalisation. Ls opérations d signalisation n pouvant avoir liu qu dans ls méthods d'événmnts issus d rquêts SIP, la dénition d la syntax s limit à cs méthods t omt ls sssions. Suls ls déclarations d variabls d typ rspons sont égalmnt considérés. Nous applons ctt syntax abstrait SPL fwd (Figur 7.5). H ::= rspons DIR opt mthod_nam { D S } DIR opt := Non Som(DIR) DIR ::= incoming outgoing D ::= rspons x ; S ::= id = fwd URI opt rturn E R ɛ cond(e B, S 1, S 2 ) S 1 ; S 2 URI opt := Non Som(E URI ) E R ::= id /ERROR /SUCCESS E B ::= id == E R E URI ::= URI URI,... URI ::= constant Fig. 7.5: Syntax abstrait du langag SPL fwd Un programm SPL put dirctmnt êtr réécrit n son homologu SPL fwd. La gur 7.6

99 Dénition du langag 77 illustr ctt réécritur sur la méthod INVITE du srvic d rdirction vrs la scrétair n cas d non répons. D plus, nous supposrons qu ds tchniqus d transformations d programms tlls qu la propagation d copis t la propagation d constants [ASU86] sont appliqués an d'obtnir l programm SPL fwd. 1 rspons Som(incoming) INVITE { 2 rspons r; 3 r = fwd Non; 4 cond (r == /ERROR, 5 r = fwd Som( sip:scrtary@xampl.com ); rturn r, 6 rturn r) 7 } Fig. 7.6: Méthod INVITE du srvic comptur n SPL fwd Nous présntons tout d'abord l'analys vériant qu'un srvic st bin typé. Nous vrrons nsuit l'analys d l'opération forward prmttant d détctr ls srvics suscptibls d prdr un répons positiv émis lorsqu l'intrlocutur décroch Analys d typ Nous nous concntrons dans ctt sction sur ls opérations d signalisation. L'intégralité d la sémantiqu statiqu vériant ls typs d'un programm SPL st disponibl n annx B, pag 151. La gur 7.7 donn ls règls d typ pour l langag SPL fwd. Ls opérations d signalisation n puvnt êtr utilisés qu dans ls méthods événmntills. La règl 7.1 dénit la vérication d typ pour un tll méthod. L'évaluation ds déclarations puis d l'instruction doit produir un typ conform à clui d la méthod, c'st-à-dir d typ rspons 1. Ls règls 7.2 t 7.3 dénissnt ls règls d typ pour ls déclarations. La déclaration d'un nouvll variabl d typ rspons associ son idntiur au typ rspons dans l'nvironnmnt τ. Un fois l'nsmbl ds déclarations évalués, ls instructions d la méthod sont évalués vis à vis d l'nvironnmnt τ. La vérication ds instructions st décrit par ls règls 7.4 à 7.9. Sul l'instruction rturn produit un typ d rtour rspons. La règl 7.9 impos qu'il s'agiss d la drnièr instruction. Enn, la règl 7.8 impos qu ls dux branchs ds conditionnlls rtournnt un valur d mêm typ. Ainsi, si un branch rtourn un valur d typ répons, ctt règl garantit qu'un répons st égalmnt rtourné par l'autr branch. Ls règls 7.4 t 7.5 décrivnt l'opération d signalisation forward rspctivmnt sans argumnt t avc argumnt. Si un argumnt st présnt, il doit êtr d typ URI ou list d'uri (Règl 7.5). Dans ls dux cas, l'instruction produit un typ void t la variabl qui rçoit la valur du forward doit êtr déni dans l'nvironnmnt t êtr d typ rspons. Ls règls 7.10 à 7.13 prmttnt d vérir ls xprssions. Pour un variabl, son typ st consulté dans l'nvironnmnt τ (Règl 7.10). Ls constants produisnt lur typ rspctif (Règls 7.11, 7.13 t 7.14). Enn, l résultat d la comparaison d dux valurs st un boolén. D plus, ls dux valurs comparés doivnt êtr d typ idntiqu. Nous pouvons garantir qu tout programm rspctant l'nsmbl ds règls d la gur 7.7 produit un uniqu répons pour chacun ds méthods événmntills qu'il comport. D 1 à l'xcption d la rquêt ACK qui appartnant à la transaction initial a un typ d rtour void

100 78 SPL plus, suls ls xprssions d typ uri ou uri list puvnt êtr utilisés comm opérand d l'opération forward. D D : τ D τ D S S : rspons H rspons dir? mthod_nam { D S } : rspons (7.1) τ := τ[id rspons] τ D rspons id : τ (7.2) τ D D 1 : τ 1 τ 1 D D 2 : τ 2 τ D D 1 ; D 2 : τ 2 (7.3) τ(id) = rspons τ S id = fwd : void (7.4) τ E URI URI : uri uri list τ(id) = rspons τ S id = fwd URI : void (7.5) τ E R E R : rspons τ S rturn E R : rspons (7.6) τ S ɛ : void (7.7) τ E B E B : bool τ S S 1 : t 1 τ S S 2 : t 2 t 1 = t 2 τ S cond (E B, S 1, S 2 ) : t 1 (7.8) τ S S 1 : void τ S S 2 : t τ S S 1 ; S 2 : t (7.9) τ E R id : τ(id) (7.10) c {/SUCCESS, /ERROR} τ E R c : rspons (7.11) τ E R E R : t 1 τ E R id : t 2 t 1 = t 2 τ E B id == E R : bool (7.12) c { sip:do@xampl.com,...} τ E URI c : uri c { sip:do@xampl.com,...,...} τ E URI c : uri list (7.13) (7.14) Fig. 7.7: Vérication ds typs pour l langag SPL fwd Analys d l'opération forward Nous vnons d voir l'analys d typ d programms SPL. Cpndant, ctt analys, bin qu nécssair, n'st pas susant. Ell n garantit pas qu'un évntull répons positiv, rçu grâc à un forward, st bin rtransmis à l'applant. Nous présntons dans ctt sction un analys supplémntair prmttant d'intrdir un nouvll opération forward lorsqu'un précédnt a produit un répons positiv, c.-à-d. /SUCCESS. Ctt rstriction

101 Dénition du langag 79 prmt d'mpêchr un srvic d réalisr un rdirction d'appls vrs qulqu'un si un autr prsonn a déjà accpté l'appl. La règl 7.23 évalu un méthod t a la form suivant : H rspons dir? mthod_nam { D S } : P Ctt règl rtourn un valur P qui indiqu si la méthod évalué st valid vis à vis d la propriété qu nous considérons. Ctt valur dvint fauss aussitôt qu'un utilisation illégal d l'opération forward st détcté. Un règl d la form τ E R xp : σ (Règls 7.24 à 7.26) signi qu l'évaluation d l'xprssion xp dans l'nvironnmnt τ rtourn l statut σ. L statut σ a pour valur succss si l'xprssion st connu pour êtr un répons avc un cod d rtour d typ 2xx. σ a pour valur rror si l'xprssion st connu pour êtr un répons avc un cod d rtour supériur ou égal à 300. Enn, σ a pour valur si l cod d rtour d la répons n'st pas connu. Cs valurs d statut formnt un ordr partil tl qu succss t rror. Ct ordr partil srt lors d la fusion ds nvironnmnts réalisé à la règl La comparaison ntr dux réponss (Règl 7.27) rtourn un pair constitué d'un idntiur t d'un statut. Ctt comparaison prmt d détrminr si la répons décrit par l'idntiur st un succès ou un rrur. La découvrt d ctt information st nsuit propagé dans chacun ds branchs d la conditionnll (Règl 7.21). L point clé d ctt analys st dans l traitmnt du forward (Règls 7.17 t 7.18) t d la conditionnll. En t, la répons rçu par un opération forward doit êtr systématiqumnt sauvgardé dans un variabl. L'nvironnmnt τ modélis ainsi ls ts d l'nsmbl ds opérations forward qui ont u liu. Si ct nvironnmnt contint un variabl dont la valur st succss ou, alors un précédnt forward a ou put avoir réussi. Dans cs dux cas, un nouvll opération forward st prohibé t la propriété d l'analys prnd la valur fauss (Règl 7.17). Si touts ls variabls d l'nvironnmnt sont connus comm ayant la valur rror (Règl 7.18), nous avons l'assuranc qu'aucun précédnt forward n'a réussi t qu'un nouvau st possibl. Dans tous ls cas, l'nvironnmnt st mis à jour t la variabl id st associé à la valur, indiquant qu la nouvll valur d l'opération forward n'a pas ncor été tsté t qu'il put donc s'agir d'un succès. L tst d'un variabl st réalisé par la règl d la conditionnll (Règl 7.21) n coopération avc ls règls 7.24 à La branch S 1, corrspondant au thn, st analysé sachant qu l'nvironnmnt rèt l fait qu l tst était positif. La branch S 2, ls, st analysé sachant qu l tst était négatif. Dans c cas, l'nvironnmnt st construit avc l'opératur, dénit comm suit, succss = rror, rror = succss t =. L'évaluation ds branchs S 1 t S 2 conduit à dénir dux nouvaux nvironnmnt, τ 1 t τ 2. Comm chacun d'ux put êtr disponibl à l'xécution, l'analys ls fusionn pour évalur ls instructions suivants n utilisant l'opératur : τ τ τ, déni comm suit : τ 1 τ 2 = {(x, σ 1 σ 2 ) (x, σ 1 ) τ 1 (x, σ 2 ) τ 2 } Ct opératur garantit qu si la répons d'un forward n'st pas connu dans l'un ds dux branchs, ou possèd ds valurs diérnts dans chacun, alors la variabl corrspondant prnd la valur.

102 80 SPL τ := τ[id rror] τ D rspons id : τ (7.15) τ D D 1 : τ 1 τ 1 D D 2 : τ 2 τ D D 1 ; D 2 : τ 2 (7.16) (x, σ) τ. σ rror τ := τ[id ] τ S id = fwd URI? : τ, fals (7.17) (x, σ) τ. σ = rror τ := τ[id ] τ S id = fwd URI? : τ, tru (7.18) τ S rturn E R : τ, tru (7.19) τ S ɛ : τ, tru (7.20) τ E B E B : (id, σ) τ[id σ] S S 1 : τ 1, fwd 1 τ[id σ] S S 2 : τ 2, fwd 2 τ S cond (E B, S 1, S 2 ) : τ 1 τ 2, fwd 1 fwd 2 τ S S 1 : τ 1, fwd 1 τ 1 S S 2 : τ 2, fwd 2 τ S S 1 ; S 2 : τ 2, fwd 1 fwd 2 (7.21) (7.22) D D : τ D H rspons dir? τ D S S : τ, fwd mthod_nam { D S } : fwd (7.23) (id, σ) τ τ E R id : σ (7.24) τ E R /SUCCESS : succss (7.25) τ E R /ERROR : rror (7.26) τ E R E R : σ τ E B id == E R : (id, σ) (7.27) Fig. 7.8: Sémantiqu statiqu du langag SPL fwd Analys d l'xprssion constant /SUCCESS L'analys ds occurrncs d l'xprssion constant /SUCCESS prmt d garantir qu'un srvic d routag n fabriqu pas d répons d succès. Ctt propriété st important pour garantir la cohérnc d l'état ds périphériqus utilisaturs. L'occurrnc d ctt constant st résrvé à l'xprssion ds conditionnlls. Ctt constant n put pas srvir à dénir un variabl d typ répons t n'st pas un valur d rtour valid pour l'instruction rturn Sémantiqu dynamiqu Nous vnons d donnr ds analyss prmttant d garantir qu'un répons st bin produit pour chaqu rquêt SIP rçu t qu'aucun nouvll opération forward n'st réalisabl lorsqu'un répons ayant, ou pouvant avoir, un cod d rtour d typ 2xx st déjà n cours d traitmnt dans la méthod. Cs analyss sont réalisés statiqumnt, c'st-à-dir avant l'xécution, an qu suls ls srvics valids puissnt êtr déployés dans l'nvironnmnt d'xécution. Nous allons à présnt spécir l comportmnt ds srvics à l'aid d'un sémantiqu dynamiqu. Cll-ci prmttra d documntr l langag t d dénir ds outils pour l'xécution d srvics. La présntation d la sémantiqu dynamiqu s limitra aux aspcts

103 Dénition du langag 81 rlatifs aux sssions hiérarchiqus t à la signalisation dans ls méthods ; l'intégralité d la sémantiqu dynamiqu st disponibl n annx (Sction B.3 t suivants, pag 155). Il st important d notr qu ctt sction st indépndant d la précédnt t qu crtains noms d variabl comm σ ou τ sont réutilisés sans lin avc la sction précédnt Sssions Nous avons vu qu SPL st conçu autour d la notion d sssions organisés d manièr hiérarchiqu. Un sssion comprnd un nsmbl d variabls, c.-à-d. un état, t ds méthods (Sctions , t ). An d'idntir d manièr uniqu un sssion, chacun st associé à un uniqu labl. Pour décrir la position d'un sssion dans la hiérarchi, un adrss st égalmnt associé à un sssion. L'adrss d'un sssion st formé par la séqunc ds labls d la sssion t ds sssions parnts. L'état d'un sssion st stocké dans un état global σ. Ct état global associ à un adrss d sssion un tupl contnant la branch activ, qui st rprésnté par un list d'idntiurs, l statut d la sssion, l'nvironnmnt d la sssion qui associ ls variabls d'un sssion à lur valur, t la list ds adrsss ds sous-sssions : σ stat = addrss branch list status nv addrss list L statut d'un sssion, d typ status, st composé d quatr informations : liv, prsistnt, clos_fn t opn. liv st un marquur boolén indiquant qu la sssion st activ lorsqu l marquur st vrai. prsistnt st un marquur boolén indiquant la prsistanc d la sssion. Il put êtr non initialisé t alors avoir la valur. clos_fn st l nom d la méthod à invoqur lors d la frmtur d'un sssion. La valur dénot l'absnc d'un tll méthod. opn st un ntir qui indiqu l nombr d transactions n cours au nivau d la sssion courant. status = bool bool string int La sémantiqu d SPL utilis un nsmbl d fonctions qui manipulnt ls sssions : crat_sssion, prpar_mthod_invocation, continu_sssion, t nd_sssion. La fonction crat_sssion étnd l'état global σ avc un ntré pour un nouvll sssion. Ctt fonction a la signatur suivant : crat_sssion : program stat addrss mthod_nam stat Lors d la création d'un sssion, l statut initial d la sssion st déni comm suit : liv a la valur vrai, prsistnt la valur t opn la valur zéro. La list ds sous-sssions st initialisé à un list vid. La valur clos_fn t la valur d la branch activ dépndnt du typ d sssion. Ls valurs sont indiqués au tablau 7.3. L'nvironnmnt d sssion st initialisé avc l'évaluation ds déclarations rlativs à la sssion. Finalmnt, la fonction crat_sssion rtourn un nouvl nvironnmnt global qui contint la nouvll sssion. Un fois la nouvll sssion créé, ls méthods d la sssion puvnt êtr invoqués. L'invocation st initialisé par la fonction prpar_mthod_invocation du typ : prpar_mthod_invocation : program stat addrss mthod_nam dirction dcl list stmt nv list stat

104 82 SPL Typ d sssion Fonction nal Branchs srvic undploy dfault rgistration unrgistr dfault dialog uninvit list hérité vnt unsubscrib list hérité Tab. 7.3: Conguration d'un sssion n fonction d son typ Ctt fonction xtrait ls déclarations t ls instructions associés à la méthod, récupèr l'nsmbl ds nvironnmnts dont hérit la sssion t incrémnt l comptur opn pour indiqur qu'un transaction st n cours. La lists ds déclarations, ls instructions, l'nvironnmnt d la sssion t un nouvl état global sont alors rtournés. L'nvironnmnt d la sssion st formé d'un séqunc d'nvironnmnts. Chacun d'ux corrspond à un nivau dans la hiérarchi ds sssions. L'xécution ds instructions manipul la séqunc ds nvironnmnts d sssion précédmmnt obtnu. Lorsqu l'xécution s trmin, cs nvironnmnts doivnt êtr mis à jour dans l'nvironnmnt global σ. Ctt opération st dévolu à la fonction continu_sssion ayant l typ suivant : continu_sssion : program stat addrss nv list stat L comportmnt d ctt fonction dépnd d l'état du marquur liv d la sssion. Si la sssion st activ, σ st mis à jour avc ls nouvaux nvironnmnts produits par l'xécution d la méthod, t l comptur opn st diminué d'un transaction activ. Si la sssion n'st plus activ, la fonction nd_sssion st invoqué t détrmin si la sssion doit êtr détruit n fonction du statut d la sssion. La fonction s trmin n rtournant un nouvl état σ du systèm. nd_sssion : program stat addrss stat L partag d l'état, ntr ls méthods t ls sssions, impos un gstion automatiqu d ct état. La trminaison d'un sssion st un phas important t délicat d ctt gstion. La trminaison d'un sssion put avoir liu pour plusiurs raisons : un trminaison normal (par xmpl, un intrlocutur raccroch), la création a échoué (par xmpl, prsonn n'a répondu à l'appl) ou un alarm protocolair invoqu la méthod d clôtur d sssion (par xmpl, un rrur résau st survnu). Néanmoins, il n'st pas toujours désirabl d détruir un sssion immédiatmnt. Il st par xmpl nécssair d'attndr qu ls méthods n cours ou ls sous-sssions activs rçoivnt un répons t s trminnt. Un sssion n'st donc détruit qu si son comptur opn st nul t qu'il n'y a donc aucun méthod n attnt d'un répons. La hiérarchi ds sssions impos égalmnt un gstion particulièr lors d la clôtur ds sssions. Du point d vu du protocol SIP, un sssion put êtr trminé mais, du point d vu du langag SPL, son état doit parfois prsistr. C'st notammnt l cas d'un sssion nrgistrmnt qui put xpirr à la dmand d l'utilisatur ou lorsqu l'alarm corrspondant xpir. Dans c cas, il n'st pourtant pas nécssair d clor ls sous-sssions dialog t vnt évntullmnt activs. La sssion rgistration doit alors êtr prsistant an qu ls variabls associés puissnt êtr référncés par ls sous-sssions. L marquur prsistnt indiqu alors si un sssion doit attndr la n ds sssions lls ou si cs drnièrs doivnt

105 Dénition du langag 83 êtr closs immédiatmnt, n mêm tmps qu la sssion courant. La méthod unrgistr st ainsi prsistant an qu ls dialogus n cours puissnt s trminr normalmnt alors qu la méthod undploy st non-prsistant an qu l'administratur d'un systèm puiss étindr un srvur sans délai. La gstion automatiqu ds sssions par l langag prmt libérr d manièr systématiqu ls allocations mémoirs liés à un sssion particulièr lorsqu la sssion st clos. D plus, la structur hiérarchiqu ds sssions t la notion d prsistanc prmttnt au systèm d libérr égalmnt l'état ds évntulls sous-sssions. L'état alloué st ainsi minimal à tout instant d l'xécution ds srvics Opérations d signalisation Nous vnons d voir la sémantiqu dynamiqu pour ls sssions hiérarchiqus dans SPL. Nous allons à présnt voir un scond concpt clé du langag, la sémantiqu dynamiqu ds opérations d signalisation. Nous vrrons tout d'abord l'invocation d méthods lors d la récption d'un rquêt puis l'opération forward qui rlai ls rquêts t rtourn la répons nal corrspondant. Invocation d méthods La sémantiqu ds trms d SPL st décrit à l'aid d'un machin abstrait fondé sur ls continuations [ADM05]. L'xécution d ctt machin st spécié comm un séqunc d congurations. La prmièr d cs congurations corrspond à la récption d'un rquêt SIP. La drnièr corrspond à l'émission d'un répons du srvic vrs la machin virtull SIP. Ls congurations intrmédiairs rprésntnt l'xécution d'un trm du langag ou d'un continuation. Un continuation st similair à la pil d contrôl utilisé dans l'implémntation ds langags impératifs. A chaqu évaluation d'un trm par la sémantiqu, un tâch st ajouté à la continuation courant. Ctt tâch contint tous ls élémnts nécssairs pour trminr l'xécution du trm courant. Ctt approch rnd chaqu continuation autonom t st xploité lors d la sémantiqu du trm forward. Ls congurations décrivnt un sémantiqu à ptit pas d l'invocation d'un méthod. Il xist quatr typs d congurations : l'invocation d méthods, l'évaluation du corps d'un méthod, la continuation d'un méthod, c.-à-d. après un opération forward, t l rtour d'un méthod. Invocation d'un méthod : mssag, φ, σ = mi srvic Évaluation du corps d'un méthod : σ, addrss, nvs, s = h dcls, stmt Continuation d'un méthod : σ, addrss, nvs, uri, local_nv = mc s, rsp Rtour d'un méthod vrs la machin virtull SIP : valu, σ L'évaluation d'un trm par un règl sémantiqu réécrit la conguration courant t n produit un nouvll. Ctt réécritur consist ssntillmnt à mpilr t dépilr ds tâchs sur la pil d contrôl, c'st-à-dir modir la continuation. Nous illustrons ici l'invocation d la méthod INVITE qui cré un nouvll sssion dialog. L traitmnt ds autrs méthods st similair. La règl 7.28 initialis l'invocation d la méthod INVITE. Après avoir récupéré la branch activ dans la sssion parnt, un nouvll sssion st créé dans l'nvironnmnt global σ ; puis, l'xécution ds déclarations t ds instructions st préparé par la méthod prpar_mthod_invocation. La règl produit alors un nouvll conguration prmttant l'xécution ds déclarations t ds instructions pour la branch activ. La continuation st alors

106 84 SPL armé avc la tâch INITIAL_INVITE. addrss = srvic, rid, did lookup_branchs(σ, parnt(addrss)) = branch crat_sssion(φ, σ, addrss, branch, undialog) = σ prpar_mthod_invocation(φ, σ, dirction, INVITE) = µ µ = m, dcls, stmt, nvs, σ τ = σ, addrss r = nvs, m, rq, hadrs INVITE(rid, did), dirction, rq, hadrs, φ, σ = mi srvic τ, r, INITIAL_INVITE φ = h dcls, stmt (7.28) Après avoir xécuté ls instructions du corps d la méthod, la continuation rvint dans la conguration où la tâch INITIAL_INVITE doit êtr xécuté. Ls règls 7.29 t 7.30 décrivnt rspctivmnt l'xécution d la continuation slon qu la méthod rtourn un répons avc un succès, rspctivmnt un rrur. Dans l prmir cas, sul l'état global st mis à jour avc l nouvl nvironnmnt t la nouvll branch. En cas d'rrur, la prsistanc d la sssion st initialisé an d clor la sssion. Dans c cas, la prsistanc prnd la valur fauss t la sssion sra immédiatmnt détruit lors d l'appl à la fonction nd_sssion réalisé par la fonction continu_sssion. lookup_branchs(σ, addrss) = branchs continu_sssion(φ, σ, addrss, ρ nvs, add(b, branchs)) = σ σ, addrss, ρ = mc INITIAL_INVITE φ, /SUCCESS/rsp(rsp_hadrs), b (7.29) /SUCCESS/rsp(rsp_hadrs), σ st_prsistnc(σ, addrss, fals) = σ lookup_branchs(σ, addrss) = branchs continu_sssion(φ, σ, addrss, ρ nvs, add(b, branchs)) = σ σ, addrss, ρ = mc INITIAL_INVITE φ, /ERROR/rsp(rsp_hadrs), b (7.30) /ERROR/rsp(rsp_hadrs), σ Ls invocations ds méthods intrmédiairs t trminals sont similairs xcpté l fait qu'lls n'invoqunt pas la fonction crat_sssion. À la n d'un méthod intrmédiair, la sssion continu systématiqumnt t la règl d continuation st donc similair à la règl n cas d succès (Règl 7.29). À la n d'un méthod trminal, la sssion st systématiqumnt clos, la règl d continuation st donc similair à la règl n cas d'rrur (Règl 7.30). Il st à notr qu la prsistanc st toujours fauss pour ls méthods initials. Ell vari cpndant n fonction d la méthod nal invoqué. L troisièm argumnt d la fonction st_prsistnc st ajusté n conséqunc slon l tablau 7.4. Exprssions forward L'évaluation d'un xprssion forward provoqu l'arrêt momntané du srvic SPL n cours d'xécution t l rtour du contrôl vrs la machin virtull SIP sous-jacnt, qui rlay alors la rquêt sur l résau avant d traitr ls autrs rquêts ntrants. Quand la répons arriv, la machin virtull rstaur l contxt du srvic ayant réalisé l'opération forward. Ctt rlation d co-routinag [HFW84] ntr ls srvics SPL t la machin virtull SIP nécssit qu l'opération forward fourniss susammnt d contxt à la machin virtull pour qu l'xécution d la méthod puiss rprndr t nir son

107 Dénition du langag 85 Méthod méthods initials undploy unrgistr uninvit unsubscrib Prsistanc non non variabl (n fonction d l'administratur) oui n cas d'xpiration d l'alarm non non Tab. 7.4: Valur d la prsistanc n fonction d la trminaison d sssion xécution. Nous mployons pour cla un stratégi standard d co-routinag avc passag d continuation. La sémantiqu d l'opération forward st déni par ls trois congurations suivants : Exprssions : σ, addrss, nvs, uri, local_nv, s = xp Continuation ds xprssions : σ, addrss, nvs, uri, local_nv = c s, valu Appl d la machin virtull SIP : forward(valu, bool, s, hadrs, σ) Rtour d la machin virtull SIP : forward_rspons(valu, s, σ) La règl 7.31 commnc par évalur l'évntull xprssion fourni n argumnt du forward, c'st-à-dir un URI pour réalisr un rdirction. Un fois l'xprssion calculé, l srvic s'intrrompt t donn l contrôl à la machin virtull (Règl 7.32). Si aucun rdirction n'st dmandé, l srvic s'intrrompt immédiatmnt t rnd l contrôl à la machin virtull (Règl 7.33). Lorsqu'un répons st rçu par la machin virtull, ctt drnièr rstaur l contxt t l srvic comm l décrit la règl L'xécution rprnd n dépilant la continuation. Dans l cas d'un rdirction n parallèl, c.-à-d. paralll forward, l scond argumnt d la fonction forward prnd la valur vrai. τ, ρ, s = forward xp τ, ρ, FORWARD_EXP :: s = xp (7.31) updat_nvs(σ, addrss, ρ nvs ) = σ ρ msg_info = m, rq, hadrs σ, addrss, ρ = c FORWARD_EXP :: s, v forward(v, fals, (FORWARD addrss ρ msg_info ρ local_nv ) :: s, hadrs, σ ) (7.32) updat_nvs(σ, addrss, ρ nvs ) = σ ρ msg_info = m, rq, hadrs σ, addrss, ρ, s = forward forward(rq, fals, (FORWARD addrss ρ msg_info ρ local_nv ) :: s, hadrs, σ ) (7.33) lookup_nvs(σ, addrss) = nvs τ = σ, addrss ρ = nvs, msg_info, local_nv forward_rspons(rsp, (FORWARD addrss msg_info local_nv) :: s, σ) τ, ρ = c s, rsp (7.34)

108 86 SPL 7.3 Bilan Nous avons présnté dans c chapitr un langag dédié, nommé SPL, pour spécir ds srvics d routag d mssags ntr ds srvics d communications. C langag st statiqumnt typé t possèd ds abstractions spéciqus aux srvics d routag pour ds communications fondés sur SIP. Nous rtindrons comm abstractions ls sssions hiérarchiqus t ls opérations d signalisation. Cs abstractions xplicitnt l comportmnt d'un srvic t fournissnt ds opportunités pour optimisr la gstion d l'état automatiqumnt t vérir la cohérnc du srvic vis à vis du protocol d communications SIP sous-jacnt. Nous avons présnté n détail dux analyss statiqus : l'un vériant la cohérnc d typ dans un srvic t garantissant ntr autrs qu'un répons uniqu st toujours rtourné (Sction ), t l'autr vériant la bonn utilisation d l'opération d signalisation forward (Sction ). Nous avons égalmnt présnté la sémantiqu dynamiqu ds constructions principals du langag (Sction 7.2.3). Nous pouvons désormais, à l'aid d la sémantiqu d SPL, n réalisr un implémntation.

109 Chapitr 8 Mis n uvr d SPL Dans c chapitr nous décrivons notr implémntation du langag SPL [BCL + 06a, PCRL07] ainsi qu'un xmpl d srvic SPL xploitant ls fonctionnalités du langag. Nous précisons dans un prmir tmps l domain d notr étud dénissant ls hypothèss d l'implémntation. Dans un scond tmps, nous décrivons l procssus global d dévloppmnt ds srvics SPL. Enn, la présntation d la chaîn d compilation détaill chaqu phas d c procssus. Nous concluons par l'xplication d'un srvic SPL ayant srvi à la validation du procssus t d son implémntation. 8.1 Domain d l'étud La mis n uvr qu nous présntons dans c chapitr s limit à un sul pil protocolair SIP : l'implémntation d référnc d l'intrfac d programmation JAIN SIP. La couch logicill prmttant d fair l lin ntr l protocol SIP t l langag st par conséqunt fondé sur l langag Java. Ctt couch logicill constitu un machin virtull. Dans notr étud, nous avons dévloppé un prmir intrprèt, n O'Caml [Lr97], qu nous avons xpérimnté sur diérnts plat-forms : Windows, Linux t Mac. Ct intrprèt fonctionn n co-routinag avc la machin virtull SIP. Un fois notr approch ainsi validé, nous avons fait évolur ct intrprèt vrs un implémntation Java an d'obtnir un implémntation plus homogèn. Ls diérnts élémnts présntés dans c chapitr n sont cpndant pas spéciqus aux langags Java t O'Caml t puvnt êtr implémntés à l'aid d'autrs langags d programmation généralists. Ainsi, il smbl raisonnabl d ciblr ds langags d programmation tls qu C, C++ ou C#. Bin qu'un tll implémntation puiss s'avérr moins aisé n C, ds gains d prformanc n tmps d'xécution puvnt êtr scomptés. 8.2 Procssus d dévloppmnt La gur 8.1 illustr l procssus d dévloppmnt d'un srvic d routag fondé sur SPL. Dans un prmir tmps, un srvic st dévloppé par un programmur n SPL. Un phas d vérications st nsuit ctué pour déclr d'évntulls incohérncs vis à vis ds contraints du protocol SIP t d la pil sous-jacnt. Ctt phas d vérications trminé, un génératur d cod st xécuté t produit un rprésntation adapté à un intrprèt. L'intrprétation ds srvics st déclnché par ls événmnts qu produit la machin virtull. Lors 87

110 88 Mis n uvr d SPL d l'intrprétation, ls opérations d signalisation fournis par la machin virtull sont invoqués par l'intrprèt. La machin virtull t un intrprèt du langag SPL constitunt un srvur d'applications pour ls srvics d routag. C srvur d'applications or un consol d'administration prmttant d'installr t d déployr ds srvics pour ls utilisaturs d la plat-form d communications. Srvic SPL Compilatur Analysur Génération d cod objt O Caml Génération d cod XML Intrprèt O Caml XML-RPC Machin virtull Pil SIP Intrprèt Java Gstionnair d srvics Srvur d applications Fig. 8.1: Procssus d dévloppmnt d srvics d routag n SPL 8.3 Chaîn d compilation La chaîn d compilation du langag SPL s compos d trois élémnts. Tout d'abord un analysur véri la validité ds srvics vis à vis d propriétés pouvant êtr détrminés statiqumnt. Dux génératurs d cod produisnt nsuit au choix un rprésntation binair ou un rprésntation XML du srvic. Clls-ci sont dstinés rspctivmnt à l'intrprèt O'- Caml t l'intrprèt Java. Cs dux intrprèts coopèrnt avc la machin virtull SIP, dédié à SPL. Ctt machin virtull, associé à l'un ds intrprèts, form un srvur d'applications SIP pour ds srvics SPL Analysur L'analysur d srvic SPL s décompos n plusiurs partis totalisant plus d ligns d cod O'Caml : d'un part un analysur lxical t syntaxiqu standard, d'autr part ds analysurs spéciqus aux propriétés ds srvics d routag rposant sur l protocol SIP. Cs

111 Chaîn d compilation 89 analysurs spéciqus rprésntnt nviron 800 ligns d cod dont plus d 600 pour l'analys d typ. L'analys d typ prmt d garantir d nombruss propriétés du domain. Ell prmt d garantir, par xmpl, la bonn utilisation ds n-têts ds mssags SIP ou qu'un répons st toujours rtourné suit à un rquêt. Ell garantit égalmnt qu'un rdirction a toujours liu vrs un URI bin formé Génératurs d cod t intrprèts L'nvironnmnt d'xécution ds srvics SPL rpos sur dux intrprèts (O'Caml t Java). Ils sont tous dux issus d'un implémntation dirct d la sémantiqu dynamiqu. Ctt sémantiqu a n outr prmis un dévloppmnt rapid ds intrprèts n rspctivmnt 1 t 2 smains, comm l'indiqu l tablau 8.1. Cs dux implémntations intrprètnt un rprésntation adapté ds srvics. L'implémntation O'Caml fonctionn grâc à un rprésntation sérialisé d'objts O'Caml tandis qu l'implémntation Java import un rprésntation XML sous form d'objts Java. Dux génératurs d cod prmttnt d réécrir ls srvics validés par l'analysur dans l'un ou l'autr ds rprésntations. O'Caml Java Tmps d dévloppmnt 1 smain 2 smains Nb. d ligns Nb. d mots Nb. d fonctions/méthods Nb. d moduls/classs 6 45 Tab. 8.1: Comparaison ds implémntations O'Caml t Java Machin virtull Chacun ds implémntations d l'intrprèt coopèr avc un machin virtull SIP dédié à SPL (SIP VM)[BCL + 06b]. La SIP VM a n charg d fournir, pour l'nsmbl ds srvics SPL, ls abstractions d srvics t d sssions ainsi qu la gstion d l'état. D plus, ctt machin virtull doit orir un architctur ouvrt t xibl prmttant aux srvics d'intragir avc ds rssourcs xtériurs via ls moduls SPL. An d répondr à cs bsoins, nous avons dévloppé plusiurs composants logicils : un gstionnair d srvics, un modératur d srvics, un couch d'abstraction du protocol, un couch d'abstraction ds srvics t un nvironnmnt d'xécution ouvrt. L'architctur d cs composants st rprésnté n Figur 8.2. Gstionnair d srvics L gstionnair d srvics fournit un intrfac pour contrôlr l cycl d vi ds srvics. Ls srvics sont stockés dans un dépôt local sous lur form xécutabl précédmmnt généré. Cs opérations sont gérés à l'aid d'un consol d'administration à distanc. Un fois installés, ls srvics puvnt êtr activés pour un utilisatur ou un group d'utilisaturs. Lors d l'activation d'un srvic, un événmnt d déploimnt st

112 90 Mis n uvr d SPL Fig. 8.2: Architctur du srvur d'applications généré par l gstionnair d srvics. Ls utilisaturs ainsi qu ls groups sont égalmnt administrés via la consol d'administration. Couch d'abstraction ds srvics Lorsqu'un srvic st activé via l gstionnair d srvics, un événmnt dploy st émis vrs l'nvironnmnt d'xécution. La méthod corrspondant du srvic st alors évalué par l'intrprèt. D manièr similair, quand un srvic st désactivé, un événmnt undploy st émis. Bin qu cs événmnts soint générés par la plat-form t non pas issus d'un événmnt protocolair SIP, l'nvironnmnt d'xécution prmt d ls traitr uniformémnt au nivau ds srvics SPL. Enn, ctt couch d'abstraction st rsponsabl d la gstion d l'état ds srvics lors ds phass d sauvgard t d rstauration qui ont liu ntr ls événmnts. Modératur automatiqu Lorsqu'un mssag SIP st rçu par la pil protocolair, cll-ci transmt l mssag au modératur. L modératur analys alors l mssag SIP t détrmin l'nsmbl ds srvics dvant êtr xécutés pour un utilisatur donné. Ct nsmbl d srvics form un list ordonné qui st réévalué après chaqu xécution d'un srvic. En t, un rdirction put avoir u liu. Il n'st alors plus nécssair d'xécutr ls srvics rstant pour ct utilisatur. Couch d'abstraction du protocol L rôl d ctt couch st d réalisr l ranmnt ds événmnts protocolairs n événmnts SPL organisés slon l cycl d vi d la sssion à laqull ils s rapportnt. Ls rquêts sont ainsi analysés pour détrminr s'il s'agit d la création d'un sssion, d'un opération intrmédiair ou d la trminaison d'un sssion. L ranmnt ds événmnts opéré par ctt couch d'abstraction prnd égalmnt n compt ls alarms protocolairs ayant pu xpirr. Environnmnt d'xécution L'nvironnmnt d'xécution réagit aux événmnts produits par ls couchs d'abstraction. Il fournit ainsi aux srvics un vu haut nivau t unié ds événmnts. L'nvironnmnt d'xécution organis d manièr hiérarchiqu ls sssions fournis par ls dux couchs d'abstraction sous-jacnts t facilit d fait la gstion d l'état au nivau ds srvics. Moduls Ls moduls prmttnt d'étndr ls fonctionnalités qu'or l srvur d'application aux srvics SPL. Il s'agit d'un approch standard déjà xploité dans c but par d'autrs

113 Dévloppmnt d srvics 91 srvurs tls qu Apach[Apa] ou OpnSr[Opa]. Dans l cas ds srvics d communications, chaqu srvic Intrnt st potntillmnt un rssourc t put êtr xploité par un srvic d routag. Il st ainsi possibl d dévloppr ds moduls prmttant d'accédr à ds srvics locaux (par xmpl, systèm d chirs ou dat t hur du systèm) ou ds srvics distants (par xmpl, srvics Wb, bass d donnés, agndas partagés ou srvur d conférncs). An d validr notr approch, nous avons dévloppé divrs moduls pour, par xmpl, la gstion d'un journal, la manipulation d'un carnt d'adrsss ou l contrôl d'un rssourc multimédia (CRM). L modul CRM a ntr autr été mis n uvr lors du dévloppmnt d'un srvic d l d'attnt téléphoniqu. 8.4 Dévloppmnt d srvics Un srvic d l d'attnt (Annx C) a été dévloppé an d validr l langag t son implémntation. C srvic consist n nviron 200 ligns d SPL t prmt la mis n rlation avc un scrétariat. Un l d'attnt st déni pour quatr prsonns pndant qu'un cinquièm st n rlation avc l scrétariat. Ls appls ntrants sont tous routés vrs un agnt SIP fournissant ds fonctionnalités multimédia. Ct agnt st piloté grâc au modul CRM t or ds fonctionnalités d pont audio, similairs à un srvur d conférnc, t d lctur d mssags pré-nrgistrés. Si un prsonn appll l scrétariat t qu clui-ci st disponibl, ls intrlocuturs sont mis n rlation (prmir cas n haut à gauch, Figur 8.3). Ls prsonns arrivant par la suit rstnt n attnt. L'agnt lur annonc n boucl lur rang dans la l (autrs cas, Figur 8.3). Lorsqu l'un ds intrlocuturs raccroch, la prsonn suivant dans la l st mis n rlation avc l scrétariat désormais disponibl. Ls autrs prsonns dans la l sont alors notiés d lur nouvau rang. Si la l st plin, ls appls supplémntairs sont rjtés n indiquant d rapplr ultériurmnt. Scrétair Communication ntr l srvic SPL t l agnt multimédia via l modul CRM Utilisaturs Agnt multimédia Fig. 8.3: Princip du srvic d l d'attnt C srvic mt n uvr plusiurs fonctionnalités du langag dont ls sssions hiérarchiqus, ls opérations d signalisation t l'accès aux n-têts. Il nécssit pas moins d 6