Elektronski fakultet u Niu,

Katedra za raunarstvo

Java Web Servisi

Student:
Miroslav Naumovski 12999

Datum: 6.5.2011.

Prvi deo Uvod u XML

ta je XML?

XML je skradenica od EXtensible Markup Language

XML je jezik slian HTML
XML je zamiljen i projektovan da PRENOSI podatke, a ne da ih prikazuje
XML Ne postoje predefinisani tagovi u XML-u.Morate praviti svoje tagove
XML je pravljen da bude self-descriptive da opisuje sam sebe

Razlike izmedju XML i HTML

1. XML nije zamena za HTML.
2. XML i HTML su projektovani sa razliitim ciljevima:

XML je projektovan da prenosi i uva podatke, i fokusira se na to STA su ti podaci

HTML jep rojektovan da prikazuje podatke,fokusirajudi se na to kako podaci
IZGLEDAJU

Znai u HTML-u je sve u prikazu informacija, dok se XML odnosi na prenos informacija.

XML NE RADI nita

Malo je teko za razumeti, ali XML u stvari ne radi nita. XML jek kreiran s ciljem da se
struktuiraju, snimaju i prenose informacije.
Ovo je primer poruke od jedne osobe drugoj,snimljena kao XML:
<beleska>
<kome>Bog licno</kome>
<od>Miroslav</od>
<zaglavlje>Obavestenje</zaglavlje>
<telo>I love elfak in poslednje vreme...</telo>
</beleska>
Ova poruka opisuje samu sebe. Ima svog posiljaoca, primaoca, takodje ima zaglavlje i telo
poruke.
Ali i dalje, ovaj XML dokument NE RADI nista. To je samo parce informacije umotano u
tagove. Zato neko mora da napise softver kako bi se ta informacija slala, primala ili
prikazivala.

Sa XML-om kreramo svoje sopstvene tagove

Tagovi koje sam koristio gore nisu predvidjeni nikakvim XML standardom.Njih sam kreirao ja
kao autor XML dokumenta.Ovo je zato sto kako rekosmo XML nema predefinisane tagove.
XML omogucava autoru da sam kreira svoje tagove i strukturu dokumenta.
Za razliku od njega HTML koristi striktno definisane tagove.
Znaci zakljucak je da je XML softverski i hardverski nezavisan alat za prenos informacija.

Drugi deo Web servisi,opte

Sta su web servisi?

Web servisi su aplikacije

Komuniciraju kroz otvorene protokole
Web servisi su samostalni i opisuju sami sebe
Web servisi se mogu otkriti kroz UDDI
Web servisi se mogu koristiti od strane drugih aplikacija
XML je osnova za web servise

Kako radi?
Osnovna platforma za web servise je XML + HTTP.
XML je jezik koji se moze koristiti izmedju razlicitih platformi i programskih jezika a da ipak
prenese slozene poruke i funkcije.
Elementi platforme web servisa:

SOAP (Simple Object Access Protocol)

UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)

Razliite platforme
Razlicite platforme pristupaju webu koriscenjem web pretrazivaca, takoda bi one trebale da
mogu na neki nacin da saradjuju. E kako bi mogle da sarauju, napravljene su web aplikacije.
Web aplikacije su male aplikacije koje se pokredu na webu. Napravljene su po standardima
web pretrazivaca imogu se koristiti na bilo kom pretrazivacu ili platformi.

Web Servisi izdizu Web aplikacije na veci nivo

Koriscenjem web servisa web aplikacija moze da podeli funkciju ili poruku sa ostatkom
sveta.
Web servisi koriste XML da kodiraju i dekodiraju podatke, i SOAP protokol da ih
prenesu(koriscenjem otvorenih protokola).
Pomocu web servisa, mozemo na primer da povezemo dva servera koji rade pod razlicitim
operativnim sistemima.

Web Services se koriste u 2 svrhe

Ponovno koriscenje aplikacijskih komponenti.
Postoje stvari koje najcesce trebaju aplikacijama. Zasto ih praviti ponovo?
Web aplikacije mogu ponuditi gotove aplikacijske komponente kao sto su: konverzija valute,
vremenski izvestaji, ili usluge prevoda na primer.
Povezivanje postojeceg softvera.
Web services pomazu da se resi problem interoperabilnosti davanjem mogucnosti razlicitim
aplikacijama da povezu svoje podatke.
Sa web servisima mozemo razmenjivati podatke sa razlicitim aplikacijama i platformama.
Web Servisi imaju tri razlicita elementa platforme: SOAP, WSDL i UDDI.

Sta je SOAP?
To je protokol bazira na XML-u napravljen da omoguci aplikacijama da razmene podatke
preko HTTP-a.
Ili prostije: SOAP je protokol za pristupanje Web Servisu.

SOAP je skracenica od Simple Object Access Protocol

SOAP je komunikacioni protokol
SOAP je format za slanje poruka
SOAP je projektovan da radi preko interneta
SOAP je nezavisan od platforme
SOAP je nezavisan od programskog jezika
SOAP je baziran na XML-u
SOAP je prost i lako se nadogradjuje
SOAP omogucava prolazak kroz firewallove

ta je WSDL?
WSDL je je jezik baziran na XML-u a sluzi za lociranje i opis Web servisa.Opisuje interfejs
web servisa.

WSDL je skracenica od Web Services Description Language

WSDL je baziran na XML - u
WSDL se koristi za opis Web servisa
WSDL se koristi za lociranje Web servisa

ta je UDDI?
UDDI je servis gde kompanije mogu da prijave(registruju) ili traze Web servise.

UDDI je skraceno od Universal Description, Discovery and Integration

UDDI je direktorijum za snimanje informacija o Web servisima
UDDI je direkorijum interfejsa web servisa opisanih u WSDL-u
UDDI komunicirapreko SOAP-a
UDDI ugradjen je u .NET platformu

Jo neto o web servisima

Web servisi su set alat koji se moze koristiti na vise razlicitih nacina. Tri najcesca nacina koriscenja
web servisa su RPC, SOA i REST.
Remote procedure calls

RPC Web servisi predstavljaju interfejs poziva distribuirane funkcije(ili metoda) koji je slican
kod mnogih proizvodjaca softvera. U stvari osnovna jedinica RPC Web servisa je WSDL
operacija.A rekosmo da se WSDL odnosi na opis interfejsa web servisa.
Prvi web servisi su bili fokusirani na RPC-u,i kao rezultat, ovaj stil je siroko rasprostranjen i
koriscen. Medjutim ovaj metod je cesto kritikovan jer nije loseley coupled . Loseley coupled
je sistem cija svaka komponenta zna jako malo, ili ne zna uopste o drugim komponentama.
Drugi prilazi sa priblizno istom funkcionalnoscu kao RPC su Object Management Group
(OMG) Common Object Request Broker Architecture (CORBA), Microsoft-ov Distributed
Component Object Model (DCOM) ili Sun Microsystems Java/Remote Method Invocation
(RMI).

Service-oriented arhitektura
Web servisi se takodje mogu upotrebiti da se implementira arhitektura u skladu sa serviceoriented architecture (SOA) konceprima, gde je osnovna jedinica komunikacije poruka, a ne
operacija. U ovom slucaju se servisi cesto nazivaju porukama-orijentisani.
SOA Web servisi su podrzani od strane vecine proizvodjaca softvera. Za razliku od RPC Web
servisa, loose coupling je prisutan, zato sto je akcenat bacen na "ugovor" koji WSDL
obezbedjuje,umesto na pozadinske implementacione detalje.

Representational state transfer (REST)

REST pokusava da opise arhitekture koje koriste HTTP ili slicne protokole ogranicavanjem
svog interfejsa na set dobro poznatih, standardnih operacija(kao sto su GET, POST, PUT,
DELETE kod HTTP-a). Ovde, fokus je bacen na interagovanje resursima okruzenja, umesto na
poruke ili operacije.

Arhitektura bazirana na REST-u moze da koristi WSDL da opise SOAP slanje poruka preko
HTTP-a, moze biti implementirana kao apstrakcija SOAP-a (kao sloj iznad), ili moze da uopste
i ne koristi SOAP.

Jo neto o SOAP protokolu

SOAP je protokol baziran na XML-u i sluzi za messaging, znaci prosledjivanje poruka.Sastoji
se od pravila za struktuiranje poruka koje se mogu koristiti za jednosmerno slanje poruka, ali
se cesto koristi kada se web servisi koriste u RPC(Remote procedure call) stilu.Nije vezan za
nijedan specifican protokol, mada se najvise koristi sa HTTP-om.Nije vezan za nijedan
programski jezik ili operativni sistem, tako da teoretski, klijentske i serverske masine mogu
da budu pokrenute na bilo kojoj platformi, i na bilo kom jeziku,dok god mogu da oforme i
razumeju SOAP poruke.
Primer:Zamislimo da imamo malu bazu podataka koja sadrzi tabelu sa podacima o
zaposlenima.I sad zelimo da napravimo web servis koji ce drugim sistemima u kompaniji da
omoguci pretragu ovih podataka.Servis bi recimo trebao da vrati ime i broj telefona
zaposlenog(niz od 2 stringa) kada se unese referentni broj zaposlenog (integer). U javi bi
prototip servisa izgledao ovako:
String[] getEmployeeDetails ( int employeeNumber );
Ideja ja da logiku za pristup i zahteve databazi naseg servisa enkapsuliramo u u jednoj
metodi pisane u ma kom prog jeziku.Onda postavimo proces koji ce slusati zahteve
upucene ka servisu.Takvi zahtevi su u SOAP formatu, i oni sadrze u sebi ime servisa i
zahtevane parametre.Sada listener proces obradjuje i dekodira SOAP zahtev, i transformise
ga u poziv funkcije.Kada funkcja vrati rezultat, on ponovo to kodira u SOAP poruku(odgovor)
i vraca je natrag pozivaocu.Prakticno ovo je koncept:

Jo neto o WSDL-u
WSDL je skradeno od Web Services Description Language.
WSDL je dokument pisan u XML-u. Ovakav jedan dokument opisuje web servis. Definise
lokaciju servisa i operacije(ili metode) koje servis nudi.

Definise format poruka zahteva i poruka odgovora koje klijent salje odnosno prima od
servisa. Poruke zahteva i poruke odgovora definisu imena i tipove podataka koje klijent
razmenjuje sa operacijom.
Klijentski program cita WSDL kako bi utvrdio koje funkcije su dostupne na serveru. Bilo koji
specificni tipovi podataka koji se koriste ugradjeni su u WSDL fajl u formatu XML Schema. A
klijent koristi SOAP kako bi zapravo pozvao neku od funkcija definisanih u WSDL-u.
WSDL je celina UDDI-ja, svetskog podlovnog registra baziranog na XML-u.Mozemo reci da je
WSDL jezik koji UDDI koristi.Razvijen je od strane Microsofta i IBM-a.

Jos malo o UDDI-ju

UDDI (Universal Description, Discovery, and Integration) je registar baziran na XML-u za
kompanije sirom sveta koje pruzaju web servise. Njegov primarni cilj je da poveze
kompanije,omoguci online transakcije ,tj da kompanije pronadju jedna drugu na internetu, i
mogu interoperabilno elektronski da posluju. UDDI se cesto uporedjuje za telefonskim
imenikom.Omogucava da se kompanije vide po imenu, proizvodu,lokaciji, ili web servisima
koje nude.

Gde je tu Java???
Java je samo na pocetku imala neke bazicne funkcionalnosti za Web Servise.Prve verzije Java
web servisa su bile
JAX-RPC 1.0
J2EE 1.4 koja je sadrzala JAX-RPC 1.1
Najnovija verzija Java servisa je Java EE 6 koja je programerima mnogo laksa, jer je laksa za
pravljenje enterprise klasnih aplikacija.
Java web servisi se baziraju na sledecim standardima:
-

JAX-WS : Java API za servise bazirane na XML-u.Naslednik JAX-RPC-a, omogucava razvoj i

koriscenje web servisa sa Javom.
JAXB Java Architecture for XML Binding. Tesno povezan za JAX-om JAXB standard
kontrolise kako su Java objekti predstavljeni u XML-u.
WS-Metadata Web Services Metadata za Java platformu.WS-Metadata obezbedjuje
zapise koji doprinose fleksibilnoj definiciji i koriscenju Web Servisa
WSEE Web Services for Java EE.Definise model programiranja i run-time ponasanje
Web Servisa u Java EE kontejneru

Service-Oriented Arhitektura sa Java Web servisima

Moderne Java aplikacije moraju da podrze principe servisno orijentisane
arhitekture.Osnova vecine SOA aplikacija su web servisi.Takodje, JWS standardi su veoma

bitni.Oni su osnova SOA razvoja sa Java EE.A loosley coupled SOA aplikacije su bitne zbog
toga sto omogucavaju da poslovni procesi budu fleksibilni.
Vecina kompleksnosti i zabune koje dozivljavaju softver inzenjeri pri radu sa JAX-WS se
odnose na to kako se JAX-WS/JAXB-generisane klase koje su kreirane JAX-WS WSDL
kompajlerom mapiraju u XML poruke definisane u WSDL-u.

Web Services Platform Architecture (WSPA)

Platforma web servisa je set alata za pozivanje i razvoj web servisa koriscenjem odredjenog
programskog jezika.Platforma ima server-side i client-side komponente.Server side
komponente se obicno pakuju u nekakkvu vrstu kontejnera( Na primer Java EE aplikacioni
server).Client-side komponente su obicno pakovane kao set alata za pristupanje instancama
Java interfejsa koje omotavaju neki web servis.Bilo koja web servis platforma mora da ima 3
sastavna dela svog core-a:Invocation(pozivanje), Serialization(serijalizacija) i
Deployment(uposljavanje).

Invokacija
Postoje invocation mehanizmi i na klijent i na server strani.Na server strani, invocation
mehanizmi su odgovorni za:
1. Primanje SOAP poruke iz transporta (na primer sa HTTP-a)
2. Pozivanje handlera koji vrse predobradu poruke(na primer kako bi se odrzala poruka
iz bezbednosnih razloga ili obradilo SOAP zaglavlje)
3. Odredjivanje servisa kome je poruka namenjena, drugim recima, koju WSDL operaciju
funkcija treba da pozove.
4. Posto je detektovan target operacija,odredjivanje koja Java klasa/metod treba da se
pozove.Ovo zovemo Java target.Odredjivanje Java terget-a se takodje zove dispatching
5. Prosledjivanje SOAP poruke serijalizacionom podsistemu kako bi je deserijalizovao u
Java objekte koji se mogu proslediti Java targetu kao parametri.
6. Pozivanje(invoking) Java targeta koriscenjem parametara generisanih Serijalizacionim
podsistemom i generisanje Java objekta koji target metod vraca.
7. Prosledjivanje objekta koji je funkcija vratila Serijalizacionom podsistemu kako bi ga
serijalizovao u XML element u skladu sa WSDL-om
8. Omotavanje tog XML elementa kao SOAP odgovora ponovo u skladu za WSDL-om
9. Pustanje SOAP odgovora nazad na transport za isporuku
U svakom stadijumu ovog procesa moze da se desi izuzetak.Kada se on desi , invocation
podsistem pravi specjalnu SOAP fault poruku koju vraca klijentu.Jedan deo kompleksnosti
sistema potice od toga sto mora da podrzi SOAP.
Na klijent strani, invokacioni proces je slican ukoliko zelite da pozovete web servis
koriscenjem Java interfejsa.Sve zavisi od problema koji resavamo.Ako klijent radi sa XMLom lakse je samo napraviti SOAP poruku i proslediti je web servisu.S druge strane, ako

klijent radi sa Java objektima, kako JWS pretpostavlja, na scenu stupa client-side invocation
system, koji je odgovoran za:
Client-Side pozivanje(invocation)
1. Kreiranje instance web servis endpoint-a(krajnje tacke) koja implementira Java interfejs
koji se u skladu sa JWS terminologijom naziva service endpoint
interface(SEI).Invocation sistem ima jednu ili vise fabrika za kreiranje SEI instanci.Ove
instance se ili kreiraju u letu ili imse pristupa koriscenjem JNDI-ja(Java naming and
directory interface).Obicno se SEI instance implementiraju koriscenjem Java proksija ili
invocation handlera.
2. Pozivanje SEI instance
3. Uzimanje parametara prosledjenih SEI-ju i njihovo slanje serializacionom podsistemu
gde se serijalizuju u XML elemente u skladu sa XML semom definisanom WSDL-om
target servisa
4. Omotavanje parametara u SOAP poruku u skladu sa WSDL-om.
5. Pozivanje handlera koji post-procesiraju poruku( na primer za podesavanje SOAP
zaglavlja)
6. Predaja poruke transportu za isporuku na target web servis
7. Primanje SOAP poruke sa odgovorom iz transporta
8. Prosledjivanje SOAP poruke serijalizacionim sistemu kako bi je deserijalizovao u Java
objekat koji je instanca klase koja se poklapa sa povratnim tipom SEI-ja(service endpoint
interfejsa koji u stvari vrace konacni rezultat.ja to zamisljam kao pravi interfejs ka na
primer korisniku na toj strani)
9. Kompletiranje poziva SEI-ja vracanjem deserijalizovanog SOAP odgovora.
Generalno proces pozivanja na klijent strani je obrnut od pozivanja na serveru.Na server
strani, sistem pozivanja povezuje Java metod sa proxy soap operacijom definisanu WSDLom.Izvrsava WSDL operaciju pozivanjem Java metoda.Obrnuto, na klijent strani sistem
pozivanja povezuje WSDL definisanu SOAP operaciju sa proxy Java iterfejsom.
Zanimljiva stvar je sto je samo srednji deo slike 1.1 SOAP zahtev/odgo
vor, i on je definisan WSDL-om.Pozivi Java metoda na svakoj strani su proizvoljni iz
perspektive Web servisa.U stvari mozemo da imamo potpis jednog Java metoda na klijent
strani, i TOTALNO drugaciji potpis metoda na server strani.U vecini slucajeva i jeste tako, i
koriste se razliciti programski jezici.JEr ukoliko bi obe strane radile sa istim Java
bibliotekama klasa, invokacija bi mogla da se odradi preko Java RMI(Remote procedure
invocation).

Serijalizacija
Je proces transformisanja primerka Java klase u XML element.Obrnuti proces se naziva
deserijalizacija.Serijalizacija je najvazinija komponenta na bilo kojoj platformi za Java web
servise.Hostovani unutar web servis kontejnera, mogu se nalaziti vise SOAP end-point-ova
gde svaki odgovara grupi web servisa.Endpoint ima asocirani WSDL interfejs koji definise
operacije.Endpointovi su apstrakcija za web servis,nacin na koji klijent vidi web servis. U
stvari, mi imamo neki web servis.Ali on u stvari pruza vise usluga.Te usluge nam obavljaju
neke funkcije, koje pak imaju svoj potpis definisan u WSDL-u.
Sledeca slika oslikava Java interfejs sa jedne i WSDL interfejs sa druge strane.U WSDL
interfejsu imamo elemenat(tag) pod nazivom <types>.Ovaj element sadrzi XML Schema
definicije tipova podataka koji se koriste u web servisima opisanim u ostatku tog WSDL
dokumenta.

Isecak prikazuje definicuju elementa pod nazivom customerPurchase.Kvalifikovano ime za

ovaj elemennt je wrapper:customerPurchase.Kao sto vidimo ovaj elemenat se koristi kao
jedan deo definicije poruke za onCustomerPurchase.Iduci nanize vidimo portType imenovan
kao CustomerPurchase definisan unutar operacije processCustomerPurchase koja koristi
onCustomerPurchase kao ulaz.Odatle ovaj isecak definise Web servis
processCustomerService koji kao ulaznu poruku zahteva jednu instancu elementa
wrapper:customerPurchase.Pozivanje ovog web servisa stoga, zahteva instanciranje
wrapper:customerPurchase.Primetimo da je za definiciju wrapper:customerPurchase u
WSDL odeljku potrebno da se importuju 2 elementa imported:customer i imported:po.Ovi
elementi su ubaceni negde u WSDL(importovani) sto sad nije bitno.Tako da su nam je za
pravljenje SOAP poruke potrebne 2 instance imported:customer i imported:po.
E sad pogledajmo kod sa leve strane.Vidimo da su importovane 2 klase.One se koriste kao
parametarske za metod newPurchase.Web Service Proxy prikazan na slici POVEZUJE

(binduje) Java interfejs metod sa WSDL operacijom processCustomerPurchase.Proxy je

kreiran sistemom pozivanja.On poziva WSDL operaciju razvijenu na SOAP endpointu
slanjem SOAP poruke.Tako da implementacija proksija na web servisu mora da pozove
nekakav sistem koji uzima instance com.sales.Customer i
com.soabook.purchasing.PurchaseOrder i kreira instancu wrapper:customerPurchase koja
se moze ugraditi u telo SOAP poruke.E tu stupa na scenu serijalizacioni sistem.
Uloga serijalizacionog sistema tokom pozivanja
1. Primanje parametara od web service proksija
2. Serijalizovanje oba dva parametara(cust i po ) klase
3. Kombinovanje ova dva elementa i njihovo umotavanje u wrapper klasu
wrappper:customerPurchase;
4. Predaja instance wrapper klase Web Service proksiju kako bi se ugradila u SOAP poruku
i poslala na SOAP endpoint
Znaci web proxy prosledi parametre za serijalizaciju sistemu za serijalzaciju, on ih
serijalizuje, umota u jedan wrapper i vrati proxiju, koji zatim salje SOAP endpoint-u kao
SOAP poruku.
Serijalizacioni podsistem prevodi parametre(prosledjene interfejs proksiju) sa instanci
njihovih Java klasa u instance zeljene XML Schem-e.U ovom zlucaju, target je
wrapper:customerPurchase.Ova preslikavanja iz Java klasa u XML Sematske komponente se
nazivaju mapiranje tipova ili type mapping.Kako bi obavio ovaj prelaz, serializacioni
modul mora da primeni neku strategiju mapiranja, koja govori kako se instance Java klasa
prevode u XML komponente.Maping strategija povezuje Java klasu sa njenim XML-Sema
tipom, i opisom serializera(ili deserijalizera) koji moze da instance klase transformise u XML i
obrnuto.Serializacioni kontekst je set strategija mapiranja koje serijalizacioni sistem moze
koristiti da implementira preslikavanja tipova koriscenih u odredjenom web servisu.
Neki od mehanizama mapiranja:
-

Standard binding: Standardno preslikavanje koje je predvidjeno JAXB i JAX-WS

standardima.Preslikavanja su predefinisana standardnim bind-ovanjem Java klasa u XML
Seme
Source code annotations: JWS koristi ovaj prilaz kako bi obezbedio izmene ne vrhu
standardnog bind-a.Anotacije u izvornom kodu zeljene Java klase modifikuju standardno
preslikavanje i tako definisu izmenjen nacin za preslikavanje
Algoritamsko:Mapiranja su ugradjena u algoritme koje izvrsava serijalizacioni podsistem
Rule-based: Zasnovano na pravilima.Mapiranja su definisana kao pravila koja se mogu
kreirati i editovati nezavisno od serijalizacionog posistema.

Svaki od ovih metoda ima svoje prednosti i mane.Kao dodatak, JWS je obezbedio anotacioni
mehanizam kako bi olaksao programerima da definisu kako se Java tergeti serijalizuju.

Razvoj (Deployment)
Sistem razvoja obezbedjuje alate za podesavalje Java target-a kako bi on bio pozvan kao
web servis putem SOAP poruka.
Odgovornosti sistema razvoja:
-

Razvoj Java targeta Zavisi od kontejnera gde poziv nastane.Moze da oznaci samo
pravljenje klasnih definicija Java tergeta dostupnim class-loaderu sistemu pozivanja
(invocation)
Mapiranje WSDL operacije(a) na Java targete. Omogucava konfigurisanje web servisa
tako da sistem pozivanja moze pravilni da asocira dolazecu SOAP poruku sa njenim Java
targetom.Ova informacija o mapiranju je snimljena kao meta podaci kojima sistem
pozivanja(invocation) moze da pristupi iz sistema uposljavanja kako bi odredio koji java
target da pozove.
Definisanje serijalizacionog konteksta Sistem razvojaa konfigurise serijalizacioni
podsistem serijalizacionim kontekstom potrebnim za preslikavanje.
Objavljivanje WSDL-a Sistem ravoja asocira Java target sa WSDL dokumentom koji
sadrzi WSDL operaciju na koju je prikacen target.Ovaj WSDL dokument je dostupan web
servis klijentima kao URL ili u drugoj formi na primer unutar UDDI registra.
Konfigurisanje SOAP hendlera Ovde spadaju hendleri koje deployment sistem
obezbedjuje za pre ili post invokaciju(pozivanje).Iako sistem pozivanja poziva hendlere,
oni se zapravo konfigurisu u sistemu uposljavanja.
Konfigurisanje endpoint osluskivaca(listener-a) Sistem uposljavanja konfigurise
kontejner tako da postoji transportni osluskivac za SOAP poruke.

Trei deo Pregled Java Web Servisa

Uloga JWS-a u SOA razvoju aplikacija
U osnovi, JWS obezbeuje set tehnologija koje omogudavaju koriscenje i kreiranje web
servisa koriscenjem Jave.Kako bi poceli diskusiju gde se JWS uklapa u SOA razvoj,
ispitivacemo hipotetcku aplikaciju.
HIPOTETIKA SOA APLIKACIJA
Neka je u pitanju hipoteticka SOA alplikacija za upravljanje narudzbenicama.Ona prima
narudzbine klijenata kao SOAP zahteve, i vraca potvrde o narudzbini kao SOAP odgovore.Na
slici je aplikacija Order Management u sredini i nazvana je SOA Composite App, kako bi se
naglasilo da se sastoji od grupe pozadinskih servisa.Servisi postoje kao nezavisne jedinice
logike.Poslovni proces se zato moze razbiti na serijeservisa, gde je svaki odgovoran za
izvrsavanje jednog dela procesa.E sad da pogledamo od cega se taj proces narucivanja
sastoji:
1.Klijent salje narudzbenicu koja pored ostalog sadrzi PO(Purchase order) Broj, i listu
narucenih stvari, kao i broj komada.
2.PO broj i narucene stvari se prosledjuju sistemu za obradu narudzbenica.Taj sistem
proverava narudzbenicu da vidi da li pokriva stvari koje su narucene, i merod placanja koji se
koristii
3. Ako PO pokriva narucene stavke Vracaju se autorizacija i opis zeljenih uslova placanja
4.Dalje,stvari se prosledjuju Sistemu za upravljanje magacinom kako bi se videlo sta je u
magacinu, kao i koji su verovatni datumi isporuke.
5.Vraca se informacija tipa Item Availiibility
6.NA kraju, vraca se poruka odgovora klijentu Potvrda o narucivanju koja definise uslove
placanja, i ocekivane datume kada ce roba biti isorucena

Posto smo ceo posao razbili na logcke jedinice,i to u nasem sluaju 2, svaka od njih se moze
opisati ulaznim i izlaznim porukama.
Servis za obradu narudbenica
Ulazna poruka: PO broj i lista artikala koji su naruceni
Obada:Odredjuje da li narudzbenica pokriva artikle koji su naruceni, i koji se metodi placanja
zahtevaju
Izlazna poruka: Potvrda za artikle koji su naruceni i opis nacina placanje za te artikle
Ovaj sistem za obradu narudzbenica implementiran je koriscenjem Java EE5.Drugi sistem
koji se implementira je Sistem za upravljanje magacinom.On je odgovoran za Servis za
upravljanje magacinom.
Servis za upravljanje magacinom
Ulazna poruka: Lista artikala koji se narucuju
Obrada:Odredjuje da li su artikli u magacinu, i kada ce moci da se isporuce

Izlazna poruka:lista artikala i datumi do kojih se isporucuju koji se jednom recju nazivaju
dostupnost sistema(system availibility).
E sad vidimo da je ovaj drugi sistem za magacin implementiran koriscenjem .NET-a.Ceo nas
sistem za upravljanje naruzdbenicama je opisan kao SOA composite aplikacija, zato sto se u
pozadini sastoji o 2 servisa.On procesira narudzbenice pozivanjem sistema za obradu
narudzbenica,a zatim magacina i kombinovanjem informacija kako bi vratio potvrdu o
narucivanju.E sad ceo sistem za upravljanje narudzbenicama je jedan veliki servis.Stoga,
koriscenjem SOA, servis se moze sastojati od vise pozadinskih servisa.
JWS omoguava SOA razvoj
Kada smo razmisljali o dizajnu Upravljanja Narucivanja jasno je da okmpozitne SOA
aplikacije zahtevaju da pozadinske SOA aplikacije koje pozivaju imaju dobro definisane
interfejse.
Zato, interfejs podsistema morada bude lepo definisan.Takodje moraa da zna da enkapsulira
poruku u format koji ce servis za obradu narudzbenica moci da razume.U ovom slucaju Web
servisi omogucavaju strukturu dase naprave zeljeni interfejsi.Iako nije zahtevano sa SOA
programiranje Web servisi imaju set standarda za interfejse i mesaging koji olaksavaju
buildovanje SOA aplikacije u formi nezavisnoj od platforme.Nije bitno, sto je recimo jedan
podservis na primer obrada narudzbenice implementirana u EE 5,a drugi, na primer
Upravljanje magacinom u .NET, jer oba podsistema odrzavaju web servise.Moguce je
uspostaviti saradnju, jer oba podrzavaju web servise, i pozivanjem aplikacija koriscenjem
njihovih webservis interfejsa.
Pri koriscenju web servisa,definicije interfejsa se odredjuju WSDL-om.Zato je svaki servis
prikazan na slizi asociran sa svojim WSDL dokumentom.WSDL se pise koriscenjem XML-a.On
definise ulazne i izlazne parametre web servisa u obliku XML Seme.Ulazni parametri su
isporuceni web servisu koriscenjem mssaging strukture.Takodje, izlazni parametri se primaju
kao poruka.Ponovo, SOA ne definise nikakvu formu poruke.SOAP poruke se koriste kako bi
prenele ulazne i izlazne parametre odredjene u definiciji WSDL intefjsa.Tako da web servisi
daju 2 sastavnadela u razvoju SOA aplikacije: jezik za definiciju interfejsa (WSDL) i messaging
standard (SOAP). SOAP poruke se prenose preko mnostva standarda : HTTP,SMTP i JMS.
HTTP GET zahtevi se upucuju kako bi se dobile definicije WSDL interfejsa od servisa, a HTTP
POST se koristi da prenese SOAP zahteve i odgovore.E to je nacinkako se osnovni Web
framework koristi u SOA razvoju aplikazija.JWS standardi daju alate za rad sa WSDL i
SOAP/HTTP unutar programskoh jezika Java.Postoje server-side alati koji omogucavaju da se
pozovu Java metoodi SOAP porukama, i da se objave WSDL definicije.Takodje postoje clientside alati za citanje WSDL dokumenata i slanje/primanje SOAP poruka.Mozemo zamisliti
klijent i server stranu kao dve strane znaka jednakosti.NA narednoj slici imamo prikazane
razne Java Web servis standarde JSR-ove koji podrzavaju server stranu jednakosti.Kako
bismo objasnili uloge ovih razlicitih JSR-ova na server strani , razvoj i poziv servisa su

propraceni brojevima.U dnu slike je Port komponenta.Ona predstalja upakovani web servis
koji se prosledjuje Java EE5 kontejneru.Ovaj kontejner m dodje kao neko okruzenje sa
pokretanje.Polje u sredini je oznaceno kao Web Service Application i predstavlja run-time
klase(poske razvoja) koje implementiraju web servis.Iznad su polja imenovana kao Java
parametri i jedno polje imenovano kao Java return.Ova polja predstavljaju run time
instance Java objekata koji se prosledjuju metodu jedne od klasa koje se nalaze u Web
Service Application.Ako se vratimo na primer sa narudzbenicama, to mogu da budu PO i broj
artikala na primer.E sad polja iznad ovih su oznacena kao XML Parameters i XML return.Oni
predstavljaju XML formu parametaara funkcije jezgra, i njene povratne vrednosti.Blizu vrha
slike je krug sa nazivom Endpoint.On predstavlja URL gde Web Service application prima
HTTP GET zahtev za WSDL definicijom interfejsa, ili HTTP POST za razmenu input i output
poruka.
Osencene povrsine na slici ilustruju koji Java servis odgovara razlicitim fazama razvoja i
invokacije.
Razvoj i Invokacija Web Servisa na Server-Strani
1. JWS definise Port komponentu(cesto oznacavanu samo kao Port)kao serverski
pogled na Web servis.Port komponenta moze bti upakovana kao WAR ( za razvoj na
endpointu gde je servlet) il ikao EJB JAR(za razvoj kao EJB endpoint).WSEE je
standard koji definise razvojni proces i strukturu pakovanja(ukljucujuci i deskriptore
pakovanja).WS-Metadata opisuje kako anotacije u pakovanim klasama oblikuju
razvoj( na primer WSDL interfejs koji predstavlja port komponentu moze biti
izmenjen(customized) koriscenjem WWS-Metadata anotacija).
2. Pomarajuci se ka vrhu slike, sledi invokacija Web servisa razvijenog po Port
komponenti.Endpoint podrzavaa HTTP GET zahteve za WSDL koji opisuje WEB
Servis.Struktura ovog WSDL-a je odredjena JAX-WS-om,JAXB-om i pomocu WSMetadata.Generalno, JAX-WS anotacije upravljaju stilom WSDL-a koji se koristi.JAXB
anotacije u drugu ruku manipulisu reprezentacijom Java parametara i povratnim
tipovima kao XML Shema komponenata.WS-Metadata anotacije manipulisu
specificnim delovima WSDL iterfejsa( na primer target namespace-om i lokalnim
imenima za bilo koji od elemenata koji su sadrzani u WSDL dokumentu).Handling
WSDL zahteva generalno nije deo WSPA(Web Service Platform Architecture),ipak,
cesto je funkcija koja je ukljucena u invokacioni podsistem platforme web servisa.
3. Invokacioni sistem razvijenog Web Servisa se pokrece kada stigne SOAP zahtev preko
HTTP POST metode na endpoint-u.
4. Endpoint mozemo prosto da zamislimo kao soket koji slusa za neke
podatke.Endpoint Web servisa je obicno implementiran u servletskoj klasi koja slusa
na endpoint URL adresi a specificira se u toku razvoja.Servlet nije specificiran
programerom Port komponenteOn je deo interne Java EE5 implementacije JWSa.Tokom razvoja, anotacije i/ili deskriptori razvoja bivaju ocitani WSEE runtime-om,

odredjuje se endpoint URL, i unutrasnjost kontejnera se konfigurise da razvije

oslushkivac na endpointu.Podesavalje endpointa je funkcija sistema razvoja u WSPA.
5. Korak 5 ilustruje da je SOAP zahtev postao set XML parametara instanci XML
Schema komponenti definisanih kao parametri u WSDL-u. JAX WS runtime je
odgovoran za izvlacenje ovih parametara iz SOAP poruke.Ekstraktovanje XML
arametara je definisaano kao deo dispatching procesa koji je obuhvacen
podsistemom invokacije u WSPA.
6. Dalje se XML parametri deserijalizuju u Java parametre.Ovu deserijalizaciju radi JAXB
runtime.Deserijalizacija je kontrolisana(kontrolisu se preslikavanja) anotacijama u
target Java klasi.JAXB koristi introspekciju da ispita anotacije u target klasama, i tu
informaciju(zajedno sa standardnim Java/XML bindovanjem definisanim JAXB-om)
koristi da isgenerise instance target parametara(parametara za obradu koji se pri
pozivu daju targetu).Ovaj korak povezuje serijalizacioni podeistem za WSPA.
7. Kada se parametri jednom kreiraju, poziva se target klasa/metod.U WSPA to je
odgovornost invokacionog sistema.Unutar Java EE 5, ovo radi JAX-WS.Slika prikazuje
da JAX-WS,JAXB i WS-Metadata svi igraju ulogu u definisanju anotiranih Java klasa
koje cine Web servis aplikaciju.Ovo je zato sto se anotacije svakog od ovih servisa
koriste u ovim klasama.Klasa koja je pozvana(takodje zvana i implementaciono
zrno) mora biti oznacema WS-Metarada akotacijom(na primer @WebService) koja
ce ukazivati na to da implementira Web servis.Klase koje reprezenruju parametre i
povratne tipove, najcesce ce imati mnoge JAXB anotacije.Kao dodatne, neke JAXB
anotacije mogu se koristiti na implementacionom zrnu kako bi kontrolisale stil
WSDL-a.
8. Posle invokacije, koraci u procesu teku obrnuto.Java klasa povratnog tipa koji vraca
funkcijase JAXB serijalizacijom pretvara u XML povratni tip.Serijalizacija se kao i
deserijalizacija kontrolise anotacijama u klasi kojadefinise povratni tip podatka.
9. Dalje JAX-WS pravi instancu XML povratnog tipa, i umotava je u SOAP odgovor
10. Konacno, SOAP odgovor se vraca nazad potraziocu preko HTTP-a

Client-Side invokacija Web servisa

1. Prvi korak u client-side invokaciji obicno ukljucuje generisanje servise endpoint
interfejsa(SEI-ja) koriscenjem WSDL to Java mapping alata.SEI predstavlja Java
reprezentaciju servisa koji se poziva.SEI se kreira pre kompajliranja klijentske
aplikacije,zbog toga sto se njegove definicije interfejsa koriste u klijentskoj
aplikaciji.Generisanje SEI ukljucuje JAXB,JAX-WS i WS-Metadata.JAXB mapira XML
parametre i i vraca tipove opisane u WSDL-u u Java parametre i povratni tip koji se
koriste u SEI-ju.WS-Metadata anotacije mapiraju WSDL operacije u Java metode.JAXWS u medjuvremenu radi standardno mapiranje i WSDL u Java unutar samog SEI-ja
dokumentovano WS-Metadata anotacijma.
2. U runtime-u kreira se instanca JAX-WS klase javax.xml.ws.Service, i ona sluzi da stvori
korisnicki pogled na web servis koji se poziva.Metod Service.getPort se koristi da se
napravi run-time instanca SEI-a generisanog uprethodnom koraku.Znaci mo smo na
klijent strani nekako apstrakovali kako izgleda servis koji je u stvari na serveru.Sa get
port pravimo instancu SEI-ja, jer rekosmo dase port odnosi na aplikaciju koja stoji iza
necega...Run-time instanca se implementira koriscenjem Java proxy tehnologije, i
predstavljena je na slici kao Proxu Instance.Kao sto je na slici, Proxy Instance
implementira service endpoint interface SEI.

3. Dalje, startuje se web servis pozivanjem jednog od SEI metoda Proxy

Instance.Parametri koji se prosledjuju SEI metodu su instance klasa koje su
generisane tokom kreiranja SEI-ja(korak 1 jer se tamo sve generise iz XML-a).Klase su
definisane JAXB mapiranjem iz XML Schema ukljucenih u WSDL.Prethodna slika
pokazuje kako SEI implementiran Proxy Instancom takodje koristi WS-Metadata i
JAX-WS.U SEI-ju postoje anotacije koje su kreirane od strane oba ova standarda,ali
pak one ne uticu na to kako korisnik poziva SEI metod.Ove anotacije koristi JAX-WS
runtime da prevede iz JAXB parametara i poziva metoda u SOAP zahtev koji se salje
Web servsu.Kada JAX-WS generise SOAP zahtev, i pre nego sto ga posalje na
endpoint web servisa, pozivaju se hendleri, ako postoje.Hendlere definise korisnik, i
oni mogu da manipulisu SOAP zahtevima/odgovorima.Proces pakovanja handlera na
klijent strani je odredjen je WSEE specifikacijom,a poziv handlera ide kroz JAXWS.Anotacije koje se koriste da povezu handlere sa implementacijom endpointa su
definisane specifikacijom u ES-Metadata.
4. Kad hendler obradi SOAP zahtev, on se salje Web Servisu, i nazad se dobija SOAP
odgovor.SOAP odgovor se obradjuje i inverznom smeru.Prvo se pozivaju
hendleri.Onda se parametri SOAP odgovoraa deserijalizuju(preko JAXB runtime-a).
5. Na kraju Proxy instanca vraca JAXB instancu kao povratnu vrednost.
Primarni cilj JWS-a je da olaksa Java developerima kreiranje i razvoj Web Servisa.Nekad,
da bi se napravilo lakse okruzenje, mora da se napravi par malih ogranicenja.I to je
normalno. Jos jedna uloga JWS-a je da sakrije kompleksnost platforme, pogotovo
procesa razvoja, jer to za Java developera i nije vazno...

Anotacije u izvornom kodu

JWS dizajneri su uveli anotacije u izvornom kodu za Web Servise kako bi pomogli dase
smanji kompleksnost procesa razvoja.Anotacije su definisane JAX-WS-u,WS-Metadata, i
JAXB.Ove anotacije se koriste u sva tri podsistema WSPA: invokaciji,serijalizaciji,razvoju.

Literatura:

Wikipedia
www.w3schools.com
SOA Using Java Web Services Mark D. Hansen
http://help.sap.com/saphelp_nw04/helpdata/en/fa/c7503e1dac5b46e10000000a11
4084/content.htm
Mnotvo internet foruma i drugih izvora na mrei