Java web Servisi

Download Report

Transcript Java web Servisi

Miroslav Naumovski 12999

 Za početak, da definišemo neke stvari i izraze koji će se nadalje spominjati

 XML je skraćenica od EXtensible Markup Language  XML je jezik sličan HTML-u  XML je zamišljen i projektovan da PRENOSI podatke, a ne da ih prikazuje  XML ne postoje predefinisane tagove.Morate praviti svoje tagove  XML je pravljen da bude self-descriptive – da opisuje sam sebe

 XML nije zamena za HTML  XML je projektovan da prenosi i čuva podatke  HTML je projektovan da prikazuje podatke fokusirajući se na to kako izgledaju  XML je kreiran s ciljem da se struktuiraju, snimaju i prenose informacije  XML je softverski i hardverski nezavisan alat za prenos informacija

 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

  Osnovna platforma za web servise je XML + HTTP.

XML je jezik koji se moze koristiti između različitih platformi i programskih jezika a da ipak prenese složene poruke i funkcije.

Elementi platforme web servisa:  SOAP (Simple Object Access Protocol)   UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language)

      Treba da sarađuju Zato su napravljene web aplikacije Male aplikacije koje se pokreću na webu Uklapaju se u bilo koju platofmu,jer su napravljene po standardima browsera Njihovim korišćenjem delimo usluge sa ostatkom sveta.

Primer:2 servera sa različitim OS.

 Ponovno korišćenje aplikacijskih komponenti(kako bi se koristile gotove aplikacijske komponente, npr. konverzija valute)  Povezivanje postojećeg softvera – rešavanje problema interoperabilnosti  Web servisi imaju 3 različita elementa platforme: SOAP, WSDL i UDDI

•    •     To je protokol baziran na XML-u napravljen da omogući aplikacijama razmenu podataka preko HTTP-a.Ili prostije SOAP je protokol za pristupanje Web servisu.

Skraćenica 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

    Služi za messaging, slanje poruka,sastoji se od pravila za struktuiranje podataka.Često se koristi kada se web servisi koriste kao RPC(Remote Procedure call).

Primer baze zaposlenih Logika za pristup i zahteve bazi enkapsulirana u 1 metodi pisanoj u nekom programskom jeziku Postavlja se funkcija koja sluša

• SOAP zahtev se transformiše u poziv metode

       WSDL je je jezik baziran na XML-u a služi za lociranje i opis Web servisa.Opisuje interfejs web servisa.Definiše lokaciju servisa i operacije koje on pruža.Takodje definiše format klijent/server poruka koje se razmenjuju.

Klijent čita WSDL kako bi utvrdio šta server nudi.

Bilo koji specifični tipovi podataka ugrađeni su u WSDL u XML Schema formatu.

Klijent za pozivanje zapravo koristi SOAP kako bi pozvao neku on funkcija definisanih u WSDL-u 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

      UDDI je servis gde kompanije mogu da prijave(registruju) ili traže 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 komunicira preko SOAP-a UDDI ugradjen je u .NET platformu

 Registar baziran na XML-u za kompanije širom sveta koje pružaju web servise  Njegov cilj je da ih poveže,omogući online transakcije,tj. da kompanije pronađu jedna drugu na internetu i interoperabilno i elektronski da posluju.

 UDDI je kao telefonski imenik: imena kompanija,proizvodi, ili web servisi koje pružaju

• • • Web servisi mogu da se koriste na 3 načina: RPC(Remote Procedure Call) SOA (Service Oriented Architecture) REST(Representational state transfer)

     RPC Web servisi predstavljaju interfejs poziva distribuirane funkcije.

Osnovna jedinica RPC servisa je WSDL operacija Široko rasprostranjen, ali nije “ loosley coupled ” A to je sistem čija svaka komponenta zna jako malo ili uopšte o drugim komponentama sistema RPC pokreće klijent, koji šalje zahtev i parametre poznatom serveru. Udaljeni server vraća odgovor, I aplikacija nastavlja sa izvršenjem. Dok server obradjuje zahtev, klijent je blokiran(čeka dok server ne vrati rezultat).

 Osnovna jedinica komunikacije je poruka,a ne operacija  Sistemi bazirani na SOA su porukama Orijentisani  Loose coupling je prisutan, jer je akcenat bačen na “ugovor” koji WSDL obezbeđuje, umesto na pozadinske implementacione detalje

  REST pokusava da opiše arhitekture koje koriste HTTP ili slične protokole ograničavajući svoj interfejs na set dobro poznatih, standardnih operacija(kao sto su GET, POST, PUT, DELETE kod HTTP-a). Ovde, fokus je bačen na interagovanje resursima okruženja, umesto na poruke ili operacije.

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

• • Prve verzije servisa su bile: JAX-RPC 1.0

• J2EE 1.4 koja je sadržala JAX-RPC 1.1

Najnovija verzija: Java EE6

Baziraju se na sledećim 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 ponašanje Web Servisa u Java EE kontejneru

    1.

2.

3.

Platforma web servisa je set alata za pozivanje i razvoj web servisa korišćenjem određenog programskog jezika Server-side komponente imaju nekakvu vrstu kontejnera(Java EE aplikacioni server) Client-side komponente su obično pakovane kao set alata za pristupanje instancama Java interfejsa koje predstavljaju neki web servis Bilo koja web servis platforma ima 3 dela svog jezgra Invokacija(pozivanje) Serijalizacija Razvoj(Deployment)

         Primanje SOAP poruke iz transporta (na primer sa HTTP-a) Pozivanje handlera koji vrše “predobradu” poruke(na primer kako bi se obradilo SOAP zaglavlje) Određivanje servisa kome je poruka namenjena , drugim rečima, koju WSDL operaciju funkcija treba da pozove.

Posto je detektovana target operacija, odredjivanje koja Java klasa /metod treba da se pozove.Ovo zovemo Java target.Određivanje Java target-a se takodje zove dispatching Prosledjivanje SOAP poruke serijalizacionom podsistemu kako bi je deserijalizovao u Java objekte koji se mogu proslediti Java targetu kao parametri.

Pozivanje(invoking) Java targeta koriscenjem parametara generisanih serijalizacionim podsistemom i generisanje Java objekta koji target metod vraca.

Prosledjivanje objekta koji je funkcija vratila Serijalizacionom podsistemu kako bi ga serijalizovao u XML element u skladu sa WSDL-om Omotavanje tog XML elementa kao SOAP odgovora ponovo u skladu za WSDL-om Pustanje SOAP odgovora nazad na transport za isporuku

 Na klijent strani invokacioni sistem je sličan ukoliko pozivamo web servis korišćenjem Java interfejsa  Ako klijent radi sa XML-om lakše je samo napraviti SOAP poruku i proslediti je web servisu  Ako klijent radi sa Java objektima kako JWS pretpostavlja, na scenu stupa Client-Side Invocation System

         Kreiranje instance web servis endpoint-a invocation handlera.

(krajnje tacke) koja implementira Java interfejs koji se u skladu sa JWS terminologijom naziva “service endpoint interface”(SEI).Obično se SEI instance implementiraju korišćenjem Java proksija ili Pozivanje SEI instance Uzimanje parametara prosledjenih SEI-ju definisanom WSDL-om target servisa i njihovo slanje serializacionom podsistemu gde se serijalizuju u XML elemente u skladu sa XML šemom Omotavanje parametara u SOAP poruku u skladu sa WSDL-om.

Pozivanje handlera koji post-procesiraju poruku ( na primer za podesavanje SOAP zaglavlja) Predaja poruke transportu za isporuku na target web servis Primanje SOAP poruke sa odgovorom iz transporta Prosleđivanje 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 vraća konačni rezultat.

Kompletiranje poziva SEI-ja vraćanjem deserijalizovanog SOAP odgovora.

 Na server strani, sistem pozivanja povezuje Java metod sa proxy soap operacijom definisanom WSDL-om.Izvrsava WSDL operaciju pozivanjem Java metoda.

 Obrnuto, na klijent strani sistem pozivanja povezuje WSDL definisanu SOAP operaciju sa proxy Java iterfejsom.

 Proces transformisanja Java klase u XML element  Hostovani unutar web servis kontejnera mogu se nalaziti više SOAP endpoint-ova gde svaki odgovara grupi web servisa.Dalje svaki takav endpoint ima svoj WSDL interfejs koji definiše operacije koje ovaj endpoint izvršava.Endpointovi su apstrakcija za web servis, način na koji klijent vidi web servis

Web Service proxy povezuje (binduje) Java interfejs metod sa WSDL operacijom. Proxy je kreiran sistemom pozivanja.

On poziva/pokreće 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.PurchaseOrd

er i kreira instancu wrapper:customerPurchase koja se moze ugraditi u telo SOAP poruke.E tu stupa na scenu serijalizacioni sistem.

     Primanje parametara od web service proksija Serijalizovanje oba dva parametara(“cust” i “po” ) klase Kombinovanje ova dva elementa i njihovo umotavanje u wrapper klasu wrappper:customerPurchase; Predaja instance wrapper klase Web Service proksiju kako bi se ugradila u SOAP poruku i poslala na SOAP endpoint Znači web proxy prosledi parametre za serijalizaciju sistemu za serijalizaciju, serializer ih odradi, umota u wraper klasu I tako vrati proksiju koji zatim šalje SOAP endpoint-u poruku

• • • Serijalizacioni sistem prevodi parametre(prosleđene interfejs proksiju)sa instanci njihovih Java klasa u instance željene XML Scheme.E ovakva preslikavanja se zovu mapiranje Serijalizacioni modul primenjuje neku strategiju mapiranja Maping strategija vezuje Java klasu sa njenom XML Schema i opisom serializera/deserijalizera koji može da konvertuje XML->Java class I obrnuto

• • • Neki od načina mapiranja: Standard binding Source code annotations Algoritamsko – mapiranja su ugrađena u algoritme koje izvršava podsistem • Rule-Based – odvojena pravila, kreiraju se I edituju nezavisno od serijalizacionog podsistema Serijalizacioni kontekst predstavlja set strategija mapiranja koje serijalizacioni sistem može koristiti da implementira preslikavanja tipova korišćenih u određenom web servisu

    Sistem razvoja obezbeđuje alate za podesavanje 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 označi samo pravljenje klasnih definicija Java targeta dostupnim class-loaderu sistema pozivanja (invocation)

Mapiranje WSDL operacije(a) na Java targete. –

Omogućava konfigurisanje web servisa tako da sistem pozivanja moze pravilno da asocira dolazeću SOAP poruku sa njenim Java targetom.Ova informacija o mapiranju je snimljena kao meta podaci kojima sistem pozivanja(invocation) moze da pristupi iz sistema razvoja kako bi odredio koji java target da pozove.

    Definisanje serijalizacionog konteksta – Sistem razvoja konfigurise serijalizacioni podsistem serijalizacionim kontekstom potrebnim za preslikavanje.

Objavljivanje WSDL-a – Sistem razvoja asocira Java target sa WSDL dokumentom koji sadrzi WSDL operaciju na koju je prikačen 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 razvoja.Ovi hendleri pružaju usluge kao što je autentifikacija,enkripcija podataka i generalno da obezbede sigurnost.

Konfigurisanje endpoint osluskivaca(listener-a) – Sistem uposljavanja konfigurise kontejner tako da postoji transportni osluskivac za SOAP poruke.

   Kao što vidimo deployment sistem mora da odradi dosta komplikovanih zadataka kao što su sigurnosni zahtevi, Java/XML Binding,podešavajući endpoint, deployment deskriptori, itd.

Platforma web servisa može da se sastoji od više kontejnera.U našem slučaju su to application server container Java EE5 i UDDI.Kao što vidimo, svaki od objekata koji je razvijen u kontejneru, zavisi od njegovih container-specific deployment deskriptora.Međutim endpoint listener,SOAP hendleri,i Java target aplikacija mogu biti opisani i u WSDL maping deskriptorima.

Znači ceo deployment bukvalno zavisi od deskriptora sa različitih mesta...Kao na slici ------ 

   JWS je u osnovi set tehnologija za korišćenje i kreiranje web servisa korišćenjem Jave Hipoteticka SOA aplikacija sa narudžbenicama Klijent šalje narudžbenicu koja ima PO(Purchase order) broj i listu artikala  2 podsistema, obrada narudžbenice i upravljanje magacinom 1.Slanje narudžbenice 2.Provera validnosti i metoda plaćanja 3.Vraća se autorizacija i opis željenih uslova plaćanja 4.Salje se zahtev magacinu i vraća podatak tipa Item Availibility 5.Vraća se odgovor klijentu sa uslovima plaćanja i rokom isporuke

    Servis obrade narudžbine-ulaz PO i lista artikala,izlaz potvrda za artikle i način plaćanja,implementiran u Java EE5 Servis upravljanja magacinom – ulaz lista artikala,izlaz lista artikala+datumi isporuke,implementiran u .NET

Ceo naš sistem – SOA composite – 2 dela,2 servisa implementirana u različitim okruženjima E sad ceo sistem za upravljanje narudzbenicama je jedan veliki servis.Stoga, koriscenjem SOA, servis se može sastojati od vise pozadinskih servisa.

         Ako sistem upravljanja narudžbenicama traži potvrdu i metod plaćanja od podsistema za obradu narudžbenice, mora da zna TAČNU formu u kojoj da posalje zahtev ovom podsistemu Zato interfejs podsistema mora biti lepo definisan Takođe mora da enkapsulira poruku u format koji podsistem razume U ovom slučaju Web servisi su ti koji omogućavaju da se naprave željeni interfejsi bez obzira što su platforme različite Interfejs svakog servisa na prethodnoj slici je definisan WSDL dokumentom gde su ulazni i izlazni parametri web servisa definisani XML Schem-om Servisi komuniciraju slanjem SOAP poruka koje prenose ulazne i izlazne parametre skladno definiciji WSDL-a Znači WSDL da izdefiniše interfejs, a SOAP za poruke HTTP GET – za traženje interfejsa,,HTTP POST za zahteve i odgovore Sve ovo je način korišćenja web frameworka za SOA aplikacije

     Port komponenta – upakovani web servis koji se prosleđuje Java EE5 kontejneru Web Service Application(sredina) – klase koje implementiraju sami web servis Java parametri i Java return – Java objekti parametri/povratne vrednosti XML Parameters i XML return – sve to samo u XML formi Endpoint – To je URL gde Web Servis prima HTTP GET zahtev sa WSDL definicijom interfejsa ili HTTP POST za razmenu poruka

           Endpoint treba da podrži HTTP GET zahteve za slanje WSDL interfejsa Strukturu WSDL definiše JAX-WS,JAXB i WS-Metadata JAX-WS anotacije definišu stil WSDL-a JAXB kako se objekti slikaju u XML WS-Metadata anotacije – manipulišu specifičnim delovima WSDL interfejsa Invokacioni sistem se pokrece po prijemu SOAP HTTP POST zahteva Endpoint – kao soket,implementiran u servletskoj klasi koja sluša na URL adresi, ne programiramo ga mi već je deo JWS-a JAX-WS izvlači XML Schema definicije is SOAP poruke JAXB deserijalizuje Java parametre Za pozivanje target metoda zadužen je takodje JAX-WS Java EE5 možemo zamisliti kao nekakvo kompletno okruženje koje omogućuje našoj aplikaciji da radi kao web servis

     Generisanje SEI-ja(Service Endpoint Interface). Ovo se radi pre kompajliranja klijentske aplikacije jer se definicije interfejsa koriste u klijentskoj aplikaciji U run-time-u kreira se instanca JAX-WS klase javax.xml.ws.Service I ona služi da stvori korisnički pogled na web servis koji se poziva.Dalje Service.getPort pravi instancu SEI-ja Znači, sada smo na klijentskoj strani nekako apstrakovali kako izgleda servis koji je inače na serveru Hendler – obrađuje SOAP zahtev,šalje ga Web Servisu.Kad se dobije odgovor, obrađuje ga u inverznom smeru Na kraju celog procesa,Proxy instanca(koja inače implementira SEI) vraća objekat kao povratnu vrednost

 Uloga JWS-a je da sakrije kompleksnost platforme, pogotovo procesa razvoja, jer to Java developeru nije važno  Da olakša developerima razvoj web servisa

    Apache Axis je open source,Web service framework baziran na XML-u. Sastoji se od Java I C++ implementacije SOAP servera, I različitih utility programa i API-ja za generisanje i razvoj Web Servis aplikacija. Korišćenjem Apache Axis, developeri mogu da prave interoperabilne, distribuirane aplikacije.

Pri korišćenju Java Axisa postoje 2 načina na se Java kod pretvori u web servis.Najlakši je korišćenjem native JWS fajlova.Drugi način je custom razvoj ukoliko menjamo resurse koji se prikazuju kao web servis JWS ekstenzija sadrži Java kod koji treba da se prikaže kao web servis.Razlika u odnosu na obični Java fajl je u ekstenziji Takodje JWS se razvija kao source kod, ne prave se class fajlovi