Infrastructure for Electronic Business on the Internet
Figura Avantazhet e teknologjive të agjentëve te levizshem [Horvat99]
Yüklə 5,92 Mb.
|
5.4 Figura Avantazhet e teknologjive të agjentëve te levizshem [Horvat99], Legjenda: CA - Aplikacionet Client; SA - Server Application; HS - serveri Host, Si, S 2, S 3 - Serverat; NB - Kompjuteri fletore; Koment: Në rastin e parë, pasi agjenti software është mbjellë, paralelizimi i te dhenave ne menyre të pavarur, bëhet njëkohësisht.Në rastin e dytë,agjenti software e kryen punen, edhe pse rrjeti nuk funksionon. Në rastin e tretë, agjenti software ben punen, për shkak se përdoruesi është "dembel" ose "i zënë" me punë të tjera (p.sh.,shperndarjen e e-mail-it). Serveri i agjentit software është përgjegjës për: (a) administrimin, (b) Sigurine, dhe (c) Transferimin. Administrimi i referohet një lloj kontabiliteti, për të mbajtur shenim dhe per tu kujdesur pre agjentin e levizshem ne egzekutim. Siguria i referohet një sërë çështjeve të lidhura 
Figura 5.5 Mekanizmat e mëdha te lëvizshmërisë [Horvat99]. Legjenda: ATP - Protokolli i Transpotit te Agjentit; RMI - Thirrja e Metodave Remote. Kodi i Agjentit është përgjegjës për: (a) Migrimin ndërmjet serverave, (b) Komunikimin midis serverit dhe agjentit, ose ndermjet agjentëve të shumte, dhe (c) Përpunimi i detyrës qe të përfundojë. Me fjalë të tjera, seksione të veçanta të kodit sherbejne për zbatimin e migracionit, të komunikimit, si dhe të përpunimit. Mekanizmat që mundësojnë mobilitetin e agjentit janë të ilustruar në Figurën 5.5. Ka dy mekanizma bazë për zbatimin e agjentëve të lëvizshmërisë: (a) RMI apo thirrje e metodës remote, i bazuar në teknologjinë e thirrjes në distancë se procedurave dhe (b) ATP ose Protokolli i Transpotit te Agjentit, i bazuar në teknologjinë sockets software.
Trajtimi i RMI nënkupton një seri të aktiviteteve handshaking. Trajtimi i ATP nënkupton ekzistencën e një arkitekturë me shtresa në krye të TCP / IP. Figura 5.6 Një përmbledhje e mekanizmave të komunikimit te agjentëve te levizshem [Horvat99]. Legjenda: Transmetim - një për të gjithë; Multicast - një për të shumë (nga një listë e përcaktuar mirë); unicast - nje per nje. Koment: Konkurenca është, si zakonisht, në mes të lehtës dhe efikases. Mekanizmat që mundësojnë komunikimin e agjenteve janë të shënuara në Figura 5.6. Ka katër mekanizma bazë për zbatimin e komunikimit te agjenteve: (a) Thirrja e procedurave, i cili është një mekanizëm sinkron, relativisht i vështirë për tu paralelizuar, (b) Mekanizmi Callback, i cili është një mekanizëm asinkron, relativisht kompleks për tu zbatuar, (c) Mekanizmi Mailbox , i cili është një tjetër mekanizëm asinkrone, gjithashtu relativisht kompleks për tu zbatuar, dhe (d) Mekanizma të Transmetimit, te cilet mund të reduktohet në multicast ose unicast (mekanizmat e transmetimit nënkupton komunikimet nga një për të gjithë, multicast nënkupton komunikimet nga një tek shumë, ndërsa unicast nënkupton komunikimit nga nje tek nje). Mjetet për programimin e agjentëve te levizshem mund të gjenden në JDK (Java Development Kit) Versioni 1.1. ose versionet e më vonëshme. Klasat e specializuara dhe metodat janë dhënë, dhe programuesi ka vetëm për të menduar për aplikacionin. Në versionet e reja, infrastruktura është dhënë edhe për serverët e agjenteve që do të instalohen. Mjetet për zbatimin e sistemeve te agjentit të lëvizshem më kompleks janë të shënuara në Figura 5.7. Këto mjete përfshijnë: (a) Aglet nga IBM Tokio, (b) Voyager nga Object Space, (c) Oddyssey nga General Magic, dhe (d) Concordia nga Mitsubishi Electric. Aglet vë stresin në apletet ne internet, Voyager perqendron stresin në të qenit në gjendje për të kthyer një shumëllojshmëri të llojeve te objekteve tradicionale në lloje objektesh te levizshme, Odyssey e perqendron stresin në aplikacione të shpërndara levizese, dhe Concordia e vë stresin në bashkëpunim midis agjentëve te levizshem. 
Figura 5.7 Disa mjete te njohura për krijimin e aplikacioneve levizese [Horvat99] [GM97] [IBM97] [MEITC A97] [ObjectSpace97]. Legjenda: ITCA - Një departament i Mitsubishi Electronics. Koment: Kur krahasojmë mjetet e këtij lloji, shpesh herë,karakteristikat teknike janë dytesore, si dhe ekzistenca e dokumentacionit të qartë dhe shënimet e mira ne aplikacion janë primare. 5.8 Figura hedh më shumë dritë mbi nëntë karakteristikat e ndryshme të katër mjeteve të zgjedhura për zbatimin e sistemeve të agjenteve te levizshem. Nocionet ne figuren 5,8 janë vetë-shpjeguese. Megjithatë, është edhe një karakteristikë më shumë që është shpesh herë më e rëndësishme - disponueshmërinë e një dokumentacioni që është i lehtë ne përdorim dhe i shpejtë për tu kuptuar. Në një numër projektesh, zgjedhja e mjeteve që do tu përdorur nuk është në bazë të nëntë karakteristikave teknike te listuara, por në
Figura 5.8 Një krahasim i mjeteve të njohura për krijimin e aplikacioneve te levizshme [Horvat99] [Shah98]. Legjenda: GUI - Nderfaqja Grafike e Perdoruesit; RMI - Metoda e Thirrjes Remote. Koment: Në një projekt të fundit, në të cilin ky autor ka qenë i përfshirë, të katër mjetet ishin të kënaqshme nga këndvështrimi teknik. Vendimi përfundimtar per cilat mjete të zgjedhim u bazua në cilësinë e dokumentacionit në dispozicion. disponueshmërinë e një dokumentacion me cilësi të lartë. Arsyeja kryesore prapa marrjes se vendimeve të tilla ishte se, herët a vonë, të gjithë konkurrentët do të konvergojnë me kryerjen e se njejtes performance, kështu që nuk ka rëndësi se çfarë mjeti është përdorur, ajo që është e rëndësishme është 
Figura 5.9 Percaktimi i karakteristikave te modeleve të ndryshme të koordinimit [Cabri98]. Legjenda: bashkim - Aktivizimi i lidhur me burim / ndarjen e të dhënave për qëllime të koordinimit. Koment: bashkim me i vogel,sa më efikas modeli, vetëm një gjë - që të ketë një nisje të shpejtë. 5.5 Modelet Koordinuese për agjentët e levizshem Gjatë jetës së tyre normale, agjentët e levizshem duhet të koordinojnë aktivitetet e tyre me subjektet e tjera që ata mund të takojne në hostet remote, si: (a) burimet e Host-it dhe (b) të agjentëve të tjera. 5.5.1 Çështjet e Rëndësishme Koordinimi i përshtatshem i agjenteve është i nevojshem për dy arsye kryesore: (a) Për të shmangur vizitat e shumta të disa agjentëve në vendin e njëjtë, dhe (b) Për të mundësuar tërheqjen precize dhe efikase te informacionit nga nje site remote. Arsyeja e parë është e lidhur me komunikimet mes dy agjentëve. Arsyeja e dytë ka të bëjë me komunikimin ndërmjet një agjenti dhe një burimi në vendin e remote host-it. Legjenda: S- Hapësinor; T - I përkohshëm. Koment: Modeli Linda është më i efektshmi, dhe me kompleksi per tu realizuar.Emri i modelit Linda vjen nga një projekt i njohur për përpunimin e procesimit të shpërndare që eksperimentoi me nocione të ngjashme. Prezantimi qe vijon supozon se (a) aplikimi me i madh i agjentëve te levizshem është kërkimi i informacionit dhe rikthimi i tij, dhe (b) Agjentët e lëvizshme janë në gjendje të klonojne veten. Karakteristikat që dallojnë koordinimin e modeleve të ndryshme janë: (a) Ekzistenca ose jo e bashkimit hapësinor dhe (b) Ekzistenca ose jo e bashkimit te përkohshëm.Termat bashkim hapësinore dhe bashkim i përkohshëm janë të percaktuara në figurën 5,9. Bashkimet e veçanta nënkuptojne se komunikimi i agjentëve te levizshem ndan një emer hapësire të përbashkët,e për rrjedhojë, modelet e pabashkuara hapsinore detyrojne nje ndërveprim anonim. Bashkimi i perkohshem nënkupton që komunikimi i agjentëve te levizshem duhet të jetë i sinkronizuar;për rrjedhojë,modelet perkohesisht te pabashkuara arrijne nje ndërveprim asinkron. Katër kategori kryesore të modeleve të koordinimit janë të shënuara në figurën 5,10, së bashku me emrat e disa sistemeve që zbatojnë katër modelet. Këto katër modele janë: (a) koordinimi i drejtpërdrejtë (edhe bashkimin e perkoshem edhe ate spacial), (b) koordinim i orientuar (bashkim i perkohshem dhe spacial te pabashkuar), (c) koordinimi Blackboard-based (bashkim spacial dhe perkohesisht i pabashkuar), dhe ( d) koordinimi Linda (të dyja spacial dhe i perkohshem i pabashkuar). Sa me i ulët nivelin i bashkimit,aq më fleksibël modeli i koordinimit. Në rastin e koordinimit të drejtpërdrejtë, agjentët e levizshem fillojë të komunikojne me njëri-tjetrin duke emërtuar qarte palët e përfshira (kjo zbaton bashkim hapësinor). Në koordinimin me ndër-agjent, dy agjentët e levizshem duhet të bien dakord mbi protokollin e përbashkët të komunikimit, i cili zakonisht është një protokoll peer-to-peer. Qasja në burimet lokale te mjedisit te hostit është bërë duke përdorur trajtim klient-server. Çdo burim në mjedisin host menaxhohet nga një server i dedikuar. Agjenti i levizshem merr shërbimet nga burimet e hostit duke furnizuar parametrat (dhe ndonjëherë edhe kodin) në serverat e burimeve te hostit. Komunikimi i drejtpërdrejtë me ndër-agjent në shkallë të lartë-do të thotë protokolle komplekse rutimi dhe komunikimet bëhen shumë të varura nga besueshmërinë e rrjetit. Gjithashtu, komunikimin midis subjekteve të lëvizshme janë të vështira për programin. Transmetimi është një zgjidhje e mundshme, por kjo ndihmon vetëm me aplikacione të vogla. Koordinimi i drejtpërdrejtë është i mirë për akses në burimet lokale të mjedisi te hostit, pasi ata janë zakonisht statike. Në rastin e takimit të koordinimit të orientuar, agjentët e levizshem mund të bashkëveprojnë, por ata nuk kanë per te emruar ne menyre eksplicit palët e përfshira. Ndërveprimi ndodh në kontekstin e takimeve. Një pikë e re takimi është e përcaktuar, e hapur, dhe mbahet nga një nismëtar, te cilet shpesh herë shërbejne edhe si server per pikat e takimit. Pasi një pikë e re takim është themeluar, ajo mund te bashkohet nga agjentët e levizshem te interesuar. Një nga pyetjet e shpeshta është se si nje agjentët e levizshem mesojne për një pikë të re. Ky informacion është marrë nga modeli broadcast ose multicast, i cili është i kufizuar në qëllime për mjedisin e hostit remote. Modeli Broadcast ose multicast nuk e shpërndarë në një Intranet ose në te gjithe internetin, me qëllim për të shmangur trafikun e gjerë dhe të panevojshme te rrjetit. Tabelat nuk janë përdorur, që nga perfshirja e mosbashkimit spacial(hapsinor). Koordinimi i orientuar mund të zgjidhë problemet e lidhura me nevojën për identifikimin e palëve të përfshira dhe në mënyrë eksplicite, për shkak se trajtimi nënkupton mosbashkim hapësinor. Rreziku i një agjenti te levizshem qe humb një ndërveprim (dmth., rreziku i agjentit te levizshem nuk eshte në pikën e takimit, kur agjentët e tjere të lëvizshem janë atje) është relativisht e lartë. Si pasojë, sinkronizimi i rreptë është i nevojshem, që kufizon fushën e ndërveprimit në bashkëveprim-vetem-lokal (kjo do të thotë, mjedis remote ne nyje, ose një Intranet të vogël, që nga sinkronizimi në lidhje me një Intranet apo në te gjithë internetin do të ishin te shtrenjta). Problemi i vizitave të shumta të agjentëve të ndryshem te levizshem në vendin e njëjtë është zgjidhur duke i lejuar agjent e levizshem, para se të lëvizin për në nyjen e ardhshëm të largët, për të lënë një vulë të përshtatshme kohore. Nëse një agjent i levizshem vjen në një nyje të largët dhe gjen një pullë kohë atje, ai e di që një tjetër agjent i levizshem me të njëjtën kërkesë tashmë ishte aty. Në këtë rast, një vendim duhet të meret, për t'u larguar menjëherë, ose të rivizitoj sërish vendin, nëse supozohet se disa pjesë të reja dhe interesante te informacionit krijohen ndërkohë (kjo është arsyeja pse agjentët e levizshem lënë vulat e kohës, dhe jo tage pa informacion lidhur me kohë). Natyrisht, zgjidhja me vulat koha ka te meta. Privatsia mund të keqpërdoret (sepse meret vesht se cili ishte atje, dhe kur), dhe se mund të ketë probleme me forcimin e gjendjes se vdekjes (skenare të ndryshme janë të mundshem, te cilet i lihen lexuesit te interesuar për tu shtjelluar). Në rastin e koordinimit blackboard-based,agjentët e levizshem bashkëveprojnë nëpërmjet hapësirave të përbashkëta të te dhënave, të cilat janë lokale për mjedisin e hostit. Hapësira e përbashkët e të dhënave hapësinore do të thotë bashkim. Komunikimet janë të bazuara në blackboards, që nënkupton mosçiftimi plotë i perkohshem - agjentë te levizshem të ndryshem mund të vizitojne blackboards-at në kohë të ndryshme. Kur arrin një agjent në nje site remote, ai menjëherë kontrollon blackboard-in, për një mesazh shenjues (dmth., një lloj vule kohe) nga një tjetër agjent i të njëjtit aplikim. Nëse nuk është gjetur asnje mesazh shënues, agjenti i levizshem mund te lere vetë mesazhin e tij shënues. Koordinimi Blackboard ka përparësi (në lidhje me ekzistencën e bashkimeve te përkohshme - mesazhet mund të lihen në blackboard) dhe disavantazhet (lidhur me ekzistencen e bashkimit hapësinor - subjekte qe bashkveprojmë duhet të bien dakord mbi emrat e mesazheve të përbashkëta). Në rastin e koordinimit Linda,aksesi në blackboards lokale është i bazuar në zbatimin e një mekanizmi te shoqëruar. Në shumicën e sistemeve, informacioni është marrë duke përdorur një mekanizëm pattern-matching. Kjo do të thotë që fjalë kyçe mbi blackboardin dhe ne koken e agjentit te levizshem te specifikuar duhet te jene njelloj, zakonisht në mjedisin e HTML (hapësirën e kërkimit për kombinim është brenda kufijve të dokumentit HTML). As marrëveshje te perkohshme e as dituri e përbashkët nuk eshte e nevojshme, sepse trajtimi perfshin të dy mosçiftimet si hapësinore dhe të përkohshme. Në mënyrë që të bashkëveprojnë me mjedisin lokal, agjentët e levizshem duhet te krijojne entitet e tyre ObjectSpace. Koordinimi Linda është modeli i vetëm (nder katër modelet ekzistuese) që ofron pershtatje adekuate dhe shkallzueshmeri për aplikimet e ardhshme ne Internet (Tri trajtimet e tjera janë më të përshtatshme për intranets dhe Internet fushe veprimi te kufizuar). Trajtimi ka potenciale, por puna e tij është shumë e varur në cilësinë e zbatimit. Me fjalë të tjera, potencialet mund të arrihet vetëm nëse përpjekje të mjaftueshme vihen në zbatim te trajtimit. 5.5.2 Shembuj të dy trajtimeve me modelin Linda Dy trajtimi të ndryshme te modelit Linda do të diskutohen shkurtimisht. Një është e lidhur me tregun elektronik [Bettini98], dhe tjetra për bursën elektronike të aksioneve [Ciancarrini98]. 
Figura 5 0,11 Shembull i një tregu elektronik [Bettini98]. Legjenda: CameraClient - Një pseudokod "applet" (qe mund te thirret nga nje dokument HTML); MarketClient - Një pseudokod "appleti"; ShopAgent - Një pseudokod "appleti". Koment: Vini re se programet e shumta ShopAgent mund të ekzekutohen njëkohësisht. 5.5.2.1 Nje trajtim me modelin Linda i implementuar në X-KLAIM 5.11 Figura ilustron një shembull te një tregu elektronik i zbatuar në gjuhën X-KLAIM, e cila është një formë e gjuhes KLAIM e përmendur me pare. I gjithe aplikacioni është i bazuar në një sërë procesesh se agjenteve. CameraClient është një proces klient që aktivizon një agjent te levizshem për të punuar në tregun elektronik. MarketAgent është një agjent i lëvizshëm, me të ardhur në një destinacion të internetit, ai kërkon listën e dyqaneve, dhe i viziton ato, duke i pyetur për emrin e dyqanit, distanca fizike e dyqanit nga pozicioni i pronarit të agjentit të lëvizshem, bëjnë nga produkti, dhe çmimi i produktit. ShopAgent është një agjent që përfaqëson një dyqan, ai është në gjendje të japë të dhënat e kërkuara për emrin, distancën, ndertimin, dhe çmimin. Ky agjent eshte i klonuar në disa kopje, një për secilin dyqan. 
Figura 5,12 Shembull kodi CameraAgent [Bettini98].Legjenda: Ky është një pseudokod. Koment: Kodi për MarketAgent dhe ShopAgent i është lënë lexuesit per ta zhvilluar, si një ushtrim. 5.12 Figura tregon kodin CameraAgent, duke përdorur një pseudokod-tipike per gjuhet e orientuara nga objektet. Pseudo-kodi është vetë-shpjegues. lexuesit e interesuar janë të mirëpritur për të ndryshuar pjesë të pseudo-kodit , për të treguar se ata i kuptojnë të dhënat. 
Figura 5,13 Shembull i WWW aktive [Ciancarrini98]. Legjenda: CORBA - Objektet e zakonshme kerkojne ndërmjetës ne arkitekturë. Koment: WWW-ja Aktive është aktivizuar nga një program browser WWW, dhe mund të shfrytëzojnë CORBA dhe / ose objektet e ngjashme. 5.5.2.2 Nje trajtim i modelit Linda duke implementuar Web-in Aktiv Figura 5.13 ilustron një shembullin e një faqe WWW aktive e implementuar duke përdorur trajtimin sipas modelit Linda. WWW aktive është në gjendje të përdore shërbimet e ofruara nga klientët dhe serverat WWW. Ky studim është i bazuar në përdorimin e PageSpace (përmendur më parë), e cila është në thelb një kornizë për dizajnin e WWW aktive, e përbërë nga agjentët autonome qe kryerjen detyrat të tyre; kjo kornize mund të kontrollohet me gjuhë të ndryshme të koordinimit. Ky studim ishte duke përdorur gjuhën e koordinimit Paradise, e cila u zhvillua në Universitetin e Bolonjës. Shembulli i Figures 5.13 i referohet një aplikimi stock exchange (ankande të shumta të mallrave të shpërndarë). Të gjitha detajet e Figures 5.13 janë përshkruar në titullin e saj. 5.6 Studimet e çështjeve te Zgjedhura në Teknologjia e Agjenteve te Levizshem Kumtesa "Krahasimi i familjeve te Agjenteve te levizshem" jane bashkë-autor nga studiuesit nga Universiteti i Karlsruhe ( hartroth@ira.uka.de ).Krahason një agjent one-hop dhe nje multi-hop dhe efiqencen e tyre në skenare të ndryshme të interesit. Kumtesa "Distributed Heterogeneous Database Systems Based on Mobile Agents" jane bashkë-autor nga studiuesit nga Universiteti i Catania ( csanto@iit.unict.it ).Ai nderfuti paradigmat e agjentëve te levizshem në vend të paradigmave te modelit klient-server, si një mënyrë më e mirë per sa i perket çështjeve të modelit në aplikimet e agjentëve te levizshem. Kumtesa "Protokollet për Faturimin e Agjenteve te Levizshem" jane bashkë-autor nga studiuesit nga Universiteti Kombëtar i Singaporit. Ajo diskuton një zgjerim të standardit MobilelP - një zgjerim qe eshte përgjegjës për faturimin e agjentëve te levizshem. 5.7 Kërkimi ne Internet Ka dy trajtime themelore për kërkimin në Internet: (a) kërkim ne bazë te indekseve dhe (b) kerkim ne baze te lidhjeve. Shembuj të motorëve te kërkimit me bazë indeksimi janë Altavista, Infoseek dhe të ngjashme. Shembuj të motorëve te kërkimit ne baze te lidhjeve janë spiders, Yahoo dhe të ngjashme. Trajtimet e bazuara në indeksimin e kërkimit është i përhapur dhe i njohur mirë. Megjithatë, ai ka të meta të caktuara. Informacioni nuk mund të gjendet nëse ai nuk është i indeksuar me parë. Kjo nuk do të jetë një problem, në qoftë se indeksimit është bërë menjëherë, dmth menjëherë pasi informacioni (një prezantim të ri ne WWW) është krijuar. Megjithatë, ky nuk është rasti. Edhe në qoftë se krijuesi i prezantimit të ri ne WWW raporton pamjen e tij ofruesit te shërbimit te kërkimit ne baze te indekseve, mund të duhen ditë, javë, ose edhe muaj, para se të dhënat e lidhura me te ,te indeksohen. Në përfundim, informacioni është "padukshem" për motorët e kërkimit ne baze te indekseve, për një periudhë kohore, që nga krijimi e tij deri në indeksimin e informacionit. Me fjalë të tjera, gjatë kësaj periudhe kohore, të dhënat e nevojshme nuk mund të gjendet nga motorët e kërkimit qe kerkojne ne baze te indekseve. Pyetja është, çfarë ndodh në qoftë se dikush ka për të gjetur disa informacione para se të marrë indeksin. Përgjigja është, që të kthehet në metodat e kerkimit ne baze te lidhjeve. Si pasojë,metodat e kërkimit ne baze te lidhjeve janë të rëndësishme për te ashtu-quajturin misionin e "kritike" te bizneseve, ku është e rëndësishme që të gjeni disa informacione para se të indeksohen, si dhe para se të vihet gjerësisht në dispozicion të konkurrencës. Me arritjen në disa pjesë të informacionit të ri para të tjerëve (pra, duke aksesuar ndonjë prodhim të ri para se të tjerët ta bejne ate), dhe ka më shumë gjasa për të krijuar një diferencë më të mirë fitimi. Një tjetër pyetje është, cili është thelbi që i bën metodat e bazuara ne lidhje të zbatueshme për misionin kritike ne biznese. Përgjigja e këtyre pyetjeve jepet më mirë, pasi shohim se si funksionojne mekanizmat e kerkimit ne baze te lidhjeve. Ka dy trajtime themelore për të kërkimin ne baze te lidhjeve. Njëra është më e drejtpërdrejtë, dhe permendet si kerkim gjenetik. Tjetri është më indirekt, dhe permendet si forcim i simuluar. Algoritme gjenetike fillimisht ishin shpikur dhe zhvilluar në fushën e inteligjencës artificiale. Forcimi i simuluar fillimisht ishte shpikur e zhvilluar në fushën e matematikës se aplikuar. 
Figura 5.14 Përfaqësim simbolik të një algoritmi gjenetik për kërkim në Internet. Legjenda: D - Aplikimi i drejtpërdrejtë i URL-se se gjetur në faqen e mëparshme WWW; M - Mutacioni i URL se gjetur në faqja e mëparshme WWW , si dhe zbatimin e URL-ve te mutacionuara, W - Një faqe WWW. Koment: Kontrolli fillon nga një "faqe premtues" WWW .Të gjithe pointerat ne adresën URL në këtë faqe WWW janë të vendosura (tre në këtë shembull). Disa prej tyre janë zbatuar direkt në faqet e reja WWW (dy në këtë shembull). Ne të tjerat me pare kryhet mutacioni dhe më pas aplikimi(një në këtë shembull). 5.7.1 Genetic Algorithms for the Internet Search KAPITULLI 6 Kasheja Proxy Kasheja në Internet ka disa aspekte. Dikush mund të flase për kashe në nivele të larta kërkese, në lidhje me Kashen në video në domenin e nivelit të kërkesës, ose në lidhje me kashen në nivelin domain proxy. Ky kapitull është i dedikuar për kashen proxy dhe problemet e lidhura me te . 6.1 Hyrje në Proxy Server Proxy serverat janë një shtesë në serverat WWW, duke siguruar kashen (që do të diskutohen në këtë kapitull) dhe të sigurisë (jashtë objektit të këtij libri). Proxy server është trajtuar si një pjesë e serverit WWW. Siç tregohet në Figurën 6.1, kjo është e vendosur ndermjet serverit dhe klientit. Të gjitha të dhënat nga serveri tek klienti dhe anasjelltas duhet të kalojnë nëpërmjet proxy server. Si pasojë, proxy server është një vend ideal për kashen e internetit mekanizmat dhe gjithashtu për mekanizmat e sigurisë në Internet. Probleme të mëdha me arkitektura klient-server tradicionale janë: (a) Serverat janë të mbingarkuara dhe nuk jane te mbrojtur plotësisht nga abuzimet që vijnë nëpërmjet rrjetit, (b) është i mbushur plot dhe gjeresia e brezit në dispozicion nuk të siguron nje nivel te mire shërbimi, dhe (c) pergjigjja e kerkesave behet e gjate. 
Figure 6.1 An illustration of the role of the proxy layer - bringing savings, both to the server and the clients [Petkovic99]. Legend: Term proxy comes from a word for an agency function, related to the power of a person authorized to act as the deputy or substitute for another. Comment: Major functions of traditional proxy servers are security (not covered in this book) and caching (covered in this book). 
Figure 6.2 Proxy forms - server proxy, intermediate proxies, and client proxies [Petkovic99]. Legend: The kernel of the proxy operation is the request-response cycle. Comment: Proxy cache stores a copy of the requested object, which brings the following savings:
Duke futur një server proxy në mes serverit dhe klientit WWW, siç tregohet në Figurën 6.2, të tre problemet reduktohen, ose eliminohen: (a) Një numër i kontrolleve përkatëse mund të bëhen nga proxy (të referuara si firewall funksion), kështu që problemi i mbrojtjes se serveri gjithashtu rritet ndjeshëm, (b) numrin e kërkesave të vendosura para serverit janë me shërbim nga proxy (p.sh., nga kasheja proxy), kështu mbingarkesa e serverit ulet ndjeshëm si problem (c) Së fundi, proxy është më afër klientit, kështu pergjigjja ndaj mesazheve eshte me e shpejte per te arritur tek klienti (veçanërisht në qoftë se, përveç kashes, prefetching është përdorur). Në parim, proxy server mund të vendoset në disa vende në internet: (a) perpara serverit, (b) perpara klientit, dhe (c) Në një vend të përshtatshëm në mes serverit dhe klientit. Kasheja Proxy ruan një kopje lokale të objektit të kërkuara, e cila sjell tre përfitime të rëndësishme: (a) Numri i sulmeve të serverit WWW është reduktuar, (b) Numri i biteve në internet është i reduktuar, dhe (c) kohë që përdoruesit të presin për objektin qe do të shkarkoje reduktohet, gjithashtu. Proxy prefetching është një lloj akseleratori performancës, qe eshte ne pune (ne më të shumtën e kohës), në lidhje me kashen proxy. Ajo i ndihmon për uljen e shtesë se gjendjes se rrjetit, nga kopje ruajtjen e objekteve që nuk janë kërkuar ende, por qe mund të kërkohen se shpejti. 6.2 Hyrje në kashen Proxy Në parim, siç tregohet në Figurën 6.3, sistemi proxy kashe mund të organizohet ne menyre hierarkike.Topologjia e figures 6.3 korrespondon me një skenar tipik që punojnë në një departament të universitetit. Ajo përfshin dy kasha proxy. Kur një artikull të dhënash është e nevojshme, një nga arka proxy është kontrolluar e parë, dhe nëse te dhenat e dëshiruar nuk jane gjetur, tjetra është e kontrolluar, gjithashtu. Shkarkimi nga interneti është inicuar vetëm nëse të dhënat nuk gjendet në asnjë nga dy kashet proxy. Nëse kasheja e klientit është ndërtuar në një shfletues WWW, ajo mund të jetë: (a) e vazhdueshme ose (b) jo e vazhdushme. Proxy-t e vazhdueshem mbajnë dokumentet e tyre në mes të dy shfletuesve kerkues WWW (për shembull, që është rasti me shfletuesin Netscape Navigator).Kasheja jo e vazhdushme nuk cakton asnjë kujtese memorjeje ose disk per te ruajtur kur përdoruesi mbyll shfletuesin (për shembull, që është rasti me shfletuesin Mozaiku). Vini re se proxy e vashdueshem nuk jane domosdoshmërisht më të mirë se ato jo te vazhdueshmit. Kjo varet nga kërkesa. Shpesh herë, është më mirë për të filluar një seancë të re shfletimi me një arkë boshe, se sa me një sasi që është e mbushur me të dhënat e parëndësishme. 
Often times, it is better to start a new browsing session with an empty cache, rather than with a cache that is filled up with irrelevant data. Legend: This example shows the implementation of proxy caching in the School of Electrical Engineering, University of Belgrade. Comment: The two proxy servers back-up each other. If an object is not found in the closest proxy server, the other proxy server is checked first, before the request is forwarded to the Internet Karakteristikat e nje transporti te një sasi proxy janë të rëndësishme për ecurinë e saj. Kasheja-ja mund të punojnë me norma të ndryshme të transferimit të brendshme dhe të jashtme, sepse gjendjet e brendshme dhe të jashtme janë të ndryshme në këtë çështje të përgjithshme. Figura 6,4 pikat e burimet dhe te gjendjeve te brendshme dhe të jashtme. Raporti per cmimin me te mire dhe performancen, këto dy gjendje duhet të jetë te ekuilibruar. Gjatë llogaritjes së normave konkrete te transferimit të zbatuara, ka për të marrë në konsideratë jo vetëm gjendjet e brendshëm e të jashtëm, por edhe volumin qe do të transferohet dhe probabilitetin e një qasje të ardhshme për të njëjtin objekt. Karakteristikat me te medha te kashes të cilat kufizojnë performancën e diskut janë të kufizuara nga I / O dhe throughput e kufizon hapësira e magazinimit te kashes. Për këtë arsye, perdoret nje kashe e cila mund te levizet kur perdoret, dhe ne nën-seksionet i eshte kushtuar menyres se heqjes. 6.3 Politikat e Largimit për kashen Proxy Çdo politikë heqjeje perdore një algoritëm per llojet e objekteve të fshehur në bazë të disa kritereve. Kur vjen koha për largimin e një objekti nga kasheja, objekti që do të hiqet është ne krye të listës nga listat e renditura. Ka tre skenare heqjen: (a) Largimi mbi kërkesën, pra, heqja është bërë kur madhësia e objektit te kërkuar tejkalon madhesine e kashes, (b) heqjen periodike, p.sh., heqja është bërë në mënyrë periodike çdo njësi T te kohës; dhe (c) heqjen e kombinuar, pra, heqja është bërë si në mënyrë periodike dhe të kërkesës. Në literaturën e hapur, mbi heqjen e kërkesës shpesh here i jane referuar si zëvendësim. 
Figure 6.4 Internal versus external latency [Petkovic99]. Legend: Parameters influencing the latency are:
Comment: The major performance-limiting characteristics of proxy cache are the limited storage space and the disk I/O throughput. Figura 6.5 përcakton një numër algoritmesh per heqje. Siç treguam tashmë, ato janë përdorur për të renditur objektet në kashe, në mënyrë që objektet që hiqen të parët janë ato që kanë më pak të ngjarë të jenë te nevojshem në të ardhmen. Të gjitha algoritme e largimit nga Figura 6.5 janë të përcaktuara dhe të shpjeguara plotësisht në figurë. Larmia e madhe e tyre tregon për faktin se shumë kerkime aktive kane ndodhur në këtë fushë. Vini re se, në teori, secili algoritem i Figures 6.5 mund të mbështesin ose heqjen e kërkesës, ose heqjen periodike, ose heqjen e kombinuar. Megjithatë, shumica e implementimeve deri tani mbështesin heqjen e kerkeses. Implementimi i të gjitha metodave te përmendura në Figurën 6.5, perdore vetëm zbatimi Pitkow-Recker mbështet heqjen e kombinuar. 
Yüklə 5,92 Mb. Dostları ilə paylaş:
|