PALVELUSOPIMUSTEN MONITOROINTI
Hyväksymispäivä Arvosana
Arvostelija
PALVELUSOPIMUSTEN MONITOROINTI
Xxxxx Xxxx
Helsinki 22.4.2009 HELSINGIN YLIOPISTO
Tietojenkäsittelytieteen laitos
Tiedekunta/osasto – Fakultet/Sektion – Faculty/Section Matemaattis- luonnontieteellinen/tietojenkäsittelytiede | Laitos – Institution – Department Tietojenkäsittelytieteen laitos | |
Xxxxxx – Författare – Author Xxxxx Xxxx | ||
Työn nimi – Arbetets titel – Title | ||
Oppiaine – Läroämne – Subject Seminaari: Palvelusuuntautuneet järjestelmät | ||
Työnlaji – Arbetets art – Level Seminaaripaperi | Aika – Datum – Month and year 4 / 2009 | Sivumäärä – Xxxx xxxxx – Number of pages 15 |
Tiivistelmä – Referat – Abstract Kun asiakkaan ja palveluntuottajan välille solmitaan palvelusopimus, se sisältää usein sanktiot palvelusopimuksen laatukriteereiden alittamisesta. Jotta näitä palvelusopimuksia voidaan valvoa, täytyy palveluiden käytettävyyttä valvoa jat- kuvasti. Tämä seminaarityö käsittelee palvelusopimusten monitorointia. ACM Computing Classification System (CCS): D.4.8 [Performance]: Monitors, X.3.5 [Online Information Services]: Web-based services, K.6.2 [Installation Management]: Performance and usage measurement, K.6.4 [System Management]: Quality assurance, K.6.m [Miscellaneous]: Contracts. | ||
Avainsanat – Nyckelord – Keywords Monitoring, Service Level Agreements, Web services | ||
Säilytyspaikka –Förvaringsställe – Where deposited - | ||
Muita tietoja –Övriga uppgifter – Additional information - | ||
Sisältö
1 JOHDANTO 1
2 MONITOROINNIN TARVE 2
2.1 Palvelusopimukset 2
2.2 Tärkeimmät mittauskohteet 2
2.3 Sanktiot 3
2.4 Palveluntarjoajan näkökulma 4
3 MONITOROINNIN HAASTEET 5
3.1 Testaus 5
3.2 Mittausepävarmuus 5
3.3 Lokit 6
3.4 Esimerkki monitoroitavasta palvelutilanteesta 6
3.5 Keskinäinen syyttely 7
3.6 Vastuun ja riskien jakaminen 8
3.7 Sopimusyhdistelmän määrittäminen 8
3.8 Sopimusyhdistelmät monen operaattorin tapauksessa 9
4 MONITOROINNIN TOTEUTUS 10
4.1 Toimintaympäristö 10
4.2 Monitorin toteutus 11
4.3 Käsittelijät 12
4.4 Vuorovaikutteinen palvelu 13
5 YHTEENVETO 13
LÄHTEET 14
1 Johdanto
Jos organisaation tietojärjestelmät ovat riippuvaisia kumppanien tarjoamien pal- veluiden saatavuudesta ja laadusta, niiden tasosta sovitaan usein yhteisellä palvelusopimuksella (Service Level Agreement, SLA). Ulkoistamisen riskien hallitsemiseksi sopimuksessa voidaan määritellä rangaistusmaksu huonosta palvelutasosta. Jotta palveluntaso voidaan todentaa, tulee tarjottuja palveluja monitoroida. Monitoroitavia suureita voivat olla erilaiset aikarajat, luotettavuus ja suoritettujen palvelujen lukumäärä.
Monitorointi on vaativa toimenpide. Palveluita voidaan etsiä ja hyödyntää ohjel- mistojen suorituksen aikana. Tällöin palvelutason sopimisen ja sen monitoroin- nin täytyy noudattaa samaa periaatetta. Monitoroinnin tulisi olla jatkuvaa ja sen tulee skaalautua suurellekin määrälle palvelutapahtumia. Palvelutason alittami- sesta seuraavista maksuista johtuen, kaikkien osapuolien tulisi voida valvoa toistensa palveluja. Näitä valvonnan tuloksia ei voi soveltaa sellaisenaan. Kaikki osapuolet eivät välttämättä kerro tuloksiaan rehellisesti, lisäksi mittavirheet ja - epätarkkuudet sotkevat tuloksia.
Edellä mainituista seikoista johtuen monitoroinnissa on selvitettävä mitä kannat- taa ja voi monitoroida, miten se tehdään ja miten tuloksia tulkitaan. Tässä työs- sä käydään läpi miksi monitoroidaan, mitä monitoroinnissa tulisi ottaa huomioon ja käsitellään lopuksi monitoroinnin toteutusta.
Luvussa 2 selvitetään monitoroinnin tarvetta. Luvussa 3 esitellään mitä monito- roinnissa tulisi ottaa huomioon. Luvussa 4 käsitellään monitoroinnin toteutusta. Luku 5 sisältää yhteenvedon.
2 Monitoroinnin tarve
Palveluperustaisessa tietotekniikassa voidaan tarvittava palvelutaso määrittää palvelusopimuksessa. Palvelutaso edellyttää usein palvelun nopeuteen, luotet- tavuuteen ja suorituskykyyn liittyviä laatumääreitä [ERS08]. Nämä määreet tulisi määritellä siten, että ne ovat mitattavissa. Palvelunkäyttäjä sijoittaa aikaa ja re- sursseja palvelun integrointiin, joten palvelun laadulla ja saatavuudella on ta- loudellista merkitystä hänelle [CES07]. Palvelutarjoajan tulisi pystyä takaamaan palvelun laatu (QoS) koko palvelun elinkaaren ajaksi [ELS03].
2.1 Palvelusopimukset
Palvelujen käytöstä sovitaan kahdenkeskisillä palvelutasosopimuksilla (SLA), jotka määrittelevät palvelun laatutason [ERS08]. Niissä voidaan määritellä pal- velusopimuksen kesto, tarjottava kapasiteetti, vasteajat, prioriteetit, vastuut ja sanktiot sovitun palvelutason alituksista. Palvelusopimuksia voidaan tehdä oh- jelmiston ajoaikana. Jotta sopimuksia voidaan noudattaa ja valvoa, niiden tulisi olla ymmärrettäviä, täsmällisiä ja monitoroitavissa [ERS08].
Palvelusopimuksia varten on kehitteillä eri tekniikoita. WSLA (Web Service Le- vel Agreement) on Web palveluihin tarkoitettu palvelusopimus, joka perustuu XML-merkkauskielen käyttöön. Toinen kehitysasteella oleva kieli palvelusopi- muksia varten on SLAng, jossa siinäkin palvelusopimukset esitetään XML- merkkauskielellä. SLAng:ia kehitetään siten, että sillä on mahdollista esittää ei- toiminnallisia vaatimuksia sopimuksissa palvelun laadun vaatimuksia varten [ELS03].
2.2 Tärkeimmät mittauskohteet
Tärkeimmät mitattavat ei-toiminnalliset määreet ovat aikaan (timeliness), luotet- tavuuteen (reliability) ja tuotokseen (throughput) liittyvät rajoitukset [ERS08].
Näitä kaikkia tulisi voida monitoroida jatkuvasti.
Aikamäärettä kuvataan viiveellä, joka on palvelukutsun ja palautteen välillä. So- pimuksessa voidaan vaatia missä ajassa palautteen (response) tulee seurata pyyntöä (request). Luotettavuutta voidaan kuvata esimerkiksi sopimalla kuinka monta virhettä sallitaan tietyssä ajassa [ERS08].
Asiakkaan kyky lähettää oikeanlaisia palvelukutsuja vaikuttaa palvelun toimi- vuuteen. Jos tätä ei oteta huomioon, voi asiakas vaatia vilpillisesti korvauksia ongelmista, jotka on itse aiheuttanut [ERS08].
2.3 Sanktiot
Sopimuksessa on mahdollista määrittää rahallinen sanktio palvelutason alitta- misesta [CES07]. Nämä palvelusopimuksessa määritellyt sanktiot ovat meka- nismi palvelunkäyttäjän riskien minimoimiseen [CES07]. Koska tässä käsiteltä- vä monitorointi kohdistuu lähinnä palvelusopimusten täyttämiseen liittyvien asi- oiden mittaamiseen, koskevat toimijoiden motiivit monitoroinnin osalta lähinnä edellä mainittuja sanktioita.
Jos palvelusopimuksessa on määritelty rahallinen sanktio, muuttaa se seuran- nan luonnetta. Monitoroinnilla voidaan kerätä todisteet palvelutason alituksista. Lähtökohtaisesti kukaan ei halua maksaa sanktioita missään tilanteessa [CES07]. Täten vahingonkorvausvaatimuksia varten on pystyttävä keräämään mahdollisimman aukottomat todisteet. Vahingonkorvauksista johtuen kiusaus petkuttamiseen kasvaa tai vaihtoehtoisesti itse aiheutetut vahingot saatetaan maksattaa kolmannella osapuolella, joka olisi sinänsä toiminut hyvässä uskossa [ERS08].
Näiden todisteiden kerääminen ei ole mahdollista ellei palvelusopimuksen sank- tiopykäliä ole määritelty tarkasti. Niiden tulee olla täsmällisiä ja ymmärrettäviä [CES07]. Lisäksi niiden tulee olla monitoroitavissa ja tulosten mitattavissa tilas- totieteen menetelmin [CES07].
2.4 Palveluntarjoajan näkökulma
Palveluntarjoajan tulee voida huolehtia omista intresseistään. Niinpä palvelun- tarjoajan kannalta on vähintäänkin neljä syytä monitorointiin palvelusopimuksen puitteissa [ERS08].
Palvelutarjoajan tulee voida varmistaa esitetyt korvausvaatimukset es- tääkseen vilpilliset vaatimukset.
Palveluntarjoajan pitää huomioida sovitun käytön ylittävä käyttö ja muut mahdolliset väärinkäytökset.
Palvelutasoja tulee tarkkailla, etteivät ne alita taattuja raja-arvoja.
Palvelukapasiteetin tarkkailu kertoo onko riittävästi kapasiteettia ottaa uusia asiakkaita tai tarjota nykyisille asiakkaille lisää palveluja.
Palvelukapasiteettiin ja sitä kautta palvelutasoon voidaan tarvittaessa puuttua ainakin kahta kautta. IT-infrastruktuuriin voidaan tehdä tarpeelliset muutokset esimerkiksi hankkimalla lisää palvelinkapasiteettia tai muuttamalla ohjelmisto- konfiguraatio vastamaan paremmin palveluvaatimuksiin [ERS08].
Palvelusopimukset voidaan jakaa turvallisiin ja turvattomiin palveluntarjoajan näkökulmasta [ERS08]. Turvallisessa vaihtoehdossa palveluntarjoaja voi omilla toimillaan taata koko palveluketju toimivuuden. Vaihtoehtoisesti ne osat palve- luketjua, joihin palvelutarjoajalla ei ole pääsyä, voidaan turvata palvelusopimuk- sella. Turvattomassa vaihtoehdossa palveluntarjoaja ei voi vaikuttaa osaan pal- veluketjua, eikä omaa sopimusta niiden toimivuudesta. Tällöin palveluntarjoajal- la on mahdollisuus joutua maksamaan korvauksia toisen palveluntarjoajan huo- nosta palvelutasosta ilman, että itse voi vaikuttaa asioihin mitenkään.
3 Monitoroinnin haasteet
Monitorointi on haastava tehtävä, joka on kallista eikä se koskaan voi olla täy- dellistä [BaC08b]. Ongelmia aiheuttavat erilaiset mittavirheet ja sopimusten eh- toihin liittyvät epätarkkuudet [CES07].
Jotta monitoroinnista olisi hyötyä, täytyy sopimuksessa mainittujen vaatimusten olla sellaisia, että niiden täyttymistä voidaan ylipäätään valvoa. Valvonnan mahdollisuus voi olla vain yhdellä osapuolella tai molemmilla sopimusosapuolil- la. Paras tilanne valvonnan kannalta kuitenkin on, jos valvontaa voi suorittaa myös molempien osapuolten luottama kolmas osapuoli.
3.1 Testaus
Normaali testaus uutta palvelua käyttöönotettaessa on tarpeellista, mutta riittä- mätöntä ulkopuolista palvelua hyödynnettäessä [ERS08]. Tällainen testaus kat- taa usein palvelun suorituskyvyn ja luotettavuuden läpikäynnin. Samalla voi- daan varmistua palvelun sopivuudesta omaan käyttöön.
Palveluympäristössä palvelun laatu riippuu kuitenkin enemmän palveluntarjo- ajan kyvykkyydestä ylläpitää palvelunlaatua koko sen elinkaaren ajan [ERS08]. Lisäksi palvelunlaatuun voi vaikuttaa sen suosio, joka aiheuttaa sille kuormaa muiden käyttäjien taholta. Tällöin palveluja on monitoroitava joko jatkuvasti tai niiden toiminnasta on kerättävä tilastollisesti merkittävä aineisto [ERS08].
3.2 Mittausepävarmuus
Mittaamiseen liittyy aina epävarmuus. Mittauksen tulos on parhaimmillaankin vain arvio. Täten monitorointiin liittyvät osapuolet eivät voi yksinkertaisesti vain esittää mittaamiaan tuloksia ja tehdä vaatimuksia tai oletuksia palvelutasosta tulkitsematta ensin mittaustuloksia. Mittaustarkkuus tulisikin sopia etukäteen [CES07].
Mittaustarkkuuden sopiminen on kuitenkin hankala tehtävä. Sen tulisi olla oi- keudenmukainen molempia osapuolia kohtaan ja eikä itse mittavirhettä voi mo- nitoroida [CES07]. Siksi tätä koskeva rajoitus tulisi suunnitella siten, että se voi- daan arvioida tilastollisin menetelmin [CES07].
3.3 Lokit
Pidettäessä kirjaa tapahtumista voidaan jälkikäteen todistaa sopimusrikkomuk- set. Kaikissa tilanteissa ei ole kuitenkaan mahdollista pitää täydellistä lokia ta- pahtumista. Syynä saattaa olla tilanpuute tai lokien kirjoittaminen saattaa osoit- tautua liian raskaaksi toimenpiteeksi. Nämä rajoitteet koskevat varsinkin mobiili- laitteita.
Ilman täydellistä lokia tapahtumista saattaa olla vaikea osoittaa sopimusrikko- muksia. Jos esimerkiksi tallennetaan vain epäonnistuneet tapahtumat, saattaa palveluntarjoaja esittää, että palvelua on ylikuormitettu [ERS08]. Tästä ei kui- tenkaan ole mitään näyttöä suuntaan tai toiseen, jos loki sisältää vain virhetilan- teet.
3.4 Esimerkki monitoroitavasta palvelutilanteesta
Monitorointiin liittyviä kysymyksiä käydään läpi seuraavissa luvuissa kuvassa 1 esitetyn palvelumallin mukaisesti.
Kuva 1: Kolmen välinen palvelutilanne [CES07].
Kuvassa 1 on esitetty yksinkertainen palvelumalli, joka kuvaa tavallista palvelu- tilannetta. Kuvassa vasemmalla on asiakas (C), oikealla palveluntarjoaja (S) ja niiden välissä operaattori (I). Asiakas tekee palvelupyynnön (dispatch), joka lähetetään palveluntarjoajalle (send). Palveluntarjoaja käsittelee palvelupyyn- nön (process) ja lähettää vastauksen (respond). Pyynnön kuten vastauksenkin välittää operaattori.
3.5 Keskinäinen syyttely
Tällaisessa ympäristössä on helppo olettaa seuraavanlainen skenaario. Asiakas lähettää palvelupyynnön, muttei saa vastausta. Palveluntarjoaja väittää, ettei saanut pyyntöä ja operaattori väittää kuitenkin sellaisen välittäneensä. Molem- milla osapuolilla on esittää helposti väärennettävät lokit, jotka todistavat väitteet [CES07]. Tällaisessa tilanteessa asiakkaan on vaikea esittää korvausvaatimuk- sia.
Jos oletetaan, että asiakas vaatii korvauksia palveluntarjoajalta, voi palveluntar- joaja esittää, että sopimuksessa on luvattu esimerkiksi 95% saavutettavuus so- pimuksen elinkaaren ajalle ja se tullaan saavuttamaan. Kun aikaa kuluu ja vir- hetilanteita tulee lisää, voi palveluntarjoaja vedota, että vaikka kaikkiin pyyntöi- hin ei ole vastattu, on palvelu ollut kuitenkin kaikkina muina aikoina käytettävis- sä ja näin ollen 95% saatavuus saavutetaan [CES07]. Näin ollen asiakas kään- tyy operaattorin puoleen. Operaattori esittää oman todistusaineiston ja kertoo välittäneensä palvelupyynnöt.
Edellä mainitussa tilanteessa asiakas on heikoilla esittäessään korvausvaati- muksia. Sopimuksesta on vähän tai ei ollenkaan tukea vaatimuksille. Monito- roinnistakaan ei vaikuta olevan hyötyä. Asiakas ei voi monitoroida milloin hänen käyttämänsä palvelu on päällä ja milloin ei, eikä asiakas voi monitoroida toimit- taako operaattori palveluviestin perille vai ei.
3.6 Vastuun ja riskien jakaminen
Yksi ratkaisu edellisessä luvussa kuvatun tilanteen selvittämiseksi on tehdä useampia sopimuksia, joilla vastuuta jaetaan [CES07]. Tällöin operaattori ja palveluntarjoaja voivat tehdä keskinäiset sopimukset. Tästä seuraa luonnolli- sesti lisää sopimuksia monitoroitavaksi.
Jos oletetaan edellisessä esimerkissä, että viestinvälityksestä vastaa vain yksi operaattori ja täydellisen luotettavia lokeja ei ole saavissa, tulisi sopimusten olla yhteisesti monitoroitavissa. Operaattorin tulisi tarjota sopimus asiakkaan verk- korajapintaan ja palveluntarjoajan tulisi tarjota sopimus omaan verkkorajapin- taansa operaattorille [CES07]. Näin saadaan sopimusten kattama ketju asiak- kaalta palveluntarjoajalle siten, että kaikki sopimukset ovat vähintään kahden osapuolen monitoroitavissa. Jos tällainen ei ole mahdollista, tulisi kehittää luo- tettavia sulautettuja monitorointiratkaisuja verkko- ja palveluinfrastruktuuriin [CES07].
3.7 Sopimusyhdistelmän määrittäminen
Edellisessä luvussa esitettiin, että käytännössä sopimuksia tulisi tehdä useam- pia, jotta voidaan turvata kaikkien osapuolien edut. Eri sopimusyhdistelmävaih- toehtojen lukumäärä on lähes rajaton. Taulu 1 sisältää eri sopimusyhdistelmä- vaihtoehtojen lukumäärän esimerkkitapauksessa.
Taulu 1: Sopimusyhdistelmävaihtoehtojen lukumäärät monitoroitavuuden mu- kaan jaoteltuna.
Taulussa on jaoteltu sopimusvaihtoehdot monitoroitavuuden mukaan seuraa- vasti.
Sat (satisfaction), sopimuksen tulee olla osa asiakkaan palveluketjua.
Safe (safety), sopimuksen tulee olla palveluntarjoajan monitoroitavissa tai toisella sopimuksella turvattu.
Non-red (Non-redundancy), ei tarvita päällekkäisiä sopimuksia. Non-rec (Non-reciprocity), ei vastakkaisia sopimuksia.
Non-client, asiakkaan ei tule tarjota palvelusopimuksia.
Mon (monitorability), sopimuksen tulee olla monitoroitavissa.
Arb (arbitratability), luotettava kolmas osapuoli pystyy monitoroimaan so- pimuksen.
Koko verkon kattavaa yhtä sopimusta ei tarvita, eikä luotettava sellaista voi itse asiassa ollakaan [ERS08]. Tarvitaan siis yhdistelmä sopimuksia, jos kaikkien edut halutaan yhtäläisesti turvata. Edellä olevan taulun jaottelun mukaan vain yksi sopimusyhdistelmä on mahdollinen siten, että asiakkaan vaatimukset täyt- tyvät ja kaikki sopimukset ovat molempien osapuolten monitoroitavissa ja turval- lisia [CES07]. Tämä on nimenomaan luvussa 3.6 esitetty sopimusyhdistelmä.
3.8 Sopimusyhdistelmät monen operaattorin tapauksessa
Vastuun ja riskien jakaminen monen operaattorin tapauksessa onnistuu ketjut- tamalla sopimukset. Sopimukset ketjutetaan asiakkaalta palveluntuottajalle si- ten, että jokaisen peräkkäisen operaattorin välillä on omat palvelusopimukset [CES07]. Tämä tilanne on kuvattu kuvassa 2.
Kuva 2: Palvelusopimusketju usean operaattorin välillä [CES07].
Esitetyssä mallissa jokaisen uuden operaattorin ajatellaan olevan asiakas. Ku- vassa tällainen väliasiakas on C1. Ensimmäisen verkon osalta tehdään siis so- pimuskuvio, jossa operaattori kaksi on asiakkaan ominaisuudessa. Toisen ver- kon osalta tehdään sopimuskuvio, jossa operaattori kolme on asiakkaan omi- naisuudessa ja operaattori yksi on palvelun tuottajan asemassa. Tätä kuviota jatketaan kunnes sopimukset kattavat katkeamattoman ketjun asiakkaan ja pal- veluntarjoajan välillä.
4 Monitoroinnin toteutus
Monitorointi voidaan jakaa reaaliaikaiseen monitorointiin ja ei-reaaliaikaiseen monitorointiin [ERS08]. Ei-reaaliaikaisessa monitoroinnissa kerätään tietoja pal- velun toiminnasta myöhempää analysointia varten. Reaaliaikaisen monitoroin- nin perusteella saadaan varoitukset palvelutason heikkenemisestä välittömästi ja niihin voidaan reagoida ilman viivettä [ERS08]. Reaaliaikainen monitorointi voi vähentää merkittävästi palveluntarjoajan tappioita, ei-reaaliaikaiseen statis- tiikaan vetoamalla voi vastaavasti kuluttaja hakea korvausta kärsimistään va- hingoista.
Monitorointi on sitä tärkeämpää mitä enemmän palvelut omaavat muuttuvia ominaisuuksia ja tukevat lyhytaikaista toimintaa [BGG04]. Tällöin sopimuksista tulisi voida generoida automaattisesti niitä valvovat monitorit tai ne eivät ennätä reagoida muutoksiin [BaC08a].
4.1 Toimintaympäristö
Web palvelut (Web Services) ovat tapa, jolla palveluita käytännössä toteute- taan. Web palvelut sisältävät mekaniikan, jolla palveluntarjoajia voidaan suori- tusaikana etsiä ja sopia laatuparametrit [BGG04]. Web palvelujen dynaamisesta luonteesta johtuen ne vaativat jatkuvan reaaliaikaisen monitoroinnin [BiG07].
Uusi Web palveluja kehitetään ja julkaistaan asiakkaiden käyttöön ja käytetyt palvelut voivat kadota käytöstä ilman varoitusta. Lisäksi Web palvelujen sidok- set saattavat vaihtua ajoaikana. Tällaista toimintaympäristöä voidaan kuvata termillä avoimen maailman ohjelmistot (open-world software).
Näistä kaikista muutosmahdollisuuksista johtuen monitoroinnin tulee olla jatku- vaa [BiG07]. Tällöin myös validoinnin ja monitoroinnin tulee ulottua kehityksestä ajoaikaiseksi [BiG07].
4.2 Monitorin toteutus
Yksi tapa valvoa sopimuksia on monitoroida BPEL (Web Services Business Process Execution Language) prosesseja suoritusaikana [BGG04]. BPEL kieltä käyttäen voidaan orkestroida palvelukokonaisuus. Tällaisesta kokonaisuudesta voidaan monitoroida kolmea erilaista virhetilannetta. Nämä ovat aikakatkaisut, suoritusaikaiset virheet ja sopimuksen toiminnallisten rajoitusten rikkominen [BGG04].
Aikakatkaisut ja suoristusaikaiset virheet voidaan valvoa BPEL kieltä ja hyviä suunnittelumalleja käyttäen [BGG04]. Toiminnalliset rikkomukset voidaan moni- toroida käyttämällä tätä varten tehtyjä monitoreja, jotka ovat itsekin Web palve- luita [BGG04]. Lopullinen valvonta tapahtuu siis tarkkailemalla monitorien anta- mia viestejä. Kuvassa kolme on prosessi, joka on muutettu monitoroiduksi pro- sessiksi.
Kuva 3: Standardin prosessin muunto monitoroiduksi prosessiksi [BGG04].
4.3 Käsittelijät
Koska palveluperustaiset tietojärjestelmät perustuvat viestien välitykseen, ovat käsittelijät tehokas tapa monitoroida liikennettä. Yksi tapa tehokkaaseen moni- torointiin löytyy käyttämällä Apachen AXIS käsittelijöitä, joilla siepataan liikenne [ERS08]. Valmiit Java-luokat voidaan generoida palvelusopimuksista, jotka on laadittu SLAng:ia käyttäen [ERS08]. Nämä luokat voidaan asentaa asiakkaan tai palveluntarjoajan palvelimelle.
Kuva 4: Eclipse käyttö [ERS08]. Kuva 5: Monitorien asennus [ERS08]. Kuvassa neljä on kaavio luokkien generoimisesta Eclipse:n liitännäistä käyttä-
en. Vaikka luokat saadaan valmiiksi käännettäviksi, ne täytyy kuitenkin erikseen asentaa käyttöön. Kuvassa viisi on kuvattu näiden generoitujen luokkien (Checker) sijoittaminen tuotantoon.
4.4 Vuorovaikutteinen palvelu
Vuorovaikutteiset palvelut ovat tilallisia. Tällöin niihin ei päde yksinkertainen monitorointi, jossa tutkitaan, että lähtöarvo ja loppuarvo vastaavat toisiaan [BiG07]. Tilattomat palvelut siis palauttavat aina saman lopputuloksen, jos niitä kutsutaan samalla lähtöarvolla. Vuorovaikutteisessa palvelussa tapahtumien kulku riippuu aiemmista tapahtumista asiakkaan ja palveluntarjoajan välillä.
Jotta vuorovaikutteista palvelua voidaan monitoroida, tarvitaan määrittely palve- lun käyttäytymisestä. Monitorointia vaikeuttaa se tosiseikka, että palvelun jokai- sella instanssilla on oma tila, joka ei näy muille. Esimerkki tällaisesta vuorovai- kutteisesta tilallisesta palvelusta on virtuaalinen ostoskori [BiG07].
Yksi esitetty tapa vuorovaikutteisen palvelun monitorointiin on käyttää algebral- lista määrittelyä [BiG07]. Tällöin palvelun salattu tila on pääteltävissä suorite- tuista toimenpiteistä. Monitoroimalla toimenpiteet tiedetään mikä pitäisi olla lop- putulema.
5 Yhteenveto
Palvelusopimukset tehdään asiakkaan ja palveluntarjoajan välille. Molemmille osapuolille on määritelty sopimukseen omat vastuut. Asiakkaan ei tule käyttää palveluita sovittua käyttömäärää enempää ja palveluntarjoajan tulee pysyä siinä palvelutasossa, minkä sopimuksessa takaa. Näitä sopimuksia voidaan tehdä automaattisesti, joten sopimusten valvonnan tulisi olla yhtä automaattista.
Sopimusrikkomuksia varten sopimuksiin voidaan liittää sanktiot. Tällöin on läh- tökohdaksi otettava se, että valvonnan tulee toimia niin, että yhden osapuolen vilpillisyys ei aiheuta kustannuksia muille. Lähtökohtaisesti kukaan ei halua maksaa korvauksia kenellekään, joten sopimusrikkomuksen todistaminen on vaativaa.
Sopimusten valvonnan tärkeimmät kohteet ovat viive, luotettavuus ja tulokset. Jotta näitä kohteita voidaan valvoa, tarvitaan esitetyssä yksinkertaisessakin ta- pauksessa, jossa on asiakas, operaattori ja palvelu, vähintään kaksi sopimusta. Tämä siksi, että sopimusten tulisi olla sopimusosapuolten monitoroitavissa, ei- vätkä ne saa aiheuttaa viattomille osapuolille kustannuksia. Tässä yksinkertai- sessakaan mallissa ei ole mahdollista, että olisi vain yksi sopimus, jolla voitai- siin monitoroinnin kannalta luotettavasti kattaa koko tuotantoketju. Sen sijaan on vain yksi yhdistelmä sopimuksia, jolla se onnistuu.
Palveluperustainen toteutus perustuu yleensä käytännössä Web palveluiden käyttöön. Nämä palveluita tulee jatkuvasti lisää ja ne voivat kadota käytöstä il- man varoitusta. Tällainen avoimen maailman ohjelmistoympäristö (open-world software) vaikeuttaa monitoroinnin toteutusta. Monitoroinnin tulisikin olla johdet- tavissa suoraan sopimuksista ja jatkuvaa. Käytännössä se voitaneen toteuttaa liittämällä monitorointi osaksi www-palvelimien käsittelijöitä (handler).
6 Lähteet
BaC08a Xxxxxxxxxx, X. ja Xxxxxxx, X., Towards a methodology for lifelong validation of service compositions. Proceedings of the 2nd interna- tional workshop on Systems development in SOA environments, ACM Press, New York, NY, USA, 2008, sivut 7 – 12.
BaC08b Barbagallo, D. ja Xxxxxxx, X., Towards understanding the role of adverse selection and moral hazard in automated negotiation of service level agreements. Proceedings of the 3rd international workshop on Services integration in pervasive environments, ACM Press, New York, NY, USA, 2008, sivut 7-12.
BGG04 Xxxxxx, X., Xxxxxx, X. ja Guinea, S., Smart monitors for composed services. Proceedings of the 2nd international conference on Ser-
vice oriented computing, ACM Press, New York, NY, USA, 2004, sivut 193 - 202.
BiG07 Bianculli, D. ja Xxxxxx, X., Monitoring conversational web services. 2nd international workshop on Service oriented software engineer- ing: in conjunction with the 6th ESEC/FSE joint meeting, ACM Press, New York, NY, USA, 2007, sivut 15 – 21.
CES07 Xxxxxxxx, X., Xxxxxxxx, X., Xxxxx, X. ja Skene, A., The monitora- bility of service-level agreements for application-service provision. In WOSP '07: Proceedings of the 6th international workshop on Software and performance, ACM Press, New York, NY, USA, 2007, sivut 3-14.
ELS03 Xxxxxxxx, X., Xxxxxxx, D. ja Skene, J., SLAng: a language for defining service level agreements. Proceedings of the Ninth IEEE Workshop on Future Trends of Distributed Computing Systems, London, UK, 2003, sivut 100-106.
ERS08 Xxxxxxxx, X., Xxxxxxxx, X. ja Xxxxx, X., Efficient online monitor- ing of web-service SLAs. Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering, ACM Press, New York, NY, USA, 2008, sivut 170-180.