PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 STUDIES AND REPORTS OF THE PLUGIT PROJECT 15. Harri Karhunen

Koko: px
Aloita esitys sivulta:

Download "PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 STUDIES AND REPORTS OF THE PLUGIT PROJECT 15. Harri Karhunen"

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 STUDIES AND REPORTS OF THE PLUGIT PROJECT 15 Harri Karhunen D Y N A A M I N E N M A L L I L I I K E T O I M I N T A S O V E L L U S T E N I N T E G R O I M I S E K S I KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijä: Harri Karhunen Tietojenkäsittelytieteen laitos PlugIT-projekti Kuopion yliopisto Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh ISBN (koko teos) ISBN (osa 15) ISBN (PDF) Kopijyvä Oy, Kuopio 2004

3 Harri Karhunen. Dynaaminen malli liiketoimintasovellusten integroimiseksi. Painos. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN (osa 15) ISBN (PDF) T I I V I S T E L M Ä Tässä selvityksessä esitetään keinoja liiketoimintasovellusten yhteistoiminnallisuuden parantamiseksi palvelupohjaisessa ohjelmistoarkkitehtuurissa. Yrityksen tai yhteisön tuotantoprosessi nähdään palveluiden muodostamana joukkona. Palvelu voi koostua useiden palveluiden yhteistyön tuloksesta. Tavoitteena on kehittää ohjelmistoarkkitehtuuria siten, että palveluparadigman avulla voidaan parantaa eri liiketoimintasovellusten integroitumista toistensa kanssa. Tavoitteena on osoittaa yrityksille polku, jota kohti kulkea, jotta yritykset saavuttaisivat liiketoimintatavoitteensa ja menestyisivät kilpailussa toisten yritysten kanssa. Ohjelmistot tarvitsevat keinoja dynaamiseen kommunikointiin toimijaverkossa (many-tomany). Palvelupyynnön esittämisen ja suorittamisen tulee tapahtua turvallisesti, luotettavasti ja siten, että tiedon yhtenäisyys taataan kaikissa olosuhteissa. Lisäksi toiminnassa tulee huomioida organisaation erilaiset vaatimukset: - Hanketta varten tarvitaan erillisiä tiimejä. - Sovellus tai käyttäjä voi olla useassa tiimissä. - Käyttöoikeuksien hallinnan tulee tapahtua joustavasti. - Sovellusten kesken on kyettävä ylläpitämään kontekstia liiketoimintaprosessin toteuttamiseksi. - Palvelun tuottamiseksi tarvitaan tuotantoprosessi. Tuotantoprosessi ja sen erityispiirteet on hallittava. Sovellusintegraatio tulee huomioida jo kehitysaikaisissa liittymissä ja on pyrittävä siihen, että integrointi tapahtuu prosessi-integraation muodossa. Prosessi-integraatio mahdollistaa aikaisen kehittämisen ja myöhäisen sidonnan, jolloin integroituvien järjestelmien kehittäminen on helpompaa, koska hyvin määritellyt integrointipisteet auttavat rajoittamaan sovellusten välisiä riippuvuuksia. Usein jo olemassa oleviin sovelluksiin joudutaan rakentamaan liittymiä toisiin ohjelmistoihin. Liittymien rakentaminen tulee toteuttaa hyödyntäen olemassa olevaa teknologiaa. Verkkopalveluiden ja komponenttipohjaisen sovelluskehityksen yhdistämisen avulla voidaan erilaiset järjestelmät yhdistää ja taata tietoturva, transaktioiden hallinta ja riittävän luotettava toiminta kriittisissä liiketoimintajärjestelmissä. Selvityksessä esitetään dynaaminen malli palvelupyyntöjen käsittelemiseksi. Malli perustuu hierarkiseen Broker-arkkitehtuurimalliin. Mallin avulla kuvataan organisaation toimintaa ja sääntöjen avulla luodaan organisaation eri ohjelmistojen (ja käyttäjien) välille yhteistoiminnallisuutta. Mallin avulla luodaan universaali virtuaalikone, jonka kautta eri komponenttialustoilla toimivat ohjelmistot voidaan yhdistää yhdeksi toimivaksi kokonaisuudeksi. Yleinen kymmenluokittelu UDK: Asiasanat (YSA): komponentit, ohjelmistot, atk-ohjelmat, integraatio, sovellukset, verkkopalvelut

4

5 E S I P U H E Tämä selvitys on tehty PlugIT-hankkeessa sen TEHO-osaprojektissa vuosina PlugIThankkeessa on tuotettu avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. TEHO-osaprojektin tavoitteena on kehittää yhteistyöyritysten toimintaperiaatteita ja yhteisiä pelisääntöjä ja ratkaisuja ohjelmistotuotantoon, laadunvarmistukseen ja testaukseen. Tämä lisää yritysten tuotteiden integroitavuutta ja mahdollistaa kokonaisuuden integraatiotestauksen. Tämän selvityksen lähtökohtana on ollut PlugIT-hankkeessa tehty kehitystyö. Tämä selvitys tutkii liiketoimintaprosessien integraatiota palvelukeskeisen ajattelutavan näkökulmasta. Selvitys esittelee mallin, jonka avulla liiketoimintasovellusten yhteistoiminnallisuutta voidaan lisätä. Malli on rakennettu mahdollisimman yleiseksi, jotta siitä voidaan rakentaa toimialakohtaisia toteutuksia. Lähtökohtana selvityksessä on ollut prosessikeskeisyys. Sen ansiosta malli soveltuu teollisuuden, kaupan ja palvelusektorin sekä myös terveydenhuollon sovellusten yhteistoiminnallisuuden parantamiseen. Hanke tukee terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla. Kohderyhmänä ovat yritysten ja organisaatioiden tietohallinnossa työskentelevät henkilöt. Selvitys pyrkii siihen, että yritysten ja organisaatioiden avainhenkilöt näkisivät informaatiotekniikan tuomat mahdollisuudet keinona lisätä yrityksen toimintakykyä vastata asiakkaiden muuttuviin vaatimuksiin. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Esitän kiitokseni jatko-opintojeni ohjaajalle Anne Eerolalle kriitikistä ja kannustuksesta. Kiitän myös PlugIT-projektiin osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkökulmista. Kuopiossa 26. elokuuta 2004 Harri Karhunen

6

7 SISÄLLYSLUETTELO 1 JOHDANTO Tavoitteet Business to Business Taustaa, tavoitteita ja vaatimuksia Ongelmat ja voimat Ongelmat Monoliittisten arkkitehtuurien ongelmat Voimat Tutkimuksen sisältö Historiaa KONTEKSTI Yleistä Palvelukeskeinen arkkitehtuuri Verkkopalvelut (Web-services) Bottom-up ja top-down Etäproseduurikutsu (RPC Remote prosedure call) - ja viestipohjainen (Message-oriented middleware MOM) -tyyli Web Services (WS) -verkkopalvelumäärittely YRITYSPALVELUARKKITEHTUURI RATKAISUNA Yleistä Yritystason palveluarkkitehtuuri (Enterprise service architecture ESA) Yleistä Standardit ovat elintärkeitä Trendejä, jotka vaativat yritystason arkkitehtuuria Arkkitehtuurin transformaatio Tietojärjestelmien evoluutio Yritystason arkkitehtuurin (ESA) sisäinen rakenne Yritystason palveluarkkitehtuurin perusarvot ja merkitys Komponentit ja palvelut, yrityssovellusten kerrokset Yritystason arkkitehtuuri (ESA) ja liiketoiminnan lisäarvo (Business Value of ESA) Koostesovellukset eli komposiittisovellukset (Composite applications) Joustavuus ja yhdenmukaisuus (Compliance) Esimerkkejä Portaalien avulla käytettävyyttä erilaisiin tarpeisiin Liiketoiminta-ajattelu ja arkkitehtuuri Arkkitehtuurin edut/haitat Yrityspalveluarkkitehtuurin luonne ja tavoitteet Sovellusten luokittelua Toiminta-alusta (Platform) DYNAAMINEN MALLI SOVELLUSINTEGRAATIOON Yleistä Dynaaminen arkkitehtuurimalli integroinnin suorittamiseksi Hypoteesit... 40

8 4.4 Prosessin mallintaminen Prosessin mallintaminen Prosessin palveluketju Järjestelmän määrittely ja palveluarkkitehtuurin tarve ARKKITEHTUURIKUVAUS Yleistä Uudet roolit palveluintegraattori Arkkitehtuurimalli Komponentit ja komponenttikaavio Komponentit ja komponenttien tehtävät Yleistä Asiakassovellus ja adapteri (Client Application and Adapter) Palvelun edustajakomponentti asiakkaalla Palvelukomponentti (Service component) Palveluagentti (Service Agent) Palvelukomponentti koordinaation- ja transaktionhallinta Yleistä Koordinaationhallinta hajautetussa ympäristössä Komponentin tilat Transaktioiden hallinta Rajapinnat ja niiden operaatiot Yleistä IAdapter IService IMessage ITransaction IRules Palvelypyyntö yhteistyökaavion avulla kuvattuna Nimipalvelu DYNAAMINEN ARKKITEHTUURI TERVEYDENHUOLLOSSA Yleistä Terveydenhuollon yleinen palvelurakenne Skenaarioita Skenaario1: asiakkaan terveyskeskuskäynti Skenaario 2: asiakas kutsutaan lähetteen pohjalta sairaalaan YHTEENVETO JA TULEVAISUUDEN HAASTEET Implementaation ongelmia Tietojärjestelmät ja ohjelmistotoimittajat Tulevaisuus LÄHTEET LIITE1. SANASTO JA KÄSITTEET... 1 LIITE2. DOKUMENTTIPOHJAISET LIIKETOIMINTAPROTOKOLLAT (EBXML, ROSETTANET, XCBL)... 1

9 1 J O H D A N T O 1.1 Tavoitteet Business to Business Liiketoiminta vaatii yrityksiltä yhteistoimintaa ja verkostoitumista. Yritykset luovat yhteenliittymiä valmistaakseen palvelukokonaisuuksia asiakkaiden tarpeisiin. Yhdessä yritykset ja yritysten osaaminen ovat enemmän. Asiakas esittää palvelupyynnön ja palveluntarjoajat muodostavat renkaan ja toteuttavat palvelupyynnön. Teknologian kehittyminen tarjoaa keinot yhteistoiminnan tehostamiseksi ja automatisoimiseksi. Ohjelmistotekniikassa palvelukeskeinen arkkitehtuuri pyrkii toteuttamaan yritysten tarpeet. Palvelutuotanto on toteutettava tehokkaasti, dynaamisesti, luotettavasti ja turvallisesti. Verkkopalvelutekniikoiden ja komponenttitekniikoiden avulla voidaan luoda skaalautuva ympäristö yhteistoimintaa varten (Sessions, 2000). Tuotantoprosessien toteuttaminen vaatii ohjelmistojen integrointia yhteistoiminnallisuuden aikaansaamiseksi. Integroinnin tulee tapahtua Prosessikeskeisesti (process-oriented). Yhteistoiminnallisuuden rakentaminen on tehokkaampaa tuotantoprosessin pohjalta, koska yhteistoiminnallisuus voidaan huomioida koko tietojärjestelmän kehityskaaren ajan (lifecycle). Prosessikeskeisyys mahdollistaa myös sovelluksen joustavamman muuttamisen. Integroinnin ongelmana korostuu sekä yrityskulttuurien erilaisuus että yritysten tietotekniikkaratkaisujen heterogeenisuus. Verkottuminen muodostuu hankalaksi teknisten esteiden johdosta. Tehokkainta olisi, jos informaatiojärjestelmät voisivat kommunikoida standardilla tavalla ja niiden semantiikka (tiedon syntaksi ja merkitys) olisivat samat kaikilla yrityksillä. Valitettavasti näin ei ole ja siksi yritysten ja sovellusten välille joudutaan suorittamaan yhteensovittamista eli integrointia yhteistoiminnallisuuden aikaansaamiseksi. Ihanteena on integraatio, johon organisaatiot voivat liittyä yhteisen rajapinnan kautta. Rajapinnan tulee olla niin yleinen ja yksinkertainen, että hyvinkin erilaisilla sovelluksilla on kyky hyödyntää rajapintaa. Tässä dokumentissa pyritään esittämään yleinen arkkitehtoninen ratkaisu, joka on yleistettävissä yritysten väliseen integraatioon. Esitettävä dynaaminen malli on nähtävä abstraktina viitekehyksenä, johon voidaan peilata järjestelmän nykyistä tilaa ja jota kohti voidaan pyrkiä. Modernit ohjelmistotalojen sovelluspalvelimet sisältävät yleensä kaikki verkkopalvelujen rakentamiseen tarvittavat komponentit kuten web-palvelimen, kehitystyökaluja mm. dokumenttien automaattiseen generointiin, integrointiin muiden järjestelmien kanssa sekä sovelluspalvelimen. Malli on tarkoitettu määrittely-, analyysi- ja suunnitteluvaiheen tarpeisiin. Rakentamisvaiheessa luodusta mallista tehdään tekniikkariippuva toteutus. Dynaaminen malli perustuu hierarkisten Broker-komponenttien käyttöön ja tarjoaa ansaintamahdollisuuden yritysten välisten liiketoimintojen järjestelijälle ja soveltuu erinomaisesti esimerkiksi erilaisten hankintarenkaiden rakentamiseen tai esimerkiksi teollisen tuotannon järjestämisessä. Terveydenhuollossa mallin avulla voidaan rakentaa esimerkiksi asiantuntijapalveluita tai luoda erilaisia hoitoprosesseja, käyttää mallia potilashallinnossa sekä rakentaa käyttöliittymäportaaleja, joiden avulla eri sovellusten toiminnallisuutta voidaan yhdistellä kunkin käyttäjäryhmän vaatimusten mukaisesti. SELVITYS 15 9

10 1.1.2 Taustaa, tavoitteita ja vaatimuksia Tämä dokumentti on tarkoitettu johdatukseksi yritysten ja organisaatioiden tietohallinnossa työskenteleville henkilöille. Tavoitteena on antaa eväitä ohjelmistoarkkitehtuurin suunnitteluun. Dokumentin ymmärtäminen edellyttää jonkin verran ohjelmistotekniikan käsitteiden tuntemusta. Dokumentti on jatkoa PlugIT:n E2-projektissa kehitettyyn sovellusulokkeen avulla tapahtuvaan integraatioon, jossa määriteltiin ja suoritettiin kahdenvälistä integraatiota KYS:n Puijon Sairaalan gastroenterologisen tutkimusyksikön ja kliinisen patologian laboratorion välillä. Integraatiotarve oli seuraava: Gastroenterologinen tutkimusyksikkö pyytää patologin lausunnon näytteestä lähettämällä lähetteen patologille. Integraation avulla lähettävä järjestelmä käyttää vastaanottavan järjestelmän palveluja mm. muodostaen omasta lausunnostaan pyynnön, täydentäen pyyntöä ja lähettäen sen vastaanottavaan järjestelmään. E2-projektissa sovellettiin PlugIT-hankkeessa kehitettyä integrointimenettelyä. Integrointi suoritettiin kahdenvälisesti siten, että toisen sovelluksen sovellusuloke tarjosi toiselle sovellukselle rajapinnan, jota toinen hyödynsi. Siirrettävä tieto sovellusten välillä muodostettiin rakenteisena dokumenttina XML-merkkauskielen avulla, jotta järjestelmän muutoksen takia ei integrointia tarvitse suunnitella kokonaan uudelleen. Kahden välinen integrointi ei kuitenkaan riitä yleiseksi ratkaisuksi liiketoimintaprosessien hallintaan. Tarvitaan yleisempi ratkaisu, joka mahdollistaa liiketoimintaa osallistuvien kumppaneiden yhteistoiminnan joustavammin ja useiden toimijoiden kesken. Tämän dokumentin mallin tavoitteena on suorittaa integrointeja monesta-moneen-tyyppisesti (many-to-many) ja suoraan sovellusten kesken. Aluksi näkökulma oli bottom-up tarkastelu, jonka pohjalta tutkittiin integraatiota ja sen ongelmia. Tarkastelukulma tutki suunnittelumallien avulla E2-arkkitehtuurimallia. Tutkimuksen pohjalta syntyi Broker-arkkitehtuurimalliin pohjautuva arkkitehtuurikuvaus. Mallissa tutkittiin palvelupyyntöjen välitystä tavoitteena tehokas ja skaalautuva komponenttirakenne erilaisten sovellusten kesken. Mallin nimipalveluominaisuuksia suunnittelumallien avulla on tutkittu edelleen. Palvelupyyntö voi muodostaa monimutkaisen tuotantoketjun, jossa transaktiot on hallittava. Palvelupyynnön kulloinenkin käsittelytilanne ja sisältö on hallittava, kun palvelu toteutetaan eri toimijoiden kesken. Sanotaan, että on hallittava konteksti (context management). Tutkittiin myös kontekstinhallinnan ongelmankenttää hajautetussa verkkoympäristössä. Luotu arkkitehtuurikuvaus pyrkii yksinkertaisuuteen ja joustavuuteen. Liiketoimintaprosessit voivat olla monimutkaisia. Pyrittäessä automatisoituihin tuotantoprosesseihin on prosessiin kyettävä tuomaan mukaan joitakin tekoälyyn liittyviä piirteitä kuten yksinkertaista päättelyä (jos x niin y) ja toimintaskriptien toteutusta. Siksi avuksi tarvitaan ohjelmistoagentteja. Agentit ovat palveluohjelmistoja, joiden tarkoituksena on tutkia annettua tehtävää ja tehdä tarvittavia johtopäätöksiä. Agentilta vaaditaan jonkinlaista älykkyyttä, jotta se voisi suorittaa päättelyä (Autonomous Interface Agents, 1997). Selvitysten perusteella kävi ilmi, että bottom-up -lähestymistapa on liian rajoittunut. Jos näkökulma on pelkästään tekninen, on tuloksena integraatio, joka voi olla toiminnaltaan tehokas, mutta joustamaton, koska tarkastelutapa ei huomioi liiketoimintaympäristöä ja sen asettamia vaatimuksia liiketoiminnan kehittyessä. Lähtökohdaksi on otettava top-down -lähestymistapa, mikä mahdollistaa liiketoimintaprosessien huomioimisen integraatiovaatimuksia laadittaessa. Muita vaatimuksia ovat tekniikkariippumattomuus, skaalautuvuus, tehokkuus ja yksinkertaisuus. Top down lähestymistapa tarkoittaa sitä, että lähtökohtana on tuotantoprosessi, jonka kaikki osat (=toiminnot) nähdään palveluina. Palvelut koostuvat toisista palveluista muodostaen toimintaverkon, joka toteuttaa tuotantoprosessin. Tekniikkariippumattomuus merkitsee sitä, että tämän määrittelyn mukainen järjestelmä on toteutettavissa kaikilla olemassa olevilla väliohjelmistoalustoilla. Skaalautuvuutta (scalability) tarvitaan, jotta järjestelmä selviää nopeista palvelupyyntöjen määrän muutoksista. Järjestelmän tulee olla tehokas, joten teknologiaa on sovellettava siten, että välitysjärjestelmän aiheuttama tehokkuushäviö voidaan minimoida. Hajautettu tiedonvälitys lisää väistämättä monimutkaisuutta ja virheen syntymisen mahdollisuus kasvaa verrattuna monoliittiseen keskitettyyn järjestelmään. Järjestelmän on tarjottava virheenkäsittely. Järjestelmän osien tulee olla mahdollisimman 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

11 standardeja ja yksinkertaisia, jotta järjestelmä toimii luotettavasti ja virheenjäljitys on mahdollisimman helppoa. Koska malli pohjautuu jo olemassa olevaan teknologiaan ja koettuihin käytäntöihin, on sen soveltaminen yritystasolla kohtuullinen tehtävä. Koska integroinnin lähtökohtana on prosessikeskeisyys, niin tehdyt integrointiratkaisut kestävät ja skaalautuvat paremmin yrityksen toimintojen kehittyessä ja muuttuessa. Sovellusten esittämä palvelupyyntö muutetaan rakenteiseksi dokumentiksi XML-koodattuna SOAP-sanomaan paketoituna, joka toimitetaan vastaanottajalle. Kuopion yliopistolla on tutkittu XRake-projektissa (XBI/XRAKE-projekti 2002) merkintätapoja ja menetelmiä heterogeenisten järjestelmien integroimiseen XML-rajapintoja käyttäen. Plugit-hankkeessa on tutkittu kontekstinhallintaa sekä eri järjestelmien välistä käyttäjän tunnistamista ja autentikointia. PlugIT:ssa on myös kehitetty suunnittelumenetelmä komponenttipohjaisten sovellusten kehittämiseksi. Tutkimusten tuloksia sovelletaan tässä mallissa soveltuvin osin. Sovellusten tarjoamat palvelut kuvataan verkkopalvelukuvauskielen (Web Service Description Language WSDL) avulla (Web Services Activity, 2004). 1.2 Ongelmat ja voimat Ongelmat Eri organisaatioilla on käytössään sekä organisaation sisällä että organisaatioiden välillä runsaasti erilaisia ohjelmistoja, joiden kyky yhteistoimintaan toisten ohjelmien kanssa on puutteellista. Ongelmana on kuinka tarjotut palvelut löydetään, tunnistetaan ja kuinka palveluiden semantiikka kyetään hallitsemaan. Lisäksi palvelua vailla olevan on kyettävä esittämään ja toimittamaan palvelupyyntö palvelua tarjoavalle sovellukselle ja päinvastoin. Lisäksi organisaatiot kehittyvät ja muuttuvat nopeasti ajan mukana. Palvelupyynnön toteuttaminen toteutetaan usein verkostoituneesti, jolloin tuotantoprosessista voi muodostua monimutkainen ketju, jossa kunkin osan keskinäiset suhteet ja toteutusjärjestys on hallittava. Tarvitaan koordinaatiota. Asiakkaan pyytämä palvelu voi koostua useista palvelupyynnöistä. Koordinaation avulla asiakkaalle voidaan taata hänen haluamansa palvelu. Koska palvelupyyntö koostuu erillisistä palvelupyynnöistä, joiden suoritukset voivat kokonaispalvelua koottaessa riippua toisistaan, tarvitaan transaktioiden hallintaa. Ongelmaksi muodostuu muodostuvan palvelukokonaisuuden transaktioiden hallinta. Koska palvelupyyntöjen toteuttaminen tuotannossa voi muodostaa pitkän tuotantoketjun, jolloin reaaliaikaisuuden vaatimusta ei voida toteuttaa, ei RPC-tyyliä voida käyttää prosessien toteuttamisessa. Lisäksi yhteistoiminnallisuuden toteuttaminen vaatii eri tiedostomuotojen ja tiedonsiirtotekniikoiden hallintaa kuten rakenteiset dokumentit, binääritiedostot, kokonaisina (block) tai tietovirtoina (stream) siirrettävät dokumentit. Eri vaatimusten toteuttaminen standardilla tavalla voi olla mahdotonta, jolloin joudutaan rakentamaan ongelman ratkaisemiseksi epästandardeja ratkaisuja kuten palvelupyynnön liitteenä toimitettavien binääritiedostojen kuten esimerkiksi kuvatiedostojen siirtämiseksi pyynnön mukana osapuolelta toiselle. Tämä voi tapahtua esimerkiksi http-protokollan mukaisesti MIME-koodattuna lohkoina (Alonso, 2004). Eri yritysten järjestelmien integroiminen on kallista, hankalaa ja hidasta. Yhteistoiminnallisuuden aikaansaaminen vaatii tiedolta formaalia esitysmuotoa. Jotta tietoa voitaisiin käyttää virheettömästi, on sen syntaksi kyettävä esittämään siten, ettei tiedon käsitteleminen aiheuta eri järjestelmissä virheitä (poikkeuksia). Tiedolla on myös merkitys. Tieto on kyettävä määrittelemään siten, että se merkitsee kaikille samaa ja vain samaa. Jo tiedosta sopiminen voi olla integraatiossa vaikeaa. Eräs ratkaisu tiedon ongelmaan ovat koodistot koodistopalvelimineen. Aluksi ajateltiin, että verkkopalveluiden avulla muodostetaan yleisiä kauppapaikkoja, jossa yritykset tarjoavat palveluitaan ja josta asiakkaat löytävät palvelut ja kauppaa käydään automaatti- SELVITYS 15 11

12 sesti verkkopalveluiden avulla. Siihen on vielä pitkä matka. Ongelmana on luottamus. Kuinka voidaan varmistua, että palveluntarjoajan identiteetti on se, miksi hän sen ilmoittaa, jottei tapahdu väärinkäytöksiä? Kuinka voidaan varmistaa tuntemattoman palveluntarjoajan tarjoaman palvelun laatu? Entäpä huomenna, onko palveluntarjoajaa olemassa? Yrityskumppaneiden on tunnettava toisensa, luotettava toiseen ja varsinkin, jos toisen palvelua käytetään osana omaa tuotetta, vaikuttaa huonon alihankkijan suorittama palvelu omaan yrityskuvaan. Verkottuminen tapahtuu suljetummin esimerkiksi siten, että yritykset, jotka tuntevat toisensa, muodostavat tuotantorenkaita. Tai yritys voi rakentaa oman tuotemerkin alihankkijoiden palveluiden avulla vastaten palvelun laadusta Monoliittisten arkkitehtuurien ongelmat Palveluarkitehtuurin näkökulmasta monoliittisuus tarkoittaa kerran (one time), yhteen tarkoitukseen (one purpose) ja yhdellä tavalla (one way). Useimmilla yrityksillä ei ole ohjelmistoja, jotka toteuttaisivat yritystason arkkitehtuurin (ESA) periaatteita. Yritykset kärsivät tästä ongelmasta monin tavoin. Usein yrityksellä on useita ohjelmistoja, jotka on kehitetty tai hankittu koordinoimatta niiden välistä yhteistoimintaa järjestelmällisesti. Seurauksena tästä on järjestämätön monimutkaisuus. Tässäkin tapauksessa automaation lisääminen onnistuu, se vain on kallista, hidasta ja lisää monimutkaisuutta entisestään. Monoliittisuuteen liittyvä tiukka sidonta (tight coupled) hidastaa kykyä muutoksiin. Tällöin yrityksen IT-osastosta tulee kehityksen jarru. IT-osasto suhtautuu kaikkeen kehitykseen negatiivisesti pyrkiessään välttämään työmäärän paisumista ( ei onnistu... ). Tämä hankaloittaa yrityksen liiketoimintastrategioiden suunnittelua ja toteutusta. Tarvitaan joustavuutta. Tiukka sidonta aiheuttaa sen, että johonkin ominaisuuteen vaadittu muutos voi vaikuttaa myös muihin tekijöihin. Esimerkiksi, jos CRM-järjestelmä käyttää toisen järjestelmän tietovarastoja. Tiukka sidonta merkitsee esimerkiksi sitä, että sen sijaan, että tietoja tarjoava sovellus tarjoaisi operaation avulla vastauksen tehtyyn kyselyyn (API-rajapinnan kautta), järjestelmän tietoja käytetäänkin sen tietokantaresurssin kautta. Mikäli tietokantaresurssiin tehdään muutoksia, on muutos huomioitava myös toisessa järjestelmässä. Mitä enemmän riippuvuuksia ohjelmistojen välillä on, sitä hankalammaksi ja kalliimmaksi muutoksiin vastaaminen ja ylläpito muodostuvat Voimat Palvelupyynnön esittäjän palvelupyyntö on välitettävä palveluntarjoajalle ja muunnettava palveluntarjoajan ymmärtämään muotoon. Sovellukset voivat toimia erilaisilla alustoilla. Sovellukset voivat olla perinnejärjestelmiä (legacy), joilla on erittäin vajavainen kyky yhteistoimintaan. Sovellusten välinen kommunikointi on kyettävä toteuttamaan joustavasti, tehokkaasti, turvallisesti ja skaalautuvasti. Asiakkaan tulee kyetä esittämään palvelupyyntö usealle sovellukselle (one-to-many) ja asiakkaan tulee kyetä saamaan vastaus monelta sovellukselta (many-to-one). Tarvitaan siis kykyä manyto-many tyyppiseen viestintään. Organisaatiot toimivat tiimeissä, joita on kyettävä muodostamaan dynaamisesti. Tämä tarkoittaa sitä, että muodostettaessa ryhmiä niiden käyttöoikeudet voidaan hallita oletusarvoisesti ryhmän organisatorisen aseman perusteella. Jotta tämä saavutettaisiin, on ohjelmistoilla oltava kyky mallintaa organisaatiota. Liiketoimintaprosessit voivat olla monimutkaisia. Prosessi voi sisältää vaatimuksia suoritusjärjestyksestä. Prosessin aiheuttamat poikkeukset on osattava käsitellä. Prosessin on kyettävä esittämään vaihtoehtoisia skenaariota siitä kuinka menetellä kussakin tilanteessa. Yritysten toiminta on dynaamista. Liiketoiminnan perusteet ovat aina samat. Kilpailukyky muodostuu siitä, kuka tuntee parhaiten asiakkaan tarpeet, tunnistaa oman liiketoimintansa vahvuudet ja heikkoudet ja pystyy tarjoamaan asiakkaalle parasta mahdollista palvelua kilpailukykyisesti. Jotta tämä onnistuu, tarvitaan joustavuutta. 12 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

13 1.2.4 Tutkimuksen sisältö Tutkimuksen toisessa luvussa käydään lävitse verkkopalveluiden perusteita. Kolmannessa luvussa tutustutaan yritystason palveluarkkitehtuureihin. Luvussa korostetaan yrityksen siirtymäpolkua monoliittisistä sovelluksista yhteistyötä tekeviin komponenttipohjaisiin sovelluksiin. Yritystason sovellusten yhteistoiminnallisuus toteutetaan verkkopalveluarkkitehtuurien avulla. Eri tilanteissa tarvitaan erilaisia ratkaisuja. Yrityksen on kussakin tapauksessa mietittävä, mikä on sille parasta. Neljännessä luvussa esitellään dynaamisen integrointimallin teoreettinen perusta. Esitellään mallin perusarkkitehtuuri ja keskeisimmät hypoteesit. Liiketoimintaprosessin mallintamiseksi esitellään arkkitehtuurin määrittelyprosessi, jossa lähtökohtana ovat yrityksen liiketoimintaprosessit ja liiketoimintaentiteetit. Prosessit muodostavat palveluketjuja. Palvelukeskeisen arkkitehtuurin keskeisimpiä tehtäviä on prosessin mallintaminen. Viidennessä luvussa kuvataan dynaaminen arkkitehtuuri ja toimintaympäristö. Luvussa kuvataan komponentit, rajapinnat, koordinaationhallinnan ja transaktioiden perusteet. Luvussa kuusi sovelletaan dynaamista arkkitehtuuria terveydenhuollossa mallintamalla tuotantoprosessia palvelukomponenttien avulla. Kahden skenaarion avulla esitetään kuvitteellinen tilanne sekä perusterveydenhuollosta että erikoissairaanhoidosta. Viimeisessä luvussa luodaan yhteenveto ja arvioidaan tulevaa kehitystä. 1.3 Historiaa Tietojenkäsittelytehtävien historia voidaan jakaa kolmeen tai neljään jaksoon. 80-luvulle asti tietojenkäsittelytehtävät perustuivat eräajotyyppisiin järjestelmiin, jolloin ensin tallennettiin järjestelmään tarvittavat tiedot ja tallennuksen jälkeen suoritettiin tarkistusajo ja varsinainen tuotantoajo. Teknologian kehittymättömyys ja kalleus johti siihen, että tietojenkäsittelyä käytettiin yritysten prosessien hallinnassa pääasiassa hallinnollisissa tehtävissä esimerkiksi henkilöstöhallinnossa ja laskentatoimessa. Hallinnolliset tehtävät tarjosivat olemassa olevalle tietojenkäsittelymallille sopivia tehtäviä sisältäen lajittelu-, laskenta- ja tulostustehtäviä. Malli tarjosi mahdollisuuden palvelupohjaiseen tuotantoon, jossa tietojenkäsittelypalvelut ostettiin palveluoperaattorilta. Tällöin tallennusvaihe tehtiin usein itse, ja operaattori suorittu tarpeelliset tietokoneajot ja toimitti asiakkaalle asiakkaan tarvitsemat tulosteet. Käytetyintä tällainen ohjelmistopalvelu oli esimerkiksi palkanlaskennassa (palkka-ajot, tilipussit, maksatus) ja kirjanpidossa (kirjanpito, reskontrat, laskutus ja ulkoinen laskentatoimi). Teknologia kehittyi. Halvat PC-laitteet, minitietokoneet ja mikroverkot laajensivat tietokoneiden käyttöä ja loivat uusia käyttötapoja. Entistä tehokkaammat mikrotietokoneet tarjosivat käyttöliittymänsä kautta mahdollisuuden tehdä reaaliaikaisia kyselyjä, päivityksiä ja tulostuksia. Aiemmin päivitys- ja kyselytehtävät pystyttiin tekemään ainoastaan suurten yritysten tietojärjestelmissä. Tietojen ja tietojenkäsittelyn hallinta siirtyi palvelukeskuksilta yrityksille. Yritykset omistivat usein laitteensa ja ohjelmistonsa. Teknologia tarjosi aiempaa paremman palvelukyvyn, ja tietojenkäsittelyä voitiin soveltaa uusissa liiketoimintatehtävissä. Lopulta Internet ja sen globaali rakenne mahdollisti yritysten välisen tietojenvaihdon. Tyypillinen tälle ajalle ominainen yritysratkaisu oli usein se, että toimistopalvelut toimivat käyttäjien mikrotietokoneissa (fat client) ja yhteisiä palveluja olivat tiedosto- ja tulostuspalvelut (Sessions, 2000). Taloushallinto hoidettiin pääasiassa minitietokoneiden avulla, koska ohjelmistotoimittajat tarjosivat ohjelmistopalveluita omilla alustoillaan. Taloushallinnon ohjelmistot olivat luonteeltaan monoliittisia ja niiden integrointi mikroverkkoihin oli vaikeaa. 90-luvun lopulla tietojenkäsittely oli osa jokaisen yrityksen arkea, se oli jokaisella työpöydällä. Tiedon ja tiedonkäsittelyn hallinta johti siihen, että tietojenkäsittelytehtävät suoritettiin hajautetusti verkossa. Ongelmaksi muodostui vaatimus ohjelmistojen yhteistoiminnallisuudesta, ylläpidettävyydestä ja järjestelmien hallinnasta. Pyrittiin vähentämään käyttäjän työpöytäkerroksen tehtäviä (workspace tier). Asiakaskerroksen tehtäviä siirrettiin sovellustason kerrokselle (thin- SELVITYS 15 13

14 client). Tavoitteena oli, että työpöytäkerros hallitsee sovellusten esittämisen (käyttöliittymän) ja varsinaiset työtehtävät keskitetään sovelluspalvelimille, jotka käyttävät tiedonhallintaan siihen erikoistuneita tietokantapalvelimia. Siirryttiin komponenttipohjaiseen ajatteluun (component-oriented approach), mikä tarkoittaa sovellusten jakamista osiin siten, että näitä osia voidaan uudelleenkäyttää (Reuse) maksimaalisesti. Pian havaittiin, että ohjelmistojen kyky yhteistoimintaan (interoperability) oli puutteellista. Internetistä oli jo muodostunut globaali kaikkialle ulottuvat tietoverkko. Tämän vuoksi ryhdyttiin kehittämään tekniikoita kuten ebxml liiketoimintojen dokumenttien vaihtoa varten (Top-down dokumenttipohjainen lähestymistapa) ja verkkopalveluarkkitehtuuri (Web Service Architecture WSA) ohjelmistojen operaatioiden hallintaan (bottom-up prosessipohjainen lähestymistapa), joiden avulla tietoverkon kautta voitiin vaihtaa palvelupyyntöjä tai dokumentteja yritysten välillä. Syntyivät verkkopalvelut (Web services). Jo hajautuksen käyttöönotto 90-luvulla loi monimutkaisen ohjelmistoinfrastruktuurin. Verkkopalvelutekniikoiden käyttöönotto lisää edelleen monimutkaisuutta. Tämän vuoksi markkinoille on syntynyt tarvetta ja kysyntää palveluista. Vanha palvelukeskusajattelu uudessa muodossa on muodostumassa houkuttelevaksi ja kilpailukykyiseksi ratkaisuksi. Asiakas ostaa palveluita ja maksaa palveluista käytön mukaan. Ulkoistamalla osan toimintoja palveluiden avulla, yritys voi keskittyä ydintoimintoihinsa. Palvelutarjoaja voi erikoistua palvelutuotantoon ja tarjota asiakkailleen parasta mahdollista palvelua. Palveluntarjoaja voi ostaa osan palveluita toisilta palveluntarjoajilta ja niin edelleen. Palvelukeskeinen lähestymistapa (service-oriented approach) tuottaa yritysten kesken monipuolisia verkostoja, joissa toiminnan tehokkuus saavutetaan erikoistumalla. Ohjelmistot kykenevät automaattiseen yhteistoimintaan verkkopalveluiden avulla. Verkkopalveluiden avulla palvelujen rakenne ja semantiikka kuvataan, palvelut löydetään ja palveluja kutsutaan. Yritykset voivat luoda yhteistoimintaverkostoja ja sovittaa tietojärjestelmänsä yhteen siten, että voidaan luoda palvelukokonaisuuksia. Yhteistoiminta ratkaistaan palvelukeskeisen arkkitehtuurin avulla (SOA Service-oriented Architecture). Palveluoperaattori saa tulonsa myymästään palvelusta. Asiakas liittää omat tietojärjestelmänsä palveluun ja palveluoperaattori kokoaa oman palvelunsa muista palveluista. Markkinoilla on tarvetta palveluintegraattorista (service integrator), joka liittää eri palvelut toisiinsa ja luo rajapinnan asiakkaan ja palvelun välille. Palvelukeskeinen toimintamalli muuttaa ohjelmistoliiketoiminnan ansaintalogiikkaa. Ohjelmistoyrityksen on kyettävä hyödyntämään palveluliiketoiminnan antamat mahdollisuudet ja parantamaan tuotteidensa ominaisuuksia siten, että niillä on tarvittava yhteistoiminnallisuus verkkopalveluympäristössä. 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

15 2 K O N T E K S T I 2.1 Yleistä Tässä luvussa esitellään perusteet ja määrittelyä palvelupohjaisen arkkitehtuurin ymmärtämiseksi. Palvelut nähdään yritysten liiketoimintaprosessien toteuttajina. Liiketoimintasovellusten konteksti palvelukeskeisessä arkkitehtuurissa pohjautuu yhteisiin sopimuksiin, määrittelyihin ja standardeihin. Ohjelmistot toimivat hajallaan verkossa. Ohjelmat ovat yhteistoiminnassa toistensa kanssa pyytäen ja tarjoten palveluita. Palvelupyyntöjä esitetään myös eri organisaatioiden välillä. Organisaatiot toimivat joustavasti ja muodostavat erilaisia tiimejä hankkeiden toteuttamiseksi (Taulukko 1). Taulukko 1: Tavoitteita ohjelmistojen välisessä integraatiossa Yrityssovellusten integraatiotavoitteita (Goals for modelling enterprise integration) Sovellusten välinen yhteistoiminnallisuus (interoperability between applications) Dynaaminen käyttäytyminen (dynamic behaviour) Tekninen riippumattomuus ja läpinäkyvyys (technical independency, transparency) Aikainen suunnittelu, myöhäinen sidonta = uudelleenkäytettävyys (aarly design + late binding = software reuse Turvallisuus, luotettavuus, jäljitettävyys (security, reliability, traceability) Asiakas esittää palveluoperaattorille palvelupyynnön. Asiakas ei tiedä kuinka palvelu rakennetaan, asiakkaalle riittää tieto eli kuvaus siitä, millaisen palvelun hän saa sitä pyydettyään. Palveluoperaattori koostaa asiakkaalle sopivan palvelun. Palvelu voi koostua muiden palveluntarjoajien palveluista. Palvelut kommunikoivat keskenään käyttäen välittäjää (Broker), joka integroi palvelut toisiinsa. Palveluintegraatio voidaan tarjota ulkopuolisena palveluna tai yritykset voivat verkostoitua ja rakentaa tarvitsemansa integraatiopalvelun (Kuva 1). Client Service1 Service Service2 ServiceN Kuva 1: Asiakas esittää palvelupyynnön Jotta palvelupyyntöjen käsittelyssä saavutetaan riittävä skaalautuvuus (scalability), tulisi kommunikaation olla asynkronista (asynchronous). Komponenttien tulisi olla tilattomia (stateless). Komponentit saavat tarvittavat tilatiedot taustalla olevalta tietokannalta (back-end data-base). Ti- SELVITYS 15 15

16 lattomuus mahdollistaa tehokkaan instanssien hallinnan (instance management), koska ei tarvitse pitää kirjaa siitä, monellako asiakkaalla on viite instanssiin. Jokaiselle asiakkaalle tarjotaan oma istunnon aikainen instanssi. Instanssien hallinta voidaan hoitaa joko alustamalla instanssi tarvittaessa (JIT just-in-time) tai käyttäen instanssipoolia (instance pooling algorithm). Toinen mahdollisuus on käyttää tilallista instanssia, jonka useat asiakkaat jakavat (shared instances) (Sessions, 2000). Tilattomuuden tavoitteesta voidaan poiketa, jos (Sessions, 2000): - Komponentin instanssilla voi olla tila, jos tila ei kohdistu tiettyyn asiakaskomponenttiin. - Olioiden ilmentymillä (object instance) voi olla tila, mutta ei komponentin ilmentymällä (component instance). - Tarvittaessa komponenttiin voidaan laittaa tila. Tällöin komponenttia ei voi hallita instanssienhallinta-algoritmien avulla. Tässä tapauksessa instanssi varataan yhden proxyn käyttöön. Tätä kutsutaan keskustelevaksi moodiksi (conversational mode). Komponentin alustana toimivalta sovelluspalvelimelta ja siinä toimivalta komponentilta vaaditaan ominaisuuksia (Sessions, 2000): - Tilatiedot eivät ole instanssissa, koska instanssienhallinta voidaan suorittaa tehokkaasti instanssienhallinta-algoritmien avulla. Samoin säikeidenhallinta voidaan hoitaa automaattisesti instanssienhallinta-algoritmien avulla. - Voidaan hyödyntää kuormituksentasausalgoritmeja (load balancing algoritms). - Käytetään resurssipooleja (resource pooling). - Sidotaan metodit transaktioihin (transactional boundary). Transaktioiden hallinta kuuluu väliohjelmistolle (middletier)-ohjelmistolle. - Turvallisuus (safety) on mukana komponenttiprosessissa. Tietoturva (security) kuuluu väliohjelmistolle. 2.2 Palvelukeskeinen arkkitehtuuri Palvelukeskeinen arkkitehtuuri (SOA Service-oriented architecture) määrittelee arkkitehtuuriset periaatteet itsenäisten systeemien yhteistoiminnan toteuttamiseksi. Systeemien autonomisuus (Autonomy) tarkoittaa niiden erillisyyttä, kykyä toimi itsenäisesti ja kykyä itse määritellä tarjoamansa toiminnallisuuden. Yhteistoiminnallisuus (interoperate) tarkoittaa kykyä toimia yhteistoiminnassa (ObjectWatch Newsletter Number 45). Palvelukeskeisen arkkitehtuuri pohjautuu seuraaviin periaatteisiin (ObjectWatch Newsletter Number 45 ): - Asynkroninen kommunikaatio sovellusten ja järjestelmien välillä. - Kyky käyttää heterogeenisia kommunikaatiokanavia eli erilaisten järjestelmien on kyettävä yhteistoimintaan. - Tietoturvallisuustekijöiden huomioonottaminen eli tunnistaminen (identifiointi) ja varmentaminen (verifiointi ja sertifiointi) sekä kyky kommunikaation salaukseen. Osapuolet todistavat (Proof) identiteettinsä toiselle osapuolelle. - Virheidenhallinta palveluketjussa (error management across the systems matrix). - Koska kommunikointi on asynkronista, tarvitaan työnkulun koordinaatiota (workflow coordination), jotta voidaan seurata palvelupyynnön käsittelytilannetta. Synkronisessa kommunikaatiossa samaa tarvetta ei ole, koska palvelupyyntö käsitellään välittömästi. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

17 2.3 Verkkopalvelut (Web-services) Palvelukeskeisen arkkitehtuurin kommunikaatiokanava toteutetaan verkkopalvelujen (Webservices) avulla. Tällöin tietojenkäsittely on palveluorientoitunutta (SOA Service-oriented Computing) (Standards for Service-Oriented Architecture, 2004). Verkkopalvelut voidaan nähdä yhteisenä kommunikointikanavana, jossa sovitaan yhteinen tiedon esitysmuoto (syntaksi ja semantiikka) ja vaihdetaan informaatiota organisaatioiden välillä. Verkkopalveluiden autonomisuus mahdollistaa hyvinkin erilaisten sovellusten integroinnin, kuten esimerkiksi graafisten kuvantamisohjelmien ja tietokantapohjaisten sovellusten yhteistoiminnan. Menetelmän vahvuutena on se, että itse integraation tekninen toteutus ei rajoita verkottumista, vaan on mahdollista suorittaa aidosti integraatiota prosessikeskeisesti esimerkiksi mallintamalla liiketoimintaprosessia ja liiketoimintaentiteettejä ja yhdistelemällä entiteettejä ja operaatioita palvelukomponenttien avulla luoden tarvittavan yhteistoiminnallisuuden. Verkkopalveluarkkitehtuuri perustuu kerrosarkkitehtuuriin, jolloin pinoon liitetään yhä uusia abstraktioita. Usein joustavuuden lisäys johtaa suorituskyvyn (performance) laskuun. Eli yhteistoiminnallisuudesta joudutaan maksamaan. Kuvassa 2 on esitetty sovellusten välinen löyhä kytkentä (loose-coupled) käyttäen verkkopalvelutekniikoita. Browser HTML Application Presentation logic XML +WS-* Other applications Business services Application Business services SQL RDBMS WM (Java,C#) Hardware (OS) Kuva 2: Verkkopalvelut ja sovellusten kommunikaatio (Standards for Service-Oriented Architecture, 2004) Verkkopalvelut toimivat kommunikaatiokanavana ja ne voidaan kuvata protokollapinon (Web service stack) avulla. Protokollapino toimitetaan vastaanottajalle kulloinkin soveltuvaa kommunikaatiokanavaa pitkin. Kuvassa 3 verkkopalvelupino muodostuu jakamalla palvelu abstraktiotason mukaisesti. Liiketoimintaprosessi alkaa ylimmältä tasolta (service negotiation), jossa sovitaan verkkopalveluissa käytettävistä protokollista, viitataan prosessinmäärittelydokumenttiin, työnkulkuun, transaktioihin ja prosessinkulkuun. Seuraavalla tasolla (workflow, discovery, registries) määritellään työnkulku jollain työnkulun kuvaamiseen soveltuvalla XML-pohjaisella kuvausnotaatiolla (esim. WSFL, BPEL4WS). Tällä tasolla ovat määrittelyt palveluiden julkaisemiseksi ja löytämiseksi (UDDI, ebxml Registry). Seuraavalla tasolla (Service description language) on palveluiden SELVITYS 15 17

18 kuvausdokumentti (WSDL, WSCL). Viestitasolla (Messaging) kuvataan viesti rakenteisen SOAPdokumentin avulla. Kaikki liikenne kuljetaan lähettäjältä vastaanottajalle SOAP-sanomassa. Jotta sanoma voitaisiin siirtää teknisiä siirtoteitä pitkin vastaanottajalle, on sovittava siirtoyhteydessä käytettävästä protokollasta. Protokollina voidaan käyttää kaikkia soveltuvia protokollia kuten esimerkiksi HTTP, HTTPS, FTP, IIOP, RMI ja SMTP. Käytännössä vain HTTP, HTTPS ovat suosteltavia protokollia, koska eri järjestelmien palomuurit hankaloittavat muiden protokollien (porttien) käyttöä. Alimpana ovat liiketoimintanäkökohdat (business issues). Tässä kerroksessa sovitaan kaikki liiketoimintaan liittyvät asiat kuten standardit, palvelun laatukysymykset sekä palveluiden järjestämiseen ja organisointiin liittyvät kysymykset. Nämä päätökset ovat lähtökohtana verkkopalvelun toteuttamisessa (Web Service Architectures, 2002). Kuva 3: Verkkopalveluprotokollapino (Web Service Architectures, 2002) Bottom-up ja top-down Palvelupyynnön ja vastauksen rakentamiseksi tarvitaan yhteistoimintaa varten useita näkökulmia. Horisontaalinen näkökulma lähtee siitä, että pyritään kehittämään menettelyjä, jotka ovat yleisiä riippumattomia liiketoiminnan erityispiirteistä. Ajatuksena on, että määrittelyt soveltuvat kaikille sellaisenaan. Tämä lähestymistapa keskittyy bottom-up tyylisesti teknisistä lähtökohdista lähtien yhteistoiminnallisuuden suunnitteluun. Esimerkiksi ensiksi määritellään asiakkaan toiminta-alusta (käyttöjärjestelmä, väliohjelmistot) ja yhteistoimintakanavat. Sen jälkeen tutkitaan olemassa olevat resurssit ja niiden tarjoama toiminnallisuus. Sen jälkeen kääritään olemassa olevat resurssit ja integroidaan niiden tarjoama toiminnallisuus yhtenäisen rajapinnan taakse. Lopuksi mukautetaan sovelluslogiikan syötteet siten, että sovellusta voidaan käyttää asiakkaan käyttämän protokollan avulla käyttäen soveltuvia kanavia. Tätä lähestymistapaa joudutaan käyttämään silloin, kun integroidaan jo olemassa olevia järjestelmiä toisiinsa (Alonso ym., 2004). Uutta järjestelmää suunniteltaessa luonteva lähestymistapa on top-down tyyli. Ongelmakenttää tarkastellaan kokonaisuutena ja määritellään toiminnallisuutta jakaen ongelmakenttä pienempiin osiin. On tutkittava myös, mitkä kerrokset eli esitys, sovelluslogiikka tai resurssikerros (presentation tier, application logic tier, resource management tier) on tarpeen toteuttaa hajautettuna. Tällä periaatteella suunniteltu uusi järjestelmä toteuttaa yleensä yhtä järjestelmäarkkitehtuuria, josta johtuen sen osien (komponenttien) välille muodostuu yleensä tiukka sidonta (tight coupling). Tämä tarkoittaa sitä, että komponenttien välillä on riippuvuuksia, jolloin muutos yhdessä komponentissa voi johtaa muutokseen toisessa komponentissa, jos rajapinnat muuttuvat. 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

19 2.3.2 Etäproseduurikutsu (RPC Remote pr osedure call) - ja viestipohjainen (Message-oriented middleware MOM) -tyyli Verkkopalvelujen perustyyli on etäproseduurikutsujen käyttö (RPC-tyyli), jolloin asiakas on vailla palvelua ja pyytää palveluntuottajalta palvelua ja jää odottamaan vastausta. Vastaus kyselyyn saapuu sovitun ajan puitteissa tai käsittely päättyy poikkeukseen (esim. timeout). RPC-tyyli ei kuitenkaan sovellu pitkäkestoisten palvelupyyntöjen toteuttamiseen, vaan tällöin joudutaan yhteistoiminta rakentamaan viestipohjaisesti (message-oriented). Viestipohjaisuus tarkoittaa sitä, että asiakas lähettää palvelupyynnön omaan lähtevään työjonoonsa, josta se aikanaan siirtyy palveluntarjoajan saapuneitten pyyntöjen työjonoon odottamaan käsittelyä. Verkkopalvelumääritelmät pyrkivät kuvaavamaan yhteistoimintaa horisontaalisesti, mikä tarkoittaa sitä, että ne ovat toteutettavissa alasta ja sovelluksesta riippumatta. Alakohtaiset erityispiirteet kuten koodistot, esitysmuoto ja dokumenttimallit on sovittava erikseen (Alonso ym., 2004) Web Services (WS) -verkkopalvelumäärittely Verkkopalvelut pohjautuvat rakenteisiin dokumentteihin. Palvelupyyntö kuljetetaan SOAPsanomassa osapuolelta toiselle. Sanoma sisältää liiketoiminnan palvelupyynnön (operaatio parametreineen tai dokumentti). Omana kerroksenaan on huomioitava tietoturva, luotettavuus, koordinointi ja transaktioidenhallinta. Sanoman rakentamiseksi voidaan käyttää esimerkiksi dokumenttipohjaista OASIS:ksen ebxml-arkkitehtuuria (ebxml, 2004), (kts. Liite 2) tai IBM:n ja kumppaneiden kehittämää prosessilähtöistä verkkopalveluarkkitehtuuria (Service Oriented Architectures and Web Services, 2004). Prosessikeskeisyys tarkoittaa tässä sitä, liiketoimintaa tarkastellaan matalantason operaatikutsuina ja näiden kutsujen parametreina. Lähtökohta keskittyy liiketoimintaprosessin kuvaamiseen ja toteuttamiseen toimijaverkossa (Alonso ym., 2004). Verkkopalvelut määritellään standardisoituna tapana integroida web-perustaisia sovelluksia käyttäen XML, SOAP, WSDL ja UDDI-standardeja. Nämä standardit ovat avoimia, joten niistä ei tarvitse suorittaa lisenssimaksuja. Sen sijaan lisäpalvelut kuten WS-Security, WS-Reliable Messaging, WS-Transactions, WS-Trust määrittelyt eivät ole avoimia määritelmiä ja ovat siten riskejä integraation rakentajalle (Alonso ym., 2004). Palvelupyynnön välittämiseksi ja automatisoimiseksi tarvitaan (Ferris ym., 2003): - Palvelun löytäminen rekisterin "puhelinluettelon" avulla. Esimerkiksi UDDI (Version 3) on OASIS:n määrittely (UDDI.org, 2004). - Palvelun ominaisuuksien kuvaaminen rakenteisen dokumentin avulla. W3C:n suositukset kattavat SOAP:n (Version 1.2) ja WSDL:n (version 2.0 working draft) (Web Service Activity Statement, 2002). - Liiketoimintaprosessit toteutetaan palveluiden avulla. Palveluketjun hallintaan tarvitaan prosessinhallintavälineitä. Palvelukokonaisuuden toteuttamiseksi palvelujen toteuttamisketju siis se, missä järjestyksessä palvelut toteutetaan, on kuvattava standardilla tavalla. Palveluketjun kuvaaminen voidaan tehdä esimerkiksi BPEL kielellä (BPEL4WS Business Process Execution Language for Web Services) (BPEL4WS Specs. 1.1, 2003). - Palvelun semantiikan kuvaaminen automatisointia varten (semanttinen web) (McIlraith ym., 2003), - Tietoturva, luotettavuus, transaktioiden hallinta, palveluiden koordinaatio, luottamus toteutetaan käyttäen komponenttipohjaisia väliohjelmistoja. Sovelluspalvelinten välistä yhteistoimintaa varten on laadittu määrittelyjä kuten esimerkiksi WS-security, WS-reliable messaging,. Web-service coordination,ws-transactions, WS-trust. - Verkkopalvelujen luotettavuus (WS-reliable messaging) merkitsee, että taataan toimituksen perillemeno ja että viesti menee ainoastaan kerran (ei duplikaatteja). Malli käyttää consu- SELVITYS 15 19

20 mer/producer suunnittelumallia, jos palvelun laatu (quality of service) on omana kerroksenaan. Viestin luotettavuus voidaan varmistaa joko request/response, callback tai poll menettelyillä (Alonso ym., 2004). - Verkkopalvelujen koordinaatio (WS-coordination) on kehys, joka koostuu aktivointipalvelusta, rekisteröintipalvelusta sekä joukosta koordinaatioon liittyvistä koordinaatioprotokollista. Koordinaation avulla voidaan hallita hajautettujen sovellusten operaatioiden toteutusta, voidaan luoda konteksti ja julkaista toiminto toisissa palveluissa ja suorittaa koordinaatioprotokollan rekisteröinti. Kehys mahdollistaa transaktioiden prosessoinnin, työnkulun hallinnan sekä muiden järjestelmien toimintojen koordinoinnin heterogeenisessa ympäristössä (WS-coordination, 2003). - Verkkopalvelujen turvallisuus (WS-security) takaa sovellusten turvallisen viestienvaihdon, jossa sovellusten kesken voidaan vaihtaa mm. käyttäjätunnuksia ja salasanoja (WS-security, 2002). Verkkopalvelujen luottamus (WS-trust) auttaa osapuolia vaihtamaan valtuutustietoja (credentials) (WS-trust, 2004). Sun ja joukko muita yrityksiä ovat alkaneet laatia omaa verkkopalvelustandardia (Web Services Composite Application WS-CAF) suositusta, jonka avulla on tarkoituksena mahdollistaa komposiittisovellusten (composite application) rakentaminen. Suositus koostuu kolmesta määritelmästä (WS-CAF Announcement, 2004): - Kontekstinhallinta (Web service context WS-CTX), joka yksinkertainen kehys kontekstinhallintaan, jonka avulla osallistuja voivat jakaa saman kontekstin ja vaihtaa informaatiota. - Koordinaationhallinta (Web service coordination framework WS-CF) määrittelee ohjelmistoagentin ominaisuudet kontekstinhallitsemiseksi. Koordinaattori varmistaa, että viestit ja tulokset kommunikoivat asianmukaisesti niin, että jonkin palvelun toteutuminen tai virhetoiminto voidaan sitoa osaksi suurempaa kokonaisuutta ja luoda siten verkkopalvelukokonaisuuksia. - Transaktionhallinta (Web services transaction management WS-TXM) määrittelee transaktioprotokollat, jotka voidaan liittää (plugged) koordinaatiokehykseen ja luoda yhteistoimintaa transaktiomanagereiden, pitkäkestoisten tapahtumien ja asynkronisten liiketoimintaprosessien kesken. Sen tarkoituksena on olla siltana erilaisten transaktionhallintamallien välillä kuten esimerkiksi MQ Series:n ja JMS:n välillä. Kuvassa 4 on esitetty IBM:n verkkopalveluiden pino (Web Services Stack). Kuva 4: Verkkopalvelupino (Curbera ym., 2003) 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

Jä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ätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajä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ätiedot

HOJ J2EE & EJB & SOAP &...

HOJ 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ätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria. CASE: Metropolia. Jaakko Rannila & Tuomas Orama 1

Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria. CASE: Metropolia. Jaakko Rannila & Tuomas Orama 1 Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria CASE: Metropolia 31.10.2012 Jaakko Rannila & Tuomas Orama 1 Aiheet Tietojärjestelmien integrointi Integrointiin liittyvät

Lisätiedot

A Service-Oriented Architecture (SOA) View of IHE Profiles

A 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ätiedot

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen

Vastausten 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ätiedot

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio Muutos PlugIT-tutkimusyhteistyösopimukseen, sivu 1/29 Muutos Tutkimusyhteistyösopimukseen PlugIT: Terveydenhuollon sovellusintegraatio 1. Projektiosapuolet: 1.1 Tutkimusosapuolet KUOPION YLIOPISTO, projektin

Lisätiedot

Sovellusarkkitehtuurit

Sovellusarkkitehtuurit HELIA TiKo-05 1 (9) Sovellusarkkitehtuurit ODBC (Open Database Connectivity)... 2 JDBC (Java Database Connectivity)... 5 Middleware... 6 Middleware luokittelu... 7 Tietokanta -middleware... 8 Tapahtumamonitorit

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Tieto ja järjestelmät integroituvat asiakaslähtöisiksi palveluiksi. JHS-seminaari Jukka Ahtikari

Tieto ja järjestelmät integroituvat asiakaslähtöisiksi palveluiksi. JHS-seminaari Jukka Ahtikari Tieto ja järjestelmät integroituvat asiakaslähtöisiksi palveluiksi JHS-seminaari 5.4.2005 Jukka Ahtikari Yhteentoimivuus muodostuu eri osa-alueista Yhteentoimivat palvelut Organisatorinen käyttäjät, prosessit,

Lisätiedot

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( )

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( ) PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma (1.5.2002-31.8.2004) Ydin-osaprojekti: potilastietojen toiminnallisen hallinnan näkökulma Yhteisten ydinkomponenttien määrittely" Ydin-osaprojektin rooli

Lisätiedot

Kari Rouvinen Johtaja, Technology Products & Solutions. Oracle Finland Oy

Kari Rouvinen Johtaja, Technology Products & Solutions. Oracle Finland Oy Kari Rouvinen Johtaja, Technology Products & Solutions Oracle Finland Oy Puolimatkassa Fusioniin Yritysostoja Collaxa Kesäkuu 2004 Prosessi-integraatio ohjelmisto PeopleSoft Tammikuu 2005 Yritysohjelmisto

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

www.solita.fi solita@solita.fi

www.solita.fi solita@solita.fi www.solita.fi solita@solita.fi JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005 Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen

Lisätiedot

Työeläkeyhtiö Varma. IBM Software Day 9.11.2010 Tuukka Tusa, Digia

Työeläkeyhtiö Varma. IBM Software Day 9.11.2010 Tuukka Tusa, Digia Työeläkeyhtiö Varma IBM Software Day 9.11.2010 Tuukka Tusa, Digia Varman perustehtävät Toimintamme perustuu suomalaiseen työhön ja työeläkejärjestelmän kestävyyden turvaamiseen Käsittelemme eläkkeet oikein

Lisätiedot

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-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ätiedot

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

SOA SIG SOA Tuotetoimittajan näkökulma

SOA 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ätiedot

Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability.

Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability. Integrointi? Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability. Joitain motivaattoreita... 1. Enterprise Application Integration: Eri organisaatioissa

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri

Jä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ätiedot

Kuntien integraatioalusta. Hannes Rauhala 3.11.2015

Kuntien integraatioalusta. Hannes Rauhala 3.11.2015 Kuntien integraatioalusta Hannes Rauhala 3.11.2015 Johdantoa asiaan Espoon kaupunki on toiminut edelläkävijänä kansallisen palveluväylän (Xroad) käyttöönotossa. Asiasta järjestettiin Espoossa ja Lahdessa

Lisätiedot

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy

Harri 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ätiedot

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy Käytännön haasteita ja ratkaisuja integraation toteutuksessa Jukka Jääheimo Teknologiajohtaja Solita Oy 13.03.2008 Sisältö 2 Alustus Integraation haasteet Integraatioarkkitehtuuri Hyvän integraatioarkkitehtuurin

Lisätiedot

Integraatiotekniikan valinta - tie onnistumiseen.

Integraatiotekniikan valinta - tie onnistumiseen. Integraatiotekniikan valinta - tie onnistumiseen markus.andersson@commit.fi http://www.commit.fi 1 Agenda Järjestelmäintegroinnin nykytila Menestystekijät Teknologiatekijät Tekijöistä onnistunut projekti

Lisätiedot

Palvelun versio 1.0 Toimeenpanopalvelun tunnus (ks. M ) 10fea, 9c2f, 4760, 9095, f4f9295f4b19

Palvelun versio 1.0 Toimeenpanopalvelun tunnus (ks. M ) 10fea, 9c2f, 4760, 9095, f4f9295f4b19 1 5. Luokittamispalvelu 5.1. Palveluinformaatio Palvelun nimi Luokittamispalvelu Palvelun versio 1.0 Toimeenpanopalvelun tunnus (ks. M14.4.42) 10fea, 9c2f, 4760, 9095, f4f9295f4b19 5.2 Avainkäsitteet 5.2.1

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston 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ätiedot

IPv6 käyttöönoton mahdollistajat operaattorin näkemys

IPv6 käyttöönoton mahdollistajat operaattorin näkemys IPv6 käyttöönoton mahdollistajat operaattorin näkemys Jyrki Soini TeliaSonera 1 IPv6 toimi nyt IPv4 osoitteet loppumassa hyvää vauhtia keskusvarasto (IANA) jakoi viimeiset osoitelohkot 3.2.2011 RIPE arvioi

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät 2012-2013

Ohjelmistoarkkitehtuurit. Kevät 2012-2013 Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit 1 Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät

Ohjelmistoarkkitehtuurit. Kevät Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:

Lisätiedot

Σ!3674. Advanced Test Automation for Complex Software-Intensive Systems

Σ!3674. Advanced Test Automation for Complex Software-Intensive Systems Advanced Test Automation for Complex Software-Intensive Systems = Advanced Test Automation for Complex Software- Intensive Systems Pääteemana kompleksisten ja erittäin konfiguroitavien softaintensiivisten

Lisätiedot

TIETOHALLINTOLAKI (LUONNOS) Korkeakoulujen IT-päivät Erityisasiantuntija Olli-Pekka Rissanen

TIETOHALLINTOLAKI (LUONNOS) Korkeakoulujen IT-päivät Erityisasiantuntija Olli-Pekka Rissanen TIETOHALLINTOLAKI (LUONNOS) 13.10.2010 Korkeakoulujen IT-päivät Erityisasiantuntija Olli-Pekka Rissanen Keskeisenä tavoitteena Toteuttaa eduskunnan 7.12.2009 tekemä päätös, että hallituksen tulisi valmistella

Lisätiedot

Liikkuvien työkoneiden etäseuranta

Liikkuvien työkoneiden etäseuranta Liikkuvien työkoneiden etäseuranta TAMK IoT Seminaari 14.4.2016 2 1) IoT liiketoiminnan tukena 2) Iot ja liikkuvat työkoneet 3) Case esimerkit 4) Yhteenveto, johtopäätökset, tulevaisuuden näkymät Cinia

Lisätiedot

itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance

itsmf 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ätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

Lisätiedot

Tulevaisuuden Internet. Sasu Tarkoma

Tulevaisuuden Internet. Sasu Tarkoma Tulevaisuuden Internet Sasu Tarkoma Johdanto Tietoliikennettä voidaan pitää viime vuosisadan läpimurtoteknologiana Internet-teknologiat tarjoavat yhteisen protokollan ja toimintatavan kommunikointiin Internet

Lisätiedot

Soveltuvimpien standardien esittely ja vaikutusten arviointi TITAN Tietoturvaa teollisuusautomaatioon Tekes Turvallisuusohjelman hanke

Soveltuvimpien standardien esittely ja vaikutusten arviointi TITAN Tietoturvaa teollisuusautomaatioon Tekes Turvallisuusohjelman hanke Soveltuvimpien standardien esittely ja vaikutusten arviointi TITAN Tietoturvaa teollisuusautomaatioon Tekes Turvallisuusohjelman hanke TITAN-SEMINAARI 9.11.2010 Pasi Ahonen, VTT TITAN projektissa koottiin

Lisätiedot

PerustA - Perustietovarantojen viitearkkitehtuuri. Liite 3: Tietojärjestelmäarkkitehtuurin. integraatioarkkitehtuuri

PerustA - Perustietovarantojen viitearkkitehtuuri. Liite 3: Tietojärjestelmäarkkitehtuurin. integraatioarkkitehtuuri 1 (11) PerustA - Perustietovarantojen viitearkkitehtuuri Liite 3: Tietojärjestelmäarkkitehtuurin looginen jäsennys ja integraatioarkkitehtuuri 2 (11) Sisältö 1 TIETOJÄRJESTELMÄARKKITEHTUURIN LOOGINEN JÄSENNYS

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

Korkeakoulujen IT muutoksessa. Trendejä ja vaikutuksia maailmalta ja meiltä

Korkeakoulujen IT muutoksessa. Trendejä ja vaikutuksia maailmalta ja meiltä Korkeakoulujen IT muutoksessa Trendejä ja vaikutuksia maailmalta ja meiltä Miksi me välitämme Trendeistä? Globaalit macro trendit Toimialakohtaiset trendit Teknologia trendit Oma synteesi ja tutkimus Lisää

Lisätiedot

Luento 12: XML ja metatieto

Luento 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ätiedot

Edellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti

Edellä 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ätiedot

Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla

Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla lopullinen versio esityksestä löytyy osoitteesta: http://www.centek.fi/serapi/mater/thatk05.pdf Terveydenhuollon atk-päivät, Helsinki,

Lisätiedot

Palveluprosessien tietomallit ja masterdatan hallinta SOA ympäristössä

Palveluprosessien tietomallit ja masterdatan hallinta SOA ympäristössä Palveluprosessien tietomallit ja masterdatan hallinta SOA ympäristössä Timo Itälä TKK IIR 22.4.2009 Agenda SOA ja MDM? Toimintaprosessit ja niiden tietomallit Masterdata Palveluarkkitehtuuri ja masterdata

Lisätiedot

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisuus kahdella tasolla Oppimisaihiot ( Learning Objects

Lisätiedot

SOLEA-tulosseminaari Päätössanat

SOLEA-tulosseminaari Päätössanat SOLEA-tulosseminaari Päätössanat Espoo, 25.11.2011 Juha Mykkänen, Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos, HIS-yksikkö Kari Hiekkanen, Aalto-yliopiston Teknillinen korkeakoulu, SoberIT-laboratorio

Lisätiedot

INTEGROIDUT PROJEKTITOTEUTUKSET. IPT-strategiapäivä , Lauri Merikallio, Vison Alliance Partners Oy

INTEGROIDUT PROJEKTITOTEUTUKSET. IPT-strategiapäivä , Lauri Merikallio, Vison Alliance Partners Oy INTEGROIDUT PROJEKTITOTEUTUKSET IPT-strategiapäivä 16.1.2014, Lauri Merikallio, Vison Alliance Partners Oy Arkipäivän pohdintaa epävarmuuksia ja riskejä sisältävien hankkeiden johtamisessa Kuka/ketkä hinnoittelevat

Lisätiedot

Päihittääkö J2EE.NETin SOAn pohjana?

Päihittääkö J2EE.NETin SOAn pohjana? Päihittääkö J2EE.NETin SOAn pohjana? Nääsvillen Oliopäivät 2004 15.12.2004 Pekka Kähkipuro Kehitysjohtaja, FT pekka.kahkipuro@sysopen.fi Sisällys Miksi SOA? Palvelukeskeinen arkkitehtuuri Ratkaiseeko SOA

Lisätiedot

Tavallisimmat kysymykset

Tavallisimmat kysymykset Autodesk Design- ja Creation Suite -paketit Tavallisimmat kysymykset Tässä dokumentissa on vastauksia tavallisimpiin kysymyksiin Design- ja Creation Suite -pakettien myynnin loppumisesta. 24.5.2016 Sisällysluettelo

Lisätiedot

Harjoitustyö Case - HelpDesk

Harjoitustyö Case - HelpDesk Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.

Lisätiedot

Kuluttajille tarjottavan SIP-sovelluksen kannattavuus operaattorin kannalta

Kuluttajille tarjottavan SIP-sovelluksen kannattavuus operaattorin kannalta Kuluttajille tarjottavan SIP-sovelluksen kannattavuus operaattorin kannalta Diplomityöseminaari 6.6.2005 Tekijä: Sanna Zitting Valvoja: Heikki Hämmäinen Ohjaaja: Jari Hakalin Sisältö Taustaa Ongelmanasettelu

Lisätiedot

Uutta Remote Support Platform 3.0 -versiossa

Uutta Remote Support Platform 3.0 -versiossa Uutta Remote Support Platform for SAP Business One Asiakirjaversio: 1.0 2012-10-08 Kaikki maat Typografiset merkintätavat Kirjasintyyli Esimerkki Näytöstä lainatut sanat tai merkit. Näitä ovat kenttien

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

Sisällönhallinnan menetelmiä

Sisällönhallinnan menetelmiä Sisällönhallinnan menetelmiä Airi Salminen Jyväskylän yliopisto http://www.cs.jyu.fi/~airi/ Suomalaisen lainsäädäntötyön tiedonhallinta: suuntana semanttinen web RASKE2-projektin loppuseminaari Eduskunnassa

Lisätiedot

vakuutuslaitosten ja TAMLAn välillä

vakuutuslaitosten ja TAMLAn välillä Asioiden välittämien työeläkealan toimijoiden ja TELKin sekä vakuutuslaitosten ja TAMLAn välillä Työeläkealan XML-käytäntöjen soveltaminen Taustaa, tämän dokumentin tarkoitus Asioiden välittäminen tapahtuu

Lisätiedot

Supply Chain Module 1

Supply Chain Module 1 2.5.2016 Supply Chain Module 1 1. Määritelmä 2. Kuinka vähittäiskaupan ketju toimii? 3. Mitä toimenpiteitä teet kaupassa? 3.1. Perusvarastonvalvonta/ Check-in ja Check-out toiminnot (Vastaanotto ja Palautukset)

Lisätiedot

Tietoyhteiskunnan haavoittuvuus kuinka voimme hallita sitä?

Tietoyhteiskunnan haavoittuvuus kuinka voimme hallita sitä? Huoltovarmuuskeskuksen 10-vuotisjuhlaseminaari Helsinki, 26.2.2003 Tietoyhteiskunnan haavoittuvuus kuinka voimme hallita sitä? TkT Arto Karila Karila A. & E. Oy E-mail: arto.karila@karila.com HVK, 26.2.2003-1

Lisätiedot

TIMECON UNISON SUJUVAA TURVALLISUUDEN HALLINTAA

TIMECON UNISON SUJUVAA TURVALLISUUDEN HALLINTAA TIMECON UNISON SUJUVAA TURVALLISUUDEN HALLINTAA TIMECON UNISON Moderni IP-pohjainen turvallisuuden hallintajärjestelmä TIMECON UNISON mahdollistaa joustavuudellaan sekä helppokäyttöisyydellään organisaatioille

Lisätiedot

JHS-järjestelmä ja avoimet teknologiat. Tommi Karttaavi

JHS-järjestelmä ja avoimet teknologiat. Tommi Karttaavi JHS-järjestelmä ja avoimet teknologiat Tommi Karttaavi 13.5.2008 JHS-järjestelmä (historiaa) Valtioneuvoston päätös valtionhallinnon sisäisistä standardeista 7.9.1977 Valtiovarainministeriö vahvisti valtionhallinnon

Lisätiedot

Case: Avoimen lähdekoodin ohjelmistojen hyödyntäminen Lahdessa

Case: Avoimen lähdekoodin ohjelmistojen hyödyntäminen Lahdessa Case: Avoimen lähdekoodin ohjelmistojen hyödyntäminen Lahdessa JHS-seminaari, Säätytalo Marko Monni Tietohallintojohtaja Lahden kaupunki Agenda Nykytila Tulevaisuus Miksi avoimen lähdekoodin ohjelmistoja?

Lisätiedot

KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA

KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA Tarjouspyyntö Liite 5.3: Järjestelmän ylläpidettävyden arviointi 1 / 5 VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 22.4.15 3.01 Poistettu kotihoito

Lisätiedot

Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen

Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen Yrjö Koivusalo tietohallintapäällikkö Varsinais-Suomen sairaanhoitopiiri Kansallinen vs. alueellinen arkkitehtuuri Onko yhteensovittaminen

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

XML johdanto, uusimmat standardit ja kehitys

XML johdanto, uusimmat standardit ja kehitys johdanto, uusimmat standardit ja kehitys Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: on W3C:n suosittama

Lisätiedot

TeliaSonera Identity and Access Management

TeliaSonera Identity and Access Management TeliaSonera Identity and Access Management 22.10.2009 EMC Forum Juha Arjoranta 1 TeliaSonera Identity and Access Management Alustus käyttövaltuushallintaan IAM kokonaisratkaisun elementit Nykytilaa ja

Lisätiedot

Liite A Määritelmät 1 (6)

Liite A Määritelmät 1 (6) 1 (6) Liite A Määritelmät 2.3 Uusi versio 2.4 Versio joulukuun neuvotteluja varten 2.6 Tarjoajille 29.1.2015 lähetetty versio 2.7 Helmikuun 2015 neuvotteluissa käsitelty versio 2.81 Tarjoajille 18.2.2015

Lisätiedot

Suomi.fi-palveluväylä

Suomi.fi-palveluväylä Suomi.fi-palveluväylä 18.11.2016 Versio: 3.0, JPVO122 Esityksen sisältö 1. Suomi.fi-palvelukokonaisuus 2. Palvelulupauksemme 3. Mitä palvelu tarjoaa? 4. Palveluväylän kokonaisuus 5. Vyöhykkeet ja väyläratkaisut

Lisätiedot

Muutokset suoran sanoma-asioinnin webservicepalvelun

Muutokset suoran sanoma-asioinnin webservicepalvelun SANOMALIIKENNE Tullihallitus Suora sanoma-asiointi 16.6.2012 Muutokset suoran sanoma-asioinnin webservicepalvelun XML-schemoihin v.1.8 muutos 16.6.2012 SISÄLLYSLUETTELO 1 Johdanto... 3 2 Aikataulu ja yhteensopivuus...

Lisätiedot

Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille

Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille Liite Kansallinen vaativuustaso / eurooppalaisen tutkintojen viitekehyksen taso Taso1 Tutkinnot, oppimäärät ja

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 9. Virtualisointi ja pilvipalvelut teknologia-arkkitehtuurin suunnittelussa

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 9. Virtualisointi ja pilvipalvelut teknologia-arkkitehtuurin suunnittelussa JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 9. Virtualisointi ja pilvipalvelut teknologia-arkkitehtuurin suunnittelussa Versio: Palautekierros, 2. palautekierros Julkaistu: Voimassaoloaika:

Lisätiedot

SOA:lle on useita, jonkin verran toisistaan poikkeavia määritelmiä. Alla niistä muutamia.

SOA:lle on useita, jonkin verran toisistaan poikkeavia määritelmiä. Alla niistä muutamia. 1 Tässä esimerkki vaikkapa tyypillisestä yrityksen tietojärjestelmästä. Järjestelmään liitetään uusia osia vähitellen. Eri osat ovat eri tahojen erilaisilla teknologioilla kehittämiä. Osien välinen liitos

Lisätiedot

Liiketoimintasovellusten modernisointi - Anna sovelluksillesi uusi elämä. Sofor varmistaa investointiesi tehokkaan hyödyntämisen

Liiketoimintasovellusten modernisointi - Anna sovelluksillesi uusi elämä. Sofor varmistaa investointiesi tehokkaan hyödyntämisen Liiketoimintasovellusten modernisointi - Anna sovelluksillesi uusi elämä Sofor varmistaa investointiesi tehokkaan hyödyntämisen 1 Syitä liiketoimintasovellusten modernisointiin Sovellusten käyttötarkoitus

Lisätiedot

Vuorovaikutteinen 3D ja tietomallipalvelimet

Vuorovaikutteinen 3D ja tietomallipalvelimet Vuorovaikutteinen 3D ja tietomallipalvelimet 1 2 Sisältö Virtuaalirakentamisen laboratorio Tietomallipalvelimet Vuorovaikutteinen 3D Vuorovaikutteinen 3D ja tietomallipalvelimet Vuorovaikutteinen 3D iroom

Lisätiedot

6. Arkkitehtuurityylit

6. Arkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit - Kerrosarkkitehtuurit - Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit - Asiakas-palvelin arkkitehtuurit - Viestinvälitysarkkitehtuurit

Lisätiedot

Pharma-ohjelman tilanne ja kansainvälisen liiketoimintaosaamisen kehittäminen Harri Ojansuu Teknologia-asiantuntija

Pharma-ohjelman tilanne ja kansainvälisen liiketoimintaosaamisen kehittäminen Harri Ojansuu Teknologia-asiantuntija Pharma-ohjelman tilanne ja kansainvälisen liiketoimintaosaamisen kehittäminen 6.5.2008 Harri Ojansuu Teknologia-asiantuntija Ohjelman kesto: 2008-2011 Ohjelman laajuus: 58 miljoonaa euroa Visio Suomessa

Lisätiedot

suomi.fi Suomi.fi-palveluväylä

suomi.fi Suomi.fi-palveluväylä Suomi.fi-palveluväylä Julkishallinto, valtion ja kuntien yhtiöt 11.9.2015 Versio 1.0 JPV031 Esityksen sisältö 1. Suomi.fi-palvelukokonaisuus 2. Palvelulupauksemme 3. Mitä palvelu tarjoaa? 4. Miten? 5.

Lisätiedot

13/20: Kierrätys kannattaa koodaamisessakin

13/20: Kierrätys kannattaa koodaamisessakin Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy

Lisätiedot

TIMECON UNISON SUJUVAA TURVALLISUUDEN HALLINTAA

TIMECON UNISON SUJUVAA TURVALLISUUDEN HALLINTAA TIMECON UNISON SUJUVAA TURVALLISUUDEN HALLINTAA TIMECON UNISON Moderni IP-pohjainen turvallisuuden hallintajärjestelmä. Mahdollisuus integrointiin eri järjestelmien välillä oli yksi pääsyistä, miksi valitsimme

Lisätiedot

REST an idealistic model or a realistic solution?

REST an idealistic model or a realistic solution? REST an idealistic model or a realistic solution? 17.10.2006 Jari Aarniala jari.aarniala@cs.helsinki.fi Johdanto Representational State Transfer, eli REST Arkkitehtuurinen tyyli hajautetuille (hypermedia)järjestelmille

Lisätiedot

SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri. Service-Oriented Locally adapted Enterprise Architecture

SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri. Service-Oriented Locally adapted Enterprise Architecture SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri Service-Oriented Locally adapted Enterprise Architecture "Miten meillä mennään SOA:an?" @ SOLEA-project participants Hankkeen osapuolet

Lisätiedot

HIJAT HR TYÖPÖYTÄ PALVELUNA KUVAUS, SOPIMUS 22005, LIITE 2

HIJAT HR TYÖPÖYTÄ PALVELUNA KUVAUS, SOPIMUS 22005, LIITE 2 HIJAT HR TYÖPÖYTÄ PALVELUNA KUVAUS, SOPIMUS 22005, LIITE 2 HELSINGIN KAUPUNKI JA LOGICA OY 1 Palvelusopimus 22005 1 SISÄLLYSLUETTELO 1 PALVELUNA -PALVELUN TEKNINEN PALVELINYMPÄRISTÖN KUVAUS... 2 2 PALVELUNA-PALVELU...

Lisätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

Lisätiedot

yritysneuvontapalvelut Yritys Suomi sopimuksen puitteissa koulutus ja kehittämispalvelut, joita kehitetään Yhessä hankkeessa

yritysneuvontapalvelut Yritys Suomi sopimuksen puitteissa koulutus ja kehittämispalvelut, joita kehitetään Yhessä hankkeessa yritysneuvontapalvelut Yritys Suomi sopimuksen puitteissa koulutus ja kehittämispalvelut, joita kehitetään Yhessä hankkeessa Yhden luukun periaate? Eri osa-alueisiin erikoistuneet toimijat pystyvät yhdessä

Lisätiedot

MÄÄRÄYS SIJOITUSPALVELUYRITYKSEN RISKIENHALLINNASTA JA MUUSTA SISÄISESTÄ VALVONNASTA

MÄÄRÄYS SIJOITUSPALVELUYRITYKSEN RISKIENHALLINNASTA JA MUUSTA SISÄISESTÄ VALVONNASTA lukien toistaiseksi 1 (5) Sijoituspalveluyrityksille MÄÄRÄYS SIJOITUSPALVELUYRITYKSEN RISKIENHALLINNASTA JA MUUSTA SISÄISESTÄ VALVONNASTA Rahoitustarkastus antaa sijoituspalveluyrityksistä annetun lain

Lisätiedot

VALTIONEUVOSTON ASETUS VAHVAN SÄHKÖISEN TUNNISTUSPALVELUN TARJOAJI- EN LUOTTAMUSVERKOSTOSTA

VALTIONEUVOSTON ASETUS VAHVAN SÄHKÖISEN TUNNISTUSPALVELUN TARJOAJI- EN LUOTTAMUSVERKOSTOSTA LIIKENNE- JA VIESTINTÄMINISTERIÖ Muistio Liite 1 Viestintäneuvos 27.10.2015 Kreetta Simola LUONNOS VALTIONEUVOSTON ASETUS VAHVAN SÄHKÖISEN TUNNISTUSPALVELUN TARJOAJI- EN LUOTTAMUSVERKOSTOSTA Taustaa Vuoden

Lisätiedot

Sisäasianministeriön toimenpiteet henkilöstöhallinnon yhtenäistämiseksi

Sisäasianministeriön toimenpiteet henkilöstöhallinnon yhtenäistämiseksi Sisäasiainministeriön hallinnonalan Kieku-tietojärjestelmähanke Sisäasianministeriön toimenpiteet henkilöstöhallinnon yhtenäistämiseksi Kieku-info 23.9.2011 Sirpa Joensuu, projektipäällikkö Lähtötilanne

Lisätiedot

Verkostot ja strateginen kyvykkyys kilpailutekijänä

Verkostot ja strateginen kyvykkyys kilpailutekijänä Menestyksen eväät Kone- ja metallituoteteollisuus tuottavuusloikkaukseen yhteistyöllä Verkostot ja strateginen kyvykkyys kilpailutekijänä Liiketoimintasuhteen anatomia Jukka Vesalainen Vaasan yliopisto

Lisätiedot

Lean johtaminen ja työkalut. Työpaja 16.3.2016

Lean johtaminen ja työkalut. Työpaja 16.3.2016 Lean johtaminen ja työkalut Työpaja 16.3.2016 Lean ja Lean Construction Teoriainformoidut käytännön ihmiset MITÄ ON LEAN? LEAN on johtamisfilosofia joka on koko organisaatiota koskeva laaja-alainen muutosprosessi,

Lisätiedot

Sovelluspalvelin terveydenhuollon sovellustuotannossa ja sovel Iusintegraat iossa, Juha Rannanheimo, Kuopion YO

Sovelluspalvelin terveydenhuollon sovellustuotannossa ja sovel Iusintegraat iossa, Juha Rannanheimo, Kuopion YO SUOMEN KUNTAUITTO Sosiaali - ja terveysyksikkö TERVEYDENHUOLLON 27. ATK- PAIVAT 4. - 5.6.2001 Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuksen päivät Sovelluspalvelin terveydenhuollon

Lisätiedot

Tietotuen suunnittelu hoitolinjojen sairaalassa

Tietotuen suunnittelu hoitolinjojen sairaalassa Tietotuen suunnittelu hoitolinjojen sairaalassa Kaarina Tanttu, VSSHP, T- Pro hanke VARSINAIS-SUOMEN SAIRAANHOITOPIIRI kaarina.tanttu@tyks.fi HOSPITAL DISTRICT OF VARSINAIS-SUOMI Hoitolinjojen sairaalan

Lisätiedot

Järjestelmäintegrointi osana sovellusten rakentamista

Järjestelmäintegrointi osana sovellusten rakentamista 05 96 09:33 MEDICI DATA OY NT=358 81 3155650 5.02 Järjestelmäintegrointi osana sovellusten rakentamista Antero Ensio Medici Data Oy MediciData Oy aese9605.ppt 24.5.1998 7:51 sivu 1 24 05 96 09:34 MEDICI

Lisätiedot

EcoProP Potilashuoneen toiminnalliset vaatimukset

EcoProP Potilashuoneen toiminnalliset vaatimukset EcoProP Potilashuoneen toiminnalliset vaatimukset HospiTool 1.12.2006 Janne Porkka Esityksen sisältö Taustatietoja Vaatimustenhallinta Toimivuusajattelu HospiTool hankkeen 1.vaiheen esittely Pyritään määrittelemään

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Tietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy.

Tietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy. Tietoturvallisuuden kokonaisvaltainen hallinta 3.12.2015 Heikki O. Penttinen Castilsec Oy Tietoturvallisuuden päätavoitteet organisaatioissa Tietoturvallisuuden oikean tason varmistaminen kokonaisvaltaisesti

Lisätiedot

Viisi vinkkiä tasokkaaseen tiedolla johtamiseen ja parempaan asiakasymmärrykseen

Viisi vinkkiä tasokkaaseen tiedolla johtamiseen ja parempaan asiakasymmärrykseen Viisi vinkkiä tasokkaaseen tiedolla johtamiseen ja parempaan asiakasymmärrykseen Big Data Solutions Oy 2017 VIISI VINKKIÄ TASOKKAASEEN TIEDOLLA JOHTAMISEEN JA PAREMPAAN ASIAKASYMMÄRRYKSEEN Basware on maailman

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Prosessien ja toiminnan kuvaamisen kehittämiskohteet, tasot, näkökulmat ja esimerkit

Prosessien ja toiminnan kuvaamisen kehittämiskohteet, tasot, näkökulmat ja esimerkit Irmeli Luukkonen, Itä-Suomen Yliopisto, Tietojenkäsittelytieteen laitos, HIStutkimusryhmä SOLEA-seminaari, 25.11. 2011 klo 9-16, Dipoli, Espoo Prosessien ja toiminnan kuvaamisen kehittämiskohteet, tasot,

Lisätiedot

Liikkuva työ pilotin julkinen raportti 30.06.2014

Liikkuva työ pilotin julkinen raportti 30.06.2014 Liikkuva työ pilotin julkinen raportti 30.06.2014 2 / 9 Green ICT pilotin raportti SISÄLLYSLUETTELO 1. Tiivistelmä koekäytöstä... 3 2. Toteutus... 4 2.1.Tavoite... 4 2.2.Mobiilisovellus... 4 2.3.Käyttöönotto...

Lisätiedot

Verkostoituneen toimintaympäristön ja projektien turvallisuuden hallinta. Professori Harri Haapasalo

Verkostoituneen toimintaympäristön ja projektien turvallisuuden hallinta. Professori Harri Haapasalo Verkostoituneen toimintaympäristön ja projektien turvallisuuden hallinta Professori Harri Haapasalo Esityksen sisältö Mitä verkostoitunut toimintaympäristö tarkoittaa? & Mitä haasteita verkostoituneessa

Lisätiedot