SOA ja integrointimallit - yhteentoimivuuden paikalliset pelisäännöt

1. IT-arkkitehtuuri 20.11.2007 Helsinki SOA ja integrointimallit - yhteentoimivuuden paikalliset pelisäännöt Juha Mykkänen tutkijatohtori Kuopion yliopisto HIS-tutkimusyksikkö

2. tämän esityksen asiat pohjautuvat pääosin • soveltavaan tutkimukseen v. 2000-2007 • useita hankkeita terveydenhuollon toimialalla, 20+ yritystä ja käyttäjäorganisaatiota • komponenttipohjainen sovellustuotanto  • sovellusintegraatio  • palveluarkkitehtuuri (ja sen toimialastandardoinnin käynnistyminen) • SerAPI-hankkeen tuloksiin • www.serapi.fi • Specification of Reusable integration solutions for Health Information Systems -väitöskirjaan, Kuopion yliopisto, 2007 • julkaisuihin integroinnin suunnittelupäätöksistä, standardeista, määrittelymenetelmistä ja monenvälisistä integrointihankkeista • esiintyjän työhistoriaan: ohjelmistokehittäjä  välinekehittäjä  tutkija (IT-arkkitehtuuri)  standardoija  hallintoleimasin

3. esityksen sisältö • yhteentoimivuus • …palveluarkkitehtuurissa • integroinnin keskeiset suunnittelupäätökset • SOA-palvelut + muut integrointiratkaisut • palvelualustojen vaikutukset • esimerkki • miten välttyä rajapintaspagetilta? • tahallisen yksisilmäinen (integraatio) näkökulma palveluarkkitehtuuriin • monet tärkeät seikat (liiketoiminnan mallinnus, hallinta, hyötyjen mittaaminen jne.) jätetään vähemmälle

4. miten välttyä rajapintaspagetilta?

5. vastaus: • vakioi

6. tarkennettu vastaus: • vakioi siten, että useimman tyyppisiin integrointitarpeisiin löytyy paikallinen sabluuna • (= valmis pohja 1. integrointimalleihin 2. -tasoihin ja 3. muihin keskeisiin integroinnin suunnittelupäätöksiin) • sovellusinfrassa (arkkitehtuuritasolla) • kyettävä vastaamaan eri tyyppisiin integrointitarpeisiin • siis vakioi käyttäjäintegraatio, tietointegraation 2-4 ratkaisumallia, prosessi-integraatio, määrittele toiminnallisten palvelujen tyypit • tietojen osalta AINA semantiikka!! • standardeilla usein järkevää vakioida myös toiminnallisia ja teknisiä liittymiä • tekninen infrastruktuuri ja elinkaarimallit • vakioinnilla lähinnä markkina-, ylläpito- ja osaamishyötyjä • ESB:llä joustavuus- ja ketteryys-hyötyjä • yksi ratkaisu / malli ei sovi kaikkeen! • mutta yksi ratkaisu / malli voi kuvitella tietävänsä kaiken

7. yhteentoimivuus

8. yhteentoimivuus (interoperability) The ability of two or more systems or components to exchange information and to use the information that has been exchanged.” Functional interoperability ability to exchange information Semantic interoperability ability to understand the information exchanged [IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]

9. Lait, ohjeet, toimintatavat ratkaistavat asiat ohjelmistoja liitettäessä Prosessit Milloin? • järjestelmän elinkaari • toiminnallinen arkkitehtuuri • sovellusarkkitehtuuri • tekninen arkkitehtuuri Mitä? Missä? Miten? • ratkaistava kaikissa sovellusintegraatio-tilanteissa Verkot [Peter Herzum, Oliver Sims] Laitteet

10. Tietopohjainen tiedonsiirto tai kopiointi tietokannat, viestit, dokumentit, deklaratiivinen yksinkertaisuus, runsaasti käytetty ”business documents” Prosessipohjainen määriteltyjen ja keskitetysti ylläpidettyjen prosessien kerros prosessin koordinaattori (orkestraatio), prosessien hajauttaminen (koreografia) työnkulkujen ymmärtämisestä määrittelyyn ja ohjaukseen Palvelupohjainen jaetut toiminnot ja operaatiot, yhteiset palvelut (common services) rpc-pohjainen middleware, Web services, imperatiivinen uudelleenkäyttö, vähemmän päällekkäistä tietoa, toiminnallisuutta, ylläpitoa ja toteutustyötä Käyttäjälähtöinen yhdenmukainen näkymä moniin järjestelmiin portaalit, sovellusten synkronointi käytettävyys, personointi, monikanavaisuus jne. integrointimallit – vaatimusten ja perusratkaisujen ensisijainen luonne [David Linthicum]

11. palveluarkkitehtuurin integrointiarkkitehtuuri

12. esimerkkejä haasteista, joihin palveluarkkitehtuuriajattelulla pyritään vastaamaan(esimerkkinä SerAPI-hanke/terveydenhuolto) • Samoja tietoja syötetään ja kopioidaan käsin tai ylläpidetään moniin eri järjestelmiin • Uusiin tarpeisiin vastaaminen ohjelmistoissa vie kauan aikaa (ohjelmistojen versiokehityssyklit pitkiä, paljon muutos- ja lisäyspyyntöjä) • Käyttöönottoprojektit ja versiovaihdokset aiheuttavat runsaasti häiriöitä ja viivästyksiä • Tutkimus/kehityshanke tai hankinta tuottaa käyttökelpoisen erityisratkaisun, mutta sitä ei saada liitettyä muihin järjestelmiin • (Hoito)prosesseja mallinnetaan, mutta tietojärjestelmät eivät taivu tukemaan määriteltyä tavoitetilaa

13. SOA what: interoperability • SOA: lähestymistapa, jossa tietojärjestelmät ja prosessit koostetaan sovelluspalveluista • SOA ei ole arkkitehtuuri, mutta arkkitehtuuri (osat, niiden suhteet ja kehittämisperiaatteet) erittäin keskeinen • alkuvaiheessa hyödyt uudelleenkäytöstä, sitten yhdenmukaisuudesta, myöhemmin mukautuvuudesta • keskeiset SOA-teesit • muutosherkkyys • joustavuus • toimialavastaavuus • uudelleenkäyttö, palvelujen yleiskäyttöisyys • SOA yhteistoiminnallisuuden kannalta • yhdistelmä: EAI, BPM ja komponenttipohjaisuus • järjestelmäkokonaisuuden hahmottaminen palveluina • rajapinta- ja sopimuskeskeisyys

14. viitearkkitehtuuri: esimerkki [Arsanjani A. Service-oriented modeling and architecture.]

15. integrointiarkkitehtuuri viitearkkitehtuurissa • tekniset perusratkaisut ja edellytykset hajautetun palvelupohjaisen arkkitehtuurin toteuttamiselle • keskeistä (ja suosittua) • ESB • karkeajakoiset sovelluspalvelut • mutta huomioitava myös • muut kuin palvelukerros • eri tyyppiset integrointivaatimukset…

16. integrointiarkkitehtuurin keskeiset suunnittelupäätökset Lars-Göran Lindgren, Creative Commons Attribution ShareAlike license version 2.5 http://creativecommons.org/licenses/by-sa/2.5/ Gedstrom, Creative Commons Attribution ShareAlike license version 2.5 http://creativecommons.org/licenses/by-sa/2.5/

17. keskeiset integrointiarkkitehtuurin suunnittelupäätökset • kullekin integrointitilanteelle tunnistettavissa • ensisijainen integrointimalli • muuttuvuuden taso ja mukautuvuusvaatimukset • keskitys vai hajautus + yhteinen malli vai mediaatio • karkeajakoisuus- ja vuorovaikutteisuusvaatimukset • coupling & cohesion - kytkennän ja esim. vuorovaikutteisuuden tiukkuus • samojen "sovellus- tai palveluroolien" lukumäärä • vuorovaikutus- ja viestinvaihtomallit • tilan-, kontekstin- ja sessionhallinta • tehtävä valintoja mm. infran ja vakioinnin suhteen • oletko sovelluspalvelun tarjoaja vai hyödyntäjä? [Mykkänen, Riekkinen, Laitinen, Karhunen, Sormunen. Designing Web Services in Health Information Systems: From Process to Application Level, Int J Med Inf 2007]

18. milloin SOA-palvelut? • SOA-palvelut • prosessin muuttuvuus korkea • uudelleenkäyttö tärkeää • toiminnallisuus keskittyy prosessin vaiheisiin, ei yksittäisiin transaktioihin • prosessien mukauttaminen tai personointi tärkeää • ratkaisun katettava useita organisaatioyksiköitä • ajon aikainen mukautuvuus / kontekstitietoisuus tärkeää • liiketoiminnan tiedot ja semantiikka hajautettu • myös huomioitava • data-integraatio (DW, ETL), portaalit, prosessikerros, back-end integraatio komposiittipalvelujen koostamiseksi jne. • kumppanien ESB-ratkaisut ja -arkkitehtuurit [IBM 2006]

19. eri integrointitavat viitearkkitehtuurissa(yksinkertaistettuna) Käyttäjäintegraatio Prosessi-integraatio Tietointegraatio Palveluintegraatio

20. palvelualustat + esimerkkejä niiden vaikutuksista suunnittelupäätöksiin

21. palvelualustojen käyttö • palvelualusta (ESB) perusteet : • lähettäjien ja vastaanottajien välissä (intermediary) • ohjelmistojen välinen kommunikointi • aina SOAP/http • yleensä myös viestipohjainen middleware (MOM) • eri viestinvälitysmallit: synkroninen, ei-synkroninen, publish/subscribe • tukee Web services-standardeja (XML, WSDL, SOAP, http) • reititys (mm. palveluntarjoajien löytäminen / korvaaminen, ajonaikainen sidonta) • muunnokset (tietomuotojen + viestinvälitysprotokollien välillä) • metatietojen käyttö (osoitteet, rajapinnat, skeemat, policy-määrittelyt) • seuranta (esim. Business Activity Monitoring, tekninen toimivuus, SLA-valvonta), turvallisuusominaisuudet • (usein) prosessimoottorin käyttö • ESB ei ole yhtä kuin hub and spoke-integrointialusta: myös integrointikomponentit hajautettu palveluiksi palveluväylän kautta [mukaillen Gartner + Bea + Chappell]

22. palvelualusta perus-SOA-mallissa [SOA4HL7]

23. palvelualusta orkestroidussa ja välitetyssä SOA-mallissa Static intermed. Dynamic intermed. [SOA4HL7]

24. palvelualustan vaikutuksia suunnittelupäätöksiin • vaikuttaa • tekniset protokollasopimukset • rajapintojen syntaksi, kommunikaatioprotokollat, vaatimukset sovellusten teknisille adaptereille, joskus myös eri viestintämuotojen mäppäys mahdollista • ympäristön hallittavuus • keskitetty yhteys-, valvonta- (ja virhetilanne-) piste vai hajautetut integrointipalvelut • lisää joustavuutta ja erilaisia soveltamismahdollisuuksia, mutta myös uuden kerroksen järjestelmään ja eri soveltamistapoja • otettava kantaa oletuksiin alustan hoitamista seikoista • policy-määritysten suhde toiminnallisiin määrityksiin • periaatteessa kaikki voi olla joko rajapintaa tai konfiguraatiota • esim. "pyynnön vastaanottajan" määrittely: mikä yhdistelmä reititystä ja rekisteriä? • onko osa palvelun rajapintaa, alustan / hakemiston hoidettava asia vai palvelun käyttäjän vastuulla paikallistaa? • kulkeeko "kaikki" palvelualustan kautta, vai tehdäänkö suoria liitäntöjä esim. ydinpalveluihin – esim. Bea-arvio: 20 palvelun sovelluksen onnistuvat vielä point-to-point • ei vaikuta • semanttiset ja toiminnalliset perusratkaisut (tietoelementtien ja kokonaisuuksien merkitykset, pl. yksinkertaiset yhdistelyt ja jaot) • toiminnallisten vaatimusten perusluonne (integrointitapa) • taustajärjestelmien toiminnallinen viitemalli ja tietorajoitteet (kenttien pituudet jne.) • mitä jos alusta yrittää ”seurata” integraatiota joka onkin käyttöliittymätasolla?

25. filosofinen ero (tai USA-Ruotsi-maaottelu)

26. esimerkki

27. vakiointiesimerkki: liitäntätyypit sairaaloiden integrointiarkkitehtuurissa (mid-term) • keskitetyt, jaetut sovelluspalvelut (ydinpalvelut) • lisäpalvelut, kontekstinhallinta jne. • organisaatioiden väliset palvelut ja prosessit [Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007]

28. Yhteistyö- hankkeet, "naapurit" SerAPI- työkohde yhteisesti sovittuja rajapintojapaikallisia + järjestelmäkohtaisia valintoja Kontekstinhallinta Prosessivälineet ja -esimerkit EBMeDS / Käypä hoito eResepti Potilas- ydinrajap. IHE? Koodisto- rajapinnat Potilas- listat Ateria- tilaus Päätöksen- tuki DRG + APR ryhmittelyt Ajan- varaus Kansallinen arkisto Käyttäjä-oikeus-rajapinnat Web services-suositukset, esimerkit ja standardit • keskitetyt, jaetut sovelluspalvelut (ydinpalvelut) • lisäpalvelut, kontekstinhallinta jne. • organisaatioiden väliset palvelut ja prosessit

29. kuinka paikallisesti kukin taso ratkaistaan / vakioidaan? standardoinnin taso yrityksen tuotteet A kansainvälinen tuote B Euroopan markkinoille C kotimaan markkinoille D tuoteräätälöinti E asiakasräätälöinti F pilotointi laitos alue / tuote FI CEN ISO [Antero Ensio]

30. miten välttyä rajapintaspagetilta?

31. vastaus: • vakioi

32. tarkennettu vastaus: • vakioi siten, että useimman tyyppisiin integrointitarpeisiin löytyy paikallinen sabluuna • (= valmis pohja 1. integrointimalleihin 2. -tasoihin ja 3. muihin keskeisiin integroinnin suunnittelupäätöksiin) • sovellusinfrassa (arkkitehtuuritasolla) • kyettävä vastaamaan eri tyyppisiin integrointitarpeisiin • siis vakioi käyttäjäintegraatio, tietointegraation 2-4 ratkaisumallia, prosessi-integraatio, määrittele toiminnallisten palvelujen tyypit • tietojen osalta AINA semantiikka!! • standardeilla usein järkevää vakioida myös toiminnallisia ja teknisiä liittymiä • tekninen infrastruktuuri ja elinkaarimallit • vakioinnilla lähinnä markkina-, ylläpito- ja osaamishyötyjä • ESB:llä joustavuus- ja ketteryys-hyötyjä • yksi ratkaisu / malli ei sovi kaikkeen! • mutta yksi ratkaisu / malli voi kuvitella tietävänsä kaiken

33. yhteenveto • SOA:ssa korostetaan (usein) "suuria" rajapintoja ja dokumenttipohjaisuutta • public enterprise service (kumppanien välillä)? • "business activity + entity", sekä yleistetyllä että tarkalla tasolla • lisäksi otettava kantaa mm. • käyttäjätarpeet (vuorovaikutteisuus vs. "eräkäyttöinen" web-käyttöliittymä, portaalit, monikanavaisuus) • prosessikerros: prosessipalvelut, prosessimoottori vai koreografia; prosessilogiikan ulkoistaminen vanhoista järjestelmistä ongelmallista • yhdenlaisilla palveluilla ei ratkaista kaikkea • arkkitehtuurin kerroksellisuus • palvelujen luokittelut (esim.): • integrointitapa • yleiskäyttöisyys: erityisesti YDINpalvelujen tunnistus ja uudelleenkäyttö • operaatioiden karkeajakoisuudessa vaatimuksista riippuvia eroja • SOAn yksi rooli integraation syventäjänä: IT-integraatiosta toiminnan ja tietojärjestelmien yhdessä kehittämiseen

34. Kiitos juha.mykkanen@uku.fi vs. www.uku.fi/tike/his