310 likes | 544 Vues
2. Katsaus. Perustekniikat lyhyesti K?ytt?tapojen perusvaihtoehdotSOAP ja WSDL-k?ytt?tapojaTurvallisuuden tasotTekniikoiden lupaukset ja "lupaukset"Standardointi K?ytt? terveydenhuollon sovelluksissaKonteksti : SerAPI-projekti, Tausta: PlugIT-projekti, Komponentti-FixIT-projekti. 3. Hajaute
E N D
1. Web-sovelluspalvelutekniikat(Web services) Juha Mykknen, Marko Sormunen Kuopion yliopisto, HIS-yksikk
HL7 SIG-seminaarin, Helsinki, 10.3.2004
pohjalta laajennettu versio, 16.11.2004
2. 2 Katsaus Perustekniikat lyhyesti
Kytttapojen perusvaihtoehdot
SOAP ja WSDL-kytttapoja
Turvallisuuden tasot
Tekniikoiden lupaukset ja lupaukset
Standardointi
Kytt terveydenhuollon sovelluksissa
Konteksti : SerAPI-projekti, Tausta: PlugIT-projekti, Komponentti-FixIT-projekti
3. 3 Hajautetun vliohjelmiston (Middleware) historiallinen kehityskaari etohjelmakutsut (RPC)
transaktiot mukaan -> TP Monitors (Tuxedo jne.)
olio-ominaisuudet TP Monitoreihin -> oliosanomavlittimet (CORBA, COM, RMI)
viestijonot TP Monitoreihin -> MOM, message-oriented middleware (MSMQ, MQSeries, monet integrointialustat jne.)
Internet-tekniikat mukaan -> Web services
ja niille ensimmisen etohjelmakutsut
ei revoluutio, vaan evoluutio
4. 4 Web-sovelluspalvelutekniikat Tiedon siirtoesitys ja siirto
tiedonvlitys verkossa yleens http siirtoprotokollan avulla
SOAP, mrittelee kirjekuoren siirrettvlle sanomalle, voidaan kytt eri siirtoprotokollien pll (http, shkposti, FTP, Jabber..)
Rajapintojen (tiedot, toiminnot) mrittely
WSDL, mrittelee operaatiot, tietotyypit ja sidonnat alemman tason protokolliin (esim. SOAP), luodaan/luetaan yleens automaattisesti vlineill
XML-RPC kytt http-protokollaa, mrittelee yksinkertaisia etohjelmakutsuja
ebXML CPP/A tai muut XML-dokumenttimritykset voivat mritell tiedonsiirrossa kytettvi dokumenttityyppej ja -merkkauksia
Palveluiden dynaaminen lytminen, rekisterit
UDDI
ebXML registry, vlipalvelin..)
Lismritykset (-tasot)
toimintaprosessien mrittely, sopimukset, reititys, turvallisuus jne.
SOAP, WSDL, UDDI, ebXML, XML-RPC jne. perustuvat XML:n, ja pelkk XML: mahdollista kytt eri tasoilla
5. 5 Web-sovelluspalveluiden kytttapoja Palvelukutsut
etoperaatio, RPC, pyynt - vastaus, puhelinkeskustelu
tyypillisin yhdistelm: SOAP+WSDL (+UDDI) + vlitn vastaus palvelukutsuun (synkroninen)
vlineistt piilottavat tekniikat, helppo pst 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 kytt (sek liikenteess ett sisllss)
mahdollista mys ilman SOAPia tai kytten 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 vlityksen ja ksittelyn tiedot, turvallisuus, autentikointi, transaktio)
body (XML-sislt, dokumentti tai operaatiokutsu tai -vastaus)
(liitteet)
viestien vaihto SOAP-node:jen vlill
sender, receiver, intermediary
vlinetuki nojautuu osin nimemiskytntihin (response, request jne.)
asynkronista viestint varten headerin kentill mustUnderstand arvoja
viestien kustomointi SOAP-tasolla tarkoituksena
voidaan kytt joustavasti ja monella tavalla
mutta kutakin kustomoitua kohtaa varten pit ohjelmiston tiet mit tehd
versiot 1.1 ja 1.2, jlkimminen 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 liittymn mrittely
kuvauksen osat
types: tyyppijrjestelm (esim. Schema)
message: tyypitetty siirrettv tieto
part: tiedon elementti
portType: kokoelma toimintoja
operation: palvelun tukema toiminto
input, output, viittaa messageen
binding: protokolla, jota kutsumiseen kytetn (tarkentaa edellisi)
viittaa portTypeen
operation,
input, output
service: liittympisteiden kokoelma
port: verkon liittympiste, 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-kytttavat valitaan kytttarpeen perusteella: halutaanko validoida schema, haittaako ylimrisen tyyppitiedon siirtminen SOAPin yli, halutaanko pit WSDL-mrittely luettavana, halutaanko ksitell operaatioita
wsdl:binding:ist lytyvi
rpc tai document (<wsdlsoap:binding style=..>)
encoded tai literal (<wsdlsoap:body use=..>
vaikuttavat WSDL:st syntyvn SOAPiin ja asettavat vlineille yhteentoimivuushaasteita
rpc/encoded
yksinkertainen WSDL, operaation nimi nkyviss (helppo yhdist toteutukseen)
tyyppitieto (ylimrist SOAPissa), validointi vaikeaa (vain myMethod-mrittely on schemassa, loput WSDL:)
rpc/literal
yksinkertainen WSDL, operaation nimi nkyy, tyyppitietoa ei SOAPissa
validointi vaikeaa (edelleen vain myMethod-sisinen mrittely schemassa)
(document/encoded)
document/literal
tyyppitietoa ei SOAPissa, schemassa mritelty koko SOAP body
WSDL:n luettavuus krsii, operaation nime ei ole SOAPissa (vlineen vaikeaa yhdist vastaavaan metodiin)
document/literal wrapped
SOAPissa ei tyyppitietoa, schemassa mritelty koko SOAP body, operaation nimi ujutetaan elementtin takaisin sanomaan
WSDL on monimutkainen, ei voi kytt 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 lytmiseen (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 enimmkseen ihmisten luettaviksi tarkoitettuja: vaikka esim. operaatiokuvaus saadaan rekisterist, ei parametrien merkityst ole kuvattu
onko avoimelle palveluhakemistolle todellinen tarve esim. terveydenhuollon sovellusintegraatiossa?
lhinn monien osoitteiden lytyminen 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 millkin tekniikalla? http+XML
hajautus, avointen Internet-tekniikoiden hydyntminen, sovitut rajapinnat, ymmrrettvyys
suhteellisen kevyt toteutettavuus mys vanhoihin ympristihin
http+SOAP+XML
kirjekuoren hydyt: osoitteet, aikaleimat, palautus jos viesti ei voitu toimittaa tai postinumero on vrin, sislln piilotus, omat koristelut
viestinvlitys: jos kytetn reitityst, integrointialustaa, salausta, autentikointia tms, headerin ksittely erilln sisllst
dokumenttisislt monta tapaa toteuttaa rajapintoja (mys operaatiot onnistuvat: ks. <ar:Action>-elementti)
http+SOAP+WSDL
sovelluskehityksen suoraviivaisuus (WSDL->ohjelmointikieli->WSDL)
vlinetuki, tekniikat halutessa pois nkyvist
omimmillaan operaatiot (API-rajapinnat) ohjelmointiympristiss
dokumentit integrointialustoissa tai vlineiss
kehityksen suunta (WSDL:n plle tulevat standardit, esim. prosessien mrittely BPEL4WS)
22. 22 Web-sovelluspalveluiden turvallisuus Web-palveluliikenne http-protokollaa
tyypillisesti kyttmll luo tietoturva-
aukon (sovellusliikenne lpi palomuurin
selainportin 80)
Yhteyden turvaaminen (salaus)
https, SSL (kevyt sovelluskehittjlle, raskas suoritus)
VPN (vaatii listyt, paikallisia asetuksia)
Viestitason salaukset ja allekirjoitukset
SOAP-tasolla
XML digital signatures
vaativat listyt, -suunnittelua ja sopimista
Turvallisuusinfrastruktuurin kytt (ei en alustaneutraalia!)
esim. JAAS Java-sovelluspalvelimille, NTLM + Kerberos Windows-sisverkoissa, sovelluspalvelinkohtaiset turvallisuuspiirteet
palomuuri-reik voidaan tukkia esim. sislttietoisten palomuurien avulla
Sovellustason tietoturva (sisnkirjaus, yhteiset turvallisuuspalvelut) tulossa vhitellen, ei selkeit standardeja
23. 23 Web-sovelluspalveluiden lupaukset Alusta- ja tekniikkavaihtoehtojen tuki
totta, merkki-, XML- ja Internet-pohjaisille sovelluksille runsaasti toteutusvlineit eri alustoille
Yleisten, laajalti levinneiden tekniikoiden hydyntminen
totta, Internet-tekniikat laajasti kytss (mys terveydenhuollossa)
Lys kytkent sovellusten vlill (loose coupling)
RPC-tavan palveluiden kytt on tiukkaa kytkent, lysmist dokumenttien tai tietopohjaisen kytn (kopioinnin) avulla
XML:ss lys kytkent lis joustavuutta mutta mys sovelluskohtaista toteutustyt
kytkent tiukennetaan tietotyyppien (mm. Schema) ja lismrittelyjen (mm. kytettvt SOAP-listasot) kautta
Palvelut ovat itsens kuvaavia
XML-taso: metatason (kuvailutiedon) merkitys on edelleen sovittava sovellusten vlill <person> (XML-merkkaus voi helpottaa ihmisen ymmrtmist)
WSDL-taso: vaikka liittymn (muuttunut) mritys luetaan haluttaessa, on toteutus silti tehtv / muutettava vastaamaan mrityst
(vasta) tutkimusaiheena semanttinen web, yleisten ontologioiden mrittely ja kytt
24. 24 Palvelut lydetn dynaamisesti ajon aikana
onnistuu rekistereit kyttmll, onko kuitenkaan tavoitteena, mys mediaattoreiden / integrointialustojen avulla reititykset ja muunnokset
Toimittajariippumattomuus
peruspiirteit kyttmll yhteentoimivuus ilman suuria muutoksia
epyhteensopivuuksia, standardien versiot ja pinot, puutteellinen standardituki
Kevyt teknologia, helppo opittavuus
pit paikkansa yksinkertaisimpien kyttmallien kohdalla (XML+http, XML-RPC) + vlineet tekevt paljon WSDL-SOAPin joillain tyyleill
jo SOAPin laajennusten kytss paljon opiskeltavaa ja sovittavaa
mritysten ja versioiden lukumrn jatkuva kasvu, mritysten vliset 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 kytettvt standardit
eivt tule korvaamaan jo tehtyj ratkaisuja (EDI, HL7 jne.)
ratkaisut rakennetaan olemassa olevien sovellusten plle -> niiden vaikutus nkyy mys uusilla tekniikoilla
suorituskyky
liskerroksia muutenkin monimutkaisiin jrjestelmiin
XML (tiedonsiirto, DOM-parserit)
Web-sovelluspalvelut normaaleina sovelluksina
tietokoneiden kyttmi sovelluksia, ei kyttliittym kutsun seurauksena
tavoitteena A2A (RPC) tai B2B (dokumentit) (ei B2C)
luottamuskysymykset sovellusten vlill (ulkoiset web-palvelut)
Uudet vlineet 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 vliset ratkaisut
SOAPilla turvallisuutta, integrointialustojen kytt reititykseen jne., mys asynkroninen kytt
XML ei erityisen kytnnllist massasiirroissa
adapterikehitys, loose binding
(Keskitetyt tai sovellusten vliset) palvelut
kyttjn ja yllpitjn tyn helpottaminen (pllekkisyyden vheneminen)
vlitn vastaus, kevyt toteutus moniin sovelluksiin?
http+XML -> SOAP+WSDL jos vlineet tukevat (tymr kasvaa joka lyhenteest ilman vlineit)
sovellusten muuttaminen (adapteri + oma toteutus?), sovellusten luottamus
Kyttjlle tarvittavat palvelut, kyttliittymintegraatio
eivt 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) plle
28. 28 HL7 international ja (web) services Common Terminology Services-mritys
Messaging API
Vocabulary API (vastaavuudet PlugIT-mrityksiin)
sislt esimerkit Java-tykalujen kautta WSDL-rajapinnoista
ServicesBOF: servicesbof@lists.hl7.org
Jo CCOW oli API-rajapinta, keskustelua siit mill kielell rajapinnat mriteltv (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
viestinvlitys, tietojen siirto (ja kopiointi?)
HL7 Common Services SIG + PlugIT
pienemmt operaatiot, kyttjlheisyys, enemmn kutsuja, pienempi tietojoukkoja
PlugIT http- ja XML-mritysten pivitys SOAP/WSDL:ksi?
Open CDA ja r2-sisltjen hydyntminen
palvelukutsut, tietojen keskitys (ja riippuvuus keskitetyst palvelusta?)
Ristiinhydyntminen: CDA henkiltietolomake PlugITissa, Open CDA koodistosiirto PlugITissa, PlugIT PIDS potilasrajapinta Open CDA:ssa, typytintegraatio kans. terveyshankkeessa
molemmissa pohjana kansainvliset toimialan standardit
Paikalliset ja kahdenvliset ratkaisut
http ja XML yleisi, selaimen kynnistykset jne.
XML-RPC-toteutuksia
SOAP-toteutuksia
Jatko
CDAr2
SerAPI-jatkohanke
30. 30 Lopuksi oikean tekniikkajoukon valinta erilaisiin vaatimuksiin
aluksi kyttn pisimmlle 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