Palveluarkkitehtuuri ja integraatiot

Transkriptio

1 Palveluarkkitehtuuri ja integraatiot FYI SOA seminaari Helsinki, Juha Mykkänen Itä-Suomen yliopisto, Kuopion kampus Tietojenkäsittelytieteen laitos HIS-tutkimus ja kehittäminen 1

2 Puhujan ja sisällön taustaa Juha Mykkänen, FT, tutkimusjohtaja Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos, Kuopion kampus, HIS-tutkimus Kuopio Welfare Research Center KWRC, Hyvinvoinnin tiedonhallinta ja tekniikat -tutkimuslinja HL7 Finland ry puheenjohtaja, Sosiaali- ja terveydenhuollon tietojenkäsittely-yhdistys varapuheenjohtaja, International Medical Informatics Association (IMIA) / WG Health Information Systems -järjestö, HL7 International SOA Ambassador, JHS-standardisalkku-, STM arkkitehtuurijaosto projekteja integrointiratkaisujen ja palveluarkkitehtuurin (SOA) tutkimiseen ja soveltamiseen SOLEA : SOA ja EA, teollisuus ja terveydenhuolto Sosiaalialan tietoteknologiahanke - Tikesos Mielen ja kehon eliksiirit -ohjelma, Terveyden ja hyvinvoinnin strategisen huippuosaamisen keskittymä (SalWe SHOK), SerAPI : palveluarkkitehtuuri ja sovellusintegraatio, terveys OmaHyvinvointi (MyWellbeing) , asiakaskeskeiset hyvinvointipalvelut PlugIT , sovellusintegraatio terveydenhuollossa ekat / terveyspalvelujen ajanvarauksen arkkitehtuurin suuntaviivat 2008 Healthcare services specification project (HSSP) / HL7 and OMG, Integrating the Healthcare Enterprise - IHE.fi HL7- ja web services -standardeja ajanvarauksiin, sähköiseen reseptiin, sähköiseen potilastietoarkistoon, potilasryhmittelyihin, työpöytäintegraatioon jne. 2

3 Sisältö Esityksen konteksti Integrointimallit SOA-viitearkkitehtuurissa Vanhat järjestelmät SOA:an: kerros vai pala kerrallaan? Palvelualustojen vaikutukset SOA:n suhde yhteentoimivuusstandardeihin 3

4 Konteksti 4

5 SOLEA Palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri Tekes-projekti, HIS / Itä-Suomen yliopisto, Kuopion kampus Terveydenhuollon tietojärjestelmien T&K-yksikkö, tkt-laitos SoberIT / Aalto-yliopiston Teknillinen korkeakoulu Ohjelmistoliiketoiminnan ja tuotannon laboratorio Terveyspalvelujen tuottajat Helsingin ja Uudenmaan shp, Medbit / Varsinais-Suomen shp, Pohjois-Savon shp/istekki, Satakunnan shp Teollisuusyritykset ja palvelutuottajat Konecranes, Metso, Osuuspankkikeskus, Raha-automaattiyhdistys, Järjestelmä- ja teknologiatoimittajat ja IT-integraattorit Commit;, Datawell, Fujitsu Services, Intersystems, Itella, Logica, Mawell, CSC Yhteistyöorganisaatiot Tieke, HL7, Kela, STM, Kuntaliitto, Kunta-IT, Sosiaalialan tietoteknologiahanke 5

6 Operational project architecture Strategic and tactical Enterprise Architecture SOLEA-työkohteet ja tulokset Strategy / Planning) Design Implementation Operation EA-hallintamallit EA ja SOA Governance AGM metamalli (yleinen) sovellusalueet; tietoturva, strategia, arkkitehtuuri, EA, BPM, EA ja SOA kuvaustavat EA- ja SOA -menetelmät ja välineet arkkitehtuurikehikot notaatiot, mm. ArchiMate, Business Model Canvas, JHS SOA roadmap SOA-kehitysmallit Arkkitehtuurikuvausten kohteet ja kuvaustavat kartoitukset eri EA-kuvauksista arkkitehtuurin kuvaustapojen case-tiedonkeruu palaute kuvaustapojen käytöstä Prosessien ja toiminnan kuvaaminen nykytila ja kehityskohteet mallintamisen tasot ja näkökulmat yhteiset mallit Vaatimustenhallinta Vaatimusten hallinta suhteessa EA:han EA ja SOA-mittarit Integraatio, Standardit ja SOA Object Role Modeling ORM-soveltaminen integraatiossa Standardien arviointi SOA ja standardointi tietomallien analysointi Standardointi-yhteistyö OASIS, Open Group, HL7, IHE, SFS, JHS Case-esimerkit Käyttäjähallinta vaatimukset ja rajaukset palvelupohjaiselle käyttäjäja käytönhallinnalle Palvelutapahtumien hallinta arkkitehtuuritarkennuksia terveydenhuollon valtakunnallisten, alueellisten ja paikallisten tietojärjestelmäratkaisujen kannalta Osapuolten projektit Konecranes MDM Satakunnan shp päivystys jne. 6

7 7 Tietojärjestelmien kehittämisen tavoitteita tietojärjestelmien kehitykseen liittyviä tavoitteita, joita erityisesti palveluarkkitehtuurin ja web-sovelluspalvelujen avulla pyritään saavuttamaan vrt. SOA-tavoitteet! A. Uudelleenkäyttö -jo toteutettujen toimintojen kapselointi -päällekkäisyyksien vähentäminen -yhdenmukaisten palvelujen tarjoaminen -ohjelmistotyön tuottavuus C. Osien markkinat -mahdollisuus myydä ja ostaa valmiita, erikoistuneita komponentteja -erikoistuminen -mahdollisuus valita eri vaihtoehdoista sopiva ratkaisu E. Muutoksiin varautuminen ja vastaaminen -muutokset toimintaprosesseissa ja toimintaympäristössä -teknologiamuutokset B. Tuki heterogeenisyydelle -sovellusten eri toteutustekniikat -eri käyttöjärjestelmät, käyttöliittymät, palvelimet -erityyppiset toiminnalliset vaatimukset ja prosessit D. Suurten järjestelmien hallittavuus -suuret toiminnallisuuskokonaisuudet -yhtäaikainen käyttö -skaalattavuus -kokonaisjärjestelmän ominaisuuksien lisääminen

8 Integrointimallit palveluarkkitehtuurissa 8

9 9 Hankintavaihtoehtojen monipuolistuminen Osta valmis tuote Toteuta itse Teetä uusi järjestelmä Suunnitteluta ulkopuolisella Osta ja räätälöi järjestelmä Vuokraa ulkopuoliselta (ASP) Osta ja integroi komponentit Toteuta vanhan järjestelmän sovittimena Kirjaudu käyttämään verkon kautta Laajenna sovelluskehyksestä

10 Ratkaistavat asiat ohjelmistoja liitettäessä järjestelmän elinkaari toiminnallinen arkkitehtuuri Lait, ohjeet, toimintatavat Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka sovellusarkkitehtuuri tekninen arkkitehtuuri ratkaistava kaikissa sovellusintegraatiotilanteissa Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät Verkot Laitteet [Peter Herzum, Oliver Sims] 10

11 Integrointimallit vaatimusten ja perusratkaisujen ensisijainen luonne 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. [David Linthicum] 11

12 SOA-viitearkkitehtuuri Käyttäjä Portlets WSRP Prosessi Sovelluspalvelut -atomiset -yhdistetyt Taustajärjestelmät Palvelin Top-down: prosessimalleja runsaasti, mutta vähän linkityksiä sovelluspalveluihin / rajapintoihin Palvelukomponentit Bottom-up, monia Räätälöity valmiita Hyllytuote malleja, eri tyyppisiä CRM, ERP rajapintoja Oliopohjainen eri tyyppisiin tarpeisiin Business intelligence Integrointiarkkitehtuuri (ESB) (turvallisuus-, hallinta- ja seurantainfrastruktuuri) Laadunhallinta (QoS) (metatiedot, kuvaukset, tietovarastointi) Tietoarkkitehtuuri (governance, policy) Hallintakäytännöt Viitearkkitehtuuri: IEEE P1723 (S3) 12

13 Eri integrointitavat viitearkkitehtuurissa (yksinkertaistettuna) Käyttäjäintegraatio Presentation Portlets WSRP Business process Choreography Services Enterprise components Operational systems Mainframe Composite services Project or enterprise components Prosessi-integraatio Palveluintegraatio Object-oriented CRM, ERP Tietointegraatio Business intelligence Integration architecture Security, Management, Monitoring, Quality of service 13

14 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] 14

15 Vanhat järjestelmät SOA:an: kerros vai pala kerrallaan? 15

16 Kolme siirtymäpolkua: case monoliittisten sairaalatietojärjestelmien uudistaminen tunnistetut migraatiopolut v Kerroksittainen uusiminen olemassaolevan hyväksikäyttö, teknologia-adapterit, vanhan pohjan käärintä, tieto- ja resurssipalvelut alhaalta ylös, vähittäin 2. Paloittainen uusiminen uudet osat heti uuteen arkkitehtuuriin, uusilla hyvillä tekniikoilla vanhan ja uuden rinnakkaiselo, tietojen synkronointi 3. Web-lähtöinen uusiminen vanhaan järjestelmään nopeasti web-käyttöliittymät myöhemmin uusiminen kerroksittain tai paloittain [Komponentti-FixIT] 16

17 Kaikki siirtymäpolut eri paikoissa ja järjestelmissä toteutuneet, 2006 Kerroksittainen data service lähestymistapa toteutettiin järjestelmien modernisointivälineiden avulla; perinnetietokantojen tieto käyttöön sovelluspalvelimille käytössä etenkin joissakin ytimestä irrotetuissa erillisjärjestelmissä ja portaaliratkaisujen pohjana Paloittainen siirtymäpolku: uudemmissa ydinjärjestelmissä rinnakkaiskäyttö vanhojen kanssa, keskeisten ydinpalvelujen rajapinnat joissakin ydinjärjestelmissä, samoja rajapintoja sekä perinne- että uusissa järjestelmissä; erilaisia arkkitehtuurivariaatioita Web-siirtymän avulla esimerkiksi laboratoriojärjestelmiä modernisoitu onnistuneesti: antaa vanhan toimivan tekniikan ollakin taustalla, siirtyminen tieto- ja käyttöpalveluihin... [SerAPI] 17

18 2011: Monoliittiset järjestelmät hallitsevat edelleen ydin markkinoita Integraatiot ja palvelurajapinnat lisääntyneet, mutta järjestelmien uusiminen jossain vaiheessa välttämätöntä Monoliittejä vaihdetaan uusiin, joissa entistä enemmän rajapintoja? Uusissa ratkaisuissa (esim. sähköinen asiointi) vähemmän perinnetaakkaa 18

19 Palvelualustojen vaikutukset 19

20 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, SLAvalvonta), 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] 20

21 Palvelualusta orkestroidussa ja välitetyssä SOA-mallissa Services Registry Look Up Publish Service Consumer Endpoint Application Adapter Routing Intermediary Static intermed. Transformation Intermediary Adapter Service Provider Endpoint Application Subscription Manager Dynamic intermed. Policy Manager / Service Logging / Audit Service Orchestration Engine / Service Message Persistence Store / Service Security Manager / Service Transaction Manager / Service [SOA4HL7] 21

22 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, RAY kokemukset: pari sataa palvelua hoituu vielä pitkälti myös point-to-point-periaatteella 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? 22

23 SOA:n suhde yhteentoimivuusstandardeihin 23

24 Kuinka paikallisesti kukin yhteentoimivuustaso 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] 24

25 Standardoinnin kohteita tietosisällöt (järjestelmien, asiakirjojen, rajapintojen...) tiedon siirto/esitysmuodot (viestit, asiakirjamuodot, rakenteisuus, tietotyypit jne.) järjestelmien toiminnalliset ominaisuudet arkkitehtuuri (osat, niiden suhteet + kehittämisperiaatteet) rajapintatekniikat turvallisuusratkaisut tietoliikenne, viestit, sanomat palvelurajapinnat jne. medicine and healthcare processes, pathways quality of care information models and elements terminologies, classifications, codes guidelines, knowledge standardization relevant to ehealth and HIS healthcare IT and IS electronic health records security and confidentiality support for processes service and API interfaces archiving and long term storage message interfaces electronic clinical documents data types and formats architecture IT, domain-neutral and cross-domain software production / development security process description and definition interface technologies messaging and enveloping electronic documents egovernmenance and architecture identification data communications TOIMIALAKOHTAISET, (YHDISTELMÄ), YLEISET JA TEKNISET 25

26 Standardiesimerkkejä SOA-näkökulmasta ABQC Process Classification Framework OASIS SOA Reference Model, OMG SoaML, Open Group SOA ontology, BPMM, OSIMM ebxml RIM, HL7 RIM, HL7 EHR-S FM, HL7 PHR-S FM, HL7 D-MIM OASIS UBL, BizTalk specifications, HSSP, RosettaNet, ebxml CPP/CPA, (OMG Domain Technical Committees), HL7 Scheduling, HL7 Finland minimikontekstinhallinta IEEE P1723 (S3), OASIS RA4 SOA Foundation, Open Group SOA Reference Architecture WS-RM, WS-Security, SAML, XACML, WS-Trust, WS-SecureConversation, BPEL, SCA, WS-Policy, UDDI v3 WSDL, SOAP, WS-I, JMS, CORBA, XML-RPC HTTP, FTP Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät 26

27 Palvelualusta = USA Standardi = Ruotsi Palvelualusta pyrkimys kaaoksen hallittavuuteen mediaattori: reaktiivisesti eri osapuolten protokolliin mukautuminen "väline, jolla saa nopeasti tehtyä integrointia" "helpota paikallista integrointia" integroijan ja tilaajan vastuu sisällöstä sopiminen + osin tuote/välinekohtaiset tekniikkamäppäykset? install & tweak & configure & play USA: oman onnensa seppä Yhteinen integrointimäärittely pyrkimys järjestyksen luomiseen silta: proaktiivinen ulkoinen protokolla, johon molemmat sopeutuvat "tarkasti sovitut rajapinnat ja soveltamisoppaat" "vähennä paikallista räätälöintiä" toimittajan ja tilaajan vastuu sisällöstä ja tekniikasta sopiminen agree & plug & configure & play Ruotsi: sovitaan yhdessä 27

28 Yhteenveto Sisäisessä integraatiossa yksinkertaisuus ja joustavuus tärkeintä Jäykkyyttä lisää mm. Schema-käyttö vs. REST Monenvälisessä ja standardi-integraatiossa sopimukset tärkeässä roolissa Standardit, Skeemat, sopimukset, yhteiset viitemallit monilla tasoilla SOA-standardoinnissa keskeisiä myös toiminnalliset mallit SOA:a voi tehdä ilman palvelualustaa Mutta käytännössä etenkin moniprotokolla- ja monitoimijaympäristössä hyödyt merkittäviä Policy- ja turvallisuusyksityiskohdat eivät saa saastuttaa business-rajapintoja SOA on jo arkipäivää etenkin integraationäkökulmasta Mutta etenkin prosessimallinnuksen ja järjestelmäkehityksen välissä vielä runsaasti aukkoja: heitetäänkö prosessikuvaukset menemään ja tehdään käyttötapauksista? SOA:n uudelleenkäyttö- ja integraatiohyötyjä runsaasti näkyvissä, strategisia joustavuus- ja ketteryyshyötyjä paljon vähemmän Muutaman keskeisen integrointimallin vakiointi järkevää Kulttuurimuutos kertahankinnoista jatkuvaksi kehittämiseksi pääosin kesken 28

29 29 Kiitokset

30 SOA-siirtymän päävaiheiden hyötymalli [muk. Sprott D. Best Practice Report - The Business Case for SOA. CBDI Journal, June ] Toiminnan yhdenmukaisuus ja suunnittelu Nopeus vaatimuksista käyttöönottoon Kustannussäästöt Uudelleenkäyttö projektissa Uudelleenkäyttö projektissa Palvelujen yhdenmukaistaminen Uudelleenkäyttö organisaatiossa Uudelleenkäyttö organisaatiossa, vähentynyt integrointityö Prosessien yhdenmukaistaminen Mukautettavat prosessit Komponenttikehitys, yleiskäyttöiset ratkaisut, sovellusten korvaaminen Strategian ja operatiivisen toiminnan yhtenevyys Toiminnan ja IT:n yhtenevyys Prosessien tehokkuus [Palveluarkkitehtuurin soveltaminen terveydenhuollossa: osa 1] Oppimisvaihe Integrointivaihe Uudelleensuunnitteluvaihe Kulttuurillinen integraatio SerAPI 30