Qual è la differenza tra application server e web server?
Risposte:
Il più delle volte questi termini Web Server e Application Server sono usati in modo intercambiabile.
Di seguito sono riportate alcune delle principali differenze nelle funzionalità di Web Server e Application Server:
Esempio di tale configurazione è Apache Tomcat HTTP Server e Oracle (precedentemente BEA) WebLogic Server. Apache Tomcat HTTP Server è Web Server e Oracle WebLogic è Application Server.
In alcuni casi i server sono strettamente integrati come IIS e .NET Runtime. IIS è un server web. Se dotato di ambiente di runtime .NET, IIS è in grado di fornire servizi applicativi.
Questa è una risposta dettagliata con alcuni scenari per comprendere chiaramente la differenza, la somiglianza e come entrambi possono funzionare congiuntamente e tutti
Server applicazioni è un termine che talvolta viene mischiato a un server Web . Mentre un server Web gestisce principalmente i protocolli HTTP , il server delle applicazioni si occupa di diversi protocolli, incluso, ma non limitato a HTTP .
Il compito principale del server Web è quello di visualizzare il contenuto del sito e il server delle applicazioni è responsabile della logica , dell'interazione tra l'utente e il contenuto visualizzato. Il server delle applicazioni funziona in combinazione con il server Web, dove uno visualizza e l'altro interagisce.
Le informazioni che viaggiano avanti e indietro tra il server e il suo client non si limitano al semplice markup di visualizzazione, ma all'interazione tra i due.
Nella maggior parte dei casi, il server crea questa interazione attraverso un'API componente , come J2EE (Java 2 Platform) , EJB (Enterprise JavaBean) e altri diversi modelli di software applicativo.
Un esempio:
Il modo migliore per comprendere la differenza tra gli scenari in cui un server delle applicazioni funziona con il server Web rispetto a uno scenario in cui non esiste un server delle applicazioni è tramite un negozio online.
Scenario 1: server Web senza un server applicazioni
hai un negozio online con solo un server web e nessun server applicazioni. Il sito fornirà un display da cui è possibile scegliere un prodotto. Quando si invia una query, il sito esegue una ricerca e restituisce un risultato HTML al suo client. Il web server invia la tua richiesta direttamente al server di database (sii paziente, lo spiegherò nel prossimo nugget) e attende una risposta. Una volta ricevuto, il server Web formula la risposta in un file HTML e lo invia al browser Web. Questa comunicazione avanti e indietro tra il server e il server di database avviene ogni volta che viene eseguita una query.
Scenario 2: server Web con un server applicazioni
se la query che si desidera eseguire è già stata eseguita in precedenza e nessun dato è cambiato da allora, il server genererà i risultati senza dover inviare la richiesta al server del database. Ciò consente una query in tempo reale in cui un secondo client può accedere alle stesse informazioni e ricevere informazioni affidabili in tempo reale senza inviare un'altra query duplicata al server di database. Il server funge essenzialmente da intermedio tra il server database e il web server. Ciò consente alle informazioni estratte di essere riutilizzabili nel primo scenario, poiché queste informazioni sono incorporate in una pagina HTML particolare e "personalizzata", questo non è un processo riutilizzabile. Un secondo client dovrà richiedere nuovamente le informazioni e ricevere un'altra pagina HTML incorporata con le informazioni richieste altamente elevate.
Per supportare una tale varietà di attività complesse, questo server deve avere una ridondanza integrata, una grande potenza di elaborazione e un'elevata quantità di RAM per gestire tutti i dati che sta estraendo in tempo reale.
Spero che sia di aiuto.
the application server deals with several different protocols, including, but not limited, to HTTP<- che dice che gestisce sicuramente le richieste http - non è accurato.
Entrambi i termini sono molto generici, uno contenente l'altro e viceversa in alcuni casi.
Server Web : fornisce contenuti al Web utilizzando il protocollo http.
Server applicazioni : ospita ed espone logiche e processi aziendali.
Penso che il punto principale sia che il server Web esponga tutto attraverso il protocollo http, mentre il server delle applicazioni non è limitato ad esso.
Detto questo, in molti scenari scoprirai che il web server viene utilizzato per creare il front-end del server delle applicazioni, ovvero espone una serie di pagine Web che consentono all'utente di interagire con le regole aziendali presenti nel server delle applicazioni.
server web
Esegui python -m 'SimpleHTTPServer'e vai a http: // localhost: 8080 . Quello che vedi è un web server al suo funzionamento. Il server serve semplicemente file su HTTP memorizzati sul tuo computer. Il punto chiave è che tutto ciò viene fatto in cima al protocollo HTTP. Esistono anche server FTP, ad esempio, che fanno esattamente la stessa cosa (servono file memorizzati) ma su un protocollo diverso.
Server delle applicazioni
Supponiamo di avere una piccola applicazione come quella di seguito (frammento di Flask ).
@app.route('/')
def homepage():
return '<html>My homepage</html>'
@app.route('/about')
def about():
return '<html>My name is John</html>'
Il programma di esempio di piccole dimensioni associa l'URL /alla funzione homepage()e /aboutalla funzione about().
Per eseguire questo codice abbiamo bisogno di un server delle applicazioni (ad es. Gunicorn) - un programma o un modulo che può ascoltare le richieste di un client e usare il nostro codice, restituire qualcosa in modo dinamico. Nell'esempio restituiamo semplicemente un pessimo HTML.
Qual è la logica aziendale di cui parlano tutti gli altri? Bene, poiché un URL è mappato da qualche parte in modo specifico nella nostra base di codice, stiamo ipoteticamente mostrando una logica su come funziona il nostro programma.
ricapitolando
web server - serve file memorizzati da qualche parte (più comunemente .css, .html, .js). I server Web comuni sono Apache, Nginx o anche SimpleHTTPServer di Python.
server applicazioni : serve file generati al volo. Fondamentalmente la maggior parte dei server Web ha una sorta di plugin o addirittura viene fornita con funzionalità integrate per farlo. Esistono anche server di applicazioni rigidi come Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), ecc.
Si noti che è possibile effettivamente creare un server Web con il codice del server delle applicazioni. Questo viene fatto in alcuni casi durante lo sviluppo in cui non si desidera avere un gazillion di server diversi in esecuzione sul computer.
Come hanno sottolineato Rutesh e jmservera, la distinzione è confusa. Storicamente, erano diversi, ma negli anni '90 queste due categorie precedentemente distinte mischiavano caratteristiche e si fondevano efficacemente. A questo punto è probabilmente meglio immaginare che la categoria di prodotti "App Server" sia un superset rigoroso della categoria "web server".
Un po 'di storia. Agli inizi del browser Mosaic e del contenuto con collegamento ipertestuale, si sviluppò questa cosa chiamata "web server" che serviva il contenuto della pagina Web e le immagini su HTTP. Gran parte del contenuto era statico e il protocollo HTTP 1.0 era solo un modo per spedire i file. La categoria "web server" si è evoluta rapidamente per includere la funzionalità CGI, avviando in modo efficace un processo su ogni richiesta Web per generare contenuto dinamico. Anche l'HTTP è maturato e i prodotti sono diventati più sofisticati, con funzionalità di cache, sicurezza e gestione. Con la maturazione della tecnologia, abbiamo ottenuto la tecnologia lato server basata su Java specifica per l'azienda da Kiva e NetDynamics, che alla fine si sono fuse tutte in JSP. Microsoft ha aggiunto ASP, credo nel 1996, a Windows NT 4.0. Il web server statico aveva appreso alcuni nuovi trucchi, in modo che fosse un efficace "
In una categoria parallela, il server delle app si era evoluto ed esisteva da molto tempo. le aziende fornivano prodotti per Unix come Tuxedo, TopEnd, Encina derivati filosoficamente da ambienti di gestione e monitoraggio delle applicazioni Mainframe come IMS e CICS. L'offerta di Microsoft era Microsoft Transaction Server (MTS), che in seguito si è evoluto in COM +. La maggior parte di questi prodotti specificava protocolli di comunicazione specifici "chiusi" per l'interconnessione di client "fat" con i server. (Per Encina, il protocollo di comunicazione era DCE RPC; per MTS era DCOM; ecc.) Nel 1995/96, questi prodotti per server di app tradizionali iniziarono a incorporare le funzionalità di comunicazione HTTP di base, inizialmente tramite gateway. E le linee hanno cominciato a confondersi.
I server Web sono diventati sempre più maturi rispetto alla gestione di carichi più elevati, maggiore concorrenza e funzionalità migliori. I server delle app offrono sempre più funzionalità di comunicazione basate su HTTP.
A questo punto la linea tra "app server" e "web server" è confusa. Ma le persone continuano a usare i termini in modo diverso, come una questione di enfasi. Quando qualcuno dice "web server", spesso pensi ad app orientate verso HTTP, UI web e orientate. Quando qualcuno dice "App server" potresti pensare "carichi più pesanti, funzionalità aziendali, transazioni e accodamento, comunicazione multicanale (HTTP + altro). Ma spesso è lo stesso prodotto che soddisfa entrambi i set di requisiti di carico di lavoro.
Come molti hanno già detto, i server Web gestiscono le petizioni HTTP, mentre i server delle applicazioni gestiscono le petizioni per i componenti distribuiti. Quindi, forse il modo più semplice per capire la differenza è confrontare i due prodotti per quanto riguarda l'ambiente di programmazione che offrono.
IIS: ASP (.NET)
Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
MTS: COM +
ERA: EJB
JBoss: EJB
WebLogic Application Server: EJB
La differenza cruciale è che i server delle applicazioni supportano alcune tecnologie dei componenti distribuiti , fornendo funzionalità come invocazione remota e transazioni distribuite, come EJB nel mondo Java o COM + su piattaforma Microsoft. I server HTTP spesso supportano alcuni ambienti di programmazione più semplici, spesso script, come ASP (.NET) in caso di Microsoft o basati su Servlet, incluso JSP e molti altri in caso di Java o PHP e CGI in caso di Apache.
Altre funzionalità come il bilanciamento del carico, il clustering, il failover delle sessioni, il pool di connessioni, ecc. Che erano nel regno dei server delle applicazioni, stanno diventando disponibili sui server Web direttamente o tramite alcuni prodotti di terze parti.
Infine, vale la pena notare che l'immagine è ulteriormente distorta con "contenitori leggeri" come Spring Framework, che spesso integrano lo scopo dei server delle applicazioni in modo più semplice e senza l'infrastruttura del server delle applicazioni. E poiché l'aspetto della distribuzione nelle applicazioni si sta spostando dal componente distribuito al paradigma del servizio e all'architettura SOA, rimane sempre meno spazio per i server delle applicazioni tradizionali.
La differenza principale tra il server Web e il server delle applicazioni è che il server Web è destinato a servire pagine statiche, ad esempio HTML e CSS, mentre Application Server è responsabile della generazione di contenuti dinamici eseguendo il codice lato server, ad esempio JSP, Servlet o EJB.
Quale dovrei usare?
Una volta che conosci la differenza tra web e application server e container web, è facile capire quando usarli. È necessario un web serverHTTPD Apache simile se si servono pagine Web statiche. Se hai un'applicazione Java con solo JSP e Servlet per generare contenuti dinamici, allora hai bisogno web containersdi Tomcat o Jetty. Mentre, se si dispone di un'applicazione Java EE che utilizza EJB, transazioni distribuite, messaggistica e altre funzionalità fantasiose, è necessario un vero e application serverproprio JBoss, WebSphere o Oracle WebLogic.
Il contenitore Web fa parte del server Web e il server Web fa parte del server delle applicazioni.
Il server Web è composto da un contenitore Web, mentre il server delle applicazioni è composto da un contenitore Web e da un contenitore EJB.
In breve, un server Web è un server che fornisce pagine Web agli utenti tramite http. Un server applicazioni è un server che ospita la logica aziendale per un sistema. Ospita spesso processi batch / long running e / o servizi di interoperabilità non destinati al consumo umano (servizi REST / JSON, SOAP, RPC, ecc.).
Un server Web gestisce esclusivamente le richieste HTTP / HTTPS. Fornisce contenuti al Web utilizzando il protocollo HTTP / HTTPS.
Un server delle applicazioni serve la logica aziendale ai programmi applicativi attraverso un numero qualsiasi di protocolli, possibilmente incluso HTTP. Il programma applicativo può usare questa logica proprio come chiamerebbe un metodo su un oggetto. Nella maggior parte dei casi, il server espone questa logica di business attraverso un'API componente, come il modello di componente EJB (Enterprise JavaBean) che si trova sui server delle applicazioni Java EE (Java Platform, Enterprise Edition). Il punto principale è che il server Web espone tutto attraverso il protocollo http, mentre il server delle applicazioni non è limitato ad esso. Un application server offre quindi molti più servizi di un web server che generalmente include:
La maggior parte dei server delle applicazioni ha Web Server come parte integrante di essi, ciò significa che App Server può fare tutto ciò che è in grado di fare. Inoltre App Server ha componenti e funzionalità per supportare servizi a livello di applicazione come Pool di connessioni, Pool di oggetti, Supporto per le transazioni, Servizi di messaggistica ecc.
Un server delle applicazioni può (ma non sempre) funzionare su un server Web per eseguire la logica del programma, i cui risultati possono essere consegnati dal server Web. Questo è un esempio di uno scenario di server Web / server applicazioni. Un buon esempio nel mondo Microsoft è la relazione Internet Information Server / SharePoint Server. IIS è un server Web; SharePoint è un server delle applicazioni. SharePoint si trova "in cima" a IIS, esegue una logica specifica e fornisce i risultati tramite IIS. Nel mondo Java, c'è uno scenario simile con Apache e Tomcat, per esempio.
Poiché i server Web sono adatti per contenuti statici e server di app per contenuti dinamici, la maggior parte degli ambienti di produzione ha un server Web che funge da proxy inverso per il server delle app. Ciò significa che durante il servizio di una richiesta di pagina, i contenuti statici come immagini / HTML statico vengono forniti dal server Web che interpreta la richiesta. Utilizzando un qualche tipo di tecnica di filtraggio (principalmente estensione della risorsa richiesta) il server Web identifica la richiesta di contenuto dinamico e inoltra in modo trasparente al server app.
Esempio di tale configurazione è Apache HTTP Server e BEA WebLogic Server. Apache HTTP Server è Web Server e BEA WebLogic è Application Server. In alcuni casi, i server sono strettamente integrati come IIS e .NET Runtime. IIS è un server web. se dotato di ambiente di runtime .NET, IIS è in grado di fornire servizi applicativi
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+
Il confine tra questi due sta diventando sempre più sottile.
I server delle applicazioni espongono la logica aziendale ai client. Ciò significa che i server delle applicazioni comprendono una serie di metodi (anche se non esclusivamente, possono anche essere un computer in rete che consente a molti di eseguire software su di esso) per eseguire la logica aziendale. Quindi genererà semplicemente i risultati desiderati, non il contenuto HTML. (simile a una chiamata di metodo). Quindi non è strettamente basato su HTTP.
Ma i server Web trasmettono contenuti HTML ai browser Web (rigorosamente basati su HTTP). I server Web erano in grado di gestire solo le risorse Web statiche, ma l'emergere di script sul lato server ha consentito anche ai server Web di gestire contenuti dinamici. Laddove un server Web accetta la richiesta e la indirizza a script pertinenti (PHP, JSP, script CGI, ecc.) Per CREARE contenuto HTML da inviare al client. Una volta ricevuto il contenuto, il server Web invierà la pagina HTML al client.
Tuttavia, al giorno d'oggi entrambi questi server sono usati insieme. Dove il server Web accetta la richiesta e quindi chiama uno script per creare il contenuto HTML. Quindi, lo script richiamerà nuovamente una LOGICA del server delle applicazioni (ad esempio Recupera dettagli transazione) per riempire il contenuto HTML.
Quindi entrambi i server sono usati in modo efficace.
Pertanto .... Possiamo tranquillamente affermare che oggigiorno, nella maggior parte dei casi, i server Web sono utilizzati come sottoinsieme di server applicazioni. MA teatralmente NON è così.
Ho letto molti articoli su questo argomento e ho trovato questo articolo abbastanza utile.
Un server applicazioni è in genere progettato e distribuito per facilitare processi più lunghi che richiederanno anche più risorse.
Un web server viene utilizzato per brevi scoppi che non richiedono molte risorse, in genere. Ciò è principalmente per facilitare la gestione del traffico web.
In termini Java, ce n'è ancora uno: container web (o più rigorosamente, container servlet). È, diciamo, tra web server e application server.
Un contenitore Web in termini Java è un server delle applicazioni che praticamente implementa solo la parte JSP / Servlet di Java EE e manca di diverse parti principali di Java EE, come il supporto EJB. Un esempio è Apache Tomcat.
Un server delle applicazioni è una macchina (in realtà un processo eseguibile in esecuzione su alcune macchine) che "ascolta" (su qualsiasi canale, utilizzando qualsiasi protocollo), per richieste da parte dei client per qualunque servizio fornisca, e quindi fa qualcosa in base a tali richieste. (può o meno implicare un rispetto per il cliente)
Un server Web è un processo in esecuzione su una macchina che "ascolta" in particolare sul canale TCP / IP utilizzando uno dei protocolli "Internet" (http, https, ftp, ecc.) E fa tutto ciò che fa in base a tali richieste in arrivo. .. In generale, (come definito originariamente), veniva recuperato / generato e restituito una pagina Web HTML al client, recuperata da un file HTML statico sul server o costruita dinamicamente in base ai parametri nella richiesta client in arrivo.
Un server Web esegue il protocollo HTTP per servire le pagine Web. Un server delle applicazioni può (ma non sempre) funzionare su un server Web per eseguire la logica del programma, i cui risultati possono quindi essere forniti dal server Web. Questo è un esempio di uno scenario di server Web / server applicazioni.
Un buon esempio nel mondo Microsoft è la relazione Internet Information Server / SharePoint Server. IIS è un server Web; SharePoint è un server delle applicazioni. SharePoint si trova "in cima" a IIS, esegue una logica specifica e fornisce i risultati tramite IIS.
Nel mondo Java, c'è uno scenario simile con Apache e Tomcat, per esempio.
Da un lato, un server Web serve contenuto Web (HTML e contenuto statico) tramite il protocollo HTTP. D'altro canto, un server delle applicazioni è un contenitore sul quale è possibile creare ed esporre la logica e i processi aziendali alle applicazioni client attraverso vari protocolli, incluso HTTP in un'architettura di livello n.
Un application server offre quindi molti più servizi di un web server che generalmente include:
AFAIK, ATG Dynamo è stato uno dei primissimi application server alla fine degli anni '90 (secondo la definizione sopra). All'inizio del 2000, era il regno di alcuni server applicativi proprietari come ColdFusion (CFML AS), BroadVision (JavaScript lato server AS), ecc. Ma nessuno è sopravvissuto all'era del server delle applicazioni Java.
Comprensione di base:
Nell'architettura del server client
Server:> Che serve le richieste.
Cliente:> Che consuma il servizio.
Il server Web e il server applicazioni sono entrambe applicazioni software che fungono da server per i loro client.
Hanno ottenuto i loro nomi in base al luogo di utilizzo.
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
Utilizzo -
we require low processing rates, regular processing practices involves.Ad esempio: tutti i server flat generalmente disponibili già pronti che servono solo contenuti basati sul web.
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
Utilizzo -
we require multi point processing, specialized processing techniques involves like for AI.Ad esempio: server di mappe di Google, server di ricerca di Google, server di documenti Google, server di Microsoft 365, server di computer vision di Microsoft per l'IA.
Possiamo assumerli come livelli / gerarchie nell'architettura a 4 livelli / n.
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
Seguire questo collegamento per analogie sull'architettura standard:
https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)
La differenza più grande è che un server Web gestisce le richieste HTTP, mentre un server applicazioni eseguirà la logica aziendale su un numero qualsiasi di protocolli.
In realtà Apache è un server Web e Tomcat è un server applicazioni. Quando come richiesta HTTP arriva al server web. Quindi i contenuti statici vengono rinviati al browser dal server Web. Esiste e la logica da fare, quindi quella richiesta viene inviata al server delle applicazioni. dopo aver elaborato la logica, quindi inviare la risposta al server Web e inviarla al client.
Tutto quanto sopra è semplicemente complicando troppo qualcosa di molto semplice. Un server applicazioni contiene un server Web, un server applicazioni ha solo un paio di aggiunte / estensioni in più rispetto ai server Web standard. Se guardi TomEE come esempio:
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal
Vedrai che Tomcat (contenitore / server Web) è solo un altro strumento nell'arsenale dei server delle app. Se lo desideri, puoi ottenere JPA e le altre tecnologie nel server Web, ma i server delle applicazioni impacchettano tutte queste cose per comodità. Per essere completamente classificato come server di app, è necessario essenzialmente rispettare un elenco di strumenti stabilito da alcuni standard.
Non esiste necessariamente una chiara linea di demarcazione. Al giorno d'oggi, molti programmi combinano elementi di entrambi: servire le richieste http (web server) e gestire la logica aziendale (app server)
Da https://en.wikipedia.org/wiki/Web_server
Un web server è un sistema informatico che elabora le richieste tramite HTTP, il protocollo di rete di base utilizzato per distribuire informazioni sul World Wide Web. Il termine può riferirsi all'intero sistema, o specificamente al software che accetta e supervisiona le richieste HTTP .
Da https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
Un server delle applicazioni viene eseguito dietro un server Web (ad es. Apache o Microsoft Internet Information Services (IIS)) e (quasi sempre) davanti a un database SQL (ad es. PostgreSQL, MySQL o Oracle).
Le applicazioni Web sono codici di computer che girano in cima ai server delle applicazioni e sono scritte nelle lingue supportate dal server delle applicazioni e chiamano le librerie e i componenti di runtime offerti dal server delle applicazioni .
Il server applicazioni e il server Web sono entrambi utilizzati per ospitare l'applicazione Web. D'altro canto, il server Web gestisce il contenitore Web, mentre il server delle applicazioni gestisce sia il contenitore Web sia il contenitore EJB (Enterprise JavaBean) o il contenitore COM + per Microsoft dot Net.
Web Server è progettato per servire contenuti statici HTTP come HTML, immagini ecc. E per i contenuti dinamici hanno plugin per supportare linguaggi di scripting come Perl, PHP, ASP, JSP ecc. Ed è limitato al protocollo HTTP. I server sottostanti possono generare contenuti HTTP dinamici.
Ambiente di programmazione del server Web:
IIS: ASP (.NET)
Apache Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
Application Server è in grado di fare qualunque cosa il Web Server sia in grado di ascoltare e ascolta qualsiasi protocollo, così come l'App Server ha componenti e funzionalità per supportare servizi a livello di applicazione come Pool di connessioni, Pool di oggetti, Supporto delle transazioni, Servizi di messaggistica ecc.
Ambiente di programmazione di Application Server:
MTS: COM +
ERA: EJB
JBoss: EJB
WebLogic Application Server: EJB
Sebbene possano esserci sovrapposizioni tra i due (alcuni server Web potrebbero persino essere utilizzati come server delle applicazioni), la differenza più grande tra IMHO è nel modello di elaborazione e la gestione della sessione:
Nel modello di elaborazione del server Web, l'attenzione è focalizzata sulla gestione delle richieste; la nozione di "sessione" è praticamente virtuale. Vale a dire che la "sessione" viene simulata trasferendo la rappresentazione dello stato tra client e server (quindi REST) e / o serializzandola su un archivio permanente esterno (SQL Server, Memcached ecc.).
Nel server delle applicazioni la sessione è generalmente più esplicita e spesso assume la forma di un oggetto che vive nella memoria del server delle applicazioni per l'intera durata della "sessione".
Dipende dall'architettura specifica. Alcuni server delle applicazioni possono utilizzare i protocolli Web in modo nativo (XML / RPC / SOAP su HTTP), quindi c'è poca differenza tecnica. In genere un server Web è rivolto all'utente, serve una varietà di contenuti su HTTP / HTTPS, mentre un server delle applicazioni non è rivolto all'utente e può utilizzare protocolli non standard o non instradabili. Naturalmente con RIA / AJAX, la differenza potrebbe essere ulteriormente annebbiata, offrendo solo contenuti non HTML (JSON / XML) ai client che pompano particolari servizi di accesso remoto.
IMO, si tratta principalmente di separare le preoccupazioni.
Da un punto di vista puramente tecnico, puoi fare tutto (contenuto web + logica aziendale) in un singolo server web. Se lo facessi, le informazioni verrebbero incorporate all'interno richiedendo il contenuto HTML. Quale sarebbe l'impatto?
Ad esempio, immagina di avere 2 app diverse che visualizzano contenuti HTML completamente diversi sul browser. Se dovessi separare la logica di business in un server di app di quanto potresti fornire server Web diversi cercando gli stessi dati nel server di app tramite script. Tuttavia, se non dovessi separare la logica e mantenerla nel web server, ogni volta che cambi il tuo modello di business, finiresti per cambiarla in ogni singolo web server che richiederebbe più tempo, essere meno affidabile e incline a errori.
Quasi ogni pagina che visiti utilizza entrambi. Il contenuto statico (ad es. Immagini, video) viene fornito dal server Web e il resto (le parti diverse tra l'utente e gli altri utenti) vengono generate dal server delle applicazioni.