Palvelujen dynaaminen valvonta
|
|
- Pauliina Parviainen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Palvelujen dynaaminen valvonta Esa Hämäläinen Helsinki Palveluperusteisten ohjelmistojen suunnittelu ja kehittäminen -seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
2 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.
3 Sisältö ii 1 Johdanto 1 2 Monitorit Toiminnalliset ja ei-toiminnalliset vaatimukset Metriikat Politiikat Näkökulmat Abstraktiotasot Kypsyystasot Valvontapisteet ja hajautus SLA ja SLM WSLA Terminologia WSLA:n ajonaikainen arkkitehtuuri Monitoroinnin ulkoistaminen Koreograat 13 5 Yhteenveto 14 Lähteet 15
4 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.
5 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.
6 Kuva 1: Monitorien yleinen rakenne 3
7 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 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ä.
8 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) 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
9 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.
10 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
11 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
12 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.
13 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 WSLA:n ajonaikainen arkkitehtuuri WSLA-arkkitehtuurin ajonaikaiset peruskomponentit ja palvelutason hallinnan viisi vaihetta näkyvät kuvassa5. Kuvan infrastruktuuri oletetaan toteutetuiksi Web Ser-
14 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).
15 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 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-
16 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
17 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?
18 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 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 Haa05 Haataja, J., Yritysten yhteistoimintaverkostojen valvonta Webpalveluympäristössä. Pro gradu, Department of Computer Science, University of Helsinki, maaliskuu URL 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 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 _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, web-pil. [ ]
19 16 web04b Web services architecture, [ ] web04c Web services choreography description language (ws-cdl v1.0), [ ] web04d Web services glossary, [ ] web06 Web services policy framework, ws-policy/. [ ]
Palvelujen dynaaminen valvonta
Palvelujen dynaaminen valvonta Esa Hämäläinen Palveluperustaisten ohjelmistojen suunnittelu ja kehittäminen seminaari Tuusula 18.9.2006 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Tiivistelmä Yritysten
LisätiedotYhteistoiminnan valvonta virtuaalisissa organisaatioissa
Yhteistoiminnan valvonta virtuaalisissa organisaatioissa Juha Hautakangas Helsinki 16.11.2007 Seminaarityö HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET
LisätiedotPalvelutasosopimukset ja WSLA
hyväksymispäivä arvosana arvostelija Palvelutasosopimukset ja WSLA Mikko Kautto Helsinki 31.3.2009 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY
LisätiedotHieman lisää malleista ja niiden hyödyntämisestä
Hieman lisää malleista ja niiden hyödyntämisestä Ohjelmistojen mallintaminen Kesä 2012 (Avoin yliopisto) Toni Ruokolainen, 23.8.2012 Mallit Mallit ovat todellisuuden abstraktioita, jotka on muodostettu
LisätiedotOpetushallitus. ServiceMix POC
Opetushallitus ServiceMix POC SOA Governance Gartner: SOA governance = varmistetaan ja validoidaan, että palvelut toimivat odotetulla tavalla sekä palvelut saavuttavat halutun laatutason. SOA Governancen
LisätiedotThe OWL-S are not what they seem
The OWL-S are not what they seem...vai ovatko? Verkkopalveluiden koostamisen ontologia OWL-S Seminaariesitelmä 15.4.2013 Emilia Hjelm Internet on hankala Nykyinternet on dokumenttien verkko Asiat, joita
Lisätiedotarvostelija OSDA ja UDDI palveluhakemistoina.
Hyväksymispäivä Arvosana arvostelija OSDA ja UDDI palveluhakemistoina. HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Laitos Institution
LisätiedotJärjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri
Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
LisätiedotSOA SIG SOA Tuotetoimittajan näkökulma
SOA SIG SOA Tuotetoimittajan näkökulma 12.11.2007 Kimmo Kaskikallio IT Architect Sisältö IBM SOA Palveluiden elinkaarimalli IBM Tuotteet elinkaarimallin tukena Palvelukeskeinen arkkitehtuuri (SOA) Eri
Lisätiedotin condition monitoring
Etäteknologioiden automaatiosovellukset Using e-speak e in condition monitoring tutkija professori Hannu Koivisto Sisältö Tausta Globaali kunnonvalvontajärjestelmä E-speak globaalissa kunnonvalvontajärjestelmässä
LisätiedotTiedonsiirto- ja rajapintastandardit
Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite
LisätiedotEdellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti
1 Edellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti abstrakteimmalta tasolla tarkentaen yhä yksityiskohtaisemmalle
LisätiedotOhjelmistojen mallintaminen
Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta
LisätiedotJärjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,
Järjestelmäarkkitehtuuri (TK081702) SOA SOA-arkkitehtuuri perustuu xml:ään ja Web Services teknologioihin Mahdollistaa joustavan mukautumisen tuleviin muutoksiin Kustannustehokas Toteutukset perustuvat
LisätiedotArvostelija. PALVELUSOPIMUSTEN MONITOROINTI Jouni Lång. Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Hyväksymispäivä Arvosana Arvostelija PALVELUSOPIMUSTEN MONITOROINTI Jouni Lång Helsinki 22.4.2009 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Tiedekunta/osasto Fakultet/Sektion Faculty/Section
LisätiedotHarri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy
Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Oracle10 g Web Services Sisältö Service Oriented Architecture (SOA) Web Services Service Oriented Architecture Service Oriented
LisätiedotJohdantoluento. Ohjelmien ylläpito
Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito
LisätiedotA Service-Oriented Architecture (SOA) View of IHE Profiles
A Service-Oriented Architecture (SOA) View of IHE Profiles HL7 IHE meeting 20.8.2009 Timo Itälä SoberIT, TKK Juha Mykkänen, KuY 2 SoberIT IHE ja SOA (palveluarkkitehtuuri) SOA (service-oriented architecture)
LisätiedotFiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen
FiSMA 1.1 Monikerrosarkkitehtuuri 1 (6) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen
LisätiedotITK130 Ohjelmistojen luonne
ITK130 Ohjelmistojen luonne Luennon sisältö Ohjelmistotekniikka ja vaatimukset Ohjelmistotuote Ei-toiminnallisten vaatimusten luokittelu Sisäiset ja ulkoiset vaatimukset Oikeellisuus Luotettavuus Kestävyys
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
LisätiedotWeb-palveluiden alusta Axis2
Web-palveluiden alusta Axis2 Aki Heikkinen Ohjaaja: Raimo Rask Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos Suullisen esittämisen seminaarin kirjallinen tukimateriaali 15. helmikuuta 2010 Tiivistelmä
LisätiedotAditron ulkoistuspalvelut. 6.11.2008 Sanomatalo Helsinki Petri Tolonen
Aditron ulkoistuspalvelut 6.11.2008 Sanomatalo Helsinki Petri Tolonen Aditro palvelee asiakkaitaan neljällä alueella Asiakasrajapinta Liiketoimintaprosessit Informaatiologistiikka Asiakassuhteen hallinta
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotArkkitehtuurinen reflektio
Arkkitehtuurinen reflektio Toni Ruokolainen Toni.Ruokolainen@cs.helsinki.fi Helsinki 6.10.2003 Tiivistelmä HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET
LisätiedotFiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen
FiSMA 1.1 Monikerrosarkkitehtuuri 1 (7) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen
LisätiedotTietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
LisätiedotEuroopan unionin neuvosto Bryssel, 25. heinäkuuta 2014 (OR. en)
Euroopan unionin neuvosto Bryssel, 25. heinäkuuta 2014 (OR. en) 12141/14 ADD 1 ENV 689 STATIS 80 RECH 333 SAATE Lähettäjä: Euroopan komissio Saapunut: 17. heinäkuuta 2014 Vastaanottaja: Kom:n asiak. nro:
LisätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti
LisätiedotITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan
ITSM Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan Olli Saranen Senior Consultant Avoset Oy 31.8.2016 Esittely Mukana suomalaisten pankkijärjestelmien kehittämisessä ja ylläpitotyössä
LisätiedotMonitoimittajaympäristö ja SIAM, haasteet eri toimijoiden näkökulmasta
Monitoimittajaympäristö ja SIAM, haasteet eri toimijoiden näkökulmasta itsmf Finalnd 21.09.2017 Jaana Nurmi Delivery Executive, SIAM & ITSM Tieto jaana.nurmi@tieto.com Jaanan historia Ovi Store Nokia Maps
LisätiedotMittaamisen maailmasta muutamia asioita. Heli Valkeinen, erikoistutkija, TtT TOIMIA-verkoston koordinaattori
Mittaamisen maailmasta muutamia asioita Heli Valkeinen, erikoistutkija, TtT TOIMIA-verkoston koordinaattori SISÄLTÖ 1. Mittari vs. indikaattori vs. menetelmä - mittaaminen 2. Luotettavat mittarit 3. Arvioinnin
LisätiedotLuento 12: XML ja metatieto
Luento 12: XML ja metatieto AS-0.110 XML-kuvauskielten perusteet Janne Kalliola XML ja metatieto Metatieto rakenne sanasto Resource Description Framework graafikuvaus XML Semanttinen Web agentit 2 1 Metatieto
LisätiedotEnterprise SOA. Nyt. Systeemi-integraattorin näkökulma
Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia
LisätiedotJohdatus rakenteisiin dokumentteihin
-RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista
LisätiedotInspire-prosessin tilannekatsaus 01 / 2012
Inspire-prosessin tilannekatsaus 01 / 2012 23.1.2012 Täytäntöönpano-ohjeet Ohje haku- ja katselupalvelujen palvelutasosäännösten tulkinnasta Latauspalvelujen ohjeiden laatiminen pitkällä Tiedostolatauspalvelu
LisätiedotTietotekniikkapalveluiden saatavuudenhallinnan kehittäminen
Tietotekniikkapalveluiden saatavuudenhallinnan kehittäminen Diplomityöseminaari 4.3.2009 Tekijä: Jussi Repo Valvoja: Prof. Raimo Kantola Ohjaaja: DI Jari Alasuvanto, Noval Networks Esityksen sisältö Työn
LisätiedotKomission asetus latauspalveluista Jani Kylmäaho Inspire-sihteeristö
Komission asetus latauspalveluista 31.1.2012 Jani Kylmäaho Inspire-sihteeristö 1 Sisällys Verkkopalveluasetus ja yhteentoimivuusasetus Mitä aineistoja velvoite koskee? Kansallinen vs. yhteentoimiva muoto
LisätiedotKonsensusongelma hajautetuissa järjestelmissä. Niko Välimäki Hajautetut algoritmit -seminaari
Konsensusongelma hajautetuissa järjestelmissä Niko Välimäki 30.11.2007 Hajautetut algoritmit -seminaari Konsensusongelma Päätöksen muodostaminen hajautetussa järjestelmässä Prosessien välinen viestintä
Lisätiedot811312A Tietorakenteet ja algoritmit 2015-2016. I Johdanto
811312A Tietorakenteet ja algoritmit 2015-2016 I Johdanto Sisältö 1. Algoritmeista ja tietorakenteista 2. Algoritmien analyysistä 811312A TRA, Johdanto 2 I.1. Algoritmeista ja tietorakenteista I.1.1. Algoritmien
LisätiedotJärjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet
Järjestelmäarkkitehtuuri (TK081702) Ympäristö Muutostarpeet ja niihin vastaaminen Yritysarkkitehtuuri Liiketoiminta-arkkitehtuuri Tavoitteet, Palvelut, Prosessit Informaatioarkkitehtuuri Tietotarpeet,
LisätiedotHSMT J2EE & EJB & SOAP &...
HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista
LisätiedotHarjoitustehtävät ja ratkaisut viikolle 48
Harjoitustehtävät ja ratkaisut viikolle 48 1. Tehtävä on jatkoa aiemmalle tehtävälle viikolta 42, missä piti suunnitella älykodin arkkitehtuuri käyttäen vain ennalta annettua joukkoa ratkaisuja. Tämäkin
LisätiedotAjankohtaisia SOA tutkimusteemoja
Ajankohtaisia SOA tutkimusteemoja Paavo Kotinurmi Ohjelmistoliiketoiminnan ja -tuotannon laboratorio Sisältö Miten integraatiostandardit pohjana SOA-palveluille? Mitä on semanttinen SOA ja mitä SOAn haasteita
LisätiedotKäyttötapausanalyysi ja testaus tsoft
Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten
LisätiedotInteraktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.
Malli-näkym kymä-ohjain arkkitehtuurit (Model-View View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Lähtökohdat: Sovelluksen
LisätiedotLiiketoimintajärjestelmien integrointi
Liiketoimintajärjestelmien integrointi Vierailuluento 12.12.2016 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application
LisätiedotPalvelusuuntautunut ohjelmistotuotanto Luento 1: Kurssin järjestelyt, palveluperustaisten järjestelmien periaatteet Toni Ruokolainen, 8.9.
CINCO Collaborative and interoperable computing Palvelusuuntautunut ohjelmistotuotanto Luento 1: Kurssin järjestelyt, palveluperustaisten järjestelmien periaatteet Toni Ruokolainen, 8.9.2009 Luennon runko
Lisätiedotsertifikaattiratkaisu Apitamopki
Ilmoitin.fi - tunnistamisen sertifikaattiratkaisu Apitamopki Web Services -rajapinnan muutokset Verohallinnon ja ohjelmistotalojen yhteistyöpäivä 23.5.2019 Esityksen sisällöstä Muutama sana varmenteista
LisätiedotLiiketoimintatarpeista toimivaksi järjestelmäksi Jari Kekkonen Chief Consulting Officer. 22.1.2008 Ixonos Oyj
Liiketoimintatarpeista toimivaksi järjestelmäksi Jari Kekkonen Chief Consulting Officer 22.1.2008 Ixonos Oyj Liiketoimintatarpeet mitä, missä ja miten? Markkinaosuuden kasvattaminen tavoitteet Myyjät tekevät
LisätiedotIBM Iptorin pilven reunalla
IBM Iptorin pilven reunalla Teppo Seesto Arkkitehti Pilvilinnat seesto@fi.ibm.com Cloud Computing Pilvipalvelut IT:n teollistaminen Itsepalvelu Maksu käytön mukaan Nopea toimitus IT-palvelujen webbikauppa
LisätiedotVastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen
Vastausten ja tulosten luotettavuus Vastaukset 241 vastausta noin 10 %:n vastausprosentti tyypillinen Kansainväliset IT:n hallinnan hyvät käytännöt. Luotettavuusnäkökohdat Kokemukset ja soveltamisesimerkit
LisätiedotHP OpenView ratkaisut toiminnan jatkuvuuden turvaajina
HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina - Käytännön esimerkkejä ITIL ja ITSM mukaisista IT palveluhallinnan toteutuksista ja mahdollisuuksista Ville Koskinen Sales Specialist, HP Software
LisätiedotHOJ J2EE & EJB & SOAP &...
HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista
LisätiedotWeb-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k
1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.
LisätiedotISO Standardisarja Eräitä ulottuvuuksia Kari Komonen
ISO 55000 Standardisarja Eräitä ulottuvuuksia 6.11.2014 Kari Komonen Eräitä käsitteitä omaisuus, omaisuuserä kohteet, asiat tai kokonaisuudet, joilla on tai voi olla arvoa organisaatiolle omaisuudenhallinta
LisätiedotJHS 180 Paikkatiedon sisältöpalvelut Liite 4 INSPIRE-palvelujen laadun testaus
JHS 180 Paikkatiedon sisältöpalvelut Liite 4 INSPIRE-palvelujen laadun testaus Versio: 28.2.2013 Julkaistu: 28.2.2013 Voimassaoloaika: toistaiseksi Sisällys 1 Yleiset vaatimukset... 2 2 Latauspalvelun
Lisätiedot7 Viestipohjaisten yritysjärjestelmien suunnittelumallit
7 Viestipohjaisten yritysjärjestelmien suunnittelumallit Hohpe G., Woolf B.: Enterprise Integration Patterns. Addison-Wesley 2004. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Viestinvälitykseen
LisätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
LisätiedotLiiketoimintajärjestelmien integrointi
Liiketoimintajärjestelmien integrointi Vierailuluento 2.3.2015 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application
Lisätiedotohjelman arkkitehtuurista.
1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
LisätiedotJuha Viinikka, Senior Manager, Corporate Security, Kesko
6.6.2019 Juha Viinikka, Senior Manager, Corporate Security, Kesko Esityksen teemat Tarvitaan business case Ajatellaan uudella tavalla ja laajemmin Suunnitelmat osaksi strategiaa ja arkkitehtuurimallia
LisätiedotVisma Software Oy
pidättää itsellään oikeuden mahdollisiin parannuksiin ja/tai muutoksiin tässä oppaassa ja/tai ohjelmassa ilman eri ilmoitusta. Oppaan ja siihen liittyvän muun materiaalin kopiointi on kielletty ilman :n
LisätiedotMicrosoft Dynamics CRM 4.0. Jani Liukkonen
Microsoft Dynamics CRM 4.0 Jani Liukkonen Microsoft Dynamics CRM kokonaisuus Täysi CRM toiminnallisuus ja joustavuus Vuorovaikutukset -Markkinointi Myynti -Asiakaspalvelu xrm -Prosessituki SOA -Joustava
LisätiedotRekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä
Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,
LisätiedotStandardi IEC Ohjelmisto
Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,
LisätiedotPAS-RATKAISUN PALVELUKUVAUS
LIITE 3 PAS-RATKAISUN PALVELUKUVAUS versio 2.0 26.6.2019 SISÄLLYS 1 Johdanto... 2 1.1 Dokumentin tarkoitus ja tausta... 2 1.2 PAS-ratkaisun yleiskuvaus... 2 2 Palvelukuvaus... 2 2.1 Palvelun sisältö...
LisätiedotTIEA341 Funktio-ohjelmointi 1, kevät 2008
TIEA34 Funktio-ohjelmointi, kevät 2008 Luento 3 Antti-Juhani Kaijanaho Jyväskylän yliopisto Tietotekniikan laitos 2. tammikuuta 2008 Ydin-Haskell: Syntaksi Lausekkeita (e) ovat: nimettömät funktiot: \x
LisätiedotInteraktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.
Malli-näkym kymä-ohjain arkkitehtuurit (Model-View View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Lähtökohdat: Sovelluksen
LisätiedotTestaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science
Testaustyökalut Luento 11 Antti-Pekka Tuovinen 25 April 2013 1 Tavoitteet Työkalutyyppejä Testauksen hallinta Testien määrittely Staattinen analyysi Dynaaminen testaus 25 April 2013 2 1 Työkalut ja testaus
LisätiedotKäyttöjärjestelmät: prosessit
Käyttöjärjestelmät: prosessit Teemu Saarelainen Tietotekniikka teemu.saarelainen@kyamk.fi Lähteet Stallings, W. Operating Systems Haikala, Järvinen, Käyttöjärjestelmät Eri Web-lähteet Käyttöjärjestelmä
LisätiedotJohtamisen haaste kokonaisarkkitehtuuri menestyksen mahdollistajako?
Johtamisen haaste kokonaisarkkitehtuuri menestyksen mahdollistajako? JÄRJESTÄJÄ SAVO Q AIKA 14.11.2018 Kokonaisarkkitehtuurin määrittelyä Tekijä(t) Armour, F. & Kaisler, S. 2017. Introduction to Enterprise
LisätiedotLuku 6. Dynaaminen ohjelmointi. 6.1 Funktion muisti
Luku 6 Dynaaminen ohjelmointi Dynaamisessa ohjelmoinnissa on ideana jakaa ongelman ratkaisu pienempiin osaongelmiin, jotka voidaan ratkaista toisistaan riippumattomasti. Jokaisen osaongelman ratkaisu tallennetaan
LisätiedotWeb sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin
TEKNILLINEN KORKEAKOULU / VAASAN YLIOPISTO Diplomityöesitelmä Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin Timo Ahola 2006 Web sovellus Web palvelut joiden avulla laite voidaan liittää
LisätiedotToimilohkojen turvallisuus tulevaisuudessa
Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot
LisätiedotTestauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen
Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia
LisätiedotSisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta
Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia
LisätiedotPalvelutasolupaus - vai palvelutason kuvaus?
Yhteistyö-työryhmä Case-työpaja Palvelutasolupaus - vai palvelutason kuvaus? Alustus: Antti Rainio 21.11.2012 21.11.2012 Palvelujen palvelutasolupaus tai -tieto Strategian mukaiset tavoitteet Paikkatieto
LisätiedotUlkoistustoimittajan valvontapalvelu. Ville Mannonen / DataCenter Finland
Ulkoistustoimittajan valvontapalvelu Ville Mannonen / DataCenter Finland Datacenter Finland Oy Vuonna 2003 perustettu konesalipalveluita tuottava yritys Tarjoaa asiakkaileen korkean käytettävyyden konesalipalveluita
LisätiedotCisco Unified Computing System -ratkaisun hyödyt EMC- ja VMwareympäristöissä
Cisco Unified Computing System -ratkaisun hyödyt EMC- ja VMwareympäristöissä EMC Forum 22.10.2009 Lauri Toropainen ltoropai@cisco.com 2009 Cisco Systems, Inc. All rights reserved. 1 ICT-infrastruktuuriin
LisätiedotAutomaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat
Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista hallinnasta Pauli Kartano
Julkisen hallinnon linjaukset tiedon sijainnista hallinnasta 11.9.2018 Pauli Kartano Lausuntokierros Linjaukset ja lausunnot nähtävillä lausuntopalvelussa Julkisen hallinnon linjaukset tiedon sijainnista
Lisätiedotitsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance
itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance Markus Leinonen M.Sc. (Econ.), CIA, CISA Senior Manager, Internal Controls Cargotec Oyj 1984 1986 1992 1995 1997 1997 2002 2002 2008
LisätiedotKuvitettu YVA- opas 2018
Kuvitettu YVA- opas 2018 Oppaan sisältö I Perusasiat YVA-menettelystä s. 4 II Vähän täsmennystä tekijöistä ja osallistumisesta s. 8 III YVA-menettelyn sisällöt s. 13 IV Arvioinnin tulokset ja kuinka niihin
LisätiedotPertti Pennanen License 1 (7) EDUPOLI ICTPro1 23.10.2013
License Pertti Pennanen License 1 (7) SISÄLLYSLUETTELO Lisenssien hallinta... 2 Lisenssisopimus... 2 Yleisimmät lisensiointimallit... 2 OEM lisenssi... 3 Kelluva lisenssi... 3 Työasemakohtainen lisenssi...
LisätiedotPalvelukatalogi liiketoiminnan tukena
Palvelukatalogi liiketoiminnan tukena itsmf risteily 10.2.2011, Eija Hallikainen DataCenter Finland Oy:n palvelutarjooma Korkean käytettävyyden energiatehokkaat konesalipalvelut Laadukkaat etä- ja lähitukipalvelut,
LisätiedotReflektiomekanismien rooli palveluorientoituneissa järjestelmissä. Seminaarityö Tom Bertell
Reflektiomekanismien rooli palveluorientoituneissa järjestelmissä Seminaarityö 30.10.2007 Tom Bertell Sisältö 1 Johdanto... 1 2 Dynaamisuus palveluorientoituneiden järjestelmissä...2 2.1 Yleistä... 2 2.2
LisätiedotMalliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki
Malliperustainen ohjelmistokehitys - MDE 25.9.2007 Pasi Lehtimäki MDE Miksi MDE? Mitä on MDE? MDA, mallit, mallimuunnokset Ohjelmistoja Eclipse, MetaCase Mitä jatkossa? Akronyymiviidakko MDE, MDA, MDD,
LisätiedotOHJ-4301 Sulautettu Ohjelmointi
OHJ-4301 Sulautettu Ohjelmointi (http://www.cs.tut.fi/~sulo/) 5op, to 12-14, TB 109 Arto Salminen, arto.salminen@tut.fi Läpäisyvaatimukset Hyväksytysti suoritetut: Tentti Harjoitustyöt Harjoitustyöt 3
LisätiedotSYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor 2014
SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor Mannerheimintie 2 00100, Helsinki Finland tel: +358 9 4152 0200 www.reaktor.fi info@reaktor.fi 2014
LisätiedotKokonais-IS-arkkitehtuuri korkeakouluissa Tietohallinnon näkökulma
Kokonais-IS-arkkitehtuuri korkeakouluissa Tietohallinnon näkökulma FT, tietohallintopäällikkö Seinäjoen ammattikorkeakoulu Jaakko.Riihimaa@seamk.fi GSM 040-8304104 Kokonaisarkkitehtuurimalli: yleishavaintoja
LisätiedotTiera Sähköinen arkistointi. Palvelun käytettävyys ja sanktiot. Sopimus Tiera Sähköinen arkistointi-palvelusta
Sopimus -palvelusta Salon kaupunki Saapunut 9.12.2014 34/02.08.00.01.08/2014 24.6.2014 Liite 1.1, Palvelun käytettävyys ja sanktiot Palvelun käytettävyys ja sanktiot Kuntien Tiera Oy Tammasaarenkatu 3
LisätiedotTyökalujen merkitys mittaamisessa
Työkalujen merkitys mittaamisessa Mittaaminen ja Ohjelmistotuotanto -seminaari Toni Sandelin 18.4.2001, VTT Elektroniikka, Oulu 1 Sisältö Mihin työkalutukea tarvitaan? Työkalut & metriikat: luokitus Mittausohjelmien
LisätiedotOppimistavoitteet kurssilla Rinnakkaisohjelmointi
17.5.2006 1/5 Oppimistavoitteet kurssilla Rinnakkaisohjelmointi Rinnakkaisuus ja rinnakkaisuuden soveltaminen tietojenkäsittelyjärjestelmissä Kurssin Tietokoneen toiminta perusteella ymmärtää, miten ohjelman
LisätiedotJHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa
JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi
LisätiedotKokonaisvaltainen mittaaminen ohjelmistokehityksen tukena
Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida
Lisätiedot