Aplikacijski strežnik, spletni strežnik: Kakšna je razlika?

23. avgust 2002

V: Kakšna je razlika med aplikacijskim strežnikom in spletnim strežnikom?

Spletni strežnik obravnava izključno zahteve HTTP, medtem ko aplikacijski strežnik aplikacijskim programom prek poljubnega števila protokolov služi poslovno logiko.

Vsakega podrobneje preučimo.

Spletni strežnik

Spletni strežnik obravnava protokol HTTP. Ko spletni strežnik prejme zahtevo HTTP, se odzove z odzivom HTTP, na primer pošlje nazaj stran HTML. Za obdelavo zahteve se lahko spletni strežnik odzove s statično stranjo HTML ali sliko, pošlje preusmeritev ali prenese generiranje dinamičnega odziva na nekatere druge programe, kot so skripti CGI, JSP-ji (strani JavaServer), strežniški programčki, ASP-ji (aktivne strani strežnika). ), JavaScripts na strani strežnika ali katera druga tehnologija na strani strežnika. Ne glede na njihov namen takšni programi na strežniški strani ustvarijo odziv, najpogosteje v HTML, za ogled v spletnem brskalniku.

Razumejte, da je model pooblaščanja spletnega strežnika dokaj preprost. Ko zahteva pride v spletni strežnik, spletni strežnik preprosto posreduje zahtevo programu, ki je najbolje sposoben to obdelati. Spletni strežnik ne ponuja nobene funkcije, razen preprostega zagotavljanja okolja, v katerem lahko strežniški program izvede in posreduje nazaj ustvarjene odgovore. Strežniški program ponavadi zagotavlja takšne funkcije, kot so obdelava transakcij, povezljivost baze podatkov in sporočanje.

Spletni strežnik sicer morda sam ne podpira transakcij ali združevanja povezav z bazo podatkov, vendar lahko uporablja različne strategije za odpoved napak in razširljivost, kot so uravnoteženje obremenitve, predpomnjenje in združevanje v skupine - funkcije, ki so pogosto pomotoma dodeljene kot funkcije, rezervirane samo za strežnike aplikacij.

Aplikacijski strežnik

Kar zadeva aplikacijski strežnik, po naši definiciji aplikacijski strežnik odjemalskim aplikacijam prek različnih protokolov, vključno s HTTP, izpostavi poslovno logiko. Medtem ko se spletni strežnik ukvarja predvsem s pošiljanjem HTML-ja za prikaz v spletnem brskalniku, aplikacijski strežnik omogoča dostop do poslovne logike, ki ga uporabljajo odjemalski aplikacijski programi. Aplikacijski program lahko uporablja to logiko, tako kot bi poklical metodo na objektu (ali funkciji v postopkovnem svetu).

Takšni odjemalci aplikacijskega strežnika lahko vključujejo GUI (grafični uporabniški vmesnik), ki se izvajajo v osebnem računalniku, spletnem strežniku ali celo drugih strežnikih aplikacij. Informacije, ki potujejo naprej in nazaj med strežnikom aplikacij in njegovim odjemalcem, niso omejene na preprosto označevanje zaslona. Namesto tega so informacije programska logika. Ker ima logika obliko klicev podatkov in metod in ne statičnega HTML-ja, lahko odjemalec uporabi izpostavljeno poslovno logiko, kakor hoče.

V večini primerov strežnik to poslovno logiko izpostavi s komponentnim API-jem, kot je model komponente EJB (Enterprise JavaBean), ki ga najdemo na aplikacijskih strežnikih J2EE (Java 2 Platform, Enterprise Edition). Poleg tega aplikacijski strežnik upravlja lastna sredstva. Takšne naloge varovanja vrat vključujejo varnost, obdelavo transakcij, združevanje virov in sporočanje. Tako kot spletni strežnik lahko tudi strežnik aplikacij uporablja različne tehnike razširljivosti in odpornosti na napake.

Primer

Kot primer lahko razmislite o spletni trgovini, ki v realnem času ponuja informacije o cenah in razpoložljivosti. Najverjetneje bo spletno mesto ponudilo obrazec, s katerim lahko izberete izdelek. Ko oddate poizvedbo, spletno mesto izvede iskanje in vrne rezultate, vdelane na strani HTML. Spletno mesto lahko to funkcionalnost izvaja na več načinov. Pokazal vam bom en scenarij, ki ne uporablja aplikacijskega strežnika, in drugi, ki ne. Če vidite, kako se ti scenariji razlikujejo, boste lažje videli funkcijo aplikacijskega strežnika.

Scenarij 1: Spletni strežnik brez strežnika aplikacij

V prvem primeru samo spletni strežnik zagotavlja funkcionalnost spletne trgovine. Spletni strežnik sprejme vašo zahtevo, nato pa jo posreduje strežniškemu programu, ki je zmožen obdelati zahtevo. Strežniški program informacije o cenah poišče iz baze podatkov ali ploščate datoteke. Ko je program na strani strežnika pridobljen, podatke uporabi za oblikovanje odziva HTML, nato pa jih spletni strežnik pošlje nazaj v vaš spletni brskalnik.

Če povzamem, spletni strežnik preprosto obdela zahteve HTTP, tako da odgovori na strani HTML.

Scenarij 2: Spletni strežnik s strežnikom aplikacij

Scenarij 2 je podoben scenariju 1, saj spletni strežnik še vedno prenese odziv na skript. Vendar lahko zdaj poslovno logiko za iskanje cen postavite na aplikacijski strežnik. S to spremembo lahko skript preprosto pokliče storitev iskanja aplikacijskega strežnika, namesto da bi skript vedel, kako poiskati podatke in oblikovati odgovor. Skript lahko nato uporabi rezultat storitve, ko skript ustvari svoj odgovor HTML.

V tem primeru strežnik aplikacij služi poslovni logiki za iskanje informacij o cenah izdelka. Ta funkcionalnost ne pove ničesar o zaslonu ali o tem, kako mora stranka uporabiti informacije. Namesto tega odjemalec in strežnik aplikacij pošiljata podatke sem in tja. Ko odjemalec pokliče storitev iskanja aplikacijskega strežnika, storitev preprosto poišče informacije in jih vrne odjemalcu.

Z ločitvijo logike oblikovanja cen od kode, ki ustvarja odziv HTML, postane logika določanja cen veliko bolj uporabna med aplikacijami. Druga stranka, na primer blagajna, bi lahko poklicala isto službo, kot uslužbenec odjavi stranko. Nasprotno pa v scenariju 1 storitve iskanja cen ni mogoče ponovno uporabiti, ker so informacije vdelane v stran HTML. Če povzamemo, v modelu Scenarija 2 spletni strežnik obravnava zahteve HTTP tako, da odgovori s stranjo HTML, medtem ko aplikacijski strežnik služi logiki aplikacije z obdelavo zahtev za cene in razpoložljivost.

Opozorila

V zadnjem času spletne storitve XML zabrišejo mejo med aplikacijskimi strežniki in spletnimi strežniki. S posredovanjem koristnega tovora XML spletnemu strežniku lahko spletni strežnik zdaj obdela podatke in se odzove tako kot v preteklosti aplikacijski strežniki.

Poleg tega večina aplikacijskih strežnikov vsebuje tudi spletnega strežnika, kar pomeni, da lahko spletni strežnik štejete za podmnožico aplikacijskega strežnika. Medtem ko aplikacijski strežniki vsebujejo funkcionalnost spletnega strežnika, razvijalci le redko uvedejo aplikacijske strežnike v tej vlogi. Namesto tega po potrebi pogosto uvedejo samostojne spletne strežnike v tandemu s strežniki aplikacij. Takšno ločevanje funkcionalnosti pomaga pri zmogljivosti (preproste spletne zahteve ne bodo vplivale na zmogljivost strežnika aplikacij), konfiguraciji uvajanja (namenski spletni strežniki, združevanje v skupine itd.) In omogoča izbiro najboljših izdelkov.

Tony Sintes je neodvisni svetovalec in ustanovitelj svetovalnega podjetja First Class Consulting, ki je specializirano za premostitev različnih podjetniških sistemov in usposabljanja. Zunaj prvovrstnega svetovanja je Tony aktivni samostojni pisec in avtor knjige Sams Teach Yourself Objekt-Oriented Programming in 21 Days (Sams, 2001; ISBN: 0672321092).

Preberite več o tej temi

Za več člankov o strežnikih aplikacij poiščite Java strežniki aplikacij odsek JavaWorld 's Aktualni indeks
//www.javaworld.com/channel_content/jw-appserv-index.shtml
Želijo več? Glej Vprašanja in odgovori o Javi indeksna stran za celoten katalog Vprašanj
//www.javaworld.com/columns/jw-qna-index.shtml
Obiščite več kot 100 vpoglednih nasvetov Java nekaterih najboljših mož v poslu JavaWorld 's Java Nasveti indeksna stran
//www.javaworld.com/columns/jw-tips-index.shtml
Preberite več o strežnikih aplikacij in spletnih strežnikih v našem Enterprise Java diskusija
//forums.idg.net/webx?50@@.ee6b80a
Prijavite se za JavaWorldje brezplačen tedensko Enterprise Java e-novice
//www.javaworld.com/subscribe
Na naslovu .net boste našli ogromno člankov, povezanih z IT, iz naših sestrskih publikacij