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

IT-arkkitehtuuri20.11.2007

Helsinki

Juha Mykkänentutkijatohtori

Kuopion yliopistoHIS-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

Semantic interoperability

Functional interoperability

yhteentoimivuus (interoperability)

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.”

ability to exchange information

ability to understand the information exchanged

[IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]

9

ratkaistavat asiat ohjelmistoja

liitettäessä• järjestelmän elinkaari• toiminnallinen

arkkitehtuuri

• sovellusarkkitehtuuri• tekninen arkkitehtuuri

Te knise t liittymät

Te knine n infrastruktuuri

Sov e llusinfrastruktuuri

Toiminnallise t liittymät

Se mantiikka

Toiminnalline n v iite malli

Ke hitysprose ssin liittymät

• ratkaistava kaikissa sovellusintegraatio-tilanteissa

[Peter Herzum, Oliver Sims]

Prosessit

Lait, ohjeet, toimintatavat

Laitteet

Verkot

10

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

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

Operationalsystems

Mainframe

Enterprisecomponents

Services

Business processChoreography

Presentation Portlets WSRP

Composite services

Project or enterprise components

Object-oriented

CRM,ERP

Businessintelligence

Integration architecture

Security, Managem

ent,M

onitoring, Quality of service

[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.5http://creativecommons.org/licenses/by-sa/2.5/

Gedstrom, Creative Commons Attribution ShareAlike license version 2.5http://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)

Operationalsystems

Mainframe

Enterprisecomponents

Services

Business processChoreography

Presentation Portlets WSRP

Composite services

Project or enterprise components

Object-oriented

CRM,ERP

Businessintelligence

Integration architecture

Security, Managem

ent,M

onitoring, Quality of service

Käyttäjäintegraatio

Prosessi-integraatio

Palveluintegraatio

Tietointegraatio

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

Service Consumer Endpoint

Application

Services Registry

Service Provider Endpoint

Application

Adapter

AdapterPublishLook Up

Security Manager /

Service

Logging / Audit Service

Message Persistence

Store / Service

Transaction Manager /

Service

[SOA4HL7]

23

palvelualusta orkestroidussa ja välitetyssä SOA-mallissa

Orchestration Engine / Service

Service Consumer Endpoint

Application

RoutingIntermediary

Services Registry

Service Provider Endpoint

Application

Policy Manager / Service

Adapter

Adapter

Subscription Manager

Transformation Intermediary

PublishLook Up

Security Manager /

Service

Logging / Audit Service

Message Persistence

Store / Service

Transaction Manager /

Service

Dynamicintermed.

Staticintermed.

[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)

Palvelualusta Yhteinen integrointimäärittelypyrkimys kaaoksen hallittavuuteen

pyrkimys järjestyksen luomiseen

mediaattori: reaktiivisesti eri osapuolten protokolliin mukautuminen

silta: proaktiivinen ulkoinen protokolla, johon molemmat sopeutuvat

"väline, jolla saa nopeasti tehtyä integrointia"

"tarkasti sovitut rajapinnat ja soveltamisoppaat"

"helpota paikallista integrointia" "vähennä paikallista räätälöintiä"

integroijan ja tilaajan vastuu toimittajan ja tilaajan vastuusisällöstä sopiminen + osin tuote/välinekohtaiset tekniikkamäppäykset?

sisällöstä ja tekniikasta sopiminen

install & tweak & configure & play agree & plug & configure & playUSA: oman onnensa seppä Ruotsi: sovitaan yhdessä

26

esimerkki

27

vakiointiesimerkki: liitäntätyypit sairaaloiden integrointiarkkitehtuurissa (mid-term)

1. keskitetyt, jaetut sovelluspalvelut (ydinpalvelut)2. lisäpalvelut, kontekstinhallinta jne.3. organisaatioiden väliset palvelut ja prosessit

Administration and management

Financials

Materialsmanagement

Personnelmanagement

Property andinfrastructuremanagement

Sales, CRM,marketing, PR

Clinical subsystems

Surgery

Neonatal

Cardiology

Pathology

Anaesthesiology+ ICU

Gastroenterology

Clinical core

Patient andprovider id

Decisionsupport

Pharmacy

Terminology

Etc

EHR repository

Administrative core

Patient / providerdemographics

Invoicing

Admisstion,discharge,

transfer

Inpatient andoutpatient

management

Resource /operationsplanning

Materials& mealordering

Orders / referrals,prescriptions,consultations

Scheduling,Resouce

Management

Patientgrouping,

DRG

User management, security and access control

Integration, data access

Workflow and process management

Professional front-endsPatient/citizen front-end

Lab

Radiology+ PACS

Medication

Results

Problems

Population /community health

Insurance

Reporting, Data warehousing, Management

Workstations Web Mobile Ubiquitous

Statisticalreporting

Research

Guidelines,protocols

Equipment

Diseasemanagement

1. 2. 3.

1. Common, shared and centralized services2. Context management, added value services3. Loosely-coupled messages, documents, cross-facility invocations

Identification User role Care relationship Consent

[Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007]

28

yhteisesti sovittuja rajapintojapaikallisia + järjestelmäkohtaisia valintoja

1. keskitetyt, jaetut sovelluspalvelut (ydinpalvelut)2. lisäpalvelut, kontekstinhallinta jne.3. organisaatioiden väliset palvelut ja prosessit

Administration and management

Financials

Materialsmanagement

Personnelmanagement

Property andinfrastructuremanagement

Sales, CRM,marketing, PR

Clinical subsystems

Surgery

Neonatal

Cardiology

Pathology

Anaesthesiology+ ICU

Gastroenterology

Clinical core

Patient andprovider id

Decisionsupport

Pharmacy

Terminology

Etc

EHR repository

Administrative core

Patient / providerdemographics

Invoicing

Admisstion,discharge,

transfer

Inpatient andoutpatient

management

Resource /operationsplanning

Materials& mealordering

Orders / referrals,prescriptions,consultations

Scheduling,Resouce

Management

Patientgrouping,

DRG

User management, security and access control

Integration, data access

Workflow and process management

Professional front-endsPatient/citizen front-end

Lab

Radiology+ PACS

Medication

Results

Problems

Population /community health

Insurance

Reporting, Data warehousing, Management

Workstations Web Mobile Ubiquitous

Statisticalreporting

Research

Guidelines,protocols

Equipment

Diseasemanagement

1. 2. 3.

1. Common, shared and centralized services2. Context management, added value services3. Loosely-coupled messages, documents, cross-facility invocations

Identification User role Care relationship Consent

Kansallinen arkisto

Koodisto-rajapinnat

Ajan-varaus

Yhteistyö-hankkeet, "naapurit"

SerAPI-työkohde

Päätöksen-tuki

Potilas-ydinrajap.

Potilas-listat

IHE?

DRG + APRryhmittelyt

eResepti

Prosessivälineet ja -esimerkit

Ateria-tilaus

Käyttäjä-oikeus-rajapinnat

Kontekstinhallinta

EBMeDS /Käypä hoito

Web services-suositukset, esimerkit ja standardit

29

kuinka paikallisesti kukin taso ratkaistaan / vakioidaan?

ISOCENFIlaitos alue /tuote

standardoinnin tasoyrityksen tuotteet

A kansainvälinen tuoteB Euroopan markkinoille C kotimaan markkinoilleD tuoteräätälöintiE asiakasräätälöintiF pilotointi

[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

www.uku.fi/tike/his

vs.