Tammet – 22. september 2009, kell 23:38

2009-09-22T23:38:06Z

←Vanem redaktsioon		Redaktsioon: 23. september 2009, kell 01:38
2. rida:		2. rida:
	T.Tammet		T.Tammet

	Ilmunud ~~arvutimaailmas~~ 2/07 kui "veebiteenused reeglite ikkes"		Ilmunud Arvutimaailmas 2/07 kui "veebiteenused reeglite ikkes"
	</b>		</b>

Tammet – 22. september 2009, kell 23:37

2009-09-22T23:37:56Z

←Vanem redaktsioon		Redaktsioon: 23. september 2009, kell 01:37
1. rida:		1. rida:
			<b>
	T.Tammet		T.Tammet

	Ilmunud arvutimaailmas 2/07 kui "veebiteenused reeglite ikkes"		Ilmunud arvutimaailmas 2/07 kui "veebiteenused reeglite ikkes"
			</b>

	Veebiteenused on kasulik meetod tarkvara ehitamise juures. Veebiteenuste		Veebiteenused on kasulik meetod tarkvara ehitamise juures. Veebiteenuste

Tammet – 22. september 2009, kell 23:37

2009-09-22T23:37:40Z

Uus lehekülg

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.

Veebiteenuste võlu ja valu - Redigeerimiste ajalugu

Tammet – 22. september 2009, kell 23:38

Tammet – 22. september 2009, kell 23:37

Tammet – 22. september 2009, kell 23:37