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

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

Liiketoimintajärjestelmien integrointi

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

PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003. Koko projektin keskeiset tehtävät

PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003. Koko projektin keskeiset tehtävät PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003 Tässä työsuunnitelmassa on esitetty vain tutkimussuunnitelman mukaisten tärkeimpien tuotosten aikaansaamiseksi

Lisätiedot

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

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

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

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

Älykäs verkottuminen ja käyttäjänhallinta. Pekka Töytäri TeliaSonera Finland

Älykäs verkottuminen ja käyttäjänhallinta. Pekka Töytäri TeliaSonera Finland Älykäs verkottuminen ja käyttäjänhallinta Pekka Töytäri TeliaSonera Finland 1 Älykäs verkottuminen Tekniikka, organisaatio ja prosessit muodostavat yhtenäisesti toimivan palvelualustan Älykäs toiminnallisuus

Lisätiedot

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin

Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin Tampereen teknillinen yliopisto 28.1.2010 Jouni Vuorensivu Remion Ltd. www.remion.com jouni.vuorensivu@remion.com Jouni Vuorensivu

Lisätiedot

HSMT J2EE & EJB & SOAP &...

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

Tietojärjestelmäarkkitehtuurit

Tietojärjestelmäarkkitehtuurit Tietojärjestelmäarkkitehtuurit ITK130 Johdatus ohjelmistotekniikkaan Syksy 2003 Sami Kollanus 1 Aluksi Tietojärjestelmäarkkitehtuurit vs. ohjelmistoarkkitehtuurit Pohjana Tietojärjestelmäarkkitehtuurit

Lisätiedot

Microsoft Dynamics CRM 4.0. Jani Liukkonen

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

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

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

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

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

Tiedonsiirto- ja rajapintastandardit

Tiedonsiirto- ja rajapintastandardit Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen

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

Tässä kertauksena SOA ja palvelu.

Tässä kertauksena SOA ja palvelu. 1 Tässä kertauksena SOA ja palvelu. Eri lähteet esittävät erilaisia vaatimuksia SOA-järjestelmän osasille eli palveluille. Yleisimpiä ja tärkeimpiä ovat autonomisuus, löyhä sidonta, toteutusriippumaton

Lisätiedot

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja 1 Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja kommunikointi toteutetaan SOAPin avulla. Näihin kieliin

Lisätiedot

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

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

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) Yritysarkkitehtuuri. Muutostarpeet

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet Järjestelmäarkkitehtuuri (TK081702) Ympäristö Muutostarpeet ja niihin vastaaminen Yritysarkkitehtuuri Liiketoiminta-arkkitehtuuri Tavoitteet, Palvelut, Prosessit Informaatioarkkitehtuuri Tietotarpeet,

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

Semanttisen Webin mahdollisuudet yrityksille

Semanttisen Webin mahdollisuudet yrityksille Semanttisen Webin mahdollisuudet yrityksille Käytännön kokemuksia 15.1.2010 Janne Saarela Profium Oy Esityksen sisältö Semanttisen Webin arvolupaus Arvolupauksen lunastaminen Kuvapankeissa Järjestelmäintegraatiossa

Lisätiedot

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen.

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

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

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

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit

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

Ajankohtaisia SOA tutkimusteemoja

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

Verkostojen tehokas tiedonhallinta

Verkostojen tehokas tiedonhallinta Tieto Corporation Verkostojen tehokas tiedonhallinta Value Networks 3.9.2014 Risto Raunio Head of Lean System Tieto, Manufacturing risto.raunio@tieto.com Sisältö Mihin verkostoitumisella pyritään Verkoston

Lisätiedot

Paketoidut toiminnanohjausratkaisut projektiorganisaatioille. Jan Malmström Mepco Oy

Paketoidut toiminnanohjausratkaisut projektiorganisaatioille. Jan Malmström Mepco Oy Paketoidut toiminnanohjausratkaisut projektiorganisaatioille Jan Malmström Mepco Oy Projektiorganisaatioiden haasteita Investoinnin myyminen johdolle ja johdon sitoutuminen Organisaation totuttujen toimintamallien

Lisätiedot

Kokonais-IS-arkkitehtuuri korkeakouluissa Tietohallinnon näkökulma

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

TeliaSonera. Marko Koukka. IT viikon seminaari 11.10. 2007 Identiteetin hallinta palveluna, Sonera Secure IDM

TeliaSonera. Marko Koukka. IT viikon seminaari 11.10. 2007 Identiteetin hallinta palveluna, Sonera Secure IDM TeliaSonera Marko Koukka IT viikon seminaari 11.10. 2007 Identiteetin hallinta palveluna, Sonera Secure IDM Sisällysluettelo Identiteetinhallinta operaattorin näkökulmasta Identiteetinhallinnan haasteet

Lisätiedot

Sonera perustaa Helsinkiin Suomen suurimman avoimen datakeskuksen. #SoneraB2D

Sonera perustaa Helsinkiin Suomen suurimman avoimen datakeskuksen. #SoneraB2D Sonera perustaa Helsinkiin Suomen suurimman avoimen datakeskuksen Sonera perustaa Suomen suurimman avoimen datakeskuksen Perustamme Suomen suurimman kaikille yrityksille palveluja tarjoavan datakeskuksen

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

A2: Vuorovaikutus ja viestintä

A2: Vuorovaikutus ja viestintä A2: Vuorovaikutus ja viestintä Vastuuprofessorit: Pirkko Oittinen (koordinoija) Marko Nieminen Tapio Takala Matti Vartiainen A3 moduuleissa Eero Hyvönen (YVJ) Matti A. Hämäläinen (YVJ) Eila Järvenpää (YVJ)

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

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä OHJ-5201 Web-palveluiden toteutustekniikat Kurssisisällöstä Tarja Systä 1 Yleistä Esitietovaatimukset OHJ-1400 Olio-ohjelmoinnin peruskurssi (pakollinen) OHJ-5010 Hajautettujen järjestelmien perusteet

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 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ä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

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

ELO-Seminaari 24.11.2005

ELO-Seminaari 24.11.2005 H E L S I N G I N K A U P P A K O R K E A K O U L U H E L S I N K I S C H O O L O F E C O N O M I C S ELO-Seminaari 24.11.2005 Sami Sarpola, Tutkija Liiketoiminnan teknologian laitos Helsingin kauppakorkeakoulu

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

Uuden sukupolven verkko-oppimisratkaisut 15.2.2012 Jussi Hurskainen

Uuden sukupolven verkko-oppimisratkaisut 15.2.2012 Jussi Hurskainen Uuden sukupolven verkko-oppimisratkaisut 15.2.2012 Jussi Hurskainen Arcusys Oy Toimivan johdon omistama tietotekniikan palveluyritys Perustettu vuonna 2003 Henkilöstö 48 ohjelmistoalan ammattilaista Asiakkaina

Lisätiedot

Tietojärjestelmän osat

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

Järjestelmäarkkitehtuuri (TK081702) Pilvipalvelut. Pilvipalvelut - lähtökohtia

Järjestelmäarkkitehtuuri (TK081702) Pilvipalvelut. Pilvipalvelut - lähtökohtia Järjestelmäarkkitehtuuri (TK081702) Pilvipalvelut Pilvipalvelut Nouseva toteutustekniikka ja trendi Kuluttajat edellä, yritykset perässä Paino sanalla Palvelu Yhtenäisyyksiä vuosikymmenten taakse, sovelletaan

Lisätiedot

Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä

Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä Juha Mykkänen, Irmeli Minkkinen, Assi Pöyölä, Annamari Riekkinen Kuopion yliopisto

Lisätiedot

Joustavat järjestelmät mukautuvat liiketoiminnan tarpeisiin

Joustavat järjestelmät mukautuvat liiketoiminnan tarpeisiin Joustavat järjestelmät mukautuvat liiketoiminnan tarpeisiin Mitä on palvelukeskeinen arkkitehtuuri? Liiketoimintaprosessien muunneltavuus ja optimoitavuus ovat keskeisiä jokaisen yrityksen kilpailukyvyn

Lisätiedot

HELSINKI AREA TESTBED. Martti Mäntylä, HIIT 12.3.2003

HELSINKI AREA TESTBED. Martti Mäntylä, HIIT 12.3.2003 HELSINKI AREA TESTBED Martti Mäntylä, HIIT 12.3.2003 Pääkaupunkiseudun innovaatioympäristö Pääkaupunkiseudulla hyvät lähtökohdat uusien ICTyritysten syntymiseen Innovaatioympäristöä täytyy kehittää edelleen:

Lisätiedot

Taltioni teknisen alustan arviointi

Taltioni teknisen alustan arviointi Taltioni teknisen alustan arviointi Taltioni sidosryhmätilaisuus, 10.1.2012 Jaakko Lähteenmäki, Niilo Saranummi 1/11/2012 2 Selvitystyön kohde Selvitystyö: VTT & Fujitsu Keskeiset vaatimukset Taltioni-palvelulle?

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

Facta palvelimien uusiminen Helsingin kaupunki

Facta palvelimien uusiminen Helsingin kaupunki Facta palvelimien uusiminen Helsingin kaupunki TARJOUS 70214 06.03.2014 Helsingin kaupunki Kiinteistövirasto Anu Soukki PL 2205 00099 Helsingin kaupunki anu.soukki@hel.fi eero.saarinen@hel.fi tea.tikkanen@hel.fi

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit 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ä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

10 SYYTÄ VALITA VISMA JÄRJESTELMÄTOIMITTAJAKSI

10 SYYTÄ VALITA VISMA JÄRJESTELMÄTOIMITTAJAKSI Toiminnanohjaus Taloushallinto HR ja palkanlaskenta CRM asiakkuudenhallinta Konsultointi ja lakipalvelut Hankinta ja perintä 10 SYYTÄ VALITA VISMA JÄRJESTELMÄTOIMITTAJAKSI VISMA SOFTWARE OY Paraskaan ohjelmisto

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

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

TIEKE katsaus. johtava asiantuntija Pertti Lindberg, Energiateollisuus ry

TIEKE katsaus. johtava asiantuntija Pertti Lindberg, Energiateollisuus ry TIEKE katsaus johtava asiantuntija Pertti Lindberg, Energiateollisuus ry 20130911 TIEKE hanke Sähkönjakeluyhtiöiden ja palveluntuottajayhtiöiden tietojärjestelmien yhteensopivuus Energiateollisuus ry hankkeen

Lisätiedot

ORACLE INFORMATION AGE APPLICATIONS ORACLE FUSION MIDDLEWARE ORACLE GRID

ORACLE INFORMATION AGE APPLICATIONS ORACLE FUSION MIDDLEWARE ORACLE GRID ORACLE INFORMATION AGE APPLICATIONS ORACLE FUSION MIDDLEWARE ORACLE GRID Business Process Management (BPM) vihdoinko yhteinen ymmärrys prosesseista liiketoiminnan ja IT:n kesken? Timo Haavisto Ratkaisuarkkitehti

Lisätiedot

Business Oulu. Teollisuus-Forum 29.5.2013. Wisetime Oy:n esittely

Business Oulu. Teollisuus-Forum 29.5.2013. Wisetime Oy:n esittely Business Oulu Teollisuus-Forum 29.5.2013 Wisetime Oy:n esittely Wisetime Oy Wisetime Oy on oululainen v. 1991 perustettu ohjelmistotalo, jonka omat tuotteet, Wise-järjestelmät ja niihin liittyvät tukipalvelut,

Lisätiedot

Organisaation tietojärjestelmät

Organisaation tietojärjestelmät Organisaation tietojärjestelmät Yrityksen tietojenkäsittely neljä pääaluetta perinteiseen tietojenkäsittely, tietoliikenne, toimistoautomaatio ja tuotantoautomaatio 2 Perinteinen tietojenkäsittely Liiketoiminnan

Lisätiedot

J2EE vs..net Olli Sakari

J2EE vs..net Olli Sakari TEEMA-ARTIKKELI J2EE vs..net Olli Sakari J2EE ja.net ovat tietojärjestelmäteknologioita, joiden varaan suuri osa tulevaisuuden tietojärjestelmistä tulee rakentumaan. Molemmat teknologioista tarjoavat välineitä

Lisätiedot

Muutoksen hallinta rakenteisen projektissa. Kari Kovanen Development manager Etteplan Technical Information

Muutoksen hallinta rakenteisen projektissa. Kari Kovanen Development manager Etteplan Technical Information Muutoksen hallinta rakenteisen projektissa Kari Kovanen Development manager Etteplan Technical Information Etteplan Oyj Yksi Pohjoismaiden suurimmista teollisuustekniikan suunnittelu- ja asiantuntijapalveluyrityksistä

Lisätiedot

Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883

Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883 itsmf Finland Conference 2013 TOP10 The Sounds of IT Service Management Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883 #monitoimittajaympäristö

Lisätiedot

Arkkitehtuuri muutosagenttina

Arkkitehtuuri muutosagenttina Arkkitehtuuri muutosagenttina Smarter Processes, Development & Integration Hannu Salminen CTO OP-Pohjola 2013 IBM Corporation Taustaa Nykyinen IT-arkkitehtuuri ja liiketoimintatarpeet eivät kohtaa OP-Pohjolan

Lisätiedot

Hajauta yhdistäen ja yhdistä hajauttaen: Web Services

Hajauta yhdistäen ja yhdistä hajauttaen: Web Services Hajauta yhdistäen ja yhdistä hajauttaen: Web Services Janne Saarela janne.saarela@profium.com 17.12.2002 Tampereen oliopäivät Esityksen sisältö Arvolupaus Johdanto teknologioihin Yhteensopivuuden taso

Lisätiedot

Kohti teollisuuden älykästä palveluliiketoimintaa

Kohti teollisuuden älykästä palveluliiketoimintaa Kohti teollisuuden älykästä palveluliiketoimintaa Miia Martinsuo Tampereen teknillinen yliopisto, Teollisuustalouden laitos 1.9.2015 Puh. 040-8490895 e-mail miia.martinsuo@tut.fi Sisältö Alykäs teollinen

Lisätiedot

Älykästä. kulunvalvontaa. toimii asiakkaan omassa tietoverkossa

Älykästä. kulunvalvontaa. toimii asiakkaan omassa tietoverkossa Älykästä kulunvalvontaa e Acces toimii asiakkaan omassa tietoverkossa Perinteisen kulunvalvonnan seitsemän pullonkaulaa eli miksi useat yritykset eivät ole hankkineet kulunvalvontajärjestelmää? 1. Koska

Lisätiedot

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000 Case TUHTI 17.12.2002 1 TietoEnator 2002 Projektin tunnuslukuja! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999! Otettu tuotantokäyttöön syksyllä 2001! Proof of Concept (5 henkilöä 4 kk) ->

Lisätiedot

Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn

Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn Terveydenhuollon 29. ATK-päivät Jyväskylä 25-27.5.2003 Verkostoitumisen

Lisätiedot

Parempaa liiketoimintaa henkilöstöjohtamisen uusilla välineillä

Parempaa liiketoimintaa henkilöstöjohtamisen uusilla välineillä Parempaa liiketoimintaa henkilöstöjohtamisen uusilla välineillä Sirpa Huuskonen ja Harri Nikander ISS Palvelut ISS Palvelut Oy 12 000 työtekijää Suomessa Siivous Kiinteistön ylläpito Turvallisuuspalvelut

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Ohjelmien automaattisen verifioinnin reunamailla

Ohjelmien automaattisen verifioinnin reunamailla Ohjelmien automaattisen verifioinnin reunamailla Antti Siirtola Tietotekniikan laitos, Perustieteiden korkeakoulu, Aalto-yliopisto, antti.siirtola@aalto.fi Suomalainen Tiedeakatemia, Nuorten akatemiaklubi,

Lisätiedot

Sakari Olli Tieturi OY. SOA - ajattelutapa vai teknologia

Sakari Olli Tieturi OY. SOA - ajattelutapa vai teknologia SOA - ajattelutapa vai teknologia Tieturi OY Sakari Olli FM Ohjelmistoarkkitehtuureiden sekä teknologioiden asiantuntija Tieturi OY Suomen johtava koulutusyritys Konsultointipalveluiden tarjoaja aiheina

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma

KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma Strateginen selvityshanke Eila Niemelä 1 Lähtökohta Selvitys suomalaisen teolllisuuden komponenttipohjaisten ohjelmistojen kehittämisestä ja

Lisätiedot

Tekninen suunnitelma - StatbeatMOBILE

Tekninen suunnitelma - StatbeatMOBILE Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in

Lisätiedot

Tietohallinnon arvo liiketoiminnalle

Tietohallinnon arvo liiketoiminnalle Tietohallinnon arvo liiketoiminnalle Viikko-seminaari 27.9.2007 Lauri Byckling, Deloitte Mitä on arvo Arvon määritelmiä: Hyöty suhteessa hintaan Laatu suhteessa odotuksiin Saatu lisähyöty Tietohallinnon

Lisätiedot

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

Viestinvälitysarkkitehtuurit

Viestinvälitysarkkitehtuurit Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti hajautettuja Komponenttien palveluja ei tiedetä tarkasti etukäteen Komponentteja ja

Lisätiedot

Cisco Unified Computing System -ratkaisun hyödyt EMC- ja VMwareympäristöissä

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

Nykyaikainen IP pohjainen provisiointi operaattorin verkkoon

Nykyaikainen IP pohjainen provisiointi operaattorin verkkoon Nykyaikainen IP pohjainen provisiointi operaattorin verkkoon Palvelun myynti lähtökohdaksi Liiketoimintamallin ja verkon muutos Säästöt verkon kustannuksissa ja asiakaspalvelussa Provisioinnin toteuttaminen

Lisätiedot

Terveydenhuollon Atk-päivät 2009

Terveydenhuollon Atk-päivät 2009 Terveydenhuollon Atk-päivät 2009 26. 27.5.2009, Jyväskylä Mika Kolhinoja Teknologiakonsultti Citrix CCA, Citrix CCEA, Citrix CCSP, Microsoft MCP, Microsoft MCSA, Microsoft MCSE, Microsoft MCTS, Microsoft

Lisätiedot

verkkolasku.fi 2.1.2011

verkkolasku.fi 2.1.2011 palveluna Notebeat Entrepreneur -ohjelmalla hoidat kaikki yrityksesi myynti- ja ostolaskut sähköisesti selainkäyttöliittymässä, sekä siirrät ne kätevästi tilitoimistoon. Säästät heti käyttöönotosta alkaen

Lisätiedot

Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin

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

VISMA TEHOSTAA LIIKETOIMINTAA

VISMA TEHOSTAA LIIKETOIMINTAA VISMA TEHOSTAA LIIKETOIMINTAA -konserni lyhyesti Liikevaihto noin 772 miljoonaa EUR (2012) Liikevaihto kvartaaleittain 2012: Q1/2012 n. 190 milj. EUR Q2/2012 n. 194,4 milj. EUR Q3/2012 n. 180,0 milj. EUR

Lisätiedot

EKSOTE Sähköisen asioinnin seminaari 14.10.2014

EKSOTE Sähköisen asioinnin seminaari 14.10.2014 EKSOTE Sähköisen asioinnin seminaari 14.10.2014 Sähköisen asioinnin mahdollisuudet tulevaisuudessa Sami Säisä Mitä on sähköinen asiointi? Sähköinen Internetissä toimivaa palvelua? Itsepalveluna toteutettavaa

Lisätiedot

ITK130 Ohjelmistojen luonne

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

ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN. Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi

ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN. Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi MISTÄ ALUETIETOJÄRJESTELMÄSSÄ ON KYSYMYS? Asiakkaan tietojen tulisi olla saatavissa vain niiden käyttöön,

Lisätiedot

Pilvi 9.0. Arkkitehtuuri. Esimerkki arkkitehtuurit

Pilvi 9.0. Arkkitehtuuri. Esimerkki arkkitehtuurit Esimerkki arkkitehtuurit Sivu 2/8 Sisällysluettelo 1. Johdanto... 3 1.1. Termejä... 3 2. Web hosting ilman kuormantasausta... 4 3. Web hosting kuormatasaus ja bastion... 5 3.1.... 5 3.2. Kuvaus... 5 4.

Lisätiedot

ERP, joka menestyy muutoksessa

ERP, joka menestyy muutoksessa ERP, joka menestyy muutoksessa Se joustavampi ERP Agresso on toiminnanohjausjärjestelmä, joka tukee dynaamisten organisaatioiden kehitystä nopeasti muuttuvassa ympäristössä. Ohjelmistokehityksen tavoitteena

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

One1 alueelliset lähienergiaratkaisut. Harri Kemppi

One1 alueelliset lähienergiaratkaisut. Harri Kemppi One1 alueelliset lähienergiaratkaisut Harri Kemppi One1 Oy One1 Oy on suomalainen Clean Tech-yritys Toimintamme pohjautuu uusiutuvan energian teknologioiden kehittämiseen ja keskittämiseen lähilämpö/korttelilämpö-tyyppiseksi

Lisätiedot

Yhteisöllinen mallintaminen ja hajautetut mallit Ari Jolma Aalto-yliopisto. Mallinnusseminaari 2011 Lahti. Ari Jolma 1

Yhteisöllinen mallintaminen ja hajautetut mallit Ari Jolma Aalto-yliopisto. Mallinnusseminaari 2011 Lahti. Ari Jolma 1 Yhteisöllinen mallintaminen ja hajautetut mallit Ari Jolma Aalto-yliopisto Mallinnusseminaari 2011 Lahti Ari Jolma 1 Informaatio vs aine Informaatio ei ole kuten aine, sen kopiointi ei maksa juuri mitään

Lisätiedot

Mikko Rotonen on IT-kehitysjohtaja HUS Tietohallinossa ja APOTTI-hankkeen IT-osuuden projektipäällikkö.

Mikko Rotonen on IT-kehitysjohtaja HUS Tietohallinossa ja APOTTI-hankkeen IT-osuuden projektipäällikkö. Mikko Rotonen on IT-kehitysjohtaja HUS Tietohallinossa ja APOTTI-hankkeen IT-osuuden projektipäällikkö. Selviytymistä vai suorituskykyä seminaari 3.9.2012 Sivu 1 Apotti hankekokonaisuuden tavoitteena on

Lisätiedot

Suomalainen pilvimaisema Yhteenveto Liikenne- ja viestintäministeriön selvityksestä 2013

Suomalainen pilvimaisema Yhteenveto Liikenne- ja viestintäministeriön selvityksestä 2013 Suomalainen pilvimaisema Yhteenveto Liikenne- ja viestintäministeriön selvityksestä 2013 Seppo Kalli Digital Media Finland Selvitys Suomalainen pilvimaisema Liikenne- ja viestintäministeriö Julkaisuja

Lisätiedot