Web-sovelluspalvelutekniikat (Web services)

1
Web-sovelluspalvelutekniikat(Web services)

• Juha Mykkänen, Marko Sormunen Kuopion yliopisto,
  HIS-yksikkö
• HL7 SIG-seminaarin, Helsinki, 10.3.2004
• pohjalta laajennettu versio, 16.11.2004

toimiiko ollenkaan?
huippu-uutuus?
vanhaa tavaraa uudessa paketissa?
2
Katsaus

• Perustekniikat lyhyesti
• Käyttötapojen perusvaihtoehdot
• SOAP ja WSDL-käyttötapoja
• Turvallisuuden tasot
• Tekniikoiden lupaukset ja lupaukset
• Standardointi
• Käyttö terveydenhuollon sovelluksissa
• Konteksti SerAPI-projekti, Tausta
  PlugIT-projekti, Komponentti-FixIT-projekti

3
Hajautetun väliohjelmiston (Middleware)
historiallinen kehityskaari

• etäohjelmakutsut (RPC)
• transaktiot mukaan -gt TP Monitors (Tuxedo jne.)
• olio-ominaisuudet TP Monitoreihin -gt
  oliosanomavälittimet (CORBA, COM, RMI)
• viestijonot TP Monitoreihin -gt MOM,
  message-oriented middleware (MSMQ, MQSeries,
  monet integrointialustat jne.)
• Internet-tekniikat mukaan -gt Web services
• ja niille ensimmäisenä etäohjelmakutsut
• ei revoluutio, vaan evoluutio

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ä (http, sähköposti, FTP, Jabber..)
• Rajapintojen (tiedot, toiminnot) määrittely
• WSDL, määrittelee operaatiot, tietotyypit ja
  sidonnat alemman tason protokolliin (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 käyttötapoja

• Palvelukutsut
• etäoperaatio, RPC, pyyntö - vastaus,
  puhelinkeskustelu
• tyypillisin yhdistelmä SOAPWSDL (UDDI)
  välitön vastaus palvelukutsuun (synkroninen)
• välineistöt piilottavat tekniikat, 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
Etäohjelmakutsu yleisesti (eri vaihtoehtoja)
etäohjelmakutsu
XML-RPC, SOAP, http
WSDL
WSDL
vastaus
XML
Tyypillinen välineistötuettu web-sovelluspalvelu
-arkitehtuuri
UDDI
WSDL
WSDL
SOAP
WSDL
7
Dokumenttipohjainen yhteistoiminta
dokumentti
SOAP, http, FTP..
(dokumentti)
XML, CDA (XML), (HTML, .doc)
ebXML esimerkkinä
ebXML registry
CPP
CPP
CPA
SOAP
dokumentti
CPA
8
SOAP-tiedonsiirto

• kirjekuori XML-sanomille
• envelope (viestin alku ja loppu)
• header (viestin välityksen ja käsittelyn tiedot,
  turvallisuus, autentikointi, transaktio)
• body (XML-sisältö, dokumentti tai operaatiokutsu
  tai -vastaus)
• (liitteet)
• viestien vaihto SOAP-nodejen välillä
• sender, receiver, intermediary
• välinetuki nojautuu osin nimeämiskäytäntöihin
  (response, request jne.)
• asynkronista viestintää varten headerin kentillä
  mustUnderstand arvoja
• viestien kustomointi SOAP-tasolla tarkoituksena
• voidaan käyttää joustavasti ja monella tavalla
• mutta kutakin kustomoitua kohtaa varten pitää
  ohjelmiston tietää mitä tehdä
• versiot 1.1 ja 1.2, jälkimmäinen tarkempi (ja
  joustavampi)

9
http SOAP RPC-kutsu

• POST /ibm-soap/rpcrouter.jsp HTTP/1.1
• Host localhost
• Content-Type text/xml charset"utf-8"
• Content-Length 484
• SOAPAction "http//www.psol.com/soap/reverse"
• ltSOAP-ENVEnvelope
• xmlnsxsi"http//www.w3.org/1999/XMLSchema/ins
  tance/"
• xmlnsxsd"http//www.w3.org/1999/XMLSchema/"
• xmlnsSOAP-ENV"http//schemas.xmlsoap.org/soap
  /envelope/"gt
• ltSOAP-ENVBodygt
• ltns1reverse
• xmlnsns1"http//www.psol.com/soap/rever
  se"
• SOAP-ENVencodingStyle
  "http//schemas.xmlsoap.org/soap/encoding/"gt
• ltst xsitype"xsdstring"gtPineapplesoftlt/
  stgt
• lt/ns1reversegt
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

10
SOAP-dokumenttiviesti header

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltSOAP-ENVEnvelope xmlnsSOAP-ENV"http//schemas.
  xmlsoap.org/soap/envelope/" xmlnsar"http//www.h
  l7.fi/ar2002/refdb"gt
• ltSOAP-ENVHeadergt
• ltarMessageHeader SOAP-ENVmustUnderstand"1"gt
• ltarFromgt
• ltarPartyIdgt1.2.246.537.10..koodistopalvelin..
  lt/arPartyIdgt
• ltarRolegtcodeServerlt/arRolegt
• lt/arFromgt
• ltarTogt
• ltarPartyIdgt1.2.246.537.10.245.1lt/arPartyIdgt
• ltarRolegtcodeUserlt/arRolegt
• lt/arTogt
• ltarCPAIdgt1.2.246.777.11.2003.1lt/arCPAIdgt
• ltarConversationIdgt1.2.246.537.10..107530024708
  8lt/arConversationIdgt
• ltarServicegtcodeServerlt/arServicegt
• ltarActiongttermItemEntrylt/arActiongt
• ltarMessageDatagt
• ltarMessageIdgt1.2.246.537.10..koodistopalvelin
  ..1075300697375lt/arMessageIdgt
• ltarTimestampgt2004-01-28T163817lt/arTimestam
  pgt

11
SOAP-dokumenttiviesti body

• ltSOAP-ENVBodygt
• ltdocument xmlnsxsi"http//www.w3.org/2001/XMLS
  chema-instance" xsinoNamespaceSchemaLocation"koo
  distosiirto_V05.xsd"gt
• ltheadergtStakes koodistopalvelin ohjelmisto
  Datawell CodeServer 3.0 20031214lt/headergt
• ltbodygt
• lttermSystem id"1.2.246.777.5.164.2003.1"
  language"fi" beginDate"2003-01-01T000001.0"
  expirationDate"2020-12-31T235959.0"
  lastModifiedDate"2003-12-02T101952.0"
  lastModifiedBy"Lehtonen, Jari"gt
• ltattribute type"longname" dataType"ST"
  language"fi"gtHL7-Laeaekkeenantolaite
  2003lt/attributegt
• ltattribute type"status" dataType"ST"gt1lt/att
  ributegt
• lt/termSystemgt
• lt/bodygt
• lt/documentgt
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

12
WSDL-rajapintakuvaus

• web-sovelluspalvelun liittymän määrittely
• kuvauksen osat
• types tyyppijärjestelmä (esim. Schema)
• message tyypitetty siirrettävä tieto
• part tiedon elementti
• portType kokoelma toimintoja
• operation palvelun tukema toiminto
• input, output, viittaa messageen
• binding protokolla, jota kutsumiseen käytetään
  (tarkentaa edellisiä)
• viittaa portTypeen
• operation,
• input, output
• service liittymäpisteiden kokoelma
• port verkon liittymäpiste, binding ja
  verkko-osoite

13

• lt?xml version"1.0" encoding"UTF-8" ?gt
• ltwsdldefinitions targetNamespace"http//kettinki
  .uku.fi81/axis/services/LDAPWebService"
  xmlns"http//schemas.xmlsoap.org/wsdl/"
  xmlnswsdl"http//schemas.xmlsoap.org/wsdl/"
  xmlnsxsd"http//www.w3.org/2001/XMLSchema"
  xmlnssoapenc"http//schemas.xmlsoap.org/soap/enc
  oding/" xmlnswsdlsoap"http//schemas.xmlsoap.org
  /wsdl/soap/" xmlnsapachesoap"http//xml.apache.o
  rg/xml-soap" xmlnsintf"http//kettinki.uku.fi81
  /axis/services/LDAPWebService" xmlnsimpl"http//
  kettinki.uku.fi81/axis/services/LDAPWebService"gt
• ltwsdlmessage name"identifyByUserNameRequest"gt
• ltwsdlpart name"userName" type"xsdstring" /gt
  
• lt/wsdlmessagegt
• ltwsdlmessage name"identifyByUserNameResponse"gt
• ltwsdlpart name"identifyByUserNameReturn"
  type"xsdstring" /gt
• lt/wsdlmessagegt
• ltwsdlportType name"LDAPServant"gt
• ltwsdloperation name"identifyByUserName"
  parameterOrder"userName"gt
• ltwsdlinput name"identifyByUserNameRequest"
  message"implidentifyByUserNameRequest" /gt
• ltwsdloutput name"identifyByUserNameResponse"
  message"implidentifyByUserNameResponse" /gt
• lt/wsdloperationgt
• lt/wsdlportTypegt

14

• ltwsdlbinding name"LDAPWebServiceSoapBinding"
  type"implLDAPServant"gt
• ltwsdlsoapbinding style"rpc" transport"http//sc
  hemas.xmlsoap.org/soap/http" /gt
• ltwsdloperation name"identifyByUserName"gt
• ltwsdlsoapoperation soapAction"" /gt
• ltwsdlinput name"identifyByUserNameRequest"gt
• ltwsdlsoapbody use"encoded"
• encodingStyle"http//schemas.xmlsoap.org/so
  ap/encoding/"
• namespace"http//ldap" /gt
• lt/wsdlinputgt
• ltwsdloutput name"identifyByUserNameResponse"
  gt
• ltwsdlsoapbody use"encoded"
• encodingStyle"http//schemas.xmlsoap.org/so
  ap/encoding/"
• namespace"http//kettinki.uku.fi81/axis/se
  rvices/LDAPWebService" /gt
• lt/wsdloutputgt
• lt/wsdloperationgt
• lt/wsdlbindinggt
• ltwsdlservice name"LDAPServantService"gt
• ltwsdlport name"LDAPWebService"
• binding"implLDAPWebServiceSoapBinding"gt

15
WSDL-käyttötavat

• valitaan käyttötarpeen perusteella halutaanko
  validoida schema, haittaako ylimääräisen
  tyyppitiedon siirtäminen SOAPin yli, halutaanko
  pitää WSDL-määrittely luettavana, halutaanko
  käsitellä operaatioita
• wsdlbindingistä löytyviä
• rpc tai document (ltwsdlsoapbinding style..gt)
• encoded tai literal (ltwsdlsoapbody use..gt
• vaikuttavat WSDLstä syntyvään SOAPiin ja
  asettavat välineille yhteentoimivuushaasteita
• rpc/encoded
• yksinkertainen WSDL, operaation nimi näkyvissä
  (helppo yhdistää toteutukseen)
• tyyppitieto (ylimääräistä SOAPissa), validointi
  vaikeaa (vain myMethod-määrittely on schemassa,
  loput WSDLää)
• rpc/literal
• yksinkertainen WSDL, operaation nimi näkyy,
  tyyppitietoa ei SOAPissa
• validointi vaikeaa (edelleen vain
  myMethod-sisäinen määrittely schemassa)
• (document/encoded)
• document/literal
• tyyppitietoa ei SOAPissa, schemassa määritelty
  koko SOAP body
• WSDLn luettavuus kärsii, operaation nimeä ei ole
  SOAPissa (välineen vaikeaa yhdistää vastaavaan
  metodiin)
• document/literal wrapped
• SOAPissa ei tyyppitietoa, schemassa määritelty
  koko SOAP body, operaation nimi ujutetaan
  elementtinä takaisin sanomaan
• WSDL on monimutkainen, ei voi käyttää
  polymorfisia operaatioita, ei sovi datagraafeihin

16
rpc/encoded

• ltmessage name"myMethodRequest"gt
• ltpart name"x" type"xsdint"/gt
• lt/messagegt
• ltmessage name"empty"/gt
• ltportType name"PT"gt
• ltoperation name"myMethod"gt
• ltinput message"myMethodRequest"/gt
• ltoutput message"empty"/gt
• lt/operationgt
• lt/portTypegt
• ltbinding .../gt
• lt!-- I won't bother with the details, just assume
  it's RPC/encoded. --gt

yksinkertainen WSDL, operaation nimi näkyvissä
(helppo yhdistää toteutukseen) tyyppitieto
(ylimääräistä SOAPissa), validointi vaikeaa (vain
myMethod-määrittely on schemassa, loput WSDLää)
ltsoapenvelopegt ltsoapbodygt ltmyMethodgt ltx
xsitype"xsdint"gt5lt/xgt lt/myMethodgt lt/soapbodygt
lt/soapenvelopegt
17
rpc/literal

• ltmessage name"myMethodRequest"gt
• ltpart name"x" type"xsdint"/gt
• lt/messagegt
• ltmessage name"empty"/gt
• ltportType name"PT"gt
• ltoperation name"myMethod"gt
• ltinput message"myMethodRequest"/gt
• ltoutput message"empty"/gt
• lt/operationgt
• lt/portTypegt
• ltbinding .../gt
• lt!-- I won't bother with the details, just assume
  it's RPC/literal. --gt

yksinkertainen WSDL, operaation nimi näkyy,
tyyppitietoa ei SOAPissa validointi vaikeaa
(edelleen vain myMethod-sisäinen määrittely
schemassa)
ltsoapenvelopegt ltsoapbodygt ltmyMethodgt ltxgt5lt/xgt lt/
myMethodgt lt/soapbodygt lt/soapenvelopegt
18
document/literal

• lttypesgt
• ltschemagt
• ltelement name"xElement" type"xsdint"/gt
• lt/schemagt
• lt/typesgt
• ltmessage name"myMethodRequest"gt
• ltpart name"x" element"xElement"/gt
• lt/messagegt
• ltmessage name"empty"/gt
• ltportType name"PT"gt
• ltoperation name"myMethod"gt
• ltinput message"myMethodRequest"/gt
• ltoutput message"empty"/gt
• lt/operationgt
• lt/portTypegt
• ltbinding .../gt
• lt!-- I won't bother with the details, just assume
  it's document/literal. --gt

tyyppitietoa ei SOAPissa, schemassa määritelty
koko SOAP body WSDLn luettavuus kärsii,
operaation nimeä ei ole SOAPissa (välineen
vaikeaa yhdistää vastaavaan metodiin)
ltsoapenvelopegt ltsoapbodygt ltxElementgt5lt/xElementgt
lt/soapbodygt lt/soapenvelopegt
19
document/literal wrapped

• lttypesgt
• ltschemagt
• ltelement name"myMethod"/gt
• ltcomplexTypegt
• ltsequencegt
• ltelement name"x" type"xsdint"/gt
• lt/sequencegt
• lt/complexTypegt
• lt/elementgt
• lt/schemagt
• lt/typesgt
• ltmessage name"myMethodRequest"gt
• ltpart name"parameters" element"myMethod"/gt
• lt/messagegt
• ltmessage name"empty"/gt
• ltportType name"PT"gt
• ltoperation name"myMethod"gt
• ltinput message"myMethodRequest"/gt
• ltoutput message"empty"/gt

ei tyyppitietoa, schemassa määritelty koko SOAP
body, operaation nimi ujutetaan elementtinä
takaisin sanomaan WSDL on monimutkainen, ei voi
käyttää polymorfisia operaatioita, ei sovi
datagraafeihin
ltsoapenvelopegt ltsoapbodygt ltmyMethodgt ltxgt5lt/xgt lt/
myMethodgt lt/soapbodygt lt/soapenvelopegt
20
UDDI-rekisterit

• palveluiden löytämiseen (SOAP)-operaatiot
• registration palvelukuvaus rekisteriin
• lookup palvelun haku
• useanlaista tietoa
• white pages palvelun tuottajatiedot
• yellow pages palvelun luokittelu (esim.
  hakukone, kirjakauppa)
• green pages palvelun rajapinta, WSDLn sijainti
  jne.
• julkiset ja yksityiset rekisterit
• muistuttaa naming service, trader service / CORBA
• mutta UDDI-rekisterit ovat enimmäkseen ihmisten
  luettaviksi tarkoitettuja vaikka esim.
  operaatiokuvaus saadaan rekisteristä, ei
  parametrien merkitystä ole kuvattu
• onko avoimelle palveluhakemistolle todellinen
  tarve esim. terveydenhuollon sovellusintegraatioss
  a?
• lähinnä monien osoitteiden löytyminen yhdestä
  paikasta, muun tyyppinen dynaaminen sidonta on
  jo systeemiohjelmointia (CORBA DII)
• hoidetaanko tarpeet (osoitteet yms.)
  paikallisella konfiguroinnilla, LDAP-/
  ActiveDirectory-hakemistoilla jne?

21
Mitä saavutetaan milläkin tekniikalla?

• httpXML
• hajautus, avointen Internet-tekniikoiden
  hyödyntäminen, sovitut rajapinnat, ymmärrettävyys
• suhteellisen kevyt toteutettavuus myös vanhoihin
  ympäristöihin
• httpSOAPXML
• kirjekuoren hyödyt osoitteet, aikaleimat,
  palautus jos viestiä ei voitu toimittaa tai
  postinumero on väärin, sisällön piilotus, omat
  koristelut
• viestinvälitys jos käytetään reititystä,
  integrointialustaa, salausta, autentikointia tms,
  headerin käsittely erillään sisällöstä
• dokumenttisisältö monta tapaa toteuttaa
  rajapintoja (myös operaatiot onnistuvat ks.
  ltarActiongt-elementti)
• httpSOAPWSDL
• sovelluskehityksen suoraviivaisuus
  (WSDL-gtohjelmointikieli-gtWSDL)
• välinetuki, tekniikat halutessa pois näkyvistä
• omimmillaan operaatiot (API-rajapinnat)
  ohjelmointiympäristöissä
• dokumentit integrointialustoissa tai välineissä
• kehityksen suunta (WSDLn päälle tulevat
  standardit, esim. prosessien määrittely BPEL4WS)

22
Web-sovelluspalveluiden turvallisuus

• Web-palveluliikenne http-protokollaa
• tyypillisesti käyttämällä luo tietoturva-
• aukon (sovellusliikenne läpi palomuurin
• selainportin 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ö (ei enää
  alustaneutraalia!)
• 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

23
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
• XMLssä 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ä ltpersongt
  (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ä
• (vasta) tutkimusaiheena semanttinen web, yleisten
  ontologioiden määrittely ja käyttö

24
Web-sovelluspalveluiden lupaukset..

• 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 (XMLhttp, XML-RPC) välineet tekevät
  paljon WSDL-SOAPin joillain tyyleillä
• jo SOAPin laajennusten käytössä paljon
  opiskeltavaa ja sovittavaa
• määritysten ja versioiden lukumäärän jatkuva
  kasvu, määritysten väliset suhteet
• Russel Butek WSDL usage styles IBM
  DeveloperWorks, Which style of WSDL shoud I use?
• Timo Tarhonen SOAP 1.1n ja 1.2n pikavertailu,
  Open CDA tulospaketti.

25
Lupaukset ja myytit

• Globaalit, kaikkialla käytettävät standardit
• eivät tule korvaamaan jo tehtyjä ratkaisuja (EDI,
  HL7 jne.)
• ratkaisut rakennetaan olemassa olevien
  sovellusten päälle -gt niiden vaikutus näkyy myös
  uusilla tekniikoilla
• suorituskyky
• lisäkerroksia muutenkin monimutkaisiin
  järjestelmiin
• XML (tiedonsiirto, DOM-parserit)
• Web-sovelluspalvelut normaaleina sovelluksina
• tietokoneiden käyttämiä sovelluksia, ei
  käyttöliittymää kutsun seurauksena
• tavoitteena A2A (RPC) tai B2B (dokumentit) (ei
  B2C)
• luottamuskysymykset sovellusten välillä (ulkoiset
  web-palvelut)
• Uudet välineet tukevat, vahvuutena
  alustaneutraalius, web-tekniikat
• Paisuneet odotukset, standardoinnin hajanaisuus,
  lastentaudit

26
Web-sovelluspalvelut -standardointi

• W3C
• XML-perusstandardit (Schema, Xpath, XML
  namespaces jne.), SOAP, arkkitehtuuri
• OASIS
• UDDI, (ebXML yhdessä YKn kanssa,
  XML.org-schemavarasto), turvallisuus (SAML jne.)
• WS-I
• profiles, WS-I basic profile, testaus jne.
• OMG
• WSDL mappings (C, CORBA ), UML Web Services
• JCP (Java)
• WS-Composite Application Framework, JAX-RPC, JAXR
  jne.

27
Integrointitarpeisiin vastaaminen

• Alueellinen tiedonsiirto
• tietojen saatavuuden ja siirron toteutus,
  tietoturva huomioiden
• dokumenttipohjaiset ratkaisut, organisaatioiden
  väliset ratkaisut
• SOAPilla turvallisuutta, integrointialustojen
  käyttö reititykseen jne., myös asynkroninen
  käyttö
• XML ei erityisen käytännöllistä massasiirroissa
• adapterikehitys, loose binding
• (Keskitetyt tai sovellusten väliset) palvelut
• käyttäjän ja ylläpitäjän työn helpottaminen
  (päällekkäisyyden väheneminen)
• välitön vastaus, kevyt toteutus moniin
  sovelluksiin?
• httpXML -gt SOAPWSDL jos välineet tukevat
  (työmäärä kasvaa joka lyhenteestä ilman
  välineitä)
• sovellusten muuttaminen (adapteri oma
  toteutus?), sovellusten luottamus
• Käyttäjälle tarvittavat palvelut,
  käyttöliittymäintegraatio
• eivät web-sovelluspalveluita (osin asiaan
  liittyviä Web Services for Remote Portals)
• voitaisiin tosin tukea esim. (Web service
  -kontekstipalvelun avulla)
• Prosessi-integraatio
• vaatii tapahtumia, operaatioita tai
  toiminnallisia dokumentteja
• BPEL4WS yms. rakentuvat SOAP/WSDL (tai ebXML
  perusstandardien) päälle

28
HL7 international ja (web) services

• Common Terminology Services-määritys
• Messaging API
• Vocabulary API (vastaavuudet PlugIT-määrityksiin)
• sisältää esimerkit Java-työkalujen kautta
  WSDL-rajapinnoista
• ServicesBOF servicesbof_at_lists.hl7.org
• Jo CCOW oli API-rajapinta, keskustelua siitä
  millä kielellä rajapinnat määriteltävä (ISO IDL
  vai HL7 IDL)
• XML ITS (Implementation Technology Specifications)

Harold Solbrig, Mayo Clinic Common Terminology
Services, Presented to the HL7 Service SIG, San
Diego, January 2004
29
Web-sovelluspalvelut terveydenhuollon
sovellusintegraatiossa Suomessa

• Avoimet rajapinnat
• HL7 CDA
• Avoimet rajapinnat Open CDA web
  services-valmius SOAP 1.1 (ja 1.2)
• dokumentti- tarvittaessa asynkroninen malli
• viestitiedot SOAP headerissa, XML (CDA) SOAP
  Bodyssa
• sanoma kuittaus malli
• viestinvälitys, tietojen siirto (ja kopiointi?)
• HL7 Common Services SIG PlugIT
• pienemmät operaatiot, käyttäjäläheisyys,
  enemmän kutsuja, pienempiä tietojoukkoja
• PlugIT http- ja XML-määritysten päivitys
  SOAP/WSDLksi?
• Open CDA ja r2-sisältöjen hyödyntäminen
• palvelukutsut, tietojen keskitys (ja riippuvuus
  keskitetystä palvelusta?)
• Ristiinhyödyntäminen CDA henkilötietolomake
  PlugITissa, Open CDA koodistosiirto PlugITissa,
  PlugIT PIDS potilasrajapinta Open CDAssa,
  työpöytäintegraatio kans. terveyshankkeessa
• molemmissa pohjana kansainväliset toimialan
  standardit
• Paikalliset ja kahdenväliset ratkaisut
• http ja XML yleisiä, selaimen käynnistykset jne.
• XML-RPC-toteutuksia
• SOAP-toteutuksia

30
Lopuksi

• 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
  (RPC-tyyli)
• laajennettavuus, varmennukset, reititykset,
  viestit (dokumentit)

• SerAPI-jatkohanke Web-sovelluspalvelut ja
  palveluarkkitehtuuri terveydenhuollon
  sovellustuotannossa ja integraatiossa
• palvelut oikeaan paikkaan, WS ei sovi kaikkeen
  (tarpeet), migraatio
• tieto-, palvelu-, käyttäjä- ja prosessi-integraati
  o
• teknisten nippelien piilotus vai opettelu?

menopeli monenlaiseen maastoon
uusi tekniikkaperhe, ydin kypsymässä
hyödyntää vanhoja ajatuksia (liittymät,
web-tekniikat) vanhat sovellukset uusien
palvelujen pohjana
toimii varmimmin (ja löytyy paras välinetuki),
kun pitäydytään peruspiirteissä ja -tekniikoissa
31
juha.mykkanen_at_uku.fi
ja muutkin kuin tekninen näkökulma