Palvelujen dynaaminen valvonta

Palvelujen dynaaminen valvonta Esa Hämäläinen Helsinki 6.12.2006 Palveluperusteisten ohjelmistojen suunnittelu ja kehittäminen -seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

i Tiivistelmä Ohjelmistojen ja järjestelmien koko on kasvanut ja niiden potentiaalinen monimutkaisuus on lisääntynyt. Tämä on osaltaan kasvattanut mm. testauksen, suunnitteluaikaisen verioinnin ja oikeaksi todistamisen aiheuttamia kustannuksia ja siihen tarvittavaa aikaa. Toisaalta ohjelmistojen toiminta perustuu nykyisin yhä suuremmassa määrin sähköisiin sopimuksiin, jotka neuvotellaan ja niihin liittyvistä vaatimuksista sovitaan dynaamisesti. Ennakkoon ei välttämättä tiedetä mitä oikea toiminnallisuus on tai mitä ei-toiminnallisia vaatimuksia järjestelmälle asetetaan. Näistä syistä johtuen hyväksytyn toiminnallisuuden varmistaminen vaatii suoritusaikaista valvontaa. Suoritusaikaisten dynaamisten monitorien tehtävänä on tarkkailla suorituksessa olevaa järjestelmää ja päätellä vastaako lopputulos ennalta asetettuja tavoitteita.

Sisältö ii 1 Johdanto 1 2 Monitorit 2 2.1 Toiminnalliset ja ei-toiminnalliset vaatimukset............. 2 2.1.1 Metriikat............................. 4 2.1.2 Politiikat.............................. 5 2.2 Näkökulmat................................ 6 2.3 Abstraktiotasot.............................. 7 2.4 Kypsyystasot............................... 7 2.5 Valvontapisteet ja hajautus....................... 8 3 SLA ja SLM 8 3.1 WSLA................................... 9 3.1.1 Terminologia........................... 9 3.1.2 WSLA:n ajonaikainen arkkitehtuuri............... 10 3.1.3 Monitoroinnin ulkoistaminen................... 12 4 Koreograat 13 5 Yhteenveto 14 Lähteet 15

1 Johdanto 1 Yritysten toiminnan tehostuminen ja verkottuminen asettaa vaatimuksia tietojärjestelmien kehittämiselle ja hallinnalle. Näiden haasteiden ratkaiseminen kustannustehokkaasti on yrityksen kilpailukyvyn kannalta ensiarvoisen tärkeää ja voi lisäksi luoda täysin uusia liiketoimintamalleja. Palveluperustaiset ohjelmistot ovat yksi tekninen lähestymistapa ratkaista nämä haasteet kustannustehokkaasti. Yritykset tuottavat asiakkaille palveluja joko yksin tai yhdessä toimien liiketoimintaverkoston osana. Verkostossa toimivat yritykset muodostavat virtuaalisen yrityksen. Yrityksen toimintaan liittyy sekä materiaalivirtojen että informaatiovirtojen hallinta. Informaation välittämiseksi yritykset lähettävät toisilleen sähköisiä viestejä, jolloin puhutaan sähköisestä liiketoiminnasta. Sähköisessä liiketoimintaverkostossa yritykset toimivat itsenäisesti heterogeenisessa ympäristössä ja voivat muodostaa dynaamisesti virtuaaliyrityksiä. Yhteisöt ovat luonteeltaan hajautettuja ja rakenteeltaan mahdollisesti hyvin kompleksisia. Yritysten yhteistoiminta perustuu sähköisiin sopimuksiin. Tässä ympäristössä vuorovaikutusten oikeellisuuden ja sopimusten mukaisuuden varmistaminen on olennainen osa toimivaa verkostoa. Ohjelmistojen ja järjestelmien koko on kasvanut ja niiden potentiaalinen monimutkaisuus on lisääntynyt. Tämä on osaltaan kasvattanut mm. testauksen, suunnitteluaikaisen verioinnin ja oikeaksi todistamisen aiheuttamia kustannuksia ja siihen tarvittavaa aikaa. Heterogeenisessä ympäristössä toimivien automonisten palvelujen tapauksessa järjestelmän oikeaa toiminnallisuutta ei välttämättä voi edes määritellä ennakkoon. Palvelut voivat perustua (sähköisiin)sopimuksiin, jotka neuvotellaan ja niihin liittyvistä vaatimuksista sovitaan dynaamisesti. Ennakkoon ei välttämättä tiedetä mitä oikea toiminnallisuus on. Esimerkiksi SOA-pohjaiset [Pap03] palvelut ovat teknologianeutraaleja, löysästi sidottuja ja sijaintinsa suhteen tuntumattomia, jolla on vaikutuksia myös palvelun veriointiin. Jos määritelmänsä mukaisesti SOA-pohjaiset järjestelmät voivat muuttua suoritusaikaisesti: esimerkiksi abstrakti palvelu voidaan sitoa dynaamisesti uuteen tarjoajaan tai palvelun tuottaja voi muutta palvelunsa sisäistä toteutusta. Palvelujen uudet tuottajat, versiot ja konteksti vaikuttavat palvelun oikeellisuuteen ja palvelun laatuun. Suoritusaikaisten dynaamisten monitorien tehtävänä on tarkkailla suorituksessa olevaa järjestelmää ja päätellä vastaako lopputulos ennalta asetettuja tavoitteita.

2 Monitorit voidat herättää tarvittaessa korjaustoimenpiteitä. Virheiden havaitsemisen lisäksi monitoroinnilla on toinenkin tehtävä: se voi ylläpitää järjestelmän tilaa ja tarjota välineet raportointinäkymän muodostamiseen. Luvussa 2 käsitellään erilaisia näkökulmia ja tapoja luokitella monitoreja ja dynaamista valvontaa. Luvussa 3 monitorointia tarkastellaan palvelutasosopimusten ja luvussa 4 koreograoiden kannalta. 2 Monitorit Dynaamiset monitorit (runtime monitors) [DGR04] tarkkailevat järjestelmän suoritusaikaisia tapahtumia ja päättelevät vastaako järjestelmän havaittu käytös järjestelmän toivottua tai vaadittua käytöstä. Voidaan puhua myös jatkuvasta monitoroinnista (continuous monitoring) [BG05]. Kuvassa 1 näkyy monitorien yleinen looginen rakenne. Itse monitori koostuu kahdesta osassa. Observer tarkkailee ajettavaa järjestelmää ja Analyzer vertaa havaittua käytöstä vaadittuun käytökseen. Lisäksi on aiheellista erottaa myös monitorin tarvitsemat syötteet (requirements), jotka kuvaavat toivotun käyttäytymisen, sekä toimenpiteet, jotka mahdollisesti herätetään (event handlers) käsittelemään virhetilannetta. Esimerkkinä voi mainita myöhemmin tarkemmin luvussa 3.1 kuvatut WSLAkehykseen kuuluvat Measurement, Condition Evaluation ja Management -palvelut. Seuraavaksi esitetään jaotteluja, joiden perusteella monitoreja voi luokitella sekä suuntia, joista monitorointia voi tarkastella. 2.1 Toiminnalliset ja ei-toiminnalliset vaatimukset Ajatellaan tilannetta, jossa asiakas pyytää tuottajalta palvelua. Toiminnallisesti ymmärrettynä vaatimukset täyttyvät, mikäli tarjoaja vastaa ennalta sovitulla tavalla, yksinkertaistaen esimerkiksi kyllä/ei. Mutta jos otetaan huomioon milloin tuottaja vastaa, siirrytään ei-toiminnalliselle puolelle. Sinänsä (toiminallisesti) oikea vastaus voi muuttua vääräksi, jos se saapuu liian myöhään. Monitoroinnin on kyettävä siis havaitsemaan saman tapahtuman molemmat, sekä toiminnalliset että eitoiminnalliset vaatimukset.

Kuva 1: Monitorien yleinen rakenne 3

4 Kuva 2: Qos Specications Palvelun laatu koostuu mitattavien metriikoiden ja luokittelevien politiikkojen yhdistelmästä. Metriikat kuvaavat esimerkiksi järjestelmän suorituskykyä, turvallisuutta tai palvelujen suhteellista tärkeyttä. Politiikat kuvaavat ehtoja ja rajoja, jotka järjestelmän tulee täyttää, ts. politiikat määrittelevät mikä on sallittua ja mikä ei. Ei-toiminnalliset vaatimukset pyritään kuvaamaan numeroarvoilla, joista voidaan tarvittaessa laskea myös koostettuja arvoja kuten keskiarvo. Tällä perusteella ei-toiminnallisille vaatimuksille voidaan antaa politiikkapohjaiset raja-arvot jotka joko toteutuvat tai eivät toteudu. Seuraavassa esitetään palveluun laatuun liittyvien käsitteiden luokittelu [SCD + 97], joka on havainnollistettu kuvassa 2. Ylimmän tason erottaja on akselilla metriikka / politiikka. 2.1.1 Metriikat Metriikat jaotellaan edelleen (i) suorityskykymetriikoihin (performance metrics), (ii) turvallisuus (security) ja (iii) suhteelliseen tärkeyteen (relative importance). Suorituskykymetriikoita ovat: Timeliness tarkoittaa aikaa liittyviä mittoja. Näitä ovat mm. vasteaika, palvelun alku- ja loppuajankohta. Aikaan liittyviä mittoja voi koostaa sekä laskea niistä tunnuslukuja. Aikaa liittyvät mitat ovat luonteeltaan intuitiivisia ja helposti ymmärrettäviä.

5 Precision tarkoittaa tässä yhteydessä kokoon liittyviä mittoja. Kokoon liittyvät mitat vaativat hyvän määrittelyn, sillä niiden tulkinta ei ole suoraviivaista. Samalla datalla voi olla erilaisia esitysmuotoja ja siten koko voi vaihdella esitystavasta riippuen. Esimerkkinä voi mainita vaikka jonkin tietorakenteen vaatiman fyysisen koon. Accuracy tarkoittaa virheettömyyttä. Esimerkkinä voisi mainita kuvatiedostot: mikä osa pikseleistä on todellisuudessa oikein? Missä määrin pakkaus hukkaa ja siten vääristää kuvaa? Combination metriikat koostuvat eri tyyppisten metriikoiden yhdistelmistä. Kuvatiedostoa esimerkkinä käyttäen pakkaukseen kuluvalla ajalla, kuvan koolla ja virheettömyydellä on yhteys. Yhteisvaikutuksen voi koostaa havainnolliseksi funktiolla. Relative importance kuvaa palvelupyyntöjen suhteellista tärkeyttä toisiinsa nähden. Minkä hinnan asiakas on valmis maksamaan palvelusta? Korkeamman hinnan tarjoajan on mahdollista saada pyynnölleen korkeampi prioriteetti. Palvelupyynnön tärkeyttä voi mitata prioriteetilla. Security metrics. Turvallisuuteen liittyvä mitattava ominaisuus on mm. palvelun saatavuus (availability) ts. järjestelmän turvallisuuden kannalta on kriittistä joidenkin palvelujen taattu saatavuus. Lisäksi voi mainita luotettavuuden (condentiality) ja yhtenäisyyden (integrity). 2.1.2 Politiikat Politiikat jaetaan palvelutasoihin (level of service) ja hallintapolitikkoihin (management policies). Level of Service määrittelee tason, johon tietty palvelu sitoutuu. Palvelutason voi ajatella meta-määritelmäksi palvelun konkreettisille laatuparametreille (QoS parameters), jotka mahdollistavat politiikkapohjaisten väittämien antamisen mitattaville metriikoille. Palvelutaso voi vaihdella taatusta (quaranteed service), jossa palvelu tuotetaan hinnasta riippumatta, toiseen ääripäähän, jossa palvelu vain yritetään suorittaa ilman takeita onnistumisesta (best eort service). Management Policies. Määrittelevät toimet, joihin ryhdytään tietyissä erikoistilanteissa. Esimerkiksi jonkun palvelun kaatuminen tai hidas toiminta voi johtaa

6 Kuva 3: Näkökulmia siihen, että asiakas haluaa uudelleen neuvotella sopimuksen ja mahdollisesti vaihtaa palvelun tuottajaa. Hallintapolitiikoilla ei ole määrällisiä mittareita ja ne ilmaistaan tyypillisesti luokkina esim. ALLOW tai DENIED jonkin ominaisuuden suhteen. Yleisesti politiikoita voi tarkastella eri konteksteissa. Sähköisten sopimusten (econtracts) kannalta politiikat ovat osa sopimukseen sisältyvää SLA:ta (Service Level Agreement). Toiseksi politiikoita voi tarkastella Web Service -arkkitehtuurin [web04b] kannalta, joissa ne voidaan ilmaista esimerkiksi WS-Policy:lla [web06]. Käytännössä sopimuksia solmittaessa käytetään usein normaalia ihmisten kirjakieltä, jota koneet eivät ymmärrä; näissä tapauksissa palvelutason kuvaaminen on yleensä kaikkea muuta kuin formaalia eikä siten olen valvontajärjestelmien ymmärtämää. 2.2 Näkökulmat Monitorointia voi tarkastella eri näkökulmista [SCD + 97], joita on havainnollistettu kuvassa 3. Käsitteet eivät suoraan vastaa SOA-maailman käsitteitä, mutta pyrin tarkastelemaan niitä SOA:n kannalta. Application perspective tarkastelee järjestelmää asiakkaan näkökulmasta. Asiakasta ei kiinnosta miten järjestelmä toimii kokonaisuudessaan, vaan se, miten hänen omat tarpeensa täyttyvät. Tässä tapauksessa palvelua katsotaan asiakasroolista. Asiakas voi toteuttaa itsenäisen monitoroinnin omista tarpeistaan lähtien. Resource perspective tarkastelee järjestelmään yksittäisen palvelun kannalta. Palvelun sisäistä toteutusta voi muutta palvelurajapinnan takana ilman, että se näkyy muille osapuolille. Tältä suunnalta voidaan katsoa esimerkiksi palvelujen priorisointia eri asiakkaiden kesken; jonkin asiakkaan palvelupyyntö voin olla tärkeämpi kuin jonkun toisen. Palvelun tuottaja voi olla kiinnostunut monitoroimaan itsenäisesti kykyään täyttää lupaamansa palvelutason tai toiminnallisuuden. Tässä yhteydessä voidaan puhua tuottajan roolista.

7 System perspective tarkastelee järjestelmää kokonaisuutena, kaikki osapuolet ja koko viestinnän kattaen. Toiminnalliselta kannalta ajateltuna tässä tapauksessa lähestytään koreograan käsitettä (luku 4). Systeeminäkökulman voi ajatella tarkoittavan sekä a) verkonhallinnan että b) koko liiketoimintaverkoston näkökulmaa. Monitorointi voi toimia koko järjestelmän tasolla mm. pitäen yllä yhteistä tilatietoa. 2.3 Abstraktiotasot Monitorit voivat sijoittua tai ne voivat havainnoida suorituksessa olevan järjestelmän tilaa eri abstraktiotasoilla [Haa05]. Perinteisessä tietoliikennemaailmassa valvonta voi toimia millä tahansa ISO OSI -mallin tasolla, alkaen fyysisen verkkokerroksen valvonnasta päätyen päätyen korkean sovelluskerroksen tasolle. Sähköisten liiketoimintaverkostojen kannalta katsottuna valvonnan abstraktiotasot voivan vaihdella sopimustasolta aina viestinvälitystasolle. Sopimustaso määrittelee liiketoimintavaatimukset ja viestinvälitystasolla käsitellään yksittäisiä viestejä ja niiden järjestystä. Helsingin yliopiston tietojenkäsittelytieteen laitoksen Web- Pilarcos prototyyppiprojektissa[web04a] valvonnan toteutus on jaettu abstraktiotasoihin. Lisäksi valvonta voi olla hierarkiaan liittymätöntä. Tällöin kyseessä on tasoriippumaton valvonta. Tasoriippumaton valvonta kuvaa ominaisuuksia jotka ovat aina olemassa kaikille sovelluksille. Extended SOA -arkkitehtuurissa (ESOA) [Pap03] valvonta sijoittuu Composition tasolle. 2.4 Kypsyystasot Palvelujen automaattinen valvonta voi toimia kolmessa eri moodissa. Valvonta on joko passiivista, aktiivista tai proaktiivista. Passiivisessa valvonnassa havaitut virheet kirjataan lokiin myöhempää käsittelyä varten. Passiivisen valvonnan etu on sen suorituskykymielessä vähäinen rasittavuus. Aktiivisessa moodissa järjestelmään ja sitä valvovaa ohjelmistoa ajetaan samanaikaisesti rinnakkain. Aktiivisessa tilassa toimiva valvonta pystyy ylläpitämään

8 tietoa järjestelmän tilasta. Havaittuihin virheisiin reagoidaan välittömästi, kuitenkaan valvottavan järjestelmän toimintaan vaikuttamatta ja tieto virheistä voidaan levittää reaaliaikaisesti kaikille osapuolille. Proaktiivisessa moodissa valvonta suoritetaan samanaikaisesti rinnakkain kuten aktiivisessakin moodissa, mutta synkronisoidusti valvottavan järjestelmän kanssa ja virheellinen toiminta estetään. Valvonnan tason pitää olla vähintään aktiivista ennen kuin voidaan puhua dynaamisesta monitoroinnista. 2.5 Valvontapisteet ja hajautus Valvonta voidaan hajauttaa. Monitorointi voi olla fyysisesti asiakkaan, palvelimen tai mahdollisen kolmannen osapuolen toteuttamaa. Edellisen luvun abstraktiotasojen kannalla katsottuna voi olla mahdollista löytää abstraktioraja, jota yleisempi valvonta on yhteistä (ts. on yhteinen jaettu tila), ja jota alempi monitorointi on selvästi paikallista. Valvontapisteillä tarkoitan kohtia, joissa monitorointi sidotaan valvottavaan järjestelmään. Valvonta voi olla upotettu lähdekooditasolla osaksi järjestelmää tai toisaalta olla itsenäinen fyysisesti eri koneessa ajettava ohjelma. Usein käytettyjä tekniikoita ovat mm. proxy:t ja välittimet. Tämän tyyppisistä välineistä voi mainita esimerkiksi XML -palomuurit. Web-Pilarcos prototyypissä [web04a] palvelujen valvontarutiinit on sijoitettu lokaalisti kommunikaatiokanavien päätepisteisiin [KMR05]. 3 SLA ja SLM Palvelutasosopimukset (SLA, Service Level Agreements) kuvaavat palvelun laatuun (QoS, Quality of Service) liittyvät vaatimukset. Palvelutasosopimuksien kuvaamiseen on olemassa useita eri kieliä. Sopimusten rakenne voi vaihdella, mutta kaikki kuvaavat yleensä ainakin seuraavat [KL03]: sopimuksen osapuolet palvelun mitattavat metriikat

9 laatuparametrit algoritmin laatuparametrien laskemiseksi metriikoista SLO:t (service level Objectives), jotka antavat raja-arvot laatuparametreille toimet, jotka suoritetaan palvelutasosopimusta rikottaessa. Palveluntasonhallinta (SLM, Service Level Managemet) voidaan ajatella prosessina tai palvelutasosopimusten suoritusympäristönä, jossa palvelutasosopimukset toteutetaan. Palveluntasonhallinta sisältää mm. palvelutasosopimusten monitoroinnin ja evaluoinnin. Palvelutasosopimukset ovat yleisesti käytettyjä IT palveluissa; hostaus- ja tietoliikenne palveluista aina help deskeihin. Eri yrityksillä on kuitenkin käytössään erilaisia parametrejä ja mittoja kuvaamaan palvelun laatua. Sopimukset on usein ilmaistu normaalin (ihmisen) kirjakielen keinoin. Tässä tapauksessa niiden toteuttaminen ja kääntäminen monitoroitavaan muotoon hyvin hidasta ja kallista. Kehitys ja tutkimus kulkee kohti sähköisiä ja osin automaattisesti neuvoteltavia sopimuksia (econtracts). Tästä kannalta katsottuna palvelutasosopimukset ovat osa sähköistä sopimusta ja määritelevät palvelun laatuvaatimukset (QoS, quality of Service). Palvelutasosopimukset eivät yksinään ole sähköisiä sopimuksia vain osa niitä 3.1 WSLA Web Service Level Agreement (WSLA) [KL03] on alunperin IBM:n kehys, joka on tarkoitettu tukemaan palvelutasosopimusten määrittelyä, prosessointia ja monitorointia Web Service -arkkitehtuurissa. WSLA-pohjaista lähestymistapaa on sovelluttu mm. TrustCoM:ssa [?]. WSLA-kehyksen osia on joustava ja laajennettava XML Schema -pohjainen SLA-kieli sekä suoritusympäristö, johon sisältyy monitorointiin ja raportointiin liittyviä palveluja. Ajatuksena on lisäksi, että osa monitorointitehtävistä voidaan antaa kolmannen osapuolen tehtäväksi, jolla pyritään suurempaan objektiivisuuteen ja mahdollisesti juridiseen pitävyyteen. Palvelutasosopimuksiin pohjautuen on mahdollista konguroida monitorointiympäristö automaattisesti.

10 3.1.1 Terminologia WSLA-arkkitehtuurin monitoroinnin kannalta olennaisia käsitteitä ovat: Resource Metrics ovat tyypillisesti saatavissa suoraan palvelun tarjoajan järjestelmistä. Näitä ovat esimerkiksi reitittimet, väliohjelmistot tai palvelimet. Tyypillinen esitys näille metriikoille on SNMP MIB:t (Simple Network Management Protocol, Management Information Base). Tällä tasolla mittauksen kohde on esimerkiksi suorituskykyyn liittyvä arvo tai laskuri. SLA määrittelee mitattavat kohteet. Composite Metrics koostuvat useista eri lähteistä saaduista metriikoista ja mahdollisesti jo aiemmin lasketuista kompositioista. Nämä metriikat voivat esimerkiksi ilmaista palvelun saatavuutta; palvelu on käytettävissä 23h vuorokaudessa tai jokin palvelu vasteaika on keskimäärin 5 sekuntia. Tämän tason metriikat voi luontevasti ulkoistaa kolmannelle osapuolelle tai palvelun tarjoaja voi itse koostaa nämä metriikat. Komposiitti metriikoiden laskeminen perustuu SLA:ssa määriteltyihin algoritmeihin. SLA parameters määrittelevät metriikoille kontekstin, joka liittyy nimettyyn asiakkaaseen ja siten liittää metriikat osaksi tiettyä sopimusta. Tämän tason metriikan voi ajatella asettavan rajat edellisessä kohdassa mainituille komposiittimetriikoille ts. SLA parametrien perusteella voidaan sanoa onko jokin sopimukseen liittyvä ehto toteutunut vai ei. Tällainen ehto voi olla esimerkiksi hyväksytty vaihteluväli. SLA parametrien tasolla tapahtuva monitorointi on luontevaa ulkoistaa tarvittaessa kolmannelle osapuolelle. Business Metrics kuvaavat miten edellisen kohdan SLA parametrit vastaavat liiketoiminnallisia vaatimuksia, liiketoiminta strategiaa ja/tai riskienhallintaa. Kuvassa 4 on havainnollistettu metriikkojen koostamista. WSLA-kehys tarjoaa useita malleja palvelutasosopimusten määrittelyyn ja sopimuksen neuvotteluun, mutta se ei sisälly tämän kirjoituksen aihepiiriin. 3.1.2 WSLA:n ajonaikainen arkkitehtuuri WSLA-arkkitehtuurin ajonaikaiset peruskomponentit ja palvelutason hallinnan viisi vaihetta näkyvät kuvassa5. Kuvan infrastruktuuri oletetaan toteutetuiksi Web Ser-

11 Kuva 4: WSLA:n metriikoiden koostaminen vice:llä ja palvelut kuvatuiksi WSDL:llä. Palvelutasosopimuksessa on viitteitä ko. WSDL-kuvauksiin. Kuvassa näkyvät viisi elinkaaren vaihetta ovat: 1. Palvelutasosopimuksen neuvottelu ja perustaminen. Tätä varten kehyksessä on toteutettu SLA Establishment Service. Tämä työkalu sallii asiakkaan hakea palvelun tarjoajan metriikat ja koostaa niistä mm. SLA:n parametrit. Tämän neuvottelun tulos on yksi sopimus. 2. SLA deployment. Tämä palvelu on vastuussa sopimuksen validoinnista, alustamisesta ja hajautuksesta eri osapuolille. 3. Palvelutason mittaaminen ja raportointi. Tämä vaihe konguroi ajonaikaisen ympäristön ja suorittaa SLA-parametrien laskennan perustuen resurssimetriikoihin. Tämä on olennainen vaihe dynaamisen valvonnan kannalta ja vaihe koostuu kahdesta palvelusta: Measurement service kerää ja ylläpitää tieto järjestelmän ajonaikaisesta tilasta. Measurement service mittaa SLA:ssa määriteltyjä metriikoita, kuten vasteaikaa tai saatavuutta. Measurement Service voi saada tiedot suoraan järjestelmästä tai esim. toimimalla välittäjänä (interceptor). Measurement Service voi mitata joko kaikkia tai osajoukkoa SLA parametrien määrittelemistä ominaisuuksista. Measurement Servicen voi ajatella luvun 2 määritelmien mukaiseksi tarkkailijaksi (observer).

12 Kuva 5: WSLA:n ajonaikainen arkkitehtuuri Condition Evaluation Service vertaa mitattuja arvoja SLA-parametreissä määriteltyihin arvoihin ja testaa vastaavatko ne luvattuja rajoja. Evaluointi voi olla jatkuvaa tai se voi perustua näytteisiin. Condition Evaluation Service:n voi ajatella luvun 2 määritelmien mukaiseksi analysaattoriksi (analyzer). 4. Management service on vastuussa korjaavista toimenpiteistä, mikäli Condition Evaluation Service havaitsee virheitä. Management Service:n voi ajatella luvun 2 määritelmien mukaiseksi tapahtumankäsittelijäksi (event handler). 5. SLA Termination. 3.1.3 Monitoroinnin ulkoistaminen Perinteisesti SLA:t ovat olleet kahdenvälisiä sopimuksia asiakkaan ja palvelun tarjoajan välillä. Määritelmä: signatory parties ovat sopimuksen allekirjoittavat osapuolet. WSLA-arkkitehtuuriin kuuluu olennaisena osana mahdollisuus ulkoistaa moni-

13 Kuva 6: WSLA: Ulkoistettu valvonta torointi. Mikäli sopimuksen solmineet osapuolet eivät halua valvoa palvelua tai he eivät luota toisiinsa, on ratkaisuna kolmas osapuoli. Monitoroinnin ulkoistamisella voidaan pyrkiä mm. juridiseen pitävyyteen. Kolmannet monitoroivat osapuolet toimivat sopimusta tukevassa roolissa. Kuvassa 6 on havainnollistettu ulkoistettua valvonta. 4 Koreograat W3C:n määritelmän [web04d] mukaan koreograa kuvaa vuorovaikutuksen palvelun ja asiakkaan välillä. Määritelmän mukaan ei ole mahdollista nimetä nimetä yksittäistä tahoa, joko kontrolloin koko vuorovaikutusta. Käytännössä koreograakielistä esimerkiksi BPEL sallii kuvauksen kuitenkin sekä a) abstraktilla, koko verkoston kattavalla tasolla että b) konkreettisena suorituskelpoisena koodina yhden osapuolen kannalta. Koreograa kuvaa mm. viestintään käytettävät sanomat ja niiden järjestyksen. Lisäksi koreograan tulee määritellä toimenpiteet, joihin ryhdytään virhetilanteissa. Koreograa voi olla implisiittinen, jolloin yhteistoiminta sovitaan yleisellä tasolla, tai eksplisiittinen, jolloin vuorovaikutus kuvataan tarkemmin lisäten kuvaukseen

14 syntaksi, semantiikka ja hyväksytyn käyttäytymisen tarkka kuvaus. Eksplisiittisen koreograan etu on sen verioitavuus ja mahdollisuus valvoa sen kulkua suoritusaikaisesti. Verioinnin ja dynaamisen valvonnan edellytys on, että koreograa kuvataan jollain formaalilla kielellä. Tällainen kieli on esimerkiksi Web Services Choreography Description Language (WS-CDL) [web04c]. Koreograakuvauksesta voi generoida koodirunkoja toteutuksen avuksi sekä syötteitä monitoreille. Koreograan kulkua voidaan suoritusaikaisesti valvoa esimerkiksi rakentamalla koreagraaa vastaava tilakone [MJSSW03] [Haa05]. 5 Yhteenveto Järjestelmien koko on kasvanut ja samalla ne ovat muuttuneet niin monimutkaisiksi, että niiden toimintaa on vaikea tai jopa mahdoton ennalta testata ja verioida. Tätä kehitystä ovat edesauttaneet esimerkiksi palveluperustaisten järjestelmien yleistyminen. Palveluperustaiset järjestelmät toimivat luonteensa mukaisesti autonomisesti heterogeenisessä ympäristössä. Lisäksi järjestelmiä koostetaan dynaamisesti esim. sähköisiin sopimuksiin pohjautuen; näiden sopimusten vaatimusten toteutumista ei voi varmistaa etukäteen vaan oikeellisuus on varmistettava dynaamisesti. Luvussa 2 tarkasteltiin monitorien yleistä rakennetta. Monitorointia voi tarkastella useista eri suunnista. Palvelutasosopimuksien kannalta korostuvat palvelun laatuun liittyvät tekijät ja koreograoiden kannalta toiminnalliset ominaisuudet. Dynaaminen valvonta voi olla suorituskykymielessä raskasta, koska valvontaa ajetaan samanaikaisesti rinnakkain valvottavan järjestelmän kanssa. Jos valvonta hajautetaan, se lisää järjestelmän monimutkaisuutta ja vaikeuttaa hallintaa. Myös eri abstraktiotasoilla tapahtuva monitorointi lisää kompleksisuutta. Lisäksi on vaikea tehdä rajaus, onko monitorointifunktio osa itse järjestelmää vai onko se erillinen kokonaisuus. Lopputulos on monimutkainen ja voisi jopa esittää kysymyksen: pitäisikö monitorointia monitoroida? Toisaalta taloudelliset vaatimukset asettavat rajoja. Onko monitorointi kustannustehokasta vain onko halvempaa hyväksyä virhellinen toiminta ja korvata vahingot erikseen?

Lähteet BG05 DGR04 Baresi, L. ja Guinea, S., Towards dynamic monitoring of ws-bpel processes. Proceedings of the 3rd International Conference of Service-oriented Computing (ICSOC'05), 2005, sivut 269282. Delgado, N., Gates, A. Q. ja Roach, S., A taxonomy and catalog of runtime software-fault monitoring tools. IEEE Trans. Softw. Eng., 30,12(2004), sivut 859872. 15 Haa05 Haataja, J., Yritysten yhteistoimintaverkostojen valvonta Webpalveluympäristössä. Pro gradu, Department of Computer Science, University of Helsinki, maaliskuu 2005. URL http://www.cs.helsinki. fi/group/web-pil/docs/haataja_thesis.pdf. In Finnish. KL03 KMR05 MJSSW03 Pap03 SCD + 97 Keller, A. ja Ludwig, H., The wsla framework: Specifying and monitoring service level agreements for web services. J. Netw. Syst. Manage., 11,1(2003), sivut 5781. Kutvonen, L., Metso, J. ja Ruokolainen, T., Inter-enterprise collaboration management in dynamic business networks. On the Move to Meaningful Internet Systems 2005: CoopIS, DOA, and ODBASE: OTM Confederated International Conferences, CoopIS, DOA, and OD- BASE, osa 3760 sarjasta Lecture Notes in Computer Science, Agia Napa, Cyprus, marraskuu 2005, URL http://dx.doi.org/10.1007/ 11575771_37. Molina-Jimenez, C., Shrivastava, S., Solaiman, E. ja Warne, J., Contract representation for run-time monitoring and enforcement. cec, 0, sivu 103. Papazoglou, M. P., Service -oriented computing: Concepts, characteristics and directions. wise, 00, sivu 3. Sabata, B., Chatterjee, S., Davis, M., Sydir, J. J. ja Lawrence, T. F., Taxonomy for qos specications. Workshop on Object-Oriented Real- Time Dependable Systems (WORDS). IEEE Computer Society, 1997, URL citeseer.ist.psu.edu/sabata97taxonomy.html. web04a Web-pilarcos project, 2004. http://www.cs.helsinki.fi/group/ web-pil. [19.9.2006]

16 web04b Web services architecture, 2004. http://www.w3.org/tr/ws-arch/. [11.10.2006] web04c Web services choreography description language (ws-cdl v1.0), 2004. http://www.w3.org/tr/ws-cdl-10/. [19.9.2006] web04d Web services glossary, 2004. http://www.w3.org/tr/ws-gloss/. [11.10.2006] web06 Web services policy 1.5 - framework, 2006. http://www.w3.org/tr/ ws-policy/. [11.10.2006]