Elektronski fakultet u Nišu, Datum: 6.5.2011.Katedra za računarstvo

Java Web Servisi

Student:

Miroslav Naumovski 12999

Prvi deo – Uvod u XML

Šta je XML?

XML je skraćenica od EXtensible Markup Language XML je jezik sličan HTML XML je zamišljen 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 različitim ciljevima:

XML je projektovan da prenosi i čuva podatke, i fokusira se na to STA su ti podaci HTML jep rojektovan da prikazuje podatke,fokusirajući se na to kako podaci

IZGLEDAJU

Znači u HTML-u je sve u prikazu informacija, dok se XML odnosi na prenos informacija.

XML NE RADI ništa

Malo je teško za razumeti, ali XML u stvari ne radi ništa. 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,opšte

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)

Različite platforme

Razlicite platforme pristupaju webu koriscenjem web pretrazivaca, takoda bi one trebale da mogu na neki nacin da saradjuju. E kako bi mogle da sarađuju, napravljene su web aplikacije.

Web aplikacije su male aplikacije koje se pokreću 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š nešto 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 service-oriented 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š nešto 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š nešto o WSDL-u

WSDL je skraćeno 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).

InvokacijaPostoje 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 XML-om 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 WSDL-om.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.

Treći deo – Pregled Java Web Servisa

Uloga JWS-a u SOA razvoju aplikacija

U osnovi, JWS obezbeđuje set tehnologija koje omogućavaju koriscenje i kreiranje web servisa koriscenjem Jave.Kako bi poceli diskusiju gde se JWS uklapa u SOA razvoj, ispitivacemo hipotetcku aplikaciju.

HIPOTETIČKA 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 narudžbenica

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 omogućava 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 client-side 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 WS-Metadata.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 JWS-a.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 odgovor10. 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.JAX-WS 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 JAX-WS.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/ c7503e1dac5b46e10000000a114084/content.htm

Mnoštvo internet foruma i drugih izvora na mreži