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

2. 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. 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. 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. 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. 6

7. 7

8. 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. 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" <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance/" xmlns:xsd="http://www.w3.org/1999/XMLSchema/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <ns1:reverse xmlns:ns1="http://www.psol.com/soap/reverse" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <st xsi:type="xsd:string">Pineapplesoft</st> </ns1:reverse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

10. 10 SOAP-dokumenttiviesti header <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ar="http://www.hl7.fi/ar2002/refdb"> <SOAP-ENV:Header> <ar:MessageHeader SOAP-ENV:mustUnderstand="1"> <ar:From> <ar:PartyId>1.2.246.537.10..koodistopalvelin..</ar:PartyId> <ar:Role>codeServer</ar:Role> </ar:From> <ar:To> <ar:PartyId>1.2.246.537.10.245.1</ar:PartyId> <ar:Role>codeUser</ar:Role> </ar:To> <ar:CPAId>1.2.246.777.11.2003.1</ar:CPAId> <ar:ConversationId>1.2.246.537.10..1075300247088</ar:ConversationId> <ar:Service>codeServer</ar:Service> <ar:Action>termItemEntry</ar:Action> <ar:MessageData> <ar:MessageId>1.2.246.537.10..koodistopalvelin..1075300697375</ar:MessageId> <ar:Timestamp>2004-01-28T16: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. 11 SOAP-dokumenttiviesti body <SOAP-ENV:Body> <document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="koodistosiirto_V05.xsd"> <header>Stakes koodistopalvelin ohjelmisto: Datawell: CodeServer 3.0 [20031214]</header> <body> <termSystem id="1.2.246.777.5.164.2003.1" language="fi" beginDate="2003-01-01T00:00:01.0" expirationDate="2020-12-31T23:59:59.0" lastModifiedDate="2003-12-02T10: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. 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. 13 <?xml version="1.0" encoding="UTF-8" ?> <wsdl:definitions targetNamespace="http://kettinki.uku.fi:81/axis/services/LDAPWebService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:intf="http://kettinki.uku.fi:81/axis/services/LDAPWebService" xmlns:impl="http://kettinki.uku.fi:81/axis/services/LDAPWebService"> <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:message> <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. 14 <wsdl:binding name="LDAPWebServiceSoapBinding" type="impl:LDAPServant"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="identifyByUserName"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="identifyByUserNameRequest"> <wsdlsoap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://ldap" /> </wsdl:input> <wsdl:output name="identifyByUserNameResponse"> <wsdlsoap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://kettinki.uku.fi:81/axis/services/LDAPWebService" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="LDAPServantService"> <wsdl:port name="LDAPWebService" binding="impl:LDAPWebServiceSoapBinding"> <wsdlsoap:address location="http://kettinki.uku.fi:81/axis/services/LDAPWebService" /> </wsdl:port> </wsdl:service> </wsdl:definitions>

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

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

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

19. 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 .../>

20. 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. 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. 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. 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. 24 �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. Web-sovelluspalveluiden lupaukset..

25. 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. 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. 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. 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@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)

29. 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. 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)

31. 31 juha.mykkanen@uku.fi