Web-Oriented Architecture

Jednostavno je uvek (naj)bolje

Granularna struktura resursa u WOA

Temu servisno orijentisane arhitekture (SOA) samo smo dotakli pišući o virtualizaciji u SK 4/2008. Da je ovaj pojam dominantan u svetu informacionih tehnologija pokazuju blogovi vodećih stručnjaka na ovu temu, kao i broj pretraga ovog i srodnih pojmova na internet pretraživačima. Pokušaćemo da objasnimo šta je to toliko značajno u vezi sa SOA i njenom implementacijom.

Redefinisanje pogleda na projektovanje softvera

Tehnologija je neuhvatljiva zverka! To je postalo jasno i najvećim skepticima i tradicionalistima. Stare, proverene aplikacije jednostavno više nisu dovoljno dobre, brze ili pouzdane i svi se okreću novim, naprednim rešenjima. Ta rešenja moraju biti u osnovi sistemska, sposobna da budu deo mnogo većeg i složenijeg entiteta u budućnosti čiji pravac razvoja i ne mora biti poznat. Upravo je ova potreba ključni argument da tehnologija projektovanja softvera mora krenuti putem SOA.

Osnovni koncept ove tehnologije leži u zadatku da se softverski sistemi moraju učiniti manje kompleksnim kroz pakovanje kôda u servise koji implementriraju jednostavne usluge. Time se eliminiše redundantnost, koja predstavlja najozbiljniju manu dosadašnjeg rada na projektovanju softvera, kroz mogućnost upotrebe servisa iznova i iznova, kao i njegovo menjanje u cilju prilagođavanja posebnim potrebama. Prostije rečeno, pisanje aplikacija „od nule” više nije u modi. Realnost nas uči da se najveći deo pisanog kôda replicira (kopi-pejstuje, Copy-Paste) iz drugih, već postojećih rešenja. Tako se stvara veliki broj kopija potpuno identičnih delova aplikacija, zauzima se prostor i smanjuje efikasnost. Uvođenjem servisno-orijentisanih pravila projektovanja, aplikacije postaju platforme na kojima će biti zasnivani budući servisi.

Bazični principi koji definišu SOA su:

• mogućnost ponovne upotrebe kôda (servisa)

• granularnost (razdvajanje servisa po veličini, načinu upotrebe ili nekom drugom kriterijumu)

• modularnost (mogućnost uklapanja servisa, poput Lego kockica)

• skladnost sa standardima (uobičajenim projektnim, ali i posebnim koje zahteva konkretan problem)

• pravilno označavanje i kategorizacija servisa radi postizanja takozvanih federacija resursa, skupova postojećih servisa kojima je lako upravljati i koje je lako pratiti.

Ovi principi dalje se nižu u posebna pravila na kojima se izgrađuju SOA sistemi. Prateći ta pravila, trebalo bi da je lako uspostaviti sistem koji je prilagođen konkretnom biznisu ili kompaniji, ali u realnosti to nije baš tako. Gde nastaje problem?

Da bi se u jednoj kompaniji uspostavio SOA, potrebna je tesna saradnja dve njene potpuno izdvojene celine, IT sektora i menadžmenta. Ukoliko neko smatra da je ovo lako ostvarljiva saradnja, grdno se vara. Ne samo da se ova dva sektora razlikuju u struci koju poseduju njihovi članovi, već i u načinima razmišljanja, a SOA je novost, kako za programere tako i za menadžment. Kako onda prodati SOA nekoj kompaniji? Vodeći prodavci ove tehnologije ističu da je najlakše prvo razgovarati s menadžmentom i objasniti im koliki bi se obrt uloženog novca (ROI, return on investment) postigao ukoliko bi sistem postao jednostavan i lako repliciran. Kada shvate kako to izgleda, njih će interesovati još samo jedna stvar – koliko to košta. Ipak, ni to nije baš tako jednostavno. Uvođenje SOA u jednu kompaniju znači da bi projektanti morali biti upoznati sa svakim detaljem poslovanja i sa svakom aktivnošću koju kompanija obavlja, a to može da potraje veoma mnogo vremena. Tako se može preći granica vremena (novca) koje je menadžment spreman da potroši na „neke tamo novotarije”. Još jedna od bolnih priča realnosti je i ta da u najvećem broju kompanija SOA baš i ne funkcioniše. „Napustite brod”, viknu kapetan...

Napuštanje broda ili promena taktike

Na razvoj „teškaša” – sistemskih aplikacija za rad u velikim kompanijama, u softverskom inženjerstvu je utrošeno preko dve decenije. Toliko vremena u informatičkom smislu predstavlja gotovo večnost, a pri tom postignuti rezultati mogu se smatrati marginalnim, uprkos ogromnim investicijama velikih korporacija. Ovi pokazatelji nimalo ne idu u prilog SOA i postavljaju ovu tehnologiju na put sumnje svih relevantnih faktora među onima koji daju novac za implementaciju.

Ipak, svi stručnjaci iz ove oblasti slažu se da je SOA korak u pravom smeru, ali da je potrebno promeniti pogled na projektovanje softvera i posmatranje njegovog mesta u biznisu. Dakle, problem je u dizajnu i implementaciji. Jednim pogledom na najuspešnije implementacije SOA poput Amazonovog, zatim neizbežnog giganta po imenu Google i njegovog API-ja (Application Programming Interface) ili eBaya možemo uočiti da je zajednička platforma za sve njih Web.

Krunski dokaz odbrane u suđenju SOA tehnologiji zapravo i jesu Web 2.0 kompanije. One žive onakav život kakav bi trebalo da bude i život onih kompanija koje implementiraju servisno orijentisanu arhitekturu. Kako one mogu da pomognu da se ta uspešna implementacija prenese i van virtuelne sfere? Odgovor je veoma prost – ključ leži na Mreži. Ogromna snaga Weba sadržana je u informacijama (resursima) koje poseduje, kao i u slojevitoj arhitekturi na kojoj je zasnovan. Ako dodamo još i izuzetnu podršku protokola komunikacije i otvorenost tih istih protokola (svako može da piše aplikacije zasnovane na njima), dobijamo jedan nov pristup projektovanju SOA. Njegovo ime je WOA – Web-oriented Architecture.

Šta je to WOA

Broj mashup aplikacija u 2008. godini na sajtu ProgrammableWeb

Jedan od najpredanijih ljudi u ovoj oblasti, čovek po imenu Dion Hinchcliffe, vodi blog posvećen implementacijama SOA. Osnovne stavke jednog WOA sistema su, prema njegovim rečima, sledeće:

• informacije unutar WOA predstavljene su u obliku resursa i pristupa im se pomoću protokola specificiranih u URI-ju (Uniform Resource Identifier); najčeće je to HTTP

• svakom resursu na Mreži moguće je pristupiti preko jedinstvene globalne adrese – URI

• manipulacija resursima izvodi se pomoću tehike poznate kao REST (Representational State Transfer)

• pristup resursima mora biti slojevit

• usklađivanje sa standardima je implicitno

• WOA resursi mogu sadržati unutar sebe druge URI-je, i na taj način praviti granularnu mrežu resursa (poput pokazivača u programiranju).

Ako obratimo pažnju, videćemo da su ove karakteristike u potpunosti u skladu sa principima SOA, što je velika prednost u startu. Imajući u vidu ova pravila, lako je zamisliti jedan veliki sistem poput svemira, u kojem se informacije slažu u granularnu strukturu čiji su čvorovi povezani dinamičkim vezama, koje omogućavaju pristup resursima bilo pojedinačno ili u celini, u zavisnosti od potreba aplikacije koja pristupa resursima.

Da bismo upoznali ovu tehnologiju bolje od osnova, navedimo i njen detaljniji opis. Svaki WOA resurs mora posedovati uniformnu, jednoznačnu i globalno jedinstvenu URI adresu, kako na lokalnoj mreži (SOA) tako i na Webu. Taj identifikator trebalo bi da opisuje resurs koliko je god to moguće njegovom String prirodom.

To znači da umesto http://kompanija.com/resursi/349 treba koristiti http://kompanija.com/data/logs/login.xml. Primetimo da je poželjno uvoditi ekstenziju resursa u njegov URI, a korišćenje XML formata je najčešći slučaj. S obzirom na to da je WOA granularan skup resursa, potrebno je obezbediti da se pristupom nekom od manjih skupova mogu dohvatiti i svi drugi koherentni URI-ji zarad potreba za linkovanjem, pronalaskom ili upotrebom srodnih resursa. Tako se eliminiše potreba za stvaranjem lokalnih kopija koje zauzimaju prostor i čine sistem tromijim.

Deo URI-ja trebalo bi da budu i stringovi upita ka provajderu resursa, jer se na taj način mogu spakovati čitavi algoritmi u ovu adresu, i tako povećati efikasnost platforme. Upravo zbog ovakvog pristupa, pametno bi bilo premestiti sve moguće informacije iz HTTP hedera upravo u URI, i na taj način mnogostruko smanjiti vreme propagacije, zahvaljujući jednoj od osnovnih stvari na Webu, linkovima, koji kao nosioci URI-ja mogu preneti sve potrebne podatke. Na kraju, potrebno je obezbediti idempotentnost, odnosno mogućnost da se procedure pozovu jednom ili više puta, a da sistem sačuva konzistentnost.

Razlike između WOA i SOA

Možda najbolji način da se razume ovaj uslovno novi princip projektovanja arhitekture softvera jeste upoređivanje sa SOA. Sličnosti ova dva principa ogledaju se u tome da oba koriste HTTP, opisne formate poput XML-a i oba se mogu upotrebljavati za projektovanje sistema bilo kog stepena kompleksnosti. Razlike su mnogo veće:

• SOA ima tendenciju ka definisanju malog broja kontaktnih tačaka preko kojih se vrši transfer podataka, dok WOA definiše veliki broj tačaka, bez ograničavanja, gde svaka kontaktna tačka odgovara jednom resursu

• SOA tradicionalno, korišćenjem SOAP-a, postavlja komunikacioni sloj iznad HTTP-a i na taj način uvodi ograničenja web programerima. To kod WOA nije slučaj, s obzirom na to da su HTTP i srodni protokoli komunikacije idealni za najveći broj mrežnih aplikacija

• dizajn SOA ostvaren je kroz apstrakciju odozgo nadole kako bi bilo što lakše koristiti priručne alate, dok je WOA nastao apstrakcijom odozgo nagore iz Weba i kao takav je u startu kompatibilan sa raznim XML parserima, uveliko dostupnim na Mreži

• WS-Security i drugi prefinjeni standardi okosnica su sigurnosti SOA sistema, dok se WOA zadovoljava standardnim HTTPS

• SOA mora koristiti XML Schemas za ugovore servisa, dok WOA ignoriše ovaj problem i prepušta web servisima da koriste formate na koje su prirodno navikli

• upotreba SOA u browserima može biti izazov, dok se WOA platforme mogu čitati korišćenjem velikog broja dostupnih čitača.

Problemi s kojima se WOA suočava leže u činjenici da je to tehnologija koja predstavlja, jednostavnu, uniju najboljih principa, gledano po efikasnosti, a ne formalni skup standarda. To je više skup pristupa i tehnika ostvarivanja koji je pokazao najbolje rezultate u ispunjavanju ciljeva koji su zadati svakom SOA sistemu. Ipak, potrebno je još mnogo posla kako bi se ove tehnike prilagodile SOA, i to pre svega u pogledu upravljanja i sigurnosti, ali i usvajanja „konteksta velikih kompanija” unutar WOA inicijative.

Strategija razvoja

Srce WOA tehnologije predstavlja pomenuti REST, koji je odgovoran za skup povezanih pristupa za projektovanje robusnog mrežnog ekosistema labavo povezanih entiteta koji se nadmeću za titulu najupotrebljivijeg. REST servisi najčešće su XML resursi, koji su međusobno povezani korišćenjem URI u veliku mrežu miliona web resursa. Ovo je model na kom je zasnovana i sama Mreža. Ovakav princip projektovanja umnogome se razlikuje od objektno-orijentisanog (OO), pre svega zbog izostanka odvajanja implementacije od interfejsa. U OO konceptu smo mrzeli bočne efekte i zato osmislili „skrivanje informacija”, ali na Mreži ovi bočni efekti zaista dobijaju na smislu. Ukoliko napravimo određeni REST servis, vrlo brzo će se stvoriti dinamička veza ka nekom drugom servisu, koji može, ali ne mora biti u tesnoj vezi s njim. Na ovaj način praktično se emulira evolucija u čijem centru su, namesto organizama, servisi i resursi. Fokus kod projektovanja WOA tehnologije je na dizajnu radi potrošnje, a ne na dizajnu radi integracije. To praktično znači da se više ne nameće kao imperativ da se sav kôd razdvoji u što sitnije modele koji bi se kasnije lako pakovali, a da pri tom u centru pažnje nije konkretan problem koji treba rešavati. Gledajući unazad, iako OO princip traži upravo suprotno, pokazalo se da je češći trend pravljenje jedne supermoćne klase koja obavlja posao namesto skupa međusobno povezanih manjih klasa. WOA ovome parira jer ima u startu mogućnost integracije, zahvaljujući sposobnosti nižih nivoa apstrakcije, same Mreže. Izuzetna osobina REST/WOA saradnje je i njihova skalabilnost, odnosno mogućnost primene u sistemima različite kompleksnosti i veličine, što predstavlja ključnu karakteristiku svake SOA platforme.

Pokušajmo da na vagu stavimo koristi s jedne, a rizik s druge strane. Najveće koristi od WOA svakako su lakoća korišćenja i upravljanja servisima zbog oslanjanja na tehnologije nižeg sloja – Mrežu, a najveći rizici nedovoljno dobro razvijena sigurnost. Kako će ovo biti u budućnosti rešeno, ostaje da se vidi. Ako uvidimo da su pomenute Web 2.0 kompanije već poodavno prešle sa SOAP na REST, jasno je da je to recept i za druge.

„Izvolite, otvoreno je...”

Ključni trend koji je pomerio granice mogućnosti web tehnologija jeste „otvoreni kôd”. Otkako su web kompanije uvidele da mogu imati velike koristi od omogućavanja virkanja u njihovu implementaciju nekog problema, počeli su da se pojavljuju prvi otvoreni API-ji. Vodeći igrač i na ovom polju je Google.

Ubrzo nakon pomame za otvaranjem sopstvenog API-ja javnosti, nikao je veliki broj sajtova koji su koristili informacije upotrebom sevisa sa različitih izvora i tako su nastale mashup (web application hybrid) aplikacije, poput recimo Meebo (SK 6/2008). Mesto na kom možete pronaći najveću bazu ovakvih aplikacija, kao i otvorenih API-ja, kojih trenutno ima 893, jeste http://www.programmableweb.com/.

• • •

Da je servisno orijentisana arhitektura pravi princip projektovanja softvera, znali smo i od ranije. Svesni smo problema koje IT svet ima u njenoj implementaciji i zato možemo da budemo zadovoljni što je web orijentisana arhitektura dobila svoje mesto u arsenalu kojim se suprotstavljamo izazovima koje savremeni svet predočava. Tradicionalni pristupi programiranju i dizajnu softvera odavno su prevaziđeni i potrebno je da svi izvršimo kolektivni update na ovom polju. Dobar korak u tom smeru bila bi instalacija i proučavanje Ruby on Rails (http://www.rubyonrails.org/). Ovaj framework u potpunosti zadovoljava principe koje postavlja WOA i idealan je kako za početnike, tako i prekaljene programere koji žele da budu u koraku sa Web 2.0 inicijativom. See you on the Rails...

Momir ĐEKIĆ