Quelle est la différence entre le serveur d'applications et le serveur Web?

Quelle est la différence entre le serveur d'applications et le serveur Web?

La plupart du temps, ces termes serveur Web et serveur d'applications sont interchangeables.

Voici quelques-unes des principales différences de fonctionnalités de Web Server et Application Server:

• Le serveur Web est conçu pour servir du contenu HTTP. App Server peut également servir du contenu HTTP mais ne se limite pas à HTTP. Il peut être fourni un autre support de protocole tel que RMI / RPC
• Le serveur Web est principalement conçu pour servir du contenu statique, bien que la plupart des serveurs Web aient des plugins pour prendre en charge des langages de script comme Perl, PHP, ASP, JSP, etc. à travers lesquels ces serveurs peuvent générer du contenu HTTP dynamique.
• La plupart des serveurs d'applications ont Web Server comme partie intégrante, ce qui signifie que App Server peut faire tout ce dont le serveur Web est capable. De plus, App Server possède des composants et des fonctionnalités pour prendre en charge les services de niveau application tels que le pool de connexions, le pool d'objets, le support des transactions, les services de messagerie, etc.
• Les serveurs Web étant bien adaptés au contenu statique et les serveurs d'applications au contenu dynamique, la plupart des environnements de production ont un serveur Web agissant comme proxy inverse du serveur d'applications. Cela signifie que lors du traitement d'une demande de page, les contenus statiques (tels que les images / HTML statique) sont servis par le serveur Web qui interprète la demande. En utilisant une sorte de technique de filtrage (principalement l'extension de la ressource demandée), le serveur Web identifie la demande de contenu dynamique et la transmet de manière transparente au serveur d'application

Un exemple d'une telle configuration est Apache Tomcat HTTP Server et Oracle (anciennement BEA) WebLogic Server. Apache Tomcat HTTP Server est Web Server et Oracle WebLogic est Application Server.

Dans certains cas, les serveurs sont étroitement intégrés tels que IIS et .NET Runtime. IIS est un serveur Web. Lorsqu'il est équipé d'un environnement d'exécution .NET, IIS est capable de fournir des services d'application.

Ceci est une réponse détaillée avec quelques scénarios pour comprendre clairement la différence, la similitude et comment les deux peuvent fonctionner conjointement et tous

Serveur d'applications est un terme qui est parfois mélangé avec un serveur Web . Alors qu'un serveur Web gère principalement des protocoles HTTP , le serveur d'applications gère plusieurs protocoles différents, y compris, mais sans s'y limiter, HTTP .

La tâche principale du serveur Web est d' afficher le contenu du site et le serveur d'applications est en charge de la logique , de l'interaction entre l'utilisateur et le contenu affiché. Le serveur d'applications fonctionne en collaboration avec le serveur Web, où l'un s'affiche et l'autre interagit.

Les informations qui circulent entre le serveur et son client ne se limitent pas à un simple balisage d'affichage, mais à l'interaction entre les deux.

Dans la plupart des cas, le serveur crée cette interaction via une API de composant , telle que J2EE (plate-forme Java 2) , EJB (Enterprise JavaBean) et d'autres modèles de logiciels d'application différents.

Un exemple:

La meilleure façon de comprendre la différence entre les scénarios où un serveur d'applications fonctionne avec le serveur Web et un scénario où il n'y a pas de serveur d'applications est via une boutique en ligne.

Scénario 1: serveur Web sans serveur d'applications

vous avez une boutique en ligne avec uniquement un serveur Web et aucun serveur d'applications. Le site fournira un affichage où vous pourrez choisir un produit. Lorsque vous soumettez une requête, le site effectue une recherche et renvoie un résultat HTML à son client. Le serveur Web envoie votre requête directement au serveur de base de données (soyez patient, je vais vous expliquer celui-ci dans notre prochain nugget) et attend une réponse. Une fois reçue, le serveur Web formule la réponse dans un fichier HTML et l'envoie à votre navigateur Web. Cette communication aller-retour entre le serveur et le serveur de base de données se produit chaque fois qu'une requête est exécutée.

Scénario 2: serveur Web avec un serveur d'applications

si la requête que vous souhaitez exécuter a déjà été effectuée précédemment et qu'aucune donnée n'a changé depuis lors, le serveur générera les résultats sans avoir à envoyer la demande au serveur de base de données. Cela permet une requête en temps réel où un deuxième client peut accéder aux mêmes informations et recevoir des informations fiables en temps réel sans envoyer une autre requête en double au serveur de base de données. Le serveur agit essentiellement comme un intermédiaire entre le serveur de base de données et le serveur Web. Cela permet aux informations extraites d'être réutilisables dans le premier scénario, car ces informations sont intégrées dans une page HTML particulière et "personnalisée", ce n'est pas un processus réutilisable. Un deuxième client devra demander à nouveau les informations et recevoir une autre page HTML intégrée avec les informations demandées - très inefficace.

Pour prendre en charge une telle variété de tâches complexes, ce serveur doit disposer d'une redondance intégrée, d'une grande puissance de traitement et d'une grande quantité de RAM pour gérer toutes les données qu'il extrait en temps réel.

J'espère que cela t'aides.

Les deux termes sont très génériques, l'un contenant l'autre et vice versa dans certains cas.

• Serveur Web : sert le contenu au Web en utilisant le protocole http.

• Serveur d'applications : héberge et expose la logique et les processus métier.

Je pense que le point principal est que le serveur Web expose tout via le protocole http, tandis que le serveur d'applications ne s'y limite pas.

Cela dit, dans de nombreux scénarios, vous constaterez que le serveur Web est utilisé pour créer le serveur frontal du serveur d'applications, c'est-à-dire qu'il expose un ensemble de pages Web qui permettent à l'utilisateur d'interagir avec les règles métier trouvées dans le serveur d'application.

serveur Web

Exécutez python -m 'SimpleHTTPServer'et accédez à http: // localhost: 8080 . Ce que vous voyez, c'est un serveur Web à son fonctionnement. Le serveur sert simplement des fichiers via HTTP stockés sur votre ordinateur. Le point clé est que tout cela se fait en plus du protocole HTTP. Il existe également des serveurs FTP par exemple qui font exactement la même chose (servir des fichiers stockés) mais en plus d'un protocole différent.

Serveur d'application

Disons que nous avons une petite application comme ci-dessous (extrait de Flask ).

@app.route('/')
def homepage():
    return '<html>My homepage</html>'

@app.route('/about')
def about():
    return '<html>My name is John</html>'

Le petit programme d'exemple mappe l'URL /à la fonction homepage()et la /aboutà la fonction about().

Pour exécuter ce code, nous avons besoin d'un serveur d'applications (par exemple Gunicorn) - un programme ou un module qui peut écouter les demandes d'un client et en utilisant notre code, renvoyer quelque chose de manière dynamique. Dans l'exemple, nous renvoyons simplement du très mauvais HTML.

Quelle est la logique métier dont parlent toutes les autres personnes? Eh bien, comme une URL correspond à un endroit spécifique de notre base de code, nous montrons hypothétiquement une certaine logique sur le fonctionnement de notre programme.

Récapitulation

serveur Web - sert des fichiers stockés quelque part (le plus souvent .css, .html, .js). Les serveurs Web courants sont Apache, Nginx ou même SimpleHTTPServer de Python.

serveur d'applications - sert les fichiers générés à la volée. Essentiellement, la plupart des serveurs Web ont une sorte de plugins ou même viennent avec des fonctionnalités intégrées pour le faire. Il existe également des serveurs d'applications stricts comme Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.

Notez que vous pouvez réellement créer un serveur Web avec le code du serveur d'applications. Cela se fait dans certains cas pendant le développement où vous ne voulez pas qu'un million de serveurs différents s'exécutent sur votre ordinateur.

Comme l'ont souligné Rutesh et jmservera, la distinction est floue. Historiquement, ils étaient différents, mais au cours des années 90, ces deux catégories auparavant distinctes ont mélangé des fonctionnalités et ont effectivement fusionné. À ce stade, il est probablement préférable d'imaginer que la catégorie de produit «App Server» est un sur-ensemble strict de la catégorie «serveur Web».

Un peu d'histoire. Au début du navigateur Mosaic et du contenu hyperlien, il a évolué ce qu'on appelle un "serveur Web" qui servait le contenu et les images des pages Web via HTTP. La plupart du contenu était statique et le protocole HTTP 1.0 n'était qu'un moyen de transporter des fichiers. Rapidement, la catégorie «serveur Web» a évolué pour inclure la capacité CGI - en lançant efficacement un processus sur chaque demande Web pour générer du contenu dynamique. HTTP a également évolué et les produits sont devenus plus sophistiqués, avec des fonctionnalités de mise en cache, de sécurité et de gestion. Au fur et à mesure que la technologie évoluait, nous avons obtenu la technologie côté serveur spécifique à l'entreprise de Kiva et NetDynamics, qui a finalement toutes fusionné dans JSP. Microsoft a ajouté ASP, je pense en 1996, à Windows NT 4.0. Le serveur Web statique a appris de nouvelles astuces, ce qui en fait un outil efficace "

Dans une catégorie parallèle, le serveur d'applications avait évolué et existait depuis longtemps. des sociétés ont livré des produits pour Unix comme Tuxedo, TopEnd, Encina qui étaient philosophiquement dérivés des environnements de gestion et de surveillance des applications mainframe comme IMS et CICS. L'offre de Microsoft était Microsoft Transaction Server (MTS), qui est devenu plus tard COM +. La plupart de ces produits spécifiaient des protocoles de communication spécifiques "fermés" pour interconnecter les "gros" clients aux serveurs. (Pour Encina, le protocole de communication était DCE RPC; pour MTS c'était DCOM; etc.) En 1995/96, ces produits de serveurs d'applications traditionnels ont commencé à intégrer des capacités de communication HTTP de base, d'abord via des passerelles. Et les lignes ont commencé à s'estomper.

Les serveurs Web sont devenus de plus en plus matures en ce qui concerne la gestion de charges plus élevées, plus de simultanéité et de meilleures fonctionnalités. Les serveurs d'applications offrent de plus en plus de capacités de communication basées sur HTTP.

À ce stade, la ligne entre «serveur d'application» et «serveur Web» est floue. Mais les gens continuent d'utiliser les termes différemment, comme une question d'accent. Lorsque quelqu'un dit «serveur Web», vous pensez souvent aux applications orientées HTTP et interface utilisateur Web. Quand quelqu'un dit "serveur d'application", vous pouvez penser "charges plus lourdes, fonctionnalités d'entreprise, transactions et files d'attente, communication multicanal (HTTP + plus). Mais souvent, c'est le même produit qui répond aux deux ensembles d'exigences de charge de travail.

• WebSphere, le "serveur d'applications" d'IBM, possède son propre serveur Web intégré.
• WebLogic, un autre serveur d'applications traditionnel, également.
• Windows, qui est le serveur d'applications de Microsoft (en plus d'être son serveur de fichiers et d'impression, le serveur multimédia, etc.), regroupe IIS.

Comme beaucoup l'ont dit auparavant, les serveurs Web traitent les pétitions HTTP, tandis que les serveurs d'applications traitent les pétitions pour les composants distribués. Donc, peut-être que la façon la plus simple de comprendre la différence est de comparer les deux produits en ce qui concerne l'environnement de programmation qu'ils proposent.

Serveur Web -> Environnement de programmation

IIS: ASP (.NET)

Tomcat: Servlet

Jetée: Servlet

Apache: Php, CGI

Serveurs d'applications -> Environnement de programmation

MTS: COM +

ÉTAIT: EJB

JBoss: EJB

Serveur d'applications WebLogic: EJB

La différence cruciale est que les serveurs d'applications prennent en charge certaines technologies de composants distribués , fournissant des fonctionnalités telles que l'invocation à distance et les transactions distribuées, comme EJB dans le monde Java ou COM + sur la plate-forme Microsoft. Le serveur HTTP prend souvent en charge des environnements de programmation plus simples, souvent des scripts, comme ASP (.NET) dans le cas de Microsoft ou basé sur Servlet, y compris JSP et bien d'autres dans le cas de Java ou PHP et CGI dans le cas d'Apache.

D'autres capacités telles que l'équilibrage de charge, la mise en cluster, le basculement de session, le pool de connexions, etc., qui étaient auparavant du domaine des serveurs d'applications, deviennent également disponibles sur les serveurs Web directement ou via certains produits tiers.

Enfin, il convient de noter que l'image est encore plus déformée avec des "conteneurs légers" comme Spring Framework, qui complètent souvent l'objectif des serveurs d'applications de manière plus simple et sans l'infrastructure du serveur d'applications. Et puisque l'aspect distribution dans les applications passe du composant distribué au paradigme de service et à l'architecture SOA, il reste de moins en moins d'espace pour les serveurs d'applications traditionnels.

La principale différence entre le serveur Web et le serveur d'applications est que le serveur Web est destiné à servir des pages statiques, par exemple HTML et CSS, tandis que le serveur d'applications est responsable de la génération de contenu dynamique en exécutant du code côté serveur, par exemple JSP, Servlet ou EJB.

Lequel devrais-je utiliser?
Une fois que vous connaissez la différence entre le serveur Web et le serveur d'applications et les conteneurs Web, il est facile de déterminer quand les utiliser. Vous avez besoin d'un web serverHTTPD Apache similaire si vous diffusez des pages Web statiques. Si vous avez une application Java avec uniquement JSP et Servlet pour générer du contenu dynamique, vous avez besoin de web containersTomcat ou Jetty. Bien que, si vous avez une application Java EE utilisant EJB, une transaction distribuée, une messagerie et d'autres fonctionnalités sophistiquées, vous avez besoin d'un logiciel complet application servercomme JBoss, WebSphere ou WebLogic d'Oracle.

Le conteneur Web fait partie de Web Server et le serveur Web fait partie d'Application Server.

Le serveur Web est composé d'un conteneur Web, tandis que le serveur d'applications est composé d'un conteneur Web ainsi que d'un conteneur EJB.

En bref, un serveur Web est un serveur qui sert des pages Web aux utilisateurs via http. Un serveur d'applications est un serveur qui héberge la logique métier d'un système. Il héberge souvent à la fois des processus batch / longs et / ou des services d'interopérabilité non destinés à la consommation humaine (services REST / JSON, SOAP, RPC, etc.).

Un serveur Web gère exclusivement les requêtes HTTP / HTTPS. Il sert du contenu au Web à l'aide du protocole HTTP / HTTPS.

Un serveur d'applications sert la logique métier aux programmes d'application via un nombre illimité de protocoles, y compris éventuellement HTTP. Le programme d'application peut utiliser cette logique comme il appellerait une méthode sur un objet. Dans la plupart des cas, le serveur expose cette logique métier via une API de composant, telle que le modèle de composant EJB (Enterprise JavaBean) trouvé sur les serveurs d'applications Java EE (Java Platform, Enterprise Edition). Le point principal est que le serveur Web expose tout via le protocole http, tandis que le serveur d'applications ne s'y limite pas. Un serveur d'applications offre ainsi beaucoup plus de services qu'un serveur Web qui comprend généralement:

• Une API (propriétaire ou non)
• Équilibrage de charge, basculement ...
• Gestion du cycle de vie des objets
• Gestion de l'état (session)
• Gestion des ressources (par exemple pools de connexions à la base de données)

La plupart des serveurs d'applications ont Web Server comme partie intégrante, ce qui signifie que App Server peut faire tout ce dont le serveur Web est capable. De plus, App Server possède des composants et des fonctionnalités pour prendre en charge les services de niveau application tels que le pool de connexions, le pool d'objets, le support des transactions, les services de messagerie, etc.

Un serveur d'applications peut (mais pas toujours) s'exécuter sur un serveur Web pour exécuter la logique du programme, dont les résultats peuvent ensuite être fournis par le serveur Web. C'est un exemple de scénario de serveur Web / serveur d'applications. Un bon exemple dans le monde Microsoft est la relation Internet Information Server / SharePoint Server. IIS est un serveur Web; SharePoint est un serveur d'applications. SharePoint se trouve "au-dessus" d'IIS, exécute une logique spécifique et sert les résultats via IIS. Dans le monde Java, il existe un scénario similaire avec Apache et Tomcat, par exemple.

Les serveurs Web étant bien adaptés au contenu statique et les serveurs d'applications au contenu dynamique, la plupart des environnements de production ont un serveur Web agissant comme proxy inverse du serveur d'applications. Cela signifie que pendant le service d'une demande de page, le contenu statique tel que images / html statique est servi par le serveur Web qui interprète la demande. En utilisant une sorte de technique de filtrage (principalement l'extension de la ressource demandée), le serveur Web identifie la demande de contenu dynamique et la transmet de manière transparente au serveur d'application.

Un exemple d'une telle configuration est Apache HTTP Server et BEA WebLogic Server. Apache HTTP Server est Web Server et BEA WebLogic est Application Server. Dans certains cas, les serveurs sont étroitement intégrés tels que IIS et .NET Runtime. IIS est un serveur Web. lorsqu'il est équipé de l'environnement d'exécution .NET, IIS est capable de fournir des services d'application

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+

La frontière entre ces deux est de plus en plus mince.

Les serveurs d'applications exposent la logique métier aux clients. Cela signifie que les serveurs d'applications sont constitués d'un ensemble de méthodes (pas exclusivement cependant, peuvent même être un ordinateur en réseau permettant à beaucoup d'exécuter des logiciels dessus) pour exécuter la logique métier. Il affichera donc simplement les résultats souhaités, pas le contenu HTML. (similaire à un appel de méthode). Il n'est donc pas strictement basé sur HTTP.

Mais les serveurs Web transmettent le contenu HTML aux navigateurs Web (strictement basés sur HTTP). Les serveurs Web étaient capables de gérer uniquement les ressources Web statiques, mais l'émergence de scripts côté serveur a également permis aux serveurs Web de gérer le contenu dynamique. Où un serveur Web prend la demande et la dirige vers les scripts pertinents (PHP, JSP, scripts CGI, etc.) pour CRÉER du contenu HTML à envoyer au client. Une fois le contenu reçu, le serveur Web enverra la page HTML au client.

Cependant, de nos jours, ces deux serveurs sont utilisés ensemble. Où le serveur Web prend la demande, puis appelle un script pour créer le contenu HTML. Ensuite, le script appellera à nouveau un serveur d'applications LOGIC (par exemple, récupérer les détails de la transaction) pour remplir le contenu HTML.

Les deux serveurs sont donc utilisés efficacement.

Par conséquent ... Nous pouvons affirmer que de nos jours, dans la plupart des cas, les serveurs Web sont utilisés comme un sous-ensemble de serveurs d'applications. MAIS théâtralement ce n'est pas le cas.

J'ai lu de nombreux articles sur ce sujet et j'ai trouvé cet article très pratique.

Un serveur d'applications est généralement conçu et déployé pour faciliter des processus plus longs qui nécessiteront également davantage de ressources.

Un serveur Web est utilisé pour les courtes rafales qui ne nécessitent généralement pas beaucoup de ressources. Ceci est principalement destiné à faciliter le service de trafic Web.

En termes Java, il y en a un de plus: le conteneur Web (ou plus strictement, le conteneur de servlet). C'est, disons, entre le serveur Web et le serveur d'applications.

Un conteneur Web en termes Java est un serveur d'application qui essentiellement ne met en oeuvre la partie JSP / Servlet Java EE et manque de plusieurs parties de noyau de Java EE, comme support EJB. Un exemple est Apache Tomcat.

Un serveur d'applications est une machine (un processus exécutable s'exécutant sur une machine, en fait) qui "écoute" (sur n'importe quel canal, en utilisant n'importe quel protocole), les demandes des clients pour tout service qu'il fournit, puis fait quelque chose en fonction de ces demandes. (peut ou non impliquer une réponse au client)

Un serveur Web est un processus exécuté sur une machine qui "écoute" spécifiquement sur le canal TCP / IP en utilisant l'un des protocoles "Internet" (http, https, ftp, etc.) et fait tout ce qu'il fait en fonction de ces demandes entrantes. .. Généralement, (tel que défini à l'origine), il récupérait / générait et renvoyait une page Web HTML au client, soit récupérée à partir d'un fichier HTML statique sur le serveur, soit construite dynamiquement en fonction des paramètres de la demande entrante du client.

Un serveur Web exécute le protocole HTTP pour servir des pages Web. Un serveur d'applications peut (mais pas toujours) s'exécuter sur un serveur Web pour exécuter la logique du programme, dont les résultats peuvent ensuite être fournis par le serveur Web. C'est un exemple de scénario de serveur Web / serveur d'applications.

Un bon exemple dans le monde Microsoft est la relation Internet Information Server / SharePoint Server. IIS est un serveur Web; SharePoint est un serveur d'applications. SharePoint se trouve "au-dessus" d'IIS, exécute une logique spécifique et sert les résultats via IIS.

Dans le monde Java, il existe un scénario similaire avec Apache et Tomcat, par exemple.

D'une part, un serveur Web sert du contenu Web (HTML et contenu statique) via le protocole HTTP. D'un autre côté, un serveur d'applications est un conteneur sur lequel vous pouvez créer et exposer la logique métier et les processus aux applications clientes via divers protocoles, y compris HTTP dans une architecture à n niveaux.

Un serveur d'applications offre ainsi beaucoup plus de services qu'un serveur Web qui comprend généralement:

• Une API (propriétaire ou non)
• Gestion du cycle de vie des objets,
• Gestion de l'Etat (session),
• Gestion des ressources (par exemple pools de connexion à la base de données),
• Équilibrage de charge, basculement ...

AFAIK, ATG Dynamo a été l'un des tout premiers serveurs d'applications à la fin des années 90 (selon la définition ci-dessus). Début 2000, c'était le règne de certains serveurs d'applications propriétaires comme ColdFusion (CFML AS), BroadVision (Server-side JavaScript AS), etc. Mais aucun n'a vraiment survécu à l'ère des serveurs d'applications Java.

Compréhension de base :

Dans l'architecture client-serveur

Serveur:> Qui sert les requêtes.

Client:> Qui consomme du service.

Le serveur Web et le serveur d'applications sont des applications logicielles qui servent de serveurs à leurs clients.

Ils ont obtenu leurs noms en fonction de leur lieu d'utilisation.

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.

Utilisation -

      we require low processing rates,

      regular processing practices involves.

Par exemple: Tous les serveurs plats généralement disponibles prêts à l'emploi qui ne servent que du contenu 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.

Utilisation -

      we require multi point processing,

      specialized processing techniques involves like for AI.

Par exemple: serveurs Google Maps, serveurs de recherche Google, serveurs Google Documents, serveurs Microsoft 365, serveurs de vision par ordinateur Microsoft pour l'IA.

Nous pouvons les assumer comme des niveaux / hiérarchies dans une architecture à 4 niveaux / n niveaux.

 So they can provide 
                    load balancing,
                    multiple security levels,
                    multiple active points,
                    even they can provide different request processing environments.

Veuillez suivre ce lien pour les analogies d'architecture standard:

https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)

La plus grande différence est qu'un serveur Web gère les requêtes HTTP, tandis qu'un serveur d'applications exécute la logique métier sur un nombre quelconque de protocoles.

En fait, Apache est un serveur Web et Tomcat est un serveur d'applications. Quand une requête HTTP arrive sur le serveur Web. Ensuite, le contenu statique est renvoyé au navigateur par le serveur Web. Y a-t-il une logique à faire, puis cette demande est envoyée au serveur d'applications. après le traitement de la logique, la réponse est envoyée au serveur Web et envoyée au client.

Tout ce qui précède complique simplement quelque chose de très simple. Un serveur d'applications contient un serveur Web, un serveur d'applications n'a que quelques ajouts / extensions supplémentaires par rapport aux serveurs Web standard. Si vous regardez TomEE comme exemple:

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

Vous verrez que Tomcat (conteneur / serveur Web) n'est qu'un autre outil de l'arsenal des serveurs d'applications. Vous pouvez également obtenir JPA et les autres technologies sur le serveur Web si vous le souhaitez, mais les serveurs d'applications emballent tout cela pour votre commodité. Pour être entièrement classé comme serveur d'applications, vous devez essentiellement vous conformer à une liste d'outils établie par une norme.

Il n'y a pas nécessairement de ligne de démarcation claire. De nos jours, de nombreux programmes combinent des éléments des deux - servir les requêtes http (serveur Web) et gérer la logique métier (serveur d'application)

De https://en.wikipedia.org/wiki/Web_server

Un serveur Web est un système informatique qui traite les demandes via HTTP, le protocole réseau de base utilisé pour diffuser des informations sur le World Wide Web. Le terme peut faire référence à l'ensemble du système, ou spécifiquement au logiciel qui accepte et supervise les requêtes HTTP .

Depuis https://en.wikipedia.org/wiki/Application_server#Application_Server_definition

Un serveur d'applications s'exécute derrière un serveur Web (par exemple Apache ou Microsoft Internet Information Services (IIS)) et (presque toujours) devant une base de données SQL (par exemple PostgreSQL, MySQL ou Oracle).

Les applications Web sont des codes informatiques qui s'exécutent sur des serveurs d'applications et sont écrits dans la ou les langues prises en charge par le serveur d'applications et appellent les bibliothèques d'exécution et les composants proposés par le serveur d'applications .

Le serveur d'applications et le serveur Web sont tous deux utilisés pour héberger l'application Web. Le serveur Web traite le conteneur Web d'autre part, le serveur d'applications traite le conteneur Web ainsi que le conteneur EJB (Enterprise JavaBean) ou le conteneur COM + pour Microsoft dot Net.

Le serveur Web est conçu pour servir du contenu statique HTTP comme HTML, des images, etc. et pour le contenu dynamique, il a des plugins pour prendre en charge les langages de script comme Perl, PHP, ASP, JSP, etc. et il est limité au protocole HTTP. Les serveurs ci-dessous peuvent générer du contenu HTTP dynamique.

Environnement de programmation du serveur Web:

IIS: ASP (.NET)

Apache Tomcat: Servlet

Jetée: Servlet

Apache: Php, CGI

Le serveur d'applications peut faire tout ce que le serveur Web est capable et écoute à l'aide de n'importe quel protocole.App Server possède des composants et des fonctionnalités pour prendre en charge les services de niveau application tels que le pool de connexions, le pool d'objets, le support des transactions, les services de messagerie, etc.

Environnement de programmation d'Application Server:

MTS: COM +

ÉTAIT: EJB

JBoss: EJB

Serveur d'applications WebLogic: EJB

Bien qu'il puisse y avoir des chevauchements entre les deux (certains serveurs Web peuvent même être utilisés comme serveurs d'applications), la plus grande différence à mon humble avis est dans le modèle de traitement et la gestion de session:

Dans le modèle de traitement du serveur Web, l'accent est mis sur le traitement des demandes; la notion de "session" est à peu près virtuelle. C'est-à-dire que la "session" est simulée en transférant la représentation de l'état entre le client et le serveur (d'où REST) ​​et / ou en le sérialisant vers un stockage persistant externe (SQL Server, Memcached etc).

Dans le serveur d'applications, la session est généralement plus explicite et prend souvent la forme d'un objet vivant dans la mémoire du serveur d'applications pendant toute la durée de la "session".

Cela dépend de l'architecture spécifique. Certains serveurs d'applications peuvent utiliser nativement les protocoles Web (XML / RPC / SOAP sur HTTP), il n'y a donc pas de différence technique importante. Généralement, un serveur Web est accessible à l'utilisateur, servant une variété de contenu via HTTP / HTTPS, tandis qu'un serveur d'applications n'est pas accessible à l'utilisateur et peut utiliser des protocoles non standard ou non routables. Bien sûr, avec RIA / AJAX, la différence pourrait être encore plus nuageuse, ne servant que du contenu non HTML (JSON / XML) aux clients qui pompent des services d'accès à distance particuliers.

OMI, il s'agit principalement de séparer les préoccupations.

D'un point de vue purement technique, vous pouvez tout faire (contenu web + logique métier) sur un seul serveur web. Si vous le faisiez, les informations seraient intégrées à l'intérieur du contenu HTML demandé. Quel serait l'impact?

Par exemple, imaginez que vous avez 2 applications différentes qui rendent le contenu HTML entièrement différent sur le navigateur. Si vous souhaitez séparer la logique métier en un serveur d'applications, vous pouvez fournir différents serveurs Web recherchant les mêmes données dans le serveur d'applications via des scripts. Cependant, si vous ne séparez pas la logique et ne la conservez pas sur le serveur Web, chaque fois que vous modifiez votre modèle commercial, vous finirez par le changer dans chaque serveur Web que vous possédez, ce qui prendrait plus de temps, serait moins fiable et sujette aux erreurs.

• serveur web: pour chaque URL, il renvoie un fichier. C'est tout. Le fichier est un contenu statique , ce qui signifie qu'il est stocké quelque part sur le serveur, avant de faire votre demande
• serveur d'applications: pour chaque URL, il exécute du code écrit dans une langue , génère une réponse et la renvoie. La réponse n'existe pas à l'avance, elle est générée pour votre demande particulière .

Presque toutes les pages que vous visitez utilisent les deux. Le contenu statique (par exemple, des images, des vidéos) est servi par le serveur Web, et le reste (les parties qui sont différentes entre vous et les autres utilisateurs) sont générés par le serveur d'applications.