Plan
8.1. Osnove web usluga
8.2. Web 2.0 i web usluge
8.4. Interakcija s web servisima
8.6. Sastav web usluga
8.7. Web usluge u ASP.Netu
8.1. Osnove web usluga
Web usluga A (Web usluga) (pogledajte W3C dokument “Zahtjevi za arhitekturu web usluga”) je softverski sustav identificiran URI nizom, čija su sučelja i povezivanja definirana i opisana u XML jezik. Opis ovog softverskog sustava mogu pronaći drugi softverski sustavi koji mogu komunicirati s njim u skladu s ovim opisom putem poruka, temeljeno na XML-u, a prenosi se korištenjem internetski protokoli.Koncept web usluga nastala u kasnim 90-im godinama XX stoljeća. Međutim, do sada se ovaj koncept ustalio, a arhitektura koju nudi postala je industrijski standard u IT području.
Standardizaciju arhitekture web servisa provode radne skupine odbora W3C.
Standardi web usluga definiraju format poruka, sučelje na koje se poruka šalje, pravila za povezivanje sadržaja poruke s aplikacijom koja implementira uslugu i obrnuto, kao i mehanizme za objavljivanje i pretraživanje sučelja.
Mehanizam slanja poruka definiran je u opisu usluge (Web Services Description), koji je specifikacija sučelja usluge i pokriva formate poruka, vrste podataka, transportne protokole koji se koriste u razmjeni između agenata korisnika i davatelja usluge. Osim toga, opis usluge sadrži naznaku jedne ili više točaka u mreži (endpoint) s kojih je pružatelj dostupan.
Zahvaljujući web uslugama, funkcije bilo kojeg programa na mreži mogu biti dostupne putem interneta.
Web usluge temelje se na sljedećim univerzalnim tehnologijama:
TCP/IP je univerzalni protokol koji razumiju svi mrežni uređaji, od velikih računala do Mobiteli i PDA;
HTML - univerzalni jezik označavanje koje se koristi za prikaz informacija na korisničkim uređajima;
XML (Extensible Markup Language) je univerzalni jezik za rad s bilo kojom vrstom podataka.
Svestranost ovih tehnologija osnova je za razumijevanje web usluga. Temelje se samo na općeprihvaćenim, otvorenim i formalno neovisnim tehnologijama. Samo se time može postići glavna prednost web usluga kao koncepta izgradnje distribuiranih IS-a - njihova univerzalnost, odnosno mogućnost korištenja za bilo koje operacijske sustave, programske jezike, aplikacijske poslužitelje i sl.
Dakle, web usluge rješavaju izvorni problem– zadatak integracije aplikacija različite prirode i izgradnje distribuiranog IS-a.
Ovo je glavna stvar temeljna razlika web usluge od svojih prethodnika - tehnologije za interakciju distribuiranih aplikacija, koje su omogućile implementaciju razmjene podataka između aplikacija (Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) i Common Zahtjev za objekt Brokerska arhitektura (CORBA)). Međutim, svaki od njih bio je prilično složen za implementaciju, nije imao potrebnu univerzalnost (odnosno, još uvijek je ovisio o izboru npr. istog operativnog sustava za sve sudionike u razmjeni) i, što je posebno loše, te je tehnologije bilo vrlo teško međusobno integrirati.
Prednosti i nedostaci web usluga
Prednosti
web usluge osiguravaju interakciju softverskih sustava bez obzira na platformu;
web usluge temelje se na otvorenim standardima i protokolima. Zahvaljujući korištenju XML-a postiže se jednostavnost razvoja i otklanjanja pogrešaka web usluga;
Korištenje internetskog protokola HTTP osigurava interakciju softverskih sustava kroz vatrozid.
Manja produktivnost i veće veličine mrežni promet u usporedbi s RMI, CORBA, DCOM tehnologijama zbog korištenja XML tekstualnih poruka.
Platforme
Web usluge rade na aplikacijskim poslužiteljima. Danas gotovo svi poslužitelji web aplikacija podržavaju ovu tehnologiju:
Axis i Tomcat (oba su Apache projekti).
Mono razvojna platforma tvrtke Novell
Microsoft .NET poslužitelji tvrtke Microsoft
Java Web Services Development Pack (JWSDP) tvrtke Sun Microsystems (temeljen na Jakarta Tomcat)
Zope je objektno orijentirani poslužitelj web aplikacija napisan u Pythonu
Aplikacijski poslužitelj iz IBM-a (temeljen na Apache i J2EE platformi)
Cordys WS-AppServer
infoRouter softver za upravljanje dokumentima Web Services API
JOnAS (dio ObjectWeb Open Source inicijative)
Web Application Server iz SAP-a (Web AS je ključni dio skupa SAP NetWeaver)
Pramati Application Server tvrtke Pramati Technologies Limited
Platforma OpenEdge tvrtke Progress Software
Oracle Application Server tvrtke Oracle Corporation
Zend Framework - iz Zend Technologies
Pythomnic je platforma za pisanje distribuiranih mrežnih usluga.
Google App Engine je platforma za visoko skalabilne aplikacije koje koriste Googleovu infrastrukturu.
izvršava se na strani poslužitelja;
pružiti skup metoda dostupnih vanjskim klijentima;
izvršavanje web metoda i vraćanje rezultata klijentima;
web usluge i njihovi klijenti mogu biti napisani na različitim jezicima i/ili različite platforme.
8.2. Web 2.0 i web usluge
Tehnologije web usluga temeljne su za Web 2.0.
Izraz "Web 2.0" predložio je 2005. godine poznati američki izdavač Tim O'Reilly kako bi označio skup progresivnih trendova u razvoju web tehnologija.
Danas se ovaj pojam ne shvaća toliko kao skup specifičnih tehnologija, već kao filozofija predstavljanja informacija u web okruženju i izgradnje informacijskih odnosa.
Fenomen Web 2.0 može se podijeliti u nekoliko općih trendova u razvoju web okruženja.
Web kao platforma. Ovaj koncept je srž filozofije Web 2.0.
To se odnosi na omogućavanje korisnicima da koriste softverske aplikacije izravno putem web preglednika. Drugim riječima, ovaj koncept uključuje provođenje svih potrebnih izračuna koristeći samo one softver, koji su integrirani s web preglednikom.
Budući da web usluge omogućuju jednom web projektu da koristi softverske aplikacije drugog, organizacije ne moraju stvarati mnogo sličnih proizvoda za obavljanje istih zadataka. Dakle, web servisi omogućuju suradnju i koordinaciju među različitim institucijama u procesu kreiranja web sadržaja.
Ovdje već govorimo o još jednom važnom principu Web 2.0 – “mash-up” (miješanju). Ovo načelo znači da je integracijom softverskih mogućnosti nekoliko web servisa neovisnih jedan o drugome moguće stvoriti novi, jedinstveni web projekt.
8.3. Tehnološki skup web usluga
Web usluge zahtijevaju korištenje nekoliko povezanih XML tehnologija koje tvore tehnološki skup (Slika 8.1).
XML je temelj na kojem se grade web usluge. Pruža jezik za definiranje podataka i kako se oni obrađuju. XML predstavlja obitelj povezanih specifikacija koje objavljuju i održavaju Internet Consortium (W3C) i druge organizacije.
SOAP (Jednostavno Pristup objektu Protocol), koji je razvio konzorcij W3C, definira format zahtjeva za web usluge. Poruke između web usluge i njezinog korisnika pakiraju se u takozvane SOAP omotnice (ponekad se nazivaju i XML omotnice). Sama poruka može sadržavati ili zahtjev za izvođenje neke radnje, ili odgovor - rezultat izvođenja ove radnje.
WSDL (Web Services Description Language) tehnologija je temeljena na XML-u koja definira sučelja web usluga, vrste podataka i poruka, kao i modele interakcije i protokole povezivanja. Prije postavljanja usluge, programer stvara njen opis u WSDL-u, navodi adresu web usluge, podržane protokole, popis dopuštenih operacija, formate zahtjeva i odgovora.
UDDI (Universal Description, Discovery and Integration) tehnologija je registar web usluga i tražilica. Koristi se za pohranjivanje i organiziranje informacija o web uslugama, kao i za pronalaženje pokazivača na sučelja web usluga.
Riža. 8.1. Tehnološki skup web usluga
Te tehnologije omogućuju implementaciju osnovna svojstva web usluga opisana u svojoj definiciji.
Na temelju njih razvijaju se novi interakcijski jezici i uslužno orijentirane arhitekture.
8.4 Interakcija s web uslugama
Sučelja web servisa primaju standardne XML poruke iz mrežnog okruženja, pretvaraju XML podatke u format koji "razumije" određeni aplikacijski softverski sustav i šalju poruku odgovora (posljednje je izborno). Implementacija softvera web usluge (osnovni softver, niža razina) mogu se izraditi u bilo kojem programskom jeziku korištenjem bilo kojeg operativnog sustava i bilo kojeg međuprograma.Interakcija softverskih sustava s web servisima prikazana je na sl. 8.2.
Riža. 8.2. Interakcija s web servisima
Postoje tri glavne arhitektonske komponente uslužno orijentirane arhitekture:
korisnik usluge: aplikacija, programski modul ili usluga koja traži i poziva traženu uslugu iz registra usluga prema opisu usluge, a također koristi uslugu koju pruža davatelj usluge u skladu sa sučeljem usluge;
davatelj usluga: aplikacija, programski modul ili usluga koja implementira uslugu u obliku web usluge, prima i izvršava zahtjeve korisnika usluge, te objavljuje uslugu u registru usluga;
servisni registar: Knjižnica usluga koja pruža sredstva za korisnike usluga da pronađu i pozovu potrebnu uslugu i prihvaća zahtjeve pružatelja usluga za objavljivanje usluga.
Kada su u međusobnoj interakciji, komponente uslužno orijentirane arhitekture izvode sljedeće osnovne operacije:
objavljivanje: kako bi usluga bila dostupna (pozivna) korisnicima usluge, potrebno im je upoznati njeno sučelje;
traži: korisnik usluge mora moći u registru usluga pronaći potrebnu uslugu koja zadovoljava navedene kriterije;
ropstvo i izazov: Nakon što primi opis usluge, korisnik usluge trebao bi moći pozvati i koristiti uslugu u skladu s opisom usluge.
Opis usluge: određuje format zahtjeva i odgovora tijekom interakcije između korisnika usluge i davatelja usluge, kao i potrebnu kvalitetu usluge;
servis: Sama usluga koju korisnik usluge može pozvati i koristiti prema objavljenom sučelju usluge.
8.5. Servisno orijentirana arhitektura aplikacije
8.5.1. Osnove servisno orijentirane arhitekture
Arhitektura u kojoj su sve funkcije aplikacije neovisne usluge s jasno definiranim sučeljima koja se mogu pozivati pravilnim redoslijedom za formiranje poslovnih procesa naziva se servisno orijentirana arhitektura (SOA).
SOA je sredstvo predstavljanja poslovanja kao skupa međusobno povezanih usluga. Jedna od njegovih prednosti je fleksibilnost i jednostavnost razvoja novih aplikacija. SOA stvara komunikacijsko okruženje za module koji implementiraju primijenjenu poslovnu logiku. Informacije o modulima objavljene su u takvom obliku da njihova uporaba ne zahtijeva poznavanje rješenja i tehnologija koje se u njima koriste.
8.5.2. Tehnologije za implementaciju uslužno orijentirane arhitekture
Za izradu složenih distribuiranih aplikacija nije dovoljan jedan skup osnovnih tehnologija (SOAP, WSDL, UDDI). Treba se pozabaviti i drugim pitanjima, kao što su osiguravanje produktivnosti, sigurnosti, pouzdana dostava poruke, koordinacija transakcija i drugo. Stoga se ovaj tehnološki skup stalno širi. Na sl. 8.3 predstavlja proširenu hrpu tehnologija web usluga, uključujući već standardizirane tehnologije i nove.
Riža. 8.3. Tehnološki skup naprednih web usluga
Tehnološki skup proširenih web usluga u osnovi je podijeljen na sljedeće dvije komponente:
tehnologije koje pružaju funkcionalnost web usluge (funkcije);
tehnologije koje pružaju kvaliteta usluge web usluge (Quality of service).
tehnologije koje pružaju funkcionalnost web usluga:
transportni sloj;
uslužni komunikacijski sloj;
sloj opisa usluge;
servisni sloj;
sloj poslovnog procesa;
sloj servisnog registra.
Tehnologije koje osiguravaju kvalitetu web usluga:
sloj politike;
sigurnosni sloj;
transakcijski sloj;
upravljački sloj.
Da bismo razumjeli svrhu slojeva, dajmo Kratki opis svaki od njih.
| № p/p | Naziv sloja | Namjena sloja | Tehnologije koje implementiraju sloj |
| Funkcije |
|||
| 1 | Transportni sloj | Opisuje sredstva za razmjenu podataka između web usluga | Standardno: HTTP, JMS (za Java aplikacije), SMTP Novo: WS-ReliableMessaging, BEEP |
| 2 | Komunikacijski sloj usluge | Opisuje načine formaliziranja mehanizama za korištenje prijenosnih protokola putem web usluga. | Standard: SOAP Novo: REST |
| 3 | Sloj opisa usluge | Opisuje načine formalizacije sučelja web usluga kako bi se osiguralo njihovo funkcioniranje bez obzira na platformu implementacije softvera i hardvera ili programski jezik. | Standard: XML, WSDL U nastajanju: ebXML |
| 4 | Servisni sloj | Opisuje softver koji WSDL naziva opisima sučelja web usluga. Konkretno, to su same web usluge | |
| 5 | Sloj poslovnih procesa | Opisuje mogućnosti organiziranja web servisa za implementaciju poslovnih procesa i tijekova rada. Istovremeno se definiraju pravila koja određuju redoslijed interakcije web servisa u cilju zadovoljenja poslovnih zahtjeva | Novo: BPEL4WS, WCF, WF |
| 6 | Sloj registra usluga | Opisuje mogućnosti organiziranja web usluga u hijerarhijske biblioteke koje omogućuju objavljivanje, pretraživanje i pozivanje web usluga na temelju opisa WSDL sučelja | Standard: UDDI U nastajanju: WS-Inspekcija |
| Kvaliteta usluge |
|||
| 7 | Sloj politike | Opisuje odredbe i uvjete pod kojima se web usluge mogu koristiti. Budući da se ovi uvjeti odnose i na funkcionalni aspekt web usluga i na aspekt kvalitete usluge na Sl. 8.3, ovaj sloj je zajednički za oba aspekta | Standardno: Trenutno nema Novo: WS-Policy, WS-PolicyAssertions i WS-PolicyAttachment |
| 8 | Sigurnosni sloj | Opisuje mogućnosti osiguranja sigurnosti web usluga i sigurnosti njihovog rada (autorizacija, autentifikacija i dijeljenje pristupa) | Standard: WS-Security Novo: WS-SecureConversation, WS-Federation, WS-Authorization, WS-Trust i WS-Privacy |
| 9 | Transakcijski sloj | Opisuje transakcijsko svojstvo distribuiranih sustava temeljenih na web uslugama kako bi se osigurala pouzdanost njihovog funkcioniranja | Standardno: Trenutno nema Novo: WS-transakcija i WS-koordinacija |
| 10 | Upravljački sloj | Opisuje mogućnosti upravljanja web servisima i karakteristike njihova funkcioniranja | Novi: |
Tehnološki skup web usluga predstavljen gore uvodi hijerarhiju u mnoge tehnologije web usluga prema njihovim funkcionalna namjena. Međutim, tablica prikazuje samo najčešće korištene i utvrđene tehnologije. Tehnologije koje su primile službeni status standardi međunarodnih konzorcija za razvoj IT standarda (W3C).
8.6. Sastav web usluga
Kompozitivnost web usluga često se smatra jednom od glavnih prednosti tehnologije, osiguravajući njihovu mogućnost ponovne upotrebe. ponovno koristiti. Općenito govoreći, sastav web usluge je pronalaženje skupa atomskih usluga potrebnih za implementaciju korisničkog zahtjeva i određivanje redoslijeda u kojem se one izvršavaju.Funkcionalnost svake web usluge određena je njenim ulazima, izlazima, preduvjetima i radnjama, koje se nazivaju IOPE (ulazi, izlazi, preduvjeti i učinci). IOPE usluge sadržan je u njenom WSDL opisu.
Web usluge se po načinu izvršavanja mogu podijeliti na atomske, koje nisu podijeljene na potprocese i korisnik ih može pozivati izravno putem interneta, te kompozitne, koje imaju potprocese povezane kontrolnim konstruktima. Poslovni zadaci korisnika u pravilu se realiziraju kompozitnim servisima, koji se mogu sastaviti iz postojećih atomskih.
Koncept web servisa to podrazumijeva pojedinačne usluge imaju određene ograničene funkcionalnosti, dok rješavanje više ili manje složenih problema zahtijeva korištenje funkcionalnosti nekoliko servisa. Stoga su tijekom razvoja arhitekture web usluga koncepti poput npr sastav i tok ili, kako se sada kaže, orkestracija i koreografija. Oni odražavaju interakcija i dosljednost usluge njihovu provedbu; Smatra se da se aplikacije izrađene pomoću web usluga temelje na Work Flow (WF).
Pojmovi orkestracija I koreografija opisuju dva aspekta razvoja poslovnih procesa temeljenih na integraciji web usluga. Na sl. Slika 8.5 općenito prikazuje odnos između ovih aspekata, koji se u određenoj mjeri međusobno nadopunjuju.
Pod, ispod orkestracija razumjeti kako usluge međusobno komuniciraju na razini poruke, uključujući poslovnu logiku i suradnju pri izvršavanju složenih procesa unutar jedno poduzeće (jedan poslovni proces).
Koreografija pokriva širi raspon sudionika interakcije, uključujući dobavljače, potrošače i partnere poduzeća. Povezan je s javnom razmjenom poruka između više web servisa, a ne s jednim poslovnim procesom koji se provodi unutar jednog poduzeća.
Standardi koreografije i orkestracije temelje se na WSDL-u. Na razini modela poslovnih procesa, nacrti standarda kao što su Wf-XML (Workflow Management Coalition), WSFL (IBM Web Services Flow Language), XLANG (Microsoftov XLANG: Business modeling language for BizTalk), PIPs (RosettaNet's Partner) su predloženi proces sučelja).
Do danas najveću težinu ima BPEL4WS (Business Process Execution). Jezik za Web usluge), koje proizvode IBM, Microsoft i BEA Systems, a WSCI (Web Service Choreography Interface) tvrtke Sun Microsystems.
Jezik BPEL4WS namijenjen je implementaciji orkestracija usluge.
WSCI jezik odražava koncept koreografija usluge.
WSCI (Web Service Choreography Interface) je jezik opisnog sučelja temeljen na XML-u koji radi u kombinaciji s WSDL-om. Njegov cilj je omogućiti korporacijama da iskoriste snagu web usluga za stvaranje procesa koji odražavaju promjenjive poslovne zahtjeve. Jezik omogućuje tvrtkama da svoje aplikacije i resurse predstave kao web usluge kako bi ih druge tvrtke mogle brzo pronaći i koristiti u svojim poslovnim procesima.
WSCI je od 2002. razvijala radna skupina konzorcija W3C (organizirana je Radna skupina za koreografiju web usluga);
Za razvoj BPEL4WS, tehnički odbor je osnovan u konzorciju OASIS 2003. godine - OASIS Web Services Business Process Execution Language TC (WS-BPEL TC).
BPEL definira ponašanje poslovnih procesa temeljenih na dt,-uslugama.
BPEL implementira funkcionalnost izvoza i uvoza koristeći isključivo sučelja web servisa.
BPEL se uklapa u temeljnu arhitekturu web usluga izgrađenu na temelju UDDI, WSDL, XML i XML sheme.
BPEL je izgrađen na tri ključna svojstva: asinkroniji, koordinaciji niti i rukovanju iznimkama. Svi se oni odnose na izazove s kojima se programeri suočavaju pri upravljanju integracijama.
Asinkronija Asinkronija se bavi asinkronim interakcijama, korelacijom poruka i pouzdanošću. Podrška za asinkroniju potrebna je za omogućavanje web usluga u integracijskim scenarijima i obavezna je za optimalno iskorištenje radnog vremena (za bolju distribuciju obrade, omogućuje korisnicima intervenciju tijekom poslovnog tijeka ili odgođene skupne obrade). Odvajanjem servisnih zahtjeva od njihovih odgovarajućih odgovora, asinkronija poboljšava skalabilnost i pomaže u izbjegavanju uskih grla u izvršavanju aplikacije. Osim toga, omogućuje nesmetano izvršavanje kada su usluge privremeno nedostupne i kada klijenti rade u izvanmrežni način rada ili onemogućeno.
Koordinacija protoka. (Koordinacija niti) Koordinacija niti uključuje paralelnu nit izvođenja, obrasce povezivanja i dinamičke niti. U stvarnim aplikacijama, poslovni tokovi mogu uključivati obrasce složenih interakcija sa sinkronim i asinkronim servisima. Koordinacija niti uključuje sučelje za WSDL, akcije niti, XML varijable i odgovorna je za kompenzaciju. BPEL koristi WSDL za upućivanje na razmijenjene poruke, pozvane operacije i vrste priključaka. Stream radnje koriste zajedničke XML varijable, tako da rukovatelji kompenzacijom moraju spremati snimke podataka koje rukovatelj može koristiti. Kompenzacijski procesori mogu poništiti korake koji su već dovršeni.
BPEL uključuje osnovne i strukturirane aktivnosti. (BPEL uključuje osnovne i strukturirane aktivnosti). Osnovne radnje sastoje se od pojedinačnih koraka za interakciju s uslugom, manipuliranje razmijenjenim podacima ili rukovanje iznimnim uvjetima na koje naiđe tijekom izvođenja. Strukturirane akcije definiraju redoslijed izvršenja i opisuju stvaranje procesa, prevodeći radnje koje izvode u strukture; Ove strukture uključuju protok podataka, kontrolne obrasce, rukovanje vanjskim događajima, rukovanje pogreškama i koordinaciju poruka.
Upravljanje iznimkama. (Upravljanje iznimkama). Upravljanje iznimkama bavi se sinkronim pogreškama, asinkrono upravljanje iznimne situacije i naknade za poslovne transakcije. Kako bismo automatizirali poslovne procese, veliki napor usmjeren na upravljanje iznimkama, a BPEL pojednostavljuje upravljanje iznimkama za web usluge. Kada se pojave iznimke, pozivaju se lokalni rukovatelji pogreškama povezani s web-uslugama, a asinkrone usluge dobivaju obavijest o tim iznimkama.
8.7. Web usluge u ASP.Netu
Tehnologija web usluga u ASP.Netu poboljšava mogućnosti izrade web aplikacija. ASP.Net trenutno podržava dva načina za razvoj i pozivanje web usluga:Preko HTTP protokola (jednosmjerni sinkroni poziv) - XML web usluge;
Preko MCF (Microsoft Communication Fundation) - asinkrone dvosmjerne razmjene poruka - MCF web usluge.
Izrada web usluge (web usluge) u Vizualni studio slično stvaranju web stranice. Također možete koristiti alat za web razvoj Microsoft Visual Web Developer za referencu i korištenje web usluga koje se nalaze u rješenju Visual Web Developer na lokalno računalo, kao i u lokalnom ili vanjskom UDDI imeniku.
Promotrit ćemo izvođenje sljedećih zadataka:
stvaranje jednostavne XML web usluge u Visual Web Developeru;
izrada zasebne web stranice korištenjem web servisa.
8.7.1. Izrada web servisa u ASP .Net. Vodič korak po korak
http://msdn.microsoft.com/ru-ru/library/8wbhsy70.aspx
Otvorite Visual Web Developer.
Na jelovniku Datoteka odaberite stavku Napravite web stranicu.
Datoteka – Nova web stranica
Otvorit će se dijaloški okvir Nova web stranica
U odjeljku odaberite ASP.NET web usluga.
Pritisnite gumb Pregled i odaberite put i naziv usluge.
Na listi Jezik odaberite C#
Pritisnite gumb u redu.
Stvorit će se datoteka Usluga.asmx s poveznicom na šifru usluge
@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" Class="Service" %>
I datoteku s kodom usluge: Service.cs
korištenje sustava;
koristeći System.Linq;
koristeći System.Web;
koristeći System.Web.Services;
Javna služba() (
// Inicijaliziraj komponentu();
Javni niz HelloWorld() (
Vrati "Hello World";
Atribut specificira imenski prostor za web uslugu
Atribut se odnosi na način definiranja WSDL-a
Dodavanje metode dostupnoj putem web usluge vrši se pisanjem odgovarajućeg koda i određivanjem kvalifikatora pristupa metodi kao javnost.
Metoda mora imati atribut
2. Sastavljanje i testiranje web usluge
Spremite uslugu i pokrenite preglednik
Podržane su sljedeće operacije. Za formalnu definiciju, vidi Opis usluge
.
Veza Opis usluge postoji opis usluge na WSDL-u
Veza - Pozdrav svijete opis servisnog poziva. Struktura SOAP zahtjeva i odgovora i kako će izgledati kada se koriste HTTP GET i POST metode.
Za testiranje poziva metode kliknite gumb Pokreni.
http://tempuri.org/"> Pozdrav svijete
Primjer
Usluga koja sadrži dvije metode.
Metoda Example1() vraća niz "Hello from ASP.Net!";
Metoda Summa vraća zbroj dva cijela broja propuštena kroz parametre.
korištenje sustava;
koristeći System.Web;
koristeći System.Web.Services;
koristeći System.Web.Services.Protocols;
javna klasa Usluga: System.Web.Services.WebService
Javna služba() (
//Odkomentirajte sljedeći redak ako koristite dizajnirane komponente
//Inicijaliziraj komponentu();
Javni niz Primjer1() (
Vrati "Pozdrav iz ASP.Neta!";
Javno int Summa(int a, int b)
VS ima ugrađenu Web DeveloperServer, koji se mora pokrenuti kada se usluga pozove. Izrađena web usluga nalazi se na ovom poslužitelju.
Kreirajmo drugu web uslugu za prevođenje temperature (primjer iz MSDN-a)
Moramo izraditi web uslugu koja pretvara temperaturu Fahrenheita u temperaturu Celzija i obrnuto.
Izrada web servisa
U Solution Exploreru(Istraživač rješenja) desni klik na imekreiran web servis
(http://localhost/TemperatureWebService) i zatim odaberite naredbu Dodajte novi element.
U poglavlju Instalirani predlošci Vizualni studio odaberite (Web usluga) i u polju Ime unesite Pretvori.
Provjerite je li potvrdni okvir označen Stavite kod u zasebnu datoteku i pritisnite tipku Dodati.
Ovaj primjer će stvoriti dvije metode u jednoj web usluzi. Prva metoda pretvara temperaturu Fahrenheita u temperaturu Celzija, a druga metoda pretvara temperaturu Celzija u temperaturu Fahrenheita.
Za izradu metoda pretvorbe slijedite ove korake:
Dodajte sljedeći kod u klasu odmah nakon HelloWorld metode:Imajte na umu da imenima funkcija prethodi atribut (>) kao dio deklaracije funkcije.
Nakon unosa funkcija spremite datoteku.
Puni kod dano je u nastavku.
koristeći System.Collections;
koristeći System.Linq;
koristeći System.Web;
koristeći System.Web.Services;
koristeći System.Web.Services.Protocols;
koristeći System.Xml.Linq;
/// Sažeti opis za Convert
// Da biste omogućili pozivanje ove web-usluge iz skripte, koristeći ASP.NET AJAX, uklonite komentare iz sljedećeg retka.
javna klasa Pretvori: System.Web.Services.WebService (
public Convert() (
//Odkomentirajte sljedeći redak ako koristite dizajnirane komponente
//Inicijaliziraj komponentu();
Javni niz HelloWorld() (
Vrati "Hello World";
Javni dvostruki FahrenheitToCelsius (dvostruki Fahrenheit)
Povratak ((Fahrenheit - 32) * 5) / 9;
Javni dvostruki CelsiusToFahrenheit (dvostruki Celzijus)
Povratak ((Celzija * 9) / 5) + 32;
Sada možete testirati web uslugu u Visual Web Developeru.
Da biste testirali web uslugu, slijedite ove korake:
U Solution Exploreru odaberite Convert.asmx i pritisnite CTRL+F5.
Pritisnite gumb Celzija do Fahrenheita, koji poziva ovu metodu.
U polju Celzija unesite 100 i kliknite gumb Poziv.
Zatvorite preglednik koji sadrži rezultate metode.
U izvornom pregledniku kliknite leđa za povratak na popis metoda.
Klik FahrenheitToCelsius i uvjerite se da metoda vraća očekivani rezultat.
Zatvorite preglednik.
Nakon što završite s izradom web usluge, sljedeći korak je njezina upotreba.
8.7.2. Korištenje web usluge u aplikaciji
Sada kada je web servis kreiran, izradit ćete web stranicu koja će koristiti kreirani web servis. Morate izraditi zasebno web mjesto sa stranicom s koje će se pokretati novostvorene metode web servisa.
Da biste to učinili, morate izraditi klijentsku aplikaciju (korisnika usluge). Kreirajmo ASP.Net stranicu kao takvog klijenta.
Na primjer, stvorimo stranicu s dva gumba, kada se klikne, pozivat će se usluge.
Poziv web servisu iz klijentske aplikacije ostvaruje se putem posredničke klase (proxy klasa).
1. Napravite web stranicu:
Na jelovniku Datoteka odaberite stavku Napravite web stranicu.
U poglavlju Instalirani predlošci Visual Studio Izaberi ASP.NET web mjesto.
Unesite naziv TemperatureWeb.
Na listi Jezik odaberite C#
Pritisnite gumb u redu.
Web usluga je komponenta koja se može referencirati u aplikaciji. Stoga je potrebno izraditi poveznicu na njega.
Da biste stvorili vezu na web uslugu, slijedite ove korake:
Na jelovniku Web stranica odaberite tim Dodajte web vezu.
Na listi URL-ovi unesite sljedeći URL za web uslugu i kliknite gumb Tranzicija:
Kada Visual Web Developer pronađe web uslugu, informacije o web usluzi prikazuju se u dijaloškom okviru Dodavanje web veze.
| Bilješka |
| Ako ne možete dodati referencu web usluge, proxy možda nije ispravno konfiguriran. U Microsoft Internet Exploreru, u izborniku Servis odaberite stavku Internet opcije, odaberite karticu Veze a zatim kliknite gumb LAN postavke. Označite kućicu Ne koristite proxy za lokalne adrese. Također, postavite polje adrese proxy poslužitelja na točan naziv proxy poslužitelja, umjesto internetske dozvole Explorer automatski otkriva proxy poslužitelj. Za više informacija obratite se svom mrežnom administratoru. |
Odaberite jednu od poveznica metode.
Pritisnite gumb Dodaj vezu.
Bilješka.
Web Developer Server mora biti pokrenut/
3. Nazovite servis s ASP stranice
Primjer 1: Izračunavanje zbroja brojeva
1. Napravite obrazac s dva tekstualna polja i gumbom Iznos.
U rukovatelju gumbima dodajte poziv metode.
Povežite prostor imena localhost
korištenje sustava;
koristeći System.Data;
koristeći System.Configuration;
koristeći System.Web;
koristeći System.Web.Security;
koristeći System.Web.UI;
koristeći System.Web.UI.WebControls;
koristeći System.Web.UI.WebControls.WebParts;
koristeći System.Web.UI.HtmlControls;
korištenje lokalnog hosta;
javna djelomična klasa _Default: System.Web.UI.Page
Zaštićeni void Page_Load(pošiljatelj objekta, EventArgs e)
Zaštićeni void Button1_Click(pošiljatelj objekta, EventArgs e)
Usluga myService= nova usluga();
Label1.Text = myService.Example1();
Zaštićeni void Button2_Click(objekt pošiljatelj, EventArgs e)
Int a, b, zbroj;
A = int.Parse(txt_a.Text);
B = int.Parse(txt_b.Text);
// zbroj = a + b;
Usluga mojaServica1 = nova Usluga();
Zbroj = mojaUsluga1.Zbroj(a,b);
Txt_summa.Tekst = summa.ToString();
Primjer 2: Pozivanje metoda pretvorbe temperature
Napravite obrazac na stranici sa sljedećim poljima:
Da biste pozvali metode web usluge, slijedite ove korake:
Otvorite stranicu Default.aspx i prebacite se na prikaz dizajna.
Iz grupe Standard U okviru s alatima povucite sljedeće kontrole na stranicu i postavite njihova svojstva kao što je prikazano u sljedećoj tablici:
zaštićeno void ConvertButton_Click(objekt pošiljatelj, EventArgs e)
Localhost.Convert wsConvert = new localhost.Convert();
Dvostruka temperatura =
System.Convert.ToDouble(TemperatureTextbox.Text);
FahrenheitLabel.Text = "Fahrenheit u Celzijus = " +
WsConvert.FahrenheitToCelsius(temperature).ToString();
CelsiusLabel.Text = "Celsius To Fahrenheit = " +
WsConvert.CelsiusToFahrenheit(temperature).ToString();
Pritisnite CTRL+F5 za pokretanje stranice.
U tekstualno polje unesite vrijednost, na primjer 100 , i pritisnite tipku Pretvoriti.
Web uslugu možete ispraviti na isti način kao i web stranice.
Najprije morate konfigurirati web mjesto koje sadrži web uslugu da omogući otklanjanje pogrešaka.
Da biste omogućili uklanjanje pogrešaka na web-mjestu web-servisa, slijedite ove korake:
Alat za administraciju web-mjesta stvorit će datoteku Web.config za web-mjesto i postaviti opcije konfiguracije za omogućavanje otklanjanja pogrešaka.
Zatvorite alat za administraciju stranice.
Da biste omogućili uklanjanje pogrešaka na web-mjestu, slijedite ove korake:
Visual Web Developer će otvoriti kodnu datoteku za stranicu.
Postavite pokazivač na sljedeću liniju:
Otkrivanje web servisa
Kako drugi programeri znaju za postojanje web usluge?Prvo, korištenjem DISCO (skraćenica od riječi discovery) - datotečnog mehanizma za pretraživanje lokalnih web servisa, odnosno mehanizma za dobivanje popisa dostupnih web servisa iz DISCO datoteka smještenih na web poslužiteljima. Osim toga, DISCO datoteke sadrže zapise o lokaciji WSDL ugovora dostupnih usluga. DISCO datoteka je XML datoteka sa zapisima.
Također je moguće koristiti VSDISCO datoteke, koje su slične DISCO datotekama, ali je njihov sadržaj rezultat dinamičke pretrage web servisa u određenim direktorijima i svim poddirektorijima. ASP .NET preslikava ekstenziju naziva datoteke .vsdisco u HTTP rukovatelj, koji traži u ovaj katalog i njegove poddirektorije asmx i disco i vraća dinamički generirani DISCO dokument. Iz sigurnosnih razloga, dinamičko pretraživanje je onemogućeno u nekim verzijama .NET Frameworka, ali ga možete omogućiti uređivanjem unosa u datoteci Machine.config.
Kako pretražujete web usluge na globalnoj mreži? Za traženje web usluga na globalnoj mreži Microsoft, IBM i Ariba zajednički su razvili UDDI (Universal Description Discovery and Integration) – specifikaciju za izgradnju distribuiranih baza podataka koja vam omogućuje pretraživanje web usluga. UDDI podržavaju stotine tvrtki. UDDI stranice same su web usluge. Svatko može objaviti svoj registar temeljen na UDDI. Većina programera nikada ne koristi UDDI API izravno. Umjesto toga, UDDI registrima pristupaju razvojni alati. Oni također generiraju klase omotača za otkrivene i odabrane web usluge.
8.8. Rezultati
Tehnologija Web usluge- Ovo Moderna tehnologija, koji pruža novu razinu distribucije. Umjesto razvoja ili kupnje komponenti i njihovog ugrađivanja u IS, predlaže se kupiti njihovo vrijeme rada i formirati softverski sustav koji poziva metode od komponenti koje su u vlasništvu i koje podržavaju neovisni dobavljači.Web usluge riješiti problem integriranja aplikacija različite prirode i izgradnje distribuiranih informacijskih sustava. Ovo je glavna temeljna razlika između web usluga i njihovih prethodnika - tehnologija za interakciju distribuiranih aplikacija, koje su na ovaj ili onaj način omogućile implementaciju razmjene podataka između aplikacija (među najrazvijenijima su Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) ) i Common Object Request Broker Architecture (CORBA)). Međutim, svaki od njih bio je prilično složen za implementaciju, nije imao potrebnu univerzalnost (odnosno, još uvijek je ovisio o izboru npr. istog operativnog sustava za sve sudionike u razmjeni) i, što je posebno loše, te je tehnologije bilo vrlo teško međusobno integrirati.
Web usluge- nova riječ u tehnologiji distribuiranih sustava. Specifikacija Otvoreno mrežno okruženje (ONE) Sun Microsystems Corporation i inicijativa. Microsoftov Net pruža infrastrukturu za pisanje i implementaciju web usluga. Trenutno postoji nekoliko definicija web usluge. Web usluga može biti bilo koja aplikacija koja ima pristup webu, kao što je web stranica s dinamičkim sadržajem. U više u užem smislu Web usluga je aplikacija koja pruža otvoreno sučelje koje mogu koristiti druge aplikacije na webu. ONE Sun specifikacija zahtijeva da web usluge budu dostupne preko HTTP-a i drugih web protokola, da se omogući razmjena informacija putem XML poruka i da se mogu pretraživati putem usluga pretraživanja. Za pristup web servisima razvijen je poseban protokol - Jednostavni protokol za pristup objektu (SOAP), koji uvodi interoperabilnost temeljenu na XML-u za mnoge web usluge. Web usluge su posebno atraktivne jer mogu pružiti visok stupanj kompatibilnosti između različitih sustava.
Hipotetska web usluga razvijena prema Sunovoj ONE arhitekturi mogla bi imati oblik registra usluga koji objavljuje opis web usluge kao dokument .
Ogroman potencijal web usluga nije određen tehnologijom koja se koristi za njihovu izradu. HTTP, XML i drugi protokoli koje koriste web usluge nisu novi. Interoperabilnost a skalabilnost web usluga znači da programeri mogu brzo stvarati velike aplikacije i veće web usluge od manjih web usluga. Specifikacija Sun Open Net Environment opisuje arhitekturu za stvaranje inteligentne web usluge.Inteligentne web usluge koriste zajedničko radno okruženje. Dijeljenjem konteksta, inteligentne web usluge mogu izvesti standardnu autentifikaciju za financijske transakcije, dati preporuke i smjernice na temelju geografske lokacije tvrtki uključenih u transakciju. e-poslovanje.
Za izradu aplikacije koja je Web servis potrebno je primijeniti niz tehnologija.
Odnos između ovih tehnologija konvencionalno je prikazan na slici. 10.1.
Riža. 10.1.
Zapravo, web usluge su jedna od mogućnosti implementacije komponentna arhitektura, u kojem se aplikacija smatra skupom komponenti koje međusobno djeluju. Kao što je već mnogo puta rečeno, interakcija komponenti koje se izvode na različitim platformama prilično je složen zadatak, posebno zahtijeva razvoj komunikacijski protokol, uzimajući u obzir značajke prijenosa podataka između različitih platformi. Jedna od glavnih ideja na kojima se temelji razmatrana tehnologija web usluga je odbacivanje binarnog zapisa komunikacijski protokol. Poruke se razmjenjuju između komponenti sustava odašiljanjem XML poruka. Budući da su XML poruke tekstualne datoteke, prijenosni transportni protokol može biti vrlo različit - XML poruke se mogu prenositi putem HTTP, SMTP, FTP protokola, a korištenje različitih transportnih protokola je transparentno za aplikacije. Kao što je već spomenuto, poziva se protokol koji omogućuje interakciju web usluga SAPUN (Jednostavni protokol za pristup objektu). Definiran je na temelju XML-a. SAPUN osigurava interakciju distribuiranih sustava, bez obzira na korišteni objektni model ili platformu. Podaci unutar SAPUN prenosi u obliku XML dokumenata posebnog formata. SAPUN ne nameće nikakav poseban transportni protokol. Međutim, u stvarnim primjenama prijenos se najčešće provodi SAPUN-poruke od HTTP protokol. Također se široko koristi kao prijevoz SMTP protokol, FTP pa čak i "čisti" TCP. Tako, SAPUN definira mehanizam pomoću kojeg Web usluge mogu međusobno pozivati funkcije. U određenom smislu, rad ovog protokola podsjeća na udaljeni poziv procedure - pozivatelj zna ime web servisa, naziv njegove metode, parametre koje metoda prihvaća i formalizira poziv ove metode u obliku SAPUN-poruku i šalje je web servisu.
Međutim, opisani pristup prikladan je samo ako su unaprijed poznati “potpisi” metoda koje Web servis implementira. Ali što ako to nije slučaj? Kako bi se riješio ovaj problem, u model web usluge uveden je dodatni sloj - sloj za opisivanje servisnih sučelja. Ovaj sloj je predstavljen kao opis WSDL.
Kao što definira W3C, " WSDL- XML format za opis mrežne usluge kao skup konačnih operacija koje rade pomoću poruka koje sadrže informacije orijentirane na dokument ili proceduru." Dokument WSDL u potpunosti opisuje sučelje web usluge s vanjskim svijetom. Pruža informacije o uslugama koje se mogu dobiti pomoću metoda usluga i kako pristupiti tim metodama. Dakle, ako potpis metode web usluge nije točno poznat (na primjer, promijenio se tijekom vremena), ciljna web usluga može se upitati WSDL-opis - datoteka u kojoj će biti sadržane te informacije.
Sljedeći sloj tehnologije je usluga Univerzalni opis, otkriće i integracija (UDDI).Ova tehnologija uključuje održavanje registra web usluga. Spajanjem na ovaj registar potrošač može pronaći web usluge koje najbolje odgovaraju njegovim potrebama. Tehnologija UDDI omogućuje pretraživanje i objavu željene usluge, a te radnje može obavljati osoba ili neka druga Web usluga ili poseban klijentski program. UDDI, pak, također je web usluga.
Stoga su web usluge još jedna implementacija sustava međuprogramska oprema. Posebnost ove tehnologije je njezina neovisnost o korištenom softveru i hardveru, kao i korištenje široko korištenih otvoreni standardi(kao što je XML) i standardne komunikacijske protokole.
Trenutno su web usluge vrlo aktivno promovirana tehnologija i pozicionirane su kao sredstvo za rješavanje brojnih problema.
Treba napomenuti da se njihovom upotrebom mogu izgraditi takozvane "standardne" aplikacije, gdje se poslužiteljski dio.
Jednostavni protokol za pristup objektu (SOAP)
Osnovni protokol koji osigurava interakciju u okruženju web usluga je
U ovom članku želim raspravljati o pitanjima vezanim uz dizajn web usluga namijenjenih međuprogramskoj interakciji. Takozvani integracijski web servisi. Prije svega, to su usluge koje će raditi u razna rješenja Enterprise Applications Integration (EAI) klasi, kao iu B2B rješenjima. Mnoge knjige i članci posvećeni su problemima razvoja web servisa korištenjem različitih platformi, ali su pitanja dizajna pokrivena mnogo slabije. Možete pronaći puno članaka sa SOA mantrama koji će biti potpuno beskorisni kada počnete dizajnirati svoj web usluga.
Dakle, razmotrimo situaciju u kojoj imate dva radna sustava (ili projekte dvaju sustava) i suočeni ste sa zadatkom organiziranja interakcije između njih. Umorni ste od shema sinkronizacije temeljenih na datotekama za uvoz/izvoz, a odabrali ste modernu, modernu i praktičnu tehnologiju web usluga. Pokušat ću govoriti o tome na što trebate obratiti pozornost i kako izbjeći uobičajene pogreške pri dizajniranju web usluge za interakciju dva sustava.
Malo SOA-e
Pa ipak, prvo nekoliko riječi o dobro poznatoj SOA-i. Pojam Service Oriented Architecture (SOA) dosta je pretrpio neselektivnu upotrebu u marketinške svrhe. Toliko se često koristi u raznim kontekstima da je sada teško reći bilo što određeno o SOA-i osim da je to "uslužno orijentirana arhitektura".Međutim, SOA ima isto pravo na život kao i "arhitektura klijent-poslužitelj" ili "višeslojna arhitektura". Kao i svaka druga "arhitektura", SOA uvodi niz apstrakcija i pravila koja nam pomažu u razvoju određene klase aplikacija. U ovom konkretnom slučaju, korisno je voditi se načelima SOA-e pri razvoju mehanizama za interakciju i integraciju aplikacija u cijelom poduzeću (Enterprise Applications Integration - EAI).
Dakle, počnimo s činjenicom da SOA aplikacije smatra servisima ili zbirkama servisa koji razmjenjuju poruke izravno ili putem nekih integracijskih mehanizama. Ove usluge moraju zadovoljiti niz uvjeta ili zahtjeva.
Prvo, usluga mora imati određenu “poslovnu vrijednost”, drugim riječima, usluga mora imati praktičnu vrijednost. Ako korisniku ili korisniku sustava ne možete jednostavnim riječima objasniti za što je vaša usluga potrebna, onda je to sa SOA gledišta propala usluga. Primjer loše usluge: "Usluga za dobivanje globalno jedinstvenih identifikatora." Primjer dobrih usluga: “Servis podataka o zaposlenicima poduzeća” ili “Servis za prijem i obradu faktura za plaćanje” (Accounts Payable).
Drugo, iz perspektive SOA-e, usluge moraju biti autonomne i neovisne. To je potrebno kako bismo, kao što je to uobičajeno u SOA-i, mogli kombinirati neke usluge s drugima ovisno o poslovnim potrebama. Ako želimo koristiti “Servis zaprimanja i obrade faktura naplativih” i pritom saznamo da ćemo morati instalirati i koristiti “Servis proračuna i financijskog planiranja”, “Servis glavne knjige” i još desetak usluge, onda sa stajališta SOA-e sve to izgleda samo degutantno.
Treće, usluga mora biti funkcionalno cjelovita s aplikativnog gledišta. Ovaj zahtjev je komplementaran prethodnom. Na primjer, “Servis za primanje i obradu faktura za plaćanje” omogućuje dodavanje aplikacije, ali ne dopušta praćenje njenog statusa. Ali u principu možemo dobiti izvješće o prijavama iz kojeg možemo saznati status prijave. Nije li ovo poznata situacija? Sa stajališta SOA-e, i s bilo kojeg stajališta, to nije točno. Usluga mora osigurati izvođenje svih osnovnih poslovnih operacija povezanih s aplikacijskim područjem ili poslovnim procesom koji pruža.
Četvrto, sve usluge moraju moći pružiti svoje opise u nekom standardiziranom formatu. WSDL i UDDI su varijante formata opisa usluge.
Peto, usluge bi trebale biti usmjerene prema distribuiranoj, asinkronoj komunikaciji bez stanja. Ovo je tipično za većinu modernih distribuiranih sustava i vrlo je važan zahtjev. Dovoljno je prisjetiti se da je klijent-poslužiteljska arhitektura usmjerena na sinkronu interakciju s pohranom stanja, te je upravo ta okolnost postala ključno ograničenje za daljnji razvoj ove arhitekture.
Šesto, SOA pretpostavlja da će se ispunjavanjem prethodnih zahtjeva servisi moći kombinirati kako bi međusobno komunicirali koristeći različite alate za integraciju, kao što su brokeri poruka i usmjerivači, poslužitelji za tijek rada itd. i tako dalje. Ključna točka ovdje je činjenica da će se scenariji integracije temeljiti na konfiguraciji, često vizualnoj, a ne na razvoju posebnog "integrirajućeg" koda, kao što se sada radi u većini slučajeva.
Ovako otprilike izgledaju glavne prekretnice na koje bismo se trebali fokusirati i koje bi trebale ograničiti naša divlja dizajnerska razmišljanja u procesu dizajniranja i razvoja integracijskih web usluga.
Izrada ugovora o uslugama.
Nakon što je Microsoft upotrijebio izraz "ugovor o uslugama" u svojoj platformi Windows Communication Foundation - WCF (bivši Indigo), ima sve šanse da postane de facto standardni izraz.Ugovor o usluzi opis je potpisa svih njegovih operacija (metoda), plus opis formata podataka s kojima radi kao ulazne i izlazne poruke.
Za web usluge, ugovor je sveobuhvatno opisan WSDL shemom usluge. Međutim, složit ćete se da WSDL nije baš dobro prilagođen ljudskoj percepciji. Ugovor se može mnogo jasnije prikazati kao UML dijagram klasa. Srećom, većina moderne platforme za razvoj web usluga pružaju funkciju automatskog generiranja WSDL opisi usluge.
Pravilno sastavljen ugovor o uslugama ključ je uspjeha i jamstvo da će vaša usluga živjeti dug i sretan život, te umrijeti prirodnom smrću, jer će je zamijeniti nova tehnologija o kojoj trenutno ne znamo ništa.
Microsoft nudi poseban pojam– "prvo ugovor" za opisivanje pristupa dizajnu kojim se prvo ugovori. On pretpostavlja da dizajn usluge treba započeti s opisom shema XSD poruka (podataka), zatim se kreira WSDL opis operacija usluge, iz kojeg se generira kod klase usluge. I tek nakon toga počinju provoditi logiku. Ideja je dobra, no ponovit ću da rad s XSD-om i WSDL-om nije baš zgodan, čak ni korištenjem vizualnih alata poput XmlSpy-a. Osim toga, sam princip "prvo kontaktirajte" ne jamči da ćemo dobiti ispravan ugovor o usluzi.
Za mene načelo "prvo kontaktiraj" znači da pri dizajniranju usluge prvo trebamo razmišljati o njezinom ugovoru, a tek na kraju o detaljima implementacije. Buduću uslugu trebate gledati izvana, kroz oči korisnika podataka ove usluge. Ovaj prikaz pojednostavljuje prijenos zahtjeva za uslugu u skup operacija koje pruža. Na primjer, razvijamo uslugu koja pruža podatke o zaposlenicima tvrtke. Logično je u njega uključiti operaciju koja vraća popis svih zaposlenika. Međutim, tijekom analize zahtjeva može se ispostaviti da će potrošača naših servisnih podataka prije svega zanimati popis zaposlenika određenog odjela. To nam govori da bismo ugovoru operacije trebali dodati parametar koji vraća popis zaposlenika koji nam omogućuje filtriranje zaposlenika određenog odjela ili bismo ovu radnju trebali odvojiti u zasebnu radnju usluge. Ovaj pristup će biti u skladu s načelom "prvo ugovor". Suprotno tome, korisniku naših servisnih podataka mogli bismo dodijeliti odgovornost da s opće liste odabere zaposlenike odjela koji su mu potrebni. Pridržavanje takve strategije pri dizajniranju integracijskih usluga loša je praksa. Analizirajući ovaj konkretan slučaj, možemo reći da ovakvo rješenje nije optimalno sa stajališta opterećenja usluge ili količine prometa, te da ovakvo rješenje smanjuje sigurnost. Ukratko, možemo reći da načela jednostavnosti i univerzalnosti ne bi smjela prevladati prilikom dizajniranja usluge. Svestranost usluge mora se postići pažljivim dizajnom. Iznimno je teško dati bilo kakve praktične preporuke u tom smjeru. Nije lako napraviti uslugu koja se ne bi sastojala od jedne metode koja izbacuje sve interne podatke sustava van, a pritom bi bila dovoljno univerzalna da je može koristiti ne samo potrošač za kojeg ste dizajnirali usluga, ali i bilo tko drugi. Da biste to postigli, trebali biste obratiti pozornost na funkcionalnu cjelovitost ugovora o uslugama.
Pogledajmo primjer. Pretpostavimo da postoji određeni sustav za računovodstvo i usklađivanje obveza prema dobavljačima, iz kategorije onih označenih pojmom Računi prema dobavljačima. Sustav omogućuje unos podataka o fakturama, osigurava poslovni proces za njihovo usklađivanje, a zatim u interakciji s računovodstvenim sustavom generira plaćanja. Računi se unose i odobravaju putem korisničkog sučelja sustava. Pred nama je zadatak: izraditi web servis putem kojeg bi drugi sustavi mogli kreirati fakture i pratiti njihov status.
Radi jednostavnosti, pretpostavit ćemo da faktura koja se plaća ima sljedeću strukturu:
Gdje:
Broj – jedinstveni broj računa koji se dodjeljuje prilikom kreiranja
RecipientID – poveznica na imenik ugovornih strana u kojem se pohranjuju svi podaci o primatelju plaćanja
Iznos – iznos koji treba platiti
PaymentDate – datum plaćanja
CategoryID – poveznica na imenik kategorija plaćanja
Vlasnik - ime zaposlenika koji je kreirao račun
Opis – opis
Stanje – stanje računa oko kojeg se gradi poslovni proces odobravanja računa.
Dakle, početni zahtjevi su nam jasni. Jasna je i shema podataka za prikaz fakture. Na temelju prikazanog dijagrama kreirat će se sljedeća XML shema koja nam dosta odgovara:
Pokušajmo sada skicirati potpis uslužnih metoda. Na temelju zahtjeva, jasno nam je da usluga mora sadržavati metode koje omogućuju kreiranje, pregled i brisanje računa za plaćanje. Rezultat je usluga s tri metode:
Izgleda jednostavno užasno! Idemo shvatiti što ovdje nije u redu.
Metoda AddPayment() za dodavanje računa uzima strukturu plaćanja kao parametar i vraća broj dodijeljen računu. Struktura plaćanja nije baš prikladan tip podataka za parametar ove metode, jer sadrži niz polja, čije je popunjavanje podložno internoj poslovnoj logici sustava. Ovo su polja Broj, Država i Vlasnik. Ne poznajemo ova poslovna pravila i ne znamo kako popuniti ova polja. Za izradu fakture potrebno je navesti: primatelja, iznos uplate, datum, kategoriju i opis. Stoga ima smisla kreirati metodu s upravo tim parametrima koja će kreirati fakturu za plaćanje i vratiti je u strukturi Plaćanje.
Metoda ListPayments() vraća popis računa kao niz struktura plaćanja. Možda bi sustav trebao vraćati samo fakture koje je izradio određeni korisnik. Međutim, nepostojanje odgovarajućeg parametra u potpisu metode ne bi vas trebalo iznenaditi. Pouzdaniji i sigurniji način dobivanja korisničkih podataka je njihovo preuzimanje iz podataka za provjeru autentičnosti. S vremenom se u sustavu zna nakupiti ogroman broj računa, a ovoj metodi bi dobro došli parametri za filtriranje izdane liste po datumu.
Konačno, metoda RemovePayment() uzima broj računa i vraća true ako je uklanjanje bilo uspješno, a false u suprotnom. Korištenje Booleovog kao rezultata nije najbolje rješenje u ovom slučaju. Razlozi neuspjeha operacije brisanja mogu biti vrlo različiti od jednostavnog nepostojanja računa s navedenim brojem, do kršenja logičkih ograničenja sustava (na primjer, račun sa statusom Committed ne može se izbrisati). Situacija je prilično česta. Pogreška se može dogoditi prilikom izvršavanja bilo koje metode web servisa, a na sreću okvir web servisa nudi standardni pristup rješavanju ovog problema. Za prijenos podataka o pogrešci koristi se SOAP poruka čije tijelo sadrži element Fault s informacijama o pogrešci. Na ovaj način ne trebamo produžiti naš ugovor o web-usluzi za prosljeđivanje poruka o pogrešci, a u slučaju metode RemovePayment(), možemo u potpunosti odustati od povratne vrijednosti. Ako brisanje računa ne uspije, informacije o razlogu bit će navedene u poruci pogreške.
Nakon svih promjena, naš web servis će izgledati ovako:
Izgleda puno bolje, ali problemi ostaju.
Pogledajmo metodu CreatePayment(). Da bismo kreirali račun, moramo proslijediti pet parametara. Nemamo problema s parametrima iznos, datum, desc. Ali gdje pronaći poveznice na primatelja i kategoriju? Kao što sam već napomenuo, ovi podaci su poveznice na elemente odgovarajućih imenika našeg sustava. I sada nam postaje jasno da kako bismo uspješno koristili našu web uslugu, moramo omogućiti pristup vrijednostima ovih direktorija.
Tako je konačni oblik našeg ugovora o web usluzi dopunjen s dvije metode EnumRecipient() i EnumCategory() te dva tipa podataka RecipientInfo i CategoryInfo. Nisu bile u izvornom ugovoru i potreba za ovim metodama nije određena izvornim zahtjevima. Oni služe za osiguranje sintaktičke potpunosti našeg ugovora o pružanju usluga. Potrošač podataka usluge sada može pozvati metode EnumRecipient() i EnumCategory() za dobivanje popisa primatelja i kategorija, odabrati željene vrijednosti iz njih, a zatim pozvati metodu CreatePayment() za izradu fakture.
Sada možemo reći da smo osmislili funkcionalno i sintaktički cjelovitu uslugu. Također, naša usluga je prilično univerzalna, te se s velikom vjerojatnošću može koristiti za integraciju s drugim sustavima koji će se suočiti sa sličnim zadaćama. Osim toga, ugovor o usluzi i njegov WSDL opis uključuju kompletne podatkovne sheme za sve poruke. Ovo je vrlo važno kako bi naša usluga mogla koristiti integracijske alate kao što su BizTalk Server, Fiorano ESB, Sonic ESB itd.
Želio bih skrenuti pozornost na posljednju točku. Format podataka koje usluga razmjenjuje vrlo je važan. Programeri često padaju u jednu od dvije krajnosti. Prvi od njih je korištenje "golog Xml" kao formata za sve poruke. Razlozi za to mogu biti vrlo različiti, od pokušaja korištenja postojećeg koda za uvoz i izvoz Xml podataka, do previše doslovnog shvaćanja biti web servisa kao mehanizma za razmjenu Xml poruka. Nedostatak ovog pristupa je prilično očit - podatkovna shema nije uključena u WSDL opis ugovora o usluzi, što otežava korištenje. Po mom mišljenju postoji samo jedan slučaj kada je takav pristup opravdan. To je slučaj kada unaprijed ne znamo format prenesenih podataka. U svim drugim slučajevima treba koristiti upisane poruke.
Druga krajnost je suprotna prvoj, a izražava se u činjenici da programeri pokušavaju koristiti unutarnje formate za prikaz podataka koji postoje u sustavu u ugovoru o usluzi. Doista, ako sustav već definira strukture i klase za predstavljanje podataka (Data Transfer Objects), zašto ih onda ne koristiti u ugovoru o uslugama? Ovo nije uvijek dobra ideja. Interni formati podataka možda neće biti prikladni za klijenta usluge. Mogu imati određeni format koji nije podržan od strane klijenta. Primjer takvog DataSet formata iz Microsoft ADO.NET. DataSet podaci savršeno se pretvaraju u XML i mogu ih koristiti ASP.NET web servisi. Međutim, ovo je interno Microsoftov format, koji nije industrijski standard, ima vlastite značajke oblikovanja XML-a koje mogu otežati drugim softverskim platformama web usluga korištenje ovih podataka. Postoje mnogi slučajevi u kojima je korištenje DataSeta opravdano i zgodno, ali usluge integracije nisu jedan od njih.
Dakle, opće preporuke za dizajniranje formata poruka za web usluge svode se na sljedeće. Uvijek pokušajte koristiti upisane poruke čiji je format opisan specifičnom Xsd shemom. Oblikujte format poruke na temelju funkcionalnih zahtjeva i samo ako rezultirajući format odgovara internom formatu podataka sustava, trebali biste razmotriti korištenje internog formata.
Protokol interakcije i njegov utjecaj na ugovor
Pod protokolom interakcije web usluge podrazumijevamo onaj dio zahtjeva koji opisuje slijed interakcije između usluge i klijenta, smjer prijenosa podataka, kao i takve aspekte ponašanja usluge kao što su transakcija, asinkronija itd. .Protokol interakcije i ugovor o usluzi vrlo su blisko povezani. Osim toga dovoljno jednostavni slučajevi, kada postoji jedna usluga i njen klijent, postoje i složeniji kod kojih protokol interakcije zahtijeva prisutnost dvije ili više usluga. Primjer takvog protokola je asinkroni komunikacijski protokol ASAP
Neću odati veliku tajnu ako kažem da je izvrstan način za izradu ugovora o usluzi (barem u smislu uključenih operacija) korištenje UML dijagrama interakcije. Moje osobno mišljenje je da se najbolji rezultati postižu korištenjem sekvencijskog dijagrama. Slika prikazuje dijagram slijeda interakcije između klijenta i usluge iz primjera AccountsPayable o kojem se raspravljalo gore. Nažalost, ovaj je primjer dovoljno jednostavan da dobijete osjećaj kako dijagrami sekvenci olakšavaju izradu ugovora o uslugama.
U najsloženijim slučajevima može biti potrebno konstruirati dijagram stanja za protokol interakcije. U ovom slučaju prijelazi u grafikonu stanja predstavljat će operacije usluge.
Sigurnosna pitanja
Nakon što je ugovor o uslugama razrađen, a ponekad čak i ranije, dizajner se suočava sa sigurnosnim problemima u punoj snazi. Vremena kada su se web servisi nazivali nezrelom tehnologijom koja ne može osigurati sigurnost podataka davno su prošla. Web usluge mogu biti pouzdane i sigurne. Ili možda neće. Sve ovisi o nama.Dopustite da navedemo niz problema koje je potrebno riješiti kako bi se dizajnirala sigurna usluga:
- Autentifikacija klijenata usluge
- Autorizacija servisnih klijenata
- Sigurnost prijenosa podataka
- Pohranjivanje identiteta za povezivanje klijenata sa uslugom
Autorizacija je proces dodjele korisniku ovlasti za pristup funkcijama i podacima. Naravno, da bi autorizirali korisnika, on mora biti prvo autentificiran. Razumjeti razliku između autentifikacije i autorizacije. Autentifikacija odgovara na pitanje "tko" je klijent, a autorizacija odgovara na pitanje "što" ovaj klijent može učiniti. U velikoj većini slučajeva poslovna pravila kojima se pojedinom korisniku dodjeljuju prava pristupa određenim podacima i radnjama definiraju se u samoj aplikaciji. Stoga je autorizacija odgovornost aplikacije koja pruža uslugu. Postoje mnoge metode, prakse i obrasci za implementaciju autorizacijskih mehanizama, čiji bi opis mogao biti tema zasebnog članka.
Uz autentifikaciju i autorizaciju, zaštita podataka prilikom prijenosa između servisa i klijenta treća je komponenta u osiguravanju sigurnosti web servisa. Stupanj zaštite određen je prirodom podataka. Postoje dva načina zaštite podataka: digitalni potpis i enkripcija.
Za potvrdu autentičnosti podataka koristi se digitalni potpis. Ne štiti podatke od neovlaštenog čitanja jer podaci nisu šifrirani. Digitalni potpis omogućuje vam da provjerite da podaci pripadaju vlasniku potpisa, kao i da podaci nisu mijenjani od potpisa. Mehanizam digitalnog potpisa vrlo je jednostavan. Temelji se na korištenju asimetričnih algoritama šifriranja, koji koriste par ključeva od kojih je jedan privatni (zatvoren), a drugi javni (otvoren). Osobitost asimetričnih algoritama je da se podaci koji su šifrirani jednim ključem mogu dešifrirati samo drugim ključem. Digitalni potpis se formira na sljedeći način. Za podatke se izračunava kontrolni zbroj (hash code) koji je kriptiran privatnim ključem vlasnika digitalnog potpisa. Ovo je digitalni potpis; dodaje se podacima. Također, podacima se može dodati javni ključ. Pomoću javnog ključa svaki korisnik može dekriptirati digitalni potpis i dobiti kontrolni zbroj s kojim se može usporediti kontrolni zbroj izračunati na temelju trenutnih podataka i tako saznati jesu li se podaci promijenili.
U slučajevima kada ne samo da moramo osigurati nepromjenjivost podataka, već i sakriti njihov sadržaj od stranaca, koristi se enkripcija. Obično se pri prijenosu podataka koristi shema ključa sesije, na čijem se mehanizmu neću zadržavati, jer se obično daje na razini infrastrukture. Dakle, digitalni potpis i enkripcija su glavni mehanizmi za zaštitu podataka tijekom prijenosa. Te mehanizme možemo omogućiti na razini transportnog protokola ili na razini SOAP poruke. Svaka metoda ima svoje prednosti i nedostatke.
Kako bi se osigurala zaštita podataka na razini transportnog protokola, obično se koristi dobro dokazani SSL mehanizam. U tom slučaju između klijenta i poslužitelja uspostavlja se sigurna veza u kojoj je sav promet šifriran. Prednost ovog pristupa je u tome što ne zahtijeva praktički nikakav dodatni napor od strane programera (uz moguću iznimku nekih značajki prilikom uspostavljanja veze). Glavni posao postavljanja sigurne SSL veze obavlja se prilikom postavljanja aplikacije. Nedostaci ovakvog pristupa su činjenica da je sav promet šifriran, a ne samo podaci koji su doista povjerljivi, a to zahtijeva mnogo računalnih resursa. Opis kako koristiti SSL u kombinaciji s ASP.NET 1.1 web uslugama može se pronaći u mom članku na http://stump-workshop.blogspot.com/2006/10/web-https-ssl.html
Mehanizmi zaštite podataka na razini SOAP poruka temelje se na korištenju proširenja SOAP protokola kao što su WS-SecureConversation, WS-Trust, WS-SecurityPolicy i WS-Security. Obično je podrška za te specifikacije ugrađena na razini platforme koja implementira web usluge, a programeru su dostupne i na deklarativnoj razini (atributi ili konfiguracija) i kao API. Prednosti korištenja ovih mehanizama uključuju njihovu fleksibilnost i svestranost. Možete koristiti i enkripciju i digitalni potpis. Moguće je zaštititi samo poruke pojedinih servisnih operacija, pa čak i pojedine dijelove SOAP poruke. Nažalost, ne podržavaju sve platforme web usluga u potpunosti ove specifikacije. Na primjer, široko korišteni .NET Framework 1.1 ne podržava WS-Security. Stoga, kada koristite ovu platformu, morat ćete implementirati zaštitu na razini transporta.
Konačno, postoji i treći način - da implementirate vlastiti mehanizam zaštite kako je, na primjer, opisano. Međutim, trebali biste shvatiti da ovaj put značajno smanjuje mogućnosti korištenja vaše usluge.
Zaključno, vrijedi se osvrnuti na pitanje pohranjivanja vjerodajnica za povezivanje s web uslugama. Već smo rekli da pristup web uslugama treba omogućiti samo autentificiranim korisnicima. Druga strana novčića je da moramo navesti vjerodajnice kada se klijent spaja na uslugu. Stoga te vjerodajnice moramo negdje pohraniti. Kada naš sustav mora komunicirati s nekoliko usluga, od kojih svaka zahtijeva svoje identitete, problem postaje posebno akutan.
Što su certifikati? U većini slučajeva to je par vrijednosti: prijava - lozinka. Ponekad to može biti certifikat klijenta ili druga vrsta vjerodajnice, ovisno o korištenom protokolu provjere autentičnosti. Treba jasno razumjeti da se identiteti klijenata odnose na podatke koje napadač može koristiti za napad na sustav. Stoga ti podaci zahtijevaju zaštitu. Ovu činjenicu trebate uzeti u obzir u fazi projektiranja. Prilikom implementacije integracijskih web usluga, vjerojatno ćete morati uložiti malo truda u razvoj mehanizama za sigurno pohranjivanje identiteta klijenata i njihovo konfiguriranje/uređivanje.
Problemi s provedbom
Problemi implementacije web servisa uvelike ovise o platformi s kojom radite, a danas ih ima jako puno. Samo Microsoft nudi 4 platforme (ASP.NET 1.1, ASP.NET 2.0, WSE 1.0-3.0, WCF-Indigo). Ima ih još više u svijetu Jave. Stoga je vrlo teško dati konkretne preporuke. Međutim, postoje točke na koje biste trebali obratiti pozornost u svakom slučaju.Većina platformi brine o generiranju WSDL opisa usluge, dajući programeru priliku da radi s uslugom kao s običnom klasom. Stoga treba stalno paziti na one detalje koji utječu na formiranje ispravnih WSDL opisa i XSD shema podataka. Te stvari uključuju korištenje Xml imenskog prostora i prefiksa, kontrolu redoslijeda serijalizacije podataka te redoslijed i stil generiranja WSDL-a.
Trebali biste pokušati odvojiti poslovnu logiku od implementacije usluge. Dobro je ako možete koristiti jednu poslovnu logiku unutar aplikacije i web usluge. U idealnom slučaju, metode vaše web usluge bit će lišene bilo kakve logike osim provjere parametara, generiranja rezultata i rukovanja pogreškama, kao što je prikazano na slici:
Zaključak
Stoga smo u ovom članku ispitali niz pitanja povezanih s dizajnom integracijskih web usluga.Usmjerili smo se na opća načela SOA koncepta. Razmotrili smo praktična pitanja izrade ugovora o uslugama, osiguravajući njegovu funkcionalnu i sintaktičku cjelovitost. Obratili smo pozornost na utjecaj protokola interakcije na ugovor o usluzi. Razmotrili smo opcije za rješavanje sigurnosnih problema web usluga. I na kraju smo se zaustavili na nekim praktičnim aspektima dizajna. Nadam se da će vam ovaj članak biti koristan pri dizajniranju integracijskih web usluga.
Softver otvorenog koda postao je mainstream strukturni element u stvaranju nekih od najvećih web stranica. S rastom ovih web stranica pojavile su se najbolje prakse i smjernice za njihovu arhitekturu. Ovo poglavlje ima za cilj pokriti neka od ključnih pitanja koja treba uzeti u obzir pri dizajniranju velikih web stranica, kao i neke od osnovnih komponenti koje se koriste za postizanje tih ciljeva.
Fokus ovog poglavlja je na analizi web-baziranih sustava, iako se dio materijala može ekstrapolirati na druge distribuirane sustave.
1.1 Načela izgradnje distribuiranih web sustava
Što točno znači stvoriti i upravljati skalabilnom web stranicom ili aplikacijom? Na primitivnoj razini, to je jednostavno povezivanje korisnika s udaljenim resursima putem Interneta. I resursi ili pristup tim resursima, koji su raspoređeni na mnogo poslužitelja i poveznica su koja osigurava skalabilnost web stranice.
Kao i većina stvari u životu, vrijeme provedeno unaprijed u planiranju izgradnje web usluge može pomoći kasnije; Razumijevanje nekih razmatranja i kompromisa iza velikih web stranica može donijeti pametnije odluke pri izradi manjih web stranica. Ispod su neka ključna načela koja utječu na dizajn velikih web sustava:
- Dostupnost: Vrijeme rada web stranice ključno je za ugled i funkcionalnost mnogih tvrtki. Za neke veće online trgovce nedostupnost čak i nekoliko minuta može rezultirati tisućama ili milijunima dolara izgubljenog prihoda. Stoga je razvoj njihovih sustava kako bi uvijek bili dostupni i otporni na kvarove temeljni poslovni i tehnološki zahtjev. Visoka dostupnost u distribuiranim sustavima zahtijeva pažljivo razmatranje redundancije za ključne komponente, brzi oporavak od djelomičnog kvara sustava i glatko smanjenje mogućnosti kada se pojave problemi.
- Izvođenje: Izvedba web stranice je postala važan pokazatelj za većinu stranica. Brzina web stranice utječe na korisničko iskustvo i zadovoljstvo, kao i na rangiranje u tražilicama—čimbenik koji izravno utječe na zadržavanje publike i prihod. Kao rezultat toga, ključ je stvoriti sustav koji je optimiziran za brze odgovore i nisku latenciju.
- Pouzdanost: sustav mora biti pouzdan tako da dani zahtjev za podacima dosljedno vraća određene podatke. U slučaju promjene ili ažuriranja podataka, isti zahtjev treba vratiti nove podatke. Korisnici trebaju znati da ako se nešto snimi ili pohrani u sustavu, mogu biti sigurni da će to ostati na mjestu za kasnije pronalaženje.
- Skalabilnost: Kada je riječ o bilo kojem velikom distribuiranom sustavu, veličina je samo jedna stavka na popisu koju treba razmotriti. Jednako su važni napori usmjereni na povećanje propusnost za rukovanje velikim količinama opterećenja, što se obično naziva skalabilnost sustava. Skalabilnost se može odnositi na raznih parametara sustav: količinu dodatnog prometa koji može obraditi, koliko je lako proširiti kapacitet pohrane ili koliko se drugih transakcija može obraditi.
- Upravljivost: Dizajniranje sustava koji je jednostavan za rukovanje još je jedan važan faktor. Upravljivost sustava izjednačava se s skalabilnošću operacija "održavanja" i "ažuriranja". Da bi se osigurala upravljivost, potrebno je uzeti u obzir lakoću dijagnosticiranja i razumijevanja novonastalih problema, lakoću ažuriranja ili modificiranja i jednostavnost korištenja sustava. (Odnosno, radi li prema očekivanjima bez kvarova ili iznimaka?)
- Cijena: Trošak je važan faktor. To očito može uključivati troškove hardvera i softvera, ali također je važno uzeti u obzir druge aspekte potrebne za implementaciju i održavanje sustava. Potrebno je osigurati količinu vremena programera potrebnog za izgradnju sustava, količinu operativnog napora potrebnog da se sustav pokrene i pokrene, pa čak i odgovarajuću razinu obuke. Trošak predstavlja ukupni trošak vlasništva.
Svaki od ovih principa pruža osnovu za donošenje odluka u dizajnu distribuirane web arhitekture. No, mogu biti i u međusobnom sukobu jer postizanje ciljeva jedne ide nauštrb zanemarivanja druge. Jednostavan primjer: odabir jednostavnog dodavanja više poslužitelja kao rješenja za performanse (skalabilnost) može povećati troškove upravljanja (morate pokrenuti dodatni poslužitelj) i kupnje poslužitelja.
Kada razvijate bilo koju vrstu web aplikacije, važno je uzeti u obzir ova ključna načela, čak i ako želimo potvrditi da projekt može žrtvovati jedno ili više njih.
1.2 Osnove
Kada se razmatra arhitektura sustava, postoji nekoliko pitanja kojima se treba pozabaviti, kao što su koje se komponente isplati koristiti, kako se međusobno uklapaju i koji se kompromisi mogu napraviti. Ulaganje novca u skaliranje bez jasne potrebe za tim nije pametna poslovna odluka. Međutim, malo predumišljaja u planiranju može uštedjeti značajno vrijeme i resurse u budućnosti.
Ovaj se odjeljak fokusira na neke osnovne čimbenike koji su ključni za gotovo sve velike web aplikacije: Usluge,
zalihost, segmentacija, I rukovanje kvarom. Svaki od ovih čimbenika uključuje izbore i kompromise, posebno u kontekstu načela opisanih u prethodnom odjeljku. Da pojasnimo, dajmo primjer.
Primjer: Aplikacija za hosting slika
Vjerojatno ste već objavljivali slike na internetu. Za velika mjesta koja pohranjuju i isporučuju mnogo slika, postoje izazovi u stvaranju isplative, vrlo pouzdane arhitekture koja ima niske latencije odgovora (brzo dohvaćanje).
Zamislite sustav u kojem korisnici imaju mogućnost učitavanja svojih slika na središnji poslužitelj i u kojem se slike mogu zatražiti putem veze na stranicu ili API-ja, slično Flickru ili Picasi. Kako bismo pojednostavili opis, pretpostavimo da ova aplikacija ima dva glavna zadatka: mogućnost učitavanja (pisanja) slika na poslužitelj i zahtijevanje slika. Naravno, učinkovito učitavanje je važan kriterij, ali brza isporuka na zahtjev korisnika (na primjer, slike se mogu tražiti za prikaz na web stranici ili drugoj aplikaciji) bit će prioritet. Ova je funkcionalnost slična onoj koju može pružiti web poslužitelj ili rubni poslužitelj mreže za isporuku sadržaja (CDN). CDN poslužitelj obično pohranjuje podatkovne objekte na više lokacija, čime ih geografski/fizički približava korisnicima, što rezultira poboljšanim performansama.
ostalo važni aspekti sustavi:
- Broj pohranjenih slika može biti neograničen, tako da se s ove točke gledišta mora razmotriti skalabilnost pohrane.
- Za preuzimanja/zahtjeve slika trebala bi postojati niska latencija.
- Ako korisnik postavi sliku na poslužitelj, njezini podaci uvijek moraju ostati netaknuti i dostupni.
- Sustav mora biti jednostavan za održavanje (upravljivost).
- Budući da hosting slika ne donosi veliku zaradu, sustav mora biti isplativ.
Još jedan potencijalni problem s ovim dizajnom je da web poslužitelj kao što je Apache ili lighttpd obično ima gornju granicu broja simultane veze da je u stanju poslužiti (zadano je približno 500, ali može biti i mnogo više), a s visokim prometom može brzo potrošiti ovo ograničenje. Budući da čitanja mogu biti asinkrona ili mogu iskoristiti druge optimizacije performansi kao što su gzip kompresija ili chunking, web poslužitelj može prebacivati čitanja feedova brže i prebacivati se između klijenata dok opslužuje mnogo više zahtjeva od maksimalnog broja veza (s Apacheom i s maksimalnim brojem veze postavljene na 500, sasvim je moguće servisirati nekoliko tisuća zahtjeva za čitanje u sekundi). Zapisi, s druge strane, drže vezu otvorenom tijekom cijelog trajanja preuzimanja. Stoga bi prijenos datoteke od 1 MB na poslužitelj mogao potrajati više od 1 sekunde na većini kućnih mreža, što rezultira time da web poslužitelj može obraditi samo 500 od ovih istodobnih unosa.
Slika 1.2: Odvajanje čitanja/pisanja
Predviđanje ovog potencijalnog problema sugerira potrebu za odvajanjem čitanja i pisanja slika u neovisne usluge, prikazane u . To će nam omogućiti ne samo skaliranje svake od njih pojedinačno (budući da je vjerojatno da ćemo uvijek više čitati nego pisati), već i da budemo svjesni što se događa u svakoj usluzi. Konačno, razlikovat će probleme koji se mogu pojaviti u budućnosti, olakšavajući dijagnosticiranje i procjenu problema sporog pristupa čitanju.
Prednost ovog pristupa je u tome što možemo rješavati probleme neovisno jedan o drugom - bez brige o snimanju i dohvaćanju novih slika u istom kontekstu. Obje ove usluge i dalje koriste globalni korpus slika, ali korištenjem tehnika specifičnih za uslugu, mogu optimizirati vlastitu izvedbu (na primjer, postavljanjem zahtjeva u red čekanja ili predmemoriranjem popularnih slika - više o tome kasnije). Iz perspektive usluge i cijene, svaka se usluga može neovisno skalirati prema potrebi. I to je pozitivna stvar, budući da bi njihovo kombiniranje i miješanje moglo nenamjerno utjecati na njihovu izvedbu, kao u gore opisanom scenariju.
Naravno, gornji model će raditi optimalno ako postoje dvije različite krajnje točke (zapravo, ovo je vrlo slično nekoliko implementacija pružatelja usluga pohrane u oblaku i mreža za isporuku sadržaja). Postoji mnogo rješenja sličnih problema, i u svakom slučaju se može naći kompromis.
Na primjer, Flickr rješava ovaj problem čitanja i pisanja raspodjeljujući korisnike među različitim modulima, tako da svaki modul može služiti samo ograničen broj definiranih korisnika, a kako se broj korisnika povećava, više podova se dodaje u klaster (pogledajte Flickr prezentaciju skaliranja,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). U prvom primjeru, lakše je skalirati hardver na temelju stvarnog opterećenja korištenja (broj čitanja i pisanja u cijelom sustavu), dok Flickr skalira na temelju korisničke baze (međutim, ovo pretpostavlja jednaku upotrebu među korisnicima, tako da kapacitet potrebno planirati prema zalihama). U prošlosti bi nedostupnost ili problem s jednom od usluga poremetio funkcionalnost cijelog sustava (na primjer, nitko nije mogao pisati datoteke), tada bi nedostupnost jednog od Flickr modula utjecala samo na korisnike povezane s njim. U prvom primjeru, lakše je izvršiti operacije na cijelom skupu podataka - na primjer, ažuriranje usluge snimanja kako bi se uključili novi metapodaci ili pretraživanje svih metapodataka slike - dok je s Flickr arhitekturom svaki modul morao biti ažuriran ili pretraživan ( ili je morala biti kreirana usluga pretraživanja za sortiranje metapodataka koji su zapravo namijenjeni za tu svrhu).
Što se tiče ovih sustava, nema lijeka, ali uvijek trebate krenuti od načela opisanih na početku ovog poglavlja: odrediti potrebe sustava (čitanje ili pisanje ili oboje, razina paralelizma, upiti na skupove podataka, rasponi, sortiranje, itd.), provesti komparativno testiranje različitih alternativa, razumjeti potencijalne uvjete kvara sustava i razviti sveobuhvatan plan ako dođe do kvara.
Redundancija
Kako bi se elegantno nosila s neuspjehom, web arhitektura mora imati redundanciju u svojim uslugama i podacima. Na primjer, ako postoji samo jedna kopija datoteke pohranjena na jednom poslužitelju, gubitak tog poslužitelja značit će gubitak datoteke. Malo je vjerojatno da će ovo biti pozitivna situacija i obično se može izbjeći stvaranjem više kopija ili sigurnosnih kopija.
Isti princip vrijedi i za usluge. Možete se zaštititi od kvara jednog čvora pružanjem integralnog dijela funkcionalnosti za aplikaciju kako biste osigurali da se više kopija ili verzija može izvoditi istovremeno.
Stvaranje redundantnosti u sustavu omogućuje vam da se riješite slabih točaka i pružite rezervnu ili redundantnu funkcionalnost u slučaju nužde. Na primjer, ako postoje dvije instance iste usluge koje se izvode u proizvodnji, a jedna od njih potpuno ili djelomično zakaže, sustav može prevladati grešku prebacivanje na radnu kopiju.
Prebacivanje se može dogoditi automatski ili zahtijevati ručnu intervenciju.
Druga ključna uloga redundancije usluge je stvaranje arhitektura koja ne omogućuje dijeljenje resursa. Uz ovu arhitekturu, svaki čvor može raditi neovisno i, štoviše, u nedostatku središnjeg "mozga" koji upravlja stanjima ili koordinira radnje drugih čvorova. Promiče skalabilnost jer dodavanje novih čvorova ne zahtijeva posebne uvjete ili znanje. Ono što je najvažnije, ne postoji kritična točka kvara u ovim sustavima, što ih čini puno otpornijima na kvarove.
.Na primjer, u našoj aplikaciji poslužitelja slika, sve bi slike imale suvišne kopije negdje na drugom hardveru (idealno na drugoj geografskoj lokaciji u slučaju katastrofe kao što je potres ili požar u podatkovnom centru), a usluge bi pristup slikama bio suvišan, s obzirom da će sve one potencijalno služiti zahtjevima. (Cm. .)
Gledajući unaprijed, balanseri opterećenja izvrstan su način da to učinite mogućim, ali više o tome u nastavku.
Slika 1.3: Suvišna aplikacija za hosting slika
Segmentacija
Skupovi podataka mogu biti toliko veliki da se ne mogu smjestiti na jedan poslužitelj. Također se može dogoditi da računalne operacije zahtijevaju previše računalnih resursa, smanjujući performanse i zahtijevajući povećanu snagu. U svakom slučaju, imate dvije mogućnosti: okomito ili vodoravno skaliranje.
Vertikalno skaliranje uključuje dodavanje više resursa jednom poslužitelju. Dakle, za vrlo velik skup podataka, to bi značilo dodavanje više (ili više) tvrdi diskovi, te bi tako cijeli skup podataka mogao biti smješten na jednom poslužitelju. U slučaju računalnih operacija, to bi značilo premještanje računanja na veći poslužitelj s bržim CPU-om ili više memorije. U svakom slučaju, vertikalno skaliranje se radi kako bi jedan resurs računalnog sustava bio sposoban za dodatna obrada podaci.
Horizontalno skaliranje, s druge strane, uključuje dodavanje više čvorova. U slučaju velikog skupa podataka, to bi značilo dodavanje drugog poslužitelja za pohranu dijela ukupne količine podataka, a za računalni resurs to bi značilo podjelu posla ili opterećenja na neke dodatne čvorove. Da biste u potpunosti iskoristili potencijal horizontalnog skaliranja, ono se mora implementirati kao unutarnji princip razvoj arhitekture sustava. U suprotnom, mijenjanje i izdvajanje konteksta potrebnog za horizontalno skaliranje može biti problematično.
Najčešća metoda horizontalnog skaliranja je podjela usluga na segmente ili module. Mogu se distribuirati na način da svaki logički skup funkcionalnosti radi odvojeno. To se može učiniti geografskim granicama ili drugim kriterijima kao što su korisnici koji plaćaju i korisnici koji ne plaćaju. Prednost ovih shema je u tome što pružaju uslugu ili pohranu podataka s poboljšanom funkcionalnošću.
U našem primjeru poslužitelja slika, moguće je da se jedan poslužitelj datoteka koji se koristi za pohranu slike može zamijeniti s više poslužitelja datoteka, od kojih svaki sadrži vlastitu jedinstveni set slike. (Vidi.) Ova bi arhitektura omogućila sustavu da ispuni svaki poslužitelj datoteka slikama, dodajući dodatne poslužitelje kako prostor na disku postaje pun. Dizajn će zahtijevati shemu imenovanja koja povezuje naziv slikovne datoteke s poslužiteljem koji je sadrži. Naziv slike može se generirati iz dosljedne sheme raspršivanja povezane s poslužiteljima. Ili alternativno, svaka bi slika mogla imati inkrementalni ID, što bi omogućilo službi za isporuku, kada zahtijeva sliku, da obradi samo raspon ID-ova povezanih sa svakim poslužiteljem (kao indeks).
Slika 1.4: Aplikacija za hosting slika sa redundancijom i segmentacijom
Naravno, postoje poteškoće u distribuciji podataka ili funkcionalnosti preko mnogih poslužitelja. Jedno od ključnih pitanja je mjesto podataka; U distribuiranim sustavima, što su podaci bliže operaciji ili točki računanja, to je bolja izvedba sustava. Posljedično, distribucija podataka na više poslužitelja potencijalno je problematična, budući da u bilo kojem trenutku podaci mogu biti potrebni, postoji rizik da možda neće biti dostupni na traženoj lokaciji, poslužitelj će morati izvršiti skupo dohvaćanje potrebnih informacija preko mreža.
Još jedan potencijalni problem javlja se u obliku
nedosljednost (nedosljednost) Kada različite usluge čitaju i pišu u dijeljeni resurs, potencijalno drugu uslugu ili pohranu podataka, moguće je da se dogodi "stanje utrke" - gdje se smatra da su neki podaci ažurirani na najnovije stanje, ali se zapravo čitaju prije nego što se ažuriran - u tom slučaju podaci nisu dosljedni. Na primjer, u scenariju hostinga slika, stanje utrke moglo bi se dogoditi ako je jedan klijent poslao zahtjev za ažuriranje slike psa, mijenjajući naslov "Pas" u "Gizmo" dok je drugi klijent čitao sliku. U takvoj situaciji nejasno je koji bi naslov, "Pas" ili "Gizmo", dobio drugi klijent.
Postoje, naravno, neke prepreke povezane sa segmentacijom podataka, ali segmentacija vam omogućuje da izolirate svaki problem od ostalih: po podacima, po opterećenju, po obrascima korištenja itd. u upravljane blokove. To može pomoći u skalabilnosti i upravljivosti, ali još uvijek postoji rizik. Postoji mnogo načina za smanjenje rizika i rješavanje kvarova; međutim, u interesu sažetosti oni nisu pokriveni u ovom poglavlju. Ako želite više informacija o ovoj temi, trebali biste pogledati post na blogu o toleranciji grešaka i praćenju.
1.3. Gradivni blokovi za brz i skalabilan pristup podacima
Nakon što smo pogledali neke osnovne principe u razvoju distribuiranog sustava, prijeđimo sada na složenije pitanje - skaliranje pristupa podacima.
Najjednostavnije web aplikacije, kao što su LAMP stack aplikacije, slične su slici u .
Slika 1.5: Jednostavne web aplikacije
Kako aplikacija raste, pojavljuju se dva glavna izazova: skaliranje pristupa aplikacijskom poslužitelju i bazi podataka. U visoko skalabilnom dizajnu aplikacije, web ili aplikacijski poslužitelj obično je minimiziran i često implementira arhitekturu dijeljenja resursa. Ovo čini sloj aplikacijskog poslužitelja sustava vodoravno skalabilnim. Kao rezultat ovog dizajna, teško dizanje će se prebaciti niz stog na poslužitelj baze podataka i prateće usluge; Ovaj sloj je mjesto gdje stvarni problemi skaliranja i performansi stupaju na scenu.
Ostatak ovog poglavlja pokriva neke od najčešćih strategija i tehnika za poboljšanje izvedbe i skalabilnosti ovih vrsta usluga pružanjem brzog pristupa podacima.
Slika 1.6: Pojednostavljena web aplikacija
Većina sustava može se pojednostaviti na sklop
što je dobro mjesto za početak traženja. Ako imate mnogo podataka, može se pretpostaviti da želite imati jednako jednostavan pristup i brz pristup poput kutije slatkiša u gornjoj ladici vašeg stola. Iako je ova usporedba previše jednostavna, ona ističe dva složena problema: skalabilnost pohrane podataka i brz pristup podacima.
Za potrebe ovog odjeljka, pretpostavimo da imate mnogo terabajta (TB) podataka i dopuštate korisnicima pristup malim dijelovima tih podataka nasumičnim redoslijedom. (Cm. .)
Sličan zadatak je odrediti lokaciju slikovne datoteke negdje na datotečnom poslužitelju u oglednoj aplikaciji za hosting slika.
Slika 1.7: Pristup određenim podacima
To je posebno teško jer učitavanje terabajta podataka u memoriju može biti vrlo skupo i izravno utječe na I/O diska. Brzina čitanja s diska je nekoliko puta manja od brzine čitanja s RAM memorija- moglo bi se reći da je pristup memoriji brz kao Chuck Norris, dok je pristup disku sporiji od reda u klinici. Ova razlika u brzini je posebno uočljiva za velike skupove podataka; u neobrađenim brojevima, pristup memoriji je 6 puta brži od čitanja diska za sekvencijalno čitanje i 100 000 puta brži za čitanje u slučajni redoslijed(Vidi Patologije velikih podataka, http://queue.acm.org/detail.cfm?id=1563874). Štoviše, čak i s jedinstvenim identifikatorima, rješavanje problema lociranja malog dijela podataka može biti jednako teško kao pokušaj da se bez gledanja iz kutije sa stotinama drugih slatkiša izabere posljednji slatkiš punjen čokoladom.
Srećom, postoje mnogi pristupi koji se mogu poduzeti da se stvari pojednostave, a četiri najvažnija pristupa su korištenje predmemorija, proxyja, indeksa i balansera opterećenja. U ostatku ovog odjeljka raspravlja se o tome kako se svaki od ovih koncepata može koristiti za mnogo brži pristup podacima.
Spremišta
Predmemoriranje ima koristi od karakteristike temeljnog načela: nedavno traženi podaci vjerojatno će ponovno biti potrebni. Predmemorije se koriste na gotovo svim razinama računalstva: hardver, operativni sustavi, web preglednici, web aplikacije itd. Cache je kao kratkotrajno pamćenje: ograničen opsegom, ali brži od izvornog izvora podataka i sadrži stavke kojima se nedavno pristupalo. Predmemorije mogu postojati na svim razinama u arhitekturi, ali se često nalaze na razini najbližoj prednjem kraju, gdje su implementirane za brzo vraćanje podataka bez značajnog opterećenja pozadine.
Dakle, kako se predmemorija može koristiti za ubrzavanje pristupa podacima unutar našeg primjera API-ja? U ovom slučaju postoji nekoliko prikladnih lokacija predmemorije. Jedna od mogućih opcija postavljanja je odabir čvorova na razini upita, kao što je prikazano u
.
Slika 1.8: Položaj predmemorije na čvoru na razini upita
Postavljanje predmemorije izravno na čvor na razini zahtjeva omogućuje lokalnu pohranu podataka odgovora. Svaki put kad se podnese zahtjev za uslugu, čvor će brzo vratiti lokalne, predmemorirane podatke, ako takvi postoje. Ako nije u predmemoriji, čvor zahtjeva će zatražiti podatke s diska. Predmemorija na jednom čvoru na razini upita također se može nalaziti u memoriji (što je vrlo brzo) i na lokalni diskčvor (brže od pokušaja pristupa mrežnoj pohrani).
Slika 1.9: Sustavi predmemorije
Što se događa kada predmemoriju rasporedite na mnogo čvorova? Kao što vidite, ako razina zahtjeva uključuje mnogo čvorova, tada je vjerojatno da će svaki čvor imati vlastitu predmemoriju. Međutim, ako vaš balanser opterećenja nasumično distribuira zahtjeve između čvorova, tada će isti zahtjev ići različitim čvorovima, čime se povećavaju promašaji predmemorije. Dva načina za prevladavanje ove prepreke su globalne i distribuirane predmemorije.
Globalna predmemorija
Značenje globalne predmemorije jasno je iz naziva: svi čvorovi dijele jedan jedini prostor predmemorije. U ovom slučaju dodajete poslužitelj ili neku vrstu pohrane datoteka koja je brža od vaše izvorne pohrane i koja će biti dostupna svim čvorovima na razini zahtjeva. Svaki od čvorova zahtjeva ispituje predmemoriju na isti način kao da je lokalna. Ova vrsta sheme predmemorije može uzrokovati neke probleme, jer se jedna predmemorija može vrlo lako preopteretiti ako se broj klijenata i zahtjeva poveća. U isto vrijeme, ova je shema vrlo učinkovita na određenim arhitekturama (posebno onima povezanim sa specijaliziranim hardverom koji ovu globalnu predmemoriju čini vrlo brzom ili koja ima fiksni skup podataka koji se moraju predmemorirati).
Postoje dva standardna oblika globalnih predmemorija prikazanih na dijagramima. Prikazana situacija je da kada se predmemorirani odgovor ne pronađe u predmemoriji, sama predmemorija postaje odgovorna za dohvaćanje dijela podataka koji nedostaje iz temeljne pohrane. Ilustrirana je odgovornost čvorova zahtjeva da dohvate bilo koje podatke koji nisu pronađeni u predmemoriji.
Slika 1.10: Globalna predmemorija, gdje je predmemorija odgovorna za dohvaćanje
Slika 1.11: Globalna predmemorija, gdje su čvorovi zahtjeva odgovorni za dohvaćanje
Većina aplikacija koje koriste globalne predmemorije imaju tendenciju da koriste prvu vrstu, gdje predmemorija sama upravlja zamjenom i dohvaćanjem podataka kako bi spriječila klijente da preplave zahtjeve za istim podacima. Međutim, postoje neki slučajevi u kojima druga implementacija ima više smisla. Na primjer, ako se predmemorija koristi za vrlo velike datoteke, nizak postotak uspješan pristup predmemorije će dovesti do preopterećenja međuspremnika s neuspješnim pristupima predmemorije; u ovoj situaciji pomaže imati veliki postotak dijeljeni skup podataka (ili vrući skup podataka) u predmemoriju. Drugi primjer je arhitektura u kojoj su datoteke pohranjene u predmemoriju statične i ne smiju se brisati. (To se može dogoditi zbog osnovnih karakteristika izvedbe u vezi s takvom latencijom podataka - možda određeni dijelovi podataka moraju biti vrlo brzi za velike skupove podataka - gdje logika aplikacije razumije strategiju zamjene ili žarišne točke bolje od predmemorije.)
Distribuirana predmemorija
Ti su indeksi često pohranjeni u memoriji ili negdje vrlo lokalno za dolazni zahtjev klijenta. Berkeley DB (BDB) i podatkovne strukture stabla, koje se obično koriste za pohranu podataka u uređenim popisima, idealne su za indeksirani pristup.
Često postoji mnogo slojeva indeksa koji djeluju kao karta, premještaju vas s jedne lokacije na drugu, i tako dalje, sve dok ne dobijete podatke koji su vam potrebni. (Cm.)
Slika 1.17: Indeksi na više razina
Indeksi se također mogu koristiti za stvaranje višestrukih drugih prikaza istih podataka. Za velike skupove podataka ovo je izvrstan način za definiranje različitih filtara i prikaza bez potrebe za stvaranjem mnogih dodatnih kopija podataka.
Na primjer, recimo da gore spomenuti sustav za hosting slika zapravo hostira slike stranice knjige, a usluga omogućuje klijentima da traže tekst u tim slikama, tražeći sav tekstualni sadržaj na danu temu na isti način na koji vam tražilice omogućuju pretraživanje HTML sadržaja. U ovom slučaju, sve te slike knjiga koriste toliko mnogo poslužitelja za pohranu datoteka, a pronalaženje jedne stranice za predstavljanje korisniku može biti prilično teško. U početku bi obrnuti indeksi za upite proizvoljnih riječi i skupova riječi trebali biti lako dostupni; zatim postoji zadatak navigacije do točne stranice i lokacije u toj knjizi i dohvaćanje točne slike za rezultate pretraživanja. Dakle, u ovom slučaju, obrnuti indeks bi se preslikao na lokaciju (kao što je knjiga B), a onda bi B mogla sadržavati indeks sa svim riječima, lokacijama i brojem pojavljivanja u svakom dijelu.
Obrnuto kazalo, koje Index1 može prikazati u gornjem dijagramu, izgledalo bi otprilike ovako: Svaka riječ ili skup riječi služi kao indeks za one knjige koje ih sadrže.
Međuindeks će izgledati slično, ali će sadržavati samo riječi, lokaciju i informacije za knjigu B. Ova slojevita arhitektura omogućuje svakom indeksu da zauzme manje prostora nego da su sve ove informacije pohranjene u jednom velikom obrnutom indeksu.
A ovo je ključna točka u sustavima velikih razmjera, jer čak i kada su komprimirani, ti indeksi mogu biti prilično veliki i skupi za pohranu. Pretpostavimo da u ovom sustavu imamo mnogo knjiga iz cijelog svijeta - 100.000.000 (pogledajte post na blogu "Inside Google Books") - i da svaka knjiga ima samo 10 stranica (da pojednostavimo izračune) s 250 riječi po stranici: To daje imamo ukupno 250 milijardi riječi. Ako uzmemo da je prosječni broj znakova u riječi 5 i kodiramo svaki znak s 8 bitova (ili 1 bajtom, iako neki znakovi zapravo zauzimaju 2 bajta), trošeći tako 5 bajtova po riječi, tada indeks koji sadrži svaki riječ samo jednom zahtijevala bi više od 1 terabajta pohrane. Dakle, možete vidjeti da indeksi koji sadrže i druge informacije, kao što su skupovi riječi, lokacije podataka i brojevi korištenja, mogu vrlo brzo rasti u veličini.
Stvaranje takvih srednjih indeksa i predstavljanje podataka u manjim dijelovima olakšava rješavanje problema velikih podataka. Podaci se mogu distribuirati na više poslužitelja i istovremeno biti brzo dostupni. Indeksi su kamen temeljac pretraživanja informacija i osnova za današnje moderne tražilice. Naravno, ovaj odjeljak samo zagrebe po površini teme indeksiranja, a bilo je mnogo istraživanja o tome kako indekse učiniti manjim, bržim, sadržavati više informacija (kao što je relevantnost) i lako ažurirati. (Postoje neki problemi s upravljanjem konkurentskim uvjetima, kao i brojem ažuriranja potrebnih za dodavanje novih podataka ili promjenu postojećih podataka, posebno kada je uključena relevantnost ili bodovanje).
Mogućnost brzog i jednostavnog pronalaženja podataka je važna, a indeksi su najjednostavniji i najučinkovitiji alat za postizanje tog cilja.
Balanceri opterećenja
Konačno, još jedan kritičan dio svakog distribuiranog sustava je balanser opterećenja. Balanseri opterećenja ključni su dio svake arhitekture jer je njihova uloga raspodijeliti opterećenje između čvorova odgovornih za posluživanje zahtjeva. Ovo omogućuje višestrukim čvorovima da transparentno služe istoj funkciji u sustavu. (Vidi.) Njihova glavna svrha je rukovanje mnogim istovremenim vezama i usmjeravanje tih veza na jedan od traženih čvorova, dopuštajući sustavu skaliranje jednostavnim dodavanjem čvorova za posluživanje velika količina zahtjevi.
Slika 1.18: Balanser opterećenja
Ima ih mnogo razni algoritmi za zahtjeve za servisiranjem, uključujući odabir slučajnog čvora, ciklički algoritam ili čak odabir čvora na temelju određenih kriterija kao što je upotreba procesora ili RAM-a. Balanseri opterećenja mogu se implementirati kao hardverski uređaji ili softver. Među balanserima opterećenja softvera otvorenog koda, HAProxy je najčešće korišten.
U distribuiranom sustavu, balanseri opterećenja često se nalaze na "prednjem rubu" sustava, tako da svi dolazni zahtjevi prolaze izravno kroz njih. Vrlo je vjerojatno da će u složenom distribuiranom sustavu zahtjev morati proći kroz više balansera, kao što je prikazano u
.
Slika 1.19: Višestruki balanseri opterećenja
Poput proxyja, neki balanseri opterećenja također mogu različito usmjeravati zahtjeve ovisno o vrsti zahtjeva. Također su poznati kao obrnuti proxyji.
Upravljanje podacima specifičnim za određenu korisničku sesiju jedan je od izazova pri korištenju balansera opterećenja. Na stranici e-trgovina Kada imate samo jednog kupca, vrlo je jednostavno dopustiti korisnicima da stavljaju artikle u svoju košaricu i spremaju sadržaj između posjeta (ovo je važno jer se vjerojatnost prodaje artikla značajno povećava ako, kada se korisnik vrati na web mjesto, proizvod je još u njihovoj košarici). Međutim, ako je korisnik usmjeren na jedno mjesto za prvu sesiju, a zatim na drugo mjesto prilikom sljedećeg posjeta, može doći do nedosljednosti jer novi čvor možda neće imati informacije o sadržaju košarice tog korisnika. (Ne biste li bili uzrujani ako stavite paket Mountain Dew-a u svoju košaricu, a kada se vratite nema ga tamo?) Jedno od rješenja bi moglo biti da sesije učinite "ljepljivima" tako da korisnik uvijek bude usmjeren na isti čvor. Međutim, iskorištavanje prednosti nekih značajki pouzdanosti, kao što je automatski failover, bit će značajno teško. U ovom će slučaju korisnička košarica uvijek imati sadržaj, ali ako njihov ljepljivi čvor postane nedostupan, bit će potreban poseban pristup i pretpostavka o sadržaju košarice više neće biti točna (iako se nadamo da ta pretpostavka neće biti ugrađena u aplikacija). Naravno, ovaj se problem može riješiti korištenjem drugih strategija i alata, poput onih opisanih u ovom poglavlju, poput usluga i mnogih drugih (kao što su predmemorije preglednika, kolačići i prepisivanje URL-ova).
Ako sustav ima samo nekoliko čvorova, tada će tehnike kao što je DNS vrtuljak vjerojatno biti praktičnije od balansera opterećenja, koji mogu biti skupi i dodaju nepotreban sloj složenosti sustavu. Naravno, u velikim sustavima postoje razne vrste algoritama za raspoređivanje i balansiranje opterećenja, uključujući jednostavne poput nasumičnog odabira ili vrtuljka i više složeni mehanizmi, koji uzimaju u obzir karakteristike izvedbe obrasca korištenja sustava. Svi ti algoritmi omogućuju vam distribuciju prometa i zahtjeva, a mogu i pružiti korisne alate pouzdanost, kao što je automatski failover ili automatsko uklanjanje oštećenog čvora (na primjer, kada prestane odgovarati). Međutim, ove napredne značajke mogu otežati dijagnosticiranje problema. Na primjer, u situacijama s veliko opterećenje, balanseri opterećenja će ukloniti čvorove koji bi mogli biti spori ili isteći (zbog gomile zahtjeva), što će samo pogoršati stvari za druge čvorove. Opsežno praćenje je važno u ovim slučajevima jer iako se čini da se ukupni promet i opterećenje sustava smanjuju (budući da čvorovi poslužuju manje zahtjeva), pojedinačni čvorovi mogu biti rastegnuti do svojih granica.
Balanseri opterećenja jednostavan su način povećanja kapaciteta sustava. Kao i druge metode opisane u ovom članku, igra ključnu ulogu u arhitekturi distribuiranog sustava. Balanseri opterećenja također pružaju kritičnu funkciju provjere zdravlja čvorova. Ako, kao rezultat takve provjere, čvor ne odgovara ili je preopterećen, tada se može ukloniti iz skupa za obradu zahtjeva, a zahvaljujući redundanciji vašeg sustava, opterećenje će se redistribuirati između preostalih radnih čvorova. .
Redovi čekanja
Do sada smo pogledali mnogo načina za brzo čitanje podataka. U isto vrijeme, drugi važan dio skaliranja podatkovnog sloja je učinkovito upravljanje zapisa. Kada su sustavi jednostavni i imaju minimalno opterećenje obrade i male baze podataka, pisanje može biti predvidljivo brzo. Međutim, u složenijim sustavima ovaj proces može trajati neograničeno dugo. Na primjer, podaci se možda moraju zapisati na više mjesta razne servere ili indekse ili je sustav jednostavno pod velikim opterećenjem. U slučajevima kada pisanje, ili čak bilo koji zadatak, traje dugo, postizanje performansi i dostupnosti zahtijeva ugradnju asinkronije u sustav. Uobičajen način za to je organiziranje reda čekanja zahtjeva.
Slika 1.20: Sinkroni zahtjev
Zamislite sustav u kojem svaki klijent zahtijeva zadatak daljinsko održavanje. Svaki od tih klijenata šalje svoj zahtjev poslužitelju, koji izvršava zadatke što je brže moguće i njihove rezultate vraća odgovarajućim klijentima. U malim sustavima gdje jedan poslužitelj (ili logična usluga) može opsluživati dolazne klijente čim stignu, situacije ove prirode trebale bi dobro funkcionirati. Međutim, kada poslužitelj primi više zahtjeva nego što može obraditi, tada je svaki klijent prisiljen čekati da zahtjevi drugih klijenata završe obradu prije nego što se generira odgovor na vlastiti zahtjev. Ovo je primjer sinkronog zahtjeva, prikazanog u .
Ova vrsta sinkronog ponašanja može značajno pogoršati rad klijenta; zapravo, dok je u stanju mirovanja, klijent je prisiljen čekati dok ne dobije odgovor na zahtjev. Dodavanje dodatnih poslužitelja za suočavanje s opterećenjem sustava zapravo ne rješava problem; Čak i uz učinkovito balansiranje opterećenja, iznimno je teško osigurati ravnomjernu i poštenu raspodjelu opterećenja koja je potrebna za maksimiziranje produktivnosti klijenta. Štoviše, ako je poslužitelj za obradu ovog zahtjeva nedostupan (ili se srušio), tada će klijent povezan s njim također prestati raditi. Učinkovito rješenje ovog problema zahtijeva apstrakciju između zahtjeva klijenta i stvarnog posla koji se obavlja da bi se on poslužio.
Slika 1.21: Korištenje redova čekanja za upravljanje zahtjevima
Ulazni redovi. Način na koji red čekanja radi je vrlo jednostavan: zadatak stigne, uđe u red čekanja, a onda “radnici” prihvate sljedeći zadatak čim ga imaju priliku obraditi. (Vidi.) Ovi zadaci mogu biti jednostavni unosi u bazu podataka ili nešto tako složeno kao što je generiranje predslike za dokument. Kada klijent pošalje zahtjeve za zadatkom u red čekanja, više ne treba čekati rezultate izvršenja; umjesto toga, zahtjevi trebaju samo potvrdu da su ispravno primljeni. Ta potvrda kasnije može poslužiti kao referenca na rezultate rada kada ih naručitelj zatraži.
Redovi čekanja omogućuju klijentima da rade na asinkroni način, pružajući stratešku apstrakciju zahtjeva i odgovora klijenta. S druge strane, u sinkronom sustavu ne postoji razlika između zahtjeva i odgovora, pa se njima ne može upravljati odvojeno. U asinkronom sustavu, klijent šalje zadatak, servis odgovara porukom kojom potvrđuje da je zadatak primljen, a klijent tada može povremeno provjeravati status zadatka, tražeći rezultat tek nakon što je dovršen. Dok klijent postavlja asinkroni zahtjev, slobodan je raditi druge poslove, pa čak i postavljati asinkrone zahtjeve od drugih usluga. Potonji je primjer kako redovi i poruke rade u distribuiranim sustavima.
Redovi čekanja također pružaju određenu zaštitu od prekida i kvarova usluge. Na primjer, vrlo je lako stvoriti vrlo otporan red čekanja koji može ponovno pokušati zahtjeve za uslugom koji ne uspiju zbog trenutnih kvarova poslužitelja. Poželjnije je koristiti red čekanja za provedbu jamstava kvalitete usluge umjesto izlaganja klijenata privremenim prekidima usluge, što zahtijeva složeno i često nedosljedno rukovanje pogreškama na strani klijenta.
Redovi su temeljni princip u upravljanju distribuiranim prijenosom između različitih dijelova bilo kojeg distribuiranog sustava velikih razmjera i postoji mnogo načina za njihovu implementaciju. Postoji dosta open source implementacija čekanja kao što je RabbitMQ.
ActiveMQ
BeanstalkD, ali neki koriste i usluge poput
5.1.1 Osnove web usluga
Web usluge je nova obećavajuća arhitektura koja pruža novu razinu distribucije. Umjesto razvoja ili kupnje komponenti i njihovog ugrađivanja u IS, predlaže se kupiti njihovo vrijeme rada i formirati softverski sustav koji poziva metode od komponenti koje su u vlasništvu i koje podržavaju neovisni dobavljači. Zahvaljujući web uslugama, funkcije bilo kojeg programa na mreži mogu biti dostupne putem interneta. Najjednostavniji primjer web servisa je Passport sustav na Hotmailu, koji vam omogućuje kreiranje autentifikacije korisnika na vlastitoj web stranici.
Web usluge temelje se na sljedećim univerzalnim tehnologijama:
TCP/IP je univerzalni protokol koji razumiju svi mrežni uređaji, od velikih računala do mobilnih telefona i PDA uređaja;
HTML je univerzalni označni jezik koji se koristi za prikaz informacija na korisničkim uređajima;
XML (Extensible Markup Language) je univerzalni jezik za rad s bilo kojom vrstom podataka.
Svestranost ovih tehnologija osnova je za razumijevanje web usluga. Temelje se samo na općeprihvaćenim, otvorenim i formalno neovisnim tehnologijama. Samo se time može postići glavna prednost web servisa kao koncepta izgradnje distribuiranih informacijskih sustava - njihova univerzalnost, odnosno mogućnost korištenja za bilo koje operacijske sustave, programske jezike, aplikacijske poslužitelje i sl. Web servisi dakle rješavaju izvorno problem - problem integracije aplikacija različite prirode i izgradnje distribuiranih informacijskih sustava. Ovo je glavna temeljna razlika između web usluga i njihovih prethodnika.
Web usluge su XML aplikacije koje povezuju podatke s programima, objektima, bazama podataka ili cijelim poslovnim transakcijama. XML dokumenti oblikovani kao poruke razmjenjuju se između web usluge i programa. Standardi web servisa definiraju format takvih poruka, sučelje na koje se poruka šalje, pravila za vezanje sadržaja poruke za aplikaciju koja implementira uslugu i obrnuto, kao i mehanizme za objavljivanje i pretraživanje sučelja.
Web usluge mogu se koristiti u mnogim aplikacijama. Bez obzira pokreću li se web usluge sa stolnih ili prijenosnih računala kupaca, one se mogu koristiti za pristup internetskim aplikacijama kao što su prednarudžbe ili praćenje narudžbi. Web usluge su pogodne za B2B integraciju (business-to-business), zatvarajući aplikacije koje izvode različite organizacije u jedan proizvodni proces. Web usluge također mogu riješiti širi problem integracije poslovnih aplikacija (EAI) povezivanjem više aplikacija u jednom poduzeću s više drugih aplikacija. U svim tim slučajevima tehnologije web usluga su "ljepilo" koje povezuje različite dijelove softvera.
Kao što se može vidjeti sa Sl. 5.1, web usluge su ljuska koja pruža standardni način interakcije s okruženjima aplikacijskog softvera, kao što su sustavi za upravljanje bazama podataka (DBMS), .NET, J2EE (Java2 Platforma, Enterprise Edition), CORBA (Common Object Request Broker Architecture), posrednici Paketi za planiranje resursa poduzeća (ERP), integracijski brokeri itd.
sl.5.1. Web usluge su u interakciji s aplikacijskim sustavima
Sučelja web servisa primaju standardne XML poruke iz mrežnog okruženja, pretvaraju XML podatke u format koji "razumije" određeni aplikacijski softverski sustav i šalju poruku odgovora (posljednje je izborno). Programska implementacija web servisa (osnovni softver, niža razina) može se izraditi u bilo kojem programskom jeziku korištenjem bilo kojeg operacijskog sustava i bilo kojeg međuprograma.
Jednostavan primjer: traženje informacija
Danas se većina usluga poziva preko weba unošenjem podataka u HTML obrasce i slanjem tih podataka usluzi dodavanjem u string Uniform Resource Locator (URL):
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
Ovaj primjer ilustrira jednostavnost web interakcija (kao što je pretraživanje, kupnja dionica ili traženje uputa za vožnju) gdje su parametri i ključne riječi ugrađeni izravno u URL. U ovom slučaju, jednostavan zahtjev za pretraživanje čizama za klizanje prikazan je u nizu upita Google tražilici. Ključna riječ za pretraživanje predstavlja uslugu kojoj će se pristupiti, a parametar Skate+boots je niz za pretraživanje koji je upisan u HTML obrazac na stranici Google web stranice. Google pretraživanje proslijedit će ovaj zahtjev različitim tražilicama, koje će vratiti popis URL-ova za stranice koje odgovaraju parametru pretraživanja Skate+boots. Ova neučinkovita metoda pretraživanja weba u potpunosti se temelji na povezivanju određenog tekstualnog niza s indeksiranim HTML stranicama.
XML je najbolji način slanja podataka. XML pruža značajne prednosti pri prijenosu podataka preko Interneta. Sada se prethodni zahtjev može predstaviti kao XML dokument:
xmlns:s="www.xmlbus.com/SearchService"> Slanje zahtjeva kao XML dokumenta ima sljedeće prednosti: mogućnost definiranja tipova i struktura podataka, veću fleksibilnost i proširivost. XML može predstavljati strukturirane podatke ili podatke određene vrste (na primjer, prihvatljivo je navesti vrijednost polja veličine kao niz brojeva ili kao broj s pomičnim zarezom) i sadržavati više informacija nego što dopušta URL. Ovaj primjer predstavljen je u obliku SOAP (Simple Object Access Protocol) poruke, standardnog oblika razmjene XML poruka koja je jedna od tehnologija u podlozi web usluga. U SOAP poruci, naziv tražene usluge i ulazni parametri predstavljeni su kao zasebni XML elementi. Ovaj primjer također ilustrira korištenje XML imenskih prostora (xmlns:), još jednog važnog elementa web usluga. Budući da XML dokumenti podržavaju više tipova podataka, složene strukture i agregaciju shema, moderne tehnologije web usluga pružaju značajne prednosti u odnosu na postojeće mogućnosti za pristup softverskim aplikacijama putem HTML-a i URL-ova. Sljedeća generacija mreže Sljedeća generacija weba temeljit će se na interakcijama usmjerenim na softver. Web usluge uključuju korištenje globalnih mreža stvorenih za međuljudsku interakciju u potpuno različite svrhe. Korištenje web usluga vrlo je isplativo s komercijalne točke gledišta. Uz sveprisutnost web usluga, Internet postaje učinkovitiji, posebno za komercijalne transakcije. Kombinacijom izravnog pristupa softverskim aplikacijama i poslovnim dokumentima, sljedeća generacija web usluga na webu omogućit će potpuno automatizirane interakcije koje omogućuju izravan pristup programskim podacima, zaobilazeći poznate web stranice. Štoviše, osnovne komponente web usluga vjerojatno će pružati i objavljivati mnoge različite tvrtke specijalizirane za pojedinačne funkcionalne elemente (provjera vjerodajnica, koordinacija transakcija, upravljanje računima). Ovo će osigurati izravnu interakciju između aplikacija i aplikacija - načelo na kojem se temelje web usluge i definira njihovu bit i implementaciju. OPĆE MEĐUSOBNO RAZUMIJEVANJE Tehnologija web usluga postoji na vrlo visokoj razini apstrakcije, što joj omogućuje da podržava višestruke, ponekad kontradiktorne, istodobne definicije. Na najjednostavnijoj razini, web-usluge se mogu smatrati internetskim posrednicima za integraciju teksta. Bilo koji podatak može se pretvoriti u i iz ASCII teksta, a ovaj je pristup dugo bio zajednički nazivnik za grafičke izlazne sustave i sustave za upravljanje bazama podataka. Tekstualno orijentirani sustavi također su u središtu uspješnog razvoja interneta, na čemu se temelji dodatna apstrakcija web servisa. Bilo koje računalo ili operativni sustav može podržati HTML, preglednike i web usluge; a kada primaju datoteke putem mreže, potpuno su ravnodušni pa čak i ne znaju s kojom vrstom aplikacijskog sustava komuniciraju. Prednosti i nedostaci web usluga. Na dobrobiti web usluge može se pripisati sljedeće: Web usluge omogućuju poduzeću integraciju svojih poslovnih procesa s poslovnim procesima poslovnih partnera i klijenata po nižoj cijeni od korištenja drugih integracijskih tehnologija. Cijena takvih rješenja temeljenih na web uslugama pristupačna je čak i za SMB (Small and Medium Business), što će takvim tvrtkama otvoriti nove razvojne perspektive; Budući da su web usluge organizirane u javne registre (UDDI registri, ebXML registri ili drugi), dostupni zainteresirane stranke u cijelom svijetu se smanjuje prag za tvrtke za ulazak na nova tržišta, dok se povećavaju mogućnosti za širenje baze kupaca; Web usluge osiguravaju kontinuitet u odnosu na IP koji je već dostupan u tvrtki, tj. možemo reći da su web usluge izgrađene na iznad postojeći IP, ali ne umjesto ih. Time se osigurava sigurnost već uloženih ulaganja u informatičku infrastrukturu, a potrebna se ne povećavaju jer nema potrebe za radikalnim promjenama; Izgradnja novih korporativnih rješenja korištenjem web servisa implementira se brže i općenito je jeftinije, budući da je glavna pažnja usmjerena na kreiranje poslovne logike rješenja, a programiranje samih web servisa samo “uokviruje” taj proces po potrebi, bez velikih troškova rada zbog učinkovitom korištenju višekratnog koda i prilagođenih razvojnih alata (IDE i SDK). Nedostaci (protiv) web usluga uključuju: Standardi integracije poslovnih procesa, pitanja upravljanja transakcijama i razvoj jedinstvenih poslovnih i IT politika za tvrtke koje komuniciraju putem web usluga još su u fazi razvoja (navest ćemo sljedeće inicijative: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web usluge (BPEL4WS ("BPEL" skraćeno kao "beeple")) IBM-a, XLANG Microsofta i specifikacije WS-Coordination i WS-Transaction, suradnja između IBM-a, Microsofta i BEA). Očito, bez njihove jasne formalizacije i objave, izgradnja IS-a temeljenog na web uslugama može se odvijati samo s različitim stupnjevima uspjeha; Dinamičko korištenje informacija poslovnog registra web usluga, pozivanje web usluga, zahtijeva rješavanje pitanja povjerenja između različitih poslovnih registara. Osim toga, postoje poteškoće u dijeljenju poslovnih registara različitih formata (na primjer, zadatak traženja određene web usluge u UDDI registru i ebXML registru zahtijeva različite pristupe zbog razlika u XML dokumentima koji opisuju istu web uslugu u svakom od ovih registara. Iako, treba napomenuti da postoje pokušaji da se ovaj problem riješi stvaranjem jedinstvenog preglednika registra. Kao primjer, grafički uslužni program Registry Browser korporacije Sun Microsystems, koji implementira skup JAXR (Java API za XML registre) sučelja; Dodavanje funkcionalnosti pružatelja web usluga funkcionalnosti aplikacijskog poslužitelja može biti izazovno zbog novosti tehnologije; Sigurnosna pitanja rada informacijskih sustava baziranih na web servisima još uvijek nisu u potpunosti riješena. WS-Security specifikacija, produkt aktivnosti IBM i Microsoft korporacija, trenutno je dosta mlada, nije „ustalila“ i djelomično se još dorađuje. Međutim, zbog općenitosti odredbi specifikacije WS-Security, sljedeći sloj specifikacija posvećenih sigurnosnim pitanjima već se priprema za izdavanje: Tvrdnje o politici web usluga, prilozi politici web usluga, okvir politike web usluga, povjerenje web usluga , Web Services Secure Conversation, Web Services Federation . Dakle, prednosti predstavljaju strateške poslovne prednosti poduzeća, a nedostaci su tehnološke prirode i nastaju zbog novosti tehnologije te je rješenje ovih problema samo pitanje vremena. Definicija web usluge Nazovimo servis resurs koji implementira poslovnu funkciju i ima sljedeća svojstva: može se ponovno koristiti; definirano jednim ili više eksplicitnih sučelja neovisnih o tehnologiji; labavo je povezan s drugim sličnim resursima i može se pozvati putem komunikacijskih protokola koji omogućuju međusobnu interakciju resursa. Web usluga(vidi W3C dokument “Zahtjevi za arhitekturu web-usluga”) je softverski sustav identificiran URI nizom čija su sučelja i povezivanja definirana i opisana pomoću XML-a. Opis ovog softverskog sustava mogu pronaći drugi softverski sustavi koji mogu komunicirati s njim u skladu s ovim opisom putem poruka temeljenih na XML-u koje se prenose korištenjem internetskih protokola.
