Kuntasektorin SOA-teknologialinjaukset
|
|
- Saija Niemi
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 Kuntasektorin SOA-teknologialinjaukset versio 1.0 Laatinut: Tampereen kaupungin kokonaisarkkitehtuurin projektiryhmä
2 2 (56) 1 JOHDANTO PALVELUKESKEISEN ARKKITEHTUURIN YLEISKUVAUS JOHDANTO PALVELUKESKEISEN ARKKITEHTUURIN MÄÄRITELMÄ VAATIMUKSET SOA-PALVELUILLE PALVELUIDEN PITÄÄ OLLA KARKEUSTASOLTAAN ERILAISIA JA TOISISTAAN KOOSTETTAVISSA PALVELULLA PITÄÄ OLLA HYVIN MÄÄRITELLYT JA STANDARDEIHIN NOJAUTUVAT RAJAPINNAT PALVELUIDEN TULEE OLLA LÖYHÄSTI KYTKETTYJÄ PALVELUIDEN TULEE OLLA HELPOSTI HAETTAVISSA PALVELUIDEN TULEE OLLA LIIKETOIMINTALÄHTÖISIÄ PALVELUIDEN TULEE OLLA UUDELLEENKÄYTETTÄVIÄ PALVELUIDEN TULEE OLLA YHTEENTOIMIVIA ERI JÄRJESTELMIEN JA YMPÄRISTÖJEN VÄLILLÄ TEKNOLOGIAT JA PALVELINOHJELMISTOT SOA-TEKNOLOGIAT JA OHJELMISTOTUOTTEET WEB-SOVELLUSPALVELUT Web-sovelluspalveluiden yleiskuvaus WS-I web-sovelluspalvelut PALVELUHAKEMISTOT JA NIIDEN SUHDE KOKONAISARKKITEHTUURIMALLINNUKSEEN LIIKETOIMINTAPROSESSIEN HALLINTA JA PROSESSIMOOTTORIT Yleistä prosessien hallinnasta ja prosessimoottoreista BPEL-prosessien hallintaohjelmistot Prosessimoottorin tuomat hyödyt prosessitoteutuksiin LIIKETOIMINTASÄÄNTÖJEN HALLINTA JA SÄÄNTÖMOOTTORIT PALVELUVÄYLÄT, ESB... 26
3 3 (56) 4.7 MASTER DATA JA SEN HALLINTA (MDM) KÄYTTÖLIITTYMÄT JA PORTAALIT SOA:n suhde käyttöliittymiin Portaalikäyttöliittymät Portaalikäyttöliittymien käyttökohteet kunnissa Portaalipalvelimet MDA SUOSITUKSET SOA-TEKNOLOGIOIDEN HYÖDYNTÄMISESTÄ YLEISIÄ TEKNOLOGIOIDEN KÄYTTÖSUOSITUKSIA OHJEISTUS WEB-SOVELLUSPALVELUIDEN TOTEUTUKSEEN VAIHTOEHTOISET TEKNOLOGIAT JA STANDARDIT HYVIÄ KÄYTÄNTÖJÄ JA ARKKITEHTUURIMALLEJA SOA:N HYÖDYNTÄMISESSÄ INTEGROINTI SOA-YMPÄRISTÖSSÄ TIETOSUOJA JA TIETOTURVA SOA-YMPÄRISTÖSSÄ STANDARDIT LIIKETOIMINTAPROSESSIT BPMN BPEL WS-I BASIC PROFILE STANDARDIT SOAP XML Schema WSDL WEB-SOVELLUSPALVELUHAKEMISTOT UDDI WSIL OBJECT MANAGEMENT GROUP (OMG) STANDARDIT... 48
4 4 (56) UML MOF OCL QVT XMI PORTAALIPALVELIMET WSRP JSR WS-* standardit ja määrittelyt KIRJALLISUUSVIITTEET MUUTOSHISTORIA... 55
5 5 (56) 1 Johdanto KuntaIT on asettanut palvelukeskeisen arkkitehtuurin (SOA) edistämisen yhdeksi tärkeimmäksi tulevaisuuden tavoitteeksi. Tämä dokumentti vastaa mitä palvelukeskeinen arkkitehtuuri tarkoittaa teknologisessa mielessä KuntaIT:lle. Dokumentin päätehtävä on esitellä palvelukeskeiseen arkkitehtuuriin pohjautuvat standardit ja koestetut teknologiat, joiden käyttämistä kuntasektorin IT-hankkeissa suositellaan. Dokumentti sisältää lisäksi käyttöohjeita ja suosituksia näiden teknologioiden hyödyntämisestä palvelukeskeisessä ympäristössä. Tämä dokumentti on osa KuntaIT:n SOA-suosituksia. Tämän dokumentin pohjatietona toimii KuntaIT:n dokumentti SOA:n hyödyntäminen kuntasektorilla [12]. Tämän dokumentin kohderyhminä ovat: Tietojärjestelmähankinnoista ja -kilpailuttamisesta vastaavat tahot Prosessien ja ohjelmistojen toteuttamisesta vastaavat tahot, mm. projektipäälliköt Kokonaisarkkitehtuurin kehittäjät Teknologia-arkkitehtuurin kehittäjät Tietojärjestelmien toimittajat Ohjelmistoarkkitehdit ja kehittäjät Asioita käsitellään dokumentissa syy-seuraus järjestyksessä. Dokumentin alussa määritetään palvelukeskeisen arkkitehtuurin käsite. Tämän jälkeen määritellään vaatimukset palvelukeskeisen ympäristön palveluille, joiden perusteella myöhemmin esiteltävät teknologiat ja standardit on valittu. Tämä vaatimuksista teknologioihin suhde on yksisuuntainen. Valittujen teknologioiden ja standardien käyttäminen ei takaa palveluille asetettujen vaatimusten täyttymistä. Tämän vuoksi teknologialinjauksia tulee aina käsitellä kokonaisuutena, jossa painopiste on teknologiavalintojen perusteissa ja palvelukeskeisen arkkitehtuurin kehittämisessä. Arkkitehtuurin kehittäminen saa puolestaan syötteensä liiketoiminnalta. Lähtökohtana on, että liiketoiminta ohjaa arkkitehtuuria ja arkkitehtuuri teknologioita (ks. kuva 1.1). Liiketoiminta Arkkitehtuuri Teknologiat Kuva 1.1 Liiketoiminnan ohjaava vaikutus
6 6 (56) 2 Palvelukeskeisen arkkitehtuurin yleiskuvaus 2.1 Johdanto Tässä luvussa kuvataan suppeasti palvelukeskeisen arkkitehtuurin käsite. Määritys perustuu SOA:n hyödyntäminen kuntasektorilla [12] dokumenttiin, joka käsittelee asiaa laajemmin. 2.2 Palvelukeskeisen arkkitehtuurin määritelmä KuntaIT käyttää seuraavaa määritelmää palvelukeskeisestä arkkitehtuurista: Palvelukeskeinen arkkitehtuuri (SOA) on joukko suunnitteluperiaatteita, käytäntöjä, menetelmiä, kehyksiä ja tekniikoita, jotka mahdollistavat sovellustoiminnallisuuksien tarjoamisen ja pyytämisen joukkona jaettuja liiketoimintalähtöisiä sovelluspalveluita. SOA muodostaa ajattelutavan asioiden suunnittelemiseksi ja hahmottamiseksi palveluiden kautta. SOA-ympäristössä ohjelmistojen toiminnallisuus ja sovelluslogiikka toteutetaan jaettujen uudelleenkäytettävien palveluiden avulla. Palvelut toimivat toiminnallisuuden ja sovelluslogiikan rakennusosina. Palvelut sisältävät palvelurajapinnan ja niitä kutsutaan tietoverkossa välitettävien viestien välityksellä. SOA nojautuu avoimiin standardeihin ja hajautettujen löyhästi toisiinsa kytkettyjen palveluiden uudelleenkäytölle. SOA lisää liiketoimintalähtöisyyttä, uudelleenkäytettävyyttä, paikka-, alusta- ja toimittajariippumattomuutta sekä tietojärjestelmien yhteentoimivuutta. Palvelukeskeinen arkkitehtuuri nähdään yleensä keskeisenä tekijänä liiketoimintaprosessien kehittämisessä. SOA-palveluiden suhde liiketoimintaprosesseihin on kaksisuuntainen. SOA auttaa prosessien kehittämisessä mahdollistaen joustavat prosessitoteutukset ja prosessien mittaamisen (ks. prosessimoottorin hyödyntäminen prosessien mittaamisessa, alakohta 4.4.2). Prosessit toimivat puolestaan pohjana SOA-palveluiden määrittelyssä. KuntaIT ei SOA-palveluvaatimuksissa edellytä palveluiden etsimistä prosessimäärityksistä, vaan näkee tämän yhtenä keskeisenä toimintatapana SOA-palveluiden liiketoimintalähtöisyyden toteuttamisessa (ks. alakohta 3.5). Merkittävimpinä vaatimuksina liiketoimintalähtöisyyden lisäksi ovat palveluiden koostettavuus, uudelleenkäytettävyys ja toteutustavan näkymättömyys palvelun käyttäjille (ns. musta laatikko). SOA vaikuttaa kaikkiin kokonaisarkkitehtuurin näkökulmiin eikä sitä voida ottaa käyttöön pelkästään yhden näkökulman osalta. Tämä asia jää usein huomiotta esim. SOAteknologiaa toimittavien yritysten viestinnästä. Esim. prosessimoottorit ja palveluväylät kuuluvat usein tärkeänä osana SOA-perustaiseen teknologia-arkkitehtuuriin. Näiden ohjelmistojen hyöty on kuitenkin vähäinen, jollei esim. toiminta-arkkitehtuuri tue palvelukeskeistä ajattelua. SOA ei myöskään määrää yksittäisiä teknologioita tai käytettäviä standardeja, mutta sen asettamat vaatimukset aiheuttavat näihin runsaasti rajauksia. Merkittävimmät rajaukset liittyvät yleensä seuraavassa luvussa käsiteltäviin palveluvaatimuksiin.
7 7 (56) 3 Vaatimukset SOA-palveluille Palvelut toimivat SOA:n keskiössä ja ovat näin järjestelmien toiminnan edellytys. Palvelukeskeisen arkkitehtuurin käyttö ei kuitenkaan määrää käytettäviä standardeja teknologioita. Tämän sijaan SOA asettaa palveluille vaatimuksia, jotka määräävät mitä teknologioita ja standardeja voidaan SOA-ympäristössä käyttää. Seuraavissa alakohdissa on lueteltu vaatimukset SOA-palveluille. Nämä vaatimukset ovat hyvin keskeisiä myöhempien lukujen kannalta. Näitä vaatimuksia voidaan pitää palvelutoteutusten kulmakivinä, joihin myöhempien lukujen teknologiavalinnat ja johtopäätökset nojautuvat. 3.1 Palveluiden pitää olla karkeustasoltaan erilaisia ja toisistaan koostettavissa Palveluiden pitää olla karkeustasoltaan erilaisia eli palveluiden tulee koostua pienemmistä palveluista (ks. kuva 4.4 palvelukerrokset). Tällä mahdollistetaan, että palvelut toteuttavat vaadittavan toiminnallisuuden ja ovat uudelleenkäytettäviä. Ylätason karkeat SOA-palvelut ovat harvoin uudelleenkäytettäviä, koska ne on kehitetty yksittäisten prosessien tai käyttötapausten pohjalta. Yksittäisten käyttö- tai integraatiotarpeiden pohjalta toteutetut ylätason palvelut ovat ongelmallisia myös suorituskyvyn osalta. Palveluiden ei suorituskyvyllisesti pitäisi palauttaa suurta määrää kutsujan kannalta tarpeetonta tietoa, mihin karkean tason palvelujen uudelleenkäyttö helposti johtaa. Myös pelkästään hienojakoisten alatason palveluiden käyttö johtaa huonoon lopputulokseen. Suorituskyvyllisesti ja mahdollisen uudelleenkäytön kannalta ei ole hyvä, että palvelua käyttävä sovellus tekee runsaasti etäpyyntöjä hienorakenteisille palveluille. Lisäksi pelkästään hienojakoisten palveluiden käyttö ei aina takaa sovelluksilta vaadittavaa toiminnallisuutta esim. transaktioiden käsittelyn osalta. Tämän vuoksi palveluiden pitää olla karkeustasoiltaan erilaisia. Tämä vaatimus aiheuttaa monesti haasteita vanhoihin sovelluksiin tehtävien integrointikerroksien kanssa. Integrointipalvelut ovat monesti liian karkeita uudelleenkäytettäväksi, vaikka niitä teknisesti olisikin mahdollista käyttää uudelleen eri tietojärjestelmistä. Vanhoissa järjestelmissä ja niistä johdetuissa palveluissa prosessilogiikka on monesti sisäänrakennettu palveluun. Tämä estää uudelleenkäytön lisäksi esim. prosessimoottorin hyödyntämisen prosessilogiikan hallinnassa. SOA-palveluita tarjoavan integrointikerroksen lisääminen ei siis tee sovelluksesta SOA-ideologian mukaista, jollei integrointikerros itsessään ole toteutettu palvelupohjaisesti. Vaatimus palveluiden koostamisesta mahdollistaa myös helpon tavan uuden toiminnallisuuden lisäämiselle ja muuttamiselle vanhoja palveluita rikkomatta. Prosessimoottoreita hyödyntävät BPEL-prosessit ovat hyvä esimerkki karkeista koostepalvelusta, joiden käyttäminen edellyttää hienompien palveluiden olemassaoloa. Näitä koostepalveluita voidaan edelleen käyttää rakennusosina isommissa koostepalveluissa, esim. toisissa BPELprosesseissa. Palveluiden koostettavuusvaatimus seuraa myös standardointijärjestö W3C:n määrityksiä. W3C edellyttää, että web-sovelluspalveluiden (web service) pitää olla koostettavissa muista web-sovelluspalveluista. Tarkemmin web-sovelluspalveluita on käsitelty kohdassa 4.2.
8 8 (56) Koostettavuudelle on olemassa myös muita tulkintoja. Koostettavuudella voidaan viitata myös esim. palvelurajapintojen suunnittelutapaan, jossa uusia ominaisuuksia voidaan lisätä pienissä erissä olemassa olevaan palveluun muuttamatta nykyistä toiminnallisuutta. Tällöin esim. palvelurajapinnan viestirakenteisiin lisätään uusia osioita uutta toiminnallisuutta varten, samaan aikaan kuitenkin sallien vanhojen laajentamattomien viestirakenteiden ja toiminnallisuuksien käyttämisen samoissa palveluissa. Tämän kaltainen koostettavuus on tärkeä huomioida palveluita suunniteltaessa. Tässä dokumentissa termillä viitataan kuitenkin ensin annettuun määritykseen. 3.2 Palvelulla pitää olla hyvin määritellyt ja standardeihin nojautuvat rajapinnat Palvelurajapinnat kuvaavat palvelun toiminnallisuuden piilottaen kuitenkin toteutukseen liittyvät yksityiskohdat. Tämä abstrakti palvelurajapinta pitää kuvata standardilla ja alustariippumattomalla tavalla, esim. WSDL-standardia (Web Services Description Language) käyttäen. Tämä mahdollistaa avoimuuden ja uudelleenkäytön edistämisen sekä mm. palvelumallien ja tietojen automaattisen viennin kokonaisarkkitehtuuri- ja prosessimallinnusta tukeviin työkaluihin. 3.3 Palveluiden tulee olla löyhästi kytkettyjä Palveluiden tulee olla irrallaan toteutuksesta ja toteutusta pitää pystyä vaihtamaan ilman että palveluiden käyttäjät sitä huomaavat. Tämä mahdollistaa palveluiden joustavan hallinnan, kehityksen ja ylläpidon sekä tekee mahdolliseksi esim. liiketoimintaihmisille muuttaa ohjelmiston toiminnallisuutta (esim. liiketoimintasääntöjä) varsinaista ohjelmistoa muuttamatta ja sen toimintaa keskeyttämättä. Palveluiden tulisi mielellään olla myös asynkronisia ja dokumenttipohjaisia. Esim. WS-I web-sovelluspalveluita käytettäessä mieluummin document- kuin rpc-tyyppisiä. Vaikka synkroninen palvelu ei aina olekaan kytketympi kuin asynkroninen, ovat asynkroniset palvelut luonteeltaan löyhemmin kytkettyjä ja yleensä helpommin esim. palveluväylässä muunnettavia ja ohjattavia. Edelliset vaatimukset edellyttävät, että palvelut pitää voida yhdistää toisiinsa dynaamisesti eli suoriin skripti- tai metodikutsuihin perustuvat palvelurajapinnat eivät ole sallittuja. 3.4 Palveluiden tulee olla helposti haettavissa Palveluiden pitäisi olla potentiaalisten käyttäjien nähtävillä ja haettavissa. Web-service standardit antavat tähän hyvän mahdollisuuden. Yleisimmin käytettyjä tapoja ovat keskitettyyn palveluhakemistoon perustuva UDDI (Universal Description Discovery and Integration) ja dokumentteihin perustuva WSIL. Palveluiden helppo haettavuus edistää uudelleenkäyttöä, ympäristön hallintaa ja innovatiivisuutta mahdollistaen palveluiden käytön ja yhdistelyn etukäteen suunnittelemattomalla tavalla. Uusia innovaatioita voi syntyä esimerkiksi eri organisaatioiden välisiä palveluita tarkastellessa tukemaan organisaatioiden välistä yhteistoimintaa ja mahdollisesti tuomaan uusia lisäarvopalveluita yhteisille asiakkaille.
9 9 (56) 3.5 Palveluiden tulee olla liiketoimintalähtöisiä Palveluiden pitää perustua liiketoimintatavoitteille, ei teknisille yksityiskohdille. Liiketoimintatavoitteet tulisi puolestaan johtaa kunnan strategiasta ja tulevaisuuden visioista, jotka toteuttavat kunnan toiminta-ajatusta ja vaikuttavuustavoitteita. Tämä on palvelukeskeisen arkkitehtuurin ydintavoitteita, jotka toteutuessaan antavat merkittäviä toiminnallisia ja taloudellisia hyötyjä. Käytännössä tämä vaatimus määrittelee etenemisjärjestyksen palveluiden tunnistamiselle ja prosessimallinnukselle. Palveluiden ja prosessien mallinnus on hyvä aloittaa tavoitetilasta ja toiminta-arkkitehtuurista, ei nykytilasta tai teknologiaarkkitehtuurista. Tämä vaatimus on SOA-siirtymän kannalta monesti tärkein ja haasteellisin. Sen toteutumisesta riippuu pääosin kuinka hyvin SOA:n hyödyt ja arkkitehtuurille asetetut tavoitteet toteutuvat. Vaatimuksen sivuvaikutukset tulevat usein myös aliarvioiduiksi. Se edellyttää monesti merkittäviä muutoksia organisaatioiden toimintatapoihin ja vastuujakoihin. Prosessimallinnusta pidetään yleensä keskeisimpänä tekijänä tämän tavoitteen saavuttamisessa. Palvelut olisi hyvä etsiä liiketoimintaprosessien kautta, jolloin palveluiden suhteet liiketoimintaan ovat jäljitettävissä. On kuitenkin tärkeää huomata, ettei pelkkä jäljitettävyys riitä tämän vaatimuksen toteutumiseen, vaan koko palvelusuunnittelun tulee lähteä liiketoiminnasta. Ohjelmistoarkkitehdit pystyvät monesti jäljittämään yksittäisen SOA-palvelun liiketoimintaprosessiin ja voivat tietää tarkasti miten palvelua hyödynnetään liiketoiminnassa. On kuitenkin mahdollista, ettei palvelu ole liiketoimintalähtöinen ja se olisi merkittävästi erilainen, jos se olisi kehitetty liiketoiminnan ehdoilla, esimerkiksi prosessimallinnuksen johdannaisena. Tämä vaatimus toimii keskeisenä yhdistävänä tekijänä SOA:n ja prosessimallinnuksen välillä. 3.6 Palveluiden tulee olla uudelleenkäytettäviä Palveluiden tulee olla uudelleenkäytettäviä. SOA:ssa palvelutoteutusten uudelleenkäyttö tarkoittaa samalla tietopääomien uudelleenkäyttöä. Uudelleenkäytettävyys tuo kustannussäästöjen ohella lukuisia hyötyjä niin ylläpidolle kuin sovelluskehitykselle. Palveluiden uudelleenkäyttö lisää myös ohjelmistojen vakautta lisäämällä tuotannossa jo entuudestaan käytettyjen ja testattujen ohjelmaosien käyttöä. Havaittuja virheitä ei tarvitse myöskään korjata kuin yhteen jaettuun palveluun. SOA-ympäristössä korjaus on mahdollista tehdä dynaamisesti puuttumatta palvelua käyttäviin sovelluksiin. Tämä eroaa merkittävästi esim. jaettujen uudelleenkäytettävien ohjelmakirjastojen käytöstä, jossa virheen korjaus edellyttää jokaisen jaettua kirjastoa käyttävän sovelluksen uudelleenrakentamista ja asentamista. On tärkeää huomata, että tämä vaatimus vaikuttaa myös palveluiden tunnistamiseen ja prosessimallinnukseen. Palveluiden tulisi olla prosessirajat ylittäviä eikä palveluita tule suunnitella pelkästään yhden prosessin näkökulmasta. Vaatimus uudelleenkäytettävyydestä yhdistyy muihin SOA-palveluvaatimuksiin. Palveluiden koostettavuusvaatimus edistää uudelleenkäytettävyyttä. Uudelleenkäytettävyys puolestaan edistää palveluiden helpon haettavuuden kanssa innovatiivisuutta ja organisaatiorajat ylittävää toimintaa. Vaikka palveluiden käyttäminen etukäteen suunnittelemattomalla tavalla tuokin monesti merkittäviä hyötyjä, pitää palveluiden käyttäjistä muistaa pitää kirjaa, jotta esim. palvelinresurssit osataan mitoittaa käytön määrän ja kriittisyyden mukaan. Tähän voidaan hyödyntää mallinnusohjelmistoja, palveluhakemistotuotteita ja standardeja (ks. lisätietoja kohdasta 4.3).
10 10 (56) Vaikka uudelleenkäytettävyys pitää palvelujen tunnistamisessa ja muussa toiminnassa aina huomioida, ei todelliseen uudelleenkäytettävyyteen ole aina mahdollista päästä. Eri organisaatiot hoitavat erilaisia tehtäviä eikä yhteistä toiminnallisuutta tai integrointitarpeita välttämättä esiinny. Tämä on syytä kuitenkin todeta palvelukohtaisesti ja tarkistaa esim. uutta palvelua analysoitaessa löytyykö samaa tehtävää tai vastuuta hoitavia palveluja entuudestaan yhteisestä palveluhakemistosta. 3.7 Palveluiden tulee olla yhteentoimivia eri järjestelmien ja ympäristöjen välillä Palveluiden tulee olla yhteentoimivia eri ympäristössä suoritettavien palveluiden ja sovellusten kanssa. Palveluiden käyttö ei saa olla esim. sidoksissa käyttöjärjestelmään tai ohjelmointikieleen. Merkittävää on huomata, ettei tämä vaatimus toteudu pelkästään teknisiä yksityiskohtia tarkastelemalla, vaan yhteentoimivuus pitää huomioida myös esim. palveluita tunnistettaessa. Esimerkiksi yhteisten tietojen (master data) pitää olla samanrakenteisia yhteentoimivuuden varmistamiseksi. Teknistä yhteentoimivuutta edistetään tukeutumalla avoimiin standardeihin ja yleisesti hyvinä pidettyihin ratkaisuihin. Teknisten linjojen tarkkuus ja konkreettisuus ovat tärkeitä asioita yhteentoimivuuden varmistamiseksi. Standardit voivat olla liian väljiä ja mahdollistavat liialliset rönsyilyt ja vaihtoehtoiset toteutustavat. Esimerkiksi web-sovelluspalvelu (web service) standardeihin nojautuvat ratkaisut voivat olla hyvin hankalasti eri ympäristöistä kutsuttavissa. Tämän vuoksi WS-I -yhteisö tarjoaa profiili-dokumentteja rajaamaan ja tarkentamaan web-sovelluspalveluihin liittyviä perusmäärittelyjä ja niiden yhteiskäyttöä. KuntaIT edellyttää SOA-palveluiden toteutuksissa WS-I basic profile määrittelyyn nojautumista (ks. kohta 4.2.2).
11 11 (56) 4 Teknologiat ja palvelinohjelmistot 4.1 SOA-teknologiat ja ohjelmistotuotteet Liiketoiminta (tavoitteet, strategia) Arkkitehtuuri (SOA) Teknologiat (Websovelluspalvelut) Kuva 4.1 Liiketoiminnan ohjaava vaikutus teknologioihin Palvelukeskeistä arkkitehtuuria tukemaan on kehitetty runsaasti ohjelmistoja, standardeja ja teknologioita. Palvelukeskeinen arkkitehtuuri ei ole kuitenkaan teknologiasidonnainen vaan lähtökohtana on, että arkkitehtuuri ohjaa teknologiavalintoja (ks. kuva 4.1 liiketoiminnan ohjaava vaikutus teknologioihin). Käyttötarpeet ja vaatimukset tarvittaville ohjelmistotuotteille tulevat SOA-palveluvaatimuksista (ks. luku 3) sekä kunnan SOA:n hallinnointiin ja strategiaan liittyvistä määrittelyistä. On hyvä huomata, että monien tuotteiden menestyksekäs hyödyntäminen voi edellyttää merkittäviä muutoksia mm. toimintatapoihin, organisaatioiden rakenteisiin ja vastuujakoihin, mikä puolestaan korostaa SOA-strategian ja kokonaisarkkitehtuurityön tärkeyttä (kokonaisarkkitehtuuria ja sen suhdetta SOA:an on käsitelty tarkemmin dokumentissa SOA:n hyödyntäminen kuntasektorilla [12]). Luvun 3 SOA-palveluvaatimukset asettavat tiukat vaatimukset palveluiden toteutusteknologioille. Näihin vaatimuksiin tällä hetkellä parhaiten vastaa web-sovelluspalveluteknologia (Web Service). Web-sovelluspalveluiden käyttö toimii myös yhtenä tärkeänä valintakriteerinä tuotteiden ja teknologioiden valinnassa. KuntaIT on valinnut seuraavat tuoteryhmät tukemaan palvelukeskeistä arkkitehtuuria. Kokonaisarkkitehtuurin mallintamista tukevat työkalut (tuki Archimate-kielelle suositeltavaa, lisätietoja mallinnuksesta dokumentissa SOA:n hyödyntäminen kuntasektorilla) BPMN-pohjaista prosessimallinnusta tukevat työkalut (ks. BPMN kohta 6.1.1, prosessimallinnuksen ja siihen liittyvän kokonaisarkkitehtuurimallinnuksen välistä suhdetta ja hyötyjä on käsitelty dokumentissa SOA:n hyödyntäminen kuntasektorilla) BPEL-prosessimoottorit (ks. prosessimoottorit kohta 4.4 ja BPEL-standardi kohta 6.1.2) Palveluväyläarkkitehtuuriin (ESB) liittyvät palvelintuotteet (ks. ESB kohta 4.5) Web-sovelluspalveluhakemistot (ks. kohta 6.3) Ajoympäristö WS-I yhteensopiville web-sovelluspalveluille (ks. web-sovelluspalvelut kohta 4.2)
12 12 (56) JSR-168 standardia tukeva portaalipalvelin (ks. portaalikäyttöliittymät kohta 4.8 ja JSR-168 standardi kohta 6.5.2) Tietoturvaohjelmistot kertakirjautumista (SSO), palveluiden käyttöoikeuksien tarkistusta ja valtuuttamista varten Master datan hallinnointituotteet (ks. MDM kohta 4.7) Näiden ohjelmistotuotteiden suhde toisiinsa on esitetty kaaviossa (kuva 4.2). Kaaviossa ohjelmistot on järjestetty ohjelmistoryhmittäin tyypillisen abstraktiotason mukaan (ohjelmistoryhmät vasemmalla). Alaspäin mentäessä abstraktiotaso laskee. On hyvä huomata, että kaavio sisältää myös kaksisuuntaisia suhteita. Tämän vuoksi ohjelmistojen keskinäinen sijainti kaaviossa ei ole täysin yksiselitteinen. Esim. kaksi web-sovelluspalvelua voi viestiä keskenään palveluväylän välityksellä. Tällöin toinen web-sovelluspalveluista lähettää viestin palveluväylälle ja toinen vastaanottaa palveluväylän välittämän viestin. Riippuen siitä, kumman web-sovelluspalvelun näkökulmasta asiaa tarkastelee, voidaan palveluväylä sijoittaa kaaviossa web-sovelluspalvelun ylä- tai alapuolelle. Koska kaavio on järjestetty tyypillisen abstraktiotason mukaan, on kerrosten välisten kutsujen suunta yleensä ylhäältä alaspäin. Kuva 4.2 Teknologiapino Tuoteryhmien ja teknologioiden jäsentely perustuu seuraavan kaavion mukaiseen kerrosjakoon.
13 13 (56) Kuva 4.3 SOA-kerrokset Abstraktiotaso kasvaa ylöspäin noustessa eikä ideaalitapauksessa ylimmällä kerroksella enää edellytetä teknisten yksityiskohtien tietämistä tai ohjelmointia. Nämä kerrokset heijastuvat suoraan palvelukerroksiin ja näiden toteutusmekanismeihin. Palvelukerrokset on esitetty alapuolella (kuva 4.4). Palveluita muodostuu eri projektien ja hankkeiden seurauksena. Alatason palveluiden ei tulisi kuitenkaan olla sidoksissa pelkästään näihin projekteihin, vaan niiden tulisi olla uudelleenkäytettävissä mahdollisimman laajasti. Uudet hankkeet voivat edellyttää myös olemassa olevien palveluiden laajentamista tai uusien palveluiden luomista olemassa olevan tiedon hyödyntämiseksi. Yläkerroksen palvelut koostuvat alemman tason palveluista ja tarjoavat riittävän toiminnallisuuden yksittäisten prosessien ja sovelluskohtaisten käyttötapausten toteuttamiseksi. Näiden palveluiden ei tarvitse olla yhtä uudelleenkäytettäviä kuin alemman tason palveluiden. Ylimmän tason palveluiden olisi suotavaa perustua tehtyihin prosessimalleihin ja palveluiden kooston olla joustavaa. Tyypillisesti prosessipalveluiden elinkaari vastaa liiketoimintaprosessin elinkaarta ja ovat näin kestoltaan pitkäikäisempiä kuin alemman tason palvelut. Lisäksi prosessipalveluiden tulisi tarjota prosessien mittaamiseen ja tehostamiseen riittävät välineet (toteutus esim. näitä ominaisuuksia tarjoavan BPEL-prosessimoottorin avulla).
14 14 (56) Kuva 4.4 Palvelukerrokset 4.2 Web-sovelluspalvelut SOA-palveluvaatimukset (luku 3) asettavat tiukat vaatimukset toteutusteknologioille. Näihin vaatimuksiin parhaiten teknologiapuolella tällä hetkellä vastaavat web-sovelluspalvelut (Web Service). Teknologioilla on kuitenkin taipumus muuttua arkkitehtuureja nopeammin, joten muita toteutusteknologioita on mahdollisesti tarjolla enemmän tulevaisuudessa Web-sovelluspalveluiden yleiskuvaus Web-sovelluspalvelu (Web Service) on joukko sovellustoimintoja, joita voidaan ohjelmallisesti kutsua tietoverkon yli. KuntaIT nojautuu web-sovelluspalvelun määrittelyssä standardointijärjestö W3C:n määritelmään. W3C:n mukaan web-sovelluspalvelu käsite viittaa XMLpohjaisiin SOAP-standardia tiedonvälitykseen käyttäviin asiakas-palvelin palveluihin, joiden rajapinnat on kuvattu ohjelmallisesti tulkittavalla kielellä (esim. WSDL). W3C:n Web Services Architecture dokumentti määrittelee web-sovelluspalvelun seuraavasti: Web Service Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
15 15 (56) Web-sovelluspalvelun tulee olla: Itsenäinen (self-contained). Asiakaspäässä ei tarvita muita ohjelmistoja. Itsensä kuvaava. Koodigeneraattoreita tai erillistä metadatapalvelua ei tarvita palvelun kutsumiseen. Modulaarinen. Monimutkaisemmat ja laajemmat web-sovelluspalvelut voidaan koostaa pienemmistä ja yksinkertaisemmista web-sovelluspalveluista Alustariippumaton. Perustuu avoimille XML-pohjaisille standardeille ja on riippumaton esim. ohjelmointikielestä ja käyttöjärjestelmästä. Nämä vaatimukset ovat pääsääntöisesti samoja kuin SOA-palveluilta yleisesti vaadittavat ominaisuudet, ks. luku 3. On hyvä kuitenkin huomata, että nämä vaatimukset ovat luonteeltaan teknisempiä kuin yleisemmät SOA-palveluvaatimukset ja että SOA-palvelut eivät rajaudu pelkästään web-sovelluspalveluihin. Web-sovelluspalvelun pitää kuitenkin täyttää yleiset SOA-palveluvaatimukset ollakseen SOA-yhteensopiva. Esimerkiksi Java EE ympäristössä käytettävät EJB-komponentit eivät täytä luvun 3 SOA-palveluvaatimuksia (esim. kohtia 3.7 ja 3.2). Mikäli olemassa olevalle EJB-komponentille tehdään websovelluspalvelupohjainen rajapinta täyttää tämä helposti web-sovelluspalvelulta vaadittavat ominaisuudet, mutta voi edelleen rikkoa SOA-palveluvaatimuksia (esim. kohtia 3.1, 3.5 ja 3.6). Web-sovelluspalveluissa käytetään tyypillisesti seuraavia standardeja: SOAP-standardi kuvaa XML-pohjaisen viestikehyksen, jonka avulla tiedot välitetään web-sovelluspalveluille. XML Schema kuvaa SOAP-viesteissä käytetyt tietorakenteet mahdollistaen siirrettävien tietojen tarkan tyypittämisen. WSDL-kieli kuvaa formaalisti web-sovelluspalvelun rajapinnan ja konkreettisen käytön. Konkreettinen osuus sisältää mm. tiedon käytetystä protokollasta ja palvelun sijainnista. WSDL-kielistä dokumenttia kutsutaan myös palvelusopimukseksi. UDDI-standardi määrittelee keskitetyn palveluhakemiston web-sovelluspalveluille. Kolme ensimmäistä standardia ovat W3C-järjestön määrityksiä, UDDI puolestaan OASISjärjestön määrittelemä standardi. Web-sovelluspalveluita voidaan tuottaa alhaalta ylös tai ylhäältä alas periaatteella. Alhaalta ylös periaatteessa web-sovelluspalvelurajapinnat muodostetaan olemassa olevista komponenteista, esim. EJB-komponenteista. Ylhäältä alas periaatteessa määritellään ensin rajapinnat eli muodostetaan palveluiden WSDL-kuvaukset. Nämä kuvaukset määritellään WSDL-dokumentin abstraktissa osiossa eli kuvaukset eivät ota kantaa sijaintiin tai toteutusympäristöön. Näille abstrakteille kuvauksille tehdään myöhemmin toteutukset halutuilla ohjelmointikielillä. Viimeistään asennusvaiheessa määritellään protokollat, sidontatavat ja sijaintitiedot WSDL-dokumentin konkreettiseen osioon. Tätä lähestymistä kutsutaan englanniksi myös contract-first tavaksi. Tämä nimi on varsin osuva, koska pääpaino ja ensimmäiset tehtävät liittyvät palvelusopimuksen määrittelyyn. Ylhäältä alas mallia pidetään yleisesti lopputuloksen kannalta parempana vaihtoehtona, koska tällä tavalla taataan rajapintojen riippumattomuus toteutustavasta. WSDL-
16 16 (56) dokumentissa XML Scheman avulla kuvatut viestirakenteet mahdollistavat yleensä eri ohjelmointikieliä yksityiskohtaisemman rajapintamäärittelyn, mutta eivät taivu kaikkiin ohjelmointikielten tarjoamiin rakenteisiin. Tämän vuoksi olemassa olevasta rajapinnasta voi olla joskus hankala muodostaa web-sovelluspalvelua. Monesti houkutteleva vaihtoehto on generoida web-sovelluspalvelut automaattisesti olemassa olevista rajapinnoista (esim. javarajapinnoista). Tähän tehtävään on runsaasti työkaluja eri valmistajilla, mutta lopputulos on harvoin hyvä. Esim. java-rajapinnat eivät tarjoa riittävästi tietoa hyvän websovelluspalvelurajapinnan muodostamiseksi. Näistä rajapinnoista jäävät puuttumaan esim. merkkijonojen maksimipituudet, numeroiden arvoalueet, elementtien minimi- ja maksimimäärät sekä valinnaisuudet ja korvattavuudet, elementtien tarkat nimet, tekstien tarkat muodot ja tarkemmat tyypitykset (esim. tietotyyppi kuukausi). Osan tiedoista pystyy liittämään web-sovelluspalvelurajapintoja muodostettaessa erillisiin metatietoihin (esim. Javan annotaatiot) mutta suuri osa tiedoista pitää yleensä lisätä WSDL-kuvaukseen. Tämän vuoksi web-sovelluspalvelurajapintoja generoidessa pitää tuotokset aina tarkastaa ja palvelukuvaukset lähes aina tarkentaa käsin WS-I web-sovelluspalvelut Web-sovelluspalveluiden merkittävät hyödyt liittyvät integroitavuuteen ja mahdollisuuteen rakentaa ohjelmistoja palvelukeskeisesti tukeutuen olemassa oleviin palveluihin. Tähän tavoitteeseen pääseminen edellyttää palveluiden yhteiskäyttöisyyttä. Yhteiskäyttöisyys monitoimittajaympäristössä edellyttää puolestaan standardeihin nojautumista. Ensimmäiset web-sovelluspalvelut osoittivat kuitenkin, ettei tämäkään aina riitä. Standardit voivat olla liian väljiä sallien liiat rönsyilyt ja käyttötavat. Standardien toteuttaminen voi olla monesti liian vaikeaa ja työlästä, jos standardit ovat laajoja ja niille löytyy runsaasti laajennuksia. Lopputuloksena on usein, ettei mikään toimittaja tue standardeja kokonaisuudessaan ja eri toimittajat pitävät eri asioita tärkeinä ja valitsevat eri osat tukensa piiriin. Näin kävi ensimmäisten web-sovelluspalveluiden yhteydessä eikä yhteiskäyttöisyyttä saavutettu kuin yksinkertaisimpien palveluiden osalta. Tätä ongelmaa ratkaisemaan perustettiin vuonna 2002 websovelluspalveluiden yhteentoimivuutta ajava järjestö WS-I (Web Services Interoperability Organization). Tähän järjestöön kuuluvat kaikki alan merkittävimmät toimijat, yhteensä n. 200 eri yritystä, mm. BEA, IBM, Oracle, SAP, Microsoft, Sun Microsystems, JBoss, Vignette, Fujitsu, Nokia, IONA, Autodesk, Hewlett-Packard, Cisco, EDS, Vesisign, BT Group, NEC, NTT ja Hitachi. WS-I järjestöllä ei ole omia standardeja, vaan järjestö tarjoaa profiili-dokumentteja, joissa tarkennetaan ja rajataan web-sovelluspalveluihin liittyviä perusmäärittelyjä ja niiden yhteiskäyttöä. Merkittävimmät dokumentit ovat Basic Profile ja tätä laajentavat Attachment Profile ja Simple SOAP Binding Profile, joka eriytettiin omaksi dokumentiksi Basic Profile versiossa 1.1. Basic Security Profile dokumentti on järjestöllä edelleen työn alla. Uusin hyväksytty (final) Basic Profile versio on 1.1. Versiot 1.2 ja 2.0 ovat tällä hetkellä (joulukuu 2008) työn alla. WS-I järjestö on menestyksekkäästi onnistunut lisäämään web-sovelluspalveluiden yhteiskäyttöä monitoimittajaympäristössä. Myös ohjelmistokehitysvälineiden tuki WS-I yhteensopivuudelle on tällä hetkellä hyvä. Suurin osa yleisimpien kehitysvälineiden valmistajista tukee uusimmissa tuotteissaan WS-I yhteensopivien web-sovelluspalveluiden kehitystä. Koska WS-I:n tuomat hyödyt yhteentoimivuudelle ovat todistetusti merkittävät ja kehitystuki hyvä, edellyttää KuntaIT WS-I Basic Profilen noudattamista kaikissa tulevissa web-
17 17 (56) sovelluspalvelutoteutuksissa. Tästä vaatimuksesta poikkeaminen edellyttää erityisen hyviä perusteita, jotka tarkastetaan aina tapauskohtaisesti. Tällä hetkellä suositeltavin versio WS-I Basic Profile yhteensopivuusvaatimukselle on 1.1 (ks. Versio 1.1 suosittelee käyttämään seuraavia versioita web-sovelluspalvelustandardeista: Standardi Versio SOAP 1.1 WSDL 1.1 UDDI 2.0 XML 1.0 XML Schema 1.0 HTTP 1.0 tai 1.1 Näiden standardien versioinnin lisäksi WS-I Basic Profile määrittelee lukuisia rajauksia standardien käytölle. Ennen WS-I Basic Profile määrityksiä merkittäviä yhteensopivuusongelmia oli etenkin viestien sidonnassa. Sidonnalla viitataan tapaan, jolla palvelu liitetään viestiprotokollaan (WS-I palveluissa protokollana aina SOAP). Alla listattuna merkittävimpiä rajoituksia, jotka tulee web-sovelluspalveluiden kehityksessä huomioida. Palveluiden väliseen viestintään tulee käyttää SOAP-viestikehystä (ei esim. WSIFlaajennuksia) SOAP-viestit pitää lähettää käyttäen HTTP(S) protokollaa (ei esim. ftp-protokollaa tai sähköpostia). HTTP-pyynnön metodina pitää käyttää POSTia. SOAP-sidonnassa (binding) ainoat sallitut kombinaatiot ovat RPC/literal ja document/literal. Tästä seuraa myös, että tietotyypit pitää määritellä XML Schemaa käyttäen eikä esim. SOAP-standardin määrittelemien tyyppien käyttö ole sallittua. SOAP-viestit eivät saa sisältää DTD-määrityksiä. Ainoat sallitut merkistöt SOAP-viesteille ja WSDL-kuvauksille ovat UTF-8 ja UTF- 16. Esim. HTML:n oletus merkistön ISO käyttö ei ole sallittua. RPC/literal sidontaa käytettäessä viestiosan (part-elementin) pitää käyttää typeattribuuttia, document/literal sidonnassa puolestaan aina element-attribuuttia. WSDL-kuvauksen sisältämien viestimäärityksien part-osassa käytettävän elementattribuutin pitää viitata juuritasolla määriteltyyn XML Schema elementtiin.
18 18 (56) Document/literal sidontaa käytettäessä WSDL:n viestikuvaukset voivat sisältää enintään yhden part-elementin. SOAP-viestin sisältöosan elementtien pitää olla samassa järjestyksessä kuin vastaavat part-määritykset WSDL-dokumentissa. Tämä koskee siis pelkästään RPC/literal muotoisia kuvauksia, kun huomioidaan aikaisemmat WS-I rajoitukset. SOAP-viestin sisältöosa (body) saa sisältää enintään yhden juurielementin. Tämän vuoksi operaatio voi ottaa vain yhden parametrin, jos viestiosan elementtimääritys ei ole complex-tyyppinen. Tyypillisesti WS-I:n tuomat rajoitteet voidaan parhaiten kiertää käyttämällä document/literal sidontaa wrapped tavalla. Document/literal wrapped on Microsoftin alun perin lanseeraama sidontamalli, josta on muodostunut alalle yleinen käytäntö. Tämä malli on valittu myös oletukseksi JAX-WS määrittelyyn, joka on osana mm. EJB 3.0 ja Java EE määrittelyjä. On kuitenkin hyvä huomioida, että document/literal wrapped ei kuulu lainkaan WS-I Basic Profile määrittelyyn eikä tämä ota wrapped-sidontaan mitään kantaa. Sidontamalli voidaan pitää kuitenkin WS-I yhteensopivana, koska se täyttää WS-I Basic Profilen sisältämät rajoitukset. Document/literal wrapped sidontamalli on laajennus WS-I Basic Profilen document/literal sidonnalle. Se määrittelee, että kaikki operaation parametrit tulee sitoa XML Scheman juurielementtiin, jonka pitää olla samanniminen kuin operaatio, johon parametrit kuuluvat. Tämä mahdollistaa, että SOAP-viestin sisältöosa voidaan validoida WSDL-dokumentin käyttämää XML-schemaa vasten ja operaatio on tunnistettavissa juurielementin nimestä. Jälkimmäinen mahdollistaa sen, että web-sovelluspalvelu voi sisältää useita samantyyppisiä parametreja sisältäviä operaatioita. Huonona puolena tästä on, ettei web-sovelluspalvelu voi koskaan sisältää useita samannimisiä operaatioita. 4.3 Palveluhakemistot ja niiden suhde kokonaisarkkitehtuurimallinnukseen Palvelurekisteri (service registry) ja hakemisto (service repository) ovat ohjelmistotuotteita, joihin tallennetaan tietoja web-sovelluspalveluista. Palvelurekisteri termillä viitataan yleensä UDDI-standardin toteuttavaan hakemistorekisteriin (ks. lisätietoja UDDI:sta 6.3.1) ja palveluhakemistolla laajempia ominaisuuksia tarjoavaan hakemistoratkaisuun. Palvelurekisterin voidaan käsitteellisesti ajatella sisältävän viitteitä ja hakemiston varsinaista tietoa palvelusta. Palvelurekisteri sisältää viittaukset web-sovelluspalveluiden WSDL-muotoisiin rajapintakuvauksiin ja suppeaa metatietoa näiden viitteiden löytämiseen. Palveluhakemistoihin kerätään tietoja SOA-palveluista laajemmin. Koska useat tuotteet sisältävät yhä useammin sekä rekisterin että hakemiston, ei eroa näiden osittain epäselkeiden käsitteiden välillä aina tehdä. Palveluhakemistoon kerätään usein tarkempien palvelukuvausten lisäksi teknistä tietoa. Näitä tietoja voivat olla esim. palvelinalusta, suorituskyky, arvioidut käyttäjämäärät, palvelun kriittisyys jne. Palveluhakemisto auttaa etenkin SOA-infrastruktuurin suunnittelussa ja hallinnassa. Sen avulla voidaan arvioida esim. minkälaisia varmistuksia ja suorituskykyä parantavia ratkaisuja tarvitaan. Palveluiden liiketoimintaan liittyvää tietoa hallinnoidaan kuitenkin yleensä kokonaisarkkitehtuurin mallinnukseen kykenevän mallinnustyökalun avulla. Tämä mahdollistaa SOApalvelutoteutusten jäljittämisen mm. liiketoimintaprosesseihin, käsitteisiin, organisaatioihin
19 19 (56) ja rooleihin. Mallinnustyökalut tarjoavat monesti myös ominaisuuksia websovelluspalveluihin liittyvien mallien automaattiseen luontiin WSDL-kuvausten pohjalta. Vaikka nämä mallit ovat luonteeltaan monesti teknisiä, tarjoaa tämä helpon tavan palvelutoteutusten liittämiseen ylätason malleihin. Näitä liiketoimintaan liittyviä tietoja voidaan joskus tuoda myös palveluhakemistoon, mutta silloin on syytä huolehtia, ettei tietoja tarvitse ylläpitää kahdessa eri paikassa. Kokonaisarkkitehtuurin mallintamista on käsitelty tarkemmin KuntaIT:n dokumenteissa SOA:n hyödyntäminen kuntasektorilla ja Archimatemallinnus. 4.4 Liiketoimintaprosessien hallinta ja prosessimoottorit Yleistä prosessien hallinnasta ja prosessimoottoreista Yksi merkittävimpiä tietotekniikalta odotettavia pitkän aikavälin tavoitteita ovat liiketoimintaprosessien tehostaminen ja laadun parantaminen. Käytännössä tämä tarkoittaa, että tietojärjestelmien tulee elää ja kehittyä liiketoiminnan ehdoilla. Tämä edellyttää tietojärjestelmiltä joustavaa ja nopeaa mukautumista liiketoimintaprosesseihin kohdistuviin muutoksiin ja tukea prosessien mittaamiselle. Tätä haastetta vastaamaan on kehitetty prosessimoottoreita. Prosessimoottori on vastuussa prosessien suorittamisesta prosessimäärittelyjen mukaisesti. SOA-ympäristössä prosessimoottorin tehtävänä on ohjata web-sovelluspalveluita ja tukea palvelukeskeiseen arkkitehtuuriin perustuvan ympäristön kehitystyötä ja prosessikeskeisen toiminnan kehittämistä. Prosessimoottori mahdollistaa graafiseen malliin pohjautuvan prosessitoteutuksen ja tämän toteutuksen joustavan muokkaamisen. Lisäksi se tarjoaa seurantatyökalut prosessin työnkulkujen tehostamiseen ja analysointiin. Prosessimoottorin käyttämä prosessimalli voidaan johtaa ylätason prosessikuvauksista, jotka voidaan puolestaan yhdistää kokonaisarkkitehtuurimalleihin. Tätä asiaa on käsitelty tarkemmin kohdassa 5.4 ja dokumentissa SOA:n hyödyntäminen kuntasektorilla. Prosessimoottorin käyttöä ei pidä nähdä pelkästään teknologia-arkkitehtuuriin kuuluvana asiana, vaan se tulee nähdä ennen kaikkea osana liiketoimintaprosessien kehittämistä ja hallintaa. Prosessimoottori tukee prosessien määrittelyä, laadun mittaamista ja nopeuttaa mittausten perusteella tehtäviä korjaustoimenpiteitä mahdollistaen näin johdetun iteratiivisen prosessikehityksen. Prosessien mallintaminen ja siitä johdettavat toteutukset auttavat myös keskittymään projektien alussa liiketoimintakysymyksiin teknisten kysymysten sijaan. Toiminnan laadun ja teknologisen joustavuuden kehittämisen lisäksi prosessimoottorilla on merkittävä ohjausvaikutus arkkitehtuuriin kehittämiseen. Prosessimoottorin käyttö muokkaa yleensä arkkitehtuuria palvelukeskeisemmäksi. Esim. BPEL-prosessimoottorin käyttö edellyttää SOA-palveluiden ja prosessien kehittämistä ja tukee vahvasti keskitettyä hallintaa ja pitkäikäisten prosessipalveluiden toteuttamista. On tärkeää huomata, että liiketoimintaprosesseihin liittyy monesti useita eri tietojärjestelmiä. Tämän vuoksi liiketoimintaprosessien suoritusta ei ole hyvä liittää osaksi uutta tai olemassa olevaa järjestelmää, vaan tehdä se keskitetysti projekteille ja järjestelmille yhteisen ratkaisun kuten prosessimoottorin kautta. Prosessimoottorin avulla arkkitehtuurista tulee läpinäkyvämpi ja prosessimääritykset ohjaavat hallitusti palveluiden koostoa. Vaikka palveluita voidaan helposti koostaa ilmankin prosessimoottoria, on pitkäikäisten ja työnkulkujen seurannan mahdollistavien prosessipalveluiden kehitystyö ja ylläpito versiopäivityksineen hankalaa ja harvinaista ilman prosessimoottoria. Käytännössä prosessimoottorin käyttö vaikuttaa lähes aina myös ohjelmistoarkkitehtuurin suunnitteluun.
20 20 (56) Prosesseja voidaan hallita ja suorittaa orkestroimalla tai koreografialla. Orkestrointi perustuu malliin, jossa koostamislogiikka ja hallinnointi suoritetaan keskitetysti (ks. kuva 4.5). Koreografia (choreography) perustuu hajautettuun malliin, jossa koostamislogiikalle ja liiketoimintaprosessille ei ole yksittäistä omistajaa eikä hallinnoitsijaa (ks. kuva 4.6). Orkestroinnissa keskitetty liiketoimintaprosessi koordinoi web-sovelluspalveluja, koreografiassa web-sovelluspalveluiden pitää olla itse tietoisia minkä web-sovelluspalveluiden kanssa ne kommunikoivat. Orkestroinnin etuna on, ettei yksittäisten web-sovelluspalveluiden tarvitse tietää muista palveluista eikä niiden tarvitse tietää olevansa osa isompaa kokonaisuutta eli osallistumisesta prosessiin. Koreografiassa web-sovelluspalveluiden pitää olla tietoisia prosessista, oikeista operaatioista, viestimuodoista sekä viestinnän ajoituksesta. Orkestrointia voidaankin verrata kapellimestarin työhön ja koreografiaa esim. tanssiryhmän tekemään yhteistyöhön. Websovelluspalvelu 4 Websovelluspalvelu 3 Orkestroinnin koordinaattori (esim. BPELprosessimoottori) Websovelluspalvelu 1 Websovelluspalvelu 2 Kuva 4.5 Orkestrointi Prosessimoottoreista suurimman käyttäjäkunnan ovat saaneet BPEL-kieltä tukevat ohjelmistot. BPEL-prosessimoottori perustuu orkestrointimalliin ja on parhaiten tuettu kieli eri valimistajien prosessimoottoreissa (ks. lisätietoja BPEL-standardista alakohdasta 6.1.2). Kirjoitushetkellä (joulukuu 2008) kaikki BPEL-kieltä tukevista prosessimoottoreista eivät tue standardoitua 2.0 versiota, mutta lähes kaikki 1.1 versiota tukevat valmistajat ovat luvan- Websovelluspalvelu 4 Websovelluspalvelu 1 Websovelluspalvelu 3 Websovelluspalvelu 2 Kuva 4.6 Koreografia BPEL-prosessien hallintaohjelmistot
21 21 (56) neet tukensa uudelle versiolle (on hyvä huomata, ettei BPEL 2.0 versio ole täysin yhteensopiva vanhempien versioiden kanssa, ks. lisää kohdasta 6.1.2). Alla on listattu yleisimmät BPEL-kieltä tukevat prosessimoottorit valmistajittain ja tuoteperheittäin: Valmistaja Tuoteperhe Prosessimoottori Active Endpoints ActiveVOS ActiveVOS Server IBM IBM SOA Foundation WebSphere Process Server Intalio Intalio BPMS Intalio Server JBOSS JBoss Enterprise Middleware JBoss jbpm BPEL Microsoft - BizTalk Server Oracle Oracle BPM Suite BPM Process Execution Engine (entinen BEA AquaLogic BPM Process Execution Engine) Oracle Oracle SOA Suite ja Oracle BPM Suite - Oracle BPEL Process Manager (mukana molemmissa suitessa) BPEL Server SAP SAP NetWeaver Exhange Infrastructure Integration Server QPR - QPR WorkFlow Server BPEL-prosessimoottori toimii ajoalustana BPEL-kielellä kuvatulle prosessille. BPEL tarjoaa standardin ja toimittajariippumaton tavan kuvata liiketoimintaprosesseja ja niiden työnkulkuja. BPEL-prosessi voi olla joko abstrakti tai suoritettava. Suoritettava BPEL-prosessi on aina web-sovelluspalvelu (ks. kohta 4.2), joka koostuu muista web-sovelluspalveluista. Suoritettava BPEL-kielinen liiketoimintaprosessi on siis koostettu web-sovelluspalvelu, josta käytetään myös nimitystä komposiittipalvelu (ks. SOA vaatimus palveluiden koostamiselle, kohta 3.1). Koska BPEL-prosessi on web-sovelluspalvelu, edellyttää BPEL-prosessin suoritus web-sovelluspalvelukutsua. BPEL-kielellä toteutettu komposiittipalvelu sisältää liiketoi-
22 22 (56) mintalogiikan, jonka perusteella se kutsuu muita web-sovelluspalveluita. Liiketoimintalogiikka voidaan halutessa myös ulkoistaa erilliseen web-sovelluspalveluun, jota komposiittipalvelu kutsuu. BPEL-palvelun vastuulla on myös rinnakkaisuuden ja virhetilanteiden käsittely. Yleensä monimutkaisemmat päättelysäännöt ja laskukaavat ulkoistetaan erilliselle sääntökoneelle, jota BPEL-palvelu kutsuu päätöstä tai laskemista tehtäessä. Sääntökone voi tarjota esim. web-liittymän säännön hallintaan ja sitä voidaan yleensä muuttaa ilman ohjelmointityötä. Erilliset sääntökoneet mahdollistavat säännön helpon muuttamisen lisäksi esim. säännön graafisen mallintamisen tai muita kaavan syöttämistä, kuvaamista ja testaamista helpottavia ominaisuuksia (ks. sääntömoottoreita käsittelevä kohta 4.5). Prosessien hallintaohjelmistot sisältävät BPEL-prosessimoottorin lisäksi yleensä välineet prosessin valvontaan ja hallintaan. Lisäksi ne voivat sisältää apuvälineitä manuaalisten, ihmistyötä vaativien, työnkulkujen toteuttamiseksi. Monesti ohjelmistot sisältävät myös integrointi-adaptereja, joilla helpotetaan esim. tietokanta- ja sanomajonointegrointeja. Yhtenä toimintamallina on, että työkalu generoi palvelun, jota BPEL-prosessi kutsuu integrointitehtävän suorittamiseksi. BPEL-kielisen kuvauksen näkökulmasta generoitu palvelu ei eroa muista kutsuttavista web-sovelluspalveluista. Prosessien hallintaohjelmistoihin liittyvät keskeisesti prosessien graafiset mallinnustyövälineet. Prosessien mallinnus- ja suunnittelutyökalu on yleensä prosessimoottorista irrallinen ohjelma, jolla prosessimoottoriin asennettava BPEL-kielinen prosessi suunnitellaan ja toteutetaan. BPEL-malleista käytetään usein myös nimitystä tekninen malli, koska BPELmalli sisältää lähes aina teknisiä yksityiskohtia, jotka ovat liiketoiminnan näkökulmasta tarpeettomia. Mallinnustyökalu sisältää yleensä prosessimoottorikohtaisia avusteita ja lisäominaisuuksia, minkä vuoksi lähes jokaisella prosessimoottorivalmistajalla on tarjolla oma mallinnustyökalu. Näitä lisäominaisuuksia voivat olla esim. tuki prosessin asentamiselle prosessimoottoriin, virheiden jäljitystoiminnot, mallin validointi ja raportointi, tukitoiminnot valmistajan muihin tuotteisiin (esim. sääntömoottori ja BAM), prosessimallin simulointi ja mittarien asettaminen prosessin eri vaiheille. Prosessien seurantaan suunnatuista ohjelmistoista käytetään usein nimitystä BAM (Business Activity Monitoring). BAM on alun perin Gartnerin lanseeraama termi, jolla viitataan yleisesti, liiketoimintaprosesseja laajemmin, liiketoimintaan liittyvien aktiviteettien reaaliaikaiseen seurantaan. Prosessimoottorivalmistajat tarjoavat yleensä yksinkertaisia seurantaominaisuuksia ilmaiseksi prosessien hallinta- ja ylläpitotyökalujen yhteydessä ja paketoivat laajemmat seuranta- ja analysointityökalut erikseen asennettaviin ja hinnoiteltuihin BAMtuotteisiin. Joillakin valmistajilla laajemmat BAM-ominaisuudet kuuluvat suoraan prosessimoottorituotteeseen. BAM-työkalut perustuvat lähes aina tapahtumien käsittelyyn ja analysointiin. Prosessin suorittamille tehtäville asetetaan tyypillisesti erilaisia mittareita mallinnustyökalun avulla. Prosessimoottorin suorittamista toimenpiteistä ja asetetuista mittareista syntyy prosessin suorituksen aikana tapahtumatietoja, joita BAM-työkalujen avulla analysoidaan. Prosesseista voidaan analysoida esim. suoritusaikoja, pullonkauloja ja tyypillisiä työnkulkuja. Sillä voidaan tunnistaa ongelmakohtien lisäksi esim. mitä reittejä pitkin prosesseissa harvemmin kuljetaan ja mitkä resurssit ovat mahdollisesti yli- tai alikäytössä. BAMtyökalut tarjoavat tyypillisesti graafisia raportointi- ja mittarinäkymiä. Raportointiominaisuudet tukevat usein tapahtumatietoon pohjautuvia laskutoimituksia ja koosteoperaatioita (esim. keskiarvo). BAM-ohjelmat mahdollistavat usein myös hälytysrajojen ja -sääntöjen asettamisen ja niiden pohjalta tuotettavat hälytykset.
23 23 (56) BPEL-prosessit voivat olla joko synkronisia tai asynkronisia ja ne voivat kutsua joko synkronisia tai asynkronisia web-sovelluspalveluita. Merkittävänä erona BPEL-palvelulla on tyypilliseen web-sovelluspalveluun verrattuna niiden pitkäkestoisuus ja tilan säilyminen. BPELprosessi voi kutsua esim. sovelluksen X web-sovelluspalvelua asynkronisesti ja jäädä odottamaan, että sovellus X välittää prosessille tiedot kutsumalla BPEL-prosessin palvelurajapintaa. Sovellus X voi pyytää käyttäjältä tietoja esim. portaalin välityksellä ja kutsua BPELprosessia vasta useiden päivien kuluttua (ks. kuva 4.7, esimerkissä portletti ja websovelluspalvelu viestivät yhteisen tietokannan välityksellä). Prosessimoottori voi virhetilannetta varten tai palvelinresursseja säästääkseen tallentaa prosessin väliaikaisesti tietokantaan (dehydration). Esim. sovellus X:n kutsuttua prosessin palvelurajapintaa, palvelupyyntöä odottamaan jäänyt prosessimoottori hakee kannasta prosessi-instanssin ja jatkaa prosessin suoritusta tallennusta edeltävästä tilasta (hydration). BPEL-prosessimoottori Sovellus X BPEL-prosessi SOAP/HTTP Websovelluspalvelu Websovelluspalvelurajapinta SOAP/HTTP Sovelluskomponentti (esim. websovelluspalvelu) Tietokanta Portletti HTTP Kuva 4.7 Prosessimoottorin käyttöesimerkki Prosessimoottorin tuomat hyödyt prosessitoteutuksiin Merkittävimpiä hyötyjä prosessimoottorin käytöstä verrattuna prosessien työnkulkujen toteuttamiseen ohjelmoimalla ovat: Prosessimoottori ohjaa ja osittain pakottaa arkkitehtuuria palvelukeskeiseksi. Toteutuneesta arkkitehtuurista tulee läpinäkyvämpi ja SOA-vaatimuksia on vaikeampi kiertää.
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ätiedotTiedonsiirto- ja rajapintastandardit
Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen
LisätiedotEnterprise SOA. Nyt. Systeemi-integraattorin näkökulma
Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia
LisätiedotWeb-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k
1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.
LisätiedotJä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ätiedotOppijan palvelukokonaisuus. Tietomallinnuksen laaja katselmointi 7.12.2011
Oppijan palvelukokonaisuus Tietomallinnuksen laaja katselmointi 7.12.2011 Sisältö Tietoarkkitehtuuri Tietomallit ja sanastot Tietomallinnus Tietomallinnus hankkeessa (Hankkeessa käytetyt keskeisimmät mallinnuselementit)
LisätiedotIoT-järjestelmän ja ulkovalaistuksen ohjauksen hankinta -markkinavuoropuhelutilaisuus
IoT-järjestelmän ja ulkovalaistuksen ohjauksen hankinta -markkinavuoropuhelutilaisuus Teknologia-arkkitehtuuri ja rajapinnat/integraatiot 21.3.2019 Sisältö Alustojen asemoituminen ja pilvivalmius Arkkitehtuuriperiaatteet
LisätiedotHSMT J2EE & EJB & SOAP &...
HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista
LisätiedotSisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta
Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
LisätiedotJ2EE 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ätiedotHOJ J2EE & EJB & SOAP &...
HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista
LisätiedotKari 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ätiedotWeb-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ätiedotIntegrointi. 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ätiedotMaster data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011
Lisätieto 15.2.2011 Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa
LisätiedotKä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ätiedotHarri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy
Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Oracle10 g Web Services Sisältö Service Oriented Architecture (SOA) Web Services Service Oriented Architecture Service Oriented
LisätiedotPerustA - Perustietovarantojen viitearkkitehtuuri. Liite 3: Tietojärjestelmäarkkitehtuurin. integraatioarkkitehtuuri
1 (9) PerustA - Perustietovarantojen viitearkkitehtuuri Liite 3: Tietojärjestelmäarkkitehtuurin looginen jäsennys ja integraatioarkkitehtuuri 2 (9) Sisältö 1 TIETOJÄRJESTELMÄARKKITEHTUURIN LOOGINEN JÄSENNYS
LisätiedotAvoimen 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ätiedotMalliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki
Malliperustainen ohjelmistokehitys - MDE 25.9.2007 Pasi Lehtimäki MDE Miksi MDE? Mitä on MDE? MDA, mallit, mallimuunnokset Ohjelmistoja Eclipse, MetaCase Mitä jatkossa? Akronyymiviidakko MDE, MDA, MDD,
LisätiedotJä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ätiedotJärjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri
Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio
LisätiedotIntegraatiotekniikan 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ätiedotOHJ-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ätiedotValtionhallinnon arkkitehtuurin kehittäminen
arkkitehtuurin kehittäminen Kehittämisohjelman esittely RASKE2-seminaari 16.5.2006 neuvotteleva virkamies Aki Siponen Valtion IT-toiminnan johtamisyksikkö arkkitehtuurin kehittäminen Arkkitehtuurista ja
LisätiedotLiiketoimintajärjestelmien integrointi
Liiketoimintajärjestelmien integrointi Vierailuluento 12.12.2016 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application
LisätiedotKäyttövaltuushallinnan hyödyt tehokkaasti käyttöön. Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland
Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland 1 Sisältö Skaalautuva pilvipalvelu Käyttövaltuushallinnan käyttöönotto palveluna
LisätiedotTenttikysymykset. + 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ätiedotPortaaliteknologiat mahdollistavat ajattelutavan muutoksen
- 1 - Portaaliteknologiat mahdollistavat ajattelutavan muutoksen Petri Kanerva Fusion Middleware Architect, Oracle Finland Oy 29.04.2010 The following is intended to outline our general
LisätiedotJHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa
JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi
LisätiedotLiiketoimintajärjestelmien integrointi
Liiketoimintajärjestelmien integrointi Vierailuluento 2.3.2015 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application
LisätiedotORACLE 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ätiedotJä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ätiedotKokonais-IS-arkkitehtuuri korkeakouluissa Tietohallinnon näkökulma
Kokonais-IS-arkkitehtuuri korkeakouluissa Tietohallinnon näkökulma FT, tietohallintopäällikkö Seinäjoen ammattikorkeakoulu Jaakko.Riihimaa@seamk.fi GSM 040-8304104 Kokonaisarkkitehtuurimalli: yleishavaintoja
Lisätiedot11.10.2013 Tekijän nimi
11.10.2013 Tekijän nimi Arkkitehtuuri kehittämisen välineenä Kokonaisarkkitehtuuri hallitun muutoksen avaimena Etelä-Savon maakuntaliitto 10.10.2013 Markku Nenonen Tutkijayliopettaja Mikkelin ammattikorkeakoulu
LisätiedotAlkuraportti. 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ätiedotVaivattomasti parasta tietoturvaa
Vaivattomasti parasta tietoturvaa BUSINESS SUITE Tietoturvan valinta voi olla myös helppoa Yrityksen tietoturvan valinta voi olla vaikeaa loputtomien vaihtoehtojen suossa tarpomista. F-Secure Business
LisätiedotJärjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet
Järjestelmäarkkitehtuuri (TK081702) Ympäristö Muutostarpeet ja niihin vastaaminen Yritysarkkitehtuuri Liiketoiminta-arkkitehtuuri Tavoitteet, Palvelut, Prosessit Informaatioarkkitehtuuri Tietotarpeet,
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite
LisätiedotSOA & Ajax Sanahelinää vai toimivaa käytäntöä sähköisessä asioinnissa? Fenix hankejohtaja Harri Juuti Projektipäällikkö Teemu Karvonen
SOA & Ajax Sanahelinää vai toimivaa käytäntöä sähköisessä asioinnissa? Fenix hankejohtaja Harri Juuti Projektipäällikkö Teemu Karvonen Agenda Fenix-hankkeen esittely Arkkitehtuuri lyhyesti Kuntalaistili
LisätiedotTietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
LisätiedotTenttikysymykset. + 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ätiedotAvoimen ja yhteisen rajapinnan hallintamalli
Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)
LisätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
LisätiedotArkkitehtuuri 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ätiedotwww.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ätiedotArkkitehtuurikuvaus. 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ätiedotFiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen
FiSMA 1.1 Monikerrosarkkitehtuuri 1 (7) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen
LisätiedotSuomen avoimien tietojärjestelmien keskus COSS ry
Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet
LisätiedotAvoimen lähdekoodin ohjelmistot julkisessa hallinnossa
Avoimen lähdekoodin ohjelmistot julkisessa hallinnossa Ohjelmistotuotteen hallinta ja hallinnointi 22.4.2015 Mikael Vakkari, neuvotteleva virkamies. VM Strategisten linjausten perusteemat Avoimuus Hallinto,
LisätiedotSUOMEN KUNTALIITTO RY
Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet...
LisätiedotToimintaympäristön kuvaus. LTC-Otso Myyjän työkalu (POC)
LTC-Otso Myyjän työkalu (POC) Toimintaympäristön kuvaus 21 toukokuu, 2015 Sisältö 1 Johdanto... 3 1.1 Dokumentin tavoite... 3 1.2 Dokumentin yleiskuvaus... 3 2 Järjestelmälle asetetut vaatimukset... 3
LisätiedotHajauta 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ätiedotOsittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit
LisätiedotRistiinopiskelun kehittäminen -hanke
Joustavia opiskelumahdollisuuksia tuetusti Exam-kevätpäivät (31.5.2018) Joustavia opiskelumahdollisuuksia tuetusti Hanke on opetus- ja kulttuuriministeriön rahoittama korkeakoulujen kehittämishanke. Tukea
LisätiedotYhteentoimivuutta edistävien työkalujen kehittäminen
Yhteentoimivuutta edistävien työkalujen kehittäminen Semantiikkaa organisaatioiden välisen tiedonvaihdon helpottamiseksi Mikael af Hällström, Verohallinto Esityksen sisältö Taustatekijöitä (OKM:n hallinnonala,
LisätiedotTIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely
Lyhyt UML-opas UML -pikaesittely UML, Unified Modeling Language Standardoitu, yleiskäyttöinen mallinnuskieli, jota ylläpitää/hallitsee (Object Management Group) OMG Historiaa: 90-luvulla oli paljon kilpailevia
LisätiedotYhteentoimivuutta kokonaisarkkitehtuurilla
Yhteentoimivuutta kokonaisarkkitehtuurilla Terveydenhuollon atk-päivät 20.5.2014 Juha Rannanheimo Ratkaisupäällikkö, sosiaali- ja terveydenhuollon ratkaisut Esityksen sisältö Kehittämisvaatimukset sosiaali-
LisätiedotKeskitetyn integraatiotoiminnon hyödyt
Keskitetyn integraatiotoiminnon hyödyt Janne Kangasluoma / Chief Enterprise Architect, Ilmarinen Teemu O. Virtanen / Director, Information Logistics, Digia 2013 IBM Corporation HUOLEHDIMME NOIN 900 000
LisätiedotSosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous
Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous 12.6.2015 Pasi Oksanen 1 Tavoite ja lähtökohdat Tavoitteena aikaansaada Varsinais-Suomen
LisätiedotTenttikysymykset. + 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ätiedotHieman lisää malleista ja niiden hyödyntämisestä
Hieman lisää malleista ja niiden hyödyntämisestä Ohjelmistojen mallintaminen Kesä 2012 (Avoin yliopisto) Toni Ruokolainen, 23.8.2012 Mallit Mallit ovat todellisuuden abstraktioita, jotka on muodostettu
LisätiedotSOA SIG SOA Tuotetoimittajan näkökulma
SOA SIG SOA Tuotetoimittajan näkökulma 12.11.2007 Kimmo Kaskikallio IT Architect Sisältö IBM SOA Palveluiden elinkaarimalli IBM Tuotteet elinkaarimallin tukena Palvelukeskeinen arkkitehtuuri (SOA) Eri
LisätiedotUutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3
Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2
LisätiedotPeppi - Koulutuksen suunnittelijan ja opettajan palvelut. Tekninen vaatimusmäärittely
Peppi - Koulutuksen suunnittelijan ja opettajan palvelut Versiohistoria Versio Päiväys Tekijä Selite 0.1 9.12.2010 Jaakko Rannila Runko 0.2 13.12.2010 Projektiryhmä 1. päivän tuotos 0.3 14.12.2010 Projektiryhmä
LisätiedotTampereen kaupungin paikkatietostrategia 2013 2015. Tampereen kaupunki
Tampereen kaupungin paikkatietostrategia 2013 2015 Tampereen kaupunki 28.3.2013 TAMPERE Tampereen kaupungin paikkatietostrategia 1 PAIKKATIETO JA PAIKKATIETOINFRASTRUKTUURI KÄSITTEENÄ Paikkatiedolla tarkoitetaan
LisätiedotOhjelmistojen mallintaminen
Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta
LisätiedotJärjestelmäarkkitehtuuri (TK081702) 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ätiedotTeliaSonera 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ätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti
LisätiedotToiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen
Vaatimusluettelo versio 0.17 Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Yleiset vaatimukset 1 Koodistopalvelujärjestelmä on selainkäyttöinen 2 Käyttöliittymän tulee
LisätiedotConcurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo
Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...
LisätiedotPä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ätiedotVisma Software Oy
pidättää itsellään oikeuden mahdollisiin parannuksiin ja/tai muutoksiin tässä oppaassa ja/tai ohjelmassa ilman eri ilmoitusta. Oppaan ja siihen liittyvän muun materiaalin kopiointi on kielletty ilman :n
LisätiedotJHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen
JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys
LisätiedotVisma Nova Webservice Versio 1.1 /
Visma Nova Webservice Versio 1.1 / 31.10.2018 pidättää itsellään oikeuden mahdollisiin parannuksiin ja/tai muutoksiin tässä oppaassa ja/tai ohjelmassa ilman eri ilmoitusta. Oppaan ja siihen liittyvän muun
Lisätiedot<Insert Picture Here> SOA-rakentajan ensimmäiset askeleet avoimien standardien hyödyntämiseen
SOA-rakentajan ensimmäiset askeleet avoimien standardien hyödyntämiseen Heikki Mattsson Konsultointipäällikkö Agenda Prosessien elinkaari (BPM) SOA palvelukeskeinen sovelluskehitys
LisätiedotUNA PoC-yhteenveto CGI Aino Virtanen
UNA PoC-yhteenveto CGI 4.10.2017 Aino Virtanen PoC-toteutusten vastuulliset toimittajat/asiakasorganisaatiot sekä sisällölliset painopisteet Mitä PoC sisälsi PoC-toiminnallisuus - hahmoteltiin UNA:n modulaarista
LisätiedotProsessien 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ätiedotAlkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS Ti Kandidaatintyö ja seminaari
LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS Ti5004000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 4.6.2007,
LisätiedotJHS-jaoston toiminta ja tavoitteet. JUHTA:n syysseminaari Kuntatalolla
JHS-jaoston toiminta ja tavoitteet JUHTA:n syysseminaari Kuntatalolla 19.9.2013 Toiminnan tavoitteiden ja painopisteiden määrittely Keinot JHS Tavoite Mitä ja minkälaisia suosituksia tavoitteiden toteutumisen
LisätiedotJHS-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ätiedotTaltioni 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ätiedotWeb sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin
TEKNILLINEN KORKEAKOULU / VAASAN YLIOPISTO Diplomityöesitelmä Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin Timo Ahola 2006 Web sovellus Web palvelut joiden avulla laite voidaan liittää
LisätiedotAjankohtaisia SOA tutkimusteemoja
Ajankohtaisia SOA tutkimusteemoja Paavo Kotinurmi Ohjelmistoliiketoiminnan ja -tuotannon laboratorio Sisältö Miten integraatiostandardit pohjana SOA-palveluille? Mitä on semanttinen SOA ja mitä SOAn haasteita
LisätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotTyökalujen merkitys mittaamisessa
Työkalujen merkitys mittaamisessa Mittaaminen ja Ohjelmistotuotanto -seminaari Toni Sandelin 18.4.2001, VTT Elektroniikka, Oulu 1 Sisältö Mihin työkalutukea tarvitaan? Työkalut & metriikat: luokitus Mittausohjelmien
Lisätiedotsertifikaattiratkaisu Apitamopki
Ilmoitin.fi - tunnistamisen sertifikaattiratkaisu Apitamopki Web Services -rajapinnan muutokset Verohallinnon ja ohjelmistotalojen yhteistyöpäivä 23.5.2019 Esityksen sisällöstä Muutama sana varmenteista
LisätiedotMetropolian tietojärjestelmäarkkitehtuuri. Nykytilan selvitys & esitys tulevaisuuden arkkitehtuurista
Metropolian tietojärjestelmäarkkitehtuuri Nykytilan selvitys & esitys tulevaisuuden arkkitehtuurista 8.9.2009 2.11.2009 Jaakko Rannila, projektipäällikkö, Metropolia ammattikorkeakoulu Eero Manninen, Java
Lisätiedotin condition monitoring
Etäteknologioiden automaatiosovellukset Using e-speak e in condition monitoring tutkija professori Hannu Koivisto Sisältö Tausta Globaali kunnonvalvontajärjestelmä E-speak globaalissa kunnonvalvontajärjestelmässä
LisätiedotKiila-viitearkkitehtuuri. Jani Harju,
Kiila-viitearkkitehtuuri Jani Harju, 8.4.2015 Käytetty arkkitehtuurimalli Arkkitehtuurimalliksi valittiin Kartturi-malli Jatkokehitetty JHS-179:stä Kartturi-mallia on käytetty mm. VAKAVA:ssa sekä Etelä-Suomen
LisätiedotPalvelut yritysarkkitehtuurin keskiössä: OP-Pohjola-ryhmän matkakokemuksia
SOA sig syysseminaari 2008: EA ja SOA Palvelut yritysarkkitehtuurin keskiössä: OP-Pohjola-ryhmän matkakokemuksia Alustus keskustelulle 12.11.2008 Jouni Lähteenmäki Yritysarkkitehti, OP-Keskus Alustuksen
LisätiedotVaatimusmää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ätiedotTietojärjestelmäarkkitehtuurit
Tietojärjestelmäarkkitehtuurit ITK130 Johdatus ohjelmistotekniikkaan Syksy 2003 Sami Kollanus 1 Aluksi Tietojärjestelmäarkkitehtuurit vs. ohjelmistoarkkitehtuurit Pohjana Tietojärjestelmäarkkitehtuurit
Lisätiedot4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa
4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat
LisätiedotTietojärjestelmät muutoksessa: Alueiden ja kuntien sote - kokonaisarkkitehtuurityö
Tietojärjestelmät muutoksessa: Alueiden ja kuntien sote - kokonaisarkkitehtuurityö Kuntamarkkinat 11.9.2014 Juha Rannanheimo Ratkaisupäällikkö, sosiaali- ja terveydenhuollon ratkaisut + Kuntaliiton toimeksiannosta
LisätiedotAVOIMEN 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