Semanticki Web

2. Pregled relevantnih tehnologija.......................................................................................22.1. Model Driven Engineering (MDE)...........................................................................2

2.1.1. Uvod u MDE.....................................................................................................22.1.2. Meta Object Facility (MOF)..............................................................................72.1.3. Unified Modeling Language (UML)..................................................................82.1.4. UML profili........................................................................................................92.1.5. Transformacije Modela...................................................................................102.1.6. XML Metadata Interchange (XMI)..................................................................142.1.7. Object Constraint Language (OCL)................................................................14

2.2. Semantički Web......................................................................................................162.2.1. XML (Extensible Markup Language).............................................................172.2.2. Ontologije........................................................................................................182.2.3. Resource Description Framework (RDF) i Web Ontology Language (OWL) 192.2.4. Logika i pravila................................................................................................21

2.3. Rewerse I1 Rule Markup Language-a (R2ML)......................................................232.3.1. Pravila ograničenja integriteta.......................................................................242.3.2. Izvedena pravila...............................................................................................252.3.3. Produkciona pravila........................................................................................252.3.4. Reakciona pravila............................................................................................26

2.4. Web servisi.............................................................................................................272.4.1. Servisno Orijentisana Arhitektura..................................................................302.4.2. SOAP................................................................................................................322.4.3. UDDI (Universal Description, Discovery and Integration)............................342.4.4. Paterni razmene poruka (Message Excange Pattern, MEP)...........................352.4.5. WSDL (Web Service Description Language)..................................................372.4.6. Uvod u drugu generaciju tehnologija Web servisa (WS-*).............................392.4.7. Kompozicija Web servisa.................................................................................402.4.8. Nedostaci Web servisa.....................................................................................42

2.5. Semantički Web servisi..........................................................................................422.5.1. OWL-S..............................................................................................................432.5.2. WSDL-S............................................................................................................442.5.3. WSMO (Web Service Modeling Ontology)......................................................462.5.4. Nedostaci semantičkih Web servisa.................................................................47

2.6. Modelovanje Web servisa.......................................................................................472.6.1. Različiti pristupi za modelovanje Web servisa................................................47

1

2.2. Semantički Web

Pojam semantički Web je uveo Tim Berners Lee [Berners-Lee et al., 2001]: Semantički Web će doneti jasnu strukturu sadržaju Web strane, stvarajući sredinu gde softverski agenti koji lutaju od strane do strane mogu spremno da izvrše specifične zadatke za korisnike. Ili malo drugačije rečeno, semantički Web će omogućiti da računari (softver) baš kao i ljudi mogu da nađu, razumeju i koriste podatke preko weba da bi postigli određene ciljeve.

Semantički Web pokriva dosta različitih oblasti i verovatno ima malo ljudi koji imaju potpuno istu predstavu o semantičkom Web-u. Ipak, možemo identifikovati teme koje su najčešće izražene u vezi sa njim [Passin, 2004]:

- indeksiranje i pristup informacijama - u cilju pronalaženja informacija, pristup semantičkog Weba treba da ide dalje od indeksiranja ključnih reči i alfabetskog indeksiranja, i da dozvoli korisnicima pretragu po konceptima i kategorijama.

- meta podaci - koriste pri pretrazi i pronalaženju informacija. Anotacija se takođe može posmatrati kao meta podatak

- anotacija – označava dodavanje informacija na postojeći dokument dostupan na Web-u bez promene originalnog dokumenta. Ove anotacije takođe mogu biti deljene preko mreže.

- mašinsko prikupljanje podataka – ovaj deo vizije se odnosi na automatsko prikupljanje podataka. Ovo znači da sam software određuje koji su mu podaci potrebni i kako da ih dobije, a onda ih i sam uzima

- otkrivanje servisa – da bi servisi mogli da se koriste, mi moramo (odnosno naš softver) biti u mogućnosti da ih nađemo, otkrijemo šta oni rade, i vidimo kako da ih pozovemo

- inteligentni softverski agenti – agent je neko ili nešto što deluje u korisnikovo ime. Softverski agent bi delovao na autonoman način, komunicirao sa drugim softverskim agentima u cilju pronalaženja servisa, ili informacija za nas. Jasno je da mreža agenata koji su u međusobnoj interakciji mora biti u stanju da opiše svoj cilj koristeći dogovorene rečnike, da otkriva servise i izvore informacija.

Da bi ideja semantičkog Weba funkcionisala, računari bi morali da imaju pristup kolekcijama informacija kao i skupovima pravila za zaključivanje koje bi oni (računari) mogli da koriste da bi sproveli automatsko rezonovanje. Dakle, pravi izazov semantičkog Web-a je upravo da obezbedi neki jezik koji bi ujedno nudio podatke, pravila za rezonovanje o podacima, i koji bi takođe omogoćavao da pravila iz bilo kojeg postojećeg sistema za predstavljanje znanja mogu biti izvežena (engl., export) na Web. Ovo se razlikuje od tradicionalnih sistema za prezentovanje znanja koji su bili centralizovani i koji su imali svaki svoj uzak skup pravila za donošenje zaključaka o podacima.

Da bi pričali o Semantičkom Webu, prvo moramo uvesti XML a zatim i objasniti pojam ontologija.

2

2.2.1. XML (Extensible Markup Language)

XML (Extensible Markup Language) [Bray et al., 2006], je metajezik koji je standardizovao World Wide Web Consortium (W3C) 1998 god, i od tada je XML bio osnova za mnoge druge standarde koji čine okosnicu promena u računarskom svetu.

XML ne definiše gramatiku, niti fiksan rečnik tag-ova ili pak skup njihovih dozvoljenih kombinacija, što ga čini potpuno proširivim. Jedini zahtev je da dokument bude dobro formiran i validan [Antoniou & Harmelen, 2004]. Dobro formiran XML document se sastoji od stabla ugnježdenih skupova tag-ova od kojih svaki može da sadrži više parova atribut/vrednost. Pri tome svi tag-ovi moraju biti upareni (svaki otvoren tag mora da bude zatvoren), vrednosti atributa se moraju pisati unutar znaka navoda, atributi ne smeju da se pojavljuju u zatvarajućem tag-u, i elementi ne smeju da se preklapaju. Ipak, ova pravila ne govore nista odredjeno o strukturi dokumenta. Da bi bila moguća komunikacija više različitih aplikacija neophodno je definisati sve elemente i imena atributa koja se mogu koristiti. Dodatno, i sama struktura dokumenta se mora definisati: koje vrednosti atribut može da ima, koji elementi se mogu ili moraju pojaviti unutar drugih elemenata, itd. Kažemo da je XML dokument validan ako je dobro formiran, i ako koristi i poštuje strukturne informacije. Postoje dva načina za definisanje strukture XML dokumenta: DTD (Document Type Definition)1 i XML shema [Fallside, 2004].

DTD se fokusira na strukturu, dozvoljavajući XML dizajneru da specificira elemente i atribute koji su odgovarajući za neki skup XML dokumenata. Ipak treba imati na umu sledeće stvari:

- DTD nije u stanju da definiše razlike u tipovima podataka. Na primer DTD ne može da proglasi da element mora da sadrži validan datum. DTD je ograničen na deklaraciju da element mora da sadrži tekst, ali ne može da kontroliše kakav tip teksta, kao npr. da razlikuje brojeve i slova

- DTD se piše koristeći različitu sintaksu od XML-a, jer je DTD nastao u svetu SGML-a, pre XML-a

XML shema je novija tehnologija, koju je usvojio W3C kao zvanični predlog 2001 god. sa namerom da se pruži detaljnija struktura koja se često povezuje sa tipovima podataka u programskm jezicima i koja je korisna u slučajevima kada je poželjno da se proveri tačnost formata podataka pre nego što procesiranje počne.

Neke od karakteristika XML sheme su: XML shema je bazirana na XML-u i samim tim ima mogućnost ponovnog korišćenja (i poboljšanja) postojećih shema; ona dozvoljava definisanje novih tipova proširivanjem ili restrikcijom već postojećih; ona nudi sofisticiran skup tipova podataka koji se mogu koristiti u XML dokumentima; XML shema ima mogućnost preciznog definisanja kardinalnosti.

Dok XML i XML shema omogućavaju opštu, dobro definisanu sintaksu laku za procesiranje, oni ne govore ništa o semantici podataka koju opisuju. To znači da povrh XML-a mora biti kreiran neki standard koji opisuje semantiku podataka [Passin, 2004]. 1 DTD specifikacija je deo XML specifikacije [Bray et al., 2006]

3

Prvi korak u tom smeru je Resource Description Framework (RDF), generalni model na sloju metapodataka i Resource Description Framework Schema (RDFS), jezik na nivou sheme. (RDF i RDF shemu ćemo objasniti u poglavljima ispod).

2.2.2. Ontologije

Termin ontologija potiče iz filozofije. Bukvalan prevod grčke reči bi bio: proučavanje prirode postojanja. Autori [Antoniou & Harmelen, 2004] opisuju ontologiju kao: osnovni termini i relacije koji čine rečnik ciljne oblasti proučavanja, zajedno sa pravilima za kombinovanje tih termina i relacija u cilju proširenja rečnika. Stavljanje ovih termina, i njihove organizacije, u pravilan redosled (njihovo aranžiranje) nazivamo taksonomija [Passin, 2004]. (još jedno objašnjenje taksonomije koju nudi isti autor je: proučavanje generalnih principa naučne klasifikacije).

U informatici najčešće citirana definicija ontologije je ona koju je dao Gruber [Gruber, 1993]: ontologija je eksplicitna specifikacija konceptualizacje. Jedno od tumačenja ove definicije bi bilo da se konceptualizacija odnosi na apstraktni model nekog fenomena u svetu, identifikujući relevantne koncepte tog fenomena. Eksplicitna znači da su eksplicitno definisani tip koncepta koji je korišćen, kao i ograničenja njihove primene.

Tipično, ontologija se sastoji od konačne liste termina i relacija između tih termina. Termini označavaju koncepte (klase ili objekte) nekog domena. Npr. u univerzitetskom domenu: studenti, kursevi, amfiteatri, predmeti, zaposleni su neki od važnijih koncepta. Relacije se obično sastoje od hijerarhije klasa. Pored relacije hijerarhije klasa, ontologije mogu sadržavati i informacije tipa:

- svojstva (properties) – X predaje Y

- ograničenja vrednosti – samo predavači mogu da drže nastavu

- isključive izraze (engl., disjoint statements) – npr. predavači i studenti su isključivi

- specifikacije logičkih relacija među objektima – svaka katedra mora da ima bar deset zaposlenih

Uloga ontologije u semantičkom Webu je da podrži razmenu znanja u okviru, i između, grupa agenata (ljudi, softverskih programa ili i jednih i drugih). Odnosno njena uloga je da obezbedi deljeno razumevanje domena. Što znači da se moraju prevazići razlike u terminologiji: npr. ono što je “zip kod” u jednoj aplikaciji može u drugoj aplikaciji da predstavlja “area kod”. Takođe dve aplikacije mogu koristiti isti termin sa različitim značenjem. Te razlike se mogu prevazići mapirajući određenu terminologiju u zajedničku ontologiju ili definisanjem direktnog mapiranja između ontologija.

U ovom cilju potrebno je da imamo standardne jezike za definisanje ontologije koji moraju biti dobro adaptirani formi logike koja će se koristiti. Takođe želimo da im pristupamo preko Web-a tako da otologije mogu biti deljene, želimo i da imamo mogučnost kombinovanja delova različitih ontologija, kao i mogućnost klasifikacije svih vrsta koncepta i resursa.

4

2.2.3. Resource Description Framework (RDF) i Web Ontology Language (OWL)

Vratimo se sada viziji semantičkog Web-a.

Najčešće korišćen opis vizije semantičkog Web-a (poznat pod nazivom Semantic Web Layer Cake) je predstavljen u radu [Berners-Lee et al., 2001] a dat je na slici 2.7 (ustvari, slika iz tog rada je sadržala jezike za pravila na sloju iznad jezika za ontologije, ali se ispostavilo da se oni ne mogu nalaziti direktno na sloju iznad, pa je Tim Berners Lee 2005 god. ponudio ispravljenu predstavu gde se pravila nalaze pored OWL-a na istom nivou2). Svaki nivo se koristi za izgradnju nivoa iznad, i niži nivo ne zavisi ni od jednog višeg nivoa. Takođe treba imati na umu da je ovo vizija W3C konzorcijuma i da je većina tehnologija opisana na slici razvijena ili prihvaćena od strane W3C. U ovom poglavlju ćemo ukratko opistati RDF, RDF shemu, i OWL.

Slika 2.7: Arhitektura Semantičkog Web-a

Iako mnogi nazivaju RDF (Resource Description Framework) „jezik“, on u osnovi predstavlja „model podataka“ [Antoniou & Harmelen, 2004] [Manola & Miller, 2004]. Njegov osnovni blok je trojka (triples), gde je svaka trojka predstavljena kao subjekat, predikat i objekat proste rečenice. Postoje razni načini za predstavljanje ovih trojki: grafovima, logičkom formulom tipa P(x,y) – gde binarni predikat P povezuje subjekat x sa objektom y, i XML-om. Vizija semantičkog Web-a zahteva prezentaciju koju mašine mogu da interpretiraju, tako da je prezentacija XML-om za nas najzanimljivija.

Subjekti i objekti se identifikuju URI-jem (Universal Resource Identifier3). Takođe se i predikati identifikuju sa URI-jem, što pak omogućava svakom definisanje novog koncepta, tako što bi samo definisao URI za njega negde na Webu (URI može biti URL, Unified Resource Locator, ili neka druga vrsta jedinstvenog identifikatora – sam identifikator ne mora i da omogućava pristup resursu).

Jedan krajnje prost primer RDF fajla u XML prezentaciji bi bio:2 pogledati i: http://www.w3.org/2006/Talks/1023-sb-W3CTechSemWeb/Overview.html#(19)3 http://www.w3.org/Addressing/URL/uri-spec.html

5

<rdf:RDF xmlns:rdf=”http://www.w3.org/1999/02/22−rdf−syntax−ns#” xmlns:ex=”http://example.org/#”> <rdf:Description about=”http://example.org/Osoba/1234”> <ex:ime>Pera</ex:ime> <ex:titula>Mr</ex:titula> </rdf:Description></rdf:RDF>

rdf:Description element predstavlja opis resursa definisanog „about“ atributom (u našem slučaju resurs je http://example.org/Osoba/1234). Unutar opisa, svojstvo (engl., property) je predstavljeno elementom (ex:ime), a vrednost tog elementa predstavlja vrednost svojstva (Pera).

RDF je nezavisan od domena (ne pretpostavlja se ništa o domenu koji će se koristiti). Samim korisnicima je ostavljeno da definišu svoju terminologiju koristeći RDF shemu (RDFS [Brickley & Guha, 2000]). Termin RDF shema nija baš najsrećnije izabran – on sugeriše da RDF shema ima isti odnos ka RDF-u kao što XML shema ima ka XML-u, što nije slučaj [Antoniou & Harmelen, 2004]. XML shema ograničava strukturu dokumenta dok RDF shema definiše rečnik koji se koristi u RDF modelu podataka.

U RDFS možemo definisati rečnik, specificirati koja svojstva (properties) se odnose na koje vrste objekata, koje vrednosti oni mogu uzeti, kao i definisati relacije između objekata. Ili malo drugačije rečeno, RDFS se može posmatrati kao proširenje RDF-a sa rečnikom za definisanje klasa, hijerarhija klasa, svojstava (binarnih relacija), hijerarhije svojstava i restrikcije svojstava.

Ipak RDF i RDF shema su relativno ograničeni u svojim mogućnostima. (npr., u RDFS ne možemo da deklarišemo opseg restrikcija koji se odnosi samo na neke klase, zatim ne možemo da kažemo da klase međusobno nemaju zajedničkih elemenata, zatim ne možemo da ograničimo koliko različitih vrednosti svojstvo može ili sme da ima, itd.)

Dakle potreban nam je jezik za ontologije koji je moćniji od RDFS-a, jezik koji nude ove mogućnosti.W3C konzorcijum je definisao OWL (Web Ontology Language) [Smith et al., 2004b] – jezik koji je namenjen da bude standardizovan i široko rasprostranjen jezik za ontologije na semantičkom Web-u. Pri dizajniranju OWL-a vodilo se računa o kompromisu koji je potrebno napraviti između povećanja izražajnosti jezika i efikasne podrške za rezonovanje (što je bogatiji jezik to i podrška za rezonovaje postaje sve neefikasnija). Ovaj kompromis je naveo W3C da definiše OWL kao tri različita podjezika: OWL Full; OWL DL (Description Logic); i OWL Lite. OWL Full je najizražajniji jezik od ova tri, ali mu je mana što je on toliko moćan da nije moguće napraviti efikasnu podršku za rezonovanje. OWL DL je podjezik OWL Full-a, koji uvodi neka ograničenja i samim tim nije toliko izražajan, ali njegova prednost je što dozvoljava efikasnu podršku za rezonovanje. I na kraju OWL Lite uvodi još više restrikcija i zbog toga ima ograničenu izražajnost, ali mu je prednost što se lako uči.

OWL naravno nije savršen. Već su identifikovani dodatni zahtevi u „OWL Requirements Document“4, ovde ćemo samo navesti neke: mogućnost importovanja drugih ontologija u OWL-u je prilično trivijalna; upotreba modula (skrivanje informacija) je još u domenu

4 http://www.w3.org/TR/webont-req/

6

istraživanja kada su ontologije u pitanju; semantika OWL-a trenutno prihvata standardan logički model pretpostavke otvorenog sveta (open-world assumption)...

2.2.4. Logika i pravila

Treba se naglasiti i uloga logike u semantičkom webu. Generalno logika nudi formalan jezik za izražavanje znanja. Logika se može koristiti za otkrivanje znanja koje je implicitno dato, logiku mogu koristiti i inteligentni agenti pri donošenju odluka, logika se zatim može koristiti i za primenu u evaluaciji pravila, za pružanje obrazloženja zašto su neki zaključci izvedeni, za pronalaženje kontradikcije, za specifikovanje otnologija i rečnika [Passin, 2004]. Ona koristi razumljivu formalnu semantiku koja dodeljuje jedinstveno značenje logičkim izrazima.

Tokom vremena mnogi sistemi logike su se razvili, ali izdvajaju se dve glavne grane: propoziciona logika (engl., propositional logic) i predikatska logika (engl., predicate logic). Propoziciona logika se bavi izrazima ili predlozima, kao i konekcijama među njima. Pored simbola za predloge, propoziciona logika sadrži i logičke (Boolean) operatore: and, or, not, if-then, if-and-only-if. Npr., u propozicionoj logici, predlog (izraz): „sve kruške su žute“, može biti predstavljen jednim simbolom „p“.

U predikatskoj logici fina struktura izraza se pak analizira do detalja. Tako da će ovaj naš izraz sada biti predstavljen celom formulom: . Simbol „ “ se naziva univerzalni kvantifikator, a simboli „kruska“ i „zuta“ predstavljaju predikate (ili relacije). Pored univerzanog kvantifikatora, predikatska logika ima i egzistencijalni kvantifikator, koji se predstavlja simbolom „ “. Moguće su formule sa više od jednog kvantifikatora. Treba naglasiti da je redosled kvantifikatora u formuli bitan.

Dve vrste kvantifikatora, logički operatori, varijable, predikati i pravila za njihovo sklapanje u formule čine sveukupnu notaciju logike prvog reda (First Order Logic, FOL). FOL se smatra fundamentalom logikom, jer (sa malim proširenjem) ona može definisati celu matematiku.

Jedan podskup predikatske logike sa efikasnim sistemom za dokazivanje (engl., proof system) čini takozvani sistem pravila (engl., rule system). Pravilo ima sledeću formu: A1,.....An→B, gde su Ai i B atomske formule. Postoje dva intuitivna načina za čitanje ovih pravila:

- ako znamo da su A1,...An istiniti onda je B takođe istinito. Pravila sa ovakvom interpretacijom se nazivaju deduktivna pravila.

- ako su uslovi A1,....An tačni, onda izvrši akciju B. Pravila sa ovom interpretacijom se nazivaju reakciona pravila.

Interesantno je ovde napomenuti da recimo u OWL-u ne postoji način da se kaže da su studenti koji studiraju i žive u istom gradu „domaći studenti“ , dok se korišćenjem pravila ovo može lako uraditi:

studira(X,Y),živi(X,Z),lokacija(Y,U),lokacija(Z,U)→domaćiStudent(X)

7

Ali sa druge strane, pravila ne mogu izraziti informacije da je osoba ili muškarac ili žena, što je pak veoma lako uraditi u OWL-u koristeći uniju (disjoint union).

Još od ranih dana Semantičkog Web-a pravila su viđena kao paradigma za predstavljanje znanja i rezonovanja na semantičkom Web-u - cilj je bio da se znanje predstavi u formi pravila, tako da ono bude pristupačno mašinama. Ipak aktivnosti su tek od skoro krenule u pravcu razvijanja standarda za jezike za predstavljanje pravila. Izdvajaju se dva pokušaja standardizacije u tom domenu: RuleML5 i Semantic Web Rule Language (SWRL) [Horrocks et al., 2003]. Mi se ovde nećemo baviti ovim jezicima, a dalje u radu ćemo se baviti R2ML-om (REWERSE I1 Markup Language) - generalnim jezikom za predstavljanjem pravila [Wagner et al., 2005].

2.4. Web servisi

Predstavićemo prvo kratku istoriju Web servisa: 2000. godine W3C konzorcijum je primio zahtev za razmatranje SOAP specifikacije [Mitra & Lafon, 2007]. Ideja je bila da podaci koji se prenose između različitih komponenti serijalizuju u XML, transportuju i zatim deserijalizuju u format koji je pogodan za odredišnu platformu. Postojanja ovog standardnog transportnog mehanizma omogućava heteregonem klijentima i serverima da postanu interoperabilni. SOAP ćemo opisati u odeljku 2.3.2.

Tokom narednih godina, W3C je objavio WSDL (Web Service Description Language) specifikaciju [Chinnici et al., 2007]. Ovaj standard, zasnovan na XML-u, je nudio jezik za opis interfejsa Web servisa na standardizovan način - način na koji Web servis prezentuje ulazne i izlazne parametre poziva, strukturu funkcije, prirodu poziva (samo ulazna, ulazna/izlazna …). WSDL ćemo opisati u odeljku 2.3.5, dok ćemo WSDL metamodel predstaviti u odeljku 3.4.

Kompletiranje prve generacije standarda Web servisa je učinjeno sa UDDI (Universal Description, Discovery and Integratio) specifikacijom6. Ova specifikacija dozvoljava kreiranje standardizovanih registara deskriptora servisa kako u okviru neke organizacije, tako i van njenih granica. UDDI nudi mogućnost da Web servisi budu registrovani na jednoj centralnoj lokaciji, gde ih zatim mogu otkriti potraživači servisa - pretražujuci registre po imenu, identitetu, kategorijama ili po specifikaciji koju obezbeđuje Web servis. UDDI ćemo opisati u odeljku 2.3.3.

5 http://www.ruleml.org/6 UDDI specifikacija je postala OASIS standard, pogledati http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm

8

9

Slika 2.19: R2ML XML reprezentacija jednog reakcionog pravila

10

Veza između ova tri tehnologije (SOAP, WSDL, UDDI) može da se opiše na sledeći način [Coyle, 2002]: aplikacija koja predstavlja klijenta Web servisa treba da locira drugu aplikaciju ili deo poslovne logike koji se nalazi negde na Web-u. Klijent pretražuje UDDI registar da bi pronašao servis, bilo po imenu, kategoriji, identifikatoru ili podržanoj specifikaciji. Kada je pronađe klijent uzima informaciju o lokaciji WSDL dokumenta iz UDDI registra. WSDL dokument sadrži informacije o tome kako kontaktirati Web sevis, i informacije o formatu za poruke, najčešće u XML shemi. Klijent pravi SOAP poruku u skladu sa XML shemom koju je našao u WSDL-u i šalje zahtev računaru na kome se nalazi servis. (Web servis može pristupati i enkapsulirati druge Web servise da bi izvrsio svoju funkciju).

Pre nego krenemo da pojasnimo svaki od ovih standarda, objasnićemo pojam Servisno Orijentisane Arhitekture (SOA).

2.4.1. Servisno Orijentisana Arhitektura

Termin „servisno orijentisan“ postoji već duže vreme i korišćen je u različitim kontekstima i u različite svrhe. Jedna konstanta koja se pominje u svim tim kontekstima je da on predstavlja jedinstven pristup za „razbijanje“ problema. Ovo znači da se logika koja je potrebna da se reši neki veći problem može bolje konstruisati, izvršiti i da se njome može lakše upravljati ako se ona razloži na skupove manjih povezanih delova [Erl, 2005]. Svaki od ovih delova se odnosi na jedan, specifičan, deo problema.

Servisno orijenitsana arhitektura je termin koji predstavlja model u kojem se automatizovana logika razlaže na manje, jedinstvene delove [Erl, 2004]. Zajedno, ovi delovi čine deo velike poslovne automatizovane logike. Individualno, ovi delovi se mogu distribuirati. Delovi su nezavisni, ali ipak nisu skroz izolovani jedan od drugoga. Oni moraju biti u skladu sa grupom principa koji im omogućavaju da se razvijaju nezavisno, a istovremeno da zadrže određenu količinu zajedničkih karakteristika i standarda. Ovi delovi logike se nazivaju servisi.

Servisi koji nude deskriptore i koji komuniciraju porukama čine osnovu servisno orijenitsane arhitekture (videti sliku 2.20). Ova arhitektura koju smo opisali do sada, deluje vrlo slično nekim starijim distribuiranim arhitekturama koji podržavaju razmenu poruka i razdvajanje interfejsa od izvršavane logike. Ono što je ipak razlikuje je način na koji su ove tri osnovne komponente (servisi, deskriptori i poruke) dizajnirani.

11

Slika 2.20: Dizajnerski problemi koje rešava SOA

Neki od ključnih aspekata principa SOA su [Erl, 2005]:

slaba veza (loose coupling) – servisi održavaju vezu koja minimizuje zavisnost, i koja samo zahteva da oni (servisi) budu svesni jadan drugog

ugovor servisa – servisi se drže komunikacionog dogovora, onako kao što je opisano u jednom ili više deskriptora (i drugim relevantnim dokumentima)

autonomija – servisi imaju kontrolu nad logikom koju enkapsuliraju

apstrakcija – svu logiku koja se nalazi van ugovora servisa, servisi sakrivaju od spoljašnjeg sveta

ponovno korišćenje – logika je podeljena u servise s ciljem promovisanja ponovnog korišćenja

kompozitnost – kolekcije servisa mogu biti sklopljene u cilju formiranja kompozitnih servisa

ne čuvanje prethodnog stanja (engl., statelessness) – servisi minimizuju zadržavanje informacija koje su specifične za neku aktivnost

otktrivanje – servisi su dizajnirani da budu deskriptivni tako da se mogu naći i da im se može pristupiti preko postojećih mehanizama za otkrivanje

Sa znanjem o komponentama koje čine našu osnovnu arhitekturu, kao i o skupu dizajnerskih principa koje možemo koristiti da bi oblikovali i standardizovali ove komponente, samo nam fali implementaciona platforma koje će nam omogućiti da sklopimo ove deliće i da napravimo servisno orijentisana automatizovana rešenja. Skup tehnologija koji čine Web servise nam nude takvu platformu. [Weerawarana et al., 2005].

Kao što smo pomenuli ranije, termin „servisno orijentisan“ je postojao pre dolaska Web servisa. Ipak, nijedan tehnološki napredak nije bio toliko pogodan, i uspešan, u manifestovanju SOA kao što su Web servisi [Chatterjee  & Webber, 2003]. Sve velike platforme danas, podržavaju kreiranje servisno orijenitsanih rešenja, i to tako da je ponuđena podrška za SOA bazirana na korišćenju Web servisa.

Sada možemo malo detaljnije opisati svaku od tehnologija koje čine srž Web Servisa.

12

2.4.2. SOAP

Pošto je sva komunikacija između servisa bazirana na porukama, izabrano okruženje (engl., framework) za razmenu poruka mora biti standardizovano tako da svi servisi, bez obzira na poreklo, koriste isti format i transportni protokol. Dodatno, unutar SOA, veliki naglasak je stavljen na dizajn aplikacije baziran na porukama (engl., message-centric) tako da je sve veća količina poslovne i aplikacione logike sadržana u porukama [Erl, 2005]. Ovo postavlja zahtev da samo okruženje za razmenu poruka bude ekstremno fleksibilno i proširivo.

SOAP specifikacija [Mitra & Lafon, 2007] zadovoljava ove zahteve i ona je univerzalno prihvaćena kao standardan transportni protokol za poruke procesirane od strane Web servisa. Od verzije 1.2 SOAP specifikacije, reč SOAP nije vise akronim „Simple Object Access Protocol“ (ona sada stoji kao samostalna reč).

SOAP je protokol baziran na XML–u, služi za razmenu podataka u decentralizovanoj, distribuiranoj sredini. SOAP se oslanja samo na XML i standardne web protokole (HTTP, FTP, SMTP) [Coyle, 2002]. Glavna svrha SOAP specifikacije je da definiše standardan format poruke. Struktura ovog formata je prilično jednostavna, ali mogućnost njegovog proširenja i prilagođavanja je ono što je pozicioniralo SOAP kao osnovu za SOA.

Svaka SOAP poruka je spakovana u kontejner koji se naziva „envelope“ (u njemu se nalaze svi delovi poruke – videti sliku 2.22). Svaka poruka moze sadrzati zaglavlje (header) – prostor predviđen za čuvanje metapodataka. U velikom broju servisno orijentisanih rešenja, zaglavlje je važan deo celokupne arhitekture, i iako je opciono retko se izostavlja. Njegova važnost se ogleda u upotrebi „blokova zaglavlja“ (header blokova) kroz koje se može implementitari veći broj proširenja.

Slika 2.22: Osnovna struktura SOAP poruke

SOAP envelop takođe sadrži i SOAP telo (body) koje sadrži poslovne informacije. Npr. SOAP telo može sadržati zahtev za servisom (engl., service request) i ulazne podatke za servis koji se procesira. Telo sadrži informacije specifične za aplikaciju i ono se procesira

13

na strani krajnjeg primaoca. U toku procesiranja SOAP poruke, SOAP čvor može izgenerisati grešku. Ako se to desi, SOAP čvor vrati SOAP poruku koja sadrzi SOAP grešku.7

Pomenuli smo da je primarna karakteristika SOAP komunikacionog okruženja naglasak na kreiranju nezavisnih (samostalnih) poruka. Ova nezavisnost je implementirana kroz korišćenje blokova zaglavlja. Blokovi zaglavlja dopunjuju poruku sa svim informacijama koje su neophodne servisima sa kojima poruka dolazi u kontakt - informacije koje omogućavaju servisima da procesiraju i rutiraju poruku u skladu sa pratećim pravilima i instrukcijama. Ovo, u stvari, znači da kroz korišćenje blokova zaglavlja, SOAP poruke mogu da sadrže dodatne informacije o isporuci i procesiranju sadržaja poruke [Erl, 2005]. Ovo pak oslobadja servise od potrebe čuvanja i održavanja logike koja je specifična za poruke (message-specific). I dalje, ovo doprinosi konceptima SOA, naglašavajući interoperabilnost i mogućnost ponovnog korišćenja (praktično sva WS-* proširenja su implementirana koristeći blokove zaglavlja. WS-* proširenja ćemo pokriti u sledećim poglavljima).

Neke od informacija kojima blokovi zaglavlja mogu dopuniti poruke:

- procesne instrukcije koje mogu izvršiti servisni posrednici (intermediaries) ili krajnji primalac

- informacije o rutiranju

- sigornosne mere koje poruka implementira

- informacije o pouzdanosti isporuke poruke

- informacije o upravljanju transakcijama

- informacije korelacije (tipično identifikator koji se koristi za povezivinje poruka za zahtev, sa porukama za odgovor)

SOAP čvorovi (nodes)

SOAP čvorovi predstavljaju procesnu logiku zaduženu za slanje, primanje i obavljanje različitih taskova na SOAP porukama [Mitra & Lafon, 2007]. Implementacija SOAP čvora je tipično platformski specifična i često se označava kao SOAP server ili SOAP osluškivač (engl., listener). Ali, bez obzira na način na koji su implementirani, SOAP čvorovi moraju biti u skladu sa SOAP specifikacijom koju podržavaju – jedino tako je moguć komunikaciono okruženje nezavisno od proizvođača.

SOAP čvorove delimo po tipu, u zavisnosti od toga u kojoj formi procesiranja oni učestvuju u određenom scenariju. Tipovi koje vezujemo za SOAP poruke su:

SOAP pošiljalac (sender) – SOAP čvor koji šalje poruku

SOAP primalac (receiver) – SOAP čvor koji prima poruku

SOAP posrednik – SOAP čvor koji prima i šalje poruku, i opciono procesira poruku pre njenog slanja

inicijalni SOAP pošiljalac – prvi SOAP čvor koji šalje poruku

7 za detalje o krajnjem primaocu i SOAP čvoru pogledati sledeći pododeljak: SOAP čvorovi

14

krajnji SOAP primalac – poslednji SOAP čvor koji prima poruku

Kada se greška desi tokom procesiranja SOAP poruke, specifikacija nudi model za obradu grešaka. Informacija o greškama se nalazi unutar <env:Body> elementa. SOAP specifikacija definiše pet kodova grešaka:

1. VersionMismatch – poruka ne odgovara SOAP verziji na čvoru

2. MustUnderstand – ciljni čvor ne razume zaglavlje u poruci koja sadrzi „mustUnderstand“ atribut

3. DataEncodingUnknown – ciljni čvor ne razume enkodovanje podataka u poruci

4. Sender – poruka je neispravno formirana kada ju je primio procesni čvor

5. Receiver – primajući čvor ili krajnji primalac (receiver) ne mogu da procesiraju poruku

Za većinu kompanija SOAP je najprihvatljivije rešenje. Sve što je ustvari potrebno, je unapred dogovorena shema za XML podatke koji se razmenjuju, i SOAP server koji je sposoban da rukuje dolazećim XML-om. Sa softverske strane, pošiljaoci moraju da pakuju svoje podatke u XML, ali većina kompanija je to već i uradila, pa im to predstavlja minimalan trud [Coyle, 2002]. Eventualno samo treba da naprave XSLT (XSL Transformations) shemu da bi automatizovale taj proces.

2.4.3. UDDI (Universal Description, Discovery and Integration)

Jedan od fundamentalnih koncepata servisno orijentisane arhitekture je mehanizam kojim bi potencijalni potraživači otkrili deskriptore Web servisa (metapodatke koji opisuju Web servise). Ti metapodaci moraju biti u formi koja se lako pretražuje, i otkriva, od strane potraživača. Potrebno je ove metapodatke skupiti, i sačuvati, u neki centralni direktorijum. Takav jedan direktorijum može postati integralni deo organizacije ili internet zajednice [Newcomer & Lomow, 2004].

Ovo je razlog zasto je UDDI (Universal Description, Discovery and Integration8) specifikacija postala važna. Ključni deo UDDI specifikacije je standardizacija podataka unutar takvog direktorijuma, koji se još naziva i registar (registry), kao i specificiranje načina za njegovu pretragu i ažuriranje (engl., update). UDDI nudi standardan način za opis poslova (engl., business), uključujući i njihovu kategorizaciju po različitim kriterijumima (npr. geografska lokacija, sektor industrije, itd. ), kao i način na koji ih potencijalni klijenti mogu tražiti na osnovu određenih zahteva.

UDDI repozitorijum se mogu nuditi na jedan od tri načina:

1. javni UDDI – ovo su UDDI repozitorijumi koji mogu poslužiti kao resors za internet bazirane Web servise. Primer je UDDI poslovni registar koji podržavaju velike kompanije (ponekad nazivane i operatori čvorova), koje predvode IBM, Microsoft i SAP, i kojeg replicira veliki broj drugih organizacija (UDDI podaci se repliciraju automatski između instanci repozitorijuma).

8 http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm

15

2. intra enterprise UDDI – preduzeće ima privatni interni UDDI repozitorijum koji nudi mnogo više kontrole nad time kojim deskriptorima servisa je dozvoljeno da budu stavljeni u repozitorijum, i ko sme da ih koristi

3. inter enterprise UDDI – opseg su mu servisi koji su deljeni izmedju više poslovnih partnera

2.4.4. Paterni razmene poruka (Message Excange Pattern, MEP)

Pre nego krenemo sa opisivanjem WSDL-a, pomenućemo paterne razmene poruka.

Svi poslovi koji su automatizovani od strane Web servisa se mogu razlikovati po prirodi aplikativne logike koja se izvršava, kao i po ulozi koju servis ima u tom poslu [Erl, 2004]. Bez obzira na to koliko je kompleksan posao, skoro svi poslovi zahtevaju prenos više poruka. Izazov leži u koordinaciji ovih poruka u određeni redosled, tako da individualne akcije koje poruke izvrše, se izvrše na pravi način. MEP predstavlja skup šablona koji nudi grupu već mapiranih sekvenci za razmenu poruka. Najčešći primer je patern zahtev-odgovor (engl., request-response). Zahtev-odgovor je najpopularniji MEP u upotrebi u distribuiranoj sredini [Hophe & Woolf, 2003], i on najčešće definiše sinhronu komunikaciju (iako se ovaj patern može primenjivati i asinhrono). Ovaj patern utvrđuje prostu razmenu, u kojoj se poruka prvo prenosi od izvora (servis potraživač) do destinacije (servis provajder). Po prijemu poruke, destinacija (servis provajder) onda odgovara porukom nazad izvoru (servis potraživač). Treba primetiti da u okviru ovog MEP-a, servisi obično zahtevaju način da pridruže poruku koju šalju kao odgovor sa odgovarajućom porukom koja je predstavljala zahtev. Ovo se može postići korelacijom [Hophe & Woolf, 2003].

Jedan od fundamentalnih zahteva za razmenu informacija Web servisima je mogućnost da se sačuva kontekst i stanje tokom isporuke većeg broja poruka. Pošto je servisno orijentisan komunikaciono okruženje slabo povezano (engl., loosely coupled), ne postoji mehanizam za povezivanje poruka koje se razmenjuju pod zajedničkim kontekstom, ili kao deo zajedničke aktivnosti.

MEP igraju važnu ulogu u WSDL-u (opisan u sledećem poglavlju), jer paterni mogu koordinisati ulazne i izlazne poruke koje su u vezi sa operacijom. Iako ćemo opisati verziju 2 WSDL specifikacije u narednom odeljku, ovde ćemo pomenuti i koje paterne podržava prethodna verzija 1.1 WSDL specifikacije9 radi boljeg razumevanja. Verzija 1.1 podržava četiri paterna. Ovi paterni se primenjuju na operacije u okviru servisa, iz perspektive servis provajdera ili krajnje tačke. Dakle podržani paterni u verziji 1.1 WSDL specifikacije su (slika 2.24):

operacija zahtev–odgovor (request-response) – po prijemu poruke, servis mora odgovoriti standardnom porukom ili pak porukom o greški

operacija traži odgovor (solicit-response) – po slanju poruke servisu potraživaču, servis očekuje standardnu poruku kao odgovor, ili pak poruku o greški

9 http://www.w3.org/TR/wsdl

16

operacija u jednom smeru (one-way) - servis očekuje jednu poruku i nije u obavezi da odgovori

operacija obaveštavanja (notification) – servis pošanje poruku i ne očekuje odgovor

Slika 2.24: Četiri osnovna paterna koje podrđava WSDL 1.1

Verzija WSDL specifikacije 2.0 [Chinnici et al., 2007] definiše samo tri paterna (patern samo-ulaz, patern robustan samo-ulaz i patern ulaz-izlaz), ali nudi mogućnost korišćenja i dodatnih paterna (patern ulaz-opcioni-izlaz, patern samo-izlaz, robustan-samo-izlaz, izlaz-ulaz, izlaz-opcioni-ulaz) [Lewis, 2007], tako da ćemo ovde predstaviti svih osam paterna:

patern ulaz-izlaz (in-out) – analogan MEP-u zahtev-odgovor (ekvivalentan WSDL 1.1 operaciji zahtev-odgovor)

patern izlaz-ulaz (out-in) – je suprotan prethodnom paternu gde servis provajder inicira razmenu slanjem zahteva (ekvivalentan WSDL 1.1 operaciji traži odgovor)

patern samo-ulaz (in-only) – podržava standardan MEP pošalji-i-zaboravi (ekvivalentan WSDL 1.1 operaciji u jednom smeru)

patern samo-izlaz (out-only) – suprotan je paternu samo-ulaz. Koristi se uglavnom za podršku objava događaja (event notification. Ekvivalentan WSDL 1.1 operaciji obaveštavanja)

patern robustan-samo-ulaz (robust in-only) – varijacija paterna samo-ulaz koja nudi opciju slanja poruke o greški kao rezultat greške koja nastaje u prenosu ili u procesiranju

patern robustan-samo-izlaz (robust out-only) – koji kao i patern samo-izlaz, ima spoljnu (outbound) poruku koja inicira prenos. Razlika je što poruka o greški može da se pošalje kao odgovor na prijem ovakve poruke

patern ulaz-opcioni-izlaz (in-optional-out) – koji je sličan paternu ulaz-izlaz sa jednim izuzetkom. Ova varijacija uvodi pravilo koje kaže da je isporuka poruke koja predstavlja odgovor opciona, i samim tim servis potraživač koji je započeo komunikaciju ne bi trebao da je očekuje. Ovaj patern takođe podržava generisanje poruka o greški

17

patern izlaz-opcioni-ulaz (out-optional-in) – je suprotan paternu ulaz-opcioni-izlaz, gde je dolazna poruka opciona. Ovaj patern takođe podržava generisanje poruka o greški

2.4.5. WSDL (Web Service Description Language)

WSDL nudi ključni sastojak za uspostavljanje slabo povezane komunikacije između servisa implementiranih kao Web servisi [Erl, 2005]. WSDL opisuje tačku kontakta za servis provajdera, često nazivanu servisna krajnja tačka (engl., service endpoint). On nudi formalnu definiciju interfejsa krajnje tačke (tako da potraživač koji želi da komunicira sa servis provajderom zna tačno kako da sastavi poruku - npr. tip i broj parametara koji se prosleđuju servisu, tip i struktura vraćenog rezultata) i takođe utvrđuje fizičku lokaciju (adresu) servisa. Dakle, jednom kada se web servis otkrije (preko UDDI-a) WSDL obezbeđuje detalje kako se stvarno povezati, i interagovati sa tim servisom.

WSDL je dizajniran oko sledećih koncepta [Newcomer & Lomow, 2004]:

1) proširivost – neke stvari su neophodne za opis servisa (format podataka koji se razmenjuje, način na koji poruke treba da se šalju, njihova destinacija ....) ali šta je sa stvarima tipa: koliko košta korišćenje servisa, koje su sigurnosne karakteristike, itd... WSDL rešava taj problem tako što se limitira samo na bitne stvari, a za ove druge nudi mogućnost proširenja (odnosno mora se napraviti nova jezička sintaksa i umetnuti na pravo mesto u WSDL-u)

2) razdvajanje ”šta” od ”kako” i ”gde” - prva stvar koju klijent mora da zna je šta servis radi. Onda mora da zna kako da koristi servis i gde se on nudi. To je osnovni princip WSDL-a – on razdvaja šta servis radi (izraženo u formi <portType> u WSDL-u 1.1 odnosno formi <interface> u WSDL-u 2.0), od toga kako treba interagovati sa servisom (izraženo u formi <binding> u verziji 1.1 i 2.0), kao i od toga gde se servis nudi (izraženo u formi <port> u WSDL-u 1.1 odnosno formi <endport> u WSDL-u 2.0). Ovo razdvajanje dozvoljava da isti opis ”šta servis radi” bude ponuđeno u različitim formama interakcije na različitim lokacijama (apstraktni opis servisa) – odnosno imamo mogućnost njegovog ponovnog korišćenja.

3) podrška za više protokola - WSDL nije direktno zavisan od HTTP-a i SOAP-a. WSDL specifikacija nema nikakva ograničenja po pitanju protokola koji mogu da se koriste za prenos parametara i rezultata. Ona nudi proširivu arhitekturu za podršku za bilo koji protokol. <binding> opisuje kako pristupiti servisu preko specifičnog protokola.

4) bez redosleda – servis koji WSDL opisuje se tipično sastoji od većeg broja operacija. Međutim nigde se ne specificira kojim redosledom se te operacije moraju izvršavati. Taj redosled se nekad naziva ”apstraktni proces” Web Servisa. Business Process Execution Language za Web service (WS-BPEL, opisaćemo ga kasnije u tekstu) uključuje koncept apstraktnog procesa.

5) bez semantike - WSDL namerno opisuje šta servis radi samo na strukturnom nivou, on ne zalazi u opisivanje semantike Web Servisa

18

WSDL specifikacija je trenutno u verziji 2.0 [Chinnici et al., 2007], i u odnosu na prethodnu verziju (WSDL 1.110) ona je prostija, ali praktičnija za opise servisa [Weerawarana et al., 2005]. Mala je verovatnoća da će WSDL specifikacija biti dalje razvijana (naravno greške će se ispravljati, ali se ne očekuje verzija 3.0 – bar ne u skorije vreme) [Weerawarana et al., 2005]. Iz prostog razloga što je WSDL specifikacija osnova za mnoge druge specifikacije (pomenućemo ih kasnije) i njena promena bi zahtevala menjanje i ostalih specifikacija. Ipak, verzija 2.0 je relativno nova, i proći će neko vreme pre nego što ona zameni verziju 1.1 (svi ozbiljniji alati podržavaju WSDL 1.1, i potrebno je neko vreme da bi WSDL 2.0 bio u potpunosti prihvaćen od strane industrije).

Objanićemo sada kako je WSDL organizovan. WSDL specifikacija definiše jezik za opisivanje apstraktne funkcionalnosti, kao i okruženje (framework) za opisivanje konkretnih detalja opisa servisa [Chinnici et al., 2007]. (videti sliku 2.25)

Slika 2.25: Struktura WSDL dokumenta

Na apstraktnom nivou WSDL opisuje Web servis u terminima poruka koje šalje i prima (poruke su opisane bez obraćanja pažnje na to kako i gde se servis nudi) koristeći neki sistem tipova – najčešće XML shemu. Operacija (<operation> element) povezuje patern razmene poruka (tj. MEP) sa jednom ili više poruka. MEP identifikuje sekvencu i kardinalnost poslatih i/ili primljenih poruka. Inerfejs (<interface> element) grupiše zajedno operacije.

Na konkretnom nivou, <binding> element, specificira detalje transportnog formata za jedan ili više interfejsa. <endpoint> element pridružuje mrežnu adresu sa <binding> elementom. I na kraju, <service> element grupiše zajedno <endpoint> elemente koji implementiraju zajednički interfejs.

WSDL metamodel ćemo predstaviti u odeljku 3.4.

10 http://www.w3.org/TR/wsdl

19

2.4.6. Uvod u drugu generaciju tehnologija Web servisa (WS-*)

Izraz „WS-*“ je postao često korišćena skraćenica koja se odnosi na drugu generaciju specifikacija Web servisa [Erl, 2004]. Ovo su proširenja osnovnom okruženju Web servisa, koji čine standardi prve generacije, a koji su predstavljeni sa WSDL, SOAP i UDDI specifikacijama. Termin „WS-*“ je postao popularan zato što većina naziva data Web servis specifikacijama druge generacije počinje prefiksom „WS-*“[Erl, 2004].

Glavna motivacija za proširivanje mogućnosti prve geracije Web servisa je bila da se omogući servisno orijentisanim arhitekturama da predstave (i poboljšaju) širi opseg poslovnih funkcija koja su neophodna za savremena preduzeća. Da bi razumeli zašto su ove specifikacije stvorene, moramo baciti pogled na neke od tih fundamentalnih zahteva poslovne automatizacije, koji nisu bili zadovoljeni prvom generacijom Web servisa.

- Upravljanje (engl., management) kontekstom i transakcijama

Početni skup tehnologija Web servisa nije imao mogućnost da podrži strukturno održavanje konteksta kroz aktivnost servisa. Bez aktivnog konteksta koji je svestan prethodnih stanja (engl., stateful), Web servisi deluju nezavisno i ne mogu podržati distribuirane transakcije. WS-Coordination standard nudi sistem upravljanja kontekstom, koji se primenjuje pri podršci atomskih transakcija, koristeći protokol koji je opisan u WS-Transaction specifikaciji. (WS-Coordination [Cabrera et al., 2005], i WS-Transaction [Cox et al., 2004] specifikacija)

- Poslovni (engl., business) procesi

Da bi mogli da povezujemo Web servise potrebno je da imamo neki standardni rečnik. Web Services Business Process Execution Language (WS-BPEL) nudi rečnik za opis procesa koji se može kompajlirati u skripte, koje bi izvršavali posrednici koji podržavaju orkestraciju. WS-BPEL zajedno sa drugim rečnicima poslovnih procesa dovodi Web servise u domen poslovne (enterprise) integracije. (WS-BPEL specifikacija [Alves et al., 2007])

- Sigurnost

Verovatno najveću prazninu u prvoj generaciji Web servisa je predstavljao nedostatak realnih sigurnosnih standarda. Kao posledica toga organizacije nisu baš bile voljne da izlože svoje poslovne procese na internetu. WS-Security okruženje (framework) uspostavljaju detaljan sigurnosni model, sastavljen od standarda koji se međusobno nadopunjuju. On utvrđuje sigurnosne mere za zaštitu SOAP poruka na putanji poruka, i podržava stvaranje kurseva delovanja (engl., policies). Osnovne WS-Security specifikacije su dopunjene serijom XML sigurnosnih standarda. (WS-Security specifikacija [Nadalin et al., 2004])

- Pouzdano slanje poruka

Da bi neko rešenje bilo robusno, njegovo komunikaciono okruženje mora biti otporno na greške. Unutar servisno orijentisane arhitekture, ovo zahteva sistem za garantovanu isporuku poruka, što takođe podrazumeva i način za komuniciranje o greškama o neuspelom prenosu. WS-ReliableMessaging nudi takav sistem, zajedno sa skupom

20

kurseva delovanja koji se može koristiti za podršku poslovnim pravilima vezanim za isporuku. (WS- ReliableMessaging specifikacija [Bilorusets et al., 2003])

- Kursevi delovanja (engl., policies)

Unutar servisno orijentisane arhitekture bi bilo korisno ako bi mogli da apstrakujemo poslovna pravila i sigurnosna pravila, tako da se ona mogu primeniti na grupu servisa kao kursevi delovanja. WS-Policy okruženje se sastoji od skupa specifikacija koja omogućavaju opis takvih kurseva delovanja, kao i standardan način za njihovo pridruživanje Web servisu. (WS-Policy specifikacija [Bajaj et al., 2004])

2.4.7. Kompozicija Web servisa

U ovom odeljku, ćemo prvo dati kratak uvod u orkestraciju i koreografiju Web servisa, a zatim ćemo u kratkim crtama objasniti i WS-BPEL specifikaciju.

Orkestracija

Umesto da imamo Web servise koji se pozivaju međusobno koristeći jedan ili više paterna za razmenu poruka, može se koristiti orkestracija za kreiranje kompleksnih paterna interakcije u poslovnoj komunikaciji, sa obradom izuzetaka, grananjem i paralelnim izvršavanjem [Newcomer & Lomow, 2004]. Da bi ovo postigla, orkestracija mora da sačuva kontekst i da ponudi korelacioni mehanizam za više servisa.

Sa orkestracijom različiti procesi se mogu povezati, bez potrebe da se ponovo razvija rešenje koje je prvobitno automatizovalo procese pojedinačno. Orkestracija premošćuje razlike između procesa, uvodeći novu logiku [Erl, 2005]. Dalje, upotreba orkestracije može smanjiti kompleksnost rešenja. Logika je apstrakovana i lakše se njome upravlja nego kada je ubačena unutar individualnih komponenti. Kroz korišćenje proširenja koja dozvoljavaju poslovnoj logici da se izrazi preko servisa, orkestracija može prezentovati i izraziti poslovnu logiku na standardizovan, servisno baziran način.

Ključni aspekt pozicioniranja orkestracije unutar SOA jeste činjenica da orkestracija sama postoji kao servis [Erl, 2004]. Samim tim, nadograđivanjem na orkestracionu logiku standardizuje se i predstavljanje procesa u okviru organizacije. Primarna industrijska specifikacija koja standardizuje orkestraciju je WS-BPEL (Web Services Business Process Execution Language, pogledati ispod) [Alves et al., 2007].

Orkestracija nudi model gde je procesna logika centralizovana ali ipak proširiva [Erl, 2005]. Kroz korišćenje orkestracije servisno orijenitisana rešenja postaju proširiva i prilagodljiva. Sama orkestracija tipično utvrđuje zajedničku tačku integracije za druge aplikacije. Ove osobine dovode do povećane organizacione aktivnosti jer: - logika koju enkapsulira orkestracija može biti modifikovana ili proširena na centralnoj lokaciji; - centralno pozicioniranje orkestracije može značajno olakšati spajanje poslovnih procesa.

Koreografija

Organizacije imaju realnu potrebu za razmenom podataka. Mala je šansa da će se baš sve organizacije dogovoriti o tome kako njihovi interni procesi treba da budu struktuirani, tako da u slučaju potrebe za međusobnom komunikaciom, sve te organizacije imaju

21

gotova automatizovana rešenja. WS-CDL (Web Service Choreography Description Language) [Kavantzas, 2005] je jedna od nekoliko specifikacija koja pokušava da organizuje razmenu informacija između više organizacija (ili više aplikacija unutar organizacija), sa naglaskom na javnu saradnju.

Važna karakteristika koreografije je da je ona namenjena javnoj razmeni poruka. Cilj je da se uspostavi neka vrsta organizovane kolaboracije između servisa koji predstavljaju različite entitete, pri čemu ni jedan entitet (organizacija) ne kontroliše kolaboracionu logiku.

Unutar bilo koje koreografije, Web servis zauzima jednu od nekoliko predifinisanih uloga. Ovo utvrđuje ono što servis radi i ono što servis može da uradi unutar konteksta nekog poslovnog zadatka. Svaka akcija koja se mapira unutar koreografije se može razbiti na seriju poruka koje se razmenjuju između dva servisa [Erl, 2005].

Iako obe pretstavljaju kompleksne paterne razmene poruka, postoji jedna razlika koja razdvaja termine „orkestracija“ i „koreografija“. Orkestracija izražava poslovni proces specifičan za organizaciju. Ovo znači da organizacija poseduje i kontroliše logiku koja stoji iza orkestracije, čak iako ta logika obuhvata interakciju sa spoljnim poslovnim partnerima. Koreografija sa druge strane ne mora (i nije) u posedu jednog entiteta. Ona deluje, kao zajednički patern za razmenu poruka koji se koristi za saradnju servisa koji pripadaju različitim provajderima.

WS-BPEL

BPEL4WS11 (Business Process Execution Language for Web services) specifikacija je nastala jula 2002. godine, i ona predstavlja zajednički trud kompanija IBM, Microsoft, i BEA. Ovaj dokument je predložio jezik za orkestraciju koji je bio inspirisan prethodnim varijacijama, IBM-ovim WSFL (Web Services Flow Languge12), i Microsoft-ovoj XLANG specifikaciji13. Verzija 1.1. BPEL4WS specifikacije, nastala u saradnji sa kompanijama SAP i Siebel Systems, je nastala u maju 2003. Ova verzija je dobila više pažnje i podrške industrije. U to vreme je BPEL4WS specifikacija bila predata OASIS tehničkom komitetu, u cilju da specifikacija bude razvijena u oficijelni otvoreni stantard. Sam jezik je preimenovan u WS-BPEL (Web Services Business Process Execution Langage) [Alves et al., 2007].

WS-BPEL je procesno orijentisan kompozicioni jezik za Web servise, koji se oslanja na WSDL. On dozvoljava kreiranje apstraktnih procesa koji mogu opisati poslovne protokole, kao i izvršnih procesa koji se mogu kompajlirati u izvršne skripte. WSDL dokument koji opisuje WS-BPEL proces sadrži interfejse za sam proces servis, kao i za sve ostale poslovne servise koji učestvuju u izvršavanju procesa [Erl, 2005].

WS-BPEL se oslanja na WS-Coordination [Cabrera et al., 2005] da bi ponudio okruženje za upravljanjem kontekstom. Koordinacioni tip poslovne aktivnosti, kao što je definisan u WS-Transaction [Cox et al., 2004], se koristi za utvrđivanjem standardnog mehanizma za upravljanjem aktivnostima koje dugo traju.

11 stara specifikacija: http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel1.pdf12 http://www.ibm.com/developerworks/library/ws-ref4/ 13 http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

22

Krajnji cilj jezika poslovnih procesa je da kompletno apstrakuju Web servise koji se nalaze u pozadini, tako da ustvari sam jezik poslovnih procesa postane API za Web servise. Takav apstraktni jezik naravno ne bi bio pogodan za sva scenarija bazirana na Web servisima, ali bi on sigurno bio koristan za neka scenarija.

2.4.8. Nedostaci Web servisa

Web servisi omogućavaju laku integraciju poslovne logike koristeći XML tehnologije, ali ipak oni nam ne dozvoljavaju da izrazimo šta servis u stvari radi. Npr. ako servisi koriste različite XML tag-ove da bi označili (engl., annotate) svoje operacije/poruke, onda nije moguće otkriti da dve operacije koje nude različiti servisi sa različitim WSDL definicijama u stvari imaju istu funkcionalnost [Fensel et al., 2007]. Slično, pretraga repozitorijuma po ključnim rečima (engl., keyword based) koristeći prirodne jezike, koju nudi UDDI, u realnim scenarijima možda neće biti dovoljna. XML formati poruka koji koriste različiti servisi mogu da budu sintaksno nekompatabilni, tako da se ostavlja, ustvari, ljudima da odrade integracioni deo posla.

Obećanje dinamičke selekcije, i automatske integracije softverskih komponenti koje su realizovane kao Web servisi tek treba da se ostvari [Akkiraju, 2007]. Ovo je delimično i zbog toga što trenutni standardi Web servisa ne pominju semantiku. Da bi pokušala da reši ovaj problem, zajednica semantičkog Weba je uvela tzv. semantičke Web servise. Kodiranje zahteva i mogućnosti Web servisa u mašinama jasnoj i obradivoj formi, semantika čini da automatsko otkrivanje, kompozicija i integracija softverskih komponenti bude moguća [McIlraith et al., 2001] (sledeći odeljak uvodi semantičke Web servise kao način da se postigne ova vizija). Semantički Web i Web servisi su komplementarne tehnologije: semantički Web dodaje mašinski obradivu semantiku podacima, a Web servisi uvode bezbolnu integraciju proizvoljnih aplikacija. Kombinacija ove dve tehnologije obećava u potpunosti mehanizovan Web za kompjutersku interakciju.

2.5. Semantički Web servisi

Termin semantički Web servisi je verovatno prvi put upotrebljen u radu [McIlraith et al., 2001]. U tom radu su semantički Web servisi opisani kao Web servisi čija su „svojstva (engl., properties), mogućnosti, interfejsi, i efekti enkodovani u jasnoj i mašinski obradivoj formi“. Taj termin sadrži dva gradivna bloka koja bi mogla da se iskombinuju, čime bi se pak napravio korak bliže automatizaciji servisa: 1) semantički Web – ima za cilj dodavanje mašinski obradive semantike podacima; 2) Web servisi – imaju za cilj integraciju raznih aplikacija i automatizaciju poslovnih procesa, tako što nude okruženje bazirano na standardima za dinamičku razmenu informacija između aplikacija.

Zahtevi za semantičke opise Web servisa su u skladu sa zahtevima za obične Web servise. Ipak, postoje male ali važne razlike, kao što je korišćenje ontologija kao deljenih

23

rečnika, koje obećavaju viši stepen automatizacije. Od tehnologije semantičkog Weba se očekuju da imaju najveći potencijal u sledećim servisno orijentisanim zadacima [Fensel et al., 2007]:

Modelovaje – tokom modelovanja servisa, servis provajder može detaljno opisati semantiku tako što će anotirati određene delove Web servisa sa konceptima iz bogatijeg semantičkog modela. Obzirom da semantički modeli nude dogovor o značenju i korišćenju termina, i mogu ponuditi formalne i neformalne definicije entiteta, biće manje nejasnoća u samoj semantici provajdera. Ovi sematički Web servisi se onda mogu objaviti u registru.

Otkrivanje – pre nego što se servis koji je objavljen na Webu (ili unutar neke organizacije) može koristiti, on prvo mora biti lociran. Tokom otkrivanja, servis potraživač može opisati zahteve servisa koristeći termine iz sematičkog modela. Tehnike rezonovanja se mogu koristiti da bi se našle semantičke sličnosti između opisa servisa i zahteva.

Pregovaranje – kada god se nađe odgovarajući provajder (onaj koji zadovoljava naše potrebe), neophodno je pregovarati o instanci servisa iz moguće grupe servisa koju dati provajder može da ponudi. Ovo uključuje utvrđivanje kurseva delovanja o poverenju (engl., trust policies), utvrđivanju načinu plaćanja, selekciji ponuda itd., gde su nam opet potrebne odgovarajuće semantičke anotacije.

Kompozicija – u slučajevima kada određen cilj ne može da se postigne korišćenjem samo jednog Web servisa, semantički opisi bi nam mogli pomoći da utvrdimo pravu kombinaciju više Web servisa. Kompozicija ne samo da zahteva semantičke anotacije celokupnih mogućnosti servisa, već i opise ponašanja (engl., behavioral description) o tome kako interagovati sa Web servisom, da bi se postigla određena funkcionalnost.

Pozivanje – tokom poziva servisa sematika se može koristiti za predstavljanje transformacije podataka. U slučaju greške tokom izvršavanja, semantika nam može pomoći jer omogućava automatko otkrivanje i vezivanje servisa koji predstavljaju odgovarajuću zamenu.

Sada ćemo opisati neke od novijih predloga za uvođenja semantike Web servisima. Ti predlozi uključuju inicijative, projekte i jezike, kao što su OWL-S, WSDL-S, i WSMO.

2.5.1. OWL-S

OWL-S [Martin et al., 2004] inicijativa ima korene u DAML ontologiji za servise (DAML Service Ontology, prvobitno se zvala DAML-S), čija je prva verzija objavljena maja 2001. god. Struktuiranje ontologije servisa je motivisano potrebom da se obezbede tri esencijalna tipa znanja o servisu (slika 2.27), od kojih je svaki okarakterisan pitanjem na koji nudi odgovor: Šta servis nudi klijentima? Kako se koristi? Kako neko da komunicira sa njim?

24

Slika 2.27: Konceptualni model OWL-S-a [Martin et al.,2004]

Servisni profil (ServiceProfile) izražava „šta servis radi“ sa ciljem reklamiranja, i služi kao šablon za servisne zahteve, tako omogućavajući otkrivanje servisa. Servis može biti opisan servis modelom (ServiceModel), koji ističe „kako servis radi“. Glavna svrha servis modela je da omogući pozivanje, kompoziciju, monitoring servisa i njegov oporavak. Da bi mogao da se mapira u svet Web servisa, OWL-S podržava utemeljivanje (ServiceGrounding) koje mapira konstrukte proces modela, u detaljne specifikacije formata poruka i protokola [Akkiraju, 2007] [Fensel et al., 2007]. OWL-S se ne ograničava na WSDL kao jedinu tehnologiju, samim tim OWL-S bi i trebalo posmatrati kao opštu ontologiju deskriptora servisa, koja je proširiva i na druge mehanizme za utemeljivanje.

2.5.2. WSDL-S

U poređenju sa OWL-S-om, WSDL-S [Akkiraju et al., 2005] predstavlja minimalistički pristup koji cilja na direktno proširenje semantikom postojecih, „tradicionalnih“ opisa Web servisa, odnosno WSDL-a. Koristeći proširivost WSDL elemenata, može se kreirati skup anotacija da bi se semantički opisali ulazi, izlazi i operacije Web servisa, kao i specificiranje kategorije servisa u eksterno definisanoj ontologiji. Jedna prednost ovog pristupa je da se on nadograđuje na postojeće industrijske standarde (programeri su uglavnom već upoznati sa WSDL-om). Druga je da se semantički modeli održavaju van WSDL dokumenta (nezavisno od njega), dakle samo se referencira na njih. Ovo pak znači da programeri imaju izbor da anotiraju Web servise nekim svojim izborom jezika za ontologije (npr. UML ili OWL-S) [Akkiraju et al., 2005]. Ovo je bitno, jer mogućnost da se ponovo iskoristi postojeći domen model izražen u jezicima za modelovanje (kao što je UML), može dosta umanjiti potrebu da se semantika odvojeno modeluje.

Dizajnerski principi WSDL-S-a se mogu sumirati na sledeći način:

- WSDL-S cilja da se nadogradi na postojeće standarde za Web servise, i nudi kompatibilne mehanizme za dodavanje semantike Web servisima

25

- Anotacije treba da budu nezavisne od jezika za predstavljanje semantičkog modela. WSDL-S ne kaže koji jezik za predstavljanje semantike treba da se koristi.

- Podrška za anotacije tipova podataka XML sheme treba da se doda XML shemi, jer je ovo najvažniji formati definisanja podataka u sferi Web servisa

(ova treća tačka, zatvaranje procepa između WSDL opisa poruka (inputs/outputs) u terminima XML sheme i njihovih semantičkih parnjaka, je upravo problem koji se adresira u OWL-S (i WSMO) u komponenti koja se bavi utemeljivanjem (engl., grounding) [Akkiraju, 2007])

Slika 2.28: WSDL-S proširenja [Gasevic & Wager, 2007]

Slika 2.29: Eksterna predstava i asocijacija semantike i WSDL elemenata [Akkiraju et al., 2005]

26

Slika 2.29 prikazuje suštinu WSDL-S-a. Ona naglašava kako se domen model čuva eksterno u odnosu na model Web servisa, i kako su asocijacije između WSDL koncepta i njihovih odgovarajućih semantičkih anotacija uspostavljene koristeći (URI) reference.

I na kraju pomenimo i SAWSDL (Semantic Annotations for WSDL and XML Schema) [Farell & Lausen, 2007]. SAWSDL je postala preporuka (engl. recomenndation) W3C konzorcijuma u avgustu 2007 god., i ona definiše mehanizme kojima se semantičke anotacije mogu dodati WSDL komponentama.

2.5.3. WSMO (Web Service Modeling Ontology)

WSMO (Web Service Modeling Ontology) je konceptualni model za opisivanje različitih aspekata vezanih za semantičke Web servise [Feier, 2005]. Njegov cilj je da razreši problem integracije aplikacija kod Web servisa.

WSMO identifikuje četiri elementa, na visokom nivou, kao glavne koncepte: ontologije, Web servise, ciljeve, i medijatore (slika 2.30)

Slika 2.30: Centralni elementi WSMO-a [Lausen et al., 2005]

Ontologije nude terminologiju koja se koristi, i predstavljaju ključni element za uspeh semantičkih Web servisa. Web servisi nude opis (mogućnosti, interfejsa, i internog rada) servisa. Ciljevi (goals) predstavljaju korisnikove želje koje se ispunjavaju izvršavanjem Web servisa. I na kraju, medijatori opisuju elemente koji prevazilaze interoperabilne probleme različitih WSMO elemenata, npr. dve različite ontologije ili servisa.

S obzirom na potrebu za posredovanjem unutar semantičkih Web servisa (posredovanje se bavi problemom heterogenosti, tj. rešavanjem mogućih razlika između resursa koji bi trebali da budu interoperabilni), WSMO identifikuje tri nivoa posredovanja: posredovanje na nivou podataka; posredovanje na nivou funkcionalnosti; posredivanje na nivou procesa. Takođe WSMO definiše i nekoliko tipova medijatora: OO medijatori, GG medijatori, WG medijatori, i WW medijatori [Lausen et al., 2005].

WSML (Web Service Modeling Language) je formalan jezik za opis ontologija i semantičkih Web servisa, koji uzima u obzir sve aspekte opisa Web servisa koje identifikuje WSMO. Baš kao što se OWL-S oslanja na OWL ontološki jezik, tako se WSMO okruženje oslanja na WSML [Akkiraju, 2007]. Baš kao što OWL definiše više

27

vatijanti jezika (OWL-Full, OWL-DL, OWL-Lite), WSML ima varijante WSML-Core, WSML-DL. WSML-Rule i WSML-Flight.

2.5.4. Nedostaci semantičkih Web servisa

Jedan od najvećih nedostataka OWL-S-a je da programeri moraju ulošiti puno truda samo da bi krenuli da ga koriste (krivulja učenja ove tehnologije je veoma strma). Jedan od razloga za ovo je i da ne postoji baš neka podrška alata za OWL-S14. Druga mana koju bi istakli je da OWL-S profil model ponavlja opise koji već postoje u WSDL-u (inputs i outputs). Ovo dovodi do toga da mora da se kreira više definicija za opisivanje istog servisa. Još jedna mana koji bi pomenuli, jeste i što OWL-S podrazumeva da svi koriste OWL za predstavljanje ontologija, što ne mora baš uvek da bude slučaj.

2.6. Modelovanje Web servisa

MDA pretstavlja idealno okruženje za ubacivanje tehnika modelovanja u proces razvoja Web servisa [Vara et al., 2005]. Podsetimo se ovde nekih od prednosti koje dobijamo korišćenjem MDA [Bezivin et al., 2004]: isti PIM se može iskoristiti više puta za generisanje modela na različitim platformama (PSM); više pogleda na isti sistem (npr. više nivoa apstrakcije ili detalja implementacije); očuvanje poslovne logike od promena ili evolucije tehnologije; poboljšanje interakcije i migracije između različitih tehnoloških prostora; itd. Pored svih ovih prednosti, sam pristup korišćenja modela tera arhitekte da razmišljaju o arhitekturi i o modelu koji stoji iza sistema koji se razvija (za razliku od pristupa koji je zasnovan na kodu, gde se arhitekte koncetrišu na kod).

2.6.1. Različiti pristupi za modelovanje Web servisa

U ovom poglavlju ćemo izdvojiti neke od pristupa modelovanja Web servisa koji se mogu naći u literaturi.

U radu [Timm & Gannod, 2005] je opisan alat koji koristi MDA tehnike za generisanje OWL-S opisa Web servisa iz UML modela. U radu se naglašava razlog za kreiranje ovakvog alata: krivulja učenja OWL-S-a je prilično strma, tako da bi postojanje jednog ovakvog alata programerima omogućilo da se fokusiraju samo na kreiranje modela Web servisa u nekom standardnom UML alatu. MDA pristup olakšava kreiranje opisa sematičkih koncepta dok sakriva sintaksne detalje kreiranja OWL-S specifikacija. Alat opisan u ovom radu se bazira na korišćenju UML profila baziranom na OWL-S-u i WSDL-u, kao i na korišćenju XSLT transformacija za transformisanje XMI-ja (XML predstave UML-a) u OWL-S.

14 Od raspoloživih alata bi izdvojili OWL-S editor (http://owlseditor.semwebcentral.org/) koji je napravljena kao plugin za Protege Ontology Editor (http://protege.stanford.edu/index.html)

28

U radu [Bezivin et al., 2004] je predstavljen razvoj jednog primera (turističke agencije) uz pomoć modela koristeći MDA pristup. PIM ovog primera je kreiran korišćenjem UML-a. Ovaj PIM je zatim transformisan korišćenjem ATL-a (Atlas Transformation Language) u PSM, baziranim na tri ciljne platforme: Java, Web servisi i Java Web Service Developer Pack15 (JWSDP). Ovaj rad nudi prikaz delova UML metamodela, Java metamodela, kao i WSDL (verzija 1.1) metamodela. U radu se takođe ističe i da su XSLT i logički jezici efikasni za transformaciju modela koji su bazirani na prostim metamodelima, ali da su oni ograničeni i podložni greškama za transformaciju modela baziranim na većim metamodelima.

U radu [Brambilla et al., 2006] je predstavljeno okruženje za dizajniranje i razvoj semantičkih Web servisa koristeći tehnike, metodologije i notacije koje se nude u softverskom inženjerstvu, inženjerstvu za Web (engl., Web engineering), i u modelovanju poslovnih procesa. Autori naglašavaju da je jedan od glavnih problema pri prihvatanju tehnologija semantičkog Web-a dodatni trošak koji nastaje zbog ručnog semantičkog anotiranja softverskih komponenti. U radu je predložen metod i skup alata za promovisanje razvoja semantičkih Web servisa (npr. WSMO-a). U radu se koriste metode Web enženjeringa, uključujući vizuelno deklarativno modelovanje (npr. WebML16, Web Modeling Language), automatsko generisanje koda (koji se može izvršavati lokalno ili globalno kroz semantičku izvršnu sredinu (engl., sematic execution environment) kao što je WSMX17, Web Service Modelling eXecution environment), i automatsko evociranje semantičkih opisa (npr. WSMO ontologja, ciljeva, Web servisa i medijatora) iz samog dizajna aplikacije.

U radu [Manolescu et al., 2005] je predstavljen konceptualni pristup dizajnu Web servisa koji je formalno definisan kao proširenje WebML (Web Modeling Language) jezika i koji je implementiranu u WebRatio18-u, CASE alatu koji podržava razvoj aplikacija u WebML jeziku. Primitive za modelovanje koje su predložene u ovom radu se oslanjaju na metamodel Web servisa, kao i na nove WebML operacione jedinice koje izražavaju različite tipove WSDL operacija, i na XML procesiranje podataka koje je potrebno za integrisanje poruka koje se razmenjuju između Web servisa.

U radu [Vara et al., 2005] je predstavljen jedan alat za podršku modelovanju Web servisa: MIDAS-CASE. MIDAS-CASE je MDA alat za razvoj informacionih sistema za Web. Korišćenjem proširenja UML-a za potrebe WSDL-a, predloženi MIDAS-CASE sistem podržava modelovanje Web servisa u tako proširenom UML-u, kao i automatsko generisanje odgovarajućeg WSDL dokumenta za modelovani Web servis. U radu je takođe ponuđen i WSDL (verzija 1.1) metamodel.

Naredna tabela (tabela 2.1) sumira raličite pristupe modelovanja Web servisa koje smo ovde izložiliPristup

Metamodel Opis modela Transformacioni mehanizam

Generisan izlaz

15 http://java.sun.com/webservices 16 http://www.webml.org/ 17 http://www.wsmx.org/ 18 http://www.webratio.com/

29

[Timm & Gannod, 2005]

UML profil UML XMI XSLT OWL-S

[Bezivin et al., 2004]

MOF MOF XMI ATL WSDL, Java, JWSDP

[Brambilla et al., 2006]

WebML WebML modeli XSLT semantički opisi (npr.

WSMO ontologja, ciljeva, Web servisa i medijatora)

[Manolescu et al., 2005]

Proširenje WebML

WebML modeli Vizuelan editor za XSLT

WebRatio izlazi(XML, Java, C#, JSP...)

[Vara et al., 2005]

UML profil UML XMI MIDAS-CASE transformaciona

jedinica

MIDAS izlazi (WSML...)

Tabela 2.1: Pregled prezentovanih pristupa modelovanja Web servisa

30