OZ 2008/3

M T 133 ORGANIZACIJA ZNANJA 2008, LETN. 13, ZV. 3 bar”> <product ref= ”http://example.com/products/21 034”/> <amount value=”1”/> </order> Informacije glede namestitvenega konteksta ponuja UriInfo. UriBuilder ponuja možnosti enostavnega kreiranja URI-jev za vire. @Context UriInfo i; OrderResource r = ... UriBuilder b = i.getBaseUriBuilder(); URI u = b.path(OrderResource.class).build (r.id ); List<URI> ancestors = i.getAncestorResourceURIs(); URI parent = ancestors.get(ancestors.size()-1); 3. Uporabljamo standardne metode, ki jih zagotavlja enotni vmesnik: GET (preberi, pridobi), POST (poso- dobi ali kreiraj brez ključa), PUT (posodobi ali kreiraj z id-jem), DELETE (briši). @Path(“orders/{order_id}”) public class OrderResource { @GET Order getOrder(@PathParam(“order_id”) String id) { ... } } 4. Različne predstavitve podatkov. Različni formati (HTML, PGN, GIF), različne strukture (XML, JSON), podpora metapodatkom o vsebini s pomočjo glave HTTP. Za določanje predstavitve podatkov uporablja- mo anotacije @ProduceMime in @ConsumeMime. 5. Komunikacije brez stanja: dolgotrajni identifikatorji, izogibanje sejam, povpraševanje se izvede neodvisno od preostalih zahtevkov, vse, kar je potrebno za pro- ces, vsebuje povpraševanje samo. Glavne prednosti na strani strežnika so: horizontalno ska- liranje, izbira alternativnega načina delovanja, shranje- vanje v predpomnilniku, zmanjšana sklopljenost, dobro delovanje z obstoječo spletno infrastrukturo. Na strani odjemalca omogoča možnost zaznamkov, enostavno eks- perimentiranje na brskalniku, široko podporo program- skih jezikov, izbiro podatkovnih formatov … Model REST upošteva lastnosti in rešitve obstoječega standarda HTTP in preizkušenih vzorcev. Če model REST primerjamo s storitveno arhitekturo (SOA), lahko ugotovimo pomanjkljivosti pri varnosti in transakcijah. SOA ima prednost pri velikih kompleksnih sistemih, kjer z orkestracijo storitev sistem razslojimo in zagoto- vimo fleksibilnost. Na drugi strani lahko REST s pridom uporabljamo na različnih napravah, kjer standardi SOA še niso upoštevani. V naslednjih letih se bo dejansko po- kazalo, na katerih področjih ima določena arhitektura prednost. Kot kaže sedaj, bo SOA prevladala predvsem pri komunikaciji med znanimi entitetami, npr. znotraj podjetja ali med poslovnimi organizacijami B2B. Arhi- tektura virov pa bo uporabljena tam, kjer spletni vmesnik predstavlja določeno konkurenčno prednost in tam, kjer dostopamo do zunanjih podatkov. AJAX Ajax je pred nekaj leti prinesel možnost gradnje bogatih spletnih aplikacj. Ajax (Asynchronus JavaScript XML) temelji na javascriptovem ukazu XMLHttpRequest, ki spreminja klasični model gradnje spletne aplikacije. XMLHttpRequest omogoča asinhrono komunikacijo med odjemalcem in spletnim strežnikom. To pa pomeni, da v aplikaciji ni treba vedno znova prenašati spletne strani, ampak lahko na sami spletni strani gradimo grafične ele- mente, podobne tistim, ki jih poznamo v namiznih apli- kacijah. Kljub temu da sta bila javascript in XMLHttpRe- quest uvedena že leta 1997 v Intenet Explorer, pa Ajax sedaj dejansko postaja ključna tema pri gradnji spletnih aplikacij. Veliko napora je trenutno vloženo v standar- dizacijo (npr. OpenAjax Alliance). Obstoječi pristopi v platformi java so zaenkrat razpršeni in neenotni, obstajajo številne knjižnice (RICO, Prototype, Dojo, Zimbra), ki pa nimajo enotnih API-jev, zato so uporabniki teh knjižnic vezani na izbrano knjižnico. Pričakovati je, da se bo to področje standardiziralo preko projektov odprte kode, JCP-ja in preko iniciative OpenAJAX Allience. Drug vidik gradnje spletnih aplikacij Ajax je manko ustreznih orodij. Na tem področju je velik napredek nova verzija NetBeans, ki vsebuje učinkovito podporo javascriptu, vključno z razhroščevalnikom, ki je neodvisen od splet- nega pregledovalnika. Marjan Vaupotič, Robert Vehovec