1 / 13

Web-sovelluspalvelut terveydenhuollossa?

Web-sovelluspalvelut terveydenhuollossa?. Juha Mykkänen, Marko Sormunen, PlugIT, Kuopion yliopisto, HIS-yksikkö PlugIT-puolivuotisseminaari, Kuopio, 28.10.2003. Esityksen sisältö. Web-sovelluspalveluiden (Web Services) idea ja määritelmä Tekniikat ja käyttötavat

ganit
Download Presentation

Web-sovelluspalvelut terveydenhuollossa?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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. 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. 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. 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 (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

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

  13. Materiaalia Component 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

More Related