Web-sovelluspalvelut terveydenhuollossa?

Juha Mykkänen, Marko Sormunen, PlugIT, Kuopion yliopisto, HIS-yksikkö PlugIT-puolivuotisseminaari, Kuopio, 28.10.2003

2

Esityksen sisältö

• Web-sovelluspalveluiden (Web Services) idea ja määritelmä

• Tekniikat ja käyttötavat• Tekniikoiden lupaukset ja

”lupaukset”• Käyttökelpoisuus

terveydenhuollon sovellusintegraatiossa?

huippu-uutuus?

vanhaa tavaraa uudessa paketissa?

toimiiko ollenkaan?

3

Web-sovelluspalvelu (Web Service)• Tarjoaa toimintoja tai tietoja verkon kautta käytettäväksi eri

sovelluksissa (sovelluspalvelu)• Ohjelmisto,

– joka tunnistetaan Internet-osoitteella, – jonka tarjoamat liittymät määritellään XML:llä, – joka kommunikoi XML-viesteillä ja Internet-protokollien avulla [W3C]

• Luonne– sisältää komponenttien piirteitä

• palvelut tarjotaan liittymän kautta, oma siirtoprotokolla• välineet voivat generoida koodia liittymämäärittelystä

– EI ole komponentti• puuttuu määritelty suoritusympäristö• voidaan toteuttaa eri tekniikoiden avulla (myös komponenttitekniikoilla)• ei ole ”asennettava” vaan ”verkon yli käytettävä” (aste-ero)• mahdollisuus sekä ”etäohjelmien” että ”dokumenttien” käyttöön integroinnissa• palvelut yleensä tilattomia, yksi palvelu”olio” / fyysinen palvelin

4

Web-sovelluspalvelutekniikat• Tiedon siirtoesitys ja siirto

– tiedonvälitys verkossa yleensä http –siirtoprotokollan avulla– SOAP, määrittelee ”kirjekuoren” siirrettävälle sanomalle, voidaan käyttää eri

siirtoprotokollien päällä (sähköposti, FTP, Jabber..)• Liittymien (tiedot, toiminnot) määrittely

– WSDL, määrittelee kutsuttavia operaatioita, määrittelee alemman tason protokollat (esim. SOAP), luodaan/luetaan yleensä automaattisesti välineillä

– XML-RPC käyttää http-protokollaa, määrittelee yksinkertaisia etäohjelmakutsuja

– ebXML CPP/A tai muut XML-dokumenttimääritykset voivat määritellä tiedonsiirrossa käytettäviä dokumenttityyppejä ja -merkkauksia

• Palveluiden dynaaminen löytäminen, rekisterit– UDDI– ebXML registry, välipalvelin..)

• Lisämääritykset (-tasot)– toimintaprosessien määrittely, sopimukset, reititys, turvallisuus jne.

• SOAP, WSDL, UDDI, ebXML, XML-RPC jne. perustuvat XML:ään, ja ”pelkkää” XML:ää mahdollista käyttää eri tasoilla

5

Web-sovelluspalveluiden toteutustapoja

• Palvelukutsut– etäoperaatio, pyyntö - vastaus, ”puhelinkeskustelu”– tyypillisin yhdistelmä: SOAP+WSDL (+UDDI) + välitön vastaus

palvelukutsuun (synkroninen)• hyvä välineistötuki, helppo päästä alkuun• SOAPin kautta laajennettavuutta ja mukautettavuutta

– pelkkä http ja XML-operaatiot• yksinkertaisuus, matala aloituskynnys

• Dokumenttisiirrot– tietopaketti, fire and forget, ”putkiposti” (tai pyyntö- ja

vastausdokumentit)– SOAP + XML-dokumentit (esim. ebXML, Open CDA) +

synkroninen tai asynkroninen kutsutapa• joustavuus, laajennusten käyttö (sekä liikenteessä että sisällössä)

– mahdollista myös ilman SOAPia tai käyttäen SOAP + WSDL-tekniikoita

– pelkkä http ja XML-dokumentit

6

Pa lve lu akä yttä vä s o ve llu s

Pa lve lu nta r jo a ja

h ttp -p a lve lup yyn tö

h ttp -va sta u s

Pa lve lu akä yttä vä s o ve llu s

Pa lve lu nta r jo a ja

R e kis te r i

1 . (T o teu ta ja )Ju lka ise p a lve lu2 . Ets i p a lve lu

( ja to te u ta so vitin )

p a lve lu p yyn töva sta u s

3 . Ku tsu p a lve lu a

etäohjelmakutsu

vastaus

XML-RPC, SOAP, httpWSDLWSDL

UDDI

WSDLWSDL

SOAP

WSDL

”Tyypillinen” välineistötuettu web-sovelluspalvelu-arkitehtuuri

Etäohjelmakutsu yleisesti (eri vaihtoehtoja)

XML

7

L ä he ttä väs o ve llu s

Vasta an o tta vaso ve llus

p a lve lup yyn tö

(va sta u s)

So ve llu ks e nliittym ä

So ve llu kse nliittymä

R e kis te r i

2 . Ju lka ise / h a ep ro fiili, ra ke n n a

so vitin

3 . L ä h e tä ja va sta a n o tad o ku me n tte ja

1 . Ju lka ise / h a ep ro fiili,ra ke n n aso vitin

dokumentti

(dokumentti)

SOAP, http, FTP..

ebXML registry

XML, CDA (XML), (HTML, .doc)

SOAP

dokumentti

CPP CPP

CPA

Dokumenttipohjainen yhteistoiminta

ebXML esimerkkinä

CPA

8

Web-sovelluspalveluiden turvallisuus

• Web-palveluliikenne http-protokollaa ”tyypillisesti” käyttämällä luo tietoturva--aukon (liikenne läpi palomuurin portin 80)

• Yhteyden turvaaminen (salaus)– https, SSL (kevyt sovelluskehittäjälle, raskas suoritus)– VPN (vaatii lisätyötä, paikallisia asetuksia)

• Viestitason salaukset ja allekirjoitukset– SOAP-tasolla– XML digital signatures– vaativat lisätyötä, -suunnittelua ja sopimista

• Turvallisuusinfrastruktuurin käyttö– esim. JAAS Java-sovelluspalvelimille, NTLM + Kerberos Windows-

sisäverkoissa, sovelluspalvelinkohtaiset turvallisuuspiirteet– ”palomuuri-reikä” voidaan tukkia esim. sisältötietoisten palomuurien

avulla• Sovellustason tietoturva (sisäänkirjaus, yhteiset turvallisuuspalvelut)

tulossa vähitellen, ei selkeitä standardeja

9

Web-sovelluspalveluiden lupaukset• ”Alusta- ja tekniikkavaihtoehtojen tuki”

+ totta, merkki-, XML- ja Internet-pohjaisille sovelluksille runsaasti toteutusvälineitä eri alustoille

• ”Yleisten, laajalti levinneiden tekniikoiden hyödyntäminen”+ totta, Internet-tekniikat laajasti käytössä (myös terveydenhuollossa)

• ”Löysä kytkentä sovellusten välillä” (loose coupling)± RPC-tavan palveluiden käyttö on tiukkaa kytkentää, löysäämistä

dokumenttien tai tietopohjaisen käytön (kopioinnin) avulla± XML:ssä löysä kytkentä lisää joustavuutta mutta myös sovelluskohtaista

toteutustyötä± kytkentää tiukennetaan tietotyyppien (mm. Schema) ja lisämäärittelyjen

(mm. käytettävät SOAP-lisätasot) kautta• ”Palvelut ovat itsensä kuvaavia”

– XML-taso: metatason (kuvailutiedon) merkitys on edelleen sovittava sovellusten välillä ”<person>” (XML-merkkaus voi helpottaa ihmisen ymmärtämistä)

– WSDL-taso: vaikka liittymän (muuttunut) määritys luetaan haluttaessa, on toteutus silti tehtävä / muutettava vastaamaan määritystä

10

• ”Palvelut löydetään dynaamisesti ajon aikana”± onnistuu rekistereitä käyttämällä, onko kuitenkaan tavoitteena, myös

mediaattoreiden / integrointialustojen avulla reititykset ja muunnokset• ”Toimittajariippumattomuus”

+ ”peruspiirteitä” käyttämällä yhteentoimivuus ilman suuria muutoksia– epäyhteensopivuuksia, standardien versiot ja ”pinot”, puutteellinen

standardituki• ”Kevyt teknologia, helppo opittavuus”

+ pitää paikkansa yksinkertaisimpien käyttömallien kohdalla (XML+http, XML-RPC)

– jo SOAPin laajennusten käytössä paljon opiskeltavaa ja sovittavaa– määritysten ja versioiden lukumäärän jatkuva kasvu, määritysten väliset

suhteet

• Kaikki tukevat, vahvuutena alustaneutraalius, web-tekniikat• Paljon odotuksia, uuden tekniikan lastentaudit, kaikki tukevat

Web-sovelluspalveluiden lupaukset..

11

Käyttö terveydenhuollon sovellusintegraatiossa?

• http- ja XML-pohjaiset ratkaisut– yksinkertaiset peruspalvelut, avoimet ydinpalvelurajapinnat– kevyt toteutus ja käyttöönotto– reititys, turvallisuus ratkaistava ”erikseen”

• SOAP– laajennusmahdollisuudet (reititys, turvallisuus jne.) – työmäärä kasvaa laajennuksia käytettäessä

• SOAP, WSDL, (UDDI)– peruspalvelut, ydinpalvelurajapinnat, tiukasti integroidut sovellukset,

vuorovaikutteisuus– SOAPin edut, välinetuki (esim. WSDL -> valmis koodi), mutta myös välinetuessa

”yllättäviä” aukkoja• Dokumenttipohjaiset ratkaisut

– CDA-dokumenttien välitys– joustavuus (erilaiset kutsutavat, löyhä kytkentä)

• Sovelluspalvelimissa, integrointialustoissa, web-palvelimissa, tietokannoissa yhä enemmän käyttöä tukevia piirteitä

• Ilman lisätyötä vaativia turvallisuuspiirteitä vain organisaation sisällä tai täysin julkisissa sovelluksissa

12

Lopuksi• minimivaatimukset sovelluksille

– tarjoaja: web-palvelin, xml-parserit– hyödyntäjä: yhteyskomponentit (http), xml-parserit

• standardoinnissa monta osapuolta– IETF, W3C, OASIS, WS-I, BPMI, OMG, yks. yritykset..– eri standardiperheiden kerroksissa päällekkäisyyksiä, viime aikoina

lähentymistä mutta EI yhteistä ohjausta• web-palveluiden käytön laskutuksessa ei vakiintuneita

käytäntöjä, sopimuskohtaista, organisaation sisäistä, ei ”globaaleja palvelumarkkinoita”

• oikean tekniikkajoukon valinta erilaisiin vaatimuksiin+ aluksi käyttöön pisimmälle standardoituneet osat: perus-http(s)-

pohjaiset palvelut, XML, perus-SOAP ja sitten:+ keveys, avoimuus, nopea toteutus, ohjelmakutsut (WSDL) + laajennettavuus, varmennukset, reititykset, viestit (dokumentit)

menopeli monenlaiseen maastoonuusi tekniikkaperhe, ydin kypsymässähyödyntää vanhoja ajatuksia (liittymät, web-tekniikat)

vanhat sovellukset uusien palvelujen pohjanatoimii varmimmin (ja löytyy paras välinetuki), kun pitäydytään

peruspiirteissä ja -tekniikoissa

13

MateriaaliaComponent and Service Technology Families: Web Service technologies. PlugIT,

2003.

Newcomer E. Understanding web services – XML, WSDL, SOAP, and UDDI. Addison-Wesley, 2002.

Peltz C. Applying design issues and patterns in web services. DevX, Jupitermedia Corp., Hewlett-Packard, 2003.

Kunisetty S. Oracle9i Application Server – Three rules of thumb for architecting web services. The Middleware Architecture Series, Oracle Technology Network, September 2002.

Julkishallinnon XML-strategia. Työryhmämuistioita 18/2003, Valtiovarainministeriö, hallinnon kehittämisosasto. http://www.vm.fi/tiedostot/pdf/fi/40535.pdf

SOAP 1.1: http://www.w3.org/TR/SOAP/

SOAP 1.2: http://www.w3.org/2000/xp/Group/#drafts

WSDL 1.1: http://www.w3.org/TR/wsdl

UDDI: http://www.uddi.org/specification.html

ebXML: http://www.ebxml.org/specs/index.htm