App-server, webserver: Hvad er forskellen?

23. august 2002

Spørgsmål: Hvad er forskellen mellem en applikationsserver og en webserver?

EN:

En webserver håndterer udelukkende HTTP-anmodninger, mens en applikationsserver serverer forretningslogik til applikationsprogrammer gennem et vilkårligt antal protokoller.

Lad os undersøge hver mere detaljeret.

Webserveren

En webserver håndterer HTTP-protokollen. Når webserveren modtager en HTTP-anmodning, svarer den med et HTTP-svar, såsom at sende en HTML-side tilbage. For at behandle en anmodning kan en webserver svare med en statisk HTML-side eller et billede, sende en omdirigering eller delegere den dynamiske responsgenerering til et andet program såsom CGI-scripts, JSP'er (JavaServer Pages), servlets, ASP'er (Active Server Pages) ), serversiden JavaScripts eller anden teknologi på serversiden. Uanset deres formål genererer sådanne server-side-programmer et svar, ofte i HTML, til visning i en webbrowser.

Forstå, at en webserver's delegationsmodel er ret enkel. Når en anmodning kommer ind på webserveren, sender webserveren simpelthen anmodningen til det program, der er bedst i stand til at håndtere den. Webserveren leverer ikke nogen funktionalitet ud over blot at give et miljø, hvor server-side-programmet kan udføre og videregive de genererede svar. Programmet på serversiden sørger normalt for sig selv funktioner som transaktionsbehandling, databaseforbindelse og messaging.

Mens en webserver muligvis ikke selv understøtter transaktioner eller pooling af databaseforbindelser, bruger den muligvis forskellige strategier til fejltolerance og skalerbarhed, såsom belastningsbalancering, caching og klyngedannelse - funktioner, der ofte fejlagtigt er tildelt som funktioner, der kun er forbeholdt applikationsservere.

Applikationsserveren

Med hensyn til applikationsserveren udsætter en applikationsserver ifølge vores definition forretningslogik til klientapplikationer gennem forskellige protokoller, muligvis inklusive HTTP. Mens en webserver hovedsageligt beskæftiger sig med at sende HTML til visning i en webbrowser, giver en applikationsserver adgang til forretningslogik til brug af klientapplikationsprogrammer. Applikationsprogrammet kan bruge denne logik, ligesom det ville kalde en metode på et objekt (eller en funktion i den processuelle verden).

Sådanne applikationsserverklienter kan omfatte GUI'er (grafisk brugergrænseflade), der kører på en pc, en webserver eller endda andre applikationsservere. Oplysningerne, der bevæger sig frem og tilbage mellem en applikationsserver og dens klient, er ikke begrænset til simpel skærmopmærkning. I stedet er oplysningerne programlogik. Da logikken tager form af data- og metodeopkald og ikke statisk HTML, kan klienten anvende den udsatte forretningslogik, uanset hvordan den vil.

I de fleste tilfælde udsætter serveren denne forretningslogik gennem en komponent-API, såsom komponentmodellen EJB (Enterprise JavaBean), der findes på J2EE (Java 2 Platform, Enterprise Edition) applikationsservere. Desuden administrerer applikationsserveren sine egne ressourcer. Sådanne portopbevaringsopgaver inkluderer sikkerhed, transaktionsbehandling, ressourcepooling og messaging. Ligesom en webserver kan en applikationsserver muligvis også anvende forskellige teknikker til skalerbarhed og fejltolerance.

Et eksempel

Som et eksempel kan du overveje en onlinebutik, der giver information om priser og tilgængelighed i realtid. Mest sandsynligt vil webstedet give en formular, som du kan vælge et produkt med. Når du sender din forespørgsel, udfører webstedet et opslag og returnerer resultaterne integreret i en HTML-side. Webstedet kan implementere denne funktionalitet på adskillige måder. Jeg viser dig et scenario, der ikke bruger en applikationsserver, og et andet der gør det. At se, hvordan disse scenarier adskiller sig, hjælper dig med at se applikationsservers funktion.

Scenarie 1: Webserver uden applikationsserver

I det første scenarie leverer en webserver alene onlinebutikkens funktionalitet. Webserveren tager din anmodning og sender den derefter til et server-side-program, der er i stand til at håndtere anmodningen. Programmet på serversiden ser priseroplysningerne op fra en database eller en flad fil. Når programmet er hentet, bruger serversiden oplysningerne til at formulere HTML-svaret, og derefter sender webserveren det tilbage til din webbrowser.

For at opsummere behandler en webserver simpelthen HTTP-anmodninger ved at svare med HTML-sider.

Scenarie 2: Webserver med en applikationsserver

Scenarie 2 ligner Scenario 1, idet webserveren stadig delegerer svargenerering til et script. Du kan dog nu placere forretningslogikken til prisopslag på en applikationsserver. Med denne ændring kan scriptet simpelthen ringe til applikationsserverens opslagstjeneste i stedet for, at scriptet ved, hvordan man slår dataene op og formulerer et svar. Scriptet kan derefter bruge tjenestens resultat, når scriptet genererer sit HTML-svar.

I dette scenarie betjener applikationsserveren forretningslogikken for at finde et produkts prisoplysninger. Denne funktionalitet siger ikke noget om visning eller hvordan klienten skal bruge oplysningerne. I stedet sender klienten og applikationsserveren data frem og tilbage. Når en klient ringer til applikationsservers opslagstjeneste, ser tjenesten simpelthen oplysningerne op og returnerer dem til klienten.

Ved at adskille prislogikken fra HTML-responsgenererende kode bliver prislogikken langt mere genanvendelig mellem applikationer. En anden klient, såsom et kasseapparat, kunne også ringe til den samme service, som en ekspedient tjekker en kunde. I modsætning hertil kan prisopslagstjenesten i Scenario 1 ikke genbruges, fordi informationen er indlejret i HTML-siden. For at opsummere, i Scenario 2's model, håndterer webserveren HTTP-anmodninger ved at svare med en HTML-side, mens applikationsserveren serverer applikationslogik ved at behandle pris- og tilgængelighedsanmodninger.

Advarsler

For nylig har XML-webtjenester sløret grænsen mellem applikationsservere og webservere. Ved at overføre en XML-nyttelast til en webserver kan webserveren nu behandle dataene og svare meget, som applikationsservere tidligere har gjort.

Derudover indeholder de fleste applikationsservere også en webserver, hvilket betyder, at du kan betragte en webserver som et undersæt af en applikationsserver. Mens applikationsservere indeholder webserverfunktionalitet, implementerer udviklere sjældent applikationsservere i den kapacitet. I stedet, når det er nødvendigt, implementerer de ofte enkeltstående webservere sammen med applikationsservere. En sådan adskillelse af funktionalitet hjælper med ydeevne (enkle webanmodninger påvirker ikke applikationsserverens ydeevne), implementeringskonfiguration (dedikerede webservere, klynger osv.) Og giver mulighed for bedst udvalgt produktvalg.

Tony Sintes er en uafhængig konsulent og grundlægger af First Class Consulting, et konsulentfirma, der har specialiseret sig i at bygge bro over forskellige virksomhedssystemer og træning. Uden for førsteklasses rådgivning er Tony en aktiv freelance skribent samt forfatter af Sams Teach Yourself Object-Oriented Programming in 21 Days (Sams, 2001; ISBN: 0672321092).

Lær mere om dette emne

For flere artikler om applikationsservere, gennemse Java-applikationsservere sektion af JavaWorld 's Aktuelt indeks
//www.javaworld.com/channel_content/jw-appserv-index.shtml
Ønsker mere? Se Java Q&A indeksside for det fulde Q & A-katalog
//www.javaworld.com/column/jw-qna-index.shtml
For mere end 100 indsigtsfulde Java-tip fra nogle af de bedste sind i branchen, besøg JavaWorld 's Java-tip indeksside
//www.javaworld.com/column/jw-tips-index.shtml
Lær mere om applikationsskærere og webservere i vores Enterprise Java diskussion
//forums.idg.net/webx?50@@.ee6b80a
Tilmeld dig JavaWorlder gratis ugentligt Enterprise Java e-mail-nyhedsbrev
//www.javaworld.com/subscribe
Du finder et væld af it-relaterede artikler fra vores søsterpublikationer på .net