Web-sovelluspalvelutekniikat (Web services)

Esitys aiheesta: "Web-sovelluspalvelutekniikat (Web services)"— Esityksen transkriptio:

1 Web-sovelluspalvelutekniikat (Web services)
Juha Mykkänen, Marko Sormunen Kuopion yliopisto, HIS-yksikkö HL7 SIG-seminaarin, Helsinki, pohjalta laajennettu versio, 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 -> TP Monitors (Tuxedo jne.) olio-ominaisuudet TP Monitoreihin -> oliosanomavälittimet (CORBA, COM, RMI) viestijonot TP Monitoreihin -> MOM, message-oriented middleware (MSMQ, MQSeries, monet integrointialustat jne.) Internet-tekniikat mukaan -> 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ä: SOAP+WSDL (+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)
XML-RPC, SOAP, http WSDL WSDL XML vastaus ”Tyypillinen” välineistötuettu web-sovelluspalvelu-arkitehtuuri UDDI WSDL WSDL SOAP WSDL

7 Dokumenttipohjainen yhteistoiminta
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-node:jen 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: " <SOAP-ENV:Envelope xmlns:xsi=" xmlns:xsd=" xmlns:SOAP-ENV=" <SOAP-ENV:Body> <ns1:reverse xmlns:ns1=" SOAP-ENV:encodingStyle= " <st xsi:type="xsd:string">Pineapplesoft</st> </ns1:reverse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

10 SOAP-dokumenttiviesti header
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=" xmlns:ar=" <SOAP-ENV:Header> <ar:MessageHeader SOAP-ENV:mustUnderstand="1"> <ar:From> <ar:PartyId> koodistopalvelin..</ar:PartyId> <ar:Role>codeServer</ar:Role> </ar:From> <ar:To> <ar:PartyId> </ar:PartyId> <ar:Role>codeUser</ar:Role> </ar:To> <ar:CPAId> </ar:CPAId> <ar:ConversationId> </ar:ConversationId> <ar:Service>codeServer</ar:Service> <ar:Action>termItemEntry</ar:Action> <ar:MessageData> <ar:MessageId> koodistopalvelin </ar:MessageId> <ar:Timestamp> T16:38:17</ar:Timestamp> </ar:MessageData> </ar:MessageHeader> <ar:AckRequested SOAP-ENV:mustUnderstand="1"/> <ar:HL7FIBodyCount SOAP-ENV:mustUnderstand="1">1</ar:HL7FIBodyCount> </SOAP-ENV:Header>

11 SOAP-dokumenttiviesti body
<SOAP-ENV:Body> <document xmlns:xsi=" xsi:noNamespaceSchemaLocation="koodistosiirto_V05.xsd"> <header>Stakes koodistopalvelin ohjelmisto: Datawell: CodeServer 3.0 [ ]</header> <body> <termSystem id=" " language="fi" beginDate=" T00:00:01.0" expirationDate=" T23:59:59.0" lastModifiedDate=" T10:19:52.0" lastModifiedBy="Lehtonen, Jari"> <attribute type="longname" dataType="ST" language="fi">HL7-Laeaekkeenantolaite 2003</attribute> <attribute type="status" dataType="ST">1</attribute> … </termSystem> </body> </document> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

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 <?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions targetNamespace=" xmlns=" xmlns:wsdl=" xmlns:xsd=" xmlns:soapenc=" xmlns:wsdlsoap=" xmlns:apachesoap=" xmlns:intf=" xmlns:impl=" <wsdl:message name="identifyByUserNameRequest"> <wsdl:part name="userName" type="xsd:string" /> </wsdl:message> <wsdl:message name="identifyByUserNameResponse"> <wsdl:part name="identifyByUserNameReturn" type="xsd:string" /> <wsdl:portType name="LDAPServant"> <wsdl:operation name="identifyByUserName" parameterOrder="userName"> <wsdl:input name="identifyByUserNameRequest" message="impl:identifyByUserNameRequest" /> <wsdl:output name="identifyByUserNameResponse" message="impl:identifyByUserNameResponse" /> </wsdl:operation> </wsdl:portType>

14 <wsdl:binding name="LDAPWebServiceSoapBinding" type="impl:LDAPServant">
<wsdlsoap:binding style="rpc" transport=" /> <wsdl:operation name="identifyByUserName"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="identifyByUserNameRequest"> <wsdlsoap:body use="encoded" encodingStyle=" namespace=" /> </wsdl:input> <wsdl:output name="identifyByUserNameResponse"> namespace=" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="LDAPServantService"> <wsdl:port name="LDAPWebService" binding="impl:LDAPWebServiceSoapBinding"> <wsdlsoap:address location=" /> </wsdl:port> </wsdl:service> </wsdl:definitions>

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” wsdl:binding:istä ”löytyviä” rpc tai document (<wsdlsoap:binding style=..>) encoded tai literal (<wsdlsoap:body use=..> vaikuttavat WSDL:stä 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 WSDL:n 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 <message name="myMethodRequest"> <part name="x" type="xsd:int"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's 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:ää) <soap:envelope> <soap:body> <myMethod> <x xsi:type="xsd:int">5</x> </myMethod> </soap:body> </soap:envelope>

17 rpc/literal <message name="myMethodRequest"> <part name="x" type="xsd:int"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's RPC/literal. --> yksinkertainen WSDL, operaation nimi näkyy, tyyppitietoa ei SOAPissa validointi vaikeaa (edelleen vain myMethod-sisäinen määrittely schemassa) <soap:envelope> <soap:body> <myMethod> <x>5</x> </myMethod> </soap:body> </soap:envelope>

18 document/literal <types> <schema> <element name="xElement" type="xsd:int"/> </schema> </types> <message name="myMethodRequest"> <part name="x" element="xElement"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's document/literal. --> tyyppitietoa ei SOAPissa, schemassa määritelty koko SOAP body WSDL:n luettavuus kärsii, operaation nimeä ei ole SOAPissa (välineen vaikeaa yhdistää vastaavaan metodiin) <soap:envelope> <soap:body> <xElement>5</xElement> </soap:body> </soap:envelope>

19 document/literal wrapped
<types> <schema> <element name="myMethod"/> <complexType> <sequence> <element name="x" type="xsd:int"/> </sequence> </complexType> </element> </schema> </types> <message name="myMethodRequest"> <part name="parameters" element="myMethod"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> 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 <soap:envelope> <soap:body> <myMethod> <x>5</x> </myMethod> </soap:body> </soap:envelope>

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, WSDL:n 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 sovellusintegraatiossa? 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?
http+XML hajautus, avointen Internet-tekniikoiden hyödyntäminen, sovitut rajapinnat, ymmärrettävyys suhteellisen kevyt toteutettavuus myös vanhoihin ympäristöihin http+SOAP+XML 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. <ar:Action>-elementti) http+SOAP+WSDL sovelluskehityksen suoraviivaisuus (WSDL->ohjelmointikieli->WSDL) välinetuki, tekniikat halutessa pois näkyvistä omimmillaan operaatiot (API-rajapinnat) ohjelmointiympäristöissä dokumentit integrointialustoissa tai –välineissä kehityksen suunta (WSDL:n 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 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ä (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 (XML+http, 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.1:n ja 1.2:n 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 -> 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ä YK:n 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? http+XML -> SOAP+WSDL 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: 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/WSDL:ksi? 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 CDA:ssa, ”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 Jatko CDAr2 SerAPI-jatkohanke

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-integraatio 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 ja muutkin kuin tekninen näkökulma