Runtime Verification Monitoring Oriented Programming SOA drd . Ionut Apetrei

1. Runtime VerificationMonitoring Oriented ProgrammingSOAdrd. IonutApetrei

2. Agenda • 1. Runtime Verification • 2. Paradigma MOP • 3. Java MOP • 4. SOA Monitoring • 5. Concluzii

3. 1. Runtime Verification • Notiunea de verificareimplicatreitehnici de baza: • demonstrareateoremelor – permitedemonstrareacorectitudiniiunui program prinutilizareamecanismelormatematice • model checking – metoda automata de verificare, se aplica in special sistemelor cu stari finite; se bazeazapelogicitemporale • testarea – denotaprocesul de gasire a bugg-urilorunuisistem

4. 1. Runtime Verification vsModel Checking • Idea logicilortemporale – o formula nu esteadevaratasaufalsaintr-o manierastaticaintr-un model (contraex. LP) • Modelelelogicilortemporalecontincatevastari, iar o formula poatefiadevarata in uneledintreaceasteasifalsa in altele. • Modeluleste un sistemtranzitional, iarproprietatileformuletemporale.

5. 1. Runtime Verification vs Model Checking • Verificareaunuisistemimplicaurmatoriipasi: • folosim un limbajdescriptiv a model checker-ului • codificamproprietatea(ile) vizateutilizandlimbajul de specificatie a model checker-ului • rulam model checker-ul, avand ca input: modelulsiformulele

6. 1. Runtime Verification • Verificarea la runtime esteprivita ca o tehnica de verificareusoara, complementaratehnicilor de tipul: model checking sitestare. • Un esec software ("software failure") este o deviatie dintre un comportament observat si comportamentul necesar al unui sistem software. • Un "fault" esteidentificat de catredeviatiastariicurente in raport cu stareaasteptata a sistemului. • O eroareeste o gresealaceapartineprogramatorului, gresealacerezultaintr-un “fault” siposibilintr-un esec.

7. 1. Runtime Verification - Monitoare • Verificarea la runtime vizeazadoardetectareaviolariisaurespectariiproprietatilor de corectitudine. • In literatura de specialitate executia unui sistem software ("run") este privita ca o posibila secventa infinita de stari ale sistemului. • Starile pot fialcatuite din asignari de variabilesausecvente de actiuniemisesiefectuate de catre un sistem. • Formal, o executieesteconsiderata ca un posibilcuvantinfinitsau trace. • Executiaunuisistemeste un prefix finit al acelui run, trace finit.

8. 1. Runtime Verification - Monitoare • Verificarea executiei unui sistem in raport cu o proprietate de corectitudine este responsabilitatea unui monitor. • Functionalitatea de baza a unui astfel de monitor este de a decide daca executia curenta satisface o anumita proprietate. • Putem extrapola si afirma ca verificarea la runtime din punct de vedere matematic si formal incearca dezvoltarea de tehnici capabile sa ofere un raspuns in ceea ce priveste incluziunii unui cuvant (trace) intr-un limbaj (set de stari ale unui sistem).

9. 1. Runtime Verification - Monitoare • Monitorizare online - implicafolosireaunui monitor pentru a verificaexecutiacurenta a unuisistem. • Monitorizare offline - implicafolosireaunui monitor pentru a multimefinita de executiiinregistrate • In ceea ce priveste verificarea la runtime, monitoarele sunt generate automat dintr-o specificatie de nivel inalt.

10. 1. Runtime Verification - „Safety properties” • Princonceptul de proprietate de siguranță se încearcăsurprindereaunuiproprietățicomportamentalecorelată cu trace-uri de execuției • Caracteristica de bazăestedată de faptulcăodatăîncălcată (proprietatea), aceasta nu maipoatefisatisfăcută • Proprietatile de siguranta pot fiaplicatepeste trace-uri finite si/sau infinite

11. 1. Runtime Verification – Definireformalamonitoare • sintaxa formală: Ḿ=(S, s0, M: S x ∑ → S) • un monitor este un automat specializat, farăstăriterminale • proprietăți ale unui monitor: • Ĺ*( Ḿ ) = { w ϵ ∑* | M (s0,w) ↓} • Ĺ(Ḿ ) = { u ϵ ∑ | M (s0,w) ↓} for all w ϵ prefixes(u)} • Ĺ*, (Ḿ ) = Ĺ*( Ḿ )  Ĺ( Ḿ )

12. 1. Runtime Verification – Definireamecanismului de functionare a monitoarelor • ideeagenerală de funcționare a unui monitor este: • automatulspecializat, va fi declanșat de evenimentele generate de cătresistemul observant (în mod concretsistemulestereprezentat de literele din ∑) • fiecareevenimentnouprimittrecemonitorul din stareacurentăînaltă stare • trecereaestedictată de funcția de tranziție M • dacămonitorul se blochează (mai exact încazulîn care funcția de tranzițieestenedefinităpestareacurentășievenimentulcurent), proprietateamonitorizatăestedeclarată ca fiindîncălcatăînacelpunct • procesul de monitorizare este descris de necesitatea verificării apartenței unui cuvânt w ϵ ∑* la prefixes(w), unde prefixes(w): ∑* → Ƥ(∑*)

13. 1. Runtime Verification – Amendament • Sistemetranzitionale (modele software) • Forma generala: Ḿ= (S, →, L) – S –multimeastarilor; → relatiebinara (relatie de tranzitie); L – functie de etichetare L: S -> Ƥ(Atoms). Pentrufiecare stare s, avemși o multime de propozițiiatomice L(s), propozițiicedeținvaloarea de adevărpentrustarea s. Tranzițiilesunt: so → s1, so → s2, s1 → s0, s1 → s2, s2 → s2. Etichetelesunt: L(so)={a,b}, L(s1)={b,c}, L(s2)={c}

14. 2. Monitoring-Oriented Programming • Modelul MOP

15. 2. Monitoring-Oriented Programming • Din perspectivaparadigmei MOP, cerinteleunuisistemapar sub forma unorspecificațiiformale, acestespecificațiiprezentându-se ca adnotări. • Flexibilitateaacesteiabordăriconstăînfaptulcărespectiveleadnotări pot fiinserateîndiferitelocatii ale programului (însensulunuisistem software); locurile de insertiesunt definite de catreprogramator.

16. 2. Monitoring-Oriented Programming • Pebazaspecificatiilorformale se va genera un asa-numit „cod de monitorizare”, acest cod esteacelasi cu limbajul de implementare al sistemuluipeste care vremsăadaugammonitoarele. • Evenimentele (element de sintaxă din cadruluneispecificații MOP –„event”) suntcele care faciliteazăverificareaproprietăților la diferitelocuriîn cod. • Un monitor trebuieprivit sub forma unui automat specializat, farăstăriterminale.

17. 2. Monitoring-Oriented Programming • Sintaxagenerala a uneispecificatii MOP

18. 2. Monitoring-Oriented Programming • Prima componentă (header-ul) vacontineinformatiidespreprocesul de monitorizare, generaresiintegrare. Pot fiadăugatesiinformatiiprivitoare la scopulsilogicafolosită la definireaunorproprietati in vedereamonitorizarii. • Încea de a douacomponenta (corpul) proprietatilemonitorizatesuntdeclarate, aceleformulevorfiasociate cu anumite plug-in-urilogice, înconcordanta cu semnaticaformalautilizata. • Ultimacomponentă (handler-ul) estereprezentată de coduldeclarat de programatorpentrucazul in care proprietateaesterespectatasauincalcata.

19. 3. JavaMOP • Tool cefaciliteazadeclararea de specificatii MOP, in urmaprocesului de generarevomavea un cod de monitorizare cu sintaxaspecificalimbajului de programare Java. • La nivel de arhitecturaJavaMOPprezinta o structura de tip client-server: • partea de client contine un modulpentruinterfatasiprocesorul de specificatii, special dezvoltatpentruJavaMOP • partea de server conține un dispecer de mesajesi plug-in-urilogicepentru Java, acesteasuportaformalisme ca: ptLTL, ftLTL, ERE si CGF

20. 3. JavaMOP • Principalulrol al acesteitehnologiieste de a translata output-ulfurnizata de egine-urilelogice in aspecte (sintaxaesteunaproprietaraAspectJ). Etapafinala de integrareapartinecompilatoruluiAspectJ care are rolul de a unificaprogramul original cu aspectele generate.

21. 3. JavaMOP

22. 3. JavaMOP

23. 3. JavaMOP • Exemplu nr.1 (din care reiesenecesitateafolosiriiJavaMOP) Vector v=new Vector(); v.add(new Integer(10)); Iteratori =v.iterator(); v.add(new Integer(20)); System.out.println(i.next()); JVM: ConcurentModificationException Proprietateaunuiiterator: fail-fast

24. 3. JavaMOP – exemplu nr.1 • package mop; import java.io.*; import java.util.*; HasNext(Iteratori) { event hasnext after(Iteratori) : call(* Iterator.hasNext()) && target(i) {} event next before(Iteratori) : call(* Iterator.next()) && target(i) {} ptltl : next implies (*) hasnext @violation { System.out.println("next called without hasNext!"); } } Specificatia monitorului

25. 3. JavaMOP – exemplu nr.2 • monitorizarea unei proprietăți ptLTL de forma : (b→ • a), unde în cazul de față b reprezintă returnarea unei liste de produse, iar a reprezintă autentificarea • rolul proprietății de mai sus este de a verifica accesul la o resursă în contextul unui SW package mop; import searchFarm.ServiciuWebSearchFarm IsAuthentificated(ServiciuWebSearchFarmswsf) { event authenticate before(ServiciuWebSearchFarmswsf) : call(* ServiciuWebSearchFarm.authenticate()) && target(swsf) {} event getFarmProdList after(ServiciuWebSearchFarmswsf) : call(* ServiciuWebSearchFarm.getFarmProdList()) && target(swsf) {} ptltl : getFarmProdList implies (*) authenticate @violation { System.out.println("Operatia nu poatefirealizatafara a fiautentificat!"); } }

26. 4. SOA Monitoring • Consta in folosireaparadigmei MOP pentrutehnologiilespecifice “Service Oriented Arcitecture“: • Servicii Web • Procese de afaceri • Componente software

27. 4. SOA – Definireconcepte • Conceptul fundamental al SOA este acela de serviciu, proprietățile sale putând fi enumerate (de menționat că un serviciu este privit sub forma unei componente software): • este definit de o interfata ce poate fi independenta de platforma • este accesibil folosind o retea • operatiile definite in interfata vor realiza operatiile esentiale („business functions”), realizarea lor vizand obiectele de tip business • interfata unui serviciu si implementarea acestuia pot fi „decorate” cu extensii ce isi vor face simtita prezenta la „runtime”.

28. 4. SOA – Proprietatigenerale ale unuiserviciu • Interfata independenta de platforma: functionalitatea unui serviciu trebuie definita de catre o interfata externa. Principalul rol al unui serviciu este acela de a adresa si de a rezolva aspecte legate de integrare. • Accesibil prin intermediul unei retele: este un principiu fundamental si constain capacitatea de a accesa functionalitătile unui serviciu intr-o manieră remote.

29. 4. SOA – Proprietatigenerale ale unuiserviciu • Operatii realizate asupra „business object”-urilor: aceasta proprietate se refera la indeplinirea/executia unor functionalitati specifice unui domeniu al aplicatiei supuse viziunii SOA. • Decorabilitate: acest concept face referire la posibilitatea de a decora, adnota operatiile serviciului, astfel incat sa fie surprinse atat aspectele functionale, cat si cele nefunctionale (WS-RealiableMessaging, WS-SecureConversation).

30. 4. SOA - Clasificare • Distingemurmatoareaclasificare a serviciilor: • servicii entitate - un serviciu de tip entitate reprezinta una sau mai multe entitati de tip „business”. • servicii functionale - deseori acest tip de serviciu nu are o reprezentare in cadrul unui model de afaceri; poate fi reprezentat totusi in cadrul unei diagrame de tip secventa.Trebuie mentionat ca un serviciu functional este serviciul orientat spre tehnologie si nu spre business (operatii de logging și notificare) . • servicii de tip proces - un serviciu de tip proces este alcatuit dintr-o serie de task-uri (activitati) relationate. Aceste activitati pot fi indeplinite in cadrul granitelor unui singur domeniu de business, peste mai multe domenii de business sau intre organizatii.

31. 4. SOA – Principiimodelare • Tehnicile arhitecturale ce se impun în procesul de modelare: • Generalizarea presupune analiza serviciului pentru a determina definirea la nivel de concept a serviciului respectiv. Putem face o analogie cu programarea orientata-obiect; o astfel de analizain contextul OO poarta numele de relatie de tip „IS-A”. O generalizare exagerata poate evita surprinderea aspectelor relevante pentru respectivul serviciu, diminuand posibilitatea refolosirii; prin acest fapt se încalca unul dintre principiile de baza ale SOA.

32. 4. SOA – Principiimodelare • Descompunerea presupune determinarea elementelor candidat pentru realizarea unei compuneri. O astfel de abordare de cele mai multe ori duce la descoperirea serviciilor de tip entitate sau a serviciilor functionale, servicii ce trebuiesc separate. Ca principiu general, cu cat serviciul este mai bine izolat, in sensul lipsei unei interdependente excesive, cu atat mai mult respectivul serviciu va putea fi folosit/refolosit si eventual integrat intr-un scenariu de “compunere “.

33. 4. SOA – Principiimodelare • Agregarea presupune analiza serviciului in vederea determinarii contextului din care face parte, in sensul relatiilor de interdependenta. Elementele ce tin de agregare pot fi clasificate ca fiind procese existente, servicii sau chiar servicii-candidat. De asemenea, putem face o paralelă cu programarea orientata-obiect; procesul poarta numele de cautare a relatiilor de tip „HAS-A”.

34. 4. SOA – Principiimodelare • Aplicareaprincipiilor de maisusestenecesara in vedereadescopeririiserviciilorce pot ficompuse. • Vomprezentasiprincipiileaditionale: • Reutilizabilitatea • Securitate • Interoperabilitate • SLA • Granularitate • Contract • Proces

35. 4. SOA – Principiimodelare • Reutilizabilitatea: scopul final al acestei tehnici este de a furniza un contract; pe baza analizelor sistemului se urmareste in primul rand gradul de refolosire pe care il poate avea respectivul serviciu. • Securitatea: de obicei, acest aspect este luat in considerare la nivelul aplicatiei. In cazul modelarii serviciilor componentele ce vor asigura securitatea vor fi încadrate intr-un model general de securitate asociat respectivei solutii SOA, model care va contine SAML (Security Assertion Markup Language), un „policy enforcement”, specificatii privind securitatea transportului, semnaturi digitale, Kerberos etc.

36. 4. SOA – Principiimodelare • Interoperabilitate: in contextul programarii orientate-obiect, obiectele comunica doar cu alte obiecte; in cazul serviciilor, acest principiu nu este aplicat, ideea de baza fiind aceea de comunicarea intre componente software implementate pe platforme software eterogene. • SLA-uri: serviciile, asemenea sistemelor pe care le expun, trebuie sa aiba definite contracte, „agreement-uri” la nivel de servicii. Aceste tipuri de specificatii sunt extrem de importante deoarece un anume serviciu intr-un context SOA va fi reutilizat de mai multe ori, in contexte diferite, implicit, procese diferite.

37. 4. SOA – Principiimodelare • Granularitate: un serviciu de cele mai multe ori va fi integrat intr-un mediu in care serviciile evolueazain ceea ce priveste interactiunea, implicit interoperabilitatea dintre diferite sisteme. Definirea unei cat mai bune granularitati (functionalitati specifice unui anume business, nu exista un grad mare de interdependenta) reprezinta garantia reutilizarii respectivei componente software.

38. 4. SOA – Principiimodelare • Contract: in cadrul unui model (in sensul unei aplicatii SOA), definirea unui contract constain identificarea elementelor necesare la nivel global. Unele dintre elemente vor fi atribute serviciilor, iar altele vor servi ca metadate expuse in cadrul contextului WS-MetaDataExchange. Trebuie mentionat faptul ca deseori vor fi luate in calcul si elementele nefunctionale, de obicei declararea acestora fiind facilitata de tehnologiile ce ofera suport pentru dezvoltarea de aplicatii orientate SOA.

39. 4. SOA – Principiimodelare • Proces: analiza de proces difera de abordarile traditionale (in sensul construirii de sisteme capabile sa realizeze un set clar de functionalitati) axate pe paradigma orientata-obiect; importanta lor in contextul IT este data de posibilitatea de a translata, a reprezenta un proces de afaceri sub forma unui serviciu web (ultimul standard elaborat de OASIS – WS-BPEL 2.0). Numeroase proiecte (tehnologii ce permit dezvoltarea software) ofera ca solutie pentru realizarea mecanismului de orchestrare (opusul conceptului de coreografie specific mai mult serviciilor web clasice – „WS-Choreography”) suport pentru lucrul cu procese de afaceri si expunerea lor ca servicii.

40. 5. Concluzii • JavaMOPsi MOP suntcentratepeflexibilitatesioptimizareamonitorizarii • Provocareaconsta in elaborareaunui set de tehnicisisolutiicapabilesamonitorizeze la runtime aplicatiile software ceapartinviziunii SOA.

41. Sfarsit • Intrebari?