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 [email protected] via ds courrirs nvoyés à l'adrss [email protected]. 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 [email protected]. 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:[email protected] SIP/2.0 2 Via: SIP/2.0/UDP alicpc.inria.fr;branch=z9hg4bk776asdhds 3 Max-Forwards: 70 4 To: Bob <sip:[email protected]> 5 From: Alic <sip:[email protected]>;tag= Call-ID: a84b4c @alicpc.inria.fr 7 CSq: INVITE 8 Contact: <sip:[email protected]> 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:[email protected]>;tag=a6c85cf 6 From: Alic <sip:[email protected]>;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:[email protected] sip:[email protected] sip:[email protected] 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:[email protected] 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:[email protected] 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:[email protected]. 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:[email protected]" 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:[email protected]"> 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:[email protected]"/> 8 </transition> 9 10 <transition stat="init" vnt=connction.rdirct.faild> 11 <rdirct dst="sip:[email protected]"/> 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:[email protected]"; 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):[email protected]")) { 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:[email protected]"); 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:[email protected] ; 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:[email protected] ) { 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:[email protected], 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:[email protected] 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:[email protected] ) { 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:[email protected] ); 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:[email protected],...} τ E URI c : uri c { sip:[email protected],...,...} τ 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

114 92 Mis n uvr d SPL méthods d la sssion dialog ainsi qu plusiurs moduls xtrns. Enn, ds fonctions intrns ont égalmnt été miss n uvr. La concision du programm t l'utilisation d l'analysur ont prmis d validr rapidmnt un vrsion du srvic, sans rrur, avant son déploimnt sur l srvur d'applications. La concision du programm prmt nn d facilmnt dévloppr ds nouvaux srvics d l d'attnt avc plus d prsonns ou ds mssags d'attnt diérnts. 8.5 Bilan Nous avons décrit dans c chapitr l procssus d dévloppmnt d srvics d routag fondé sur l'approch SPL. C chapitr prmt d s familiarisr avc la chaîn d compilation. Il présnt égalmnt l'architctur logicill d'un srvur d'applications pour ds srvics SPL. Ls diérnts outils logicils mis n uvr durant l procssus d dévloppmnt ont été validés par l'xécution d'un srvic SPL d'nviron 200 ligns gérant la signalisation d'un systèm d l d'attnt t xploitant ls divrss fonctionnalités du langag. C srvic rlativmnt complx n trm d fonctionnalités s'écrit simplmnt t d manièr concis n SPL. Ctt concision t l'utilisation d l'analysur ont prmis d'obtnir t validr rapidmnt l srvic. Sa concision prmt aisémnt t rapidmnt d dévloppr ds variants.

115 Chapitr 9 Pantaxou Nous avons présnté dans ls dux chapitrs précédnts l langag SPL, dédié au dévloppmnt ds srvics d routag. Nous allons maintnant décrir l langag Pantaxou, dédié au dévloppmnt d srvics ntités. Ls srvics ntités sont ds ntités communicants. Contrairmnt aux srvics d routag qui n font qu traitr ds communications n cours, ls srvics ntités puvnt égalmnt initir ds communications vrs d'autrs ntités communicants. Après un rappl ds élémnts constituant l domain ds srvics ntités, nous dénissons dans c chapitr l langag Pantaxou. À l'instar du langag SPL, la dénition du langag Pantaxou s compos d'un syntax, d'un sémantiqu statiqu t d'un sémantiqu dynamiqu. 9.1 Analys du domain Nous appliquons la mêm démarch pour l'analys d domain qu cll suivi lors d la concption du langag SPL. Après avoir précisé nos sourcs d'information, nous présntons dans ctt sction ls points communs t ls variations qui xistnt ntr diérnts srvics ntités. Nous complétons l'analys d domain par un cahir ds chargs pour l dévloppmnt ds srvics ntités Sourcs d'information L'analys d domain ds srvics ntités rprnd ls sourcs d'information xploités lors d la concption du langag SPL tlls qu ls srvics fondés sur ls approchs xistants t ls RFC rlativs à SIP. Nous protons égalmnt d l'xpérinc acquis lors d la concption d SPL Points communs Ls srvics d communications qu l'on considèr sont ds intrvnants dans ls communications ; nous parlrons d'ntités communicants ou d srvics ntités. Pour classir ls communications ntr ls ntités, nous dénissons trois taxonomis : un pour ls ntités, un pour ls mods d communications t un pour ls typs d donnés échangés. Entités communicants Dans l chapitr 2, nous avons vu qulqus xmpls d srvics ntités tls qu ds caméras, ds téléphons, ds écrans t ds capturs d présnc ou d 93

116 94 Pantaxou tmpératur. Tous ls srvics avc un capacité d communication puvnt êtr considérés. Nous parlrons d fonctionnalité pour caractérisr ls capacités d communication d'un srvic. Il st facil d'imaginr un pléthor d srvics ntités. Cs srvics sont caractérisés par dux attributs : ds propriétés t ds fonctionnalités. Ls propriétés caractérisnt ls srvics t précisnt, par xmpl, la résolution d'un écran ou ls codc installés sur un téléphon SIP. Ls fonctionnalités xprimnt commnt intragir avc ls autrs ntités. Ells sont dénis par dux élémnts : l mod d communications mis n uvr t l typ ds donnés échangés. Mods d communications L'échang d'information ntr ds ntités a liu slon trois mods d communications : asynchron, synchron t ux. Ls communications asynchrons prmttnt au srvic qui initi la communication d n pas rstr bloqué. Il poursuit son xécution après sa rquêt auprès du srvic distant. L srvic sourc souscrit à un typ d donnés auprès d'un autr srvic. C drnir émt ds donnés n dirction ds souscripturs. C mod d communications st généralmnt applé mod événmntil [EFGK03, Eug07]. Ls communications synchrons impliqunt qu l srvic qui rquirt un opération sur un srvic distant, s mtt n attnt d'un répons. Ctt répons contint un information prmttant au srvic sourc d poursuivr son xécution. L drnir mod d communications idntié st la communication par ux d donnés. Nous mployons par la suit l trm d sssion 1. C mod d communications st principalmnt utilisé pour l transport d la voix t d la vidéo mais il put facilmnt êtr généralisé à d'autrs typs d donnés tls qu ds msurs physiqus, par xmpl l'humidité, la luminosité ou la tmpératur. Il st alors possibl d'émttr ou d rcvoir un ux d msurs d tmpératur pour, par xmpl, assrvir un climatisur. Ls sssions impliqunt généralmnt un grand quantité d donnés. An d réduir cs quantités, ds codc sont mis n plac pour comprssr ls donnés. La mis n plac d'un communication par sssion nécssit d convnir d'un codc ntr ls dux partis. Typs d donnés échangés Nous avons pu rmarqur à plusiurs rpriss qu'il xist un multitud d typs d donnés pouvant fair l'objt d'échang ntr ds srvics. Parmi ls typs d donnés déjà introduits, il y a ls donnés audio t vidéo, ls msurs physiqus, l txt pour n citr qu cla. Mais nous pourrions égalmnt parlr d l'information d présnc, d disponibilité, d localisation d'un prsonn ou d'un bin. Il st nécssair d décrir ls donnés échangés pour dénir un systèm d communications. Un donné put êtr décrit à l'aid d propriétés. Cs propriétés constitunt llsmêms ds donnés typés. Nous obtnons ainsi un dscription arborscnt ds typs d donnés jusqu'à l'utilisation d typs primitifs tls qu ds ntirs ou ds chaîns d caractèrs. Ctt dscription st similair à la dénition Java d'un objt t d ss attributs. Par xmpl, un imag xpos plusiurs propriétés comm un profondur d coulur t un résolution. La profondur d coulur put êtr xprimé par un ntir. La résolution st quant à ll décrit par un coupl d'ntirs précisant la hautur t la largur d l'imag. 1 Il st à notr qu la notion d sssion Pantaxou n'st pas la mêm qu cll n SPL.

117 Analys du domain Variations Après avoir détrminé ls points communs ds srvics ntités t d lurs communications, nous allons voir ls variations ntr ls srvics, ls mods d communications t ls typs d donnés. Entités communicants L'apparition d nouvaux périphériqus nécssit un approch xibl, capabl d supportr cs nouvaux srvics. Par xmpl, un caméra équipé d'un détctur d mouvmnt doit pouvoir êtr intégré dans un nvironnmnt xistant où d'autrs caméras sont déployés. La nouvll caméra fournissant au moins ls mêms fonctionnalités qu ls ancinns doit êtr obsrvé d façon indiérncié par ls autrs srvics. Ls srvics xistants, communiquant avc ds caméras, n sont pas actés par ls évolutions. C bsoin d xibilité suggèr d dénir ls nouvaux périphériqus n trm d périphériqus xistants auxquls sont ajoutés ls nouvlls fonctionnalités. La dénition d'un nouvau srvic st ainsi fondé sur la dérivation d'un ancin par l'ajout d propriétés t d fonctionnalités. Un duxièm variation ntr ls srvics résid dans lurs fonctionnalités t ls propriétés qui ls caractérisnt. Ls srvics fournissnt ds fonctionnalités diérnts t ils xposnt donc un variété d combinaisons, d mods d communications t d typs d donnés. Par xmpl, un téléphon fournit un fonctionnalité d communication par sssion audio, tandis qu'un caméra fournit un fonctionnalité d sssion vidéo. Un captur d mouvmnt émt ds événmnts d détction. Enn, un captur d tmpératur st intrrogé via un opération synchron rnvoyant la tmpératur courant. Concrnant ls propriétés ds srvics, chaqu srvic possèd ds propriétés spéciqus. Lors d la dénition d'un srvic, il faut égalmnt dénir l'nsmbl ds propriétés qui l caractérisnt. Par xmpl, un périphériqu matéril a un mplacmnt physiqu. Un captur d mouvmnt survill ls mouvmnts dans un zon délimité. Un caméra ou un téléphon n puvnt communiqur qu'à l'aid d crtains codc. An d fair fac à l'abondanc d srvics, un xprt cré un modèl d l'nvironnmnt qu'il xprtis. L'xprt d'nvironnmnt dénit ls srvics présnts t prévus dans l'nvironnmnt n fonction d scénarios d'usag. Slon l'nvironnmnt (par xmpl, un écol, un ntrpris, un administration) dans lqul Pantaxou sra mis n uvr, l'nsmbl ds srvics considérés pourra ainsi varir. Concptullmnt, un modèl d'nvironnmnt st associé à un nvironnmnt. En pratiqu, un réutilisation ds partis communs ntr dux modèls doit êtr mis n pratiqu an d minimisr l coût d la dénition d'un modèl. Ctt réutilisation st d la rsponsabilité ds xprts dénissant ls modèls. Nous pouvons nvisagr la constitution d'un bas d connaissanc dans c but. Mods d communications L plan d contrôl d'un communication st indépndant du plan d donnés. Par xmpl, un srvic d survillanc connct un caméra à un écran. Il initi ls communications t ls contrôl mais n'a pas d donnés à transmttr. Il rçoit un sssion vidéo d la caméra t la rtransmt à un écran. Lors d la dénition ds fonctionnalités d'un srvic ntité, il st par conséqunt important d bin caractérisr l'orintation du ux d donnés pour ls communications d typ sssion. L ux put ainsi êtr unidirctionnl comm par xmpl pour un écran ou un caméra où la sssion vidéo st rspctivmnt rçu t émis. L ux put égalmnt êtr bidirctionnl comm par xmpl ls sssions audio ntr dux téléphons. L'orintation ds donnés pour ls dux autrs mods d communications st implicit.

118 96 Pantaxou La signatur d'un opération synchron dénit ls échangs d donnés ntr ls dux intrlocuturs. Ls argumnts d l'opération indiqunt ls donnés émiss, tandis qu l typ d rtour indiqu ls donnés rçus. D manièr similair, ls opérations asynchrons qu nous considérons sont fondés sur dux phass : un phas d souscription à ds événmnts t un phas d récption ds événmnts. Lors d la souscription, l souscriptur précis ls événmnts qu'il souhait rcvoir ultériurmnt. Dans la scond phas, l'événmnt st portur d'un donné à dstination ds souscripturs. Typs d donnés échangés Il xist d très nombrux typs d donnés échangabls. Crtains propriétés sont par aillurs communs ntr plusiurs typs. Par xmpl, l typ d la résolution d'un imag dénit à la fois la taill d'un imag x, tll qu'un photo, ou la résolution d'un vidéo. An d favorisr la réutilisation ds dénitions d typs, la dénition ds typs d donnés doit êtr hiérarchiqu Cahir ds chargs Ls objctifs du langag Pantaxou sont similairs à cux du langag SPL hormis la cibl ds srvics. L langag Pantaxou doit facilitr l dévloppmnt d srvics ntités n orant ds abstractions favorisant la concision ds programms. Ls programms produits sont plus simpls à comprndr t à maintnir lors d'évolutions ultériurs. D plus, l'utilisation d'un approch langag dédié st d natur à favorisr la réutilisation. L'nvironnmnt d'xécution t la chaîn d compilation prmttnt un réutilisation systématiqu d cod t d'xprtis pour chaqu dévloppmnt d'un nouvau srvic. Finalmnt, Pantaxou doit orir ds opportunités d vérications prmttant d garantir l bon fonctionnmnt global du systèm, si possibl avant l'xécution. Ds vérications statiqus doivnt donc êtr introduits pour garantir un coordination valid ds ntités communicants. 9.2 Dénition du langag À la suit d l'analys du domain ds srvics ntités, nous dénissons l'approch Pantaxou, sa syntax d'un part t sa sémantiqu statiqu t dynamiqu d'autr part Syntax L'approch Pantaxou st un approch n dux tmps. L langag rèt ctt décomposition t st composé d dux grammairs distincts t complémntairs. La prmièr grammair prmt d dénir un modèl d'nvironnmnt. Nous parlrons du langag PantaEnv. Il comprnd la dénition abstrait ds srvics ntités d l'nvironnmnt t ls typs d donnés associés. La scond grammair xprim ds srvics ntités concrts n dénissant lur logiqu. Nous parlons alors du langag PantaLog. L'approch Pantaxou st décrit avc l'xmpl d'un rdirction ds appls d'un scrétair d son burau vrs clui où ll s trouv au momnt d l'appl ; c scénario st détaillé n Figur 9.1. L'objctif st d lui prmttr d n pas prdr d'appls, y compris pndant ss déplacmnts dans l'ntrpris. C scénario nécssit d localisr la scrétair dans l'ncint du bâtimnt d l'ntrpris. Il mt n uvr divrs srvics : ds détcturs d présnc, un gstionnair d présnc, un bas d donnés, un agnt d présnc t ds téléphons dont un téléphon virtul. Nous proposons d'xploitr la tchnologi Blutooth pour résoudr l

119 Dénition du langag 97 problèm d détction d la présnc. Ds équipmnts Blutooth sont déployés d manièr prmannt dans ls buraux (par xmpl, ordinatur x, clé USB Blutooth) t détctnt la présnc d la scrétair à l'aid d'un périphériqu Blutooth qu'll port (par xmpl, son téléphon cllulair prsonnl). Lorsqu'un lctur Blutooth détct l'ntré d'un périphériqu Blutooth, il émt un événmnt à un gstionnair d présnc Blutooth. C gstionnair rchrch l'idntité du propriétair du périphériqu dans un bas d donnés. Il émt à son tour un événmnt signalant la présnc d'un prsonn dans un burau particulir. L'agnt d présnc rçoit ct événmnt t stock l'association ntr la localisation t la prsonn (par xmpl, la scrétair). Si l'on chrch à joindr la scrétair, un téléphon virtul rçoit l'appl t consult l'mplacmnt d la scrétair dans la list d'association précédmmnt rmpli. L'appl st alors rdirigé vrs l'mplacmnt courant d la scrétair. 1. Lorsqu'Alic ntr dans l burau 1, l lctur Blutooth détct la présnc d son périphériqu Blutooth. burau 1 <#125> burau 3 2. L lctur Blutooth publi un événmnt pour signalr la présnc du périphériqu ayant l'adrss #125. Ct événmnt st rçu par l gstionnair d présnc Blutooth. 3. L gstionnair rchrch dans la bas d donnés l'idntité du propriétair du périphériqu ayant l'adrss # L gstionnair publi un événmnt signalant qu Alic s trouv actullmnt dans l burau 1. Ct événmnt st rçu par l'agnt d présnc. burau 2 BdD <#125> Alic Gstionnair d présnc Blutooth Agnt d présnc Alic burau 1 burau 4 Téléphon virtul Résau 5. Lorsqu'un appl st à dstination du scrétariat, un sssion audio arriv sur l srvic d téléphon virtul gérant ls appls. 6. L téléphon virtul dmand à l'agnt d présnc où s trouv Alic. 7. L téléphon virtul transfrt l'appl au téléphon du burau 1. Fig. 9.1: Scénario d rdirction n fonction d la localisation Dénition d'un modèl d'nvironnmnt Avant qu ds logiqus d srvics ntités soint dévloppés t déployés, un xprt dénit un modèl d l'nvironnmnt. C modèl dénit d façon abstrait ls srvics qui doivnt êtr dévloppés. L'xprt doit rcnsr t dénir l'nsmbl ds typs d donnés nécssairs aux scénarios d'usag qui s déroulront dans l'nvironnmnt. L'xprt dénit nsuit ls communications ntr srvics t l'nsmbl ds srvics ntités qui composnt ls diérnts scénarios. Ls srvics sont dénis par lur propriétés t lurs fonctionnalités. Ls fonctionnalités détaillnt ls communications qui ont liu ntr ls srvics. Ls typs d donnés, ls communications t ls srvics d'un modèl d'nvironnmnt sont rgroupés dans un uniqu chir (Figurs 9.2, 9.3 t 9.4) écrit n PantaEnv.

120 98 Pantaxou Typs d donnés échangés Ls typs d donnés sont dénis d manièr arborscnt, n fonction d propriétés typés. L langag PantaEnv dénit ds typs primitifs tls qu ls ntirs, ls chaîns d caractèrs t ls énumérations, pour typr ls propriétés simpls. An d favorisr la réutilisation ds dénitions ds typs, ls typs puvnt êtr dénis hiérarchiqumnt. Il st ainsi possibl d ranr la dénition d'un typ ultériurmnt sans impactr l'xistant. Enn, il appartint à l'xprt d l'nvironnmnt d fair ds choix d concption quant à la hiérarchi d typs qu'il dénit. Par xmpl, un imag put êtr rprésnté d façon génériqu par un uniqu typ d donnés ou un typ d donnés put êtr déni pour chaqu typ d format d'imag dvant êtr supporté par l'nvironnmnt. C typ d choix d concption dépnd fortmnt d l'nvironnmnt, t il appartint à l'xprt d fair ls choix ls plus adaptés à son nvironnmnt. L'xprt doit cpndant tnir compt ds évolutions qu dvra supportr l'nvironnmnt qu'il st n train d concvoir. La gur 9.2 dénit ls déclarations ds typs d donnés nécssairs pour l scénario d rdirction d'appls vrs la scrétair n déplacmnt. L'utilisation ds sssions audio a été intégré d façon nativ dans l langag. L typ Audio st un typ fourni (lign 1). Il doit êtr importé lorsqu l'on souhait l'xploitr dans un nvironnmnt particulir pour intégrr ds périphériqus SIP natifs, comm ds téléphons SIP. Cs périphériqus sont manipulés comm ds srvics Pantaxou, bin qu'ils n'aint pas été dévloppés slon ctt approch. Nous trouvons nsuit la dénition d'un burau, modélisé par un idntiant d typ ntir naturl. L typ Room (lign 3) srt à dénir l'information d présnc d'un prsonn. L'URI t l statut d'un prsonn sont égalmnt associés à la présnc (ligns 7 à 11). Enn, ls typs DbBlutoothInfo t BlutoothDtction srvnt rspctivmnt lors d la consultation d la bas d donnés t lors d la détction d'un périphériqu Blutooth (ligns 13 à 20). 1 import Audio; 2 3 struct Room { 4 int numbr; 5 } 6 7 struct Prsnc { 8 uri ntity; 9 bool status; 10 Room room; 11 } struct DbBlutoothInfo { 14 uri ownrnam; 15 } struct BlutoothDtction { 18 string blutoothaddrss; 19 int signalstrngh; 20 } 21 Fig. 9.2: Déclaration ds typs d donnés du modèl d'nvironnmnt

121 Dénition du langag 99 Mods d communications Nous dénissons trois mods d communications pour ls srvics Pantaxou : ls commands, ls événmnts t ls sssions. Ils corrspondnt rspctivmnt aux communications synchrons, asynchrons t ux d donnés. Ls commands sont dénis d manièr très similair à ds intrfacs Java. Un command st un list nommé d signaturs d méthods. Cs signaturs sont typés avc ds typs d donné primitifs ou dénis par l'xprt d'nvironnmnt. La gur 9.3 donn la dénition ds commands nécssairs pour notr scénario. Ells prmttnt rspctivmnt d consultr la bas d donnés t la list d'association. 22 command DbQuryBlutooth { 23 DbBlutoothInfo gtinfobt(string blutoothaddrss); 24 } command GtRoom { 27 Room gtroom(uri usr); 28 } 29 Fig. 9.3: Déclaration ds commands du modèl d'nvironnmnt Ls événmnts t ls sssions n nécssitnt pas d dénition par l'xprt d l'nvironnmnt. Il put dirctmnt manipulr cs abstractions lors d la dénition ds srvics du modèl d'nvironnmnt (Figur 9.4). Ls mots-clés vnt t sssion sont prévus à ct t. Un notation similair aux typs paramétrés d Java 1.5 prmt d'associr un mod d communication t un typ d donnés précédmmnt déni. Finalmnt, l mot-clé command prmt d'associr ds commands précédmmnt déclarés à ds srvics. L'orintation du ux d donnés pour ls communications d typ sssion st déni par un modicatur. Il n xist trois, '!', '?', '='. Ils dénissnt rspctivmnt ls ux émis, rçus t bidirctionnls. La dénition d'un téléphon indiqu par xmpl qu c typ d srvics émt t rçoit ds sssions audio bidirctionnlls (ligns 54 t 55). Taxonomi ds srvics Pour facilitr la déclaration d cs srvics t la réutilisation, nous proposons un organisation hiérarchiqu ds srvics (Figur 9.4-(b)). Ainsi, ls capturs Blutooth (BlutoothDtctorAgnt) t ls téléphons (Phon t VirtualPhon) sont rgroupés sous un n ud uniqu périphériqu (Dvic). La gur 9.4-(a) donn la list ds srvics présnts dans l'nvironnmnt pour réalisr notr scénario. L mot-clé xtnds prmt d dénir un rlation d'héritag ntr ls srvics. Ls déclarations d srvics héritnt à la fois ds propriétés ds srvics parnts t d lurs fonctionnalités. L téléphon virtul s comport ainsi comm un téléphon standard. La déclaration ds srvics prmt d déclarr l couplag xistant ntr ls srvics, au nivau d l'nvironnmnt. Pour c fair, ls mots-clés rquirs t provids déclarnt ls fonctionnalités rspctivmnt rquiss t fournis par un srvic. La porté d'un fonctionnalité, vis à vis d la class d srvics distants, st égalmnt précisé via ls mots-clés from t to. Chaqu déclaration d'un fonctionnalité prmt ainsi un couplag fort ntr dux typs d srvic. Par xmpl, l srvic VirtualPhon nécssit la command GtRoom d'un srvic PrsncAgnt (lign 58). L dual d ctt déclaration consist à déclarr l srvic

122 100 Pantaxou 30 srvic RootSrvic {} 31 srvic BlutoothPrsncManagr xtnds RootSrvic { 32 rquirs vnt<blutoothdtction> 33 from BlutoothDtctorAgnt; 34 rquirs command<dbquryblutooth> from InfoDB; 35 provids vnt<prsnc> to PrsncAgnt; 36 } 37 srvic InfoDB xtnds RootSrvic { 38 provids command<dbquryblutooth> 39 to BlutoothPrsncManagr; 40 } 41 srvic PrsncAgnt xtnds RootSrvic { 42 rquirs vnt<prsnc> 43 from BlutoothPrsncManagr; 44 provids command<gtroom> to RootSrvic; 45 } 46 srvic Dvic xtnds RootSrvic { 47 Room room; 48 } 49 srvic BlutoothDtctorAgnt xtnds Dvic { 50 provids vnt<blutoothdtction> 51 to BlutoothPrsncManagr; 52 } 53 srvic Phon xtnds Dvic { 54 provids sssion<=audio> to Phon; 55 rquirs sssion<=audio> from Phon; 56 } 57 srvic VirtualPhon xtnds Phon { 58 rquirs command<gtroom> from PrsncAgnt; 59 } RootSrvic BlutoothPrsncManagr InfoDB PrsncAgnt Dvic Room room BlutoothDtctorAgnt Phon VirtualPhon (a) Déclarations ds srvics (b) Hiérarchi ds srvics Fig. 9.4: Srvics d'un modèl d'nvironnmnt PrsncAgnt comm fournissant la command GtRoom à l'nsmbl ds srvics, t a fortiori, par héritag au srvic VirtualPhon (lign 44). Un propriété room d typ Room (lign 47) st déclaré pour ls srvics Dvic. Ell prmt d localisr n'import qul périphériqu Dénition d'un logiqu d coordination d srvics Lorsqu'un xprt a modélisé un nvironnmnt, ds dévloppurs puvnt nsuit dévloppr ds srvics ntités. Cs srvics sont ds instancs ds srvics modélisés dans l'nvironnmnt. Ils doivnt à c titr rspctr crtains contraints. Nous dénissons la grammair du langag d logiqus Pantaxou, PantaLog, pour l dévloppmnt d srvics ntités. L'objctif d c langag st d dénir ds logiqus implémntant ds srvics abstraits d l'nvironnmnt. Cs logiqus ds srvics ntités prmttnt la coordination ds srvics d'un nvironnmnt particulir d manièr abstrait. En t, ls logiqus n font référnc à aucun instanc d srvic d l'nvironnmnt. Ells s'appuint sur ls déclarations abstraits ds srvics t sur un systèm d découvrt d srvics rposant sur ls propriétés ds srvics. Ls gurs 9.5, 9.6 t 9.7 présntnt ls srvics nécssairs au scénario d la scrétair. Dans c scénario, l gstionnair d présnc Blutooth, c.-à-d. l srvic Blutooth- PrsncManagr (Figur 9.5), coordonn l'intraction ntr ls détcturs Blutooth disséminés dans l bâtimnt t la bas d donnés. L gstionnair émt nsuit ds évén-

123 Dénition du langag 101 mnts Prsnc. Cs événmnts sont rçus par l'agnt d présnc (Figur 9.6). L'agnt d présnc maintint l'association ntr ls prsonnls d l'ntrpris t lur localisation. Il put êtr consulté pour détrminr l burau actul d'un prsonn donné. L téléphon virtul rprésnt l scrétariat (Figur 9.7) t rdirig ls appls vrs ls téléphons dans ls buraux. Il consult pour cla l'agnt d présnc an d détrminr commnt routr ls appls. La dénition d'un srvic commnc par l'importation ds déclarations (Figur 9.5, ligns 1 à 7) du modèl nécssairs pour l srvic. L dévloppur dénit nsuit l nom du srvic à l'aid d'un URI n précisant qul srvic du modèl il implémnt (lign 9). L point d'ntré du srvic s trouv au nivau du bloc d cod initial (lign 31). C bloc st xécuté lors d l'activation du srvic dans l'nvironnmnt. Il st égalmnt possibl d déclarr un bloc final qui sra xécuté lors d la désactivation. Nous trouvons dans l corps du srvic la dénition ds srvics nécssairs au bon fonctionnmnt d la logiqu. Cs dénitions srvnt lors d la découvrt d srvics. Ells détrminnt ls propriétés particulièrs qu doivnt avoir ls srvics d'un typ particulir. L gstionnair d présnc doit par xmpl rcvoir ls événmnts d détction ds idntiants Blutooth provnant d l'nsmbl ds détcturs. L gstionnair doit égalmnt consultr un bas d donnés. Cs dux typs d srvic sont dénis par l'instanc du gstionnair d présnc (ligns 11 t 12). L domain précis qu l gstionnair nécssit ds événmnts BlutoothDtction provnant d détctur Blutooth. L srvic déclar l'événmnt btdtctionevt d typ BlutoothDtction provnant ds blutoothdtctoragnt. La notation [*] précis qu la souscription d l'événmnt sra fait auprès d tous ls srvics corrspondant à la dénition d'un blutoothdtctoragnt (lign 14 à 16). La déclaration suivant prmt d localisr un bas d donnés grâc à l'opératur nw (lign 18). Ct opératur xécut un découvrt d srvics. La découvrt st fondé sur la déclaration d srvic précédnt d la bas d donnés (ligns 12). L dévloppur déclar nsuit l bloc d cod, idntié par btevtrcption, traitant ls événmnts rçus d typ btdtctionevt (ligns 20 à 29). Lorsqu'un événmnt st rçu, la bas d donnés st consulté an d détrminr l propriétair du périphériqu ayant l'adrss Blutooth détcté (lign 22). Un nouvl événmnt p d typ Prsnc st initialisé grâc au numéro idntiant l burau issu du détctur Blutooth t l'uri idntiant un mployé issu d la bas d donnés (ligns 23 à 27). Ct événmnt st nalmnt publié dans l'nvironnmnt vrs ds évntuls souscripturs (lign 28). An d rcvoir ds événmnts d détction Blutooth (lign 14), l srvic souscrit aux événmnts btdtctionevt (lign 20) provnant ds blutoothdtctoragnt (lign 11) n adoptant l comportmnt btevtrcption (lign 31). L'xécution d l'opération adopt réalis trois tâchs. Prmièrmnt, ls srvics d typ BlutoothDctctionAgnt présnt dans l'nvironnmnt sont découvrts. Duxièmmnt, l srvic courant souscrit à l'événmnt d typ BlutoothDtction auprès d chaqu srvic découvrt. Enn, l traitmnt btevtrcption st nrgistré auprès d l'nvironnmnt d'xécution. Il sra xécuté à chaqu récption d'un événmnt. L'agnt d présnc (Figur 9.6) souscrit à l'événmnt publié par l gstionnair d présnc qu nous vnons d décrir (Figur 9.5). L'agnt doit implémntr la command GtRoom qui contint un uniqu méthod gtroom. L'implémntation d ctt méthod rtourn la drnièr pièc où a été localisé un mployé particulir, donné n argumnt (ligns 22 à 24). Pour c fair, la list d'associations st implémnté à l'aid d'un tabl d hachag. Ctt tabl st maintnu à jour par l traitmnt associé à la récption ds événmnts

124 102 Pantaxou 1 import datatyp BlutoothDtction; 2 import datatyp DbBlutoothInfo; 3 import datatyp Prsnc; 4 import datatyp Room; 5 import command DbQuryBlutooth; 6 import srvic Srvic.InfoDB; 7 import srvic Srvic.BluToothPrsncManagr; 8 9 sip:[email protected] instantiats Srvic.BlutoothPrsncManagr { srvic<blutoothdtctoragnt> blutoothdtctoragnt; 12 srvic<infodb> databas; vnt<blutoothdtction> from blutoothdtctoragnt[*] { 15 signalstrngh > 50; 16 } btdtctionevt; databas db = nw databas[1]; onrciv btevtrcption(btdtctionevt ) 21 { 22 DbBlutoothInfo i = db.gtinfobt(.data.blutoothaddrss); 23 vnt<prsnc> { 24 ntity = i.ownrnam; 25 room =.src.room; 26 status = tru; 27 } p; 28 publish(nw p); 29 } initial { adopt(btevtrcption); } 32 } Fig. 9.5: Gstionnair d la présnc Blutooth provnant du gstionnair d présnc (ligns 13 à 20). L'agnt d présnc t l gstionnair d présnc puvnt srvir dans d'autrs scénarios où la localisation d périphériqus ou d'mployé st nécssair t n sont pas spéciqus au scrétariat. L drnir srvic, l téléphon virtul, st propr à notr scénario t réalis la rdirction ds appls du scrétariat vrs l burau où s trouv la scrétair. L srvic d rdirction du scrétariat (Figur 9.7) dénit un instanc d'un téléphon virtul tl qu déclaré dans l modèl d'nvironnmnt. Il détrmin la localisation d la scrétair t dénit pour cla l srvic PrsncAgnt (lign 10). Il récupèr un référnc pour communiqur lors d'un opération d découvrt d srvics (lign 14). L srvic dénit égalmnt un srvic génériqu d typ Phon an d pouvoir traitr ls appls ntrants (ligns 9 t 12). L corps du srvic s trouv dans l bloc d cod traitant ls appls ntrants (ligns 16 à 31) ; c bloc st activé avc l mot-clé adopt (lign 33), comm pour ls événmnts. Lorsqu'un sssion audio s arriv, c.-à-d. lors d'un appl ntrant, un srvic myphon d typ Phon dans l burau où s trouv la scrétair st déclaré (ligns 19 à 21). L'agnt d présnc st consulté à c titr (lign 17) pour détrminr la pièc courant d la scrétair. Un uniqu srvic myphon st localisé lors d l'opération d découvrt d srvics (lign 22) t la sssion ntrant s st rdirigé vrs c drnir qui s trouv dans la mêm pièc qu la scrétair. Si l'appl st accpté, l srvic s mt n attnt d'un nouvl appl. Nous pourrions alors changr l'état d la scrétair t précisr qu'll s trouv actullmnt au

125 Dénition du langag import datatyp Room; 2 import datatyp Prsnc; 3 import srvic Srvic.BlutoothPrsncManagr; 4 5 sip:[email protected] instantiats Srvic.PrsncAgnt { 6 7 srvic<blutoothprsncmanagr> bm; 8 9 vnt<prsnc> from bm[*] prsncevt; HashTabl htabl; onrciv prsncrcption(prsncevt ) { 14 Prsnc p =.data; 15 if (p.status) { 16 htabl.put(p.ntity, p.room); 17 } ls { 18 htabl.rmov(p.ntity); 19 } 20 } Room gtroom(uri usr) { 23 rturn htabl.gt(usr); 24 } initial { 27 adopt(prsncrcption); 28 htabl = nw HashTabl<uri, Room>(); 29 } 30 } Fig. 9.6: Agnt d présnc téléphon. Si l'appl n'aboutit pas, l'rrur st rtourné à l'applant t l srvic s mt n attnt d'un nouvl appl. Nous pourrons dans c cas, réalisr un nouvll rdirction vrs un boît vocal par xmpl Sémantiqu statiqu La décomposition du dévloppmnt ds srvics Pantaxou n dux tmps (modélisation d'un nvironnmnt t implémntation d srvics) prmt ds vérications complémntairs. La prmièr phas consist à vérir la cohérnc du modèl. Un scond phas prmt d vérir la cohérnc d'un implémntation d'un srvic vis à vis d la déclarations d c srvic dans l modèl Analyss au nivau du modèl d'nvironnmnt L'utilisation t la dénition ds typs d donnés, ds fonctionnalités t ds srvics sont contrôlés. L couplag fort ntr ls srvics d'un modèl prmt d vérir qu l dual d'un srvic st bin déni. C'st-à-dir qu nous pouvons garantir qu pour un srvic donné, l'nsmbl ds fonctionnalités qu'il fournit sont bin utilisés par au moins un srvic du modèl t qu l'nsmbl ds fonctionnalités qu'il rquirt sont bin disponibls t fournis par au moins un srvic du modèl.

126 104 Pantaxou 1 import datatyp Audio; 2 import datatyp Room; 3 import command GtRoom; 4 import srvic Srvic.PrsncAgnt; 5 import srvic Srvic.Dvic.Phon; 6 7 sip:[email protected] instantiats Srvic.Dvic.Phon.VirtualPhon { 8 9 srvic<phon> phon; 10 srvic<prsncagnt> pa; sssion<audio> from phon[*] insss; pa agnt = nw pa[1]; onrciv callrcption(insss s) { 17 Room r = agnt.gtroom( sip:[email protected] ); 18 if (r == null) r = 42; 19 srvic<phon> { 20 room = r; 21 } myphon; 22 invit(nw myphon[1], s) { 23 accptd(activsssion<audio> aas) { 24 // An activ audio sssion (aas) 25 // is accssibl. 26 } 27 rjctd() { 28 rjct(s); // Forward th rjct. 29 } 30 } 31 } initial { adopt(callrcption); } 34 } Fig. 9.7: Srvic d rdirction d'appls (Téléphon virtul) Pour ctt analys, l'nvironnmnt s associ l nom d'un typ d srvic à l'nsmbl ds fonctionnalités qui l caractéris. Chaqu fonctionnalité st décrit par l triplt (d, m, id) où d st la dirction (c.-à-d. Provids ou Rquirs), m l mod d communication (c.-à-d. command, vnt ou sssion), t id st l nom du typ d srvic distant. Nous dénissons l'opératur rlationnl binair pour dénotr un rlation d sous-typag ntr ls srvics. Nous écrirons ainsi A B pour signir qu A st un sous-typ d B, quand A t B sont tous dux, soit ds typs d srvics, soit ds typs d donnés. Pour ls commands, A B si t sulmnt si (ssi) A t B sont la mêm command, t pour ls événmnts ou ls sssions, A B ssi l typ d donnés associé à A st un sous-typ du typ d donné associé à B. La propriété (9.1) garantit qu chaqu fonctionnalité fourni st rquis par au moins un typ d srvic. Ctt propriété garantit la cohérnc du modèl n trm d connxion ntr ls srvics. Par xmpl, dans un modèl bin formé, il n put y avoir d prt d'événmnt. C'st un propriété ssntill pour ds événmnts critiqus tls qu'un alarm incndi. Concrnant ls fonctionnalités d typ command, ctt propriété évit du cod mort. id s dom( s ), (Provids, m, id t ) s (id s ), id t dom( s ), (Rquirs, m, id s ) s (id t ), m m id t id t id s id s (9.1)

127 Dénition du langag 105 La propriété (9.2) prmt d vérir qu chaqu fonctionnalité rquis st fourni par au moins un typ d srvic. Ctt propriété garantit qu chaqu fonctionnalité utilisé st bin déni. id s dom( s ), (Rquirs, m, id t ) s (id s ), id t dom( s ), (Provids, m, id s ) s (id t ), m m id t id t id s id s (9.2) L langag PantaEnv dénit l'orintation ds ux d donnés ds sssions avc ls modicaturs '!', '?' t '='. La cohérnc d l'orintation ds ux st vérié d manièr similair. Nous autorisons la connxion d'un ux bidirctionnl avc un ux unidirctionnl. Il st ainsi possibl d'utilisr, par xmpl, un visiophon pour consultr un caméra Analyss au nivau d la logiqu ds srvics Lorsqu'un modèl st valid, son nvironnmnt d'xécution dédié put êtr généré. An d déployr du cod utilisatur dans ct nvironnmnt, ls dévloppurs programmnt ds srvics n PantaLog. Cs srvics sont vériés par l compilatur PantaGn. L compilatur véri qu ls fonctionnalités miss n uvr par ls srvics corrspondnt bin à clls déclarés dans l modèl PantaEnv t uniqumnt clls-ci. Nous dénissons ls règls prmttant la vérication ds fonctionnalités d typ command, événmnt t sssion. Dans cs règls, Γ rprésnt l'nvironnmnt t st composé ds typs d srvic Σ, ds commands Ξ t ds typs d donnés. On not Ξ 1 la fonction qui associ à un signatur d méthod la command à laqull ll appartint. µ st l'nsmbl ds fonctionnalités dénis pour l typ d srvic qui st vérié, t τ rprésnt l'association ds variabls du srvic à lur typ. Ls règls ds instructions font égalmnt référnc au typ t qui st attndu n rtour du bloc d cod où l'instruction apparaît. Ls instructions ont l typ Void à l'xcption d l'instruction rturn. Srvics La règl (9.3) dénit la sémantiqu d'un déclaration d srvic. La dscription du typ d srvic st tout d'abord rchrché dans l modèl PantaEnv à partir du nom du typ d srvic. Ls propriétés proprtis, déclarés par l'implémntation, sont nsuit vériés vis à vis d clls déclarés dans l modèl, τ prop. Finalmnt l'nvironnmnt du srvic st rtourné avc un nouvll association ntr l'idntiant id t l typ du srvic. Γ spa srvicpath : t t = SrvicTyp(_, _, τ prop ) Γ, µ, τ, τ prop p proprtis Γ, µ, τ d srvic<srvicpath> {proprtis} id ; : τ[id t] (9.3) Ls règls (9.4) t (9.5) prmttnt d'instancir ls déclarations d srvic. Ells prnnnt un déclaration d srvic d typ SrvicTyp t produisnt un typ SrvicInstTyp. C typ corrspond a ds srvics qui ont été préalablmnt découvrt dans l systèm grâc à l'opératur nw. La règl (9.4) s'appliqu lorsqu'un nombr particulir d'ntités st rquis lors d la découvrt. La règl (9.5) s'appliqu lorsqu touts ls ntités doivnt êtr découvrts.

128 106 Pantaxou τ(srvic) = SrvicTyp(_, _, _) i N SrvicInstTyp(i, τ(srvic)) = t Γ, µ, τ nw srvic[i] : t (9.4) τ(srvic) = SrvicTyp(_, _, _) SrvicInstTyp(, τ(srvic)) = t Γ, µ, τ nw srvic[*] : t (9.5) Commands La règl (9.6) véri la dénition d'un command par un srvic. Ls typs ds argumnts sont tout d'abord vériés comm appartnant bin aux typs d donnés déclarés dans l modèl. La signatur d la command st nsuit rchrché dans l modèl. L typ d rtour déclaré dans l modèl st comparé avc clui déclaré par l srvic. L typ déclaré par l srvic put évntullmnt êtr un sous-typ du clui déclaré dans l modèl. L'appartnanc d ctt command au typ d srvic évalué st nalmnt vérié. Γ = (Σ, Ξ, ) Γ, µ, τ t typ i : t i t i = DataTyp(_), i {1,..., n} Ξ 1 (cmdnam, t 1 ;... ; t n ) = Command(cmdLabl, mthods) mthods(cmdnam, t 1 ;... ; t n ) = rt_typ Γ, µ, τ t typ : t d Γ, µ, τ[id 1 t 1,..., id n t n ], rt_typ s cmpd : t s t d = rt_typ t s rt_typ ProviddCommandTyp(cmdLabl) µ Γ, µ, τ m command typ cmdnam (typ 1 id 1,..., typ n id n ) cmpd (9.6) La règl (9.7) véri la bonn utilisation d'un command. Ctt règl n'st valabl qu lorsqu la command st invoqué sur un uniqu instanc d srvic. Si l'invocation d la command a liu sur un nsmbl d srvics, la règl (9.8) st évalué. L'analys réalisé st la mêm, sul l typ d rtour dièr. La signatur d la command invoqué srt tout d'abord à rchrchr la dénition d la command dans l modèl. Ctt command doit êtr rquis par l typ d srvic d l'implémntation n cours d vérication. Ell doit égalmnt êtr fourni par l typ d srvic sur lqul ll st invoqué. L typ d rtour d l'invocation corrspond au typ d rtour déclaré dans l modèl. (Σ, Ξ, ), µ, τ xp : SrvicInstTyp(i, SrvicTyp(_, µ, _)) i = 1 (Σ, Ξ, ), µ, τ xp j : t j, j {1... n} Ξ 1 (cmdnam, t 1 ;... ; t n ) = Command(cmdLabl, mthods) t = mthods(cmdnam, t 1 ;... ; t n ) RquirdCommandTyp(cmdLabl) µ ProviddCommandTyp(cmdLabl) µ (Σ, Ξ, ), µ, τ xp.cmdnam(xp 1,..., xp n ) : t (9.7)

129 Dénition du langag 107 (Σ, Ξ, ), µ, τ xp : SrvicInstTyp(i, SrvicTyp(_, µ, _)) i (N { }) \ {1} (Σ, Ξ, ), µ, τ xp j : t j, j {1... n} Ξ 1 (cmdnam, t 1 ;... ; t n ) = Command(cmdLabl, mthods) t = mthods(cmdnam, t 1 ;... ; t n ) RquirdCommandTyp(cmdLabl) µ ProviddCommandTyp(cmdLabl) µ (Σ, Ξ, ), µ, τ xp.cmdnam(xp 1,..., xp n ) : ListTyp(t) (9.8) Événmnts Ls règls (9.9) à (9.11) décrivnt ls opérations prmttant à un srvic d publir un événmnt. La règl (9.9) décrit la déclaration d'un événmnt qui prmt d'étndr l'nvironnmnt τ du srvic. L'idntiant id st ainsi associé à la dénition d l'événmnt : τ[id ProviddEvntTyp(usrTypLabl)]. Pour c fair, la dénition usrtyppath du typ d donnés d l'événmnt st récupéré dans l'nvironnmnt Γ. Ls propriétés déclarés par l dévloppur sont analysés vis à vis d clls déclarés dans l modèl. Finalmnt, la règl véri qu l typ d donnés d l'événmnt st un sous-typ du typ d donnés d'un événmnt dvant êtr publié par c srvic. Γ upa usrtyppath : usrtyp usrtyp = UsrTyp(usrTypLabl, τ prop ) Γ, µ, τ, τ prop p proprtis usrtyplabl, ProviddEvntTyp(usrTypLabl ) µ Γ = (_, _, ) (usrtyplabl) (usrtyplabl ) Γ, µ, τ d vnt<usrtyppath> {proprtis} id ; : τ[id ProviddEvntTyp(usrTypLabl)] (9.9) Un fois qu'un événmnt st déclaré, l srvic put n crér un instanc qu'il put publir. La règl (9.10) cré un instanc d'un événmnt à partir d'un déclaration d typ ProviddEvntTyp. La règl (9.11) véri qu l'instruction publish n rçoit n argumnt qu ds événmnts qui puvnt êtr publiés, c'st-à-dir ds xprssions d typ EvntInstTyp t dont l typ d srvic évalué st un fournissur. τ(idntir) = ProviddEvntTyp(tl) Γ, µ, τ nw idntir : EvntInstTyp(tl) Γ, µ, τ xp : EvntInstTyp(tl) ProviddEvntTyp(tl) µ Γ, µ, τ, t s publish (xp) ; : Void (9.10) (9.11) Ls règls (9.12) à (9.14) vérint ls opérations rlativs à la récption d'événmnts. Un srvic doit réalisr quatr étaps an d rcvoir ds événmnts : 1. Déclarr l typ d srvic qui publi l'événmnt qu'il désir rcvoir, 2. Déclarr l typ d'événmnt qu'il souhait rcvoir d cs srvics, 3. Dénir un traitmnt à xécutr lorsqu'un événmnt st rçu, 4. Invoqur l'instruction adopt an d sélctionnr t activr un traitmnt particulir.

130 108 Pantaxou L compilatur d srvics Pantaxou véri à chacun d cs étaps la cohérnc ds déclarations du dévloppur d srvic au sin d'un srvic ainsi qu vis à vis du modèl d'nvironnmnt. Nous avons vu précédmmnt la déclaration d srvic à la règl (9.3). L'étap suivant consist à déclarr l'événmnt auqul souscrit l srvic. Ctt déclaration précis dux élémnts : d'un part l typ d srvics qui émt l'événmnt, t d'autr part l nombr d souscriptions auprès ds srvics d c typ. L typ d srvics st dénoté par l trm srvic, tandis qu l nombr d souscriptions st dénoté par l'ntir i. La règl (9.12) véri qu l typ d srvic auqul l srvic souscrit publi bin l'événmnt désiré. D plus, l'événmnt publié doit avoir un typ d donnés associé qui soit un sous-typ d l'événmnt désiré. Enn, l'événmnt désiré par l dévloppur doit lui-mêm êtr un sous-typ d'un événmnt rquis par l srvic évalué tl qu déclaré dans l modèl. Γ upa usrtyppath : usrtyp usrtyp = UsrTyp(usrTypLabl 1, τ prop ) Γ, µ, τ, τ prop p proprtis τ(srvic) = SrvicTyp(_, µ, _) usrtyplabl 2, ProviddEvntTyp(usrTypLabl 2 ) µ usrtyplabl 3, RquirdEvntTyp(usrTypLabl 3 ) µ Γ = (_, _, ) (usrtyplabl 2 ) (usrtyplabl 1 ) (usrtyplabl 3 ) Γ, µ, τ d vnt<usrtyppath> from srvic[i] {proprtis} id ; : τ[id RquirdEvntTyp(usrTypLabl)] (9.12) La troisièm étap consist à dénir l traitmnt qui sra xécuté à chaqu récption d'un événmnt. La règl (9.13) récupèr la déclaration d'événmnt précédnt dans l'nvironnmnt t véri son typ. L typ d l'idntiant doit êtr un déclaration d typ RquirdEvntTyp. L typ d donnés d l'événmnt srt alors à évalur l bloc d cod qui dénit l traitmnt d l'événmnt. τ(imt yp) = RquirdEvntTyp(t) t = EvntInstTyp(t) Γ, µ, τ[im t ], Void s cmpd : Void Γ, µ, τ d onrciv id (imtyp im) cmpd : τ[id EvntRcptionTyp(imTyp)] (9.13) Finalmnt, l traitmnt rsponsabl d'un événmnt donné st sélctionné avc l'instruction adopt. Ctt instruction srt égalmnt à sélctionnr ls sssions ntrants. La règl (9.14) véri qu l'xprssion n argumnt st bin soit d typ EvntRcptionTyp, soit d typ SssionRcptionTyp. Γ, µ, τ xp : EvntRcptionTyp(_) + SssionRcptionTyp(_) Γ, µ, τ, t s adopt(xp) ; : Void (9.14) Sssions Ls sssions n Pantaxou ont un notation t un sémantiqu très similair à clls ds événmnts. Ls règls rlativs aux déclarations ds sssions, la création d'instanc d sssions, la découvrt d srvics t la dénition d'un traitmnt sont disponibls n annx D

131 Dénition du langag 109 ainsi qu l'nsmbl d la sémantiqu d Pantaxou. Nous présntons ici ls instructions t xprssions spéciqus à la manipulation ds sssions. L'instruction invit prmt d'émttr ou d rdirigr un sssion. Ell prnd n prmir argumnt l srvic auqul st dstiné la sssion. L scond argumnt st un instanc d sssion. La règl (9.15) véri qu l srvic n cours d'évaluation nécssit bin c typ d sssion t qu l srvic distant fournit bin ctt fonctionnalité. Finalmnt, chaqu branch d l'instruction st vérié. La prmièr branch corrspond au cas où la sssion émis st accpté par l srvic distant, tandis qu la scond branch corrspond au cas où la sssion a été rjté. Lorsqu la sssion st accpté, un sssion activ st alors accssibl aux dévloppurs. Γ, µ, τ xp 1 : SrvicInstTyp(_, mods, _) Γ, µ, τ xp 2 : SssionInstTyp(usrTypLabl) RquirdSssionTyp(usrTypLabl) µ usrtyplabl, (usrtyplabl ) (usrtyplabl) ProviddSssionTyp(usrTypLabl ) mods typ = ActivSssionTyp(usrTypLabl) Γ, µ, τ[id typ], t s cmpd acc : t acc Γ, µ, τ, t s cmpd rj : t rj t acc = t rj = t Γ, µ, τ, t s invit(xp 1, xp 2 ){accptd(typ id) cmpd acc rjctd() cmpd rj } : t (9.15) Un sssion activ put égalmnt êtr obtnu n accptant un sssion ntrant. Un bloc onrciv dénit l traitmnt d'un sssion ntrant, il dénit égalmnt n argumnt un variabl d typ SssionInstTyp. L'xprssion accpt prmt d'accptr la sssion ntrant t d'obtnir un référnc sur la sssion activ. La règl (9.16) modélis l'évolution d l'état d la sssion lors d'un accptation. Γ, µ, τ xp : SssionInstTyp(usrTypLabl) Γ, µ, τ accpt (xp) : ActivSssionTyp(usrTypLabl) (9.16) Au contrair, l'instruction rjct, décrit par la règl (9.17), prmt d rfusr un sssion ntrant. Ell prnd n argumnt un instanc d sssion qui n'st pas ncor activ t produit l typ Void. Γ, µ, τ xp : SssionInstTyp(_) Γ, µ, τ, t s rjct(xp) ; : Void (9.17) Sémantiqu dynamiqu La sémantiqu dynamiqu a été déni pour ls srvics ntités (Annx D.5). Ell n présnt cpndant pas d'originalité justiant d la détaillr. Sa rédaction a été réalisé n qulqus smains t a toutfois prmis d prndr crtains décisions d concption très tôt dans l procssus d dévloppmnt d l'approch Pantaxou. Par xmpl, la sémantiqu a mis n évidnc l problèm d la découvrt d l'nsmbl ds srvics, c.-à-d. [*], qui put rtournr un list vid d srvics. Nous avons convnu qu'il s'agissait d'un rrur dynamiqu t un bloc d cod onerror, global au srvic, st xécuté.

132 110 Pantaxou 9.3 Bilan Nous avons présnté dans c chapitr l'approch Pantaxou dédié au dévloppmnt d srvics ntités. Ctt approch s compos d dux langags : PantaEnv pour dénir un modèl d'nvironnmnt t PantaLog pour dénir ds logiqus d coordination d srvics. L modèl d'nvironnmnt déclar un nsmbl d srvics abstraits t ls communications qui ont liu ntr ls srvics. Cs communications s composnt d'un mod d communications t d typs d donnés. Il xist trois mods d communications n Pantaxou : command, événmnt t sssion. Lorsqu'un modèl st cohérnt, ds analyss prmttnt d l validr. Ds logiqus d srvics ntités sont nsuit dévloppés pour un modèl valid. Chaqu logiqu dénit un instanc d'un srvic abstrait d'un modèl. Un logiqu n contint pas d référnc xplicit à d'autrs srvics mais un mécanism d découvrt d srvics fondé sur ds propriétés rlativs aux srvics prmt d'intragir avc ls autrs ntités. Chaqu logiqu st vérié vis à vis du modèl auqul ll appartint. L'analysur contrôl ls déclarations d srvics, l'utilisation ds propriétés t l'nsmbl ds opérations rlativs aux communications.

133 Chapitr 10 Mis n uvr d Pantaxou Dans c chapitr nous décrivons notr implémntation du langag Pantaxou [MPCL08]. Nous précisons dans un prmir tmps l domain d notr étud t rapplons l procssus d dévloppmnt. Nous présntons nsuit la chaîn d compilation t son utilisation lors du dévloppmnt d srvics Domain d l'étud L'approch Pantaxou st fortmnt inspiré par ls mods d communications possibls n SIP, ctt approch st cpndant indépndant du protocol d communications sous-jacnt. La mis n uvr d Pantaxou a conduit au dévloppmnt d'un compilatur d modèls d'nvironnmnt Pantaxou nommé DiaGn [CJLP07, JLP + 08, JPCK08] t d'un compilatur d logiqus Pantaxou, pour ls srvics ntités. L compilatur DiaGn rpos sur plusiurs protocols d communications. Il st notammnt possibl d générr, outr l'implémntation fondé sur l protocol SIP, un implémntation fondé sur RMI ou ls srvics Wb, au choix Procssus d dévloppmnt L procssus d dévloppmnt n Pantaxou commnc par la dénition d'un modèl d'nvironnmnt comprnant la hiérarchi ds srvics du systèm ainsi qu ls commands t ls typs d donnés rlatifs aux communications ntr ls srvics. Un modèl PantaEnv st fournit au génératur DiaGn (à gauch, Figur 10.1) qui produit un intrgicil dédié au dévloppmnt ds srvics du domain. Ct intrgicil n Java assur la gstion ds srvics qui sront déployés t fournit ds mécanisms pour la découvrt d srvics. Plusiurs protocols d communications puvnt alors êtr mis n uvr. DiaGn prmt la génération d'un intrgicil fondé au choix sur l protocol SIP, la tchnologi RMI ou ls srvics Wb. L compilatur PantaGn (à droit d la gur) génèr nsuit pour chaqu srvic ntité un programm Java qui s'intègr à ct intrgicil. 111

134 112 Mis n uvr d Pantaxou 10.3 Chaîn d compilation Fig. 10.1: Approch Pantaxou La chaîn d compilation d l'approch Pantaxou s compos du compilatur DiaGn, d'un intrgicil généré par DiaGn pour un nvironnmnt donné t du compilatur d srvics PantaLog qui cibl ct intrgicil DiaGn L format d'ntré d DiaGn, DiaSpc, st un xtnsion d Java dérivé du langag d modélisation d'nvironnmnt PantaEnv. Un pré-traitmnt réécrit ls modèls Pantaxou tls qu'ils ont été présntés au chapitr précédnt n lur équivalnt DiaSpc. L compilatur DiaGn intègr ls outils JastAdd [EH07b, HM03] t JastAddJ [EH07a]. Cs outils prmttnt d manipulr l'arbr abstrait d programms Java. Après avoir analysé syntaxiqumnt un modèl d'nvironnmnt t vérié sa cohérnc, divrss classs Java sont générés pour chaqu objt du modèl (c.-à-d. ls srvics, ls propriétés t ls fonctionnalités ds srvics, ls commands t ls typs d donnés). Ls classs t ls intrfacs générés sont nsuit compilés avc un compilatur Java standard Intrgicil généré L'intrgicil généré s compos d dux partis : un couch bass génériqu t un couch haut dédié. La couch génériqu fournit ls mécanisms d bas pour ls trois typs d communications ainsi qu ds mécanisms génériqus pour l'nrgistrmnt ds srvics dans l systèm t la découvrt d srvics. La couch dédié spécialis cs élémnts à l'aid d classs Java abstraits t d'intrfacs pour l modèl d'nvironnmnt considéré. Il st possibl à c nivau d dévloppr n Java ds programms pour l'intrgicil DiaGn généré. Un dévloppur d srvic DiaGn n'a qu'à implémntr la logiqu d son srvic dans un class Java qui hérit d la class abstrait corrspondant au srvic qu'il souhait implémntr. L dévloppur dispos alors d'un nrgistrmnt automatiqu d son srvic dans l

135 Dévloppmnt d srvics 113 systèm, d mécanisms d découvrt dédiés aux typs d srvics avc lsquls il st amné à communiqur t d mécanisms d communications comm la publication d'événmnts. C nivau d programmation or moins d support pour l dévloppmnt d srvics qu'un dévloppmnt n PantaLog. Il autoris cpndant un plus larg catégori d srvics notammnt grâc à la possibilité d'invoqur ds bibliothèqus Java arbitrairs. L dévloppmnt ds lcturs Blutooth présnts dans l scénario d la scrétair nécssit par xmpl l'utilisation d'un bibliothèqu d fonctions pour contrôlr ds rssourcs Blutooth [Blu] t ont donc été dévloppés n Java t intégrés dans l'intrgicil généré. L'intrfac d programmation fourni par l'intrgicil n vari pas. Il st par contr possibl d choisir l protocol d communications mis n uvr. Ds implémntations RMI t SIP sont actullmnt disponibls. Un troisièm implémntation rposant sur ls srvics Wb st partillmnt implémnté 1. La tchnologi SOAP [kso] issu ds srvics Wb a été mis n uvr dans l'implémntation SIP t prmt d construir la charg util ds mssags SIP [JPCK08] Compilatur d logiqus Pantaxou L compilatur PantaGn prnd n argumnt un srvic ntité PantaLog t l modèl PantaEnv auqul il appartint. Après l'analys syntaxiqu du programm, la cohérnc du srvic vis à vis d son modèl st vérié par PantaGn. L'utilisation ds propriétés ds srvics lors d la découvrt d srvics st vérié. Ls propriétés déclarés dans la logiqu doivnt êtr dénis dans l modèl. L'nsmbl ds opérations d communication ntr ls srvics sont égalmnt vériés. Si l srvic st valid, un programm Java st généré. C programm rpos sur l'intrgicil dédié précédmmnt généré. La génération d'un srvic pour l'intrgicil dédié st possibl car l compilatur PantaGn dispos non sulmnt du modèl d'nvironnmnt pour lqul un srvic PantaLog st écrit, mais égalmnt ds motifs d génération d DiaGn. Ls programms Java ainsi produits s'intègrnt dans l'intrgicil où ils sont xécutés. La co-concption ntr l langag PantaEnv pour la modélisation d'nvironnmnt t l langag PantaLog pour la logiqu prmt d diminur l pas d compilation, c'st-à-dir d réduir la complxité du compilatur PantaGn. C compilatur st ainsi plus aisé à maintnir car un parti d la complxité lors d la compilation d'un srvic st déporté dans l compilatur DiaGn. Ls aspcts d communications ntr ls srvics sont dévolus au compilatur d modèl, tandis qu l compilatur d PantaLog réécrit ls abstractions du langag n motifs d cod Java fondés sur ls objts t ls classs dénis par l'intrgicil généré Dévloppmnt d srvics Un implémntation partill rposant sur ls srvics Wb a été dévloppé dans l cadr du projt uropén Amigo [Ami]. Ctt implémntation s'intègr au rst d l'intrgicil Amigo qui fournit ds srvics génériqus pour la découvrt, ls commands à distanc t ls événmnts. L compilatur d modèl génèr la surcouch dédié à l'nvironnmnt ainsi qu l squltt ds srvics. Ls programms PantaLog sont nsuit compilés n un programm Java qui complèt un squltt précédmmnt généré. 1 Ls sssions n sont pas disponibls.

136 114 Mis n uvr d Pantaxou L'intégration d Pantaxou au projt Amigo a été tsté avc l'xmpl d'un gstionnair d lumièr contrôlant ls lamps d'un bâtimnt. Il st n charg d ls allumr t d ls étindr n fonction d la luminosité. C scénario donn liu à un modèl d'nvironnmnt (Figur 10.2) comprnant un typ d donnés, la luminosité, un command composé d dux méthods t trois srvics. L gstionnair LightManagr communiqu avc ls diérnts périphériqus, d'un part ls capturs d luminosité, d'autr part ls lamps. 1 datatyp Luminosity { 2 int luminosityval; 3 } 4 5 command OnOff { 6 void on() ; 7 void off() ; 8 } 9 10 srvic Srvic {} srvic Light xtnds Srvic { 13 provids command<onoff>; 14 } srvic LightSnsor xtnds Srvic { 17 provids vnt<luminosity>; 18 } srvic LightManagr xtnds Srvic { 21 rquird vnt<luminosity>; 22 rquird command<onoff>; 23 } Fig. 10.2: Domain pour la gstion d lamps n fonction d la luminosité La génération d la couch dédié pour l'intrgicil Amigo donn un ratio ntr l cod écrit t l cod produit d l'ordr d 100 comm l'indiqu l tablau L'implémntation Java d l'intrgicil Amigo rpos sur l cadr d programmation OSGI [OSG]. L compilatur d modèls génèr un paqut OSGI (bundl) pour la couch dédié ainsi qu'un squltt d paqut pour chaqu srvic. Cs squltts sont nsuit prsonnalisés manullmnt ou bin un logiqu PantaLog y st inclus. L'utilisation du génératur sur un autr xmpl indiqu qu l ratio rst du mêm ordr d grandur [Ami07]. Dscription Paquts Amigo générés d domain Couch dédié 3 paquts squltts Ratio Nb. d caractèrs Nb. d mots Nb. d ligns Tab. 10.1: Ratio d génération pour l compilatur d modèls (implémntation pour la cibl ds srvics Wb Amigo) Lorsqu l'intrgicil st généré, ds dévloppurs spécint ds logiqus particulièrs pour ls srvics abstraits du modèl. Dans l cadr d c scénario, un gstionnair d lamps

137 Bilan 115 a été dévloppé n Pantalog (Figur 10.3). Il dénit un cycl d'hystérésis autour ds valurs arbitrairs 30 t 40 qu produisnt ls capturs d lumièr. Si la luminosité dvint trop faibl, ls lamps présntnt dans l systèm sont découvrts puis allumés. Lorsqu la luminosité augmnt au-dlà d 40, ls lamps sont étints. Alors qu l gstionnair corrspondant rprésnt un trntain d ligns d PantaLog, l compilatur d srvics génèr près d quatr-vingt dix ligns d Java pour l'intrgicil dédié (Annx E). 1 import command OnOff; 2 import datatyp Luminosity; 3 import datatyp Info; 4 import srvic LightManagr; 5 import srvic Light; 6 import srvic LightSnsor; 7 8 [email protected] instantiats LightManagr { 9 10 srvic<light> { 11 } light; srvic<lightsnsor> { 14 } lightsnsor; vnt<luminosity> from lightsnsor[*] { 17 } lumevt; onrciv lumevtrcption(lumevt ) { 20 int lum =.data.luminosityval; 21 if (lum < 30) { 22 (nw light[*]).on(); 23 } ls if (lum > 40) { 24 (nw light[*]).off(); 25 } 26 } 27 // Main Sction initial { 29 adopt(lumevtrcption); 30 } 31 } Fig. 10.3: Exmpl d gstionnair d lamps 10.5 Bilan Nous avons décrit dans c chapitr l procssus d dévloppmnt d srvics ntités fondé sur l'approch Pantaxou. La concision ds langags PantaEnv t PantaLog, pour spécir un modèl t ds programms, favoris la compréhnsion ds programms t lur réutilisation. Ctt concision n s fait pas au détrimnt d l'xprssivité. Ls informations présntnt dans un modèl d'nvironnmnt prmttnt la génération d'un intrgicil dédié. Il st actullmnt possibl d choisir parmi trois protocols d communications pour ct intrgicil. L langag d logiqus Pantaxou s'appui sur l modèl d'nvironnmnt t s concntr sur ls aspcts d coordination ds communications ntr ls ntités. Sa co-concption avc l langag PantaEnv prmt d vérir très tôt la validité d'un srvic vis à vis d'un modèl d'nvironnmnt donné. Grâc au haut nivau d'abstraction qu procur l'intrgicil généré t à sa spécialisation pour

138 116 Mis n uvr d Pantaxou un nvironnmnt donné, l pas d compilation ds srvics PantaLog st réduit vrs clui-ci. L compilatur PantaGn st ainsi plus simpl à maintnir.

139 Troisièm parti Bilan 117

140

141 Chapitr 11 Apports Ls travaux qu nous avons mnés sur SPL puis Pantaxou présntnt un approch global pour l dévloppmnt d srvics d communications. Cs dux langags ont été conçus à l'aid d l'approch ds langags dédiés. La formalisation d lur sémantiqu a prmis d ls documntr avc un haut nivau d'abstraction quand ls autrs approchs n proposnt qu'un documntation n langag naturl parfois accompagné d'un implémntation d référnc. SPL t Pantaxou proposnt un approch langag au géni logicil, t c, dans l domain ds srvics d communications. La formalisation d cs langags a prmis d dénir ds analyss qui garantissnt la abilité ds srvics ainsi dévloppés Géni logicil La concption d DSL conduit à ds langags simpls d'utilisation car dédiés à un domain. En simpliant la programmation grâc à ds abstractions d plus haut nivau qu dans ls langags généralists, la communauté potntill d dévloppurs s'agrandit. L'utilisation d SPL t Pantaxou st ainsi possibl pour ds programmurs ayant un connaissanc minimal d SIP t ds communications. Dans l cadr d Pantaxou, l'xprt qui modélis un nvironnmnt facilit la tâch ds dévloppurs d srvics n xplicitant son xprtis Abstractions La concption ds langags SPL t Pantaxou nous a prmis d dénir qulqus constructions originals. Ls srvics d routag n SPL sont cntrés sur la notion d sssions hiérarchiqus avc un ot d contrôl xplicit. Ctt abstraction prmt un gstion automatiqu d l'état ntr dux événmnts à traitr. L dévloppmnt st ainsi simplié pour ls dévloppurs qui n'ont plus à xplicitr cs opérations. Ls srvics ntités n Pantaxou sont conçus autour d trois mods d communications. Cs mods d communications sont ds concpts d prmir ordr pour la dénition d'un nvironnmnt. Enn un modèl PantaEnv captur l'hétérogénéité ds srvics d'un nvironnmnt où l'approch Pantaxou put êtr déployé, grâc notammnt à l'utilisation d'un hiérarchi d srvics. Il st ainsi possibl d dénir un modèl d manièr incrémntal. L dévloppmnt d srvics ntités rst simpl là où un approch généralist nécssitrait un ort supplémntair. Ls dévloppurs dvraint n t mttr n uvr lur logiqu particulièr dans un nvironnmnt d dévloppmnt génériqu. Ils lur faudraint dévloppr manullmnt l'équivalnt d l'intrgicil dédié an 119

142 120 Apports d comblr l manqu d'abstraction inhérnt à l'utilisation d'un approch généralist. Dans l'approch Pantaxou, au contrair, ct intrgicil dédié st généré automatiqumnt grâc à DiaGn Évolutivité Ls communications constitunt un domain n prpétull évolution. D nouvaux périphériqus communicants apparaissnt régulièrmnt t ls typs d donnés qu'ils échangnt évolunt égalmnt. SPL t Pantaxou répondnt à c bsoin dans lur domain rspctif. La fonctionnalité ds moduls xtrns d SPL prmt d traitr l'nsmbl ds aspcts n'ayant pas trait à la signalisation n dhors du srvic. Il st ainsi possibl d'intégrr l systèm d'information d'un ntrpris particulièr sous la form d'un modul ou plusiurs moduls. L routag ds appls put alors êtr prsonnalisé n fonction d'informations issus d srvurs Wb, d'agndas partagés ou d bass d donnés. L'appl d'un clint important put par xmpl êtr routé dirctmnt vrs l rprésntant commrcial traitant son dossir, sans passr par l standard d l'ntrpris. Concrnant Pantaxou, l'implémntation fondé sur SIP t généré par DiaGn prmt l dévloppmnt d srvics qui intragissnt avc ls périphériqus SIP natifs, tls qu ls téléphons SIP t ls passrlls téléphoniqus (par xmpl, Astrisk [Spb]). D plus, l'utilisation d tchnologis issus ds srvics Wb facilit ls intractions ntr cs drnirs t ls srvics SIP [JPCK08]. Enn, l'intrgicil généré fournit du support d dévloppmnt pour ls srvics n périphéri du systèm qui communiqunt avc l mond xtériur. C typ d srvics n put pas êtr implémnté n PantaLog car ils nécssitnt l'utilisation d'un API particulièr, par xmpl. C'st notammnt l cas ds détcturs Blutooth qui nécssit l'utilisation d'un pil d communications Blutooth tll qu BluCov [Blu]. L'approch Pantaxou or ainsi ds prspctivs d'évolution pour l'intropérabilité avc d nouvaux périphériqus SIP, ds srvics Wb t d'autrs tchnologis accssibls dpuis Java. DiaGn facilit dans c cas l dévloppmnt d'adaptaturs ntr ls srvics xistants d l'intrgicil DiaGn t ls tchnologis xtériurs Portabilité ds srvics t réutilisation L haut nivau d'abstraction d SPL t Pantaxou prmt d'êtr indépndant d la platform sous-jacnt comm n attstnt ls diérnts implémntations ou cibls d SPL t Pantaxou. Ls abstractions qu proposnt SPL t Pantaxou prmttnt d gagnr n concision. Ls srvics sont plus simpls à écrir t à comprndr. Ls applications dévloppés puvnt alors êtr portés avc ds modications minurs dans un nouvl nvironnmnt. La réutilisation d cod st multipl. D'un part, ls srvics dévloppés protnt ds évolutions ultériurs d lur nvironnmnt d'xécution. D'autr part, ils puvnt êtr rapidmnt adaptés pour êtr déployés dans un autr nvironnmnt, par xmpl pour un nouvl utilisatur ou un nouvll ntrpris. La disponibilité d la sémantiqu dynamiqu a quant à ll prmis un implémntation dirct d'un intrprèt comm l'illustr la règl traitant un rquêt INVITE initial t son implémntation n O'Caml (Figur 11.1). L'implémntation O'Caml comport snsiblmnt autant d fonctions qu'il y a d règls dans la sémantiqu, soit nviron un cntain. L'implémntation du prototyp O'Caml a ainsi été dévloppé n un smain.

143 Fiabilité 121 addrss = srvic, rid, did lookup_branchs(σ, parnt(addrss)) = branch crat_sssion(φ, σ, addrss, branch, undialog) = σ prpar_mthod_invocation(φ, σ, addrss, dirction, initial INVITE) = µ µ = m, dcls, stmt, nvs, σ τ = σ, addrss r = nvs, m, rq, hadrs initial INVITE(rid, did), dirction, rq, hadrs, φ, σ = srvic τ, r, INITIAL_INVITE φ = dcls, stmt 11.1a. Dénition d la règl sémantiqu lt intrprt mssag phi sigma srvic = match mssag with (I_INVITE(rid, did), dirction, rqid) -> lt addrss = [srvic;(rg, rid);(dial, did)] in lt branch = lookup_branchs(sigma, parnt(addrss)) in lt sigma = crat_sssion(phi, sigma, addrss, branch, Som(If.UNINVITE)) in lt (m_par, dcls, stmts, nvs, sigma ) = prpar_handlr_invocation(phi, sigma, addrss, dirction, If.INVITE) in lt tau = (sigma, addrss) in lt rho = (nvs, (m_par, rqid), []) in spl_handlr_body tau rho ([]::[[T_INITIAL_INVITE(phi)]]) (dcls, stmts) 11.1b. Implémntation O'Caml Fig. 11.1: Invocation d la méthod pour un prmir INVITE 11.2 Fiabilité Si nous considérons l langag SPL, la disponibilité d sa dénition formll t notammnt d la sémantiqu statiqu fut d'un grand aid pour l dévloppmnt d l'analysur d programms SPL. Ell a par xmpl srvi d fondation pour l dévloppmnt d l'analysur d typs qui comport nviron 600 ligns d cod O'Caml. Dans l cadr ds srvics d communications, SPL a prmis d'améliorr la abilité ds srvics d routag tout n présrvant l'xprssivité du langag. Il st notammnt possibl d vérir qu chaqu rquêt produit bin un uniqu répons vrs l'applant (à l'xcption d la rquêt ACK qui n doit rin rnvoyr). L'analys ds xprssions forward t /SUCCESS prmt d garantir, rspctivmnt, qu'un appl accpté n'st pas prdu, t qu'un répons positiv n'st pas fabriqué par un srvic d routag. Enn, la manipulation corrct ds n-têts st garanti grâc aux constructions whn t with. La dénition d la sémantiqu statiqu d Pantaxou a quant à ll prmis ls vérications d cohérnc ntr ls srvics d'un modèl d'un part t ntr l'implémntation d'un srvic t son modèl d référnc d'autr part. L'approch ds langags dédiés a prmis d'améliorr l dévloppmnt logicil n supprimant ds sourcs d'rrurs. La formalisation ds langags dédiés rnd notammnt aisé la vérication d propriétés spéciqus au domain. La abilité ds srvics d communications st ainsi amélioré avc l'utilisation d SPL t Pantaxou vis à vis d srvics équivalnts fondés sur ds approchs généralists.

144 122 Apports 11.3 Bilan L'utilisation d l'approch ds langags dédiés nous a prmis d concvoir dux langags, SPL t Pantaxou, dédiés au dévloppmnt ds srvics d communications. SPL st spécialisé pour l dévloppmnt ds srvics d routag tandis qu Pantaxou généralis l dévloppmnt ds srvics d communications au dévloppmnt ds srvics ntités. La concption d cs langags nous a prmis d dénir ds abstractions adaptés t spéciqus aux srvics d communications modrns qui intègrnt notammnt la téléphoni t plus généralmnt ls ux multimédia. Ls solutions proposés ornt ds mécanisms prmttant lur évolution pour prndr n compt d futurs bsoins. L'utilisation d'un langag dédié prmt d portr ls srvics dévloppés sur diérnts plats-forms, favorisant ainsi la réutilisation d cod. Enn, ls abstractions fournis t la dénition formll ds langags nous a prmis d dénir divrss analyss sur ls srvics. Cs analyss améliornt à la fois la abilité ds programms t cll d la plat-form sur laqull ils s'xécutnt.

145 Chapitr 12 Conclusion La démocratisation d'intrnt t la récnt convrgnc ds résaux d télécommunications t ds résaux informatiqus ont dévloppé ls communications ntr ls individus d'un part, t ntr ls équipmnts élctroniqus d'autr part. Ls télécommunications sont désormais d'un usag courant comm l'au ou l'élctricité. La convrgnc ds résaux s'st accompagné d l'apparition d protocols informatiqus prmttant ds communications audio t vidéo. L dévloppmnt d cs protocols s'accompagn d dévloppmnts d srvics. En t, ls utilisaturs ds systèms d téléphoni patrimoniaux n sont disposés à migrr qu s'ils rtrouvnt ls srvics dont ils disposnt déjà. Cs srvics doivnt d plus avoir l mêm nivau d abilité. Parmi ls protocols d téléphoni IP, l protocol SIP st l plus xibl t l plus déployé par ls opératurs d téléphoni. L protocol SIP prmt plusiurs mods d communications. Outr ls sssions dénis pour ls communications par ux d donnés, comm ls communications audio t vidéo, l protocol SIP dénit ds communications par événmnts t nvois d mssag. À l'instar du Wb t du courrir élctroniqu, la téléphoni SIP rpos sur un protocol txtul propic aux dévloppmnts d srvics. Ls approchs d dévloppmnt d srvics xistants sont d dux typs : d'un part clls fondés sur ls langags généralists, d'autr part clls fondés sur ls langags dédiés. Cpndant aucun approch xistant n'st à la fois haut nivau, sûr t xprssiv. Soit il st nécssair d'avoir un haut nivau d'xprtis dans l protocol t la programmation informatiqu, soit ls possibilités orts sont particulièrmnt rstrints. Nous avons présnté dans ctt thès un approch pour l dévloppmnt d srvics d communications. Ctt approch rpos sur l'introduction d dux langags dédiés aux srvics d communications, nommés SPL t Pantaxou. L langag SPL prmt l dévloppmnt d srvics d routag n spéciant un logiqu pour l traitmnt ds rquêts protocolairs SIP. L langag Pantaxou généralis l dévloppmnt ds srvics d communications, t prmt l dévloppmnt d srvics ntités. Contrairmnt aux srvics d routag qui n font qu réagir t modir ds stimuli d communications provnant d'ntités communicants, ls srvics ntités sont capabls d'initir ds stimuli vrs d'autrs srvics. L langag Pantaxou xprim ds logiqus pour coordonnr ls communications ds srvics ntités. Cs logiqus d coordinations sont lls-mêms ds srvics ntités. Ls langags SPL t Pantaxou ornt ds abstractions dédiés aux srvics d communications. Lur compilatur rspctif s'appui sur cs abstractions pour analysr ls srvics t déclr d'évntulls incohérncs. Ls srvics valids sont nsuit déployés dans un nvironnmnt d'xécution. Nous drssons dans c chapitr un bilan ds diérnts contributions d ctt thès, puis 123

146 124 Conclusion rcnsons un nsmbl d prspctivs d rchrch Contributions Ls contributions d ctt thès s décomposnt n plusiurs volts : l'analys d domain ds srvics d communications, t ds approchs pour l dévloppmnt d tls srvics. Ls approchs proposés concrnnt d'un part ls srvics d routag, t d'autr part ls srvics ntités. Nous montrons dans chacun d cs dux cas la faisabilité t l'intérêt d'un approch langag. Nous présntons l procssus complt d concption d langags dédiés aux srvics d communications, dpuis l'analys d domain préalabl jusqu'à l'implémntation. Analys d domain Nous avons ctué un analys ds srvics d communications. Ctt analys a été complété par l'analys du domain ds srvics d communications fondés sur SIP t ds méthods d dévloppmnt xistants. Nous avons ainsi pu dénir ls abstractions nécssairs pour un dévloppmnt haut nivau, sûr t xprssif ds srvics d routag d'un part, t ds srvics ntités d'autr part. Enn, nous avons égalmnt déni un nsmbl d propriétés dvant êtr garantis par ls srvics. Sssion Procssing Languag (SPL) À partir d l'analys d domain t du cahir ds chargs déni, nous avons conçu l langag SPL dédié au dévloppmnt ds srvics d routag. J'ai formllmnt déni c langag, t dérivé d la sémantiqu ds analyss ainsi qu'un implémntation. Ls analyss garantissnt ds propriétés critiqus du protocol SIP sous-jacnt. L compilatur véri par xmpl qu'un répons positiv lors du procssus d routag n'st pas créé ; qu'un répons positiv n'st pas prdu ; t, qu'un répons st rtourné pour touts ls rquêts. L langag fournit ds abstractions pour ls opérations d routag. Cs abstractions prmttnt un gstion automatisé d l'état d'un srvic ntr ls diérnts événmnts auxquls il réagit. Enn, un systèm d moduls prmt l'intraction d'un srvic d routag avc l rst du systèm d'information. L dévloppmnt d srvics d routag avc l langag SPL st ainsi à la fois haut nivau, sûr t xprssif par rapport aux approchs xistants. Pantaxou L'approch Pantaxou généralis l dévloppmnt ds srvics d communications aux srvics ntités. Ctt approch a été dévloppé grâc à un procssus d concption similair à SPL. L dévloppmnt d srvics Pantaxou rpos sur dux langags qui ont été coconçus. Un prmir langag srt à spécir un modèl d l'nvironnmnt où sront déployés ls srvics. C modèl dénit ls srvics ntités t ls communications qu'ils mttnt n uvr. Un scond langag prmt d dénir nsuit ds logiqus d coordinations ds ntités spéciés dans l'nvironnmnt. Chaqu logiqu st un instanc d'un srvic ntité déni dans l modèl. Ctt concption d srvics n dux tmps prmt d réalisr ds vérications très tôt dans l procssus d dévloppmnt. La cohérnc d'un nvironnmnt st garanti avant l'implémntation d'un logiqu pour un srvic. Enn, ls logiqus Pantaxou sont statiqumnt contrôlés vis à vis du modèl d'nvironnmnt dans lqul lls s'xécutront. La dénition d'un architctur distribué st ainsi séparé du dévloppmnt unitair t local d'un logiqu. Ds compilaturs ont été dévloppés pour cs dux langags. L prmir, DiaGn, génèr un intrgicil Java dédié au modèl d'nvironnmnt fourni. L scond, PantaGn, génèr, à

147 Prspctivs 125 partir d la logiqu d'un srvic Pantaxou, un programm Java pour un intrgicil fourni par DiaGn Prspctivs Ls travaux présntés proposnt un nouvll approch, fondé sur ls langags dédiés, pour l dévloppmnt d srvics d communications. Ctt approch or dux typs d prspctivs : d'un part dans l domain ds langags dédiés, t d'autr part pour l dévloppmnt d srvics d communications. Ls prspctivs rlativs aux srvics d communications concrnnt notammnt ds aspcts non-fonctionnls t la détction d'intractions d srvics. Langags dédiés Un prspctiv à court trm consist à idntir ds domains connxs pour augmntr l langag. Nous pourrions par xmpl intégrr ds aspcts langags dédiés pour l'intrrogation d bass d donnés [VWKSB07] ou la manipulation d documnts XML [BBK + 07]. Ctt intégration pourrait êtr intérssant aussi bin pour SPL qu pour ls logiqus d coordination Pantaxou. Enn, l'intégration d divrs aspcts dans l langag constiturait un cas d'étud pour ls intrprèts monadiqus [ADM05, SBP99]. Un autr prspctiv consist à appliqur l'approch ds langags nchâssés [Hud96]. À l'instar ds travaux d'intégration d BigWig [BMS02] dans Java, qui ont donné liu à la concption d JWig [CM02], nous nvisagons d'intégrr ls concpts du langag d logiqus Pantaxou dans l langag Java. Nous protrons alors ds diérnts API Java disponibls. L nivau d abilité introduit par l langag actul d logiqus dvra cpndant êtr présrvé. Aspcts non-fonctionnls Un d nos prochains dirctions d rchrchs pour Pantaxou consist à intégrr dans l langag ds aspcts non fonctionnls ds communications, comm la sécurité ou la qualité d srvic. Cs aspcts sraint décrits au nivau du modèl d'nvironnmnt. L'analys ds logiqus Pantaxou prmttrait nsuit d crtir ls implémntations vis à vis ds nouvlls contraints. L langag E [Mil06], qui propos ds mécanisms d sécurité pour ls communications ntr srvics, pourrait srvir d bas à cs travaux. Intractions d srvics Un autr prspctiv intérssant s'inspir ds travaux sur ls intractions d srvics qui ont été réalisés pour ls langags CPL [NLMK04] t LESS [WS05]. Un analys ds srvics SPL dans lur nsmbl plutôt qu'individull prmttrait d détrminr ls conits possibls à l'xécution. La détction ds intractions pourrait êtr étudié au nivau ds srvics d'un mêm utilisatur, pour êtr étndu par la suit aux intractions ntr ls srvics d dux intrlocuturs situés dans ds domains Intrnt diérnts [KM07]. Ds problèms d condntialité t d sécurité dvront alors êtr pris n compt. Enn, la vérication d modèl st un approch promttus pour la détction d'intractions [db99] t pourrait êtr appliqué aux srvics SPL. Ls problèms d'intractions d srvics sont égalmnt présnts dans Pantaxou. Nous nvisagons d'étudir commnt détctr ds conits ntr ls logiqus Pantaxou. Cs conits puvnt survnir lorsqu dux srvics nvoint ds ordrs contradictoirs à un troisièm par xmpl. L'analys d cycls dans ls communications pouvant conduir à un blocag ou un état rroné du systèm st égalmnt un prspctiv promttus.

148 126 Conclusion 12.3 Rmarqus nals Dans l cadr d nos rchrchs sur l langag SPL, un prspctiv d rchrch portant sur l dévloppmnt visul d srvics d routag nous a paru promttus. Ls travaux d Latry [Lat07] ont visé à concvoir t dévloppr l'atlir VisuCom. Ct éditur d srvics prmt d rprésntr graphiqumnt l'arbr d décision d'un srvic d routag manipulant un appl ntrant. Ls srvics produits sont nsuit compilés pour l'nvironnmnt d'xécution du langag SPL. Visucom t l'nvironnmnt d'xécution ont par la suit fait l'objt d'un dépôt logicil t d'un dépôt d brvt [BCL + 06c] n vu d'un transfrt tchnologiqu dans la jun pouss Sidrion Tchnologis. L génératur d'intrgicils dédiés, conçu dans l cadr d nos rchrchs sur Pantaxou, fait actullmnt l'objt d'un dépôt logicil n vu d'un dissémination d la tchnologi auprès d partnairs industrils t académiqus.

149 Publications Publications liés au langag SPL 1. N. Palix, C. Consl, L. Révillèr, t J. Lawall. A Stpwis Approach to Dvloping Languags for SIP Tlphony Srvic Cration. Dans Principls, Systms and Applications of IP Tlcommunications, IPTComm, Nw-York, USA, pags 7988, Juillt L. Burgy, C. Consl, F. Latry, J. Lawall, N. Palix, t L. Révillèr. Languag Tchnology for Intrnt-Tlphony Srvic Cration. Dans IEEE Intrnational Confrnc on Communications, Istanbul, Turqui, pags , Juin L. Burgy, C. Consl, F. Latry, N. Palix, t L. Révillèr. A High-Lvl, Opn Endd Architctur For SIP-basd Srvics. Dans Procdings of th 10th Intrnational Confrnc on Intllignc in srvic dlivry Ntworks (ICIN 2006), Bordaux, Franc, pags , Mai (Postr) 4. L. Burgy, C. Consl, F. Latry, L. Révillèr, t N. Palix. Tlphony ovr IP : Exprinc and Challngs. ERCIM Nws, 63 :5354, Octobr Brvt t dépôt logicil 1. Enrgistrmnt d'un brvt uropén t intrnational : Dispositif d'intrconnxion d'un systèm d'informations d'ntrpris(s) à un srvur d'applications d'un systèm d téléphoni IP. Brvt INRIA, , nrgistré l 7 août 2006, EP Enrgistrmnt logicil auprès d l'agnc d Protction ds Programms (APP) du logicil VisuCom t d son nvironnmnt xécution, vrsion 1.0 Publications liés à l'approch Pantaxou 1. J. Mrcadal, N. Palix, C. Consl t J. Lawall. Pantaxou : a Domain-Spcic Languag for Dvloping Saf Coordination Srvics. Dans Svnth Intrnational Confrnc on Gnrativ Programming and Componnt Enginring (GPCE), Nashvill, Tnnss, USA, Octobr (À paraîtr) 2. W. Jouv, N. Palix, C. Consl t P. Kadionik. A SIP-basd Programming Framwork for Advancd Tlphony Applications. Dans Th 2nd Confrnc on Principls, Systms and Applications of IP Tlcommunications (IPTComm'08), Hidlbrg, Grmany, Juillt Récompnsé millur papir étudiant. 127

150 128 Conclusion 3. W. Jouv, J. Lancia, N. Palix, C. Consl, t J. Lawall. High-lvl Programming Support for Robust Prvasiv Computing Applications. Dans Procdings of th 6th IEEE Confrnc on Prvasiv Computing and Communications (PrCom'08), Hong Kong, China, pags , Mars 2008 (Postr). 4. C. Consl, W. Jouv, J. Lancia, t N. Palix. Ontology-Dirctd Gnration of Framworks For Prvasiv Srvic Dvlopmnt. Dans Procdings of th 4th IEEE Workshop on Middlwar Support for Prvasiv Computing (PrWar'07), Whit Plains, Nw York, USA,pags , Mars 2007.

151 Bibliographi [ABBC99] [ADA + 04] [ADM05] D.L. Atkins, T. Ball, G. Bruns, t K. Cox. Mawl : A domain-spcic languag for form-basd srvics. IEEE transactions on softwar nginring, 25(3) :334346, S. Andrsn, A. Duric, H. Astrom, R. Hagn, W. Klijn, t J. Lindn. Intrnt Low Bit Rat Codc (ilbc), décmbr M.S. Agr, O. Danvy, t J. Midtgaard. A Functional Corrspondnc btwn Monadic Evaluators and Abstract Machins for Languags with Computational Ects. Thortical Computr Scinc, 342(1) :149172, [Ami] Th IST Europan projct Amigo. http :// [Ami07] [Apa] Amigo D3.5 Amigo ovrall middlwar : Final prototyp implmntation & documntation, Apach. HTTP srvr projct. http :// [Ash02] P.J. Ashndn. Th Dsignr's Guid to VHDL. Morgan Kaufmann, [Ass05] [ASU86] [Aub07] [BBK + 07] [BCL + 06a] [BCL + 06b] [BCL + 06c] IEEE Standards Association. IEEE LAN/MAN CSMA/CD Accss Mthod, A.V. Aho, R. Sthi, t J.D. Ullman. Compilrs : principls, tchniqus, and tools. Addison-Wsly Longman Publishing Co., Inc. Boston, MA, USA, R.J. Auburn. Voic Browsr Call Control : CCXML Vrsion 1.0 (Working draft). Rapport Tchniqu, W3C, janvir E. Balland, P. Braunr, R. Koptz, P.-E. Morau, t A. Rills. Tom manual. INRIA, nov L. Burgy, C. Consl, F. Latry, J. Lawall, N. Palix, t L. Révillèr. Languag Tchnology for Intrnt-Tlphony Srvic Cration. Dans IEEE Intrnational Confrnc on Communications, pags , juin L. Burgy, C. Consl, F. Latry, N. Palix, t L. Révillèr. A High- Lvl, Opn Endd Architctur For SIP-basd Srvics. Dans Procdings of th tnth Intrnational Confrnc on Intllignc in srvic dlivry Ntworks (ICIN 2006), pags , Bordaux, Franc, mai L. Burgy, C. Consl, F. Latry, N. Palix, t L. Révillèr. Routing dvic for an IP tlphony systm, août INRIA, [Bn86] J. Bntly. Programming parls : littl languags. Commun. ACM, 29(8) :711721,

152 130 Bibliographi [Big] B. Biggs. Kphon, a Fr SIP Usr Agnt. http ://sourcforg.nt/projcts/kphon. [BKVV08] M. Bravnbor, K.T. Kallbrg, R. Vrmaas, t E. Vissr. Stratgo/XT A languag and toolst for program transformation. Scinc of Computr Programming. Spcial Issu on Exprimntal Softwar and Toolkits (EST).(To appar)., pag 147, [BLFM05] T. Brnrs-L, R. Filding, t L. Masintr. Uniform Rsourc Idntir (URI) : Gnric Syntax. Intrnt Enginring Task Forc : RFC 3986, [Blu] BluCov : Java library for Blutooth. http ://cod.googl.com/p/blucov/. BluCov group. [BMS02] C. Brabrand, A. Møllr, t M. I. Schwartzback. Th <bigwig> Projct. ACM Transactions on Intrnt Tchnology, 2(2) :79114, mai [BPM04] I.D. Baxtr, C. Pidgon, t M. Mhlich. DMS : Program Transformations for Practical Scalabl Softwar Evolution. Procdings of th 26th Intrnational Confrnc on Softwar Enginring-Volum 00, pags , [BPSM + 06] T. Bray, J. Paoli, C. M. Sprbrg-McQun, E. Malr, F. Yrgau, t J. Cowan. Extnsibl Markup Languag (XML) 1.1. W3C Not RECxml , World Wid Wb Consortium, [BRLM07] L. Burgy, L. Révillèr, J. Lawall, t G. Mullr. A Languag-Basd Approach for Improving th Robustnss of Ntwork Application Protocol Implmntations. Dans Procding of th 26th IEEE Intrnational Symposium on Rliabl Distributd Systms, pags , Bijing, China, octobr IEEE. [BTKVV06] M. Bravnbor, M. Trygv Kallbrg, R. Vrmaas, t E. Vissr. Stratgo/XT : componnts for transformation systms. Dans PEPM '06 : Procdings of th 2006 ACM SIGPLAN symposium on Partial valuation and smantics-basd program manipulation, pags ACM, [Bur08] L. Burgy. Approch langag au dévloppmnt du support protocolair d'applications résaux. PhD thsis, Univrsité d Bordaux I - LaBRI / INRIA, avril [CE00] K. Czarncki t U.W. Eisnckr. Gnrativ programming : mthods, tools, and applications. ACM Prss/Addison-Wsly Publishing Co. Nw York, NY, USA, [CJLP07] C. Consl, W. Jouv, J. Lancia, t N. Palix. Ontology-Dirctd Gnration of Framworks For Prvasiv Srvic Dvlopmnt. Dans Procdings of Th 4th IEEE Workshop on Middlwar Support for Prvasiv Computing (PrWar'07), pags , Whit Plains, NY, USA, mars [CM98] C. Consl t R. Marlt. Architcturing softwar using a mthodology for languag dvlopmnt. Dans C. Palamidssi, H. Glasr, t K. Mink, éditurs, Procdings of th 10th Intrnational Symposium on Programming Languag Implmntation and Logic Programming, volum 1490 d Lctur Nots in Computr Scinc, pags , Pisa, Italy, sptmbr [CM02] A.S. Christnsn t A. Møllr. JWIG Usr Manual, 2002.

153 Bibliographi 131 [Con04] C. Consl. Domain-Spcic Program Gnration ; Intrnational Sminar, Dagstuhl Castl, Chapitr From A Program Family To A Domain-Spcic Languag, pags Numéro 3016 dans Lctur Nots in Computr Scinc, Stat-of-th-Art Survy. Springr-Vrlag, [Cri96] M. Crispin. RFC 2060 : INTERNET MESSAGE ACCESS PROTOCOL VERSION 4rv1, décmbr [CRS + 02] B. Campbll, J. Rosnbrg, H. Schulzrinn, C. Huitma, t D. Gurl. RFC3428 : Sssion Initiation Protocol (SIP) Extnsion for Instant Mssaging, décmbr [dafgd02] R. d Almida Falbo, G. Guizzardi, t K.C. Duart. An ontological approach to domain nginring. Procdings of th 14th intrnational confrnc on Softwar nginring and knowldg nginring, pags , [damc + 06] E.S. d Almida, J.C.C.P. Mascna, A.P.C. Cavalcanti, A. Alvaro, V.C. Garcia, S.R. d Lmos Mira, t D. Lucrédio. Th Domain Analysis Concpt Rvisitd : A Practical Approach. LECTURE NOTES IN COMPUTER SCIENCE, 4039 :43, [db99] L. du Bousqut. Fatur Intraction Dtction using Tsting and Modlchcking, Exprinc rport. Dans World Congrss on Formal Mthods, Toulous, Franc, Sptmbr [DRM04] J. Drull, M. Ranganathan, t D. Montgomry. Programmabl Activ Srvics for JAIN SIP. Rapport Tchniqu, National Institut of Standards and Tchnology, juin [DTD] Documnt Typ Dnition. http :// [EFGK03] Patrick Th. Eugstr, Pascal A. Flbr, Rachid Gurraoui, t Ann-Mari Krmarrc. Th many facs of publish/subscrib. ACM Comput. Surv., 35(2) :114131, [EH07a] T. Ekman t G. Hdin. Th JastAdd xtnsibl Java compilr. Dans OOPSLA '07 : Procdings of th 22nd annual ACM SIGPLAN confrnc on Objct orintd programming systms and applications, pags 118, Nw York, NY, USA, ACM Prss. [EH07b] T. Ekman t G. Hdin. Th JastAdd systm modular xtnsibl compilr construction. Scinc of Computr Programming, 69(1-3) :1426, [Eug07] P. Eugstr. Typ-basd publish/subscrib : Concpts and xprincs. ACM Transactions on Programming Languags and Systms (TOPLAS), 29(1), [FGM + 97] R. Filding, J. Gttys, J. Mogul, H. Frystyk, t T. Brnrs-L. RFC 2068 : Hyprtxt Transfr Protocol HTTP/1.1, janvir Status : PROPOSED STANDARD. [FPDF98] W. Fraks, R. Prito-Diaz, t C. Fox. DARE : Domain analysis and rus nvironmnt. Annals of Softwar Enginring, 5 :125141, [GHJV95] E. Gamma, R. Hlm, R. Johnson, t J. Vlissids. Dsign pattrns : lmnts of rusabl objct-orintd softwar. Addison-Wsly Longman Publishing Co., Inc. Boston, MA, USA, 1995.

154 132 Bibliographi [GS08] P. Gunthr t T. Showaltr. RFC5228 : Siv : An Filtring Languag, janvir [HFW84] C. T. Hayns, D. P. Fridman, t M. Wand. Continuations and Coroutins. Dans Procdings of th ACM Confrnc on LISP and Functional Programming, pags , Austin, TX (USA), août [HHKR89] J. Hring, PRH Hndriks, P. Klint, t J. Rkrs. Th syntax dnition formalism SDFrfrnc manual. ACM SIGPLAN Notics, 24(11) :4375, [HM03] G. Hdin t E. Magnusson. JastAdd : an aspct-orintd compilr construction systm. Scinc of Computr Programming, 47(1) :3758, [Hoa69] C.A.R. Hoar. An axiomatic basis for computr programming. Communications of th ACM, 12(10) :576580, [Hud96] P. Hudak. Building domain-spcic mbddd languags. ACM Computing Survys, 28 :196196, [Hud98] P. Hudak. Modular domain spcic languags and tools. Procdings of Fifth Intrnational Confrnc on Softwar Rus, pags , [JLP + 08] W. Jouv, J. Lancia, N. Palix, C. Consl, t J. Lawall. High-lvl Programming Support for Robust Prvasiv Computing Applications. Dans Procdings of th 6th IEEE Confrnc on Prvasiv Computing and Communications (PERCOM'08), pags , Hong Kong, China, mar [Joh75] S. C. Johnson. Yacc : Yt anothr compilr compilr. Rapport Tchniqu, Bll Tlphon Laboratoris, [Jos03] S. Josfsson. Th Bas16, Bas32, and Bas64 Data Encodings, juillt [JPCK08] W. Jouv, N. Palix, C. Consl, t P. Kadionik. A SIP-basd Programming Framwork for Advancd Tlphony Applications. Dans Th 2nd Confrnc on Principls, Systms and Applications of IP Tlcommunications (IPTComm'08), Hidlbrg, Grmany, jul [JSR03] JSR 116 : SIP Srvlt API. http ://jcp.org/n/jsr/dtail?id=116, mars [JSR04] JSR 22 : JAIN SLEE API Spcication. http ://jcp.org/n/jsr/dtail?id=22, mars [JSR06] JSR 32 : JAIN SIP API Spcication. http ://jcp.org/n/jsr/dtail?id=32, novmbr [Kal06] K. Kallbrg. Stratgo : a programming languag for program manipulation. Crossroads, 12(3) :44, [KCH + 90] K. C. Kang, S. G. Cohn, J. A. Hss, W. E. Novak, t A. S. Ptrson. Fatur-Orintd Domain Analysis (FODA) Fasibility Study. Rapport Tchniqu, Carngi-Mllon Univrsity Softwar Enginring Institut, Novmbr [Kr82] B.W. Krnighan. PIC-A Languag for Typstting Graphics. Softwar - Practic and Exprinc, 12(1) :121, [KM07] M. Kolbrg t E.H. Magill. Managing fatur intractions btwn distributd SIP call control srvics. Computr Ntworks, 51(2) :536557, 2007.

155 Bibliographi 133 [Knu64] D. Knuth. Backus normal form vs. Backus Naur form. Commun. ACM, 7(12) :735736, [kso] ksoap 2 projct. http ://ksoap2.sourcforg.nt. [KT03] A. Krigl t B Trukhnov. SQL Bibl. Wily, [LAMS05] T. Lich, S. Apl, L. Marnitz, t G. Saak. Tool support for faturorintd softwar dvlopmnt : faturide : an Eclips-basd approach. Procdings of th 2005 OOPSLA workshop on Eclips tchnology Xchang, pags 5559, [Lan90] P.S. Langston. Littl Languags for Music. Computing Systms, 3(2) : , [Lat07] F. Latry. Approch langag au dévloppmnt logicil : Application au domain ds srvics d Téléphoni sur IP. PhD thsis, Univrsité d Bordaux I - LaBRI / INRIA, sptmbr [LCLL04] F. Liu, W. Chou, L. Li, t J. Li. WSIP-Wb srvic SIP ndpoint for convrgd multimdia/multimodal communication ovr IP. Wb Srvics, Procdings. IEEE Intrnational Confrnc on, pags , [Lr97] X. Lroy. Th Objctiv Caml Systm Rlas 1.05, [LMB02] J.L. Lawall, G. Mullr, t L.P. Barrto. Capturing OS xprtis in an vnt typ systm : th Bossa xprinc. Procdings of th 10th workshop on ACM SIGOPS Europan workshop : byond th PC, pags 5461, [LS75] M. E. Lsk t E. Schmidt. Lx - a lxical analyzr gnrator. Rapport Tchniqu, Bll Tlphon Laboratoris, [LTM06] R. Lrdorf, K. Tatro, t P. MacIntyr. Programming PHP. O'Rilly, [LWS04] J. Lnnox, X. Wu, t H. Schulzrinn. RFC3880 : Call Procssing Languag (CPL) : A Languag for Usr Control of Intrnt Tlphony Srvics, octobr [Mai] MailMan, th GNU Mailing List Managr. http :// Fr Softwar Foundation, Inc. [Maj] Majordomo. http :// Grat Circl. [MGB + 04] F. Mittlbach, M. Goossns, J. Braams, D. Carlisl, t C. Rowly. Th Latx Companion (Tools and Tchniqus for Computr Typstting. Addison- Wsly Profssional, [Mica] Microsoft. Microsoft Oc Communications Srvr http ://oc.microsoft.com/nus/communicationssrvr/fx aspx. [Micb] Microsoft. Microsoft Oc Communications Srvr 2007 Srvr SDK. http ://msdn.microsoft.com/n-us/library/bb aspx. [Micc] Microsoft. Microsoft Rspons Point. http :// [Micd] Microsoft. Microsoft SIP Procssing Languag. http ://msdn.microsoft.com/n-us/library/bb aspx.

156 134 Bibliographi [Mic] Sun Microsystm. Entrpris JavaBans Tchnology. http ://- java.sun.com/products/jb/. [Micf] Sun Microsystm. Java Srvlt Tchnology. http ://- java.sun.com/products/srvlt/. [Mil06] M.S. Millr. Robust Composition : Towards a Unid Approach to Accss Control and Concurrncy Control. PhD thsis, Johns Hopkins Univrsity, Baltimor, Maryland, USA, mai [MMS00] D. Minoli, E. Minoli, t L. Sookchand. ITU-T H.320/H.323, [Moi01] A. Moizard. Th GNU osip library. http :// juin [Moi03] A. Moizard. Th Xtndd Osip Library. http ://savannah.nongnu.org/projcts/xosip/, octobr [MP99] V. Mnon t K. Pingali. A cas for sourc-lvl transformations in MAT- LAB. Procdings of th 2nd confrnc on Confrnc on Domain-Spcic Languags, 2 :55, [MPCL08] J. Mrcadal, N. Palix, C. Consl, t J. Lawall. Pantaxou : a Domain- Spcic Languag for Dvloping Saf Coordination Srvics. Dans Svnth Intrnational Confrnc on Gnrativ Programming and Componnt Enginring (GPCE), Nashvill, Tnnss, USA, octobr [MR96] J. Myrs t M. Ros. RFC 1939 : Post Oc Protocol Vrsion 3, mai [MRC + 00] F. Mérillon, L. Révillèr, C. Consl, R. Marlt, t G. Mullr. Dvil : An IDL for Hardwar Programming. Dans 4th Symposium on Oprating Systms Dsign and Implmntation (OSDI 2000), pags 1730, San Digo, California, octobr [MSN06] Unocial MicroSoft Notication Protocol Vrsion 15 documntation. http ://msnpiki.msnfanatic.com/indx.php/msn_protocol_vrsion_15, décmbr [Ni80] J. Nighbors. Softwar Construction Using Componnts. PhD thsis, Univrsity of California, Irvin, [Ni04] A. Nimi. Sssion Initiation Protocol (SIP) Extnsion for Evnt Stat Publication, octobr [NLMK04] M. Nakamura, P. Llaprut, K. Matsumoto, t T. Kikuno. On dtcting fatur intractions in th programmabl srvic nvironmnt of Intrnt tlphony. Computr Ntworks (Amstrdam, Nthrlands : 1999), 45(5) : , August [Nok] Nokia. Soa-SIP. http ://opnsourc.nokia.com/projcts/soa-sip/. [OAS07] Opn Documnt Format for Oc Applications (OpnDocumnt) v1.1, févrir OASIS Consortium. [Opa] OpnSER - th Opn Sourc SIP Srvr. http :// [Opb] Th OpnSIPStack Projct. http :// [OSG] OSGI, "Opn Srvic Gatway Initiativ Hompag", http ://

157 Bibliographi 135 [Par76] D.L. Parnas. On th Dsign and Dvlopmnt of Program Familis. IEEE Transactions on Softwar Enginring, 2 :19, mars [PCRL07] N. Palix, C. Consl, L. Révillèr, t J. Lawall. A Stpwis Approach to Dvloping Languags for SIP Tlphony Srvic Cration. Dans Procdings of Principls, Systms and Applications of IP Tlcommunications, IPTComm, pags 7988, Nw-York, NY, USA, juillt ACM Prss. [PD90] R. Prito-Díaz. Domain Analysis : An Introduction. Softwar Enginring Nots, 15(2), avril [Plo81] G. D. Plotkin. A Structural Approach to Oprational Smantics. Rapport Tchniqu DAIMI FN-19, Univrsity of Aarhus, [POJK03] A. Plinscu-Onciul, J. Janak, t Jiri Kuthan. SIP Exprss Routr (SER). IEEE Ntwork Magazin, 17(4) :9, [Pos81a] J. Postl. RFC 791 : Intrnt Protocol, [Pos81b] J. Postl. RFC 793 : Transmission Control Protocol, [Pos82] J. Postl. RFC 821 : Simpl Mail Transfr Protocol, [Pri] B. Prijono. pjsip.org Opn sourc SIP stack and mdia stack for prsnc, im/instant mssaging, and multimdia communication. http :// [rs] rsiprocat. http :// Th rsiprocat projct. [Rév01] L. Révillèr. Approch langag au dévloppmnt d pilots d périphériqus robusts. Thès d doctorat, Univrsité d Rnns 1, Franc, décmbr Bst Ph.D. Thsis award from ACM SIGOPS Franc. [RLS99] J. Rosnbrg, J. Lnnox, t H. Schulzrinn. Programming Intrnt Tlphony Srvics. IEEE Intrnt Computing, 3(3) :6372, [RM01] L. Révillèr t G. Mullr. Improving Drivr Robustnss : an Evaluation of th Dvil Approach. Dans Th Intrnational Confrnc on Dpndabl Systms and Ntworks, pags , Götborg, Swdn, juillt IEEE Computr Socity. [Roa02] A.B. Roach. RFC3265 : Sssion Initiation Protocol (SIP)-Spcic Evnt Notication, juin [RSC + 02] J. Rosnbrg, H. Schulzrinn, G. Camarillo, A. Johnston, J. Ptrson, R. Sparks, M. Handly, t E. Schoolral. RFC3261 : SIP : Sssion Initiation Protocol, juin [SA04] P. Saint-Andr. RFC 3920 : Extnsibl Mssaging and Prsnc Protocol (XMPP) : Cor, octobr [SBP99] T. Shard, Z. Bnaissa, t E. Pasalic. DSL Implmntation Using Staging and Monads. Dans Confrnc on Domain Spcic Languags, pags USENIX, [SCFJ03] H. Schulzrinn, S. Casnr, R. Frdrick, t V. Jacobson. RFC3550 : RTP : A Transport Protocol for Ral-Tim Applications, juillt [SCG + 08] M. Spncr, B. Capouch, E. Guy, F. Millr, t K. Shumard. IAX : Intr-Astrisk Xchang Vrsion 2 Work in progrss, mars 2008.

158 136 Bibliographi [Sch86] D.A. Schmidt. Dnotational Smantics : a Mthodology for Languag Dvlopmnt. Allyn and Bacon, Inc., [SIM] SIMPLE : SIP for Instant Mssaging and Prsnc Lvraging Extnsions. http :// IETF SIMPLE Working group. [SKG + 07] J. Sorbr, A. Kostadinov, M. Garbr, M. Brnnan, M.D. Cornr, t E.D. Brgr. Eon : a languag and runtim systm for prptual systms. Dans SnSys '07 : Procdings of th 5th intrnational confrnc on Embddd ntworkd snsor systms, pags , Nw York, NY, USA, ACM. [Sky] Skyp. http :// [Spa] Th Apach SpamAssassin Projct. http ://spamassassin.apach.org/. Apach Fondation. [Spa] Spx : A Fr Codc For Fr Spch. http ://spx.org/. Th Xiph Opn Sourc Community. [Spb] A. Spncr. Astrisk : Th Opn Sourc PBX. http :// [Thi98] S. Thibault. Domain-Spcic Languags : Concption, Implmntation and Application. PhD thsis, Univrsity of Rnns 1, Franc, octobr [Tra95] W. Tracz. DSSA (Domain-Spcic Softwar Architctur) : pdagogical xampl. ACM SIGSOFT Softwar Enginring Nots, 20(3) :4962, [TTC95] R.N. Taylor, W. Tracz, t L. Coglians. Softwar dvlopmnt using domain-spcic softwar architcturs. ACM SIGSOFT Softwar Enginring Nots, 20(5) :2738, [UML] UML : Unid Modling Languag. http :// Objct Managmnt Group (OMG). [vd97] A. van Dursn. "Domain-spcic languags vrsus objct-orintd framworks : A nancial nginring cas study. Dans Procdings Smalltalk and Java in Industry and Acadmia, STJA'97, pags 3539, Erfurt, Grmany, sptmbr Ilmnau Tchnical Univrsity. [vdk02] A. van Dursn t P. Klint. Domain-spcic languag dsign rquirs fatur dscriptions. Journal of Computing and Information Tchnology, 10(1) :117, [VWKSB07] E. Van Wyk, L. Krishnan, A. Schwrdfgr, t D. Bodin. Attribut grammar-basd languag xtnsions for Java. Proc. 21st ECCOP, pags , [W3C02] XHTML 1.0 Th Extnsibl HyprTxt Markup Languag (Scond Edition). http :// août W3C HTML Working Group. [Wi96] D.M. Wiss. Family-orintd Abstraction Spcication and Translation : th FAST Procss. Dans Procdings of th 11th Annual Confrnc on Computr Assuranc (COMPASS), Gaithrsburg, Maryland, pags IEEE Prss, Piscataway, NJ, [Wi98] D.M. Wiss. Commonality Analysis :A Systmatic Procss for Dning Familis. Lctur Nots in Computr Scinc, 1429 :214, [Wil04] D. Wil. Lssons Larnd from Ral DSL Exprimnts. Sci. Comput. Program., 51(3) :265290, 2004.

159 Bibliographi 137 [WS00] [WS03] [WS05] [XEP08] [XSL] X. Wu t H. Schulzrinn. Whr Should Srvics Rsid in Intrnt Tlphony Systms?. IP Tlcom Srvics Workshop (IPTS) 2000, X. Wu t H. Schulzrinn. Programmabl End Systm Srvics Using SIP. Dans Procdings of Th IEEE Intrnational Confrnc on Communications IEEE, X. Wu t H. Schulzrinn. Handling Fatur Intractions in th Languag for End Systm Srvics.. Dans Fatur Intractions in Tlcommunications and Softwar Systms VIII, ICFI'05, pags , Licstr, UK, juin IOS Prss. XEP 166 : Jingl, févrir XMPP Standards Foundation. XML Schma. http ://

160 138 Bibliographi

161 Quatrièm parti Annxs 139

162

163 Annx A SPL Syntax A.1 Lxical Convntions Blanks Th following charactrs ar considrd as blanks : spac, nwlin and horizontal tabulation. Blanks sparat adjacnt idntirs, litrals and kywords that would b othrwis confusd as a singl idntir, litral or kyword. Apart from that, thy ar ignord. Commnts Commnts ar C-lik commnts. Thy start with th charactrs /* and nd with th charactrs * /. C++ commnts styl can also b usd ; all charactrs from th two charactrs // until th nd of th lin ar considrd as part of a commnt. Commnts ar tratd as blanks. Spcial Lxm Thr ar svral kinds of idntirs : idnt which dns idntirs (for variabls, functions, branchs and srvic nam) hadrid which dns SIP hadrs in th RFC fashion, which mans, with a colon at th nd of th hadr nam vntidnt which dns SIP vnts in th RFC fashion, which mans, an alphanumric squnc of charactrs with possibly som '.' insid whn tmplat vnt packags ar usd urischm which is dnd as schm in th RFC 3261 Thy us common dnitions of lttr and digit. Idntirs lttr ::= A..Z a..z digit ::= 0..9 Idntirs ar a squnc of lttrs, digits and _ (th undrscor charactr) starting with a lttr or an undrscor. A lttr can b any of th 52 lowrcas and upprcas lttrs from th ASCII st. Th currnt implmntation placs no limit on th numbr of charactrs of an idntir. 141

164 142 SPL Syntax idnt ::= (lttr _) (lttr digit _) Hadr Nams Hadr nams ar a squnc of lttrs, digits and - (th minus charactr) starting with a lttr and nding with a colon. A lttr can b any of th 52 lowrcas and upprcas lttrs from th ASCII st. Th currnt implmntation placs no limit on th numbr of charactrs of a hadr nam. hadrid ::= #lttr (lttr digit _! % * - + ) : Evnt Idntirs Evnt idntirs ar a squnc of lttrs, digits and spcial charactrs as dnd in RFC A lttr can b any of th 52 lowrcas and upprcas lttrs from th ASCII st. Th currnt implmntation placs no limit on th numbr of charactrs of an vnt idntir. vntidnt ::= vnt-packag (. vnt-tmplat) vnt-packag ::= tokn-nodot vnt-tmplat ::= tokn-nodot tokn-nodot ::= (lttr digit _! % * - + ) + URI Schm URI schm ar dnd as in RFC 3261 urischm ::= lttr (lttr digit - +.) Intgr Litrals An intgr litral is a squnc of on or mor digits. Intgr litrals ar in dcimal (radix 10). intgr ::= 0 (1..9 digit ) Prx and Inx Oprator Th following tokns ar th SPL oprators : = + - * / && ==!= < > >= <=! match notmatch Kywords Th idntirs blow ar rsrvd kywords :

165 Lxical Convntions 143 BODY bool branch brak by cancl cas continu dfault dploy dialog ls vnt xtrn fals FIFO forach forward http https if in incoming int LIFO mailto match notmatch outgoing paralll pop procssing push rason rgistration rqust rqusturi rspons rturn slct srvic sip sips string this tim tru typ undploy uninvit unrgistr unsubscrib uri void whn with Th following charactr squncs ar also rsrvd. { } [ ] ( ) < > = :, ;. Bsids th abov mntiond kywords, all siphadr, rsponskind and SIPmthod ar also kywords and ar writtn in upprcas. Ambiguitis Lxical ambiguitis ar rsolvd according to th longst match rul : whn a charactr squnc can b dcomposd into tokns in svral dirnt ways, th rsulting dcomposition is th on with th longst rst tokn.

166 144 SPL Syntax A.2 SPL Program A SPL program consists of a srvic nam and a srvic construct. program ::= srvic idnt {srvic} srvic ::= procssing {dclarations? sssion } dclarations? sssion sssion ::= rgistration {dclarations? sssion } dialog {dclarations? mthod + } vnt vntidnt {dclarations? mthod + } mthod mthod ::= typexp dirction? mthodnam(arg? ) {stmt + } typexp dirction? mthodnam(arg? ) {branch + } branch ::= branch idnt ( idnt) {stmt + } branch dfault {stmt + } dirction ::= incoming outgoing mthodnam ::= SIPmthod ctrlmthod SIPmthod ::= ACK BYE CANCEL INVITE MESSAGE NOTIFY OPTIONS PUBLISH REGISTER REINVITE REREGISTER RESUBSCRIBE SUBSCRIBE ctrlmthod ::= dploy undploy uninvit unrgistr unsubscrib Nots : Without xplicit dirction, a mthod applis for both dirction, incoming and outgoing. Thr is no SIP mssag associatd with control mthods, so hadrs ar not accssibl. Ths mthods do not hav a rspons rturn typ but a void on. unrgistr is calld aftr a REGISTER with a zro Expir ld or aftr rlatd timout. unsubscrib is calld aftr a SUBSCRIBE with a zro Expir ld, a NOTIFY with Subscription-Stat: trminatd hadr or aftr rlatd timout. dploy and undploy can only appar dirctly in th procssing block. Procssing block can hav only on rgistration block.

167 Typ Exprssions 145 Rgistration block can hav only on sssion block. Rgistration block can hav multipl vnt block, but ach on must hav an uniqu vnt idntir. A.3 Typ Exprssions typexp simpltyp modir ::= simpltyp modir? simpltyp<intgr? > idnt ::= void bool int rqust rspons string tim uri ::= LIFO FIFO Nots : Th squnc siz must b xd at compil tim. A policy could b usd to limit th siz valu. According to static proprtis, som information about a squnc (.g. maximum siz, starting position, currnt position) could b forgottn. Th squnc had is on th lft sid, this is th rst lmnt to pop. According to th squnc kind, th push opration add an lmnt on ithr th had or th tail of th squnc. If th modir is not usd, a squnc is a LIFO squnc. A.4 Function Call functioncall ::= idnt(xplist? ) xplist ::= xp (, xp) A.5 Known URI Kinds urikind ::= https http mailto sips sip uri urischm

168 146 SPL Syntax A.6 Dclarations dclarations ::= dclarations dclaration dclaration dclaration ::= typexp idnt (= xp)? ; xtrn typexp idnt(args? ) ; typexp idnt(args? ) {stmt + } typ idnt { (typexp idnt ;) + } ; args ::= arg (, arg) arg ::= typexp idnt Nots : Initializ an idntir with a forward xprssion is only allowd in a mthod, this is a signaling action. So, it cannot happn in blocks lik procssing, rgistration and sssion outsid of a mthod. A function can only call anothr on which is alrady dclard. A.7 Statmnts compound ::= stmt {stmt + } stmt ::= plac = xp ; dclaration rturn xp? (branch idnt)? ; if(xp)compound if(xp)compound ls compound whn xp (whn-hadrs) compound whn xp (whn-hadrs) compound ls compound with ; forach(idnt in xp) compound slct(xp) { slctcas slctdfault? } functioncall ; continu ; brak ; push plac xp ; whn-hadrs ::= whn-hadr (, whn-hadr) whn-hadr ::= hadrid typexp idnt (<- const)? slctcas ::= cas orlist : (stmt) slctdfault ::= dfault : (stmt) orlist plac ::= const ( const) ::= idnt(.idnt) siphadr Nots : continu and brak ar only allowd insid a forach. functioncall is th only xprssion that can also b a statmnt. Th non-trminal plac, is a plac you can assign into, lik a variabl or a hadr ld in a rqust.

169 Mssag Modication 147 Hadr lds, in ithr a rspons or a rqust, ar modid by th with construct. Th xprssion in whn can only b an idntir. A.8 Mssag Modication Th with construct could b usd as an statmnt with th this xprssion which dnot th currnt procssd rqust, or as an xprssion with a rspons valu. with ::= xp with {mssagfild (, mssagfild) } mssagfild ::= rason=xp hadrid xp A.9 Exprssions xp ::= idnt(.idnt) constant siphadr unop xp xp binop xp (paralll)? forward (xp)? with (xp) rason BODY rqusturi this pop plac functioncall unop ::=! - binop ::= + - * / < > ==!= <= >= && match notmatch

170 148 SPL Syntax constant ::= tru fals intgr "string" uri squnc rspons squnc ::= <constant (, constant) > <> uri ::= urikind :uristring Nots : Th xprssion, usd in with xprssion, must b of rspons or rqust kind. Th xprssion, usd in pop xprssion, must b of squnc kind. match and notmatch us POSIX rgular xprssions. A.10 SIP Hadrs If SIP hadrs, spcid in th RFC 3261 and RFC 3265, ar mandatory in at last on mthod, thy ar intgratd in th SPL compilr as kywords. SIP hadrs ar rstrictd in trms of typ or accss rights (NA, RO, RW). Hadr kywords rfr to rqust hadrs only. Whn a hadr is not mandatory in a rqust and for all rsponss, th whn statmnt allow a protctd accss to rad hadrs in mssags. Hadrs can only b modid with th with xprssion. siphadr ::= CALL_ID CONTACT CSEQ EVENT FROM MAX_FORWARDS SUBSCRIPTION_STATE TO VIA

171 Constant Rsponss 149 A.11 Constant Rsponss Standard rsponss in RFC 3261 and RFC 3265 ar dnd in th languag. rspons ::= /ERRORrsponsError? /SUCCESSrsponsSuccss? rsponssuccss ::= /OK /ACCEPTED rsponserror ::= /CLIENTclintErr? /GLOBALglobalErr? /REDIRECTIONrdirctionErr? /SERVERsrvrErr? rdirctionerr ::= /ALTERNATIVE_SERVICE /MOVED_PERMANENTLY /MOVED_TEMPORARILY /MULTIPLE_CHOICES /USE_PROXY

172 150 SPL Syntax clinterr srvrerr globalerr ::= /ADDRESS_INCOMPLETE /AMBIGUOUS /BAD_EXTENSION /BAD_REQUEST /BUSY_HERE /CALL_OR_TRANSACTION_DOES_NOT_EXIST /EXTENSION_REQUIRED /FORBIDDEN /GONE /INTERVAL_TOO_BRIEF /LOOP_DETECTED /METHOD_NOT_ALLOWED /NOT_ACCEPTABLE_HERE /NOT_ACCEPTABLE /NOT_FOUND /PAYMENT_REQUIRED /PROXY_AUTHENTICATION_REQUIRED /REQUESTURI_TOO_LONG /REQUEST_ENTITY_TOO_LARGE /REQUEST_PENDING /REQUEST_TERMINATED /REQUEST_TIMEOUT /TEMPORARILY_UNAVAILABLE /TOO_MANY_HOPS /UNAUTHORIZED /UNDECIPHERABLE /UNSUPPORTED_MEDIA_TYPE /UNSUPPORTED_URI_SCHEME ::= /BAD_GATEWAY /MESSAGE_TOO_LARGE /NOT_IMPLEMENTED /SERVER_INTERNAL_ERROR /SERVER_TIMEOUT /SERVICE_UNAVAILABLE /VERSION_NOT_SUPPORTED ::= /BUSY_EVERYWHERE /DECLINE /DOES_NOT_EXIST_ANYWHERE /NOT_ACCEPTABLE

173 Annx B SPL Smantics This documnt dscribs th smantics of aspcts of th SPL languag rlating to SIP RFC B.1 Simplid Syntax Th smantics considrs a much simplid vrsion of th SPL languag. An SPL program has th following form. srvic srvic { procssing { (typ x = xp ;) (dirction? typ mthod_nam () { (branch branch {dcl stmt}) + }) rgistration { (typ x = xp ;) (dirction? typ mthod_nam () { (branch branch {dcl stmt}) + }) dialog { (typ x = xp ;) (dirction? typ mthod_nam () { (branch branch {dcl stmt}) + }) }}}} Th grammar is dnd as follows : program ::= srvic srvic {procssing {dcl mthod rgistration {dcl mthod dialog {dcl mthod }}}} dcl ::= typ x = xp ; mthod ::= dirction? typ mthod_nam { (branch branch {dcl stmt}) + } dirction ::= incoming outgoing typ ::= rspons uri uri list void bool string status stmt ::= {} {stmt 1 stmt 2 } x = xp rturn xp? branch b ; if (xp) stmt 1 ls stmt 2 xp 1 with ld = xp 2 ; xp ::= forward xp paralll forward xp < xp > xp 1 == xp 2 x c rqusturi xp 1 with ld = xp 2 this 151

174 152 SPL Smantics srvic, branch, and x ar arbitrary idntirs. Th {dcl + stmt} form is only allowd at th root of a mthod handlr. mthod_nam is rstrictd according to th lvl at which it occurs : At th srvic lvl, th allowd mthods ar dploy and undploy. At th rgistration lvl, th allowd mthods ar REGISTER, REREGISTER, and unrgistr. At th dialog lvl, th allowd mthods ar INVITE, REINVITE, CANCEL, ACK, BYE, and nd_dialog. Constants c ar strings, rsponss (.g., /SUCCESS, /ERROR, and various rnmnts throf), and lists of uris (.g., sip :[email protected] ). status is an numratd typ with lmnts SUCCESS and ERROR. B.2 Static Smantics Th only typs ty usd by th typ systm ar rqust, rspons, uri, uri list, void, bool, string, and status. Th typ systm is dnd in trms of an nvironmnt τ of typ var ty. Th judgmnts for statmnts, xprssions, dclarations, mthod dclarations and programs hav th following form, whr t 0, t ty : t 0, τ stmt : t t 0, τ xp : t t 0, τ dcl : τ τ mthod program t 0 is always th typ of th nclosing mthod, and is usd to dtrmin th rturn typ of forward. For xampl, thr is no rspons associatd with an ACK, and so a forward in an ACK handlr has rturn typ void. Th judgmnts for statmnts ar dnd as follows : t 0, τ {} : void t 0, τ stmt 1 : void t 0, τ {stmt 1 t 0, τ stmt 2 : t stmt 2 } : t t 0, τ xp : t t = τ(x) t 0, τ x = xp : void t 0, τ xp : t t 0, τ rturn xp branch b ; : t t 0, τ rturn branch b ; : void t 0, τ xp : bool t 0, τ stmt 1 : t 1 t 0, τ stmt 2 : t 2 t 1 = t 2 t 0, τ if (xp) stmt 1 ls stmt 2 : t 1 t 0, τ xp 1 : rqust t 0, τ xp 2 : t 1 t 0, τ xp 2 : t 2 t 1 = t 2 t 0, τ xp 1 with ld = xp 2 ; : void

175 Static Smantics 153 Th judgmnts for xprssions ar dnd as follows : t 0, τ xp : uri list t 0, τ forward xp : t 0 t 0, τ xp : uri list t 0, τ paralll forward xp : t 0 t 0, τ xp : uri t 0, τ < xp > : uri list t 0, τ rqusturi : uri c {"...",...} t 0, τ c : string c {< sip :[email protected],...>,...} t 0, τ c : uri list t 0, τ xp 1 : t 1 t 0, τ xp 1 : t 2 t 1 = t 2 t 0, τ xp 1 == xp 2 : bool t 0, τ x : τ(x) c {SUCCESS, ERROR,...} t 0, τ c : status c {/SUCCESS, /ERROR,...} t 0, τ c : rspons t 0, τ xp 1 : rspons t 0, τ xp 2 : string t 0, τ xp 1 with ld = xp 2 : rspons t 0, τ this : rqust Th judgmnts for dclarations ar dnd as follows, in which w us typ as ithr th syntactic typ nam or th nam of th corrsponding typ in th typ systm, as convnint. Th handlr rturn typ argumnt to th analysis of ach xprssion is bcaus dclarations ar not allowd to us (paralll) forward., τ xp : t t = typ τ typ x = xp ; : τ[x typ], τ xp : t t = typ τ[x typ] dcl 2... : τ τ typ x = xp ; dcl 2... : τ Th judgmnts for mthod dclarations ar dnd as follows : τ dcl dcl 1m1 : τ 1 status, τ 1 stmt 1 : t 1... τ dcl n1... dcl nmn : τ n status, τ n stmt n : t n t 1 =... = t n = void τ dirction? void dploy { branch branch 1 {dcl 11...dcl 1m1 stmt 1 }... branch branch n {dcl n1...dcl nmn stmt n }}

176 154 SPL Smantics mthod_nam {dploy, undploy, unrgistr, nd_dialog} τ dcl dcl 1m1 : τ 1 void, τ 1 stmt 1 : t 1... τ dcl n1... dcl nmn : τ n void, τ n stmt n : t n t 1 =... = t n = void τ dirction? void mthod_nam { branch branch 1 {dcl 11...dcl 1m1 stmt 1 }... branch branch n {dcl n1...dcl nmn stmt n }} τ dcl dcl 1m1 : τ 1 void, τ 1 stmt 1 : t 1... τ dcl n1... dcl nmn : τ n void, τ n stmt n : t n t 1 =... = t n = void τ dirction? void ACK () { branch branch 1 {dcl 11...dcl 1m1 stmt 1 }... branch branch n {dcl n1...dcl nmn stmt n }} mthod_nam {REGISTER, REREGISTER, INVITE, REINVITE, CANCEL, BYE} τ dcl dcl 1m1 : τ 1 rspons, τ 1 stmt 1 : t 1... τ dcl n1... dcl nmn : τ n rspons, τ n stmt n : t n t 1 =... = t n = rspons τ dirction? rspons mthod_nam () { branch branch 1 {dcl 11...dcl 1m1 stmt 1 }... branch branch n {dcl n1...dcl nmn stmt n }} Th judgmnts for programs ar dnd as follows : dcl p1... dcl pa : τ p τ p dcl r1... dcl rc : τ r τ r dcl d1... dcl d : τ d srvic srvic { procssing {dcl p1... dcl pa τ p mthod p1... τ p mthod pb τ r mthod r1... τ r mthod rd τ d mthod d1... τ d mthod df mthod p1... mthod pb rgistration {dcl r1... dcl rc mthod r1... mthod rd dialog {dcl d1... dcl d mthod d1... mthod df }}}} Th typ chcking ruls ar, howvr, not sucint to nsur that a SPL program is wll-formd. Othr proprtis to considr includ th following : Thr is at most on incoming and at most on outgoing handlr for ach mthod nam. Thr is at most on succssful forward pr dialog handlr. Thr can b multipl succssful forwards for a rgistration. Thr is somthing to vrify about th branch nams. Onc a branch is cratd, it has to b usd (or matchd by dfault) in vry handlr that can b xcutd subsquntly. Actually, th smantics dosn't car about this. If th branch is not dnd, th mssag is simply forwardd.

177 Addrsss 155 Assignmnts to hadr lds should b chckd as to whthr th ld is assignabl. Forward cannot appar in a dclaration, vn th dclaration of a local variabl. Handlrs for control mthods, i.., dploy, undploy, unrgistr, and nd_dialog, cannot rfr to anything about a mssag, such as hadrs or rqusturi. Thy cannot us forward. A handlr that has void rturn typ must us forward in tail position. If forward succds or dos not succd, thr ar som corrsponding constraints on th rturn valu. B.3 Addrsss An addrss is a squnc of uniqu idntirs dnd as follows. labl = sssion_typ id, whr id is any form of idntir uniqu within th sssion_typ. addrss = labl list Th sssion typs dpnd on th protocol bing addrssd. For SPL, w thus hav : sssion_typ = {srvic, rg, dialog} In practic, within a givn addrss, th squnc of sssion typs rad from lft to right form a non-mpty prx of a path in a tr dscribing sssion rlationships. For xampl, if w wr to add subscriptions to SPL, th tr would b as follows : srvic rg dialog subscription Givn such a tr, a valid addrss is on that contains a prx of th squnc of sssion typs on a path from th root to a laf of a tr, whr som of th sssion typs ar optional. For xampl, for SPL rg is optional, and thus valid addrsss hav on of th following forms : (srvic, x) (srvic, x), (rg, y) (srvic, x), (rg, y), (dialog, z) (srvic, x), (rg, y), (subscription, a) (srvic, x), (dialog, z) (srvic, x), (subscription, a) Th following functions ar availabl for manipulating addrsss : parnt : addrss addrss slf : addrss labl srvic : addrss labl Ths functions ar dnd as follows : n 1 parnt( labl 1,..., labl n ) = labl 1,..., labl n 1 n 1 slf( labl 1,..., labl n ) = labl n n 1 srvic( labl 1,..., labl n ) = labl 1

178 156 SPL Smantics Ths functions can also b applid to lists of itms in on-to-on mapping with a list of addrsss, such as th list of associatd nvironmnts. B.4 Global Stat Th global stat, σ dscribs th stat of th various sssions and th rlationships btwn thm. Th stat maps an addrss to a conguration, dscribd as follows : stat = addrss branch list status (var valu) addrss list status = bool bool string int status is a tupl composd of four pics of information : liv, prsistnt, clos_fn, and opn. liv indicats whthr th sssion is accpting mssags, ithr its own mssags or crat sssion mssags of th immdiat subsssions. Th valu is tru if this is th cas. prsistnt indicats whthr on nding th sssion, th data associatd with th sssion prsists until th closing of all immdiat subsssions. Th valu is tru if this is th cas. This ld only has a maningful valu if liv is fals, as it is at th momnt of nding th sssion that th smantics chooss whthr th nding of th sssion is prsistnt. clos_fn is a string indicating th nam of th handlr to xcut on nding th sssion, or if thr is non. opn is an intgr indicating how many transactions ar in progrss at th currnt lvl. addrss list is th list of addrsss of th subsssions. Thr ar various kinds of congurations dpnding on th sssion bing modld : Dialog : In this cas, th list of addrsss is always mpty, prsistnt is fals (sinc a dialog has no subsssions, whthr it is prsistnt or not dosn't mattr), and th string componnt has valu nd_dialog. Rgistration : In this cas, th list of addrsss always contains only addrsss of dialogs. Th branch list componnt always contains only on lmnt. Th string componnt has valu unrgistr. Srvic : In this cas, th list of addrsss always contains only addrsss of rgistrations. Th branch list componnt always contains on lmnt. Th string componnt has valu undploy. If a sssion has mor than on kind of subsssion (i.., if w add subscriptions as subsssions of rgistrations), thn th addrsss of ths dirnt kinds of subsssions ar all mixd togthr in th addrss list componnt. Th information about a spcic kind of subsssion can b obtaind by ltring on th sssion_typ in th labl at th nd of ach addrss. B.5 Usful Functions W dn th _ notation to ignor a givn objct ld whn it is uslss in a particular contxt. Th notation + concatnats two lists. W dn som functions for accssing and updating th global stat σ. Th typs of ths functions ar as follows : init_sssion : stat addrss branch list bool bool string int stat lookup_dcls : program stat addrss dcl list lookup_handlrs : program stat addrss handlrs lookup_branchs : stat addrss branch list lookup_liv : stat addrss bool lookup_prsistnt : stat addrss bool

179 Usful Functions 157 lookup_clos_fn : stat addrss string lookup_opn : stat addrss int lookup_nvs : stat addrss (var valu) list lookup_dpndnts : stat addrss addrss list updat_branchs : stat addrss branch list stat st_prsistnc : stat addrss bool stat inc_opn : stat addrss stat dc_opn : stat addrss stat updat_nvs : stat addrss (var valu) list stat dlt_cong : stat addrss stat Ths functions ar dnd in trms of th functions gt_cong : stat addrss cong and st_cong : stat addrss cong stat, which ar dnd as follows : gt_cong(σ, addrss) = σ(addrss) st_cong(σ, addrss, cong) = σ[addrss cong] Th dnitions of th abov functions ar thn as follows : parnt(addrss) = cong = branchs, liv, prsistnt, clos_fn, opn,, σ = st_cong(σ, addrss, cong) init_sssion(σ, addrss, branchs, liv, prsistnt, clos_fn, opn) = σ parnt(addrss) gt_cong(σ, parnt(addrss)) = branchs p, status p, nv p, subsssions p st_cong(σ, parnt(addrss), branchs p, status p, nv p, addrss :: subsssions p ) = σ cong = branchs, liv, prsistnt, clos_fn, opn,, σ = st_cong(σ, addrss, cong) init_sssion(σ, addrss, branchs, liv, prsistnt, clos_fn, opn) = σ slf(addrss) = sssion_typ, lookup_dcls(φ, addrss) = φ dcls (srvic(addrss))(sssion_typ) lookup_handlrs(φ, addrss) = φ handlrs (srvic(addrss)) gt_cong(σ, addrss) = branchs, status, nv, subsssions lookup_branchs(σ, addrss) = branchs gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions lookup_liv(σ, addrss) = liv gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions lookup_prsistnt(σ, addrss) = prsistnt gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions lookup_clos_fn(σ, addrss) = clos_fn gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions lookup_opn(σ, addrss) = opn lookup_nvs(σ, ) =

180 158 SPL Smantics gt_cong(σ, addrss) =,, nv, lookup_nvs(σ, parnt(addrss)) = nvs lookup_nvs(σ, addrss) = nvs ++ nv gt_cong(σ, addrss) = branchs, status, nv, subsssions lookup_dpndnts(σ, addrss) = subsssions gt_cong(σ, addrss) =, status, nv, subsssions st_cong(σ, addrss, branchs, status, nv, subsssions ) = σ updat_branchs(σ, addrss, branchs) = σ Aftr a call to st_prsistnc, th liv attribut is always fals. Th boolan that is passd to st_prsistnc is th prsistnc. Thr ar two ruls bcaus it dosn't mak sns for somthing that is not liv and not prsistnt to bcom prsistnt. In this cas, as tratd by th scond rul, th prsistnc is ignord. gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions liv = tru prsistnt = tru st_cong(σ, addrss, branchs, fals, prsistnt, clos_fn, opn, nv, subsssions ) = σ st_prsistnc(σ, addrss, prsistnt) = σ gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions liv = fals prsistnt = fals st_prsistnc(σ, addrss, prsistnt) = σ gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions st_cong(σ, addrss, branchs, liv, prsistnt, clos_fn, opn + 1, nv, subsssions ) = σ inc_opn(σ, addrss) = σ gt_cong(σ, addrss) = branchs, liv, prsistnt, clos_fn, opn, nv, subsssions st_cong(σ, addrss, branchs, liv, prsistnt, clos_fn, opn 1, nv, subsssions ) = σ dc_opn(σ, addrss) = σ updat_nvs(σ,, ) = σ gt_cong(σ, addrss) = branchs, status,, subsssions st_cong(σ, addrss, branchs, status, slf(nvs), subsssions ) = σ updat_nvs(σ, parnt(addrss), parnt(nvs)) = σ updat_nvs(σ, addrss, nvs) = σ In th scond rul for dlt_cong, w dlt th addrss from th addrss list of th parnt. parnt(addrss) = st_cong(σ, addrss, ) = σ dlt_cong(σ, addrss) = σ parnt(addrss) st_cong(σ, addrss, ) = σ gt_cong(σ, parnt(addrss)) = branchs, status, nv, subsssions st_cong(σ, parnt(addrss), branchs, status, nv, subsssions addrss ) = σ dlt_cong(σ, addrss, nvs) = σ

181 Sssion Managmnt 159 B.6 Sssion Managmnt In trms of th prvious functions, w dn th functions crat_sssion, prpar_mthod_invocation, continu_sssion, and nd_sssion, having th following typs : crat_sssion : program stat addrss branch list string stat prpar_mthod_invocation : program stat addrss dirction mthod dcl list stmt nv list stat continu_sssion : program stat addrss nv list branch list stat nd_sssion : program stat addrss stat Th dnitions of ths functions ar as follows. In th scond rul, handlrs rturns th paramtr m of th mthod, and th local dclarations dcls and th cod stmt associatd with th givn branch. lookup_dcls(φ, addrss) = dcls init_sssion(σ, addrss, branchs, tru,, clos_fn, 0) = σ lookup_nvs(σ, parnt(addrss)) = parnt_nvs parnt_nvs,,, = dcls sssion_nv updat_nvs(σ, addrss, parnt_nvs ++ sssion_nv ) = σ crat_sssion(φ, σ, addrss, branchs, clos_fn) = σ lookup_handlrs(φ, addrss) = handlrs lookup_branchs(σ, addrss) = branchs handlrs(dirction, mthod, branchs) = dcls, stmt lookup_nvs(σ, addrss) = nvs inc_opn(σ, addrss) = σ prpar_mthod_invocation(φ, σ, addrss, dirction, mthod) = dcls, stmt, nvs, σ updat_nvs(σ, addrss, nvs) = σ updat_branchs(σ, addrss, branchs) = σ dc_opn(σ, addrss) = σ lookup_liv(σ, addrss) = tru continu_sssion(φ, σ, addrss, nvs, branchs) = σ updat_nvs(σ, addrss, nvs) = σ updat_branchs(σ, addrss, branchs) = σ dc_opn(σ, addrss) = σ lookup_liv(σ, addrss) = fals nd_sssion(φ, σ, addrss) = σ continu_sssion(φ, σ, addrss, nvs, branchs) = σ All of th rmaining ruls ar usd to dn nd_sssion. Th dnition uss th functions nd_parnts, nd_childrn, and clos_sssion, having th following typs : nd_childrn : program stat addrss stat nd_parnts : program stat addrss stat clos_sssion : program stat addrss stat Ending a sssion ntails nding all th childrn, with nd_childrn, and thn, if this procss is succssful, nding any of th parnts that ar not liv. Ending th childrn ntails rst moving down th tr of childrn, stting liv in ach cas to fals, and thn starting from th

182 160 SPL Smantics lavs, closing ach child that has no pnding transactions and no dpndnts. This procss is oblivious to whthr th childrn ar prsistnt. Not, howvr, that whn th currnt lvl is prsistnt, this procss is only initiatd whn thr ar no childrn, in which cas nd_childrn only closs th currnt lvl. Ending th parnts ntails looking for parnts that ar not liv and that if prsistnt hav no dpndnts. This procss works its way up th tr, stopping whn raching a parnt that dos not hav ths proprtis, or whn raching th root of th tr. clos_sssion invoks th clos handlr of th currnt sssion, onc w hav dcidd that th currnt sssion should b ndd. Whn thr is cod to valuat, it is valuatd with rspct to th mpty continuation bcaus th cod cannot us forward. Th following ruls dcid whthr to nd th sssion at th currnt lvl. On invoking nd_sssion, th liv attribut of th currnt lvl must b fals. lookup_prsistnt(σ, addrss) = tru lookup_dpndnts(σ, addrss) nd_sssion(φ, σ, addrss) = σ lookup_prsistnt(σ, addrss) = fals lookup_dpndnts(σ, addrss) = nd_childrn(φ, σ, addrss) = σ nd_parnts(φ, σ, parnt(addrss)) = σ nd_sssion(φ, σ, addrss) = σ Th following ruls nd th sssion and all of its childrn, starting at th lavs. Ths ruls assum that σ is up to dat with rspct to th various sssion nvironmnts. nd_childrn' of typ program stat addrss labl list stat is usd to loop ovr th list of dpndnts. lookup_dpndnts(σ, addrss) = lookup_opn(σ, addrss) = 0 clos_sssion(φ, σ, addrss) = σ nd_childrn (φ, σ, addrss, ) = σ lookup_dpndnts(σ, addrss) lookup_opn(σ, addrss) > 0 nd_childrn (φ, σ, addrss, ) = σ st_prsistnc(σ, child_addrss, fals) = σ nd_childrn(φ, σ, child_addrss) = σ nd_childrn (φ, σ, addrss, π) = σ nd_childrn (φ, σ, addrss, child_addrss :: π) = σ nd_childrn (φ, σ, addrss, lookup_dpndnts(σ, addrss)) = σ nd_childrn(φ, σ, addrss) = σ Th following ruls nd any of th parnts that ar not liv and now hav no mor subsssions. Ths ruls assum that σ is up to dat with rspct to th various sssion nvironmnts. nd_parnts(φ, σ, ) = σ lookup_liv(σ, addrss) = tru lookup_dpndnts(σ, addrss) nd_parnts(φ, σ, addrss) = σ

183 Cor Languag Constructs 161 lookup_liv(σ, addrss) = fals lookup_dpndnts(σ, addrss) = clos_sssion(φ, σ, addrss) = σ nd_parnts(φ, σ, parnt(addrss)) = σ nd_parnts(φ, σ, addrss) = σ Th following ruls prform th actions rquird locally to clos a singl sssion. Ths ruls assum that σ is up to dat with rspct to th various sssion nvironmnts. lookup_clos_fn(σ, addrss) = dlt_cong(σ, addrss) = σ clos_sssion(φ, σ, addrss) = σ lookup_clos_fn(σ, addrss) = clos_fn prpar_mthod_invocation(φ, σ, addrss,, clos_fn) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs,,, τ, r, CLOSE = dcls, stmt, σ dlt_cong(σ, addrss) = σ clos_sssion(φ, σ, addrss) = σ updat_nvs(σ, addrss, ρ nvs ) = σ σ, addrss, ρ = CLOSE,,, σ B.7 Cor Languag Constructs In this sction, w prsnt som usful nvironmnts which ar manipulatd by th smantic ruls. Thn, w prsnt th smantic rul for ach kind of languag constructs : dclarations, handlrs, statmnts and xprssion. B.7.1 Environmnts Th smantics uss th following nvironmnts : nvs : A squnc of nvironmnts corrsponding to th currnt addrss. For SPL, this contains at most th following nvironmnts : nv : Th srvic nvironmnt. rid_rg_nv : Th rgistr nvironmnt for a rgistration instanc. did_dialog_nv : Th dialog nvironmnt for a dialog instanc. mssag_info : A pair of th rqusturi and an nvironmnt containing bindings drivd from th mssag hadrs. local_nv : Th local nvironmnt. All of ths nvironmnts (xcpt nvs) ar mappings from variabls to valus. Th smantics rfrs to ths nvironmnts collctivly as ρ which is a tupl of th abov nvironmnts in th abov ordr. Th individual nvironmnts ar accssd by.g. ρ mssag_info. In th valuation of th ntry point of a handlr, th nvironmnt r is cratd, which is th sam as ρ, but dos not contain a local nvironmnt.

184 162 SPL Smantics B.7.2 Judgmnts for Dclarations, Statmnts and Exprssions Th smantics is organizd as an abstract machin containing th following kinds of con- gurations : Mthod invocation : mssag, φ, σ = mi srvic A mssag has th form mthod, dirction, hadrs, rq, whr rq is th rqust URI of th mssag. Handlr body : τ, r, s = h dcls, stmt τ givs contxt information and has th form σ, addrss. This information is not usd in th normal cours of xcuting th body of a handlr, but is usd in th tratmnt of (paralll) forward. r is th top lvl nvironmnt composd of hirarchical sssion nvironmnt and mssag nvironmnt (rqust URI and hadrs). s is th stack of continuations. Dclaratrion : ρ = d dcls : nv ρ is similiar to r but also includ th local nvironmnt of th invokd mthod. Statmnt : τ, ρ, s = s stmt Statmnt continuation : τ, ρ = sc s, rsp, branch rsp is ithr a rspons or. is usd for statmnts othr than rturn, which do not hav a rspons. branch is dnd similarly. Exprssion : τ, ρ, s = xp Exprssion continuation : τ, ρ = c s, valu valu is an arbitrary valu, which is not ncssarily a rspons. SIP : A SIP conguration is a call to a function of th undrlying platform, such as forward. Trminal : rsp, σ Th xcution of a handlr is rprsntd by a squnc of congurations, rlatd according to th smantic ruls. Th initial conguration is a srvic conguration. Th nal conguration is a trminal conguration. A conguration btwn th initial and nal congurations is any kind of conguration othr than a srvic conguration or a trminal conguration. Th smantics is ssntially a continuation-basd smantics, but whr th continuations hav bn dfunctionalizd as abstract machin instructions. W introduc th various instructions as thy ar ndd. In gnral, a smantic rul has th form : prcondition 1. prcondition n conguration conguration prcondition 1... prcondition n dscrib oprations that must b prformd givn th information providd in conguration in ordr to produc conguration. B.7.3 Entry Point of th Smantics Th rst stp of th smantics is to idntify th handlr to xcut.

185 Cor Languag Constructs 163 Srvic Mthods Th only srvic mthods ar dploy, which is usd to crat a srvic, and undploy, which is usd to nd a srvic. Th following ruls dn th smantics of dploy, which is assumd lik all control mthods, to succd. Thr is on continuation DEPLOY φ. addrss = srvic crat_sssion(φ, σ, addrss, dfault, undploy) = σ prpar_mthod_invocation(φ, σ, addrss,, dploy) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs,, dploy,,,, φ, σ = mi srvic τ, r, DEPLOY φ = h dcls, stmt continu_sssion(φ, σ, addrss, ρ nvs, b ) = σ σ, addrss, ρ, = sc DEPLOY φ, SUCCESS, b, σ st_prsistnc(σ, addrss, fals) = σ continu_sssion(φ, σ, addrss, ρ nvs, b ) = σ σ, addrss, ρ, = sc DEPLOY φ, ERROR, b, σ Th smantics of undploy simply nds th sssion. Bcaus a srvic is not prsistnt, this nds all subsssions as wll. addrss = srvic st_prsistnc(σ, addrss, prsistnt) = σ nd_sssion(φ, σ, addrss) = σ undploy(prsistnt),,,, φ, σ = mi srvic, σ Rgistration Mthods Th only rgistration mthods ar initial REGISTER, which is usd to crat a rgistration, and mdial REGISTER, which is usd to kp th rgistration aliv. An initial REGISTER crats an ntry for a nw rgistration id, initializs th rgistration variabls, and sts th liv bit associatd with th rgistration ntry to tru. Th initial valus of th rgistration variabls cannot rfr to th branch lists of th mssag (hadrs or rqust URI). A mdial REGISTER can updat th variabls associatd with th rgistration. Th following thr ruls dn th smantics of an initial REGISTER. Thr is on continuation : INITIAL_REG φ. addrss = srvic, rid crat_sssion(φ, σ, addrss, dfault, unrgistr) = σ prpar_mthod_invocation(φ, σ, addrss, dirction, REGISTER) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs, rq, hadrs REGISTER(rid), dirction, rq, hadrs, φ, σ = mi srvic τ, r, INITIAL_REG φ = h dcls, stmt

186 164 SPL Smantics Thr ar two ruls for th continuation INITIAL_REG φ : on whr th rgistration has succdd and on whr it has faild. continu_sssion(φ, σ, addrss, ρ nvs, b ) = σ σ, addrss, ρ = sc INITIAL_REG φ, /SUCCESS/rsp(rsp_hadrs), b /SUCCESS/rsp(rsp_hadrs), σ st_prsistnc(σ, addrss, fals) = σ continu_sssion(φ, σ, addrss, ρ nvs, b ) = σ σ, addrss, ρ = sc INITIAL_REG φ, /ERROR/rsp(rsp_hadrs), b /ERROR/rsp(rsp_hadrs), σ Th following rul is for a mdial REGISTER, i.. REREGISTER. Thr is on continuation in this cas : MEDIAL_REG φ. addrss = srvic, rid prpar_mthod_invocation(φ, σ, addrss, dirction, REREGISTER) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs, rq, hadrs REREGISTER(rid), dirction, rq, hadrs, φ, σ = mi srvic τ, r, MEDIAL_REG φ = h dcls, stmt continu_sssion(φ, σ, addrss, ρ nvs, b ) = σ σ, addrss, ρ = sc MEDIAL_REG φ, rsp, b rsp, σ Th liftim of a rgistration is limitd by a hadr associatd with th REGISTER mthod (ithr initial or mdial) or a dfault valu. At th tim of this xpiration, th support for SPL in th undrlying platform gnrats a rgistration_timout(srvic, rid, φ, σ) mssag. This mssag sts th liv ld of th rgistration to fals. If thr ar not mor sssions associatd with th rgistration, thn th rgistration is dltd. If thr ar still sssions associatd with th rgistration, thn th rgistration is dltd on th compltion of a subsqunt BYE mthod whn thr ar no rmaining liv sssions. All of this is takn car of by nd_sssion, bcaus a rgistration is dclard to b prsistnt. addrss = srvic, rid st_prsistnc(σ, addrss, tru) = σ nd_sssion(φ, σ, addrss) = σ rgistration_timout(srvic, rid, φ, σ), σ addrss = srvic, rid st_prsistnc(σ, addrss, prsistnt) = σ nd_sssion(φ, σ, addrss) = σ unrgistr(srvic, rid, φ, σ,prsistnt), σ

187 Cor Languag Constructs 165 Dialog Mthods A dialog is initiatd by an INVITE. As for REGISTER, thr ar two kinds of INVITE : initial and mdial. Thr is no nal INVITE, bcaus that is implmntd as BYE. If th srvic includs a rgistration block, thn INVITE will only bn invokd whn REGISTER has prviously bn invokd, and th call to INVITE will contain information about th associatd rid. If th srvic dos not includ a rgistration block, thn th mthod has only did as an argumnt, and th addrss is constructd as srvic, did. This stratgy applis to th othr dialog mthods as wll. Th smantics of initial INVITE is dnd by th following ruls. Thr is on continuation : INITIAL_INVITE dirction handlrs. addrss = srvic, rid, did lookup_branchs(σ, parnt(addrss)) = branch crat_sssion(φ, σ, addrss, branch, undialog) = σ prpar_mthod_invocation(φ, σ, dirction, INVITE) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs, rq, hadrs INVITE(rid, did), dirction, rq, hadrs, φ, σ = mi srvic τ, r, INITIAL_INVITE φ = h dcls, stmt Bcaus w do not control th ordring in which mssags ar transmittd to th srvic, thr ar a numbr of thr possibilitis, as shown by th following diagram. At ach nod, th boolan valu indicats whthr th dialog is liv and th intgr valu indicats th numbr of opn transactions. At any point whr th nod contains fals and 0, th sssion will b ndd whn by continu_sssion. inv ok tru,1 canc rsp tru,0 inv rr tru,2 rsp fals,1canc fals,0 cancl canc rsp invit inv ok tru,1 inv ok tru,0 tru,1 tru,0 inv rr fals,0 inv rr fals,0 Th ruls ar as follows : lookup_branchs(σ, addrss) = branchs continu_sssion(φ, σ, addrss, ρ nvs, add(b, branchs)) = σ σ, addrss, ρ = sc INITIAL_INVITE φ, /SUCCESS/rsp(rsp_hadrs), b /SUCCESS/rsp(rsp_hadrs), σ Th function add(b,branchs) adds b at th bginning of branchs if b branchs and rturns branchs othrwis.

188 166 SPL Smantics st_prsistnc(σ, addrss, fals) = σ lookup_branchs(σ, addrss) = branchs continu_sssion(φ, σ, addrss, ρ nvs, add(b, branchs)) = σ σ, addrss, ρ = sc INITIAL_INVITE φ, /ERROR/rsp(rsp_hadrs), b /ERROR/rsp(rsp_hadrs), σ Th following rul is for mthods that occur within an xisting dialog. Th mthod can b ACK, CANCEL or mdial INVITE. Thr is on continuation : MEDIAL_INVITE φ. addrss = srvic, rid, did prpar_mthod_invocation(φ, σ, addrss, dirction, REINVITE) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs, rq, hadrs REINVITE(rid, did), dirction, rq, hadrs, φ, σ = mi srvic τ, r, MEDIAL_INVITE φ = h dcls, stmt lookup_branchs(σ, addrss) = branchs continu_sssion(φ, σ, addrss, ρ nvs, add(b, branchs)) = σ σ, addrss, ρ = sc MEDIAL_INVITE φ, rsp, b rsp, σ Th following ruls ar for BYE, which nds a dialog. If th rgistration is still liv or thr ar othr dialogs associatd with th rgistration, thn w simply dlt th dialog from th dialog nvironmnt. If th rgistration is no longr liv and thr ar no othr dialogs associatd with th rgistration, thn w run th unrgistr cod and dlt th ntir rgistration (including th dialog). Thr is on continuation : BYE φ. addrss = srvic, rid, did prpar_mthod_invocation(φ, σ, addrss, dirction, BYE) = dcls, stmt, nvs, σ τ = σ, addrss r = nvs, rq, hadrs BYE(rid, did), dirction, rqhadrs, φ, σ = mi srvic τ, r, BYE φ = h dcls, stmt If th rgistration has not ndd or th rgistration has ndd and thr ar dialogs othr than th currnt on, thn th rgistration is prsrvd and w only nd th dialog. Othrwis w nd both th dialog and th nclosing rgistration. This is takn car of nd_sssion, bcaus rgistration is prsistnt. lookup_branchs(σ, addrss) = branchs st_prsistnc(σ, addrss, fals) = σ continu_sssion(φ, σ, addrss, ρ nvs, add(b, branchs)) = σ σ, addrss, ρ = sc BYE φ, rsp, b rsp, σ Th following only occurs whn no ACK appars aftr an INVITE. addrss = srvic, rid, did st_prsistnc(σ, addrss, fals) = σ nd_sssion(φ, σ, addrss) = σ dialog_timout(srvic, rid, did, φ, σ), σ

189 Cor Languag Constructs 167 Dfault Handling Whn thr is no handlr, and thus nothing to do, th smantics just forwards th mssag as normal. Actually, th smantics dos not distinguish btwn th cas whr thr is no handlr and th cas whr thr is a handlr but thr is no branch. Th lattr cas should nvr occur. Th following rul is for an REGISTER : addrss = srvic, rid crat_sssion(φ, σ, addrss, dfault, unrgistr) = σ prpar_mthod_invocation(φ, σ, addrss, dirction, REGISTER) =,, nvs, σ τ = σ, addrss ρ = nvs, rq, hadrs REGISTER(rid), dirction, rq, hadrs, φ, σ = mi srvic τ, ρ, INITIAL_REG φ = h, rturn forward branch dfault Th ruls for th othr mthods ar similar, i.., w prtnd that th statmnt is rturn forward branch dfault and thn us th original continuation. B.7.4 Smantics of Handlr Bodis A handlr can only dclar local variabls at th root of th body. Th ruls hr valuat such dclarations and thn continu with th smantics of statmnts. Not that vn th variabls associatd with whn must b dclard at th top lvl, and thus whn is implmntd by assignmnts. This implis that all whn-dclard variabls (lik all othr local dclarations) hav to b givn uniqu nams. r = nvs, mssag_info nvs, mssag_info, = d dcls : local_nv ρ = nvs, mssag_info, local_nv τ, r, s = h dcls, stmt τ, ρ, s = s stmt B.7.5 Squnc Smantics of Statmnts W assum that a squnc has on of th following forms : {} {stmt 1 stmt 2 } Ths forms ar not particularly convnint for programming, but it is asy to turn any squnc statmnt into on of ths forms, ithr by adding bracs or by dropping bracs that only nclos on statmnt. τ, ρ, s = s {} τ, ρ = sc s,, In th cas of a squnc of two statmnts, thr is on continuation : SEQ stmt 2.

190 168 SPL Smantics τ, ρ, s = s {stmt 1 stmt 2 } τ, ρ, (SEQ stmt 2 ) :: s = s stmt 1 τ, ρ = sc (SEQ stmt 2 ) :: s,, τ, ρ, s = s stmt 2 Assignmnt Not that idntirs and SIP hadrs ar unid ; a SIP hadr is just an idntir that is found in hadrs. In th cas of an assignmnt, thr is on continuation : ASSIGN x. τ, ρ, s = s x = xp τ, ρ, (ASSIGN x) :: s = xp τ, ρ = c (ASSIGN x) :: s, v τ, updat(x, v, ρ) = sc s,, updat(x, v, nvs, rq, hadrs, local_nv ) = updat l (x, v, nvs, rq, hadrs, local_nv), which is dnd as follows : x dom(local_nv) updat l (x, v, nvs, mssag_info, local_nv) = nvs, mssag_info, local_nv[x v] x dom(local_nv) updat h (x, v, nvs, mssag_info) = nvs, mssag_info updat l (x, v, nvs, mssag_info, local_nv) = nvs, mssag_info, local_nv x dom(hadrs) updat h (x, v, nvs, rq, hadrs ) = nvs, rq, hadrs[x v] x dom(hadrs) updat (x, v, nvs) = nvs updat h (x, v, nvs, rq, hadrs ) = nvs, rq, hadrs Rturn x dom(nv) updat (x, v, nvs ++ nv ) = nvs ++ nv[x v] x dom(nv) updat (x, v, nvs) = nvs updat (x, v, nvs ++ nv ) = nvs ++ nv Rturn is associatd with on continuation : RETURN b. τ, ρ, s = s rturn xp branch b ; τ, ρ, (RETURN b) :: s = xp τ, ρ = c (RETURN b) :: s, rsp τ, ρ = sc s, rsp, b Th following rturns no valu but changs th branch.

191 Cor Languag Constructs 169 τ, ρ, s = s rturn branch b ; τ, ρ = sc s,, b If If is associatd with on continuation : IF stmt 1 stmt 2. τ, ρ, s = s if (xp) stmt 1 ls stmt 2 τ, ρ, (IF stmt 1 stmt 2 ) :: s = xp τ, ρ = c (IF stmt 1 stmt 2 ) :: s, tru τ, ρ, s = s stmt 1 τ, ρ = c (IF stmt 1 stmt 2 ) :: s, fals τ, ρ, s = s stmt 2 Whn τ, ρ, s = s whn xp (hd 1 t 1 x 1,..., hd n t n x n ) stmt 1 ls stmt 2 τ, ρ, (WHEN hd 1 t 1 x 1,..., hd n t n x n stmt 1 stmt 2 ) :: s = xp {hd 1,..., hd n } dom(hadrs) ρ = updat(x 1, corc(hadrs(hd 1 ), t 1 ),... updat(x n, corc(hadrs(hd n ), t n ), ρ)...) τ, ρ = c (WHEN hd 1 t 1 x 1,..., hd n t n x n stmt 1 stmt 2 ) :: s, rq, hadrs τ, ρ, s = s stmt 1 {hd 1,..., hd n } dom(hadrs) τ, ρ = c (WHEN hd 1 t 1 x 1,..., hd n t n x n stmt 1 stmt 2 ) :: s, rq, hadrs τ, ρ, s = s stmt 2 {hd 1,..., hd n } dom(rsp_hadrs) ρ = updat(x 1, corc(rsp_hadrs(hd 1 ), t 1 ),... updat(x n, corc(rsp_hadrs(hd n ), t n ), ρ)...) τ, ρ = c (WHEN hd 1 t 1 x 1,..., hd n t n x n stmt 1 stmt 2 ) :: s, cod(rsp_hadrs) τ, ρ, s = s stmt 1 {hd 1,..., hd n } dom(rsp_hadrs) τ, ρ = c (WHEN hd 1 t 1 x 1,..., hd n t n x n stmt 1 stmt 2 ) :: s, cod(rsp_hadrs) τ, ρ, s = s stmt 2

192 170 SPL Smantics With W assum thr is only on binding, as multipl bindings can b implmntd by a squnc of withs. Thr ar two continuations : WITH1 ld xp 2 and WITH2 ld rsp. This statmnt could only b usd to updat a rqust with th this xprssion. τ, ρ, s = s xp 1 with ld = xp 2 ; τ, ρ, (WITH1 ld xp 2 ) :: s = xp 1 τ, ρ = c (WITH1 ld xp 2 ) :: s, v τ, ρ, (WITH2 ld v) :: s = xp 2 ρ = nvs, rq, hadrs, local_nv nvs, rq, hadrs[ld v], local_nv = ρ τ, ρ = c (WITH2 ld rq, hadrs ) :: s, v τ, ρ = sc s,, B.7.6 Smantics of Exprssions W considr a simplid st of xprssions in which thr ar no with xprssions, idnti- rs and SIP hadrs ar unid as dscribd abov for assignmnts, th only binary oprator is ==, thr ar no unary oprators, thr ar no pop xprssions, and thr ar no function calls. An xprssion and a branch ar obligatory in vry (paralll) forward. Th xprssion must valuat to a list. W add an xprssion for making a list out of th valu of a singl xprssion so that th valu of rqusturi can b put into a list to mak a suitabl argumnt for th trivial cas. An xprssion can rinvok th undrlying machin, via a forward or paralll forward. For this, w hav to bring σ up to dat with rspct to th changs that hav occurrd in nvs. Whn control rturns to th smantics, w similarly hav to obtain th nw nvs. For ths oprations, w hav to kp th nvironmnts sparatd. Th smantics of xprssions also nds to know σ, and th currnt addrss. Forward updat_nvs(σ, addrss, ρ nvs ) = σ ρ mssag_info = m, rq, hadrs σ, addrss, ρ, s = forward forward(rq, fals, (FORWARD addrss ρ mssag_info ρ local_nv ) :: s, hadrs, σ ) τ, ρ, s = forward xp τ, ρ, FORWARD_EXP :: s = xp updat_nvs(σ, addrss, ρ nvs ) = σ ρ mssag_info = m, rq, hadrs σ, addrss, ρ = c FORWARD_EXP :: s, v forward(v, fals, (FORWARD addrss ρ mssag_info ρ local_nv ) :: s, hadrs, σ )

193 Cor Languag Constructs 171 lookup_nvs(σ, addrss) = nvs τ = σ, addrss ρ = nvs, mssag_info, local_nv forward_rspons(rsp, (FORWARD addrss mssag_info local_nv) :: s, σ) τ, ρ = c s, rsp Paralll Forward ρ mssag_info = m, rq, hadrs τ, ρ, s = paralll forward forward(rq, tru, (FORWARD addrss ρ mssag_info ρ local_nv ) :: s, hadrs, σ ) τ, ρ, s = paralll forward xp τ, ρ, PFORWARD :: s = xp updat_nvs(σ, addrss, ρ nvs ) = σ ρ mssag_info = m, rq, hadrs σ, addrss, ρ = c PFORWARD :: s, v forward(v, tru, (FORWARD srvic rid ρ mssag_info ρ local_nv ) :: s, hadrs, σ ) Th call to forward vntually producs a call to forward_rspons. Th smantics of this is shown abov, in th tratmnt of forward. List Cration List cration is associatd with on continuation : LIST. τ, ρ, s = < xp > τ, ρ, LIST :: s = xp τ, ρ = c LIST :: s, v τ, ρ = c s, v Equality Equality is associatd with two continuations : EQ1 xp 2 and EQ2 v 1. Whn on argumnt is a rspons and th othr is a cod constant, th quality us th rspons cod hirarchy. A rspons is qual to a cod constant if th cod rspons is strictly qual or is in th sub-tr of th cod constant hirarchy. τ, ρ, s = xp 1 == xp 2 τ, ρ, (EQ1 xp 2 ) :: s = xp 1 τ, ρ = c (EQ1 xp 2 ) :: s, v 1 τ, ρ, (EQ2 v 1 ) :: s = xp 2 τ, ρ = c (EQ2 v 1 ) :: s, v 2 τ, ρ = c s, v 1 == v 2

194 172 SPL Smantics Idntir τ, ρ, s = x τ, ρ = c s, lookup(x, ρ) lookup(x, nvs, m, hadrs, local_nv ) = lookup l (x, nvs, m, hadrs, local_nv), which is dnd as follows : x dom(local_nv) lookup l (x, nvs, mssag_info, local_nv) = local_nv(x) x dom(local_nv) lookup l (x, nvs, mssag_info, local_nv) = lookup h (x, nvs, mssag_info) x dom(hadrs) lookup h (x, nvs, rq, hadrs ) = hadrs(x) x dom(hadrs) lookup h (x, nvs, rq, hadrs ) = lookup (x, nvs) x dom(nv) lookup (x, nvs ++ nv ) = nv(x) x dom(nv) lookup (x, nvs ++ nv ) = lookup (x, nvs) Constant τ, ρ, s = c τ, ρ = c s, c RqustURI ρ mssag_info = rq, hadrs τ, ρ, s = rqusturi τ, ρ = c s, rq This ρ mssag_info = rq, hadrs τ, ρ, s = this τ, ρ = c s, rq, hadrs With W assum thr is only on binding, as multipl bindings can b implmntd by nstd withs. Thr ar two continuations : WITH1 ld xp 2 and WITH2 ld rsp.

195 Cor Languag Constructs 173 τ, ρ, s = xp 1 with ld = xp 2 τ, ρ, (WITH1 ld xp 2 ) :: s = xp 1 τ, ρ = c (WITH1 ld xp 2 ) :: s, v τ, ρ, (WITH2 ld v) :: s = xp 2 τ, ρ = c (WITH2 ld cod(rsp_hadrs)) :: s, v τ, ρ = c s, cod(rsp_hadrs[ld v]) B.7.7 Smantics of Dclarations Th smantics of dclarations is dnd as blow. Each xprssion is valuatd with rspct to th mpty continuation, bcaus w know that thr is no forward in a dclaration, vn th dclaration of a local variabl. This is always invokd with in th local_nv position of ρ. nvs, mssag_info, local_nv = d local_nv, ρ, = xp 1,, = c, v 1 ρ = nvs, mssag_info, local_nv nvs, mssag_info, local_nv[x 1 v 1 ] = d x 2, xp 2,... nv ρ = d x 1, xp 1, x 2, xp 2,... nv

196 174 SPL Smantics

197 Annx C Srvic d l d'attnt n SPL 1 // Call Quuing (QUEUE) 2 3 srvic quu { 4 procssing { 5 6 xtrn string sip_invit ( uri to ); 7 xtrn void sip_by ( string call_id ); 8 9 xtrn void rtp_play ( string call_id, string fil ); 10 xtrn void rtp_bridg ( string call_id_from, string call_id_to ); xtrn int hashtbl_crat ( int siz ); 13 xtrn void hashtbl_add ( int assoc, string ky, string valu ); 14 xtrn string hashtbl_find ( int assoc, string ky ); 15 xtrn void hashtbl_dlt ( int assoc, string ky ); 16 xtrn void hashtbl_clan ( int assoc ); 17 xtrn int hashtbl_lngth ( int assoc ); FIFO string<4> rmov_lmnt ( string call_id, FIFO string<4> list ) { 21 FIFO string<4> tmp_waiting_list; 22 forach ( waiting_sssion in list ) { 23 if ( waiting_sssion!= call_id ) { 24 push tmp_waiting_list waiting_sssion; 25 } 26 } 27 rturn tmp_waiting_list; 28 } void play(string call_id, int indx) { 31 slct(indx) { 32 cas 0: rtp_play(call_id, "attnd.wav"); rturn; 33 cas 1: rtp_play(call_id, "attnd1.wav"); rturn; 34 cas 2: rtp_play(call_id, "attnd2.wav"); rturn; 35 cas 3: rtp_play(call_id, "attnd3.wav"); rturn; 36 cas 4: rtp_play(call_id, "attnd4.wav"); rturn; 37 dfault: rtp_play(call_id, "attnd5+.wav"); rturn; 38 } 39 } int callrs; 42 int calls; 43 int calls_tmp; uri call = sip:[email protected] ; void dploy () { 48 callrs = hashtbl_crat ( 5 ); 175

198 176 Srvic d l d'attnt n SPL 49 calls = hashtbl_crat ( 1 ); 50 calls_tmp = hashtbl_crat ( 5 ); 51 } void undploy () { 54 hashtbl_clan ( callrs ); 55 hashtbl_clan ( calls ); 56 hashtbl_clan ( calls_tmp ); 57 } rgistration { int prsnc = 0; // -1: undf, 0: availabl, 1: busy FIFO string<4> waiting_list; 64 int currntsiz = 4; dialog { rspons incoming INVITE () { 69 if ( prsnc!= -1 ) { 70 if ( currntsiz!= 0 ) { 71 rspons rsp = forward; 72 if ( rsp == /SUCCESS ) { 73 currntsiz = currntsiz - 1; 74 rturn rsp; 75 } ls { 76 rturn /ERROR/SERVER/SERVICE_UNAVAILABLE; 77 } 78 } ls { 79 rturn /ERROR/CLIENT/TEMPORARILY_UNAVAILABLE 80 with { rason = "Too many callrs in hold, plas rtry latr..." }; 81 } 82 } ls { 83 rturn /ERROR/SERVER/SERVICE_UNAVAILABLE; 84 } 85 } void incoming ACK () { 88 string sssion_id = ""; 89 if ( waiting_list == FIFO <> ) { 90 push waiting_list CALL_ID; 91 forward; 92 if ( prsnc == 0 ) { 93 sssion_id = sip_invit ( call ); 94 hashtbl_add ( calls_tmp, sssion_id, CALL_ID ); 95 } ls { 96 play ( CALL_ID, hashtbl_lngth(callrs)); 97 hashtbl_add ( callrs, CALL_ID, sssion_id ); 98 } 99 } ls { 100 push waiting_list CALL_ID; 101 forward; 102 play ( CALL_ID, hashtbl_lngth(callrs)); 103 hashtbl_add ( callrs, CALL_ID, sssion_id ); 104 } 105 } rspons outgoing INVITE () { 108 rspons rs = forward; 109 if ( rs == /ERROR ) { 110 string call_id_associatd = hashtbl_find ( calls_tmp, CALL_ID ); 111 hashtbl_dlt ( calls_tmp, CALL_ID ); 112 play ( call_id_associatd, hashtbl_lngth(callrs)); 113 hashtbl_add ( callrs, call_id_associatd, "" ); 114 }

199 rturn rs; 116 } void outgoing ACK () { 119 forward; 120 prsnc = 1; 121 string call_id_associatd = hashtbl_find ( calls_tmp, CALL_ID ); 122 waiting_list = rmov_lmnt ( call_id_associatd, waiting_list ); 123 currntsiz = currntsiz + 1; 124 hashtbl_add ( callrs, call_id_associatd, CALL_ID ); 125 hashtbl_add ( calls, CALL_ID, call_id_associatd ); 126 hashtbl_dlt ( calls_tmp, CALL_ID ); 127 rtp_bridg ( call_id_associatd, CALL_ID); int i = 0; 130 forach(c in waiting_list) { 131 play(c, i); 132 i = i+1; 133 } 134 } rspons incoming BYE () { 137 if ( FROM!= call ) { 138 string call_id_associatd = hashtbl_find ( callrs, CALL_ID ); 139 if ( call_id_associatd!= "" ) { 140 sip_by ( call_id_associatd ); 141 hashtbl_dlt ( callrs, CALL_ID ); 142 rturn forward; 143 } ls { 144 waiting_list = rmov_lmnt ( CALL_ID, waiting_list ); 145 currntsiz = currntsiz + 1; 146 hashtbl_dlt ( callrs, CALL_ID ); 147 rturn forward; 148 } 149 } ls { 150 string call_id_associatd = hashtbl_find ( calls, CALL_ID ); 151 sip_by ( call_id_associatd ); 152 hashtbl_dlt ( calls, CALL_ID ); 153 rspons rs = forward; 154 prsnc = 0; 155 if ( waiting_list!= FIFO <> ) { 156 string nxt_sssion = top waiting_list; 157 hashtbl_dlt ( callrs, nxt_sssion ); 158 string sssion_id = sip_invit ( call ); 159 hashtbl_add ( calls_tmp, sssion_id, nxt_sssion ); 160 } 161 rturn rs; 162 } 163 } rspons outgoing BYE () { 166 if ( TO!= call ) { 167 hashtbl_dlt ( callrs, CALL_ID); 168 rturn forward; 169 } ls { 170 rspons rs = forward; 171 hashtbl_dlt ( calls, CALL_ID ); 172 prsnc = 0; 173 if ( waiting_list!= FIFO <> ) { 174 string nxt_sssion = top waiting_list; 175 hashtbl_dlt ( callrs, nxt_sssion ); 176 string sssion_id = sip_invit ( call ); 177 hashtbl_add ( calls_tmp, sssion_id, nxt_sssion ); 178 } 179 rturn rs; 180 } } } } } }

200 178 Srvic d l d'attnt n SPL

201 Annx D Pantaxou Languag D.1 Domain Syntax A dscription of an application domain has th following form. struct structnam (xtnds parntstruct)? { (typ id ;) } num numnam = {id 1,..., id n } command commandnam { (typ id(typ 1 id 1,..., typ n id n ) ;) + } srvic srvicnam (xtnds parntsrvic)? { (typ id ;) ((rquirs provids) command<commandnam>(from to) srvicnam ;) ((rquirs provids) vnt<datatypnam>(from to) srvicnam ;) ((rquirs provids) sssion<(?! =)datatypnam>(from to) srvicnam ;) } Th datatyp taxonomy stands for a forst, whil th srvic taxonomy is a tr whos th root must b namd Srvic. A command consists of a group of mthods. Th grammar is dnd as follows : domain ::= datatyp commandintrfac srvic datatyp ::= import idntir struct idntir (xtnds idntir)? {proprty } num idntir = {idntir (, idntir) + } commandintrfac ::= command idntir {mthod } srvic ::= srvic idntir (xtnds idntir)? {proprty functionality } mthod ::= typ idntir ( (typ idntir (, typ idntir) )? ) ; proprty ::= typ idntir ; functionality ::= rquirs intractionmod from idntir ; provids intractionmod to idntir ; bind<functionality, functionality> ; 179

202 180 Pantaxou Languag intractionmod ::= command<idntir > vnt<idntir > sssion<(?! =)idntir > typ ::= idntir primitivtyp primitivtyp ::= bool int string uri void D.2 Domain Static Smantics Th static smantics uss th following typ systm and nvironmnts : Typ Systm Th + oprator is usd to build disjoint unions. PrimitivTyp = Bool + Int + String + URI PrimitivTypWithVoid = PrimitivTyp + Void Dirction = {Rquirs, Provids} Command = Idntir Evnt = Idntir Sssion = Idntir IntractionMod = Command + Evnt + Sssion Bind = (Dirction Sssion Idntir) (Dirction Sssion Idntir) Datatyp = Idntir Typ = PrimitivTyp + Datatyp TypWithVoid = PrimitivTypWithVoid + Datatyp Environmnts and Sts For an nvironmnt, th function dom() rturns th domain of. m is a mthod nvironmnt. m : Idntir (TypWithVoid (Typ list)) c is a command nvironmnt. c : Idntir m p is a proprty nvironmnt. p : Idntir Typ s f is a functionality st. s f consists of triplt (Dirction IntractionMod Idntir) and Bind d is a datatyp nvironmnt. d : Idntir ((Idntir ) p ) s is a srvic nvironmnt. s : Idntir ((Idntir ) p s f )

203 Domain Static Smantics 181 D.2.1 Static Smantics d bool : Bool d int : Int d string : String d uri : URI d void : Void id dom( d ) d id : Datatyp(id) id dom( c ) d, c command id : Command(id) id dom( d ) d, c vnt id : Evnt(id) id dom( d ) d, c sssion id : Sssion(id) d, c intractionmod : im d, c, s f rquirs intractionmod from id : s f {(Rquirs, im, id)} d, c intractionmod : im d, c, s f provids intractionmod to id : s f {(Provids, im, id)} functionality 1 : s f1 #(s f1 ) = 1 (d 1, Sssion(t 1 ), s 1 ) s f1 functionality 2 : s f2 #(s f2 ) = 1 (d 2, Sssion(t 2 ), s 2 ) s f2 t 1 t 2 (t 1 = t 2 or t 1 is a subtyp of t 2 or t 2 is a subtyp of t 1 ) s f = s f Bind((d 1, Sssion(t 1 ), s 1 ), (d 2, Sssion(t 2 ), s 2 )) d, c, s f bind functionality 1, functionality 2 : s f d, c, s f functionality 1 : s f1 d, c, s fn 1 functionality n : s fn d, c, s f functionality 1 functionality n : s fn d typ : t t Void d, p typ id; : p [id t] d, p proprty 1 : p1 d, pn 1 proprty n : pn d, p proprty 1 proprty n : pn id 2 dom( s ) d, proprtis : p d, c, functionalitis : s f d, c, s srvic id 1 xtnds id 2 { proprtis functionalitis } : s [id 1 (id 2, p, s f )] d, proprtis : p d, c, functionalitis : s f d, c, s srvic id { proprtis functionalitis } : s [id (, p, s f )] d, c, s srvic 1 : s1 d, c, sn 1 srvic n : sn d, c, s srvic 1 srvic n : sn

204 182 Pantaxou Languag d typ : t d typ 1 : t 1... d typ n : t n i [1..n] t i Void d, m typ id(typ 1 id 1,..., typ n id n ); : m [id (t, t 1,..., t n )] d, m mthod 1 : m1 d, mn 1 mthod n : mn d, m mthod 1 mthod n : mn d, mthods : m d, c command id { mthods } : c [id m ] d, c command 1 : c1 d, cn 1 command n : cn d, c command 1 command n : cn id 2 dom( d ) d, proprtis : p d struct id 1 xtnds id 2 { proprtis } : d [id 1 (id 2, p )] d, proprtis : p d struct id { proprtis } : d [id (, p )] d datatyp 1 : d1 dn 1 datatyp n : dn d datatyp 1 datatyp n : dn datatyps : d d, commands : c d, c, srvics : s datatyps commands srvics : ( d, c, s )

205 Srvic Syntax 183 D.3 Srvic Syntax A Pantaqou program has th following form. 'uri' instantiats srvicpath { srvic<srvicpath> { (proprty_nam = xp ;) } srvic_nam ; (vnt sssion)<usrtyppath> (from srvic_nam)? { (proprty_nam = xp ;) } intraction_nam ; (typ id = xp ;) (command typ cmd_nam(param 1... param n ) {stmt }) onrciv bhavior_nam(intraction_nam id) {stmt } ; initial {dcl stmt } final {dcl stmt } onerror {dcl stmt } } Th grammar is dnd as follows : program ::= import 'uri_nam' instantiats srvicpath {body} import ::= import ontology idntir ; import command idntir ; import srvic srvicpath ; import datatyp usrtyppath ; body ::= dcl initial {stmt } final {stmt } onerror {stmt } dcl ::= var typ idntir = xp ; srvic<srvicpath> {proprty } idntir ; mod<usrtyppath> (sourc)? {proprty } idntir ; bridg<typ> {dcl } idntir ; command typ idntir((param (, param) )? ) {stmt } function typ idntir((param (, param) )? ) {stmt } onrciv idntir (param) {stmt } typ ::= simpltyp([intgr? ])? activsssion<usrtyppath> idntir([intgr? ])? usrtyppath simpltyp ::= bool int string uri void const ::= tru fals intgr "string" uri srvicpath ::= Srvic (.idntir) usrtyppath ::= idntir (.idntir) proprty ::= (idntir.)? idntir = xp ; idntir = usrtyppath{proprty } ; sourc ::= from idntir[intgr *] mod ::= vnt sssion param ::= typ idntir

206 184 Pantaxou Languag stmt ::= dcl xp ; plac = xp ; if ( xp ) {stmt } if ( xp ) {stmt } ls {stmt } rturn xp? ; invit(xp, xp) {accptd(param) {stmt } rjctd() {stmt }} publish(xp) ; adopt(xp) ; rjct(xp) ; disconnct(xp) ; xp ::= const nw typ([intgr *])? xp.bind(xp, xp) accpt (xp) xp.idntir ( (xp (, xp) )? ) idntir ( (xp (, xp) )? ) idntir xp.idntir plac ::= idntir xp.idntir D.4 Srvic Static Smantics Typ Systm In ordr to valuat a Pantaqou program, th domain Γ to which it applis must b givn. Γ is a triplt (Σ, Ξ, ) which rspctivly dns for th Γ domain its srvics Σ of typ SrvicTyp, its commands Ξ of typ Command and its datatyps of typ UsrTyp. SrvicTyp is a hirarchical st of typs dnd by an ontology. Command is a st of commands which dns som mthod signaturs. UsrTyp is a hirarchical st of typs with som proprtis attachd to ach nod. SimplTyp : Void + Bool + Int + String + URI ty DataTyp : SimplTyp + UsrTyp ty UsrTyp : Idntir list (DataTyp Idntir) ty Command : Idntir (Idntir DataTyp list DataTyp) ty RquirdEvntTyp, ProviddEvntTyp : Idntir list ty ProviddSssionTyp, RquirdSssionTyp : Idntir list ty EvntInstTyp, SssionInstTyp : Idntir list ty EvntRcptionTyp, SssionRcptionTyp : Idntir ty BridgTyp, BridgInstTyp, ActivSssionTyp : Idntir list ty ModTyp : RquirdEvntTyp + ProviddEvntTyp + ProviddSssionTyp + RquirdSssionTyp + ProviddCommandTyp + RquirdCommandTyp ty ProviddCommandTyp, RquirdCommandTyp : Idntir ty ListTyp : DataTyp ty SrvicTyp : Idntir list ModTyp list (Idntir DataTyp)list ty SrvicInstTyp : (N ) SrvicTyp ty

207 Srvic Static Smantics 185 ty : SimplTyp + DataTyp + ListTyp + RquirdEvntTyp + ProviddEvntTyp + ProviddSssionTyp + RquirdSssionTyp + ActivSssionTyp + ModTyp + Command + ProviddCommandTyp + RquirdCommandTyp + BridgTyp + EvntRcptionTyp + SssionRcptionTyp + SrvicTyp + UsrTyp + SrvicInstTyp + EvntInstTyp + SssionInstTyp + BridgInstTyp Domain Dscription Rmindr : domain Γ = (Σ, Ξ, ) Σ is a nvironmnt which maps srvic labl to its dnition. Σ : Idntir list SrvicTyp Ξ is a nvironmnt which maps command nam to th list of mthods it contains. As mthod signaturs ar uniqu and blongs to a uniqu command nam, Ξ 1 is also dnd as following. Ξ : Idntir Command list Ξ 1 : Idntir DataTyp list Command is a nvironmnt which maps usr data typ labl to its dnition. : Idntir list UsrTyp Rlations is th subclass rlation. It can b applid on SrvicTyp and UsrTyp. : SrvicTyp SrvicTyp : UsrTyp UsrTyp Thn, th quivalnc rlation,, can b dnd as follows : X Y X Y Y X : ty ty ty t 1 = Void t 2 = Void t 1 t 2 = Void t 1 = t 2 = t Void t 1 t 2 = t Oprator Th oprator + is usd to concatnat lists. D.4.1 Static Smantics Th typ systm is dnd in trms of a domain Γ, an nvironmnt µ which contains th ModTyp st providd by th srvic and an nvironmnt τ of typ idntir ty. Th judgmnts for statmnts, xprssions, dclarations and programs hav th following form, whr t ty : Γ, µ, τ, τprop p proprtis Γ, µ, τ, t s stmt : t Γ, µ, τ d dcl : τ Γ, µ, τ m mthod Γ, µ, τ t typ : t Γ, µ, τ xp : t Γ pg program Th judgmnts for srvic, usr-typ and mods proprtis ar dnd as follows :

208 186 Pantaxou Languag Γ, µ, τ τprop xp : t t = τprop(p) Γ, µ, τ, τprop p p = xp Γ upa UsrTypPath : t t = τprop(p) t = UsrTyp(_, τ prop) Γ, µ, τ, τ prop p proprtis Γ, µ, τ, τprop p p = UsrTypPath {proprtis } Γ, µ, τ, τprop p p 1 Γ, µ, τ, τprop p p p Γ, µ, τ, τprop p p 1 ;... ; p p ; Th judgmnts for srvic typs ar dnd as follows : Σ( Srvic ) = t t = SrvicTyp( Srvic, _, _) (Σ, Ξ, ) spa Srvic : t (Σ, Ξ, ) spa psrvictyppath : SrvicTyp(srvicTypLabl, _, _) Σ(srvicTypLabl ++ idntir ) = t t = SrvicTyp(srvicTypLabl ++ idntir, _, _) (Σ, Ξ, ) spa psrvictyppath. idntir : t Th judgmnts for usr data typs ar dnd as follows : ( idntir ) = t t = UsrTyp( idntir, _) (Σ, Ξ, ) upa idntir : t (Σ, Ξ, ) upa pusrtyppath : UsrTyp(usrTypLabl, _) (usrtyplabl ++ idntir ) = t t = UsrTyp(usrTypLabl ++ idntir, _) (Σ, Ξ, ) upa pusrtyppath. idntir : t Th judgmnts for simpl typs ar dnd as follows : Γ, µ, τ t void : Void Γ, µ, τ t bool : Bool Γ, µ, τ t int : Int Γ, µ, τ t string : String Γ, µ, τ t uri : URI Γ, µ, τ t usrtyplabl : t Γ, µ, τ t activsssion<usrtyplabl> : ActivSssionTyp(t) Th judgmnts for compounds ar dnd as follows : Γ, µ, τ d dcl 1... dcl m : τ Γ, µ, τ, t s stmt 1 : t 1 Γ, µ, τ, t s stmt n : t n j < i, t j = Void i < n t i Void i = n Γ, µ, τ, t s {dcl 1... dcl m stmt 1 stmt n } : t i Γ, µ, τ, t s {} : Void

209 Srvic Static Smantics 187 Th judgmnts for statmnts ar dnd as follows : Γ, µ, τ plac : t Γ, µ, τ xp : t Γ, µ, τ xp : Void Γ, µ, τ, t s xp ; : Void t = t Γ, µ, τ, _ s plac = xp ; : Void Γ, µ, τ xp : ListTyp(Void) Γ, µ, τ, t s xp ; : Void t = Void Γ, µ, τ, t s rturn ; : t Γ, µ, τ xp : t t = t Γ, µ, τ, t s rturn xp ; : t Γ, µ, τ xp : Bool Γ, µ, τ, t s cmpd 1 : t 1 Γ, µ, τ, t s cmpd 2 : t 2 Γ, µ, τ, t s if (xp) cmpd 1 ls cmpd 2 : t 1 t 2 Γ, µ, τ xp 1 : SrvicTyp(_, mods, _) Γ, µ, τ xp 2 : RquirdSssionTyp(usrTypLabl) usrtyplabl, (usrtyplabl ) (usrtyplabl) ProviddSssionTyp(usrTypLabl ) mods typ = ActivSssionTyp(usrTypLabl) Γ, µ, τ[id typ], t s cmpd acc : t acc Γ, µ, τ, t s cmpd rj : t rj t acc = t rj = t Γ, µ, τ, t s invit(xp 1, xp 2 ){accptd(typ id) cmpd acc rjctd() cmpd rj } : t Not : invit should handl both cass, accpt and rjct. Th rason is th rjct statmnt should not b viwd as an rror by th rmot srvic. Γ, µ, τ xp 1 : SrvicTyp(_, mods, _) Γ, µ, τ xp 2 : SssionInstTyp(usrTypLabl) usrtyplabl, (usrtyplabl ) (usrtyplabl) ProviddSssionTyp(usrTypLabl ) mods typ = ActivSssionTyp(usrTypLabl) Γ, µ, τ[id typ], t s cmpd acc : t acc Γ, µ, τ, t s cmpd rj : t rj t acc = t rj = t Γ, µ, τ, t s invit(xp 1, xp 2 ){accptd(typ id) cmpd acc rjctd() cmpd rj } : t Γ, µ, τ xp : EvntInstTyp(tl) ProviddEvntTyp(tl) µ Γ, µ, τ, t s publish (xp) ; : Void Γ, µ, τ xp : EvntRcptionTyp(_) + SssionRcptionTyp(_) Γ, µ, τ xp : t t = ProviddSssionTyp(_) Γ, µ, τ, t s rjct(xp) ; : Void Γ, µ, τ, t s adopt(xp) ; : Void Th judgmnts for xprssions ar dnd as follows : Γ, µ, τ xp : t t = ActivSssionTyp(_) + BridgInstTyp(_) Γ, µ, τ, t s disconnct(xp) ; : Void

210 188 Pantaxou Languag c {"...",...} Γ, µ, τ c : String c {...,...} Γ, µ, τ c : URI c Z Γ, µ, τ c : Int c {tru, fals} Γ, µ, τ c : Bool Γ, µ, τ xp : ProviddSssionTyp(usrTypLabl) Γ, µ, τ accpt (xp) : ActivSssionTyp(usrTypLabl) Γ, µ, τ xp : BridgTyp(usrTypLabl) Γ, µ, τ xp 1 : ActivSssionTyp(usrTypLabl 1 ) Γ, µ, τ xp 2 : ActivSssionTyp(usrTypLabl 2 ) usrtyplabl 1 usrtyplabl 2 (usrtyplabl 1 ) (usrtyplabl) (usrtyplabl 2 ) (usrtyplabl) Γ, µ, τ xp.bind (xp 1, xp 2 ) : BridgInstTyp(usrTypLabl) τ(idntir) = RquirdSssionTyp(t) t = SssionInstTyp(t) Γ, µ, τ nw idntir : t τ(idntir) = ProviddEvntTyp(t) t = EvntInstTyp(t) Γ, µ, τ nw idntir : t τ(srvic) = SrvicTyp(_, _, _) i N SrvicInstTyp(i, τ(srvic)) = t Γ, µ, τ nw srvic[i] : t τ(srvic) = SrvicTyp(_, _, _) SrvicInstTyp(, τ(srvic)) = t Γ, µ, τ nw srvic[*] : t (Σ, Ξ, ), µ, τ xp : SrvicInstTyp(i, SrvicTyp(_, µ, _)) i = 1 (Σ, Ξ, ), µ, τ xp j : t j, j {1... n} Ξ 1 (cmdnam, t 1 ;... ; t n ) = Command(cmdLabl, mthods) t = mthods(cmdnam, t 1 ;... ; t n ) RquirdCommandTyp(cmdLabl) µ ProviddCommandTyp(cmdLabl) µ (Σ, Ξ, ), µ, τ xp.cmdnam(xp 1,..., xp n ) : t (Σ, Ξ, ), µ, τ xp : SrvicInstTyp(i, SrvicTyp(_, µ, _)) i (N { }) \ {1} (Σ, Ξ, ), µ, τ xp j : t j, j {1... n} Ξ 1 (cmdnam, t 1 ;... ; t n ) = Command(cmdLabl, mthods) t = mthods(cmdnam, t 1 ;... ; t n ) RquirdCommandTyp(cmdLabl) µ ProviddCommandTyp(cmdLabl) µ (Σ, Ξ, ), µ, τ xp.cmdnam(xp 1,..., xp n ) : ListTyp(t) Th judgmnts for placs ar dnd as follows : Γ, µ, τ idntir : τ(idntir)

211 Srvic Static Smantics 189 Γ, µ, τ xp : SrvicInstTyp(i, SrvicTyp(_, _, lds)) i = 1 lds(ld) = t Γ, µ, τ xp.ld : t Γ, µ, τ xp : SrvicInstTyp(i, SrvicTyp(_, _, lds)) i (N ) \ {1} lds(ld) = t Γ, µ, τ xp.ld : ListTyp(t) Th judgmnts for dclarations ar dnd as follows : Γ, µ, τ d dcl 1 : τ 1 Γ, µ, τ n 1 d dcl n : τ n Γ, µ, τ d dcl 1... dcl n : τ n Γ, µ, τ t typ : t t Datatyp(_) Γ, µ, τ xp : t t = t Γ, µ, τ d var typ idntifr = xp ; : τ[idntifr t] Γ, µ, τ, Void s cmpd : Void Γ, µ, τ t typ : UsrTyp(usrTypLabl) Γ, µ, τ d bridg<typ> cmpd id : τ[id BridgTyp(usrTypLabl)] Γ spa srvicpath : t t = SrvicTyp(_, _, τprop) Γ, µ, τ, τprop p proprtis Γ, µ, τ d srvic<srvicpath> {proprtis} id ; : τ[id t] Γ upa usrtyppath : usrtyp usrtyp = UsrTyp(usrTypLabl, τprop) Γ, µ, τ, τprop p proprtis usrtyplabl, ProviddEvntTyp(usrTypLabl ) µ (usrtyplabl) (usrtyplabl ) Γ, µ, τ s vnt<usrtyppath> {proprtis} id ; : τ[id ProviddEvntTyp(usrTypLabl)] Γ upa usrtyppath : usrtyp usrtyp = UsrTyp(usrTypLabl, τprop) Γ, µ, τ, τprop p proprtis usrtyplabl, RquirdSssionTyp(usrTypLabl ) µ (usrtyplabl) (usrtyplabl ) Γ, µ, τ s sssion<usrtyppath> {proprtis} id ; : τ[id RquirdSssionTyp(usrTypLabl)] Not that th following rul also apply for [*] srvics instad of [i].

212 190 Pantaxou Languag Γ upa usrtyppath : usrtyp usrtyp = UsrTyp(usrTypLabl 1, τprop) Γ, µ, τ, τprop p proprtis τ(srvic) = SrvicTyp(_, µ, _) i N usrtyplabl 2, ProviddEvntTyp(usrTypLabl 2 ) µ usrtyplabl 3, RquirdEvntTyp(usrTypLabl 3 ) µ (usrtyplabl 2 ) (usrtyplabl 1 ) (usrtyplabl 3 ) Γ, µ, τ d vnt<usrtyppath> from srvic[i] {proprtis} id ; : τ[id RquirdEvntTyp(usrTypLabl)] Γ upa usrtyppath : usrtyp usrtyp = UsrTyp(usrTypLabl 1, τprop) Γ, µ, τ, τprop p proprtis τ(srvic) = SrvicTyp(_, µ, _) usrtyplabl 2, RquirdSssionTyp(usrTypLabl 2 ) µ usrtyplabl 3, ProviddSssionTyp(usrTypLabl 3 ) µ (usrtyplabl 2 ) (usrtyplabl 1 ) (usrtyplabl 3 ) Γ, µ, τ d sssion<usrtyppath> from srvic[*] {proprtis} id ; : τ[id ProviddSssionTyp(usrTypLabl)] τ(imt yp) = RquirdEvntTyp(t) t = EvntInstTyp(t) Γ, µ, τ[im t ], Void s cmpd : Void Γ, µ, τ d onrciv id (imtyp im) cmpd : τ[id EvntRcptionTyp(imTyp)] τ(imt yp) = ProviddSssionTyp(t) t = SssionInstTyp(t) Γ, µ, τ[im t ], Void s cmpd : Void Γ, µ, τ d onrciv id(imtyp im) cmpd : τ[id SssionRcptionTyp(imTyp)] Th judgmnts for mthods ruls ar dnd as follows : Γ, µ, τ, Void s cmpd : Void Γ, µ, τ m initial cmpd Γ, µ, τ, Void s cmpd : Void Γ, µ, τ m final cmpd Γ, µ, τ, Void s cmpd : Void Γ, µ, τ m onerror cmpd Γ = (Σ, Ξ, ) Γ, µ, τ t typ i : t i t i = DataTyp(_), i {1,..., n} Ξ 1 (cmdnam, t 1 ;... ; t n ) = Command(cmdLabl, mthods) mthods(cmdnam, t 1 ;... ; t n ) = rt_typ Γ, µ, τ t typ : t d Γ, µ, τ[id 1 t 1,..., id n t n ], rt_typ s cmpd : t s t d = rt_typ t s rt_typ ProviddCommandTyp(cmdLabl) µ Γ, µ, τ m command typ cmdnam (typ 1 id 1,..., typ n id n ) cmpd Th judgmnts for programs ruls ar dnd as follows :

213 Srvic Static Smantics 191 Γ spa srvicpath : SrvicTyp(_, µ, τ) Γ, µ, τ d dcl 1... dcl n : τ Γ, µ, τ m initial Γ, µ, τ m nal Γ, µ, τ m rror Γ pg uri_nam instantiats srvicpath {dcl 1... dcl n initial nal rror}

214 192 Pantaxou Languag D.5 Dynamic Smantics Th global stat, σ, dscribs th stat of th currnt srvic and its rlationships with othr srvics. W assum onrciv dclarations hav bn mad global with a uniqu idntir. So, w can nsur to nd bhavior dclarations in σ. Notations Id SRV rfrs to srvic idntir Id M rfrs to mssag idntir Id S rfrs to sssion idntir Id E rfrs to vnt idntir Id BB rfrs to bridg bhavior idntir Id D rfrs to usr datatyp idntir Som Usful Structurs and Functions Evnt : Id D proprtis EvntMsg : Id SRV Evnt SssionStatus : pnding + aliv + dad Rcption : Id D param stmts RquirdEvnt : Id E Srvic Env Srvic : Id SRV N (N { }) Env SrvicInst : N (N { }) Id SRV list Sssion : Id SRV Id S SssionStatus proprtis RquirdSssion : Id D Env ProviddSssion : Id D Srvic Env Bridg : Id D stmts BridgInst : Id BB Id S Id S handlrs : handlr (param stmts) handlr allow to idntify a handlr,.g., initial, nal, onerror or cmd(id, DataTyp list) s = Sssion(pr, id s, _, proprtis) kill_sssion(s) = Sssion(pr, id s, dad, proprtis) s = Sssion(pr, id s, pnding, proprtis) activat_sssion(s) = Sssion(pr, id s, aliv, proprtis) s = Sssion(_, _, aliv, _) is_aliv(s) = tru s = Sssion(_, _, pnding, _) s = Sssion(_, _, dad, _) is_aliv(s) = fals Th function rturns th mininum of two valus. : {valu { }} valu valu If th rst argumnt is undnd (i.., ), rturns th valu of scond argumnt. If a valu is an rror (i.., ), rturns. Judgmnt Forms Th judgmnts for languag constructs hav th following form, whr Γ rprsnts th domain, φ th static part of th program, σ th dynamic stat of th program, ρ th currnt variabl nvironmnt and t ty. Γ, φ, σ, ρ, valu = pl plac : σ, ρ, rsult s stmt : σ, ρ, rsult xp : σ, valu ps proprtis : (idntir (σ valu) Γ, φ, σ, ρ, (idntir t) = p proprty : (idntir valu) s dcl : σ, ρ, rsult Γ = ph path : valu valu list = pa params : ρ

215 Dynamic Smantics 193 Virtual Machin API Th Pantaxou virtual machin, prsntd hr, is platform indpndant and is built on top of an implmntation-dpndant virtual machin. Such a virtual machin is givn in sction D.6 for th cas of a SIP implmntation. Th functions of th Pantaxou virtual machin ar th following. allocat : Γ stat ty (stat valu) This function is usd to allocat mmory for usr objcts. rgistr : Id Id SRV bool This function is usd to rgistr th currnt srvic. unrgistr : Id Id SRV unit This function is usd to unrgistr th currnt srvic. discovr : Srvic (Id valu) SrvicInst This function is usd to discovr availabl srvics. Th discovry procss is basd on a srvic dclaration and datatyp proprtis of th rqustd intraction mod. mssag : Id valu list N N Id SRV list (Bool valu list) Th function is usd to prform rmot mthod invocation btwn srvic. It corrsponds to th command intraction mod in Pantaxou. It is also usd to accss srvic lds. Th paramtrs ar th following, ld/command nam, ld valu/command argumnts, minimum of actd srvics, numbr of srvic rqustd, list of discovrd srvics to us. subscrib : Id D N N Id SRV list (Bool Id SRV list) This function is usd to subscrib to a st of rmot srvics for a particular kind of valu typ. Th paramtrs ar th following, th datatyp usd for th vnt, minimum numbr of srvics th srvic subscribs to, th numbr of srvics th srvic rqusts and th list of discovrd srvics to us. unsubscrib : Id D Id SRV list unit This function is usd to unsubscrib to th st of rmot srvics to which th srvic has prviously subscrib for a particular vnt typ. publish : stat valu { } This function is usd to publish vnts to subscribrs. invit : stat valu N N Id SRV list (stat Bool valu list) This function is usd to initiat a sssion (valu) with rmot srvics. A minimum numbr of srvics is spcid as wll as th numbr of rqustd srvics. dclin : Id S unit This function is usd to dclin an incoming sssion. accpt : Id S { } This function is usd to accpt an incoming sssion. It rturns if th sssion has bn acknowldg, othrwis, it rturns. by : Sssion unit This function is usd to clos an opn sssion. In addition to ths functions, th virtual machin also provids functions to acknowldg and notify rmot srvic. mssag try/rror : idmssag unit mssag ok : idmssag valu unit notify try/rror/ok : id vnt unit invit try : id sssion unit by ok : id sssion unit

216 194 Pantaxou Languag Auxiliary Functions Th following functions ar calld intrnally by th Pantaxou intrprtr/compilr. Thir function is to asy σ handling. σ stors information about th currntly valuatd srvic, variabl nvironmnt at th srvic scop lvl, activ subscriptions, activ bhaviors, activ sssions and activ bridgs. stat : ((URI Srvic) Env Subs Bhs Sssions Bridgs) lookup_slf : stat (URI Srvic) lookup_dcls : program dcl list lookup_nv : stat (var valu ) lookup_subs : stat (Id E Srvic list) lookup_bh : stat (Id D valu) lookup_sssions : stat (Id S Sssion) lookup_bridgs : stat (Id S BridgInst ) lookup : stat Env Id valu clan_sssion : Γ program stat Id S stat clan_all_subscriptions : stat stat clan_subscriptions : stat Idntir stat crat_slf : Γ program stat lookup_handlrs : program handlrs updat_nv : stat var valu stat updat_subs : stat Id E Srvic list stat updat_bh : stat Id S valu stat updat_sssions : stat Id S Sssion stat updat_bridgs : stat Id S BridgInst stat updat : stat Env Id valu (stat Env) clos_sssion : Γ program stat Id S stat clos_sssions : Γ program stat Id S list stat clos_bridg : Γ program stat BridgInst stat σ = slf, _, _, _, _, _ lookup_slf(σ) = slf φ srvnam = nam Γ = ph φ srvpath : srv (nam, srv),,,,, = σ crat_slf(γ, φ) = σ lookup_dcls(φ) = φ dcls σ = _, nv, _, _, _, _ lookup_nv(σ) = nv σ = _, _, _, bhs, _, _ lookup_bh(σ) = bhs lookup_handlrs(φ) = φ handlrs σ = _, _, subs, _, _, _ lookup_subs(σ) = subs σ = _, _, _, _, sssions, _ lookup_sssions(σ) = sssions σ = _, _, _, _, _, bridgs lookup_bridgs(σ) = bridgs

217 Dynamic Smantics 195 σ = slf, nv, subs, bhs, sssions, bridgs updat_nv(σ, x, v) = slf, nv[x v], subs, bhs, sssions, bridgs σ = slf, nv, subs, bhs, sssions, bridgs updat_subs(σ, sub, v) = slf, nv, subs[sub v], bhs, sssions, bridgs σ = slf, nv, subs, bhs, sssions, bridgs updat_bh(σ, bh, v) = slf, nv, subs, bhs[bh v], sssions, bridgs σ = slf, nv, subs, bhs, sssions, bridgs updat_sssions(σ, s, v) = slf, nv, subs, bhs, sssions[s v], bridgs σ = slf, nv, subs, bhs, sssions, bridgs updat_bridgs(σ, b, v) = slf, nv, subs, bhs, sssions, bridgs[b v] kill_sssion(lookup_sssions(σ)(s id )) = s updat_sssions(σ, s id, s) = σ lookup_bridgs(σ ) = bridgs s id dom(bridgs) bridgs(s id ) = clan_sssion(γ, φ, σ, s id ) = σ kill_sssion(lookup_sssions(σ)(s id )) = s updat_sssions(σ, s id, s) = σ lookup_bridgs(σ ) = bridgs s id dom(bridgs) bridgs(s id ) = b b clos_bridg(γ, φ, σ, b) = σ clan_sssion(γ, φ, σ, s id ) = σ is_aliv(lookup_sssions(σ)(s id )) = tru by(s id ) clan_sssion(γ, φ, σ, s id ) = σ clos_sssion(γ, φ, σ, s id ) = σ clos_sssion(γ, φ, σ, s n ) = σ clos_sssions(γ, φ, σ, s 1 ;... ; s n 1 ) = σ clos_sssions(γ, φ, σ, s 1 ;... ; s n ) = σ x dom(ρ) lookup(σ, ρ, x) = ρ(x) x dom(ρ) updat(σ, ρ, x, v) = σ, ρ[x v] is_aliv(lookup_sssions(σ)(s id )) = fals clos_sssion(γ, φ, σ, s id ) = σ clos_sssions(γ, φ, σ, ) = σ x dom(ρ) lookup(σ, ρ, x) = lookup_nv(σ)(x) x dom(ρ) updat(σ, ρ, x, v) = updat_nv(σ, x, v), ρ

218 196 Pantaxou Languag lookup_subs(σ)(id) = srv id1 ;... ; srv idm updat_subs(σ, id, ) = σ unsubscrib(id, srv id1 ;... ; srv idm ) clan_subscriptions(σ, id) = σ lookup_subs(σ) = subs s dom(subs), subs(s) = clan_all_subscriptions(σ) = σ clos_sssion(γ, φ, σ, s id1 ) = σ 1 clos_sssion(γ, φ, σ 1, s id2 ) = σ 2 lookup_handlrs(φ) = handlrs handlrs(bh) = _, stmts Γ, φ, σ 2, ρ = s stmts : σ 3, clos_bridg(γ, φ, σ, bh, s id1, s id2 ) = σ 3 lookup_subs(σ) = subs s dom(subs) subs(s) clan_subscriptions(σ, s) = σ clan_all_subscriptions(σ ) = σ clan_all_subscriptions(σ) = σ Program Mthods Th following functions ar calld by th undrlying virtual machin. Thy valut program handlrs. initial : Γ program stat nal : Γ program stat stat cmd : Γ program stat Id M Id DataTyp list valu list stat ld : Γ program stat Id M Id valu list stat vnt : Γ program stat Id SRV Id E ty valu stat sssion : Γ program stat Id SRV Id M ty valu stat sssion_clos : Γ program stat Sssion stat onerror : Γ program stat stat crat_slf(γ, φ) = σ rgistr(lookup_slf(σ)) = tru lookup_dcls(φ) = dcls Γ, φ, σ, = s dcls : σ 1, ρ, σ 1 = slf, _, subs, sssions, bridgs slf, ρ, subs, sssions, bridgs = σ 2 lookup_handlrs(φ) = handlrs handlrs(initial) =, stmts Γ, φ, σ 2, = s stmts : σ 3, _, initial(γ, φ) σ 3 crat_slf(φ) = σ rgistr(lookup_slf(σ)) = tru lookup_dcls(φ) = dcls Γ, φ, σ, = s dcls : σ 1, ρ, onerror(γ, φ, σ 1 ) = σ 2 initial(γ, φ) σ 2 crat_slf(φ) = σ rgistr(lookup_slf(σ)) = tru lookup_dcls(φ) = dcls Γ, φ, σ, = s dcls : σ 1, ρ, σ 1 = slf, _, subs, sssions, bridgs slf, ρ, subs, sssions, bridgs = σ 2 lookup_handlrs(φ) = handlrs handlrs(initial) =, stmts Γ, φ, σ 2, = s stmts : σ 3, _, onerror(γ, φ, σ 3 ) = σ 4 initial(γ, φ) σ 4 crat_slf(φ) = σ rgistr(lookup_slf(σ)) = fals initial(γ, φ)

219 Dynamic Smantics 197 lookup_handlrs(φ) = handlrs handlrs(onerror) =, stmts Γ, φ, σ, = s stmts : σ, _, onerror(γ, φ, σ) σ unrgistr(lookup_slf(σ)) clan_all_subscriptions(σ) = σ lookup_handlrs(φ) = handlrs handlrs(nal) =, stmts Γ, φ, σ, = s stmts : σ, _, nal(γ, φ, σ) σ unrgistr(lookup_slf(σ)) clan_all_subscriptions(σ) = σ lookup_handlrs(φ) = handlrs handlrs(nal) =, stmts Γ, φ, σ, = s stmts : σ, _, onerror(γ, φ, σ ) = σ nal(γ, φ, σ) σ notify try (id ) lookup_bh(σ)(t ) = bh bh = Rcption(_, param, stmts) EvntMsg(src, v ) = pa param : ρ Γ, φ, σ, ρ = s stmts : σ, _, notify ok (id ) vnt(γ, φ, σ, src, id, t, v ) σ mssag try (id m ) lookup_nv(σ)(f ild) = v mssag ok (id m, v) ld(γ, φ, σ, id m, fild, ) σ notify try (id ) lookup_bh(σ)(t ) = bh bh = Rcption(_, param, stmts) EvntMsg(src, v ) = pa param : ρ Γ, φ, σ, ρ = s stmts : σ, _, onerror(γ, φ, σ ) = σ notify rror (id ) vnt(γ, φ, σ, src, id, t, v ) σ mssag try (id m ) updat_nv(σ, fild, v) = σ mssag ok (id m, v) ld(γ, φ, σ, id m, fild, v ) σ mssag try (id m ) lookup_handlrs(φ) = handlrs handlrs(cmd(mth, t 1 ;... ; t n )) = params, stmts v 1 ;... ; v n = pa params : ρ Γ, φ, σ, ρ = s stmts : σ, _, r r mssag ok (id m, r) cmd(γ, φ, σ, id m, mth, t 1 ;... ; t n, v 1 ;... ; v n ) σ mssag try (id m ) lookup_handlrs(φ) = handlrs handlrs(cmd(mth, t 1 ;... ; t n )) = params, stmts v 1 ;... ; v n = pa params : ρ Γ, φ, σ, ρ = s stmts : σ, _, onerror(γ, φ, σ ) = σ mssag rror (id m ) cmd(γ, φ, σ, id m, mth, t 1 ;... ; t n, v 1 ;... ; v n ) σ

220 198 Pantaxou Languag invit try (id s ) lookup_handlrs(φ) = handlrs lookup_bh(σ)(t s ) = bh handlrs(bh) = Rcption(_, param, stmts) Sssion(src, id s, pnding, v s ) = pa param : ρ Γ, φ, σ, ρ = s stmts : σ, _, sssion(γ, φ, σ, src, id s, t s, v s ) σ by_ok(s id ) clan_sssion(γ, φ, σ, s id ) = σ sssion_clos(γ, φ, σ, s id ) σ D.5.1 Smantics of Top Lvl Dclarations and Handlr Paramtrs For Srvic Dclarations Srvic dclarations ar valuatd with th statmnt judgmnts. For Paramtrs (Handlrs, Mthods, Commands) v 1, = pa param 1 : ρ 1... v n, ρ n 1 = pa param n : ρ n v, ρ = pa param : ρ[param v] v 1 ;... ; v n = pa param 1 ;... ; param n : ρ n D.5.2 Smantics of Placs updat(σ, ρ, idntir, v) = σ, ρ Γ, φ, σ, ρ, v = pl idntir : σ, ρ, xp : Γ, φ, σ, ρ, v = pl xp.ld : σ, xp : SrvicInst(1, 1, srv id1 ;... ; srv idp ) mssag(ld, v, 1, 1, srv id1 ;... ; srv idp ) = tru, _ Γ, φ, σ, ρ, v = pl xp.ld : σ, xp : SrvicInst(1, 1, srv id1 ;... ; srv idp ) mssag(ld, v, 1, 1, srv id1 ;... ; srv idp ) = fals, _ Γ, φ, σ, ρ, v = pl xp.ld : σ, xp : SrvicInst(i, i, srv id1 ;... ; srv idp ) mssag(ld, v, i, i, srv id1 ;... ; srv idp ) = tru, _ Γ, φ, σ, ρ, v = pl xp.ld : σ,

221 Dynamic Smantics 199 xp : SrvicInst(i, i, srv id1 ;... ; srv idp ) mssag(ld, v, i, i, srv id1 ;... ; srv idp ) = fals, _ Γ, φ, σ, ρ, v = pl xp.ld : σ, xp : SrvicInst(1,, srv id1 ;... ; srv idp ) mssag(ld, v, 1, p, srv id1 ;... ; srv idp ) = tru, _ Γ, φ, σ, ρ, v = pl xp.ld : σ, xp : SrvicInst(1,, srv id1 ;... ; srv idp ) mssag(ld, v, 1, p, srv id1 ;... ; srv idp ) = fals, _ Γ, φ, σ, ρ, v = pl xp.ld : σ, D.5.3 Smantics of Statmnts Compound s {} : σ, ρ, s stmt 1 : σ 1, ρ 1, v 1 Γ, φ, σ i 1, ρ i 1 = s stmt i : σ i, ρ i, v i j < i, v j = (i < n v i ) (i = n) s {stmt 1... stmt n } : σ i, ρ i, v i s stmt 1 : σ 1, ρ 1, v 1 Γ, φ, σ i 1, ρ i 1 = s stmt i : σ i, ρ i, v i j < i, v j = i n v i = s {stmt 1... stmt n } : σ i, ρ i, Void/ Exprssion xp : σ, v v = v = Void v = List(Void) s xp ; : σ, ρ, xp : σ, s xp ; : σ, ρ, Assignmnt xp : σ, v v Γ, φ, σ, ρ, v = pl plac : σ, ρ, r s plac = xp ; : σ, ρ, r xp : σ, s plac = xp ; : σ, ρ,

222 200 Pantaxou Languag Rturn s rturn ; : σ, ρ, Void xp : σ, v s rturn xp ; : σ, ρ, v If xp : σ, tru Γ, φ, σ, ρ = s cmpd 1 : σ, ρ, r s if(xp) cmpd 1 ls cmpd 2 : σ, ρ, r xp : σ, fals Γ, φ, σ, ρ = s cmpd 2 : σ, ρ, r s if(xp) cmpd 1 ls cmpd 2 : σ, ρ, r Rjct xp 1 : σ 1, s id s id dclin(s id ) clan_sssion(γ, φ, σ 1, s id ) = σ 2 s rjct (xp 1 ) ; : σ 2, ρ, xp 1 : σ, s rjct (xp 1 ) ; : σ, ρ, Adopt For vnt xp : σ 1, r r = Rcption(id, _, _) lookup(σ 1, ρ, id) = RquirdEvnt(labl, srvic, proprtis) srvic = Srvic(_, count_min, count_rq, _) discovr(srvic, proprtis) = srv id1 ;... ; srv idn m = count_rq n count_min m clan_subscriptions(σ 1, id) = σ 2 subscrib(labl, count_min, m, srv id1 ;... ; srv idn ) = tru, srvlist updat_subs(σ 2, id, srvlist) = σ 3 updat_bh(σ 3, labl, r) = σ 4 s adopt (xp) ; : σ 4, ρ,

223 Dynamic Smantics 201 For sssion xp : σ 1, Rcption(id, _, _) lookup(σ 1, ρ, id) = RquirdEvnt(labl, srvic, proprtis) srvic = Srvic(_, count_min, count_rq, _) discovr(srvic, proprtis) = srv id1 ;... ; srv idn m = count_rq n count_min m clan_subscriptions(σ 1, id) = σ 2 subscrib(labl, count_min, m, srv id1 ;... ; srv idn ) = fals, srvlist updat_subs(σ 2, id, srvlist) = σ 3 clan_subscriptions(σ 3, id) = σ 4 s adopt (xp) ; : σ 4, ρ, xp : σ, Rcption(id, _, _) lookup(σ, ρ, id) = RquirdEvnt(labl, srvic, proprtis) srvic = Srvic(_, count_min, count_rq, _) discovr(srvic, proprtis) = srv id1 ;... ; srv idn m = count_rq n count_min > m s adopt (xp) ; : σ, ρ, xp : σ, Rcption(id, _, _) lookup(σ, ρ, id) = ProviddSssion(labl, srvic, proprtis) discovr(srvic, proprtis) = srv id1 ;... ; srv idn n > 0 updat_bh(σ, labl, bh) = σ s adopt (xp) ; : σ, ρ, xp : σ, Rcption(id, _, _) lookup(σ, ρ, id) = ProviddSssion(labl, srvic, proprtis) discovr(srvic, proprtis) = srv id1 ;... ; srv idn n = 0 s adopt (xp) ; : σ, ρ, xp : σ, s adopt (xp) ; : σ, ρ, Build-in Mthods xp : σ, s clos_sssion(γ, φ, σ, s) = σ s disconnct(xp) ; : σ, ρ, xp : σ, BridgInst(Id BB, Id S1, Id S2 ) clos_bridg(γ, φ, σ, Id BB, Id S1, Id S2 ) = σ s disconnct(xp) ; : σ, ρ, xp : σ, s disconnct(xp) ; : σ, ρ,

224 202 Pantaxou Languag Invit xpsrv : σ 1, srv srv = Srvic(_, 1, 1, _) Γ, φ, σ 1, ρ = xpsss : σ 2, SssionInst(ssslabl, sssproprtis) discovr(srv, sssproprtis) = srv 1 ;... ; srv n n > 0 invit(σ 2, s, 1, 1, srv 1 ;... ; srv n ) = σ 3, tru, v 1 Γ, φ, σ 3, ρ[id v 1 ] = s cmpd acc : σ 4, ρ, v s invit (xpsrv, xpsss) {accptd(typ id) cmpd acc rjctd() cmpd rj } : σ 4, ρ, v xpsrv : σ 1, srv srv = Srvic(_, 1, 1, _) Γ, φ, σ 1, ρ = xpsss : σ 2, SssionInst(ssslabl, sssproprtis) discovr(srv, sssproprtis) = srv 1 ;... ; srv n n > 0 invit(σ 2, s, 1, 1, srv 1 ;... ; srv n ) = σ 3, fals, _ Γ, φ, σ 3, ρ = s cmpd rj : σ 4, ρ, v s invit (xpsrv, xpsss) {accptd(typ id) cmpd acc rjctd() cmpd rj } : σ 4, ρ, v xpsrv : σ 1, srv srv = Srvic(_, count_min, count_rq, _) Γ, φ, σ 1, ρ = xpsss : σ 2, RquirdSssion(ssslabl, sssproprtis) discovr(srv, sssproprtis) = srv 1 ;... ; srv n m = count_rq n count_min m invit(σ 2, s, count_min, m, srv 1 ;... ; srv n ) = σ 3, tru, v 1 ;... ; v i Γ, φ, σ 3, ρ[id v 1 ;... ; v i ] = s cmpd acc : σ 4, ρ, v s invit (xpsrv, xpsss) {accptd(typ id) cmpd acc rjctd() cmpd rj } : σ 4, ρ, v xpsrv : σ 1, srv srv = Srvic(_, count_min, count_rq, _) Γ, φ, σ 1, ρ = xpsss : σ 2, RquirdSssion(ssslabl, sssproprtis) discovr(srv, sssproprtis) = srv 1 ;... ; srv n m = count_rq n count_min m invit(σ 2, s, count_min, m, srv 1 ;... ; srv n ) = σ 3, fals, v 1 ;... ; v i clos_sssions(γ, φ, σ 3, v 1 ;... ; v i ) = σ 4 Γ, φ, σ 4, ρ = s cmpd rj : σ 5, ρ, v s invit (xpsrv, xpsss) {accptd(typ id) cmpd acc rjctd() cmpd rj } : σ 5, ρ, v

225 Dynamic Smantics 203 xpsrv : σ 1, srv srv = Srvic(_, count_min, count_rq, _) Γ, φ, σ 1, ρ = xpsss : σ 2, RquirdSssion(ssslabl, sssproprtis) discovr(srv, sssproprtis) = srv 1 ;... ; srv n m = count_rq n count_min > m s invit (xpsrv, xpsss){accptd(typ id) cmpd acc rjctd() cmpd rj } : σ 3, ρ, Publish xp : σ 1, v v publish(σ 1, v) = r s publish (xp) ; : σ 1, ρ, r xp : σ 1, s publish (xp) ; : σ 1, ρ, D.5.4 Constant Smantics of Exprssions c {"...",...} c : σ, String(c) c = tru c : σ, Bool(tru) c Z c : σ, Int(c) c = fals c : σ, Bool(fals) c {...,...} c : σ, URI(c) Idntir lookup(σ, ρ, idntir) = v idntir : σ, v Constructor allocat(γ, σ, typ) = σ, v nw typ : σ, v discovr(ρ(srv), ) = srv 1 ;... ; srv p p < i nw srvic[i] : σ, discovr(ρ(srv), ) = nw srvic[*] : σ, discovr(ρ(srv), ) = srv 1 ;... ; srv p 1 i p nw srvic[i] : σ, SrvicInst(i, i, srv 1 ;... ; srv p )

226 204 Pantaxou Languag discovr(ρ(srv), ) = srv 1 ;... ; srv p p > 0 nw srvic[*] : σ, SrvicInst(1,, srv 1 ;... ; srv p ) Call xp 1 : σ 1, v 1 Γ, φ, σ n 1, ρ = xp n : σ n, v n lookup_handlrs(φ)(fct) = params, dcls, stmts v 1 ;... ; v n = pa params : ρ i [1;... ; n], v i Γ, φ, σ n, ρ = s dcls, stmts : σ, _, v fct(xp 1,..., xp n ) : σ, v xp 1 : σ 1, v 1 Γ, φ, σ n 1, ρ = xp n : σ n, v n i [1;... ; n], v i = fct(xp 1,..., xp n ) : σ n, Accpt xp : σ, s id accpt(s id ) = activat_sssion(lookup_sssions(σ )(s id )) = s updat_sssions(σ, s id, s) = σ accpt (xp) : σ, s xp : σ, s id acccpt(s id ) = updat_sssions(σ, s id, ) = σ accpt (xp) : σ, xp : σ, accpt (xp) : σ,

227 Dynamic Smantics 205 Bind xp : σ 1, v v Γ, φ, σ 1, ρ = xp 1 : σ 2, v 1 v 1 Γ, φ, σ 2, ρ = xp 2 : σ 3, v 2 v 2 updat_bridgs(σ 3, v 1, v, v 1, v 2 ) = σ 4 updat_bridgs(σ 4, v 2, v, v 1, v 2 ) = σ 5 BridgInst(v, v 1, v 2 ) = b xp.bind (xp 1, xp 2 ) : σ 5, b xp : σ 1, xp.bind (xp 1, xp 2 ) : σ 1, xp : σ 1, v v Γ, φ, σ 1, ρ = xp 1 : σ 2, xp.bind (xp 1, xp 2 ) : σ 2, xp : σ 1, v v Γ, φ, σ 1, ρ = xp 1 : σ 2, v 1 v 1 Γ, φ, σ 2, ρ = xp 2 : σ 3, xp.bind (xp 1, xp 2 ) : σ 3, Command xp : SrvicInst(1, 1, srv 1 ;... ; srv p ) xp 1 : σ 1, v 1 Γ, φ, σ n 1, ρ = xp n : σ n, v n i [1;... ; n], v i mssag(cmdnam, v 1 ;... ; v n, 1, 1, srv 1 ;... ; srv p ) = tru, w 1 xp.cmdnam(xp 1,..., xp n ) : σ n, w 1 xp : SrvicInst(min, rq, srv 1 ;... ; srv p ) j = rq p xp 1 : σ 1, v 1 Γ, φ, σ n 1, ρ = xp n : σ n, v n i [1;... ; n], v i mssag(cmdnam, v 1 ;... ; v n, min, j, srv 1 ;... ; srv p ) = tru, w 1 ;... ; w j xp.cmdnam(xp 1,..., xp n ) : σ n, w 1 ;... ; w j

228 206 Pantaxou Languag xp : SrvicInst(min, rq, srv 1 ;... ; srv p ) j = rq p xp 1 : σ 1, v 1 Γ, φ, σ n 1, ρ = xp n : σ n, v n i [1;... ; n], v i = mssag(cmdnam, v 1 ;... ; v n, min, j, srv 1 ;... ; srv p ) = fals, _ xp.cmdnam(xp 1,..., xp n ) : σ n, xp : σ, xp.cmdnam(xp 1,..., xp n ) : σ, Fild xp : SrvicInst(1, 1, srv 1 ;... ; srv p mssag(ld,, 1, 1, srv 1 ;... ; srv p ) = tru, v 1 xp.ld : σ, v 1 xp : SrvicInst(i, j, srv 1 ;... ; srv p ) k = j p mssag(ld,, i, k, srv 1 ;... ; srv p ) = tru, v 1 ;... ; v n xp.ld : σ, v 1 ;... ; v n xp : SrvicInst(i, j, srv 1 ;... ; srv p ) k = j p mssag(ld,, i, k, srv 1 ;... ; srv p ) = fals, _ xp.ld : σ, xp : σ, xp.ld : σ, D.5.5 Smantics of Dclarations Variabl xp : σ, v v s var typ id = xp ; : σ, ρ[id v], xp : σ, s var typ id = xp ; : σ, ρ[id ],

229 Dynamic Smantics 207 Srvic Evnt Γ = ph srvicpath : Srvic(srvLabl, _, _, props) Γ, φ, σ, ρ, props = ps proprtis : σ, props Srvic(srvLabl, 1, 1, props ) = v s srvic<srvicpath> {proprtis}id : σ, ρ[id v], Γ = ph usrtyppath : Usr(labl, props) Γ, φ, σ, ρ, props = ps proprtis : σ, props Evnt(labl, props ) = s vnt<usrtyppath> {proprtis}id : σ, ρ[id ], Γ = ph usrtyppath : Usr(labl, props) Γ, φ, σ, ρ, props = ps proprtis : σ, props srvic : Srvic(id srv, _, _, prop srv ) Srvic(id srv, i, i, prop srv ) = srv RquirdEvnt(labl, srv, props ) = s vnt<usrtyppath> from srvic[i] {proprtis}id : σ, ρ[id ], Γ = ph usrtyppath : Usr(labl, props) Γ, φ, σ, ρ, props = ps proprtis : σ, props srvic : Srvic(id srv, _, _, prop srv ) Srvic(id srv, 1,, prop srv ) = srv RquirdEvnt(labl, srv, props ) = s vnt<usrtyppath> from srvic[*] {proprtis}id : σ, ρ[id ], Sssion Γ = ph usrtyppath : Usr(labl, props) Γ, φ, σ, ρ, props = ps proprtis : σ, props lookup_slf(σ ) = (srvnam, _) Sssion(srvNam,, pnding, props ) = s s sssion<usrtyppath> {proprtis}id : σ, ρ[id s], Γ = ph usrtyppath : Usr(labl, props) Γ, φ, σ, ρ, props = ps proprtis : σ, props Γ, φ, σ, ρ = srvic : srv ProviddSssion(labl, srv, props ) = s s sssion<usrtyppath> from srvic[*] {proprtis}id : σ, ρ[id s],

230 208 Pantaxou Languag onrciv cmpd = {stmts} Rcption(imTyp, im, stmts) = r updat_nv(σ, id, r) = σ s onrciv id (imtyp im) cmpd : σ, ρ, Bridg cmpd = {stmts} Bridg(typ, stmts) = b updat_nv(σ, id, b) = σ s bridg<typ> cmpd id : σ, ρ, D.5.6 Ruls Rlativ to th Domain Σ( Srvic ) = Srvic( Srvic, µ, prop) (Σ, Ξ, ) = ph Srvic : Srvic( Srvic, µ, prop) (Σ, Ξ, ) = ph psrvicpath : Srvic(pSrvLabl, µ 1, prop 1 ) Σ(pSrvLabl ++ nod ) = Srvic(srvLabl, µ 1, prop 2 ) µ = µ 1 ++µ 2 prop = prop 1 ++prop 2 (Σ, Ξ, ) = ph psrvicpath.nod : Srvic(srvLabl, µ, prop) ( nod ) = UsrTyp( nod, prop) (Σ, Ξ, ) = ph nod : UsrTyp( nod, prop) (Σ, Ξ, ) = ph pusrtyppath : UsrTyp(pUTLabl, prop 1 ) (putlabl ++ nod ) = UsrTyp(utLabl, prop 2 ) prop = prop 1 ++prop 2 (Σ, Ξ, ) = ph pusrtyppath.nod : UsrTyp(utLabl, prop) Γ, φ, σ, ρ, prop = p proprty 1 : σ 1, prop 1 Γ, φ, σ n 1, ρ, prop n 1 = p proprty n : σ n, prop n Γ, φ, σ, ρ, prop = ps proprty 1... proprty n : σ n, prop n xp : σ, v Γ, φ, σ, ρ, prop = s id = xp ; : σ, prop[id v]

231 SIP Virtual Machin API 209 Γ, = ph UsrTypPath : UsrTyp(utLabl, utprop) Γ, φ, σ, ρ, utprop = ps proprtis : σ, v Γ, φ, σ, ρ, prop = p proprty = UsrTypPath {proprtis } : σ, prop[proprty v] D.6 SIP Virtual Machin API Th following functions dn th availabl functions that may b calld by th intrprtr or gnratd cod. REGISTER : Id bool rspons SIP INVITE : Id SRV proprtis rspons SIP INVITE_try : Id S unit INVITE_ok : Id S unit INVITE_dclin : Id S unit BYE : Id S unit BYE_ok : Id S unit NOTIFY_try : Id E unit NOTIFY_ok : Id E unit NOTIFY_rror : Id E unit MESSAGE : Id SRV cmd/ld valu list rspons SIP MESSAGE_try : Id M unit MESSAGE_ok : Id M valu unit MESSAGE_rror : Id M unit SUBSCRIBE : Id SRV Id D bool rspons SIP PUBLISH : EvntMsg rspons SIP Th virtual machin usd by Pantaxou can thn b dnd in trm of th lowr lvl oprations providd by th SIP virtual machin. rgistr and unrgistr Functions Th rst REGISTER argumnt is th SIP URI of th currnt srvic, i.., its nam. Th scond REGISTER argumnt indicats if th xpir hadr is st to a strictly positiv constant valu (tru) or to zro (fals). Th argumnt thus allows to rgistr and un-rgistr on th SIP srvr. REGISTER(nam, tru) = OK(_) rgistr( nam, srv ) = tru REGISTER(nam, fals) = _ unrgistr( nam, srv ) = () REGISTER(nam, tru) = ERROR rgistr( nam, srv ) = fals discovr Function Th discovr function rlis on a framwork srvic with a spcial nam, framwork. This srvic provids th discovr opration. MESSAGE(framwork, discovr, srv, proprtis ) = OK(srvics) discovr(srv, proprtis) = srvics

232 210 Pantaxou Languag MESSAGE(framwork, discovr, srv, proprtis ) = ERROR discovr(srv, proprtis) = mssag Function rq > 0 MESSAGE(srv idn, op, params) = OK(v n ) mssag(op, params, min 1, rq 1, srv id1 ;... ; srv idn 1 ) = sol, sollist mssag(op, params, min, rq, srv id1 ;... ; srv idn ) = sol, sollist ++ v n rq > 0 MESSAGE(srv idn, op, params) = ERROR n 1 min mssag(op, params, min, rq, srv id1 ;... ; srv idn 1 ) = sol, sollist mssag(op, params, min, rq, srv id1 ;... ; srv idn ) = sol, sollist rq > 0 MESSAGE(id, srv idn, labl) = ERROR n 1 < min mssag(op, params, min, rq, srv id1 ;... ; srv idn ) = fals, rq = 0 mssag(op, params, min, rq,... ) = tru, subscrib Function rq > 0 SUBSCRIBE(srv idn, labl, tru) = OK subscrib(labl, min 1, rq 1, srv id1 ;... ; srv idn 1 ) = sol, srvlist subscrib(labl, min, rq, srv id1 ;... ; srv idn ) = sol, srvlist ++ srv idn rq > 0 SUBSCRIBE(srv idn, labl, tru) = ERROR n 1 min subscrib(labl, min, rq, srv id1 ;... ; srv idn 1 ) = sol, srvlist subscrib(labl, min, rq, srv id1 ;... ; srv idn ) = sol, srvlist rq > 0 SUBSCRIBE(srv idn, labl, tru) = ERROR n 1 < min subscrib(labl, min, rq, srv id1 ;... ; srv idn ) = fals, rq = 0 subscrib(labl, min, rq,... ) = tru, unsubscrib Function SUBSCRIBE(srv idn, labl, fals) unsubscrib(labl, srv id1 ;... ; srv idn 1 ) unsubscrib(labl, srv id1 ;... ; srv idn ) = () unsubscrib(labl, ) = ()

233 SIP Virtual Machin API 211 publish Function lookup_slf(σ) = (srvn am, _) PUBLISH(EvntMsg(srvN am, v)) = OK publish(σ, v) : lookup_slf(σ) = (srvn am, _) PUBLISH(EvntMsg(srvN am, v)) = ERROR publish(σ, v) : invit Function rq > 0 v = RquirdSssion(ssslabl, sssproprtis) INVITE(srv n, sssproprtis) = OK(s n ) updat_sssions(σ, ssslabl, Sssion(srv n, s n, pnding, sssproprtis)) = σ invit(σ, v, min 1, rq 1, srv 1 ;... ; srv n 1 ) = σ, sol, sollist invit(σ, v, min, rq, srv 1 ;... ; srv n ) = σ, sol, sollist ++ s n rq > 0 v = RquirdSssion(ssslabl, sssproprtis) INVITE(srv n, sssproprtis) = ERROR n 1 min invit(σ, v, min, rq, srv 1 ;... ; srv n 1 ) = σ, sol, sollist invit(σ, v, min, rq, srv 1 ;... ; srv n ) = σ, sol, sollist rq > 0 v = RquirdSssion(ssslabl, sssproprtis) INVITE(srv n, sssproprtis) = ERROR n 1 < min invit(σ, v, min, rq, srv 1 ;... ; srv n ) = σ, fals, rq = 0 invit(σ, v, min, rq,... ) = σ, tru, by, dclin and accpt Functions BYE(s id ) by(s id ) = () INVITE_ok(s id ) ACK accpt(s id ) = INVITE_dclin(s id ) dclin(s id ) = () INVITE_ok(s id ) ACK accpt(s id ) =

234 212 Pantaxou Languag Rspons Functions Th dnition of th following Pantaxou virtual machin functions ar straightforward in th SIP virtual machin. Thy just call th corrsponding SIP virtual machin functions with th sam argumnts. mssag try is givn as an xampl. mssag try/rror : idmssag unit mssag ok : idmssag valu unit notify try/rror/ok : id vnt unit invit try : id sssion unit by ok : id sssion unit MESSAGE_try(id m ) mssag try (id m ) = ()

235 Annx E Gstionnair d lumièr 1 packag fr.labri.phonix.amigo.lightmanagr.impl; 2 3 import java.util.linkdlist; 4 5 import fr.labri.phonix.amigo.vnt.luminosityevnt; 6 import fr.labri.phonix.amigo.functionality.luminosityevntinput; 7 import fr.labri.phonix.amigo.lightmanagr; 8 9 import fr.labri.phonix.amigo.partition.lightmanagrpart; 10 import fr.labri.phonix.amigo.intf.ilightmanagr; 11 import fr.labri.phonix.amigo.light; import fr.labri.phonix.amigo.partition.lightpart; 14 import fr.labri.phonix.amigo.intf.ilight; 15 import fr.labri.phonix.amigo.lightsnsor; import fr.labri.phonix.amigo.partition.lightsnsorpart; 18 import fr.labri.phonix.amigo.intf.ilightsnsor; 19 import fr.labri.phonix.amigo.pantaxou.pantaxoucomponnt; public class LightManagrImpl xtnds LightManagr implmnts Runnabl { privat LinkdList<ILight> gtlights() { 24 LightPart lightpart = Light.gtPartition(this); 25 rturn Light.gtSrvics(lightPart); 26 } privat LinkdList<ILight> gtlight(int n) { 29 LinkdList<ILight> light = gtlights(); 30 int siz = light.siz(); 31 int j = siz - Math.min(n,siz); 32 for (int i = 0; i < j; i++) { 33 light.rmovlast(); 34 } 35 rturn light; 36 } privat LinkdList<ILightSnsor> gtlightsnsors() { 39 LightSnsorPart lightsnsorpart = LightSnsor.gtPartition(this); 40 rturn LightSnsor.gtSrvics(lightSnsorPart); 41 } privat LinkdList<ILightSnsor> gtlightsnsor(int n) { 44 LinkdList<ILightSnsor> lightsnsor = gtlightsnsors(); 45 int siz = lightsnsor.siz(); 46 int j = siz - Math.min(n,siz); 47 for (int i = 0; i < j; i++) { 48 lightsnsor.rmovlast(); 213

236 214 Gstionnair d lumièr 49 } 50 rturn lightsnsor; 51 } protctd abstract class LumEvt { 54 public abstract void rciv(luminosityevnt ); 55 } privat LumEvt lumevt = null; public void rciv(luminosityevnt ) { 60 if (lumevt!= null) { 61 lumevt.rciv(); 62 } 63 } privat class LumEvtRcption xtnds LumEvt { 66 public void rciv(luminosityevnt ) { 67 int lum =.gtdata().gtluminosityval(); 68 if (lum < 30) { 69 LinkdList<ILight> lights = gtlights(); 70 for(ilight light: lights) 71 light.on(); 72 } ls { 73 if (lum > 40) { 74 LinkdList<ILight> lights = gtlights(); 75 for(ilight light: lights) 76 light.off(); 77 } 78 } 79 } 80 } public LightManagrImpl(PantaxouComponnt componnt) { 83 supr(componnt); 84 } public void run() { 87 lumevt = nw LumEvtRcption(); 88 LinkdList<ILightSnsor> lightsnsors = gtlightsnsors(); 89 for (ILightSnsor lightsnsor: lightsnsors) { 90 lightsnsor.subscrib(this); 91 } 92 } 93 }