Web servisi
[email protected]
FER, 2006.
SADRŽAJ:
1. Osnovno o Web servisima.................................................................................................. 4
1.1 Što je to Web servis?................................................................................................ 4
1.2 Arhitektura i tehnologije Web servisa .................................................................... 9
1.2.1 Pogled na cjelinu................................................................................................ 9
1.2.2 XML malo detaljnije ......................................................................................... 16
1.2.3 SOAP malo detaljnije....................................................................................... 19
1.2.4 WSDL malo detaljnije...................................................................................... 20
1.3 Zašto je XML tako važan? ...................................................................................... 21
1.4 Motivi i potencijali. .................................................................................................. 23
1.5 Pitanje sigurnosti..................................................................................................... 25
1.6 Organizacije i standardi.......................................................................................... 26
1.7 Korak dalje ............................................................................................................... 29
2. Razvoj Web servisa u .NET okruženju ........................................................................... 32
2.1 Što je .NET ? ............................................................................................................ 32
2.2 Softverski preduvjeti ............................................................................................... 36
2.3 Visual Studio .NET - izgradnja i korištenje Web servisa ................................... 37
2.3.1 Izgradnja Web servisa .................................................................................... 37
2.3.2 Korištenje Web servisa u .NET aplikacijama ............................................... 45
2.4 .NET SDK - izgradnja i korištenje Web servisa ............................................... 51
2.4.1 Izgradnja Web servisa .................................................................................... 51
2.4.2 Korištenje Web servisa.................................................................................... 51
2.5 SOAP...................................................................................................................... 53
2.5.1 Uvod i osnovni pojmovi................................................................................... 53
2.5.2 Struktura SOAP poruke ................................................................................... 54
2.5.3 SOAP Encoding................................................................................................. 56
2.6 UDDI i DISCO ......................................................................................................... 58
2.6.1 UDDI – Universal Description, Discovery and Integration ........................ 58
2.6.2 Microsoft UDDI Services ................................................................................. 60
2.6.3 Microsoft DISCO............................................................................................... 60
2.7 Sigurnost ................................................................................................................. 61
2.7.1 Web Services Security (WS-Security) ........................................................... 61
2.7.2 Microsoft Web Services Enhancements........................................................ 62
3. Windows Communication Foundation ............................................................................ 63
3.1 Uvod .......................................................................................................................... 63
3.1.1. Usluge i arhitektura zasnovana na uslugama (SOA)................................. 63
3.1.2. Windows Communication Foundation (WCF)............................................. 66
3.2 WCF usluge .............................................................................................................. 67
3.3 WCF klijenti .............................................................................................................. 72
REFERENCE............................................................................................................................. 75
2
Uvod
Cilj rada je pružiti uvod u tehnologiju Web servisa uz malo ili nimalo predznanja o srodnim
tehnologijama. Pojašnjene su glave ideje bez previše tehničkih detalja koji u početnoj fazi nemaju
preveliku važnost. Svi aspekti Web servisa se pokušavaju objasniti korak po korak, i pritom se
pokušava ostvariti nekakav logički slijed.
U prvom dijelu je objašnjen koncept Web servisa i odgovara se na pitanje što su uopće Web
servisi. Opisuje se arhitektura Web servisa što meñu ostalim obuhvaća i tehnologije koje se koriste za
izgradnju Web servisa. Osim cjelovitog pogleda, pokušava se malo detaljnije pojasniti tehnologije XML,
SOAP i WSDL koje su ključne za izgradnju Web servisa. Ističe se važnost XML-a u razvoju Web servisa
i zaslužnost XML-a za glavna svojstva Web servisa, neovisnost o platformi i programskom jeziku.
Obzirom na važnost sigurnosti jedno od glavnih pitanja je i pitanje sigurnosti Web servisa. Kako ideja
Web servisa ne bi ostavila dojam teorije bez prakse, opisuje se što Web servisi znače za razvoj
softvera, koje su im glavne prednosti i gdje ih se može naći u stvarnosti. Dodatni doprinos smještaju
Web servisa u stvarni svijet je i dio koji se bavi organizacijama izravno uključenima u razvoj standarda
i tehnologije Web servisa.
3
1. Osnovno o Web servisima
1.1 Što je to Web servis?
Iz samog naziva „web servis“ mogu se zaključiti dvije stvari.
Radi se o nekom servisu, tj. nekoj usluzi. Netko se poslužuje, servisira. Može se jednostavno zaključiti
da naziv web servis ukazuje da se radi o dvije strane koje meñusobno komuniciraju. Jedna strana
servisira tj. poslužuje drugu stranu. Dakle jedna strana je servis (Web servis), a druga strana je
korisnik tog servisa. Web servis poslužuje svog korisnika.
Osim toga radi se o nečemu što je dostupno i koristi se putem Weba, odnosno Interneta.
Na pitanje, što čini Web, većina bi ljudi vjerojatno odgovorila Web stranice. Web stranice su
element Web-a. One korisniku pružaju podatke. Ako se za primjer uzme jednostavna Web stranica
dnevnih novina ona bi se mogla nazvati statičkim elementom Web-a. Zašto? Zato što svi korisnici te
Web stranice dobivaju jednake informacije, jednaki sadržaj.
Web stranica dnevnih novina sadrži vijesti. Te vijesti su iste za sve korisnike koji pristupaju stranici.
Bez obzira koliko korisnika otvori stranicu u browseru oni će svi dobiti jednake vijesti i jednake
informacije. Općenito gledano sadržaj Web stranice koju korisnik otvori u svom browseru ne ovisi o
nekim posebnim parametrima, nego je rezultat običnog klika na hyperlink. Klikom na hyperlink 1
otvorit će se web stranica 1. Klikom na hyperlink 2 otvorit će se web stranica 2 itd. Ako 100 korisnika
klikne na hyperlink 1, svih 100 korisnika će dobiti jednaki sadržaj web stranice 1. Ako 100 korisnika
klikne na hyperlink 2, svih 100 korisnika će dobiti jednaki sadržaj web stranice 2. Drugim riječima,
sve što korisnik čini je dohvaćanje odreñene Web stranice, jer je to jedino što mu ta Web stranica
omogućava. Može se reći da se korisniku nad takvom Web stranicom pruža samo jedna funkcija, a to
je dohvat te stranice.
4
Slika 1.1: Dohvatom Web stranice svi korisnici dobivaju isti sadržaj
Za razliku od Web stranica, Web servisi funkcioniraju na drugačiji način. Podaci koje korisnik
dobiva od Web servisa u potpunosti ovise o podacima odnosno parametrima koje korisnik šalje Web
servisu. Izlazni podaci Web servisa su funkcija ulaznih podataka, pa se može reći da Web servisi
pružaju funkcionalnost.
Svrha Web servisa je pružanje odreñene funkcionalnosti svom korisniku. Jednako kao i Web stranice,
Web servisi su dostupni i koriste se putem Web-a. Web servisi su dakle element Web-a, baš kao i Web
stranice.
Može se postaviti pitanje: kako ja, kao krajnji korisnik, mogu koristiti Web servis odnosno
funkcionalnost koju on pruža? Odgovor je jednostavan. Nikako.
Jedna od temeljnih razlika izmeñu Web stranica i Web servisa je da Web servisi nisu predviñeni za
korištenje od strane krajnjih korisnika računala (ljudi). Ali ako ih ne koriste krajnji korisnici, tko ih onda
koristi? Pa umjesto krajnjih korisnika (ljudi), Web servise i njihovu funkcionalnost koriste aplikacije, tj.
programi.
Dakle aplikacije (programi) su te koje putem Interneta koriste Web servise i njihovu funkcionalnost.
Aplikacije šalju Web servisima ulazne podatke (parametre) i kao rezultat od Web servisa dobivaju
izlazne podatke. Bitno je naglasiti da su izlazni podaci funkcija ulaznih podataka. To znači da izlazni
podaci ovise isključivo o ulaznim podacima.
Značenje ulaznih i izlaznih podataka ovisi o namjeni aplikacije i Web servisa kojeg aplikacija koristi.
Neka aplikacija može imati bilo kakvu namjenu i pritom koristiti funkcionalnost odreñenog Web
servisa.
Slika 1.2: Slanjem svojih ulaznih podataka Web servisu, aplikacije
kao odgovor primaju svoje izlazne podatke
5
Da bi se pojam Web servisa malo povezao sa stvarnim svijetom slijedi nekoliko primjera:
-aplikacija za preračun valuta u mjenjačnici može koristiti web servis neke banke kako bi dohvatila
najnovije tečajne liste,
-Web aplikacija za rezervaciju hotelskog smještaja može koristiti Web servis nekog hotela kako bi:
dohvatila točan broj slobodnih soba, napravila rezervaciju itd. ,
-Web aplikacija za rezervaciju avionske karte može koristiti Web servise različitih avio-kompanija kako
bi: dohvatila dostupne letove, mjesta na tim letovima i njihove cijene, napravila rezervaciju itd.
Kako bi još malo razjasnili pojam funkcionalnosti web servisa i povezali ga sa prethodnom
slikom iskoristit ćemo sljedeći primjer.
Neki lanac hotela u svojem računalnom sustavu ima sve podatke o broju slobodnih soba,
kategoriji i cijeni tih soba, dodatnim mogućnostima koje se nude gostima itd. U isto vrijeme postoji
veliki broj turističkih agencija koje se bave organizacijom putovanja. Te turističke agencije imaju svoje
Web stranice (Web aplikacije) putem kojih nude informacije o odredištima, smještaju te nude
mogućnost rezervacije smještaja i razne druge usluge.
Da bi povezali svoje poslovanje, hotelski lanac uspostavlja Web servis kojim nudi sve što neka
agencija može zatrebati. Jedinstveni Web servis za cijeli hotelski lanac. Taj jedinstveni Web servis
mogu koristiti mnoge Web stranice turističkih agencija kako bi ponudile jedinstvenu uslugu na jednom
mjestu. Dakle jedan Web servis koristi veliki broj Web stranica (Web aplikacija) koje komuniciraju s
tim Web servisom. Šalju mu različite ulazne podatke i parametre, te od njega dobivaju povratne
podatke i informacije ovisno o poslanim ulaznim parametrima.
Na primjer, dok jedna Web stranica Web servisu šalje upit kojim želi saznati cijenu noćenja u
dvokrevetnoj sobi, druga Web stranica Web servisu šalje podatke osobe koja želi rezervirati smještaj.
Prva Web stranica će kao povratnu informaciju dobiti podatke o cijeni noćenja u dvokrevetnoj sobi,
dok će druga Web stranica dobiti informaciju o uspješnoj rezervaciji smještaja.
Dakle taj Web servis pruža funkcionalnost. Ta funkcionalnost su zapravo usluge i informacije o
uslugama hotelskog lanca. Tu funkcionalnost koriste Web aplikacije turističkih agencija kako bi
krajnjim korisnicima (ljudima) omogućile pregledavanje i korištenje usluga hotelskog lanca dok sjede
za svojim računalom. Primjer ilustrira slika 3a.
6
Slika 1.3: Primjer Web servisa hotelskog lanca
No čak ni to nije potpuno realistično. Mnogo je realniji scenarij gdje jedna Web aplikacija koristi
mnogo Web servisa različitih hotelskih lanaca kako bi svojim krajnjim korisnicima omogućila pristup
uslugama velikog broja hotela. To ilustrira slika 4.
Slika 1.4: Realni scenarij primjene Web servisa i njihove funkcionalnosti
Sada bi trebalo biti malo jasnije što su to Web servisi te koja je njihova svrha. Web servisi su elementi
Web-a, baš kao i Web stranice. Njihova svrha je pružanje funkcionalnosti aplikacijama putem
Interneta. Mogućnosti primjene su praktično neograničene i najveći problem je osmisliti dovoljno
inovativno rješenje.
Web servis nije nešto što se može kupiti kao gotov proizvod i zatim instalirati na odreñenom
računalu. Znamo da Web servis pruža odreñenu funkcionalnost. Da bi se u stvarnom svijetu ponudila
neka usluga, odnosno funkcionalnost u obliku Web servisa, potrebno je tu funkcionalnost softverski
implementirati, tj. programirati. Npr. da bi servis hotelskog lanca mogao zaprimiti nečiju rezervaciju,
potrebno je napisati programski kôd „koji je zadužen“ za komunikaciju s hotelskom bazom podataka i
unos rezervacija u bazu.
Dakle, Web servisi su softverski sustavi.
Potrebno je razlikovati samu uslugu tj. funkcionalnost Web servisa od njegove softverske
implementacije. Softverska implementacija Web servisa je njegov agent. Vratimo se ponovo na
primjer Web servisa hotelskog lanca. Taj Web servis pruža funkcionalnost koja je jasno definirana
(dohvat podataka o sobama, rezervacija smještaja itd). Pretpostavimo da je hotelski lanac zbog toga
angažirao softversku tvrtku koja je za potrebe lanca razvila Web servis, odnosno tvrtka je napisala
agent (program) kojim se ostvaruje funkcionalnost tog Web servisa. Iz bilo kojeg razloga, lanac može
angažirati neku drugu softversku tvrtku koja će napisati svoj agent kojim se opet ostvaruje ista
funkcionalnost hotelskog Web servisa. Dakle novi Web servis pruža iste usluge i ima istu
funkcionalnost, iako se agent promijenio. Agent i funkcionalnost koju on pruža su dvije zasebne
komponente koje čine Web servis.
7
Web servisi, kao softverski sustavi, će se nalaziti na Web poslužitelju gdje će biti dostupni za
korištenje aplikacijama putem Web-a.
Softverska implementacija Web servisa izvodi se u nekom objektno orijentiranom
programskom jeziku. Temeljni element programa pisanog objektno orijentiranim jezikom je razred
(klasa). Razred se sastoji od svojih članova: svojstava i metoda. Prilikom izvoñenja programa razred
se instancira čime nastaje objekt u memoriji računala. Nad tim objektom se pozivaju metode koje on
pruža. Softverska implementacija Web servisa (u daljnjem tekstu: program) će se dakle sastojati od
razreda koji će svojim metodama ostvarivati funkcionalnost koju Web servis pruža.
Kako bi stvar još bolje pojasnili iskoristit će se primjer već spomenutog Web servisa hotelskog lanca.
Taj Web servis, kao što je ranije spomenuto, svojim korisnicima (aplikacijama) nudi različite usluge:
informacije o dostupnim sobama i o cijenama soba, mogućnost rezervacije smještaja itd.
Softverska implementacija Web servisa tog hotelskog lanca biti će ostvarena npr. razredom
HotelskiLanac. Znamo da su metode članovi razreda i znamo da se metodama ostvaruje
funkcionalnost. To znači da će u razredu HotelskiLanac
postojati npr. metoda
DohvatiDostupneSobe koja će kao svoj rezultat vraćati informacije o dostupnim sobama, zatim
metoda RezervirajSobu koja će vršiti rezervaciju sobe te kao svoj rezultat vraćati informaciju o
uspješnoj ili neuspješnoj rezervaciji itd.
Sada bi već trebao biti jasan odgovor na pitanje: tko poziva metode razreda HotelskiLanac ? Te
metode poziva upravo korisnička aplikacija koja koristi Web servis tj. njegovu funkcionalnost. To znači
da će korisnička aplikacija, kada želi rezervirati sobu, jednostavno pozvati metodu RezervirajSobu koju
pruža naš Web servis tj. njegova softverska implementacija tj. njegov razred.
Obzirom da znamo da korisničke aplikacije komuniciraju s Web servisima preko Weba, to znači da se
metode koje Web servis pruža moraju moći pozivati preko Weba. Pozivanje metoda preko Weba
zapravo znači da korisnička aplikacija mora Web servisu poslati nekakvu poruku koja sadrži naziv
metode koja se poziva i njezine argumente ako ih metoda ima. Web servis će odgovoriti porukom koja
će sadržavati rezultat pozivanja te metode uz zadane argumente.
U nastavku je detaljnije opisano kako se ostvaruje komunikacija izmeñu aplikacije i Web servisa.
Pritom se spominje razmjena poruka, slanje zahtjeva Web servisu itd. No treba imati na umu da se ne
dešava ništa drugo osim toga da korisnička aplikacija poziva metode Web servisa i prima rezultate od
Web servisa.
Slika 1.5: Funkcioniranje Web servisa na softverskom sloju
8
Web servisi će općenito imati dvije vrste metoda. Metode koje su dostupne korisničkim aplikacijama i
metode koje to nisu (lokalne metode). Kako razlikovati te metode ovisi o konkretnoj platformi i
programskom jeziku.
Postoje mnogi jezici i mnoge platforme za razvoj Web servisa. U ovom radu se za razvoj koristi
Microsoft .NET platforma i jezik C#. Više o tome u drugom poglavlju.
1.2 Arhitektura i tehnologije Web servisa
1.2.1 Pogled na cjelinu
Do sada je poznato da je Web servis softverski sustav, pojednostavljeno rečeno: aplikacija tj.
program. Program Web servisa zove se agent Web servisa i on ostvaruje funkcionalnost koju Web
servis pruža. Agent Web servisa već spomenutog hotelskog lanca nalazi se na nekom Web serveru i
svojom funkcionalnosti korisnicima omogućava korištenje usluga hotelskog lanca.
Ranije je spomenuto da naziv Web servis ukazuje na to da postoje dvije strane koje
meñusobno komuniciraju. To su Web servis i njegov korisnik. Takoñer je spomenuto da su korisnici
Web servisa neke druge aplikacije tj. programi. Obzirom da Web servis pruža uslugu korisniku nazvat
ćemo ga pružatelj usluge ili kratko pružatelj (eng. provider). Aplikaciju koja koristi funkcionalnost
odreñenog Web servisa ćemo onda nazvati korisnik usluge ili kratko korisnik (eng. consumer).
Postavljaju se pitanja: Kako korisnik dolazi do spoznaje o pružatelju? Kako korisnik
„prepoznaje“ odgovarajućeg pružatelja, tj. pružatelja koji nudi funkcionalnost koju korisnik treba?
Kako korisnik i pružatelj meñusobno komuniciraju? Postoje li neki definirani modeli komunikacije
korisnika i pružatelja? Koji protokoli se pritom koriste? Koji format podataka se koristi u komunikaciji?
itd. Odgovore na ta pitanja daje pregled tehnologija i arhitekture Web servisa.
Komunikacijska podloga
Komunikacija izmeñu korisnika i pružatelja se odvija putem Interneta. To podrazumijeva korištenje
protokola protokola IP na mrežnoj razini, odnosno protokola TCP na transportnoj razini internetskog
modela. Na najvišoj aplikacijskoj razini za komunikaciju korisnika i pružatelja koriste se različiti
protokoli kao što su: HTTP, SMTP, FTP, JMS itd. Iako nije nužan za komunikaciju korisnika i
poslužitelja najkorišteniji protokol je HTTP (koji se ujedno koristi i za komunikaciju Web preglednika tj.
browsera i Web poslužitelja prilikom dohvata Web stranica). Protokol HTTP nije predmet promatranja
ovdje te neće biti detaljnije objašnjen, no bit će spominjan u kontekstu njegovog korištenja od strane
viših razina komunikacije korisnika i pružatelja. Pritom se podrazumijeva da se umjesto protokola
HTTP može koristiti i neki drugi protokol.
Slika 1.6: Podloga komunikacije izmeñu korisnika i pružatelja
9
Poruke
Tijekom svoje komunikacije korisnik i pružatelj razmjenjuju različite podatke. U slučaju Web
servisa hotelskog lanca koji poslužuje Web aplikaciju turističke agencije, servis (pružatelj) i aplikacija
(korisnik): razmjenjuju podatke o raspoloživosti smještaja u hotelu, uslugama i sadržajima u hotelu,
cijenama, o učinjenim rezervacijama i mnoge druge. Svi podaci se izmeñu korisnika i pružatelja
razmjenjuju unutar poruka. Poruke prenose podatke izmeñu korisnika i pružatelja. Može se reći da je
poruka jedinka komunikacije izmeñu korisnika i pružatelja.
Kao što je spomenuto ranije, sva komunikacija izmeñu korisnika i pružatelja se (najčešće) odvija iznad
protokola HTTP. To znači da korisnik i pružatelj jedan drugom šalju poruke uz pomoć protokola HTTP.
Slika 1.7: Razmjena poruka izmeñu korisnika i pružatelja. P=poruka.
Postavljaju se pitanja: postoji li neki „standardni“ oblik poruke i „standardni“ način njenog
slanja, koji je format zapisa podataka u poruci, koji je format zapisa same poruke itd.
Oblik poruke te način razmjene poruka izmeñu korisnika i pružatelja definira SOAP
specifikacija. SOAP je protokol za razmjenu informacija u raspodijeljenim okruženjima kao što je Web.
Temelji se na razmjeni SOAP poruka. SOAP poruka prenosi konkretne podatke (parametre) izmeñu
korisnika i pružatelja. Prilikom slanja zahtjeva pružatelju, korisnik kreira novu SOAP poruku, te u nju
upisuje podatke koje šalje pružatelju. Nakon što primi tu SOAP poruku, pružatelj iz SOAP poruke čita
podatke koje je poslao korisnik i obavlja svoju operaciju. Analogno tome, kod slanja odgovora
korisniku, pružatelj kreira novu SOAP poruku u koju posprema podatke i rezultate operacija
predviñene za korisnika i šalje poruku korisniku. Korisnik prima SOAP poruku i iz nje čita podatke.
Prethodno je navedeno da se poruke izmeñu korisnika i pružatelja prenose posredstvom protokola
HTTP. To znači da jedna HTTP poruka (paket) u svom tijelu sadrži tj. prenosi jednu SOAP poruku. Više
detalja o SOAP-u bit će navedeno kasnije.
10
Slika 1.8: Razmjena podataka izmeñu korisnika i pružatelja SOAP porukama
Preostaje pitanje u kojem obliku zapisa se podaci razmjenjuju izmeñu korisnika i pružatelja, te
koji je oblik zapisa same poruke. Drugim riječima, pitanje je da li su podaci samo običan niz znakova,
da li su strukturirani na neki način ili su pak zapisani u binarnom obliku.
Svi podaci koje razmjenjuju korisnik i pružatelj zapisani su u XML obliku. To znači da kada korisnik tj.
Web aplikacija turističke agencije s početka, želi pružatelju tj. Web servisu hotela poslati podatke o
osobama za koje treba napraviti rezervaciju, onda će korisnik te podatke zapisati u XML obliku, te ih
na taj način poslati pružatelju. Nakon što je priredio podatke u XML obliku, korisnik te podatke
smješta unutar SOAP poruke kao što je navedeno ranije. Osim podataka korisnika i pružatelja, SOAP
poruka mora sadržavati još neke podatke potrebne za pohranu informacija o poruci i drugih sustavskih
informacija. Cijela SOAP poruka će kao i podaci biti zapisana u XML obliku. XML je oblik zapisa SOAP
poruke i podataka koje SOAP poruka prenosi. Kako bi stvar bila jasnija slijedi primjer podataka koje
korisnik šalje pružatelju i SOAP poruke koja prenosi te podatke.
Slika 1.9: Primjer XML podataka koje korisnik šalje pružatelju
11
Slika 1.10: SOAP poruka s podacima
Malo više detalja o samo XML-u te o njegovom vrlo velikom značaju u području Web servisa, a i
raspodijeljenih okruženja općenito, bit će riječi malo kasnije.
Opisi
Vratimo se malo na izvorni primjer sa hotelskim lancem. Hotelski lanac želi ponuditi svoje
usluge u obliku Web servisa. Angažira se softverska tvrtka koja kreira Web servis koji nudi usluge
hotelskog lanca i učini taj Web servis dostupnim na Webu. Taj Web servis je postao element Weba.
Kad je Web servis kreiran i „pušten“ na Web, najjednostavnije što se može desiti je da potencijalni
korisnici tog Web servisa postanu „svjesni“ da se pojavio novi Web servis. Npr. uvidom u neku online
bazu, programer ili sama aplikacija, može saznati da se pojavio novi Web servis i da je njegov vlasnik
hotelski lanac.
Da li je sama spoznaja da Web servis postoji dovoljna da bi ga se koristilo ? Nije.
Spomenuto je ranije da su Web servisi softverski sustavi. To znači da oni prema svojim korisnicima
imaju odreñeno sučelje i da nude odreñene operacije tj. odreñenu funkcionalnost. Npr. Web servis
hotelskog lanca nudi operacije: rezervacije, provjere slobodnih kapaciteta itd. Složenost Web servisa i
funkcionalnost koju pruža može biti različita. I na tom mjestu u „igru“ ulaze opisi Web servisa. Opis
Web servisa (eng. description) ima ulogu pružiti sve potrebne informacije o tome što Web servis pruža
i kako ga iskoristiti.
Postoji li neki standardni (formalni) način opisivanja Web servisa? Postoji.
Opis Web servisa je dokument koji opisuje Web servis, odnosno njegovo sučelje i njegovo značenje tj.
semantiku. Opis Web servisa zove se WSD – Web Service Description. Za kreiranje opisa Web servisa
tj. za kreiranje WSD dokumenata postoji jezik: WDSL – Web Services Description Language.
WSDL dokument je XML dokument tj. opis Web servisa je zapisan u XML formatu. Ta činjenica
zajedno sa već ranije spomenutim SOAP porukama koje se takoñer u potpunosti temelje na XML
formatu zapisa podataka ukazuje na važnost XML-a koja će kasnije biti posebno naglašena. Jeziku
WSDL će malo kasnije biti posvećeno više pozornosti.
Već je poznato da Web servis čini njegova klasa koja pak sadrži članove (metode, svojstva...).
Opisi Web servisa omogućavaju korisničkim aplikacijama da dobiju informacije o Web servisu potrebne
12
da bi s njim komunicirale. Opisi dolaze u obliku .wsdl dokumenata. Svaki Web servis ima svoj .wsdl
dokument koji, meñu ostalim, opisuje one metode Web servisa koje su dostupne njegovim
korisnicima. Zašto samo te metode? Pa obzirom da .wsdl dokumenti služe korisnicima Web servisa
logično je da je njima bitan samo onaj dio Web servisa kojemu imaju pristup, a to su upravo te
metode ! Jednako kao i metode namijenjene korisniku, opis Web servisa je takoñer dostupan na Webu
što je i logično.
Slika 1.11: Opisi Web servisa
Koncept proxy klase
Najjednostavnije rečeno, proxy klasa je klasa koja se nalazi na strani korisničke aplikacije i
koja omogućava korisničkoj aplikaciji da koristi Web servis na jednak način kao sve druge klase u
svom (lokalnom) okruženju. To znači da će aplikacija koristiti proxy klasu na jedan način kao što
koristi i klasu za komunikaciju s datotekama, klasu za grafički prikaz itd. Proxy klasa se može nazvati
predstavnikom Web servisa u lokalnom okruženju korisničke aplikacije.
Proxy klasa se stvara na temelju .wsdl dokumenata Web servisa. Stvara se tijekom razvoja
aplikacije te zapravo postaje sastavni dio aplikacije.
Ukoliko se stvari analiziraju malo detaljnije, proxy klasa je ta koja ustvari komunicira s Web
servisom u ime korisničke aplikacije, no normalno se kaže da korisnička aplikacija koristi Web servis.
Takoñer je bitno naglasiti da proxy klasa „obavlja“ sve poslove oko komunikacije s Web
servisom, a to znači: stvaranje i analiziranje SOAP poruka, razmjena poruka itd. Programer koristi
proxy klasu kao i svaku drugu klasu (instanciranje klase, pozivanje metoda nad objektima klase itd.)
te pritom uopće ne mora brinuti o detaljima komunikacije !
Cijeli koncept prikazuje sljedeća slika.
13
Slika 1.12: Koncept proxy klase
Do sada su navedena dva bitna elementa arhitekture Web servisa: poruke i opisi. Oba se u
potpunosti temelje na XML formatu zapisa podataka. Opis Web servisa opisuje sučelje i funkcionalnost
Web servisa koju pruža svojoj okolini. Poruke rješavaju pitanje komunikacije izmeñu korisnika i
pružatelja. Sve se to dešava povrh protokola HTTP.
Slika 1.13: Djelomični pregled elemenata arhitekture Web servisa
Procesi
Nakon što smo pojasnili na koji način Web servis može komunicirati te kako opisom može
omogućiti korištenje vlastite funkcionalnosti nastavljamo korak dalje.
Zamislimo scenarij u kojem postoji mnogo Web servisa i mnogo korisnika. Svi mogu komunicirati
meñusobno. Takoñer svaki Web servis ima svoj WSD opis. U toj situaciji možemo Web servise i
njihove korisnike promatrati kao zasebne objekte u raspodijeljenom okruženju kao što je Web.
14
Slika 1.14: Korisnici i pružatelji kao zasebni objekti u raspodijeljenom okruženju
Iz ovakve perspektive moguće je promatrati odnose i dogañaje meñu prikazanim objektima u
mreži. Proces je općeniti naziv za neko dogañanje i odnos u mreži. Npr. najjednostavniji proces je
očito jednostavno korištenje Web servisa od strane korisničke aplikacije. Osim takvih jednostavnih
procesa mogu postojati složeniji procesi. Složeniji primjer procesa bi bila agregacija tj. ugnježñivanje
Web servisa gdje jedan Web servis koristi drugi koji koristi treći itd. Ovdje će biti izdvojena jedna vrsta
procesa koja je od izuzetne važnosti za arhitekturu Web servisa i koja uz poruke i opise čini treći
element arhitekture, a to je otkrivanje (eng. discovery).
Otkrivanje je proces pronalaženja Web servisa po odreñenom kriteriju. Obzirom da opis Web servisa
ima ulogu svojevrsne „osobne karte“ Web servisa, proces otkrivanja će zapravo podrazumijevati
pronalaženje opisa odgovarajućeg ili odgovarajućih Web servisa.
Do procesa otkrivanja dolazi kada korisnička aplikacija ima potrebu korištenja Web servisa odreñenog
tipa. Otkrivanjem se pronalazi odgovarajući Web servis koji se potom može koristiti kao pružatelj.
Može se postaviti pitanje, da li otkrivanje vrši korisnička aplikacija ili programer koji tu aplikaciju
kreira. Odgovor je oboje. Otkrivanje može biti „ručno“ tj. Web servis može otkriti sam programer, a
može biti i „samostalno“ tj. od strane same aplikacije koja vrši otkrivanje odgovarajućeg Web servisa.
Opis Web servisa o kojem je bilo riječi ranije i proces otkrivanja se u potpunosti nadopunjuju jer je
svrha opisa omogućiti otkrivanje i korištenje Web servisa. U proces otkrivanja programer ili sama
aplikacije zapravo „ulaze“ sa kriterijima o Web servisu koji traže tj. koji im je potreban. Pritom oni ne
znaju hoće li ili neće pronaći odgovarajući Web servis. U procesu otkrivanja se onda usporeñuju
kriteriji programera sa opisima ponuñenih Web servisa. Ako opis odreñenog Web servisa odgovara
kriterijima, taj Web servis se može koristiti kao pružatelj funkcionalnosti aplikaciji.
Postoje tri osnovna pristupa kako „utjeloviti“ tj. formalno izvesti proces otkrivanja Web servisa.
Otkrivanje putem središnjeg registra se vrši onda kada postoji središnji registar Web servisa koji
postoje na mreži. Da bi to funkcioniralo potrebno je prilikom kreiranja novog Web servisa tj. njegovog
opisa, u središnji registar dodati opis Web servisa. Potrebno je izravno registrirati novi Web servis u
registru. Primjer za ovakav način otkrivanja Web servisa je UDDI ili Microsoft DISCO.
Otkrivanje putem indeksa se vrši pretragom indeksa tj. popisa ili liste odreñenih Web servisa. Bilo tko
ima slobodu sastaviti vlastiti indeks tj. popis odreñenih Web servisa. U ovom slučaju ne postoji
15
registracija novih Web servisa jer je indeks samo pokazivač na lokaciju Web servisa, a ne sadrži
njihove opise kao registar. Primjer za ovakav način otkrivanja Web servisa je Google.
P2P otkrivanje je alternativa registarskom pristupu i omogućava meñusobno otkrivanje Web servisa.
Potrebno je da postoji mreža Web servisa koji „znaju“ jedni za druge. Kod traženja odgovarajućeg
Web servisa, jedan Web servis će od svojih susjeda za koje zna da postoje, zatražiti odgovarajući Web
servis. Taj upit će se dalje distribuirati kroz mrežu Web servisa dok se ne pronañe odgovarajući. Treba
uočiti da je moguće da Web servis interno ima sastavljen indeks drugih Web servisa što je onda
kombinacija s prethodnim načinom pretraživanja.
Nakon uspješnog procesa otkrivanja Web servisa, tražitelj će i Web servis će se „dogovoriti“ o načinu
komunikacije tj. o protokolu. Na taj način tražitelj postaje korisnik Web servisa.
Procesi čine treći bitni element arhitekture Web servisa koja je sada potpuna. Komunikacijsku
podlogu pruža protokol HTTP. Korisnik i pružatelj meñusobno razmjenjuju SOAP poruke. Pružatelj ima
svoj opis kojim omogućava da ga potencijalni korisnici pronañu u procesu otkrivanja. Sve zajedno je
bazirano na XML-u kao temeljnom načinu zapisivanja podataka.
Slika 1.15: Potpuni pregled elemenata arhitekture Web servisa
1.2.2 XML malo detaljnije
XML (Extensible Markup Language) je jezik za opis strukturiranih podataka tj. jezik za
kreiranje dokumenata koji sadrže strukturirane podatke. Pritom je istovremeno omogućeno zapisivanje
podataka i njihovog značenja. Struktura XML dokumenata se temelji na oznakama (eng. tag).
Specifikacija jezika XML definira načine kreiranja i korištenja oznaka.
16
XML dozvoljava autoru XML dokumenata da kreira vlastite oznake i upravo oznake
omogućavaju opis strukture dokumenata jer sadrže informacije o značenju podataka izmeñu oznaka.
Npr. u primjeru: <ime> Marko </ime>, <ime> je početna oznaka, Marko je podatak,
a </ime> je završna oznaka. Očito oznaka označava značenje podatka kojeg obuhvaća. Početna
oznaka i završna oznaka zajedno čine element.
Iako podsjeća na jezik HTML, jezik XML nikako nije naprednija verzija jezika HTML. Obzirom da se u
XML-u mogu kreirati oznake HTML-a, očito se u XML-u može kreirati potpuni HTML dokument što
znači da je jezik XML širi od jezika HTML.
XML dokumenti se mogu promatrati kroz dva osnovna svojstva. Prvo svojstvo je dobra
oblikovanost, a drugo svojstvo je valjanost.
Da bi XML dokument bio dobro oblikovan, on mora poštivati neka opća pravila koja vrijede za
sve XML dokumente. Ta pravila definira sam jezik XML. Npr. svaki element u XML dokumentu mora
imati početnu i završnu oznaku, XML dokument smije sadržavati samo jedan korijenski element, tj.
smije postojati samo jedan element čija početna i završna oznaka obuhvaćaju sve ostale elemente,
nazivi početnih i završnih oznaka moraju biti pisani ili malih ili velikim slovima i moraju se podudarati,
elementi se moraju pravilno ugnježñivati tj. ne smije biti preklapanja itd. Ta pravila mora poštivati
svaki XML dokument bez iznimke. Ukoliko ih poštuje tada je taj XML dokument dobro oblikovan.
Za pojašnjenje valjanosti XML dokumenta iskoristit će se primjer Web servisa s početka.
Pretpostavimo da postoji Web servis hotelskog lanca kao što je ranije opisano. I pretpostavimo da
postoji veliki broj Web aplikacija raznih turističkih agencija koje koriste taj Web servis. Kad smo ranije
opisivali razmjenu poruka izmeñu korisnika i pružatelja rekli smo da poruka sadrži sustavske
informacije i konkretne podatke koje korisnik (aplikacija) šalje Web servisu (pružatelju) ili obrnuto. Ti
konkretni podaci nisu ništa drugo nego XML dokumenti. Dakle korisnici i pružatelji razmjenjuju XML
dokumente.
Slijede dva primjera o svojstvu valjanosti XML dokumenta.
Pretpostavimo da Web servis ima definiran element koji opisuje rezervaciju na sljedeći način.
<rezervacija> (podaci o rezervaciji) </rezervacija>. Podaci o rezervaciji sadrže ime,
prezime, adresu i broj rezervacije. Kako Web servis zna da element rezervacija koji je poslala
aplikacija ima strukturu identičnu onoj koju koristi on sam? Kada se pojavi nova aplikacija koja želi
koristiti Web servis, kako ta aplikacija zna koje elemente koristi Web servis i koja je njihova struktura?
Pretpostavimo da postoji više hotela koji svi imaju svoje Web servise. Jedan hotel definira da
u njegovim XML dokumentima rezervacija mora sadržavati ime, prezime i adresu. Drugi hotel definira
da u njegovim XML dokumentima rezervacija mora sadržavati prezime i broj kreditne kartice. Kako
osigurati da aplikacije koje koriste te različite Web servise pravilno komuniciraju s njima tj. kako
osigurati da aplikacije tj. servisi razumiju XML dokumente koje razmjenjuju?
U svakom jasno definiranom okruženju (djelokrugu, komunikacijskom prostoru...) mora postojati
precizna definicija o tome koje tipove tj. elemente neki XML dokument smije sadržavati.
17
Npr. u okruženju izmeñu aplikacije A i servisa S1 mora postojati definicija da element rezervacija
sadrži elemente ime, prezime i adresu. U okruženju izmeñu iste aplikacije A i servisa S2 mora postojati
definicija da element rezervacija sadrži elemente prezime i broj kreditne kartice.
Document Type Definition
DTD je jedno od mogućih rješenja za navedene probleme. DTD je jezik za opis strukture XML
dokumenata. Dozvoljenu strukturu nekog XML dokumenta definira pripadna DTD datoteka.
DTD datoteka je mjesto na kojem će se definirati kakvu strukturu ima element rezervacija. Na
prethodnom primjeru to znači da u okruženju izmeñu aplikacije A i servisa S1 mora postojati DTD
datoteka u kojoj je definirano da element rezervacija sadrži elemente ime, prezime i adresu. U
okruženju izmeñu aplikacije A i servisa S2 mora postojati DTD datoteka u kojoj je definirano da
element rezervacija sadrži elemente prezime i broj kreditne kartice.
Što to znači da u okruženju izmeñu aplikacije i servisa postoji DTD datoteka? Tijekom svoje
komunikacije aplikacija i servis razmjenjuju XML dokumente. Na početku svakog XML dokumenta
mora biti navedena DTD datoteka na temelju koje je grañen XML dokument i obje strane moraju imati
pristup toj datoteci. I servis i aplikacija imaju pristup istoj DTD datoteci kojom provjeravaju da li je
primljeni XML dokument valjan u njihovom okruženju. To je značenje valjanosti XML dokumenta. XML
dokument je valjan ako odgovara pravilima iz zadane DTD datoteke.
Slika 1.16: Provjera valjanosti XML dokumenata
Unatoč svojim mogućnostima DTD tehnologija ima dosta ograničenja. U XML dokumentu ili skupini
XML dokumenata koji koriste odreñenu DTD datoteku, dozvoljeno je koristiti samo one elemente koji
su definirani u toj datoteci. Ako se DTD datoteka promatra kao rječnik dozvoljenih riječi onda je svaki
XML dokument koji se izgradi prema toj DTD datoteci ograničen na korištenje točno onih riječi koje su
definirane u toj DTD datoteci.
XML namespaces
Problem rječnika rješava tehnologija pod nazivom XML namespaces. XML namespace ili XML prostor
imena je jedinstveni rječnik elemenata identificiran jedinstvenim URI (Uniform Resource Identifier)
identifikatorom. To omogućava da se u istom XML dokumentu koriste različiti rječnici. Konkretno
omogućeno je da se npr. u istom XML dokumentu pojavi element rezervacija iz rječnika hotela A, te
element rezervacija iz rječnika hotela B. Ta dva elementa se razlikuju oznakom prostora imena kojem
pripadaju. To omogućava sam XML.
18
Slika 1.17: XML namespace primjena
Jasno je da tehnologije DTD i XML prostori imena ne mogu funkcionirati zajedno. Stoga se postavlja
pitanje kako održati funkcionalnost koju ostvaruje DTD i istovremeno imati mogućnost korištenja XML
prostora imena.
XML Schema
Odgovor na taj problem je XML Schema. XML Schema je tehnologija analogna DTD-u no mnogo
snažnijih i naprednijih mogućnosti. Kao što je kod primjene tehnologije DTD postojala DTD datoteka
koja je definirala dozvoljene elemente i strukturu XML dokumenata, kod primjere XML Scheme koristi
se XSD (XML Schema Definition) dokument koji sadrži analogne definicije no u naprednijem obliku.
XSD dokument se u XML dokument uključuje kao prostor imena na način opisan u prethodnom
primjeru.
Slika 1.18: Odnos DTD i XML Schema tehnologija kod validacije XML dokumenata
1.2.3 SOAP malo detaljnije
Do sada je spomenuto da korisnik i pružatelj meñusobno komuniciraju tako da razmjenjuju
poruke. Spomenuto je da je SOAP formalni tj. standardni način za ostvarivanje komunikacije
porukama. Jedna SOAP poruka se prenosi jednim HTTP paketom. Jedna SOAP poruka sadrži
konkretne podatke koje razmjenjuju korisnik i pružatelj. Rečeno je da ti podaci mogu npr. biti podaci o
osobi koja želi rezervirati sobu u hotelu, podaci o slobodnom smještaju itd. Drugim riječima, podaci
koje prenosi SOAP poruka su upravo ono zbog čega postoje dotični korisnik i pružatelj. Postoje da bi
19
ostvarili neku funkcionalnost i da osobi za računalom ponude neku uslugu. Dok osoba sjedi za
računalom i vrši svoju rezervaciju, stvaraju se SOAP poruke koje te podatke prenose do Web servisa
na drugoj strani, te naravno SOAP poruke kojima servis vraća broj uspješno provedene rezervacije.
Ukoliko se sve odvilo u redu naravno. Pritom je to sve potpuno skriveno od osobe koja pokreće i
koristi cijeli proces.
Strogo gledano SOAP nije protokol. SOAP je zapravo fleksibilna platforma tj. okruženje za razmjenu
XML poruka. SOAP specifikacija je prijedlog (eng. recommendation) organizacije W3C. Dakle nije
norma ni formalni standard. Sama riječ SOAP u najnovijoj varijanti nije akronim za zapravo ništa.
SOAP je jednostavno SOAP. U prošlosti je SOAP bio akronim za Simple Object Access Protocol, a
koristila se i varijanta Service Oriented Architecture Protocol.
Struktura SOAP poruke
Ranije je navedeno da SOAP poruka sadrži sustavski dio i dio s podacima. Ti dijelovi se
formalno zovu zaglavlje SOAP poruke (eng. header) i tijelo SOAP poruke (eng. body). Zaglavlje i tijelo
poruke su sadržani unutar omotnice SOAP poruke (eng. envelope).
Zaglavlje se ne mora obavezno koristiti no najčešće sadrži odreñene kontrolne informacije o tome
kako obraditi SOAP poruku, kako ju prosljeñivati itd. U realnim scenarijima je moguće da SOAP poruka
ne putuju isključivo od korisnika do pružatelja nego da na svom putu proñe više točaka koje se zovu
SOAP čvorovi. Upravo za tu namjenu postoji tzv. blok zaglavlja koji se nalazi u zaglavlju poruke i kojih
može biti više. Pojedini od tih blokova zaglavlja mogu biti namijenjeni odreñenim čvorovima na putu
poruke.
Tijelo SOAP poruke je obavezni dio svake SOAP poruke. Tijelo sadrži konkretne podatke koje prenosi
SOAP poruka od izvora gdje je stvorena, do odredišta.
Ranije je spomenuto da se podaci izmeñu korisnika i pružatelja razmjenjuju u XML obliku. Sama SOAP
poruka je takoñer u XML obliku tj. SOAP poruka je XML dokument. Omotnica SOAP poruke je očito
glavni tj. korijenski element SOAP poruke.
Slika 1.19: Opća struktura SOAP poruke
1.2.4 WSDL malo detaljnije
Što je uopće WSDL? WSDL (Web Services Description Language) je jezik za opisivanje Web
servisa baziran na XML-u. Na temelju jezika WSDL se generiraju WSDL dokumenti koji su očito XML
dokumenti.
Ranije je spomenuto da su Web servisi softverski sustavi. To znači da oni uvijek imaju nekakvo sučelje
putem kojeg omogućavaju korištenje svoje funkcionalnosti. Korisničke aplikacije koriste to sučelje i
20
stoga je WSDL dokumentom bitno opisati sučelje, a ne internu arhitekturu Web servisa. Što
podrazumijeva opis sučelja Web servisa? Podrazumijeva opis poruka na kojima se temelji
komunikacija, tipova podataka koji se razmjenjuju, operacija (metodama) koje Web servis pruža,
lokaciju na kojoj se nalazi Web servis itd.
WSDL opis će se kod kreiranja novog Web servisa npr. unijeti u centralnu bazu podataka Web servisa
(npr. UDDI) otkuda će potencijalni korisnici moći dohvatiti informacije o tom Web servisu, njegovoj
lokaciji itd.
WSDL opis sastoji se od nekoliko elemenata koji pojedinačno opisuju glavne elemente sučelja Web
servisa. Oni su navedeni u nastavku.
<portType>
Opisuje operacije koje svojim korisnicima pruža Web servis. Zbog toga je i najvažniji element WSDL
dokumenta. Može se usporediti sa razredom (klasom) u terminima objektno orijentiranih programskih
jezika. Kao što razred sadrži metode koje pruža svojim korisnicima, tako i ovaj element sadrži
operacije (metode) koje Web servis pruža svojim korisnicima.
<message>
Opisuje poruke koje se koriste tijekom korištenja neke operacije Web servisa. Sastoji se od proizvoljno
mnogo logičkih dijelova (eng. parts). Svaki logički dio poruke definira se imenom i tipom. Ovaj
element se može usporediti sa skupom ulaznih tj. izlaznih parametara kod pozivanja neke metode.
<types>
Opisuje tipove podataka koji se koriste tijekom korištenja operacija Web servisa. Tipovima se opisuju
dijelovi poruka. Može se usporediti sa ulaznim tj. izlaznim tipovima podataka kod korištenja metoda u
standardnim programskim jezicima.
<binding>
Prethodni elementi opisuju komunikaciju na apstraktan način, neovisno o konkretnim protokolima koji
će se koristiti za izvoñenje te komunikacije u stvarnosti. Ovaj element definira konkretni protokol i
povezuje prethodne apstraktne elemente na konkretne protokole, npr. SOAP.
Slika 1.21: Segment WSDL dokumenta
Treba naglasiti da se WSDL može smatrati „strojnim jezikom“ jer ga opise Web servisa u WSDL-u ne
pišu ljudi, jednako kao što ni proxy klase na temelju WSDL dokumenata ne pišu ljudi već za oboje
postoje aplikacije koje generiraju WSDL dokumente odnosno proxy klase.
1.3 Zašto je XML tako važan?
XML je do sada spomenut nekoliko puta. SOAP poruke koje meñusobno izmjenjuju Web
servisi i njihovi korisnici su u XML formatu. Konkretni podaci koji se prenose unutar SOAP poruka su
takoñer u XML formatu. WSDL dokumenti koji opisuju Web servise su XML dokumenti. XSD dokumenti
su XML dokumenti. Obzirom na sve to XML je ključna tehnologija za Web servise.
21
XML je glavni razlog za dva izuzetno bitna svojstva koja posjeduju Web servisi, a to su:
-platformska neovisnost tj. neovisnost o platformi i
-jezična neovisnost tj. neovisnost o programskom jeziku.
Neovisnost o platformi podrazumijeva neovisnost o operacijskom sustavu iznad kojeg se izvršava Web
servis ili korisnička aplikacija. Neovisnost o programskom jeziku podrazumijeva neovisnost o
razvojnom okruženju i programskom jeziku koji se koristi za razvoj Web servisa ili korisničke aplikacije.
Što zapravo znači neovisnost o platformi tj. operacijskom sustavu? Znači da je moguća baš bilo koja
kombinacija operacijskih sustava za funkcioniranje tehnologije Web servisa. Obzirom da se radi o dvije
strane koje komuniciraju, tj. o Web servisu i korisničkoj aplikaciji, neovisnost o platformi znači da se
softver Web servisa može nalaziti na bilo kojem operacijskom sustavu, te da ga pritom može koristiti
aplikacija s bilo kojeg drugog operacijskog sustava.
To je moguće upravo zbog XML-a. XML datoteka je u potpunosti neovisna o svojstvima pojedinih
operacijskih sustava i zbog toga je moguće prenošenje podataka u XML obliku izmeñu bilo koje dvije
platforme.
Slika 1.22: Neovisnost o platformi - jedna od mogućih kombinacija platformi
Drugo važno svojstvo Web servisa je neovisnost o programskom jeziku. To ponovo omogućava upravo
XML. XML datoteka je potpuno neovisna o pojedinom programskom jeziku što omogućava da bilo koji
programski jezik kreira XML datoteku. Isto tako bilo koji programski jezik može „čitati“ XML datoteku
koje je stvorio bilo koji drugi programski jezik.
Npr. Web servis pisan u programskom jeziku C# mogu koristiti aplikacije pisane u jezicima Java, Perl,
Python, PHP itd. Moguće su različite varijante.
22
Kombinacija neovisnosti o platformi i neovisnosti o programskom jeziku daje Web servisima veliki
potencijal.
Slika 1.23: Neovisnost o programskom jeziku - jedna od mogućih kombinacija jezika
Što u realnosti znači neovisnost o platformi i programskom jeziku?
Pretpostavimo da postoje razvijene složene aplikacije pisane u različitim programskim jezicima na
različitim platformama. Ukoliko bilo koja od tih aplikacija želi koristiti neki Web servis dostupan na
Webu sve što ta aplikacija mora imati je sposobnost rukovanja XML dokumentima. Velika većina
programskih jezika ima razvijenu podršku za rukovanje XML dokumentima. Aplikacija pritom može na
temelju WSDL opisa Web servisa, ( koji je opet XML dokument ! ) doznati sve bitne informacije o Web
servisu potrebne za njegovo korištenje.
Zbog svega navedenog, Web servisi imaju svojstvo XML centričnosti (XML centric).
1.4 Motivi i potencijali.
Primjena Web servisa nije isključivo u izgradnji novih Web servisa. Bilo koja postojeća
aplikacija se može pružiti na korištenje putem Weba kao Web servis. Dakle ako negdje postoji neka
složena aplikacija čiju funkcionalnost bi bilo vrlo skupo i dugotrajno programirati, ta aplikacija se može
kao Web servis ponuditi na korištenje drugim aplikacijama. Sve što je potrebno je ostvariti vezu
23
aplikacije na Web i programski ostvariti sučelje putem kojeg vanjski korisnici mogu koristiti tu
aplikaciju. To vodi do zaključka da Web servisi zapravo omogućavaju recikliranje softvera. To osobito
dolazi do izražaja kod aplikacija koje su bile izrazito ovisne o nekoj platformi i nisu mogle komunicirati
npr. s drugim operacijskim sustavima.
Slika 1.24: Recikliranje softvera uz pomoć Web servisa
Web servisi omogućavaju drugačiji način razvoja softvera. Izgradnja softvera temeljenog na
Web servisima sastoji se od korištenja postojećih Web servisa kao komponenti u aplikaciji. Time se
zapravo pojednostavljuje cijeli proces razvoja softvera jer nije potrebno svu funkcionalnost pisati
ispočetka. Funkcionalnost postoji na Webu i samo je treba iskoristiti. Očito se Web servisi mogu
promatrati kao objekti na Webu koji pružaju funkcionalnost. Ako neki Web servis postoji na Webu
znači da ga se može koristiti ponovo i ponovo. To je svojstvo ponovne iskoristivosti (eng. reusability).
Iako je prilično logično, treba naglasiti da i sami Web servisi mogu biti korisnici drugih Web servisa.
Time su mogućnosti praktički neograničene i mogu se graditi najrazličitije Web strukture.
Slika 1.25: Različite mogućnosti komunikacije aplikacija i Web servisa
Prednosti Web servisa na strani korisnika i na strani pružatelja:
Strana pružatelja
Strana korisnika
24
Standardizirani, platformski i jezično neovisni
pristup funkcionalnosti postojećeg softvera
Brži pristup do novog softvera
Pouzdaniji i otporniji softver
Skraćenje vremena
postojećeg softvera
razvoja
zbog
korištenja
Izbjegavanje iscrpnog testiranja softvera zbog
korištenja isprobanog postojećeg softvera
Smanjenje troškova razvoja
korištenja postojećeg softvera
softvera
zbog
Ubrzanje izlaska softvera na tržište
Jednostavno dodavanje nove funkcionalnosti
putem ugradnje postojećeg softvera
Uklanjanje platformske ovisnosti pretvaranjem
aplikacije u Web servis
Jedna
od
osobito
zanimljivih
primjena
Web servisa su vrlo
popularni Web portali.
Web portali objedinjuju
veliki
broj
različitih
usluga za koje se podaci
često
dobavljaju
sa
različitih strana. Web
servisi se u tom slučaju
nameću kao logično
rješenje na način da
svaki element portala
„iza sebe“ ima Web
servis, putem kojeg
izravno
dobavlja
podatke i objavljuje ih
na portalu bez potrebe
za posredovanjem.
Slika 1.26: Web servisi i portali
1.5 Pitanje sigurnosti
Unatoč tome što se Web servisi nameću kao vrlo prihvatljiva tehnologija, još uvijek su u
odreñenoj mjeri ograničeni pitanjem sigurnosti. Sigurnost danas znači sve pa to i nije sasvim
25
neobično. Kada se govori o sigurnosti Web servisa treba znati da to ne znači isključivo sigurnost
samog Web servisa nego i sigurnost aplikacije koja ga koristi te sigurnost komunikacije izmeñu njih.
Riješiti pitanje sigurnosti Web servisa, a pritom ne riješiti pitanje sigurnosti aplikacije koja ga koristi je
napola riješen tj. neriješen problem. Isto tako nije dovoljno riješiti pitanje sigurnosti aplikacije, a
pritom zanemariti sigurnost Web servisa kojeg aplikacija koristi.
Sigurnost Web servisa može se promatrati na više razina, a jedno od najčešćih pitanja je
pitanje povjerenja platforme. To pitanje se može ukratko opisati ovako: koliko je sigurno imati
aplikaciju na ekstremno skupom IBM/UNIX stroju koja koristi Web servis na Windows stroju kućne
izrade. To je naravno samo primjer no ilustrira problem platforme.
Uz sigurnosne mjere koje su već uobičajene u računalnim sustavima, ipak je potrebno
naglasiti neke mjere pri korištenju Web servisa. Neke od tih mjera su:
•
•
•
•
stroga autentikacija i provjera identiteta izmeñu aplikacija i Web servisa,
kontrola pristupa kojom se upravlja funkcionalnošću Web servisa koju aplikacije smiju koristiti
kontrola valjanosti podataka koji se prenose
osigurana enkripcija podataka putem dokazanih standarda (SSL, PKI...)
Sigurnost koja će biti primijenjena uvelike ovisi i o namjeni Web servisa i podacima koji će se
prenositi. Nije svejedno prenose li se podaci o trenutnoj vremenskoj prognozi ili podaci o bankovnoj
transakciji. Sigurnost nadalje ovisi o tome da li je Web servis javno dostupan za korištenje ili nije. Nije
svejedno da li je Web servis dostupan na korištenje bez posebnih ograničenja ili je namijenjen samo
ograničenom krugu korisnika.
Važan faktor je odabir Web servisa iz pouzdanog izvora tj. tvrtke. Sigurno nije svejedno odabrati
vlasnika Web servisa koji postoji na tržištu dugi niz godina i za kojeg se zna da ima razvijene
sigurnosne mjere, u odnosu na vlasnika Web servisa koji postoji tek nekoliko dana.
Sigurnost Web servisa se u velikoj mjeri oslanja na postojeće sigurnosne standarde koji se već koriste
i koji su dokazani u računalnim sustavima, npr. digitalni certifikat, digitalni potpis itd. Ipak nije
dovoljno osloniti se samo na postojeće sigurnosne mjere kao što je firewall nego sigurnost Web
servisa treba rješavati odvojeno.
Pitanje sigurnosti daleko nadilazi sadržaj ovog rada.
1.6 Organizacije i standardi
26
Web servisi nisu tehnologija u vlasništvu neke kompanije. Tehnologija Web servisa se temelji
na nizu otvorenih standarda koje razvijaju različite organizacije. Te organizacije svojim radom
okupljaju velik broj stručnjaka iz kompanija koje su posebno zainteresirane za Web tehnologije.
Vjerojatno najistaknutija organizacija je World Wide Web consortium ili kraće
W3C. W3C je meñunarodni konzorcij koji se bavi isključivo razvojem Web
standarda. W3C je 1994. godine osnovao Tim Berners Lee koji je ujedno i
kreator Weba kakvog poznamo danas. Od svog osnivanja do danas W3C je izdao
preko 90 standarda u obliku W3C prijedloga (eng. W3C recommendation).
W3C trenutno ima preko 400 članova meñu kojima su i najveće IT kompanije npr. AT&T, HP, IBM,
Microsoft, Google, Intel, Deutsche Telecom, Sun, Yahoo, te brojna sveučilišta. Slijedi popis nekih od
važnijih standarda vezanih za Web servise koje je izdao W3C.
•
•
•
•
•
•
•
•
SOAP Version 1.2 Part 0: Primer
SOAP Version 1.2 Part 1: Messaging Framework
SOAP Version 1.2 Part 2: Adjuncts
SOAP Message Transmission Optimization Mechanism
Web Services Addressing 1.0 - Core
Web Services Addressing 1.0 - SOAP Binding
Web Services Architecture
Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
OASIS je takoñer meñunarodni konzorcij koji se primarno bavi
razvoje e-bussines standarda. U okviru toga u velikoj mjeri se
bavi i tehnologijom Web servisa te takoñer nudi veliki broj
standarda koji su primarno orijentirani na bussines okruženja.
U nastavku slijedi popis nekih od važnijih standarda koje izdaje OASIS.
•
•
•
•
•
•
•
•
•
•
•
Universal Description, Discovery and Integration (UDDI) v3.0.2
Universal Business Language (UBL) v1.0
Universal Business Language Naming & Design Rules v1.0 (UBL NDR)
WS-Reliability (WS-R) v1.1
Web Services Resource Framework (WSRF) v1.2
Web Services for Remote Portlets (WSRP) v1.0
Web Services Security v1.0 (WS-Security 2004)
Web Services Security v1.1
Web Services Security SAML Token Profile v 1.0 and REL Token Profile v1.0
WSDM Management Using Web Services v1.0 (WSDM-MUWS)
WSDM Management Using Web Services v1.0 (WSDM-MOWS)
Slijedi prikaz aktualnih standarda vezanih za Web servise uz njihova važna svojstva.
27
Standard ili specifikacija
Kategorija
Svrha
Održava
Izvorna
godina
Izvorni
sponzori
Osnovni standardi
XML 1.0
Podaci
Opis i pohrana
podataka
W3C
1998
Izveden iz
jezika SGML
SOAP 1.2
Poruke
Razmjena poruka
W3C
2000
IBM i
Microsoft
Opisi
Opis Web servisa
W3C
2000
IBM,
Microsoft, i
Ariba
Oglašavanje i
objavljivanje
Objavljivanje Web OASIS
servisa
2000
IBM,
Microsoft, i
Ariba
Arhitektura
Arhitektura za opis W3C
glavnih
komponenti i
meñusobnih
odnosa
2002
Software AG,
IBM, Iona, i
BEA
WSDL 2.0
UDDI 3.0.2
Web Services
Architecture
Komunikacija i poruke
Poruke
Garantira
—
pouzdanu dostavu
HTTP paketa (koji
mogu sadržavati
SOAP poruke)
izmeñu klijenta i
servera.
2001
IBM
Poruke
Dodatak na SOAP IETF
koji omogućava
slanje binarnih
sadržaja bez
pretvaranja u XML
2002
IBM i
Microsoft
Reliable HTTP
(HTTPR)
Web Services
Attachments
Sigurnost
XML Signature
Syntax and
Processing
XML Key
Management
Specification
(XKMS)
Sigurnost
XML-bazirani
digitalni potpisi
W3C
2001
Motorola,
Citigroup, i
W3C
Sigurnost
XML-orijentiran
W3C
plan za integraciju
PKI tehnologije u
Internet
2001
VeriSign,
Microsoft, i
WebMethods
Sigurnost
Dodatak na SOAP
za očuvanje
integriteta,
povjerljivosti i
autentikacije
—
2002
Microsoft,
IBM, i
VeriSign
OASIS
2002
IBM,
Epicentric, i
Web Services
Security (WSSecurity)
Korisničko sučelje
Web Services
Korisničko
sučelje
Standardni skup
sučelja za PnP
28
Standard ili specifikacija
Kategorija
Održava
Izvorna
godina
integraciju Web
servisa u portale ili
interaktivne
aplikacije.
for Remote
Portlets (WSRP)
and
Web Services
for Interactive
Applications
(WSIA)
Web Services
Experience
Language (WSXL)
Svrha
Korisničko
sučelje
Model za
—
komercijalnu
distribuciju
interaktivnih Web
servisa i
sintetiziranje novih
Web servisa.
Izvorni
sponzori
WebCollage
2001
IBM
1.7 Korak dalje
Ipak nije sve tako jednostavno kao što se čini. Nije dovoljno napisati softver i objaviti Web
servis. Stvari postaju složenije kad se na Webu nañe veliki broj Web servisa koji nude najrazličitije
29
funkcionalnosti i ne razlikuju se samo po složenosti nego i po važnosti, razini potrebne sigurnosti itd.
Pitanja vezana za Web servise treba gledati organizirano po nekakvim smislenim područjima.
Jedno od tih područja pokriva sam proces kreiranja Web servisa i obuhvaća alate dostupne na tržištu
za izgradnju i razvoj Web servisa. Za razvoj Web servisa postoje vrlo snažni alati od kompanija koje su
ujedno i najistaknutije na području razvoja standarda Web servisa, npr. Microsoft Visual Studio .NET,
IBM Web Services ToolKit, Sun JavaEE itd.
Kada se na Webu nañe dostupan veliki broj Web servisa ili se na neki način želi sustavno nadzirati rad
Web servisa govori se o području upravljanja Web servisima (eng. Web services managment). Web
servi se može općenito nalaziti u dva stanja: aktivnom (dostupnom) i neaktivnom (nedostupnom).
Izmeñu ta dva stanja Web servis prelazi aktivacijom odnosno deaktivacijom. Što znači da je Web
servis aktivan (neaktivan). Znači da Web servis može (ne može) prihvaćati zahtjeve svojih korisnika.
Osim glavnih stanja dostupnosti i nedostupnosti, postoje i podstanja. Za vrijeme dok je dostupan,
Web servis može biti zauzet (eng. busy) ili u stanju pripravnosti (eng. idle). Za vrijeme dok je
nedostupan Web servis može biti zaustavljen (npr. administracijski razlozi), zasićen (zbog prevelikog
broja zahtjeva) i u stanju greške (zbog interne pogreške sustava i sl.). Osim upravljanja postoje još i
područje pružanja podrške Web servisima, integracija, posredovanje Web servisima itd.
Prije kreiranja Web servisa i bilo kakvih konkretnih odluka pružatelj tj. vlasnik Web servisa
mora voditi računa o različitim faktorima koji su navedeni u nastavku:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
odreñivanje cijena i pravila licenciranja korisnika Web servisa
garancija dostupnosti, performansi i skalabilnosti Web servisa
pravila održavanja koja odreñuju što se dešava u slučaju problema bilo kojeg tipa
zaštita od odgovornosti u slučaju manipulacije, prijevare i neovlaštenog korištenja podataka
od strane korisnika Web servisa
mehanizmi testiranja
odabir platforme
garancije i pravila privatnosti
sigurnosne mjere
balansiranje opterećenja
scenariji oporavka u slučaju razrušenja sustava
rješenja za pitanja intelektualnog vlasništva
pitanje oglašavanja, da li vlasnik Web servisa može reći tko koristi njegov Web servis
upravljanje Web servisom što uključuje upravljanje problemima, performansama i mrežom
nadziranje korištenja Web servisa
Arhitektura zasnovana na servisima - Service Oriented Architecture SOA
Servis, odnosno Web servis je osnovni element SOA arhitekture. Po OASIS definiciji SOA je
način organiziranja i korištenja raspodijeljenih funkcionalnosti koje mogu biti pod nadzorom različitih
vlasnika. SOA nudi jedinstveni način za ponudu, otkrivanje, komunikaciju i korištenje funkcionalnosti
za ostvarenje željenih ciljeva.
Ono što se promatra u SOA arhitekturi je jedino funkcionalnost tj. usluga koju servis pruža. Detalji
implementacije nisu važni. Bitni principi razvoja, održavanja i korištenja SOA sustava su identifikacija i
kategorizacija servisa, nadziranje i upravljanje servisima, isporuka servisa, modularnost, usklañenost
sa standardima itd.
30
Slika 1.27: Servis kao osnovna grañevna jedinka SOA arhitekture
Ako se stvari gledaju na razini servisa tj. funkcionalnosti koju oni pružaju omogućeno je da se
poslovni procesi modeliraju mnogo jednostavnije tj. isključivo pomoću usluga i neovisno o nižim
detaljima. Nije potrebno misliti o tehničkim detaljima, kompatibilnosti, komunikaciji itd već je dovoljno
„slagati“ blokove prema njihovoj funkcionalnosti, a sve ovisno o tome kakva se aplikacija gradi. Treba
naglasiti da servis kao osnovni grañevni element SOA arhitekture ne podrazumijeva Web servis. Web
servisi su samo jedan način implementacije servisa tj. usluga.
31
2. Razvoj Web servisa u .NET okruženju
2.1 Što je .NET ?
Razvojem Interneta i internetskih tehnologija došlo je i do razvoja softvera temeljenog na
komponentama. Softverske komponente su, jednostavno rečeno, elementi softverskog sustava
izgrañeni u skladu s odreñenim specifikacijama, koji nude odreñenu uslugu softverskom sustavu i
mogu komunicirati s drugim komponentama u softverskom sustavu. Objekti su jedan oblik softverskih
komponenti.
Razvoj Interneta je potisnuo funkciju računala kao stroja koji radi sam za sebe i nametnuo novu
funkciju računala, a to je računalo kao dio mreže tj. većeg raspodijeljenog sustava velikog broja
umreženih računala. Računalo je dakle postalo dio veće mreže i time dobilo mogućnost komunikacije s
drugim računalima u mreži. Na isti način je i softver koji se nalazi na odreñenom računalu postao dio
mreže, a obzirom da softver čine komponente, i one su postale dio mreže.
Internet je na taj način unio dvije nove i osnovne funkcije softvera tj. softverskih komponenti. S jedne
strane softver na jednom računalu je dobio mogućnost koristiti komponente na nekom drugom
računalu u mreži, dok je s druge strane softverska komponenta na nekom računalu pružala
mogućnost da ju se iskoristi kao element nekog softverskog sustava. Stoga je pod sve većim
utjecajem Interneta i programiranje temeljeno na komponentama počelo koristiti udaljene (eng.
remote) tj. nelokalne softverske komponente.
Kako bi se iskoristila mogućnost korištenja udaljenih komponenti u softverskim sustavima razvijen je
velik broj različitih komunikacijskih modela. Dva možda najpoznatija su Microsoftov DCOM
(Distributed Component Object Model) i OMGova CORBA (Common Object Request Broker
Architecture). Problem tih i drugih komunikacijskih modela je u specifičnim i različitim načinima na
kojima oni ostvaruju komunikaciju putem Interneta. To se konkretno odnosi na mrežne protokole i
mrežne portove koje DCOM i CORBA koriste u svojem radu. DCOM se zasniva na korištenju RPC
tehnologije, dok CORBA koristi protokol IIOP. Oba protokola koriste različite mrežne portove što je
jedan od glavnih nedostataka. Obzirom na stanje sigurnosti na Internetu praktično svaki računalni
sustav koji pristupa Internetu ima vlastite zaštite kojima onemogućava svaku komunikaciju putem
nestandardnih mrežnih portova što obuhvaća i portove koje koriste različiti komunikacijski modeli, a
meñu njima DCOM i CORBA.
Dakle jedan od glavnih problema razvoja softvera u raspodijeljenom okruženju je upravo velik broj
različitih komunikacijskih modela i njihova nekompatibilnost. Tom problemu se pridružuje dobro
poznati problem nekompatibilnosti platformi (Windows, Unix...) i nekompatibilnosti programskih
jezika. Cijelu priču dodatno pogoršava činjenica da sve snažnijim razvojem Interneta aplikacije teže
„životu na mreži“ za razliku od starog modela aplikacije koja se izvršava na samostalnom računalu
odvojena od ostatka svijeta.
.NET je Microsoftova strategija koja pokušava dati odgovor na te probleme. Web servisi su
ključan element te strategije jer upravo oni daju odgovor na sve gore navedene probleme. Treba
naglasiti da Web servisi nisu vlasništvo ili patent Microsofta. Web servisi su otvorena tehnologija koja
je upravo zbog svojih dobrih svojstava dobila ključnu ulogu u .NET strategiji.
Iz prethodnog poglavlja bi trebalo biti sasvim jasno zbog čega Web servisi daju odgovor na navedene
probleme. Web servisi se u svojem radu u potpunosti oslanjaju na komunikaciju putem mrežnog
protokola HTTP koji za svoj rad koristi standardni port 80. Port 80 je standardni WWW port te stoga
nije onemogućen zaštitama računalnih sustava. Kao što Web stranice prolaze kroz zaštite i dolaze do
korisnikovog preglednika koristeći protokol HTTP, tako i Web servisi putem protokola HTTP
komuniciraju sa svojim korisnicima tj. aplikacijama koje ih koriste.
U prvom poglavlju je objašnjeno kako jedan HTTP paket sadrži jednu SOAP poruku koja pak sadržava
podatke koje razmjenjuju Web servis i korisnička aplikacija. Ti podaci kao i sama SOAP poruka su u
32
XML obliku što je zapravo obični tekst. Obzirom na univerzalnost XML-a pokazano je kako na taj način
Web servisi rješavaju i problem platformske i jezične nekompatibilnosti. Zbog značaja XML-a često se
pojavljuje naziv XML Web servisi.
.NET se stoga u potpunosti oslanja na razvoj aplikacija koje „žive na mreži“, koje pritom koriste usluge
drugih aplikacija na mreži, a ujedno i same pružaju mogućnost da budu iskorištene od nekih drugih
aplikacija na mreži, tj. pružaju svoju uslugu. U svemu tome Web servisi su ključna tehnologija jer je
upravo Web servis rješenje kojim će .NET aplikacija ponuditi svoju funkcionalnost drugoj aplikaciji.
Obzirom da se u potpunosti oslanja na Web servise, to znači da se .NET zapravo oslanja na korištenje
protokola HTTP tj. jezika XML za komunikaciju što mu daje velike mogućnosti u pogledu komunikacije
s različitim platformama i jezicima.
Zaviri li se u budućnost, moguće je svaku aplikaciju promatrati kao komadić funkcionalnosti tj. uslugu
na Webu koja se pruža na korištenje drugim aplikacijama. Na taj način Web postaje platforma za
razvoj aplikacija baziranih na uslugama. Danas još uvijek aplikacije koriste usluge operacijskog
sustava nad kojim se izvršavaju, no logično je za očekivati da će u budućnosti aplikacije biti u
potpunosti orijentirane prema Webu i koristiti usluge dostupne na Webu. Web na taj način postaje
platforma za pružanje usluga. Na tom putu leži SOA (Service Oriented Architecture) o kojoj je bilo
govora u prvom poglavlju i koja nadilazi sadržaj ovog rada.
Jedna od bitnih karakteristika .NET-a je potpuna transparentnost komunikacije izmeñu aplikacija
meñusobno udaljenih na mreži. To znači da .NET skriva sve detalje oko toga kako se ustvari odvija
komunikacija izmeñu Web servisa i aplikacije koja ga koristi. To omogućava vrlo lagan i brz razvoj
aplikacija temeljenih na Web servisima jer se prilikom razvoja aplikacije udaljeni Web servis koristi
jednako kao i usluga koja se nalazi na lokalnom računalu !
.NET Web servis može koristiti aplikacija s bilo koje druge platforme. Isto tako .NET aplikacija može
koristiti Web servis koji se nalazi na bilo kojoj platformi. Specifičnost .NET strategije je to da je za
izvoñenje .NET Web servisa i aplikacija potreban isključivo Windows operacijski sustav.
Slika 2.1: Microsoft .NET na Webu
Treba naglasiti da je „.NET“ samo strategija. Da bi se na računalu (Windows) omogućilo izvoñenje i
razvoj .NET aplikacija potrebno je instalirati softversku platformu koja omogućava upravo to, a ta
platforma se naziva .NET Framework i trenutno je u verziji 2.0. O samom .NET Frameworku će više
govora biti malo kasnije.
33
.NET strategija se može promatrati kroz nekoliko razina proizvoda i usluga koje pruža Microsoft.
.NET razvojni alati i jezici
Glavni, a ujedno i najnapredniji .NET razvojni alat je Microsoft Visual Studio .NET koji se
trenutno nalazi u verziji 2005. Osim velike podrške profesionalnom razvoju .NET aplikacija važno
svojstvo Visual Studia .NET je da omogućava izuzetno jednostavan, a time i brz razvoj .NET aplikacija
čak i programeru početniku. Ipak za razvoj .NET aplikacija nije potreban isključivo Visual Studio .NET
jer postoji i besplatna varijanta koja takoñer omogućava razvoj .NET aplikacija, a koja dolazi u obliku
.NET Framework SDK (Software Development Kit) paketa. Razumljivo je da je i u slučaju Visual Studia
.NET ili .NET Framework SDK paketa osnovna stvar već spomenuti .NET Framework koji je prvi i
osnovni preduvjet za razvoj i izvoñenje .NET aplikacija.
.NET tj. .NET Framework omogućava razvoj aplikacija u velikom broju različitih programskih
jezika. Neki od tih jezika su Visual C# .NET, Visual Basic .NET, Visual C++ .NET itd. Neki od skriptnih
jezika su VBScript, JScript .NET itd.
.NET serveri
.NET serveri meñu ostalim pružaju potpunu podršku za udomljavanje (hosting) Web servisa i
zapravo postaju izlazna točka .NET Web servisa prema korisnicima na Webu.
Microsoftovi Web servisi
Osim što svojim alatima pruža podršku razvoju Web servisa, Microsoft i sam razvija vlastite
Web servise koji se mogu koristiti u novim aplikacijama. Neki od tih Web servisa su:
MSN Search koji omogućava aplikacijama da pretražuju Internet korištenjem MSN Search pretraživača,
MetaWeblogApi i MSN Space koji omogućavaju ureñivanje i objavljivanje blogova, Virtual Earth Map i
TerraService koji pružaju usluge kartografskih servisa, itd.
Smart ureñaji
Što su uopće smart ureñaji? To su desktop računala, notebook računala, dlanovna računala,
Tablet računala, mobilni telefoni i drugi mobilni ureñaji, ugrañeni (eng. embedded) ureñaji itd. Zovu
se smart ureñajima jer imaju sposobnost pristupati i koristiti informacije i usluge na mreži neovisno o
tome gdje se korisnik nalazi i kakav ureñaj ima. Usluge koje koriste smart ureñaji su upravo Web
servisi i ideja smart ureñaja će u potpunosti biti ostvarena tek u budućnosti kada Web postane
platforma puna usluga (Web servisa) te kada ugrañeni (eng. embedded) smart ureñaji u potpunosti
uñu u svakodnevni život. Potpuna integracija smart ureñaja zapravo znači da je npr. svaki kućanski
aparat, računalo, PDA, mobitel, igraća konzola itd., ustvari jedan smart ureñaj koji je umrežen s
drugim smart ureñajima i koji pristupa Webu i pritom koristi dostupne usluge. Mogućnosti primjene
smart ureñaja su zaista beskonačne i kao što je spomenuto ranije za Web servise, jedini problem je
osmisliti dovoljno inovativno rješenje.
Za podršku smart ureñajima Microsoft razvija specijalne ugrañene (eng. embedded)
operacijske sustave. Windows Embedded familija proizvoda se trenutno sastoji od dva glavna sustava:
Windows CE koji je trenutno u verziji 5.0, te Windows XP Embedded.
Windows CE ponajprije služi na uporabu na PDA, medicinskim i industrijskim ureñajima te
potrošačkoj elektronici kao što su CD playeri, digitalne kamere, DVD playeri itd.
Windows XP Embedded služi ponajprije za uporabu na POS (Point of Service) terminalima,
thin client ureñajima (računala koja najveći dio procesiranja obavljaju na središnjem poslužitelju,
najčešće bez tvrdog diska) te naprednim STB (Set-Top Box) ureñajima (ureñaji koji omogućavaju da
standardni TV ureñaj postane sučelje prema Internetu, te da prima i dekodira digitalne DTV signale).
34
Ranije je spomenuto kako je .NET strategija te da je prvi i osnovni preduvjet za razvoj ili
izvoñenje .NET aplikacija upravo .NET Framework. Može se reći da je .NET Framework temeljni
„vidljivi“ dio .NET strategije. U nastavku će se ukratko opisati .NET Framework, njegovi glavni dijelovi i
glavne funkcije.
Glavni dijelovi .NET Frameworka su:
1.) .NET Framework Common Language Runtime – CLR
2.) .NET Framework Base Class Library – BCL
CLR – Common Language Runtime
CLR se potpuno opravdano može nazvati srcem .NET Frameworka. CLR je run-time okruženje
za izvoñenje .NET aplikacija i ostvaruje njihovu vezu s operacijskim sustavom. Prevoñenje .NET kôda
se vrši u dva koraka. U prvom koraku se izvorni kôd prevodi u prenosivi CIL (Common Intermediate
Language) oblik. U drugom koraku CLR prevodi kôd u CIL-u u strojni jezik računala na kojem se
nalazi. Prevoñenje CIL-a u strojni kod računala naziva se JIT (Just In Time) prevoñenje. .NET
omogućava programiranje u bilo kojem jeziku uz preduvjet da za taj jezik postoji prevodioc (eng.
compiler) koji radi na temelju CLS (Common Language Specification) specifikacije. Takav prevodioc
prevodi izvorni kôd u CIL oblik kojeg dalje preuzima CLR. Danas postoji .NET podrška za velik broj
programskih jezika.
Treba spomenuti i ostale važne funkcije CLR-a kao što su: provjera sigurnosti, čišćenje smeća
(eng. garbage collection), pružanje zajedničkih tipova podataka svih .NET jezicima, obrada iznimki
(eng. exception handling) itd.
BCL – Base Class Library
BCL je biblioteka razreda (eng. class) dostupnih u sklopu .NET Frameworka. Biblioteka se
sastoji od vrlo velikog broja razreda koji u potpunosti stoje na raspolaganju programeru. Razredi su
grupirani u prostore imena (eng. namespace) i omogućavaju pristup i upravljanje svim bitnim
dijelovima računalnog sustava. Postoje prostori imena za upravljanje podacima, upravljanje
datotekama, izgradnju korisničkih sučelja, višedretveno programiranje, sigurnost, XML/SOAP
programiranje itd. Razredi za upravljanje podacima grupiraju se u ADO.NET skupinu. Razredi za razvoj
Web aplikacija grupiraju se u ASP.NET skupinu.
Slika 2.2: Microsoft.NET Framework
Slika 2.3: Prevoñenje .NET kôda
Više detalja o .NET Frameworku može se pronaći na http://msdn.microsoft.com/netframework/
35
2.2 Softverski preduvjeti
Opis softvera potrebnog za razvoj i pokretanje Web servisa:
1.)
IIS – Internet Information Services (trenutno u verziji 6.0)
Microsoftov Web server koji u interakciji s ASP.NET procesom na računalu omogućava razvoj,
izvršavanje i posluživanje Web servisa. IIS je potrebno instalirati na računalu čak i ako to
računalo služi samo za razvoj Web servisa, a ne i njihovo udomljavanje (hosting) ! Takoñer
IIS je zbog uočenih problema potrebno instalirati prije .NET Frameworka ! Potrebno je
provjeriti da li je IIS instaliran na računalu, te ako nije instalirati ga. IIS se instalira kao
Windows komponenta na sljedeći način:
Start / Control Panel / Add or Remove Programs / Add Remove Windows Components
2.)
.NET Framework (trenutno u verziji 2.0, 3.0 beta)
Temeljni preduvjet za razvoj i izvršavanje bilo koje .NET aplikacije. .NET Framework moguće
je preuzeti s Microsoftovog Web sjedišta. http://msdn.microsoft.com/netframework/
3.)
Visual Studio .NET (trenutno u verziji 2005)
Microsoftovo vizualno razvojno okruženje za razvoj .NET aplikacija. VS.NET je dostupan
studentima u sklopu MSDNAA (MSDN Academic Aliance) programa. Prije instalacije VS.NET
potrebno je sa računala deinstalirati sve eventualno instalirane beta verzije Visual Studia .NET,
.NET Frameworka ili Microsoft SQL Servera.
Virtualni direktoriji
Virtualni direktorij je običan fizički direktorij na disku računala, no ono što ga čini virtualnim je
mogućnost da mu se pristupa putem Weba tj. URL adrese. Npr. fizička adresa nekog direktorija može
biti C:\webservisi\mojservis\, dok virtualna adresa (URL) tog istog direktorija može glasiti
http://NazivRačunalaNaMreži/mojservis/ . U oba slučaja pristupa se istom direktoriju, dakle istim
datotekama, no fizička adresa se koristi kod pristupanja direktoriju s lokalnog računala na kojem se on
nalazi, dok se URL adresa koristi kod pristupanja tom direktoriju putem Weba. Dakle taj virtualni
direktorij je dostupan na Webu.
Zbog toga je logično upravo u takav direktorij smjestiti Web servis tj. datoteke koje čine Web
servis. Detalji o datotekama koje čine Web servis ovdje nisu bitni i o njima će više govora biti malo
kasnije.
No nije svaki fizički direktorij na računalu ujedno i virtualni direktorij. To jest da bi se neki
fizički direktorij učinilo dostupnim na Webu potrebno je učiniti ga virtualnim. To je zadatak IIS-a.
Virtualni direktorij stvara se tako da se prvo kreira fizički direktorij negdje na disku računala.
Zatim se pokrene IIS (Control panel / Administrative tools) te se odabere Local computer / Web sites.
Nakog toga se desnim klikom na Default Web site otvara izbornik u kojem se odabire opcija New /
Virtual Directory. Nakon toga slijedi niz prozora u kojem se odabire alias za fizički direktorij u njegovoj
URL adresi te dozvole pristupa. U svrhu primjera koji slijedi u nastavku otvoren je fizički direktorij
E:\FER\WebServis, zadan mu je alias WebServis što znači da je URL tog direktorija
http://localhost/WebServis .
Tijekom instalacije Visual Studio .NET paketa može doći do poteškoća ukoliko nije instaliran IIS ili iz
nekog drugog sličnog razloga. Takve probleme može se pokušati riješiti na sljedeći način: Start / Run ,
te pokretanjem naredbe (za .NET Framework 2.0) :
C:\WINDOWS\microsoft.net\framework\v2.0.50727\aspnet_regiis
Ovisno o verziji .NET Frameworka staza se može razlikovati te o tome treba voditi računa.
Sve probleme kod kojih postoji neka vrsta poruke o pogrešci, koju dojavljuje neki od alata, može se
pokušati riješiti na način da se tekst poruke o pogrešci (ili njegov opći dio) kopira u neki od
pretraživača (npr. http://www.google.com) ili u http://support.microsoft.com/search .
36
2.3 Visual Studio .NET - izgradnja i korištenje Web servisa
U ovom poglavlju obrañena je izgradnja i korištenje Web servisa primjenom razvojne okoline
Visual Studio 2005. Pretpostavlja se instalirani IIS, .NET Framework te Visual Studio 2005. Takoñer se
pretpostavlja poznavanje osnova programskog jezika C# (klase, metode, atributi, prostori imena,
code-behind...). Prije početka izrade Web servisa preporučljivo je kreirati virtualni direktorij za
smještaj datoteka Web servisa.
2.3.1 Izgradnja Web servisa
Pokretanje novog projekta – stvaranje novog Web servisa
Nakon pokretanja Visual Studio .NET okruženja, odabiru se naredbe File / New / Web site ,
te se dobiva prozor za odabir vrste Web projekta u kojem se odabire ASP.NET Web service, željeni
programski jezik (u ovom slučaju C#) te pripremljeni virtualni direktorij na računalu.
U prikazanom slučaju odabran je pristup putem URL-a željenom direktoriju te je odabran virtualni
direktorij o kojem je bilo govora u prethodnom poglavlju. Nakon pritiska na OK, Visual Studio u
odabranom virtualnom direktoriju stvara datoteke koje čine Web servis.
37
Sadržaj virtualnog direktorija i glavne datoteke
Sadržaj virtualnog direktorija može se jednostavno vidjeti iz Solution explorera na radnoj površini.
Na slici je vidljivo da je kreiran novi Visual Studio Solution te unutar njega novi Project te da je naziv
tog Projecta upravo URL našeg virtualnog direktorija. Tim URL-om se virtualnom direktoriju može
pristupiti i iz Web preglednika.
Datoteke Service.asmx i Service.cs su glavne datoteke Web servisa. Service.asmx datoteka je
datoteka
kojom
će
se
pozivati
Web
servis
tj.
URL
Web
servisa
će
biti
http://localhost/WebServis/Service.asmx . Ona sadrži informaciju o programskom jeziku u kojem je
pisan Web servis, o lokaciji te nazivu klase Web servisa. .asmx je ekstenzija specifična isključivo za
.NET Web servise.
Service.cs datoteka sadrži programski kôd Web servisa. Naziv .cs datoteke u načelu odgovara nazivu
klase Web servisa stoga je Service naziv klase Web servisa.
Obzirom da je Visual Studio automatski kreirao datoteke Service.asmx i Service.cs znači da je
primijenjen code-behind način organizacije programskog kôda pri kojemu se „čisti“ C# programski kôd
pohranjuje u datoteke s ekstenzijom .cs, dok se ostale informacije o Web servisu pohranjuju u
datoteku s ekstenzijom .asmx. Kada se ne primjenjuje code-behind organizacija programskog kôda,
onda se specijalne informacije o Web servisu pohranjuju zajedno s programskim kôdom Web servisa u
.asmx datoteku.
Nazive .asmx i .cs datoteka moguće je prilagoditi vlastitim željama. U tu svrhu se pomoću Solution
explorera mogu preimenovati datoteke Service.asmx i Service.cs u HotelskiServis.asmx i
HotelskiServis.cs. Takoñer je potrebno u datoteci HotelskiServis.asmx učiniti potrebne preinake
obzirom. Nakon prilagodbi situaciju u Solution exploreru te .asmx datoteci izgleda kao na slikama.
38
Primjer Web servisa
U datoteci HotelskiServis.cs nalazi se početni C# kôd koji je automatski generirao Visual Studio nakon
kreiranja novog projekta. Umjesto tog kôda ovdje će se analizirati sadržaj datoteke HotelskiServis.cs
na primjeru jednog jednostavnog Web servisa. Funkcionalnost tog servisa je bazirana na primjeru
hotelskog lanca iz prvog poglavlja.
using System;
using System.Web;
using System.Web.Services;
[WebService(Name = "Web servis hotelskog lanca",
Namespace = "http://HoteliAvalon")]
public class HotelskiServis : WebService
{
public
public
public
public
int
int
int
int
SlobodneJednokrevetne = 13;
SlobodneDvokrevetne = 17;
SlobodneTrokrevetne = 10;
OsnovnaCijena = 145;
[WebMethod]
public int BrojSlobodnihSoba(int BrojKreveta) {
if (BrojKreveta==1) return this.SlobodneJednokrevetne;
if (BrojKreveta==2) return this.SlobodneDvokrevetne;
if (BrojKreveta==3) return this.SlobodneTrokrevetne;
return -1;
}
[WebMethod]
public int CijenaSobe(int BrojKreveta, int BrojDanaBoravka)
{
return BrojKreveta * BrojDanaBoravka * this.OsnovnaCijena;
}
}
Uočljivo je da je definirana klasa Web servisa naziva HotelskiServis, te da ona sadrži dvije članske
metode (BrojSlobodnihSoba i CijenaSobe) te četiri varijable. Programski kôd se u najvećem
dijelu ne razlikuje od programskog kôda bilo koje .NET aplikacije, stoga će u nastaviti biti detaljnije
opisani upravo oni dijelovi koji su su specifični upravo za Web servise.
Možda najvažnija specifičnost kôda Web servisa u odnosu na kôd drugih .NET aplikacija je korištenje
WebMethod atributa. Dodavanjem tog atributa pojedinoj metodi, ta metoda postaje Web metoda tj.
metoda dostupna na Webu. U prvom poglavlju je spomenut pojam javno dostupnih metoda koje se
mogu pozivati od strane korisničkih aplikacija i Web metode su upravo te javno dostupne metode.
Pojednostavljeno rečeno: ukoliko želimo neku metodu dati na korištenje korisničkim aplikacijama tada
ćemo joj dodijeliti WebMethod atribut. Metode koje nemaju WebMethod atribut nisu Web metode.
WebMethod atribut meñu ostalim omogućava da se za svaku Web metodu definira njezino ime i opis.
[WebMethod (MessageName ="IzračunCijene",
Description="Metoda za izračun cijene")]
Sljedeća specifičnost je WebService atribut koji se dodjeljuje klasi Web servisa. Taj atribut nije
obavezan no vrlo je koristan te se njegovo korištenje svakako preporuča. Web service atribut
omogućava da se za Web servis definira: naziv, opis i XML namespace (prostor imena) Web servisa.
XML namespace ne treba miješati sa .NET namespaceom. Koncept XML namespacea je objašnjen u
poglavlju 1.2.2. Defaultni XML namespace za Web servise je http://tempuri.org i potrebno ga je
obavezno promijeniti prije objavljivanja Web servisa na Web. XML namespace ovog Web servisa je
http://HoteliAvalon .
39
Posljednja specifičnost koju je potrebno spomenuti je da klasa HotelskiLanac naslijeñuje klasu
WebService. To nasljeñivanje nije obavezno no donosi mogućnost korištenja objekata kao što su:
Session, Application, User itd. koji su inače specifični za Web aplikacije.
Funkcionalnost razreda je izuzetno pojednostavljena i u realnoj situaciji bi programska logika za
dohvaćanje slobodnih soba i izračuna cijene boravka bila znatno složenija. Prethodni primjer Web
servisa je na sljedećoj slici stavljen u realnu situaciju na Webu. Posebno je naglašen odnos izmeñu
Web metoda i lokalnih metoda (njih nema u primjeru) koje nema WebMethod atribut.
Slika 2.4: Web metode Web servisa hotelskog lanca
Može se sa sigurnošću reći da Web metode predstavljaju smisao Web servisa jer je smisao
Web servisa u funkcionalnosti dostupnoj sa Weba. Web metode su dostupne s Weba jer ih mogu
pozivati korisničke aplikacije. S druge strane metode nisu ništa drugo nego funkcije što jasno indicira
funkcionalnost. Cijelo „čudo“ Web servisa je upravo u toj povezanosti Weba sa komadićima
funkcionalnosti, a to ostvaruju Web metode.
Ono što daje poseban značaj cijeloj priči oko komadića funkcionalnosti dostupnih s Weba
je činjenica da ta funkcionalnost može biti bilo što ako se može opisati programskim
jezikom ! Jedini problem je biti dovoljno inovativan !
Slika 2.5: Web metode kao komadići funkcionalnosti dostupni na Webu
40
Prevoñenje i testiranje Web servisa
Prevoñenje Web servisa vrši se odabirom naredbi Build / Build Web Site. Nakon prevoñenja,
projekt se može „pokrenuti“ odabirom naredbi Debug / Start Debugging. Nakon što se prvi puta
odaberu navedene naredbe prikazat će se sljedeći prozor.
Web.config je konfiguracijska datoteka ASP.NET aplikacija koju Visual Studio 2005 ne stvara
automatski za razliku od svog prethodnika. Obzirom da je korisno tijekom razvoja aplikacije imati
mogućnost debugiranja odabire se prva opcija nakon čega se u virtualnom direktoriju stvara
web.config datoteka s odgovarajućim postavkama.
Web.config je XML datoteka koja pruža
snažne konfiguracijske mogućnosti ASP.NET
aplikacijama. Više govora o web.config
datoteci će biti u poglavlju o sigurnosti Web
servisa.
Osim stvaranja Web.config datoteke u Web pregledniku se otvara URL Web servisa, u ovom slučaju
http://localhost/WebServis/HotelskiServis.asmx te se dobiva automatski generirana stranica sa
popisom svih dostupnih Web metoda te osnovnim podacima o Web servisu (ukoliko su definirani
WebService atributom).
41
Ovakav prikaz Web servisa u Web pregledniku omogućava ASP.NET u svrhu jednostavnog testiranja
ispravnosti rada Web metoda. Podrazumijeva se da popis metoda sadrži samo Web metode, a to su
upravo metode koje su u ranije prikazanom kôdu označene WebMethod atributom. Klikom na neku od
tih metoda dobiva se jednostavni formular koji omogućava programeru da unosom argumenata testira
funkcioniranje metoda !
Unosom željenih vrijednosti argumenata metode i klikom na Invoke dobiva se rezultat izvoñenja
metode ! U ovom slučaju unesen je BrojKreveta = 3 te BrojDanaBoravka = 7.
Općenito postoje tri moguća načina pozivanja Web metode. Pod pozivanjem se podrazumijeva slanje
jednog HTTP paketa, koji sadrži naziv metode i argumente, Web servisu. Razlika izmeñu ta 3 načina je
upravo u sadržaju HTTP paketa.
Temeljni i najčešći način je upravo slanje SOAP poruke jer je SOAP temeljni protokol Web servisa.
Osim slanja SOAP poruke metode se mogu pozivati primjenom HTTP GET i HTTP POST metoda. Način
prikazan gore tj. način koji ASP.NET koristi za testiranje Web servisa je upravo HTTP POST. Može se
postaviti pitanje: zbog čega bismo htjeli koristiti bilo koju drugu metodu osim slanja SOAP poruke?
Zbog toga što se Web servis može koristiti u scenariju gdje je slanje SOAP poruke presloženo ili čak
neizvedivo. To se npr. dešava u situaciji kada HTML forma koristi Web servis. Ipak u najvećem broju
primjena Web servise će koristiti aplikacije tj. razmjenjivat će se SOAP poruke. U nastavku je dan
prikaz HTTP paketa te moguća primjena za svaku od navedenih metoda.
42
I) SOAP
Kao što je spomenuto, u najvećem broju slučajeva će se s Web servisom komunicirati putem SOAP
poruka. U tom slučaju korisnička aplikacija formira SOAP poruku u koju upisuje naziv metode koju želi
pozvati te argumente koje joj želi predati. Ta SOAP poruka se smješta u HTTP paket i šalje Web
servisu. Slijedi prikaz HTTP paketa koji sadrži SOAP poruku koja se šalje Web servisu.
POST /WebServis/HotelskiServis.asmx HTTP/1.1
Host: localhost
Content-Type: application/soap+xml; charset=utf-8
Content-Length:
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CijenaSobe xmlns="http://HoteliAvalon">
<BrojKreveta>3</BrojKreveta>
<BrojDanaBoravka>6</BrojDanaBoravka>
</CijenaSobe>
</soap12:Body>
</soap12:Envelope>
Slijedi prikaz povratnog HTTP paketa koji sadrži povratnu SOAP poruku s rezultatom izvoñenja.
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length:
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CijenaSobeResponse xmlns="http://HoteliAvalon">
<CijenaSobeResult>2610</CijenaSobeResult>
</CijenaSobeResponse>
</soap12:Body>
</soap12:Envelope>
Detaljnija analiza SOAP poruka slijedi u idučem poglavlju.
II) HTTP POST
HTTP POST metoda je mnogo jednostavnija od SOAP metode. No u toj jednostavnosti leži i veliki
nedostatak POST metode, a to je nemogućnost prenošenja složenijih tipova podataka ! To se može
ilustrirati na primjeru HTTP paketa koji se šalje Web servisu te sadrži POST zahtjev.
POST /WebServis/HotelskiServis.asmx/CijenaSobe HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length:
BrojKreveta=3&BrojDanaBoravka=6
Slijedi prikaz povratnog HTTP paketa s rezultatom izvoñenja metode.
43
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length:
<?xml version="1.0" encoding="utf-8"?>
<int xmlns="http://HoteliAvalon">2610</int>
Dakle problem kod POST metode je ograničenost na jednostavne tipove podataka koji se mogu
prenijet prikazanim načinom. Da bi se Web servisu poslalo složeniji tip podataka, potrebno je te
podatke zapisati u XML obliku (serijalizirati) što je moguće jedino SOAP porukom.
Zgodan primjer gdje se može na jednostavan način iskoristiti POST metoda je pozivanje Web servisa
iz jednostavne HTML forme, a to je upravo ono što se koristi u gore prikazanom načinu testiranja Web
servisa.
III) HTTP GET
HTTP GET metoda se bazira na slanju argumenata Web metodi u sklopu URL-a.
GET /WebServis/HotelskiServis.asmx/CijenaSobe?BrojKreveta=3&BrojDanaBoravka=6 HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length:
Dok rezultat dolazi kao kod POST metode.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length:
<?xml version="1.0" encoding="utf-8"?>
<int xmlns="http://HoteliAvalon">2610</int>
Očito je da ove HTTP POST i HTTP GET metode testiranja (koje omogućava i ASP.NET) nisu
prikladne za složenije tipove podataka. Za testiranje rada Web servisa sa složenijim tipovima ulaznih
podataka potrebno je razviti specifičnu testnu okolinu.
Treba spomenuti da se u Web pregledniku takoñer može vidjet i WSDL opis Web servisa i to tako da
se
na
URL
Web
servisa
doda
niz
?WSDL.
Dakle
otvaranjem
URL-a
http://localhost/WebServis/HotelskiServis.asmx?WSDL u Web pregledniku se dobiva cjeloviti WSDL
dokument koji opisuje izgrañeni Web servis. Kao što je spomenuto ranije, WSDL dokumenti se
generiraju i analiziraju programski.
44
2.3.2 Korištenje Web servisa u .NET aplikacijama
Primjer korištenja Web servisa bit će prikazan na primjeru jednostavne ASP.NET Web
aplikacije koja će putem jednostavne forme pružati jednostavnu funkcionalnost u skladu s onim što
pruža već pokazani Web servis. Bitno je naglasiti da osim Web aplikacija funkcionalnost Web servisa
mogu koristiti i konzolne aplikacije te Windows aplikacije, pa čak i sami Web servisi.
Primjer jednostavne Web aplikacije
Nova Web aplikacija može se kreirati dok se nalazimo u ranije izgrañenom projektu Web servisa. Na
taj način Web aplikacija postaje dio Solutiona kao novi projekt. Za smještaj Web aplikacije kreiran je
novi fizički direktorij E:\FER\WebAplikacija koji je takoñer pretvoren u virtualni direktorij te mu se
može pristupiti preko URL-a http://localhost/WebAplikacija . Stvaranje nove Web aplikacija započinje
se odabirom naredbi File / Add / Web Site u glavnom izborniku. Nakon toga se dobiva već poznati
prozor u kojem će sada odabir biti drugačiji nego ranije kod Web servisa.
Nakon odabira OK, u Solution Exploreru se pojavljuje novi projekt.
Treba uočiti da je projekt Web servisa
„zatamnjen“ što znači da je on aktivan. To
znači da će se on prevoditi i pokretati
odabirom naredbi iz menija. Ukoliko želimo
prevoditi i pokretati Web aplikaciju moramo
projekt Web aplikacije učiniti aktivnim. To
možemo učiniti tako da desnim klikom miša na
naziv projekta, u izborniku odaberemo opciju
Set as StartUp Project ili nakon što smo
kliknuli na naziv projekta u Solution Exploreru
odaberemo naredbe WebSite / Set as StartUp
Project u glavnom izborniku.
45
Na prethodnoj slici treba uočiti da su za Web aplikaciju takoñer generirane datoteke u code-behind
principu. .aspx datoteka će sadržavati HTML kôd sučelja aplikacije, dok će .cs datoteka sadržavati C#
programski kôd Web aplikacije. Visual Studio omogućava da se .aspx datoteka pregledava u Source i
Design načinu. Odabir pojedinog prikaza vrši se gumbom na dnu razvojnog okruženja. U Source
načinu se može ureñivati HTML kôd, dok se u Design načinu može vidjeti kako to sučelje izgleda u
Web pregledniku. U nastavku je dan prikaz svih varijanti gotove jednostavne Web aplikacije
Prikaz .aspx datoteke u Design načinu – sučelje jednostavne Web aplikacije
Slijedi sadržaj .aspx datoteke u Source prikazu.
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs" Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Primjer jednostavne Web aplikacije</title>
</head>
<body>
<form id="form1" runat="server">
<div>
Broj kreveta u sobi:<asp:TextBox ID="TextBox1" runat="server"
Width="62px"></asp:TextBox><br/>
Broj dana boravka:<asp:TextBox ID="TextBox2" runat="server"
Width="62px"></asp:TextBox><br/>
<asp:Button ID="Button1" runat="server" OnClick="Button1_Click"
Text="Dohvat slobodnih soba" Width="192px"/><br/>
<asp:Button ID="Button2" runat="server" OnClick="Button2_Click"
Text="Izračun cijene boravka"/><br/>
<asp:Label ID="Label1" runat="server"></asp:Label></div>
</form>
</body>
</html>
46
Prevoñenjem i pokretanjem Web aplikacije može se vidjeti sučelje aplikacije u Web pregledniku.
Dvostrukim klikom mišem na svaki od gumba u Design prikazu (u razvojnom okruženju), se u .cs
datoteci stvara odgovarajući Event Handler koji se izvršava pritiskom na odgovarajući gumb.
Prikaz .cs datoteke sa dodanim Event Handlerima.
using
using
using
using
using
System;
System.Web;
System.Web.UI;
System.Web.UI.WebControls;
System.Web.UI.HtmlControls;
namespace WebApp
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{ }
protected void Button1_Click(object sender, EventArgs e)
{
//Button1 je gumb za dohvat slobodnih soba
//Ovdje je potrebno programirati funkcionalnost
//za dohvat slobodnih soba
}
protected void Button2_Click(object sender, EventArgs e)
{
//Button2je gumb za izračun cijene
//Ovdje je potrebno programirati funkcionalnost
//za izračun cijene boravka
}
}
}
Preostaje samo iskoristiti Web servis i funkcionalnost koju on pruža. Kao što je spomenuto u prvom
poglavlju, posrednik u komunikaciji izmeñu aplikacije i servisa je proxy klasa. U nastavku je
objašnjeno kako kreirati proxy klasu te kako programirati potrebnu funkcionalnost.
47
Dodavanje Web reference
Uključivanje Web servisa u .NET aplikaciju odnosno stvaranje proxy klase, vrši se dodavanjem
Web reference. Postupak dodavanja je vrlo jednostavan i svodi se na traženje Web servisa i na kraju
jednostavno korištenje proxy klase. Proxy klasa se generira automatski na temelju WSDL dokumenta
odabranog Web servisa. Postupak dodavanja Web reference počinje klikom na projekt Web aplikacije
u Solution Exploreru te odabirom naredbi Website / Add Web Reference iz glavnog menija ili
padajućeg izbornika. Slijedi prikaz prvog koraka.
Nude se više mogućnosti oko toga gdje treba tražiti Web servise no u našem slučaju se Web servis
nalazi na lokalnom računalu, kao i aplikacija iz koje smo pokrenuli ovaj postupak. Nakon odabira
opcije Web services on the local machine Visual Studio automatski pretražuje računalo za svim
dostupnim Web servisima te nakon pretrage prikazuje rezultate.
Uočljivo je da je Web servis u drugom redu odozdo upravo Web servis koji je razvijen kao primjer u
ovom radu, a naveden je i njegov URL: http://localhost/WebServis/HotelskiServis.asmx .
Odabirom tog Web servisa prikazuje se detaljan prikaz Web servisa s njegovim imenom (iz
WebService atributa), opisom, popisom Web metoda i njihovim nazivima.
48
U ovom završnom prozoru postupka uključivanja Web servisa u aplikaciju, može se odabrati naziv
Web reference. Za naziv Web reference se obično uzima naziv računala na kojem se Web servis
nalazi. U ovom slučaju to je localhost. Klikom na Add Reference referenca je dodana i pojavila se u
Solution Exploreru.
Vidi se da je automatski generiran i .wsdl opis
Web servisa te takoñer i .disco dokument koji
služi kao „link“ na Web servis. O otkrivanju Web
servisa i .disco dokumentima će biti govora
kasnije.
Web referenca, u ovom slučaju localhost,
predstavlja namespace koji sadrži proxy klasu.
To znači da se sada proxy klasa može koristiti
kao bilo koja druga klasa u aplikaciji. Naziv
proxy klase je pritom naziv koji je Web servisu
dodijeljen putem Name svojstva u WebService
atributu (bez razmaka). Proxy klasa se nadalje
instancira u objekt nad kojim se pozivaju
metode, a to su upravo Web metode Web
servisa.
Slijedi prikaz potpunog programskog kôda .cs datoteke.
using
using
using
using
using
System;
System.Web;
System.Web.UI;
System.Web.UI.WebControls;
System.Web.UI.HtmlControls;
namespace WebApp
{
public partial class _Default : System.Web.UI.Page
{
//Deklaracije varijabli
public localhost.Webservishotelskoglanca Servis;
public int Rezultat;
protected void Page_Load(object sender, EventArgs e){ }
//Event handler za gumb Dohvat slobodnih soba
49
protected void Button1_Click(object sender, EventArgs e)
{
//Instanciranje proxy klase
Servis = new localhost.Webservishotelskoglanca();
//Pozivanje metode nad objektom Servis
int BrojKreveta = int.Parse(TextBox1.Text)
Rezultat = Servis.BrojSlobodnihSoba(BrojKreveta);
//Prikaz poruke s rezultatom u sučelju
Label1.Text = "Slobodnih soba je " + Rezultat.ToString();
}
//Event handler za gumb Izračun cijene
protected void Button2_Click(object sender, EventArgs e)
{
//Instanciranje proxy klase
Servis = new localhost.Webservishotelskoglanca();
//Pozivanje metode nad objektom Servis
int BrojKreveta = int.Parse(TextBox1.Text)
int BrojDana = int.Parse(TextBox2.Text)
Rezultat = Servis.CijenaSobe(BrojKreveta,BrojDana);
//Prikaz poruke s rezultatom u sučelju
Label1.Text = "Cijena boravka je " + Rezultat.ToString() +
"kn";
}
}
}
Vidljivo je da se proxy klasa koristi kao bilo koja druga klasa u kôdu. Takoñer je bitno znati da proxy
klasa skriva sve detalje oko komunikacije sa servisom te programeru daje privid da izravno koristi sam
Web servis. Otvaranjem Web aplikacije u pregledniku može se provjeriti rad aplikacije tj. komunikacija
s Web servisom.
50
2.4
.NET SDK - izgradnja i korištenje Web servisa
U ovom poglavlju obrañena je izgradnja i korištenje Web servisa primjenom .NET SDK
(Software Development Kit) paketa. .NET SDK se automatski instalira kod instalacije Visual Studio
paketa no moguće ga je besplatno skinuti s Interneta neovisno od Visual Studio paketa. Omogućava
razvoj .NET aplikacija bez razvojnog okruženja kao što je Visual Studio tj. razvoj se vrši pomoću bilo
kojeg tekstualnog editora te osnovnih alata koje donosi SDK.
2.4.1 Izgradnja Web servisa
Izgradnja Web servisa pomoću .NET SDK se temelji na jednostavnom kreriranju .asmx i .cs
datoteka, ako se primjenjuje code-behind, odnosno .asmx datoteke ako se ne primjenjuje codebehind. Datoteke se pohranjuju u virtualnom direktoriju predviñenom za smještanje Web servisa.
Virtualni direktoriji se kreiraju na način koji je pojašnjen ranije. Za primjer će se iskoristiti isti Web
servis koji je izgrañen ranije. Sadržaji datoteka HotelskiServis.asmx i HotelskiServis.cs su identični.
Sadržaj virtualnog direktorija nakon kreiranja i pohranjivanja datoteka izgleda kao na slikama.
Nakon spremanja datoteka Web servis se može na isti način kao i ranije pozvati iz Web preglednika
putem svojeg URL-a http://localhost/WebServisSDK/HotelskiServis.asmx . Treba uočiti da nije
potrebno prevoditi izvornu datoteku s programskim kôdom jer to, jednostavno rečeno, čini .NET
Framework prilikom pozivanja Web servisa.
2.4.2 Korištenje Web servisa
Za primjer aplikacije koja koristi Web servis će se iskoristiti jednostavna Web aplikacija iz
prethodnog primjera. Sadržaj datoteka Default.aspx i Default.aspx.cs je potpuno jednak te se pomoću
tekst editora mogu kreirati navedene datoteke koje se smještaju u predviñeni virtualni direktorij.
Sadržaj takvog virtualnog direktorija u kojem se nalazi Web aplikacija izgleda kao na slici.
51
Preostaje pitanje kako u slučaju korištenja SDK-a generirati proxy klasu te kako tu klasu
uključiti u aplikaciju. Za generiranje proxy klase služi wsdl.exe alat. Pokreće se iz komandne linije te
na temelju WSDL dokumenta nekog Web servisa može generirati .cs datoteku koja sadrži proxy klasu
za taj Web servis. Do WSDL.exe alata, a i do svih drugih alata koje sadrži .NET SDK može se doći
pokretanjem SDK komandne linije naredbama Start / Programs / Microsoft .NET Framework SDK 2.0 /
SDK Command Prompt .
Za generiranje proxy klase u odgovarajućoj .cs datoteci, WSDL.exe alatu je potreban samo URL Web
servisa. Takoñer je potrebno odabrati naziv namespacea koji će sadržavati proxy klasu, a to je upravo
Web referenca u Visual Studio okruženju. Tamo je rečeno da se za ime Web reference tj. namespacea
obično odabire naziv računala na kojem se nalazi Web servis pa će se isto primijeniti i ovdje. Naredba
kojom se pokreće generiranje proxy klase glasi:
> wsdl /n:localhost http://localhost/WebServisSDK/HotelskiServis.asmx?wsdl
Pojednostavljeni opći oblik wsdl.exe alata:
Neke opcije wsdl.exe alata:
•
•
•
•
wsdl.exe <opcije> <url ili staza>
/language:<language>
Omogućava odabir programskog jezika u kojem će biti generirana proxy klasa, kratka
verzija opcije je /l: . Defaultni jezik je C#.
/namespace:<namespace>
Omogućava definiranje namespacea za proxy klasu, kratka verzija /n:
/out:<izlazna_datoteka ili staza>
Omogućava definiranje direktorija u koji treba generirati proxy klasu te definiranje
naziva same datoteke proxy klase, kratka verzija /o:
/protocol:<protokol>
Omogućava odabiranje protokola za pozivanje Web servisa, osim SOAP-a mogu se
izabrati HTTPGET i HTTPSOAP kao što je spomenuto ranije kod testiranja Web
servisa. Defaultni protokol je SOAP.
Nakon izvršenja, u glavnom direktoriju SDK-a (direktorij u kojem se nalazi nakon što se
pokrene SDK command prompt) se nalazi generirana proxy klasa u .cs datoteci. Naziv datoteke, i
same klase, je jednak nazivu Web servisa koji je definiran Name svojstvo WebService atributa (bez
razmaka). U ovom slučaju generirana je datoteka Webservishotelskoglanca.cs. U toj datoteci se
nalazi proxy klasa koja je takoñer istog imena. Sve što preostaje je uključiti datoteku s proxy klasom u
Web aplikaciju, a to se svodi na jednostavno pohranjivanje dobivene .cs datoteke u App_Code
poddirektorij Web aplikacije ! Sadržaji direktorija nakon navedenog izgledaju kao na slici.
Nakon toga moguće je aplikaciju jednostavno pokrenuti u pregledniku putem njezinog URL-a
http://localhost/WebAplikacijaSDK/Default.aspx .
52
2.5
SOAP
Već je spomenuto kako je protokol SOAP jedan od temelja arhitekture Web servisa. Razmjena
podataka izmeñu korisnika i Web servisa se odvija upravo pomoću protokola SOAP. Spomenuto je i da
se SOAP poruke prenose protokolom HTTP tj. jedan HTTP paket sadrži jednu SOAP poruku. Iako u
najvećem broju primjena korisnik izravno ne utječe na SOAP komunikaciju, u ovom dijelu će biti
detaljnije opisane SOAP poruke, njihova struktura i mogućnosti.
2.5.1 Uvod i osnovni pojmovi
Protokol SOAP je izvorno zamišljen kao protokol za slanje poruka u jednom smjeru (one-way)
no u različitim primjenama se mogu ostvariti različite varijante komunikacije kao što su zahtjev i
odgovor (request / response), zahtjev i više odgovora itd. U slučaju Web servisa se ostvaruje upravo
request/response način komunikacije gdje se razmjenjuju dvije poruke. Prvo korisnik šalje SOAP
poruku Web servisu, a zatim Web servis odgovara slanjem nove SOAP poruke. U slučaju Web servisa
se request/response način komunikacije temelji upravo na protokolu HTTP kojemu je
request/response prirodan način komunikacije. Dakle primjenom protokola HTTP se ostvaruje
request/response komunikacija SOAP porukama.
Bitno je naqlasiti da protokol SOAP ni na koji način ne „razumije“ značenje podataka koje
prenosi tj. semantiku komunikacije.
Osnovna jedinka koja vrši razmjenu SOAP poruka je SOAP čvor (eng. node). SOAP čvor može
biti SOAP pošiljatelj (eng. sender), SOAP primatelj (eng. receiver) i SOAP posrednik (eng.
intermediary). Ovisno o primjeni mogu se izgraditi složene strukture SOAP čvorova.
SOAP poruka je tekstualna poruka u XML formatu podataka, a u XML obliku su i podaci koji se
prenose SOAP porukom. Što ponovno ukazuje na značaj XML-a.
Slika 2.6: SOAP komunikacija
53
2.5.2 Struktura SOAP poruke
Temeljni okvir SOAP poruke čini SOAP omotnica (eng. envelope). SOAP omotnica sadrži
cjelokupnu strukturu SOAP poruke. Dva temeljna gradivna elementa SOAP omotnice su SOAP zaglavlje
(eng. header, u daljnjem tekstu: zaglavlje) i SOAP tijelo (eng. body, u daljnjem tekstu tijelo). SOAP
zaglavlje nije obavezni dio SOAP poruke. SOAP tijelo je obavezni dio SOAP poruke.
Zaglavlje najčešće služi za prijenos „sustavnih“ informacija koje nisu izravno povezane sa podacima
koji se prenosi. Takve informacije mogu npr. poslužiti za definiranje uputa oko usmjeravanja (eng.
routing) SOAP poruke te oko načina obrade podataka koje poruka prenosi. Sve zapravo ovisi o
primjeni te zahtjevima koje je u odreñenom sustavu potrebno ispuniti. Zaglavlje se dalje može dijeliti
na blokove.
Tijelo ima primarnu i glavnu funkciju da sadrži podatke koji se prenose SOAP porukom.
Obzirom da je SOAP poruka XML dokument ona se sastoji od oznaka (eng. tag). Kao što je opisano u
prvom poglavlju potrebno je razlikovati oznake koje opisuju strukturu SOAP poruke od oznaka koje
opisuju podatke koje SOAP poruka prenosi. To je zadatak XML namespacea i monikera kojima se
definira koja oznaka pripada kojem prostoru imena.
Slijedi primjer SOAP poruke. Za oznake SOAP poruke koristi se env moniker. XML namespace za
oznake SOAP poruke se nalazi na URL-u http://www.w3.org/2003/05/soap-envelope .
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<mojns:secure xmlns:mojns="http://HoteliAvalon">
pqff98fe8j7d
</mojns:secure>
</env:Header>
<env:Body>
<mojns:rezervacija xmlns:mojns="http://HoteliAvalon">
<mojns:popis_osoba>
<mojns:osoba>Ivo Ivic</mojns:osoba>
<mojns:osoba>Marko Markic</mojns:osoba>
</mojns:popis_osoba>
<mojns:podaci_rezervacija>
<mojns:trajanje>17</mojns:trajanje>
<mojns:dolazak>010107</mojns:dolazak>
<mojns:odlazak>010107</mojns:odlazak>
</mojns:podaci_rezervacija>
</env:Body>
</env:Envelope>
SOAP zaglavlje
Zaglavlje općenito sadrži informacije koje nisu sastavni dio podataka koje prenosi poruka.
Takve informacije se najčešće odnose na usmjeravanje poruke i procesiranje podataka iz poruke. Npr.
ukoliko su podaci u tijelu poruke kriptirani na odreñeni način, primatelj poruke mora znati kojim
enkripcijskim algoritmom su podaci kriptirani da bi ih mogao dekriptirati. Očito nema smisla te podatke
pohraniti u samo tijelo tj. podatke, nego za takve i slične podatke služi upravo zaglavlje.
Najčešći sadržaj/primjenu zaglavlja: podaci o autentičnosti pošiljatelja, digitalni potpis koji garantira
valjanost podataka u poruci, podaci o usmjeravanju itd.
Zaglavlje je opcionalan element SOAP poruke i ukoliko ga SOAP poruka sadržava, zaglavlje se u
samom zapisu poruke nalazi na samom početku omotnice, kao što je prikazano u primjeru gore.
Informacije koje se nalaze u zaglavlju se grupiraju u blokove.
54
Općenito gledano, zaglavlje može sadržavati informacije koje su dio SOAP standarda i
informacije koje nisu dio standarda i koje se unose ovisno o primjeni. Svaki SOAP čvor je obvezan kod
primitka poruke, analizirati one dijelove zaglavlja koji su definirani standardom. Jasno je da su ti
dijelovi dio env namespacea tj. koristi se env: moniker.
SOAP standard definira atribute zaglavlja koji donose neke mogućnosti oko procesiranja i
usmjeravanja poruka. U nastavku će biti pojašnjeni role i mustUnderstand atributi.
I) role atribut
Ovisno o primjeni, različitim čvorovima se mogu namijeniti različite funkcije tj. uloge. Jasno
je da čvorovi „znaju“ koju ulogu imaju. Na konceptu uloge se temelji mehanizam odlučivanja koji blok
zaglavlja treba ili ne treba obraditi. Role atributom se svakom bloku zaglavlja dodjeljuje uloga koju
čvor treba ispunjavati da bi smio obraditi taj blok zaglavlja. Drugim riječima, ukoliko čvor analizira
sadržaj role atributa, i uoči da role atribut sadrži njegovu ulogu, on procesira taj blok.
Primjer:
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<ns1:PrviBlok xmlns:ns1="http://namespace_prvog_bloka"
env:role="http://uloga-x">
...
</ns1:PrviBlok>
<ns2:DrugiBlok xmlns:ns2="http://namespace_drugog_bloka"
env:role="http://uloga-y">
...
</ns2:DrugiBlok>
</env:Header>
<env:Body >
...
</env:Body>
</env:Envelope>
Čvor koji ima ulogu x će obraditi prvi blok zaglavlja, a čvor koji ima ulogu y drugi blok.
II) mustUnderstand atribut
Nakon što je čvor analizom zaglavlja pronašao sve blokove koji se odnose na njega, iz bilo
kojeg razloga se može desiti da čvor u potpunosti ili djelomično ne izvršili ili ne analizira neki od tih
blokova. Zbog toga postoji mustUnderstand atribut koji, ukoliko je prisutan u odreñenom bloku,
obvezuje čvor da bez iznimke obavi sve što je definirano u dotičnom bloku.
Primjer:
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<ns1:PrviBlok xmlns:ns1="http://namespace_prvog_bloka"
env:role="http://uloga-x" env:mustUnderstand="true">
...
</ns1:PrviBlok>
</env:Header>
<env:Body >
...
</env:Body>
</env:Envelope>
55
SOAP tijelo
Tijelo je obvezni dio SOAP poruke. Tijelo sadrži podatke koje pošiljatelj šalje primatelju.
Podaci mogu biti u XML obliku, mogu biti niz znakova, mogu biti u binarnom obliku. SOAP standard
definira način pohranjivanja podataka u poruku o čemu će biti više govora kasnije. SOAP poruke se,
obzirom na podatke koje sadrže, mogu biti orijentirane na procedure (eng. procedure oriented) i
orijentirane na dokumente (eng. document oriented)
Poruke orijentirane na proceduru se koriste u RPC (Remote Procedure Call) komunikaciji,
što je ujedno i način komunikacije kod Web servisa. Tijelo ovakvih poruka sadrži podatke o udaljenim
procedurama (funkcijama, metodama) koje se pozivaju te ulazne parametre koji im se šalju, odnosno
rezultate izvoñenja procedura.
Poruke orijentirane na dokumente se koriste u jednosmjernoj (eng. one way) komunikaciji i
to najčešće u različitim poslovnim primjenama, za slanje poslovnih dokumenata itd.
Slijedi primjer razmjene poruka u RPC komunikaciji koja se izvodi za udaljeno pozivanje jednostavne
metode za zbrajanje koja izgleda ovako:
public int Zbrajanje(int x, int y)
{
return x + y;
}
Tijelo SOAP poruke koja sadrži poziv te metode sadrži naziv metode te ulazne argumente i izgleda
ovako (nije prikazana cijela poruka nego samo tijelo poruke):
<env:Body>
<mojns:Zbrajanje xmlns:mojns=“http://moj_namespace“>
<mojns:x>1</mojns:x>
<mojns:y>2</mojns:y>
</mojns:Zbrajanje>
</env:Body>
Ovako npr. izgleda odgovor:
<env:Body>
<mojns:RezultatZbrajanja xmlns:mojns=“http://moj_namespace“>
<mojns:rez>1</mojns:rez>
</mojns: RezultatZbrajanja >
</env:Body>
2.5.3 SOAP Encoding
SOAP Encoding standardom je definiran način zapisivanja različitih tipova podataka u SOAP
poruku. U nastavku će putem primjera biti ukratko prikazan način zapisivanja najvažnijih tipova
podataka. Područje zapisivanja podataka u XML obliku je vrlo opsežno i nadilazi granice ovog rada.
Jednostavni tipovi
Jednostavni tipovi podataka su cijeli brojevi, nizovi znakova, logičke varijable itd. Način
zapisivanja jednostavnih tipova se temelji na kreiranju oznake s nazivom varijable tog tipa. Npr.
<var1>24</var1>
<var2>IBAZCSP</var2>
56
Složeni tipovi - strukture
Primjer podatkovne strukture:
public struct OsobniPodaci
{
public string Ime;
public string Prezime;
public string JMBG;
}
čija se instanca Podaci_XY u XML formatu zapisuje ovako:
<Podaci_XY>
<Ime>Marko</Ime>
<Prezime>Markic</Prezime>
<JMBG>0001111222333</JMBG>
</Podaci_XY>
Složeni tipovi - polja
Polje cijelih brojeva, imena PrimjerPolja, zapisuje se na sljedeći način:
<PrimjerPolja soap-enc:arrayType="xsi:int[3]">
<int>11</int>
<int>68</int>
<int>22</int>
</PrimjerPolja>
Treba uočiti arrayType atribut, definiran soap-enc: monikerom, koji preciznije opisuje polje tj.
naglašava tip podataka u polju te broj elemenata polja.
XML tehnologije su vrlo široko područje i njihovo objašnjenje nadilazi ovaj rad.
57
2.6 UDDI i DISCO
Do sada je bilo govora o tome što je Web servis, kako izgraditi Web servis, kako koristiti Web
servis, opisana je komunikacija putem poruka i općenito je opisano što sačinjava jedan Web servis no
nije bilo govora o procesima u kojima sudjeluju Web servisi. Najvažniji, a vjerojatno i najprirodniji
proces za Web servise je proces otkrivanja. Ako izgradimo Web servis, on je u najvećem broju
slučajeva beskoristan, ukoliko ga ne otkriju novi korisnici. To je uostalom i priroda Web servisa.
Stoga se odmah u startu pojavila potreba za načinom distribuiranja podataka o Web servisima
na Webu kako bi ih potencijalni korisnici mogli pronaći. Proces otkrivanja se može implementirati na
različite načine ali ovdje će biti govora samo o konceptu direktorija (baze) Web servisa.
UDDI je možda najvažniji protokol koji definira standardni način objavljivanja i otkrivanja Web servisa.
DISCO je Microsoftov standard za distribuciju informacija o Web servisima.
2.6.1 UDDI – Universal Description, Discovery and Integration
Za razliku od većine drugih standarda vezanih za Web servise koje razvija W3C, UDDI je
razvijen od strane OASIS-a. Na tom tragu nalaze se i neki standardi sigurnosti Web servisa koje
takoñer razvija OASIS.
UDDI standard se temelji na konceptu središnjeg registra kojemu je glavna funkcija upravo
pohrana i ustupanje podataka i metapodataka o Web servisima. Registar se može koristiti u intranet ili
Internet okruženju tj. može biti dostupan isključivo unutar nekog poslovnog okruženja ili može biti
dostupan svima na Webu. UDDI registar na standardom predviñen način organizira i grupira Web
servise te omogućava da potencijalni korisnici pronañu upravo one Web servise koji su im potrebni.
UDDI registar može npr. omogućavati neke od sljedećih funkcija: objavljivanje podataka o
Web servisima prema kategorijama, pretraživanje Web servisa prema definiranim kriterijima,
utvrñivanje sigurnosti koju ima odreñeni Web servis, utvrñivanje načina komunikacije s Web servisom
itd.
Posebno je važno da je UDDI registar i sam ustvari Web servis jer nudi standardno
programsko sučelje (API) za svoje usluge, baš kao što to čine i Web servisi !
Osim toga UDDI se temelji na istim tehnologijama kao i Web servisi, kao što su SOAP, HTTP, XML, i
WSDL.
UDDI model podataka
Obzirom na značaj XML-a, podatkovni model UDDI registra je definiran skupom XML Schema
dokumenata. XML i u ovom slučaju ima isti značaj kao što je spomenuto ranije jer pruža neovisnost o
programskom jeziku i platformi. Druga prednost XML Scheme je što podržava složene tipove podataka
što dalje znači da UDDI registar može podržavati različite složene tipove Web servisa. Slijedi kratki
opis najvažnijih tipova podataka UDDI registra.
•
businessService,
•
•
•
businessEntity,
bindingTemplate,
tModel,
opisuje poslovnu funkcionalnost tj. uslugu koju Web servis
pruža
sadrži informacije o organizaciji koja je objavila Web servis
opisuje tehničke detalje Web servisa, njegov URL itd.
različiti metapodaci koji se odnose na komunikacija sa
servisom, sigurnost, digitalne potpise itd.
58
UDDI API
API (Application Programming Interface) je skup metoda kojima neki sustav nudi svoje
usluge. UDDI API je skup metoda kojima UDDI registar nudi svoje usluge potencijalnim korisnicima.
Konkretno, to znači da se prilikom razvoja aplikacije, mogu koristiti metode koje nudi UDDI (kao što
se koriste metode Web servisa) i na taj način aplikacija može imati sposobnost komunikacije s UDDI
registrom. UDDI API se dijeli na nekoliko različitih skupova metoda, gdje se skupovi meñusobno
razlikuju po svojoj namjeni. Prema UDDI v3 standardu koji je trenutno aktualan, postoji 6 skupova
metoda, od kojih su možda najvažniji:
•
•
•
UDDI Inquiry,
omogućava pretraživanje i dohvaćanje podataka iz UDDI registra.
Primjeri funkcija: find_binding, find_business, find_service itd.
UDDI Publication, omogućava objavljivanje i obnavljanje podataka u UDDI registru.
Primjeri funkcija: save_service, save_business, delete_service itd.
UDDI Security Policy, rješava odreñena pitanja sigurnosti komunikacije
Struktura UDDI registra
Jasno je da je UDDI registar fizička tj. računalna struktura. UDDI standard definira i neke
aspekte fizičke strukture UDDI registra.
Definiranje strukture registra kreće od koncepta UDDI čvora. Standard kaže da UDDI čvor (što
god on bio u stvarnosti) meñu ostalim mora omogućavati interakciju s UDDI podacima kroz jedan ili
više API skupova metoda te da je svaki UDDI čvor pripadnik točno jednog UDDI registra. Standard ne
definira kako čvor treba biti fizički izveden što ostavlja prilično širok manevarski prostor. U načelu
UDDI čvor može biti čak i mobilni ureñaj.
UDDI registar je viša i veća struktura od UDDI čvora. Da bi se računalni sustav mogao nazvati
UDDI registrom, on meñu ostalim, mora sadržavati jedan ili više UDDI čvorova. Takoñer čvorovi u
registru moraju zajednički upravljati UDDI podacima te izmeñu čvorova dolazi do replikacije podataka.
Kao i u slučaju UDDI čvora, standard ne definira fizičku izvedbu UDDI registra.
Ako se uzmu u obzir: koncept UDDI registra koji se sastoji od više UDDI čvorova koji
meñusobno komuniciraju i održavaju registar, koncept UDDI registra dostupnog na Webu, koncept
privatnog UDDI registra koji djeluje unutar privatnog poslovnog intraneta, onda je za očekivati da
tijekom vremena može doći do formiranja različitih složenih UDDI struktura.
Slika 2.7: Primjer UDDI strukture i prirode podataka u registrima
59
2.6.2 Microsoft UDDI Services
Djelovanje Microsofta na području koje definira UDDI standard se u najvećoj mjeri odnosi na
Microsoft UDDI Services platformu koja omogućava uspostavu UDDI registra Web servisa u intranet ili
Internet okruženju. Microsoft UDDI Services je podržan isključivo na Windows Server 2003
operacijskom sustavu što je i logično obzirom na prirodu i funkciju UDDI registra.
UDDI Services platforma se bazira na .NET Frameworku te omogućava Web pristup putem
korisničkog sučelja ili programski pristup putem protokola SOAP.
Glavni razvojni alat za sve Microsoft scenarije je Visual Studio .NET koji prepoznaje Web servise u
formi Web referenci. Ranije je prikazano kako prilikom dodavanja nove Web reference, postoji i
mogućnost pretraživanja UDDI registra.
2.6.3 Microsoft DISCO
Iako UDDI pruža prilično napredne mogućnosti u području objavljivanja i otkrivanja Web
servisa, Microsoft je razvio DISCO protokol koji pokriva jednu alternativnu vrstu scenarija. UDDI se
bazira na centraliziranoj bazi podataka koja sadrži informacije, ne o Web servisima koji postoje, nego
o Web servisima koji su u bazi objavljeni. Stoga da bi Web servis mogao biti korišten potrebno ga je
objaviti u bazi. Nadalje UDDI predviña pretraživanje baze, a ne pretraživanje odreñenog URL-a.
DISCO protokol nudi rješenje za takve i slične slučajeve gdje programer već kod razvoja Web
servisa može putem .disco dokumenata omogućiti pristup Web servisu bez da je servis objavljen u
registru. Osim toga DISCO protokol omogućava da se na zadanom URL-u utvrdi postojanje Web
servisa putem .disco dokumenata. Iako se može činiti kao dva naziva za istu stvar, to ipak nije tako.
A jedan od argumenata je i sama jednostavnost .disco dokumenta kojim se i formalno potvrñuje
postojanje Web servisa na računalu. .disco dokumenti su (naravno) XML dokumenti koji se smještaju
upravo u virtualni direktorij gdje je smješten i sam Web servis.
Primjer .disco dokumenta izgleda ovako:
<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco/"
xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/“>
<wsdl:contractRef ref=“http://localhost/WebServis/Servis.asmx?WSDL/>
</disco:discovery>
Jedna od prednosti .disco dokumenata je da se mogu neograničeno širiti URL-ovima Web servisa.
Protokol DISCO nije standard i na području Web servisa on je već prošao svoj vrhunac. Tijekom
vremena DISCO će zamijeniti WS-Inspection protokol, koji za razliku od DISCO protokola, je standard.
60
2.7 Sigurnost
Uzme li se u obzir činjenica da će većina u budućnosti Web servisa vrlo vjerojatno imati neku
vrstu naplate za usluge koje pružaju, te činjenica da je sigurnost danas pitanje broj jedan, logično je
da sigurnost Web servisa ima veliku važnost.
Do sada je bilo dosta govora o protokolu SOAP koji prema standardu nema riješeno pitanje
sigurnosti nego se pouzdaje u sigurnost svog nositelja, a u ovom slučaju je to protokol HTTP. Za
sigurnu komunikaciju putem HTTP-a zaslužan je protokol SSL koji bi se trebao koristiti uvijek kada se
zahtjeva očuvanje sigurnosti i povjerljivosti podataka koji se prenose. No to nije dovoljno.
Sigurnosnim standardima za Web servise se u najvećoj mjeri bavi OASIS te je razvijeno nekoliko
standarda koji apstraktno opisuju različite aspekte sigurnosti Web servisa. Te apstraktne modele iz
standarda je potrebno implementirati nekim konkretnim postojećim rješenjima.
2.7.1 Web Services Security (WS-Security)
Web Services Security standard (u daljnjem tekstu WSS) je izvorno opisan zajedničkom
suradnjom Microsofta i IBM-a, a kasnije je OASIS preuzeo daljni razvoj. WSS standard opisuje
sigurnosna rješenja u obliku nadogradnji na protokol SOAP (SOAP extensions) te je stoga i puni naziv
standarda Web Services Security: SOAP Message Security.
U realnosti se može očekivati nekoliko osnovnih vrsta opasnosti: poruka može biti promijenjena ili
pročitana od strane napadača, napadač može poslati neautentičnu poruku servisu, može izmijeniti
sadržaj poruke te uzrokovati da servis radi za napadača umjesto za svog pravog korisnika itd.
Ako se obuhvate sve moguće prijetnje, može se reći da je u temelju potrebno osigurati: očuvanje
integriteta podataka i očuvanje povjerljivosti podataka. Kao što je već spomenuto, standard ne
predviña konkretna rješenja, nego je modele iz standarda potrebno implementirati konkretnim
rješenjima kao što su npr. SSL, PKI, Kerberos itd.
Neki od mehanizama koji bi trebali poslužiti kod izgradnje konkretnih sigurnosnih rješenja su:
•
tokeni (sigurnosne propusnice) – rješava pitanje autentičnosti korisnika na način da se
tijekom komunikacije razmjenjuje token kojim se
garantira autentičnost obje strane. Token se izdaje
na početku komunikacije i tijekom komunikacije se
može primijeniti na različite načine npr. kod
pozivanja svake metode ili u definiranim momentima
itd.
•
digitalni potpis
- omogućava digitalno potpisivanje bloka podataka i
time garantira njegov integritet npr. XML Signature
•
kodiranje podataka
- kodiranjem se osigurava integritet i povjerljivost
podataka. Integritet poruke osigurava XML
Signature, dok povjerljivost osigurava XML
Encryption mehanizam, oba u kombinaciji s
tokenima
61
2.7.2 Microsoft Web Services Enhancements
Microsoft WSE (trenutno u v2 SP3) je dodatak .NET Frameworku kojim se omogućava
implementacija sigurnosti u SOAP porukama prema WSS standardu. Neki od mehanizama dostupnih
programeru putem WSE dodatka su: tokeni s korisničkim imenom, binarni tokeni temeljeni na X.509
certifikatima, binarni tokeni temeljeni na Kerberos propusnicama (ticket), vlastiti binarni tokeni, XML
tokeni, enkripcija XML podataka itd.
WSE funkcionira u obliku „filtera“ kroz koje prolaze SOAP poruke i koji ih mijenjaju u skladu sa
programskim rješenjem.
62
3. Windows Communication Foundation
3.1 Uvod
Web usluge obrañene u 1. i 2. poglavlju su zapravo dio šireg područja koje se jednostavno naziva
usluge (eng. services). Web usluge se mogu promatrati i kao prethodnik usluga no i kao jedna
instanca ili tip usluga. Kad se govori o Web uslugama, podrazumijeva se postojanje usluge i klijenta
koji meñusobno komuniciraju porukama putem Interneta tj. Weba. Oblik poruka, metoda razmjene i
ostale detalje definira SOAP specifikacija, dok se kao transportni mehanizam koristi protokol HTTP.
Iako izmeñu usluga i Web usluga postoje velike sličnosti i iako se najvećim dijelom koriste iste
tehnologije, usluge ipak nisu ograničene samo na korištenje protokola HTTP za prijenos poruka. Osim
prijenosnog protokola, može se reći da su usluge nešto naprednije od Web usluga po pitanju
sigurnosti, podrške obavljanju transakcija, pouzdanosti, performansama itd. WCF je upravo primjer
okvira koji objedinjuje sve to u jedinstveni programski model za razvoj usluga. Iako postoje jasne
razlike izmeñu usluga i Web usluga, to ne znači da one meñusobno ne mgu komunicirati ili da se radi
o nekompatibilnim tehnologijama.
Web usluge su, kao što je objašnjeno ranije, evolucija u razvoju raspodijeljenog softvera. Nakon
različitih pokušaja i tehnologija kao što su COM, DCOM, COM+ itd. Web usluge su prvi puta omogućile
komunikaciju koja do tada nije bila moguća ili nije bila jednostavno izvediva. To znači komunikaciju
izmeñu aplikacija na različitih platformama, različitim operacijskim sustavima, različitim programskim
jezicima, različitih modelima podataka itd.
Takva komunikacija „bez granica“ postaje standard u razvoju raspodijeljenih sustava i očekuje se da
aplikacije mogu meñusobno komunicirati bez obzira na detalje implementacije. Usluge omogućavaju
baš takvu komunikaciju i zbog toga se razvoj softvera okreće prema razvoju usluga. Web usluge su
jedan korak u tom procesu. Ono što slijedi nakon Web usluga su usluge. U nastavku će se detaljnije
pojasniti koncept usluge i arhitekture zasnovane na uslugama. Nakon toga će se detaljnije pojasniti
što je to WCF i na koji način WCF podržava razvoj raspodijeljenih sustava zasnovanih na uslugama.
3.1.1. Usluge i arhitektura zasnovana na uslugama (SOA)
Softver koji se danas razvija je primarno okrenut komunikaciji. Softver mora komunicirati s
korisnicima, bazama podataka, drugim softverom itd. Načina za ostvarenje te komunikacije je mnogo,
a jedan od tih načina je promatranje aplikacija kao usluga. Uslužna orijentacija (eng. service
orientation) je pristup razvoju softvera koji aplikacije promatra kao usluge koje komuniciraju
razmjenom poruka. Iz usluga se grade složenija rješenja, nove usluge i općenito raspodijeljeni sustavi.
Iako se može činiti da je uslužna orijentacija naslijedila objektnu orijentaciju to nije tako. Unatoč
brojnom pozitivnim stvarima koje uslužna orijentacija ima u odnosu na objektnu, nije moguće, niti je
potrebno, u potpunosti izbjeći objektnu orijentaciju. Najjednostavniji primjer je elementarna usluga
koja se sama ne sastoji od drugih usluga nego od razreda i objekata tj. ostvarena je na objektnoorijentirani način. Jedna očita razlika izmeñu objektne i uslužne orijentacije je da kod objektne
orijentacije postoji jasna hijerarhija razreda u nekom raspodijeljenom sustavu, dok kod uslužne
orijentacije ne postoji hijerarhija usluga. To dovodi do vrlo važne razlike izmeñu objektne i uslužne
orijentacije, a to je povezanost. Raspodijeljeni sustavi temeljeni na objektnoj orijentaciji tj. objektima
su čvrstvo povezani (eng. tightly coupled), dok su sustavi temeljeni na uslužnoj orijentaciji slabo
povezani (eng. loosely coupled). Čvrsta povezanost znači da u objektnoorijentiranom sustavu mora
postojati čvrsta i jasna hijerarhija razreda koju „razumiju“ sve aplikacije uključene u sustav. To kod
usluga nije slučaj jer osim što ne postoji hijerarhija razreda ni hijerarhija usluga, pojedine usluge tj.
aplikacije u sustavu zaista ne moraju imati nikakve informacije o implementaciji drugih usluga. Slaba
povezanost donosi brojne prednosti u odnosu na čvrstu povezanost. Meñu ostalim, upravo je slaba
povezanost zaslužna za mogućnost komunikacije izmeñu nekompatibilnih platformi, jezika i
operacijskih sustava.
63
Slika 3.1: Objektna orijentacija u raspodijeljenom sustavu
Slika 3.2: Uslužna orijentacija u raspodijeljenom sustavu
Može se reći da se uslužna orijentacija temelji na četiri osnovna elementa koja vrijede u svakom
raspodijeljenom sustavu temeljenom na uslugama. Ti elementi su:
-Eksplicitne granice izmeñu aplikacija tj. usluga
-Autonomnost pojedinih usluga
-Dijeljenje modela podataka koji se razmjenjuju, a ne hijerarhija razreda
-Ponašanje usluge prema korisniku ovisi o ugovoru s korisnikom (eng. policy)
Spomenuto je da se uslužno-orijentirana komunikacija temelji na razmjeni poruka. Bitno je uočiti jasnu
granicu oko svage usluge u raspodijeljenom sustavu. Tu granicu upravo čini javno sučelje svake
usluge koje je dostupno svima i putem javnog sučelja se šalju i primaju poruke. Iza granice tj. iza
javnog sučelja je skrivena implementacija usluge i korisnici usluge ne znaju, niti trebaju znati išta o
64
implementaciji usluge. Sve što im je potrebno je javno sučelje. U javnom sučelju su definirani modeli
podataka koji se mogu razmjenjivati s uslugom, oblici poruka itd. Iako ovakav opis podsjeća na
objektnu orijentaciju i koncept enkapsulacije to ipak nije tako. U objektno orijentiranom
raspodijeljenom sustavu i dalje postoji enkapsulacija na razini razreda i objekata, no ne postoji
enkapsulacija na razini usluga. Upravo tu enkapsulaciju ostvaruje uslužna orijentacija. Enkapsulacija
na razini usluga donosi prednosti koje postoje i kod razreda. Korištenje usluge postaje potpuno
neovisno o njezinoj implementaciji. Ipak treba voditi računa o razumnom korištenju i pozivanju usluga
jer svako pozivanje usluge donosi neki trošak u pogledu performansi, suvišne komunikacije itd.
Autonomija usluga je vrlo bitan koncept koji omogućava robustnost sustava i otpornost na promjene
koje su neizbježne tijekom vremena. U sustav mogu ući nove usluge, mogu se mijenjati
implementacije pojedinih usluga, verzije usluga i drugi elementi koji ne smiju poremetiti rad sustava.
Obzirom da se komunikacija izmeñu usluga u raspodijeljenom sustavu temelji na porukama te da su
usluge meñusobno neovisne, nije potrebno razmjenjivati razrede i hijerarhije razreda. Ono što može
zanimati korisnika usluge je javno sučelje koje ta usluga ima. Obzirom da se sučelje uvijek sastoji od
funkcionalnosti koje nudi usluga te od podataka koji se mogu razmjenjivati s uslugom, dovoljno je da
usluge meñusobno mogu razmjenjivati modele podataka što omogućava razmjenu konkretnih
podataka kod korištenja usluge. Osim modela podataka (eng. schema) koji opisuju podatke, svaka
usluga posjeduje i ugovor (eng. policy) kojim se opisuje ponašanje usluge.
Upravo ugovori definiraju na koji način se može koristiti pojedina usluga tj. njezina funkcionalnost.
Ugovori omogućavaju različite kombinacije u pogledu naplate usluge i sl. Ugovor zapravo razdvaja
punu funkcionalnost usluge od funkcionalnosti dostupne pojedinim korisnicima. Neki korisnici mogu
koristiti više, a neki manje funkcionalnosti iste usluge.
Sveukupno gledano uslužna orijentacija i slaba povezanost donose sljedeće pozitivne pomake u
razvoju raspodijeljenih sustava temeljenih na uslugama:
-Autonomnost usluga – promjene u implementaciji usluge, uz nepromijenjeno sučelje, nemaju
učinka na korištenje usluge od strane korisnika. Korisnici ne smiju biti ovisni o implementaciji
usluge.
-Neovisnost o prijenosnom protokolu, formatu podataka, programskom jeziku i operacijskom
sustavu
-Skalabilnost
-Dostupna funkcionalnost je definirana ugovorom
Dakle, arhitektura zasnovana na uslugama je svaka arhitektura raspodijeljenog sustava izgrañenog
prema principima uslužne orijentacije. To znači sustav temeljen na slabo povezanima autonomnim
uslugama opisanih javnim sučeljem i javnim ugovorima.
65
3.1.2. Windows Communication Foundation (WCF)
Windows Communication Foundation (Indigo) je Microsoftov okvir za razvoj, namijenjen primarno
razvoju uslužno-orijentiranih aplikacija i sustava. Microsoft je u okviru .NET frameworka 2.0 podržao
razvoj Web usluga, te osim toga bio je omogućen razvoj aplikacija temeljenih na .NET Remotingu,
primjeni transakcija itd. WCF objedinjuje prethodne tehnologije za razvoj raspodijeljenih sustava kao
što su Web usluge, Remoting u jedinstveni okvir za razvoj. Pritom je razvoj softvera primarno okrenut
prema razvoju usluga.
WCF je općenitija, šira tehnologija za razvoj koja meñu ostalim omogućava i razvoj Web usluga. To ne
znači da su WCF aplikacije i ASP.NET Web usluge nekompatibilne. WCF aplikacije mogu normalno
komunicirati s ASP.NET Web uslugama i klijentima. Iako su obje vrste aplikacija kompatibilne, postoje
razrañeni postupci migracije na WCF s ASP.NET okvira.
ASP.NET
ASMX
.NET
Remoting
Enterprise
Services
WSE
MSMQ
WCF
Web usluge neovisne o
platformi, jeziku, os-u....
.NET - .NET komunikacija
Transakcije
WS-*
Redovi poruka
Jedna od osnovnih razlika izmeñu Web usluga i WCF usluga je transportni protokol koji se koristi za
prijenos poruka. U slučaju ASP.NET Web usluga, poruke se prenose primjenom protokola HTTP, dok
WCF to proširuje i podržava niz drugih protokola kao što su TCP, MSMQ itd. Osim toga, u WCF okviru
je mnogo bolje integrirana podrška za ostvarenje sigurnosti, transakcija, pouzdanosti i drugih
specifikacija (WS-*) i svojstava komunikacije koje su u slučaju Web usluga bile dostupne kroz WSE
dodatke. Kao i u slučaju ASP.NET Web usluga, XML se opsežno koristi za podatke i metapodatke te se
i dalje vrši serijalizacija izmeñu .NET objekata i XML poruka koje se razmjenjuju i obrnuto.
Tendencija jednostavnosti je nastavljena i u .NET 3.0 okviru tj. u njegovom modelu za razvoj usluga.
Kao i kod ASMX usluga, za potpunu funkcionalnost, dovoljno je korištenje nekolicine glavnih razreda
koji opisuju glavne elemente kao što su usluga, proxy, sučelje i slično.
WCF u osnovi omogućava tri načina razvoja usluga, što je takoñer djelomično nastavak na ASMX
usluge. Ti načini su:
-deklarativno programiranje primjenom atributa
-imperativno programiranje primjenom izvornog kôda, razreda i objekata
-programiranje temeljeno na konfiguracijskim datotekama
U razvoju tipične WCF usluge, koriste se sva tri načina programiranja za rješavanje odreñenog dijela
problema. Pritom se atributima definiraju ugovori i sučelja usluge, konfiguracijskim datotekama se
rješava pitanje sigurnosti, upravljanja itd., a u izvornom kôdu se implementira funkcionalnost usluge.
WCF je „fizički“ ostvaren kao skup asemblija „iznad“ .NET Frameworka 3.0. Ti asembliji sadrže tipove
koji čine WCF API sučelje.
66
Slika 3.3: WCF u kontekstu Windowsa i .NET Frameworka
U poglavljima koja slijede će se na praktičnim primjerima objasniti razvoj i struktura WCF usluga te
WCF klijenata.
3.2 WCF usluge
Analogno kao u slučaju ASMX usluga, WCF usluge se takoñer programski ostvaruju kao razredi u
nekom programskom jeziku podržanom u .NET-u. Detaljnije će biti analizirana struktura razreda koji
ostvaruje uslugu. Osim razreda, za usluge je bitno njihovo smještanje na odreñenom hostu tj.
domaćinu. I konačno bitno je omogućiti da klijenti na neki način mogu pristupiti tom razredu tj. usluzi
smještenoj na domaćinu.
Slika 3.4: Osnovna struktura WCF usluge
Sva komunikacija s uslugom se odvija putem pristupnih točaka. U svakoj pristupnoj točki je definirano
sučelje (eng. service contract) koje opisuje koje metode razreda su dostupne u toj točki, zatim
uvezivanje (eng. binding) koje opisuje na koji način klijent može komunicirati s tom pristupnom
točkom, te konačno adresa koja definira lokaciju usluge.
Razred koji ostvaruje WCF uslugu je razred kao i svaki drugi, uz dodatak da omogućava definiranje
tzv. sučelja (eng. service contract) koja opisuju dostupnu funkcionalnost usluge. Svaki razred može
imati jedno ili više sučelja. Za definiranje sučelja, potrebno je znati koje metode razreda trebaju biti
dostupne klijentima, a koje ne. Problem oko integriranja takvih detalja u programski kôd je riješen
primjenom .NET atributa. Atributi su najobičniji nizovi znakova koji se pojavljuju na različitim
67
mjestima, npr. prije definicije razreda, prije definicije metode i sl. Atributi mogu imati svojstva i
zapravo mijenjaju ponašanje objekta kojem su pridruženi.
Definiranje razreda i sučelja usluge
Razred usluge je razred (class) bilo kojeg programskog jezika podržanog u .NET-u koji implementira
metode tj. operacije koje usluga nudi svojim korisnicima. Konceptualno ne postoje veće razlike u
odnosu na ASMX usluge. Svaki razred koji implementira WCF uslugu (nadalje: razred) mora
implementirati barem jedno ili više sučelja usluge (service contract). Sučelja usluge opisuju metode tj.
operacije koje usluga nudi svojim korisnicima. Osim sučelja usluge u razredu se može definirati i
sučelje podataka koje opisuje tipove podataka koji se mogu razmjenjivati s uslugom. Analogno
definiranju Web metoda u ASMX uslugama, u WCF uslugama se za definiranje javnih sučelja koriste
atributi.
Temeljni atribut je ServiceContract atribut (System.ServiceModel prostor imena) koji služi za
definiranje nekog razreda kao WCF usluge što implicitno definira javno sučelje usluge.
Atribut OperationContract služi za definiranje neke metode u razredu kao javne metode. To znači da
sve metode označene ovim atributom postanu javno „izložene“ i može im se pristupiti SOAP
porukama. Analogno kao i kod ASMX usluga, metode koje nisu označene tim atributom, neće biti
javno dostupne.
Sljedeći primjer pokazuje dva osnovna načina za primjenu navedenih atributa.
using System.ServiceModel;
[ServiceContract]
class Studomat
{
[OperationContract]
private int PrijaviIspit(int StudID, int PredmetID)
{
return _KomBaza(0, StudID, PredmetID, ...);
}
[OperationContract]
public int OdjaviIspit(int StudID, int IspitID)
{
return _KomBaza(1, StudID, PredmetID, ...);
}
public int _KomBaza(int TipPosla, int StudID, int PredmetID, ...)
{
... ; return NoviIspitID;
}
}
Primjer 3.1.: Jedna varijanta korištenja atributa ServiceContract i OperationContract
U prethodnom primjeru je cijeli razred označen ServiceContract atributom, što znači da postoji samo
jedno moguće sučelje koje će se moći naći na pristupnim točkama, a to sučelje će činiti one metode iz
razreda koje su označene OperationContract atributom. Obzirom da može postojati više pristupnih
točaka koje se mogu razlikovati npr. po prijenosnom protokolu, sigurnosnim postavkama ili nekom
drugom parametru, u slučaju ovakvog razreda, na svim pristupnim točkama će biti dostupne iste
metode. Dodatno je korisno spomenuti da, kao što je prikazano u primjeru, ključne riječi public i
private ne čine razliku ako su metode označene kao javne.
68
Mnogo bolji način je prikazan u idućem primjeru gdje se primjenjuje koncept sučelja razreda
(interface) koje zatim nasljeñuje razred usluge. U ovom slučaju se pojedina sučelja razreda (interface)
označavaju ServiceContract atributima i glavni razred ih nasljeñuje, te nije potrebno dodatno i razred
označavati ServiceContract atributom. Jedna od glavnih prednosti koje donosi ovakav pristup je
mogućnost definiranja praktični beskonačnog broja sučelja razreda (interface) te korištenje različitih
interfacea na različitim pristupnim točkama.
[ServiceContract]
interface IStudent
{
[OperationContract]
int PrijaviIspit(int StudID, int PredmetID)
[OperationContract]
int OdjaviIspit(int StudID, int IspitID)
}
class Studomat : IStudent
{
private int PrijaviIspit(int StudID, int PredmetID)
{
return _KomBaza(0, StudID, PredmetID, ...);
}
public int OdjaviIspit(int StudID, int IspitID)
{
return _KomBaza(1, StudID, PredmetID, ...);
}
public int _KomBaza(int TipPosla, int StudID, int PredmetID, ...)
{
... ; return NoviIspitID;
}
}
Primjer 3.2.: Bolja varijanta korištenja atributa ServiceContract i OperationContract
Kada se razredi i metode označe navedenim atributima kao u prethodnim primjerima, to omogućava
automatsko generiranje WSDL opisa (što je opet analogno ASMX uslugama).
U prethodnim primjerima su korišteni najjednostavniji tipovi podataka. Pritom se zapravo implicitno
definiralo koji tipovi podataka se prenose jer zbog njihove jednostavnosti nije bila potrebna dodatna
definicija. No često je potrebno prenositi različite složene tipove podataka i u tom slučaju je potrebno
eksplicitno definirati podatke koji se prenose. Za to se koristi DataContract atribut i služi za definiranje
složenijih tipova podataka koji se prenose, te za definiranje na koji način se vrši serijalizacija iz .NET
objekata u oblik za prijenos nekim transportnim protokolom. Idući primjer demonstrira primjenu ovog
atributa.
[DataContract]
struct Student {
[DataMember] public string Name;
int public age;
[DataMember] private int ProsjekOcjena;
}
Primjer 3.3.: Korištenje DataContract i DataMember atributa
69
Atribut DataContract služi već opisanoj svrsi, dok atribut DataMember služi za definiranje članova
strukture koji se trebaju pojaviti u serijaliziranoj verziji .NET objekta. To konkretno znači da kad se
instanca ovakve strukture prenosi u nekoj metodi označenoj kao javnoj, ustvari se prenose samo
članovi označeni DataMember atributom.
Definiranje domaćina (hosta) usluge
Razred koji implementira WCF uslugu se najčešće prevodi u biblioteku te je potreban neki host gdje će
ta biblioteka biti dostupna potencijalnim korisnicima. Osnovni načini su:
-objava usluge u proizvoljnom procesu
-objava usluge kao Windows usluge (različito od WCF usluge)
-objava usluge primjenom IIS-a
-objava usluge primjenom WAS (Windows Activation Services) usluge, samo uz IIS 7.0 (Vista)
Iako je objava WCF usluge kao Windows usluge prilično jednostavna i rješava brojne probleme,
ponekad je poželjna fleksibilnost koju omogućava hostanje WCF usluge u nekom proizvoljnom
procesu. Za takve potrebe postoji razred ServiceHost koji omogućava vrlo jednostavno hostanje bilo
koje WCF usluge, što pokazuje sljedeći primjer.
using System.ServiceModel;
public class StudomatHost
{
public static void Main()
{
ServiceHost stud = new ServiceHost(typeof(Studomat));
stud.Open();
}
}
Primjer 3.4.: Hostanje WCF usluge u proizvoljnom procesu
Kod instanciranja ServiceHost razreda moguće je definirati baznu adresu usluge, što u prethodnom
primjeru nije učinjeno. Bazna adresa usluge, definirana ovdje, se uvijek spaja s adresom definiranom
u konfiguracijskoj datoteci usluge, a obzirom da bazna adresa u primjeru definirana, to znači da će se
koristiti isključivo adresa navedena u konfiguracijskog datoteci. Nakon poziva metode open(), WCF
runtime će automatski kreirati Listener objekt koji će zaprimati sve zahtjeve klijenata prema toj usluzi.
Definiranje pristupnih točaka
Ranije je spomenuto da je usluga dostupna klijentima u pristupnim točkama (endpoints). Broj
pristupnih točaka kojima se može pristupati jednoj usluzi nije ograničen. Takoñer je moguće da se u
svakoj pristupnoj točki pristupa drugom sučelju iste usluge tj. drugom skupu operacija usluge. Za
svaku pristupnu točku potrebno je definirati koje sučelje usluge (ServiceContract) je u toj točki
dostupno, koja je adresa te pristupne točke te koje uvezivanje (eng. binding) se primjenjuje za pristup
usluzi putem te pristupne točke. O sučeljima je već bilo govora kada se govorilo o definiranju razreda
usluge. Adresa pristupne točke je URL koji na jedinstven način indentificira pristupnu točku i
omogućava nedvosmislen pristup od strane pojedinog klijenta.
70
Vrlo bitna komponenta svake pristupne točke je uvezivanje (binding). Binding definira način na koji
klijent može pristupiti usluzi. To uključuje: prijenosni protokol, mehanizme za osiguravanje pozdanosti,
sigurnosne mehanizme itd. Npr. ako vlasnik usluge želi klijentima omogućiti pristup putem protokola
HTTP i protokola TCP, mora to ostvariti kroz dva različita bindinga tj. kroz dvije različite pristupne
točke. Iako se u obje točke pristupa istoj usluzi, koriste se različiti prijenosni protokoli. Svaki binding
čine elementi bindinga. Svaki pojedini element se odnosi na odreñenu funkcionalnost, npr. protokol,
pouzdanost, sigurnost itd. Kombiniranjem različitih elemenata se ostvaruje željeno konačno uvezivanje
tj. binding. Elementi koji su obavezni u svakom bindingu su element koji definiraju prijenosni protokol
i element koji definira kodiranje sadržaja poruke. Svaki binding element čini jedan kanal (channel).
Kod objave usluge WCF runtime slaže sve kanale konfigurirane za neku uslugu, u zajednički kanalni
stog (channel stack). Kanalni stog se takoñer stvara na strani klijenta kod pristupanja usluzi ali o tome
nešto više kasnije.
U standardnoj WCF biblioteci (System.ServiceModel.Channels prostor imena) postoji niz gotovih tipova
koji ostvaruju različite elemente bindinga. Npr:
-BinaryMessageEncodingBinaryElement koji ostvaruje binarno de/kodiranje XML poruka,
-AsymetricSecurityBindingElement koji ostvaruje asimetrično kriptiranje,
-HTTPSTransportBindingElement koji ostvaruje prijenos protokolom HTTP
-ReliableSessionBindingElement koji ostvaruje pouzdani prijenos poruka itd.
Iako postoji vrlo veliki broj kombinacija, zbog kompatibilnosti s klijentima treba imati na umu da samo
kanalni stog usluge koji se podudara s kanalnim stogom na strani klijenta osigurava ispravnu
komunikaciju, te takoñer treba voditi računa o tome da velik dio klijenata, a pogotovo ne-Windows
klijenti „ne razumiju“ sve elemente koji su možda dodani u kanalni stog usluge. WCF sadrži niz gotovih
bindinga koji se mogu koristiti kod razvoja usluga i klijenata, kao što su BasicHttpBinding,
WSHttpBinding, WSDualHttpBinding, WSFederationBinding itd.
Preostaje još vidjet na koji način se praktično koristi neki binding. Ukoliko se za hostanje usluge koristi
proizvoljna aplikacija tj. ServiceHost razred, tada se binding može instancirati u izvornom kôdu, na
temelju njega se može kreirati pristupna točka te se ta pristupna točka može dodati usluzi pomoću
AddServiceEndpoint metode koja pripada ServiceHost razredu. Bitno fleksibilniji način je primjena
konfiguracijske datoteke za definiranje pristupnih točaka, bindinga i drugih parametara. To pokazuje
idući primjer.
71
Primjer 3.5: Primjer definiranja jedne pristupne točke
3.3 WCF klijenti
Klijenti su korisnici usluga tj. operacija koje pružaju usluge. U općem slučaju klijenti WCF usluga (ni
drugih usluga) ne moraju biti WCF klijenti tj. klijenti programirani u .NET 3.0 okruženju no u ovom
slučaju se govori upravo o takvim klijentima.
Klijenti pristupaju usluzi putem pristupnih točaka koje su pojašnjene u prethodnom poglavlju. Svakoj
pristupnoj točki može pristupiti jedan ili više klijenata. Analogno kao kod ASMX usluga, za pristup
usluzi klijenti i dalje koriste koncept proxy objekta koji predstavlja uslugu na strani klijenta te obavlja
komunikaciju s samom uslugom za klijenta.
Klijenti su inicijatori komunikacije te u najvećem broju slučajeva klijenti pokreću sve procese u
uslužno-orijentiranim sustavima. Jasno je da i same usluge mogu biti klijenti drugih usluga, što
praktično znači da se programski kôd pozivanja usluge može nalaziti i u samim uslugama.
72
Slika 3.5: Pristup klijenta usluzi
Obzirom da se komunikacija odvija putem proxy objekta, upravo proxy objekt otvara kanal za
komunikaciju s uslugom koji je analogan kanalu o kojem je bilo govora kod izgradnje usluge.
Slaganjem kanala u podudarni kanalni stog s obje strane omogućava se komunikacija izmeñu usluge i
klijenta. Klijent koristi operacije usluge na način da poziva javne metode usluge. Sam proxy objekt koji
predstavlja neku uslugu se u klijentu može dobiti na više načina, a najčešći način je automatsko
generiranje iz metapodataka usluge tj. WSDL opisa usluge.
Klijent i usluga komuniciraju razmjenom poruka. U komunikaciji s WCF uslugama postoji nekoliko
osnovnih modela razmjene poruka, kao što su: datagramska komunikacija, zahtjev-odgovor
komunikacija i duplex komunikacija. Kod datagramske komunikacije klijent šalje usluzi poruku i ne
očekuje odgovor. Komunikacija zahtjev-odgovor se primjenjuje kada usluga na primljeni zahtjev treba
odgovoriti nekim odgovorom. Duplex komunikacija se koristi kod složenijih modela komunikacije
izmeñu klijenta i usluge.
Slika 3.6: Osnovni modeli razmjene poruka
73
Kod razvoja klijenta potrebno je prije svega generirati proxy razred za pristup usluzi. To se može
učiniti na dva načina. Jedno je instanciranje proxy razreda dobivenog svcutil alatom, iz metaopisa
usluge. Drugi način je primjena ChannelFactory razreda za „ručno“ instanciranje kanala za slanje
poruke.
Proxy klasa koju se generira iz metaopisa usluge ima isto ime kao i usluga, s sufiksom „proxy“. U
programskog kôdu klijenta potrebno je jednostavno instancirati proxy klasu te pozivati metode usluge.
U konstruktoru proxy klase može se definirati pristupna točka i uvezivanje usluge kojoj se pristupa.
EndpointAddress address =
new EndpointAddress("http://localhost:8000/Studomat/");
BasicProfileBinding binding = new BasicProfileBinding();
StudomatProxy proxy = new StudomatProxy(address, binding);
proxy.PrijaviIspit();
proxy.Close();
Primjer 3.5. : Instanciranje proxy klase i korištenje operacija usluge
Postavlja se pitanje na koji način se generira proxy razred kao ovaj korišten u prethodnom primjeru.
To je moguće ostvariti na nekoliko načina no uvijek se koristi svcutil alat. Najčešća mogućnost je
generiranje proxy razreda na temelju adrese usluge. Svcutil pristupa adresi i dohvaća potrebne
metapodatke za generiranje proxy razreda.
svcutil http://localhost:8000/Studomat/
Primjer 3.6. : Generiranje proxy klase iz adrese usluge
Druga mogućnost je generiranje proxy klase iz asemblija same usluge, što i nije često dostupno. U
slučaju da je dostupno taj proces se odvija u dva koraka. U prvom koraku se svcutil alatom na temelju
asemblija generira metaopis usluge, a u drugom koraku se istim alatom na temelju tog opisa generira
proxy razred.
svcutil Studomat.dll
svcutil *.wsdl *.xsd
Primjer 3.7. : Generiranje proxy klase iz asemblija usluge
74
REFERENCE
[1]
W3C - World Wide Web Consortium
[2]
W3C: Web Services Architecture, 2004.
[3]
W3C: Extensible Markup Language (XML) 1.0, 2004.
[4]
W3C: SOAP Version 1.2 Part 0: Primer, 2003.
[5]
W3C: Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, 2006.
[6]
OASIS - Organization for the Advancement of Structured Information Standards
[7]
Ivana Kuzle: XML početnica, FER RASIP, 2004.
[8]
Anura Guruge: Web services theory and practice, Digital Press, 2004.
[9]
Erik T. Ray: Learning XML, O'Reilly, 2003.
[10]
Tomičić, Žarković, Rebernik: Arhitektura temeljena na servisima, FOI, 2006.
[11]
Scott Short: Building XML Web services for the Microsoft .NET platform, MSPress, 2002.
[12]
Matthew MacDonald: Microsoft .NET Distributed Applications: Integrating XML Web Services
and .NET Remoting, MSPress, 2003.
[13]
Eric Newcomer: Understanding Web Services; XML, WSDL, SOAP and UDDI, AWesley, 2002.
[14]
Auditorne vježbe iz kolegija Programske paradigme i jezici, FER, 2006.
[15]
Matthew MacDonald: Beginning ASP.NET 2.0 in C#, APress, 2006.
[16]
John Sharp: Microsoft Windows Communication Foundation Step by Step, Microsoft Press,
2007.
[17]
Justin Smith: Inside Microsoft Windows Communication Foundation, Microsoft Press, 2007.
[18]
David Pallmann, Programming Indigo BETA EDITION, Microsoft Press, 2005.
75

"[Kliknite ovdje i unesite ime]"

Uvjeti korištenja

Štovani potrošaču,

Ugovor za krajnjeg korisnika

formatu

PRAVA PACIJENATA

REGISTAR ZAPOSLENIH JAVNOM SEKTORU

null

Kamilo Antolović: Verbalno u oglasnim porukama

I. Kolaković - Priprema meča i faza brejk poena

XML zadaci - FON Forum