Veebiteenuste võlu ja valu

T.Tammet

Ilmunud Arvutimaailmas 2/07 kui "veebiteenused reeglite ikkes"

Veebiteenused on kasulik meetod tarkvara ehitamise juures. Veebiteenuste kasutusvaldkonnad ja tähtsus etteaimatavas tulevikus ainult laieneb. Samas on veebiteenuste mõiste ise ebaselge, kasutusel on palju väga erinevaid lähenemisi, ning üha vähem saavad arendajad aru, kuidas oleks mõttekas neid teenuseid ikkagi teha. Standardeid tuleb eri suundadest nagu Vändrast saelaudu, seejuures on standardid üha ebapraktilisemad ja nende sisu on tingitud peamiselt suurfirmade huvist üksteisele ja väikefirmadele nö ära panna.

Mis asi see "veebiteenus" üldse on? Laiemas mõttes tähendab "veebiteenus" nö harilikku veebi, selle erinevusega, et urlide avamist ja vormide täitmist teeb programm, ning tulemusi loeb ja kasutab samuti programm, mitte inimene. Teisisõnu, "veebiteenus" tähendab programmide omavahelist suhtlemist ja andmevahetust üle hariliku veebi.

Fraasi "veebiteenused" - inglise keeles "web services" - hakkas sajandivahetusel promoma Microsoft, kes soovis senised programmide omavahelised suhtlusstandardid EDI, CORBA, RMI ja isegi Microsofti oma DCOMi - uue, XML-põhise suhtlusstandardi vastu välja vahetada.

Vanade süsteemide hädad

Mis oli siis häda varasematel CORBAl, RMIl ja DCOMil? Ka nende standardite abil said programmid andmeid vahetada, ning needki standardid kasutasid internetti, nagu uuemad veebiteenusedki.

Peamiseks probleemiks oli varasemate standardite tohutu keerukus praktilises tarkvara-arenduses. Nende standardite kasutamine eeldas suurte spetsiifiliste teekide kasutamist, kusjuures näiteks eri tootjate ehitatud CORBA teegid omavahel enamasti tegelikult suhelda ei suutnud - mis siis, et nime poolest realiseerisid nad sama standardit.

Samuti oli arendajal väga raske ja ebamugav jälgida, mis infot programmid tegelikult siis omavahel vahetavad.

Uue veebimaailma võlud

Kuna igaüks oskab veebilehti avada ning pea kõik arendajad oskavad teha veebilehti ehitavaid ja täidetud vorme lugevaid programme, siis ei ole prveebi kaudu infovahetuse ehitamiseks - mis siis, et programmide jaoks - arendajatel vaja mingeid eriteeke kasutada või üldse midagi väga uut õppida.

Eriti mugavaks muutub olukord, kui ühe programmi poolt teisele programmile saadetud tekstist arendaja ise kergesti aru saab. Siis saab ta kergesti kontrollida, et saadetises ei oleks ilmseid vigu, samuti saab saadetise sisust suhteliselt lihtsalt aru: enamus asju on kirjutatud üpris selges inimkeeles.

Arvutid inimkeelsest tekstist paraku aru ei saa, sestap on vaja infovahetusel leida mingi kompromiss: tekst peab olema selline, et arendajal on lihtne tekstist ise aru saada, samas on tal aga lihtne kirjutada programmi, mis sellest tekstist samuti "aru saab".

Niisuguseks kompromiss-keeleks on kujunenud XML. XML on umbes nagu veebilehtede tegemiseks kasutatav HTML, kuid teda on mugavam arvutiga töödelda. Veebilehtede ehitamiseks XML otse hästi ei kõlba, sest ta ei sisalda spetsiaalseid kujunduselemente: XML on eeskätt universaalne, andmevahetuseks mõeldud süntaks ehk üldvorm, kus tekstide sisu antakse arendajate poolt vastavalt vajadusele.

Programmi poolt saadud tekstist arusaamine ei ole triviaalne

Siiamaani paistab kõik suhteliselt tore. Lepime kokku, et saadame programmide vahel XML tekste samamoodi, nagu harilikke veebilehti, ja kõik on õnnelikud. Niisugusel rõõmsal ja pisut anarhistlikul lähenemisel on isegi oma nimi: POX ehk "Plain Old XML".

Paraku tekib arendajal XML-ile otsa vaadates ikkagi küsimus, et kuidas õieti aru saada selles XML-s olevast infost. Kas mingi tekstilõik on number või kuupäev, nimi või aadress, link veebilehele või midagi muud?

XML-s antud teksti tähenduse täpne selgitamine on tegelikult näide palju üldisemast fundamentaalsest probleemist, et kuidas meie - või programmid - teise inimese või programmi saadetud tekstidest üldse aru saavad.

Veebiteenuste kontekstis enamasti ei püüta automaatselt aru saada tähenduse kogu sisust. Pigem soovitakse, et XML teksti lugev programm saaks aru andmetüüpidest lihtsamal tasemel: kas mingi tekstijupp on arv - sõltumatult sellest, kas seearv on toote hind või inimese pikkus -, kuupäev või lihtsalt ebaselge tähendusega tekst.

Kohe veebiteenuste algusaastatel tekkisid väikesed standardid selle kohta, et kuidas XML-s siis numbreid, kuupäevi, loetelusid ja struktuure esitada. Üks esimestest - ja siiamaani kasutusel olev - on nn XML-RPC. Selle standardi põhivõlu seisneb tema äärmises lihtsuses: standard on lihtsalt paar-kolm lehekülge pikk selgitav jutt (http://www.xmlrpc.com/spec) koos paari näitega. Autoriks on üks inimene - Dave Winer.

Monstrumstandardid ja ideede kaaperdamine

XML-RPC oli küll hästi lihtne, kuid mõningate asjade jaoks oli ta veidi piirav ja ebamugav. Sestap asuti välja töötama uusi ja võimsamaid standardeid, millest kõige kuulsam on nn SOAP: Simple Object Access Protocol. SOAP standardiga tegeleb üldise veebistandardite organisatsiooni W3C (w3c.org) komitee, kuhu kuuluvad eeskätt suurfirmade - Microsoft, IBM, Canon jne - esindajad.

Erinevalt lihtsast XML-RPC standardist on SOAP standardist - nime järgi lihtsast - kujunenud hiiglaslik monstrum, millest täielik arusaamine on praktiliselt võimatu, kasvõi juba seepärast, et standard on kohati udune ja vasturääkiv. Iseenesest lihtsate asjade tegemine SOAP standardi järgi on suhteliselt keerukas ettevõtmine.

Viimane asjaolu ei ole juhus: suurfirmad ei olegi enamasti huvitatud lihtsatest ja mugavalt kasutatavatest standarditest. Vastupidi: nende loomulikud huvid on tarkvara-arenduse üldises vaates destruktiivsed.

Ühest küljest soovivad suured tarkvarafirmad, et väikestel tarkvarafirmadel ja nn "sõltumatutel arendajatel" oleks raske tegevust alustada. Selleks promotakse neile lihtsate asjade tegemiseks hirmkeerulisi meetodeid, mis kas hirmutavad nad nimetatud valdkonnast üldse ära, või panevad neid kulutama väga palju aega ebaproduktiivsele tööle. Erinevates hangetes saab nõuda nö "toetust" suurele hulgale sisuliselt mittevajalikele standarditele, mida väiksemad arendajad ei pruugi suuta pakkuda.

Teisest küljest soovivad suurfirmad siduda arendajaid endatoodetud töövahenditega, selgitades arendajatele, et kui nad neid töövahendeid ei osta ja kasuta (sellega ennast ka tarkvarafirma operatsioonisüsteemist ja muudest toodetest sõltuvaks tehes), siis ei ole mingit praktilist võimalust üldse oma tarkvaratoodetega turule tulla.

Siinkirjeldatu ei ole mingi konspiratsiooniteooria: isiklikes vestlustes teiste standardikomitee liikmetega ning seotud osapooltega on näiteks Microsofti esindajad korduvalt kinnitanud taolist teadlikku, stateegilist eesmärki veebiteenuste standardite kujundamisel.

SOAP on siinkohas perfektne näide: SOAP-i ja temaga seotud standardeid lugedes saab kiiresti selgeks, et standardimeeskonna sõnum lugejale on umbes järgmine: "Ärge üldse lootkegi ise selle standardi järgi midagi teha, ostke parem kohe meie arendusvahendid ja arendusplatvormid. Kõige parem oleks, kui te ei tunnekski üldse huvi, mis meie arendusplatvormide sisemuses toimub.

SOAP standard on seejuures pidevas arengus, ning erinevad SOAP-i toetavad arendusplatvormid toetavad tema erinevaid versioone, täpsemalt: erinevaid alamhulki erinevatest versioonidest. Oleme tagasi CORBA-aegses olukorras, kus eri firmade või gruppide töövahendid, mis nime poolest nn "standardit" toetasid, tegelikult omavahel suhelda ei suutnud. Iseenesest pole siin ka midagi imelikku: majanduslikud taustahoovad on samad, ning mitmed SOAP standardi autorid olid ammustel aegadel aktiivsed CORBA arendajad.

SOAP sõnumid võivad samas endiselt olla suhteliselt lihtsad ja arusaadavad: probleem on potentsiaalselt lihtsa asja ümber ehitatud keerukas standardis.

SOAP on alles algus: seejärel tulevad mängu XML Schema, WSDL ning UDDI ...

SOAP standard ise ei kirjelda kõiki olulisi aspekte ühelt programmilt teisele saadetavas tekstis. See, kuidas XML tekstijuppe siis numbriteks või kuupäevadeks või mingiteks muudeks andmeteks tõlkida, on kirjas suhteliselt keerukas ja ambitsioonikas omaette-standardis XML Schema.

Lisaks eeldab enamik - kuid mitte kõik - SOAP teenuseid ja arendusvahendeid, et SOAP standardile vastava XML-tekstiga tuleb kuskilt kaasa eraldi suur kirjeldusfail, mis vastab ülikeerulisele ja segasele WSDL standardile, mis siis omakorda kasutab mainitud XML Schemat.

Kui mõni arendaja kõigest sellest vapralt läbi närib - ma olen oma silmaga selliseid inimesi näinud, Eesti vabariigis on neid mõni üksik, kuigi ka nemad ei ole veel päriselt kõigest aru saanud - siis ootab järgmise standardina meid ees triumviraadi kolmas osapool, UDDI - Universal Description, Discovery and Integration - teenustestandard, mis on mõeldud veebiteenuste kataloogi pidamiseks ja sellisest kataloogist vajalike teenuste leidmiseks.

Kui SOAP-i ja WSDL-i kasutatakse suhteliselt palju, siis UDDI-t kasutatakse äärmiselt vähe. Praktilisest vaatenurgast oleks mõistlik UDDI standardit täielikult ignoreerida.

Segadus kasvab: uued grupid, standardid ja organisatsioonid

Muuhulgas SOAP ja WSDL standarditega tegelev organisatsioon w3c on tekitanud juurde mitu täiendavat töögruppi, kes ehitavad täiendavaid standardeid mõistatuslike nimedega: veebiteenuste koreograafia, adresseerimine ja poliitika.

Nähes, et olukord on keeruline ning w3c ei ole samas piisavalt nende poolt kontrollitav, on hulk suurfirmasid loonud uue omaette organisatsiooni WS-I: Web Services Interoperability Organisation, mis nime järgi peaks töötama selle nimel, et erinevad veebiteenused üksteisest aru saaksid.

Samas ehitavad ettevõtted uusi SOAP-i ja WSDL-ga seotud standardeid, hetkel on neid juba üle kahekümne: WS-Addressing, WS-Attachments, WS-BusinessActivity, WS-Coordination jne jne. Osad nendest standarditest on kattuvad. Osad on veidi vastuolulised. Osad nendest on kasutuses WSDL-i uutes versioonides.

Enamus taolisi "standardeid" ei toetu seejuures laiapõhjalise töögrupi pikaajalisele tööle ja konsensusele. Pigem on tegemist väikese hulga inimeste kirjapandud ideedega selle kohta, kuidas asjad nende meelest võiksid käia. Ideid on siis tutvustatud veidi laiemale grupile, saadud tagasisidet ja seejärel pandudki kirja oma "standard". Reeglina ei tulene taolised standardid praktikast: ei ole olemas rakendust, mis oleks loodava standardi järgi ehitatud, saamaks standardi mõttekust ja rakendatavust praktikas järele proovida.

Ülikoolid ei ole paremad

Kui tarkvaraettevõtted on tegelenud veebiteenuste kirjeldamise nö lihtsamate viisidega, siis arvutiteadlaste huvi on olnud suunatud XML-tekstide tähenduse palju täielikumale ja täpsemale määratlemisele, kasutades selleks tehisintellektinduse valdkonnas väljatöötatud loogikapõhiseid meetodeid.

Sellesama w3c katusorganisatsiooni all on semantilise veebi projekti raames töötatud välja universaalsed, loogikal põhinevad andmete esitamise ja teisendamise reeglikeeled rdf, rdfs ja owl. Keelte alusideed on head, standardite kokkupanek on toimunud aga klassikalise akadeemilise kisklemise saatel, kus tulemused on konsensuse ning omavahelise kauplemise alusel otsustanud komiteed.

Kokkuvõttes ei ole loodud kolme keelega absoluutselt rahul ka nende autorid ise. Näiteks on rdf baaskeele semantika autor, tehisintellektinduse klassik Pat Hayes korduvalt selgitanud, et tema loodud semantika on väga ebaõnnestunud, kuna ta oli pideva komiteedelt lähtuva surve all. Analoogilisel seisukohal on enamus asjaga seotuid. Osa arvutiteadlasi peab ka owl keele kontseptsiooni ennast väga ebaõnnestunuks. Hiljuti kirjutas kaasaegse veebi alusepanija, w3c organisatsiooni juht ja semantilise veebi projekti innukas toetaja Tim Berners-Lee, et mitmed olulised osad praegusest rdf standardist on puhtalt vigased. Kirjavahetuse käigus on mitmed teisedki nimetatud standarditega seotud isikud kinnitanud, et mitmed standardi osad on lugejat puhtalt eksitavad, nende taga ei ole mõtestatud sisu.

Sarnaselt SOAP-i ümber tekkinud olukorraga on ka semantilise veebi standardite baasideed head ja toetavad reaalsete rakenduste kogemustele. Probleemiks on nende standardite põhiosa moodustavad keerukad laiendused, asja segasemaks ajavad täpsustused ning erivõimalused.

Arendajad on pakutud standarditest loobumas

Tekkinud olukorra tõttu keeldub üha enam tarkvara-arendajaid veebiteenuste standardeid kasutamast. Samuti ei võeta kuigi tõsiselt semantilise veebi standardeid.

Veebiteenuste osas on kasvanud toetus ideele, et vahetame üle veebi XML faile, aga ärme standardiseeri, mis seal XML failis olema peab: las rakenduste autorid lepivad selle omavahel kokku. Kohati on see lähenemine hea, toob aga kaasa väga palju lisatööd.

Radikaalsem lähenemine ütleb, et ärme kasuta XML-i, vaid saadame üle veebi reaalsete programmeerimiskeelte - näiteks javascript või python - tekste, sest nii on tegelikult kõige lihtsam.

Praegu kõige suurem, nö mõõdukas lähenemine soovitab valida ise SOAP-i väike alamosa ja kasutada seda, kas siis WSDL-i täielikult ignoreerides või sealt üksikuid lõike välja valides. Igal juhul soovitatakse ignoreerida plejaadi väljapakutud veebiteenuste standardeid ja enamust SOAP standardist.

Sarnased protsessid on toimumas semantilise veebi valdkonnas, mis on vaikselt veebiteenustele lähenemas. Uusim W3c standardialge RDFa soovitab mitte kasutada senist rdf standardit, vaid ainult tema elementaarseid ideid, ning annoteerida tegelikult harilikku html teksti. Konkreetselt tähendab see harilikku inimloetavasse veebilehte lihtsate masinloetavate annotatsioonide lisamist, mille abil märgendatakse näiteks, et see väike tekstijupp on nimi ja see teine tekstijupp telefon. Eraldi XMLi ja veebiteenuste formaati ei ole sel juhul andmete esitamiseks isegi vaja, piisab ka juba olemasolevast inimloetavast - kuigi veidi täiendatud - html-st.

Kuhu edasi?

Asjaolu, et standardite ümber tekkinud suure segaduse ning poliitilise kisklemise käigus ei ole standardid pehmelt öeldes kõige õnnestunumad, ei tohiks meid sündmuste edasise käigu osas ära hirmutada.

Enamus kirjeldatud standarditest on pakkunud välja mitmeid mõistlikke ideid ja algatanud ideede üle vaidlemise ja praktilistes rakendustes järeleproovimise, mis on edasimineku paramatu eeltingimus. Arendajate nö laiad massid ei usu pimesi neile pealesurutavaid standardeid, vaid mõtlevad eeskätt oma praktiliste vajaduste peale.

Standardite loomine on evolutsiooniline protsess: esimesed praegu loodud standardid ise surevad, kuid nende ideede paremad osa kantakse üle uutesse standarditesse, millest mõned osutuvad omakorda - mõneks ajaks - edukaks.

Praegu oleme sellise protsessi väga huvitavas, revolutsioonilises faasis, kus vajadus standardite järele on suur, samas olemasolevad standardid meid ei rahulda. Seniste standardite varemetele on tekkimas uute standardite võrsed, ning tegelikult on igal tarkvara-arendajal hea võimalus uusi ideid järele proovida ning toimuvale omalt poolt mõju avaldada.