Question 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?


523
2018-06-01 18:57


origine


Réponses:


La plupart du temps, ces termes Serveur Web et Serveur d'application sont utilisés de manière interchangeable.

Voici certaines des principales différences entre les fonctionnalités de Web Server et d'Application Server:

  • Le serveur Web est conçu pour diffuser 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
  • Web Server est principalement conçu pour servir du contenu statique, bien que la plupart des Web Servers aient des plugins pour prendre en charge les langages de script tels que Perl, PHP, ASP, JSP, etc. grâce auxquels ces serveurs peuvent générer du contenu HTTP dynamique.
  • La plupart des serveurs d'applications font partie intégrante du serveur Web, ce qui signifie que App Server peut faire tout ce que le serveur Web est capable de faire. En outre, App Server dispose de composants et de fonctionnalités pour prendre en charge les services de niveau Application tels que le regroupement de connexions, la mise en pool d'objets, la prise en charge de transactions, les services de messagerie, etc.
  • Comme les serveurs Web sont bien adaptés aux contenus statiques et aux serveurs d'applications pour le contenu dynamique, la plupart des environnements de production ont un serveur Web agissant en tant que proxy inverse du serveur d'applications. Cela signifie que tout en gérant 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 redirige de manière transparente vers le serveur de l'application.

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

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.


475
2018-06-01 19:10



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 sur le web en utilisant le protocole http.

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

Je pense que le point principal est que le serveur web expose tout à travers le protocole http, alors que le serveur d'application ne s'y limite pas.

Cela dit, dans de nombreux cas, 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 permettant à l'utilisateur d'interagir avec les règles métier trouvées dans le serveur. serveur d'application.


105
2018-06-01 19:30



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 en conjonction et tous

Serveur d'application est un terme qui est parfois mélangé avec un serveur Web. Alors qu'un serveur web gère principalement Protocoles HTTP, le serveur d'application traite plusieurs protocoles différents, y compris, mais pas limité, à HTTP.

Le travail principal du serveur Web consiste à afficher le contenu du site et le serveur d'application est en charge de la logique, l'interaction entre l'utilisateur et le contenu affiché. Le serveur d'application est travailler en conjonction avec le serveur web, où l'un affiche et l'autre interagit.

Les informations circulant entre le serveur et son client ne se limitent pas au simple balisage de l'affichage, mais à l'interaction entre les deux.

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

enter image description here

Un exemple:

Le meilleur moyen de comprendre la différence entre les scénarios dans lesquels un serveur d'applications fonctionne avec le serveur Web et celui dans lequel il n'y a pas de serveur d'applications consiste à utiliser un magasin en ligne.

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

vous avez un magasin en ligne avec seulement un serveur web et pas de serveur d'application. Le site fournira un affichage sur lequel 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 l'expliquer dans notre prochain nugget) et attend une réponse. Une fois reçu, le serveur Web formule la réponse dans un fichier HTML et l'envoie à votre navigateur Web. Cette communication 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 été modifiée depuis, le serveur générera les résultats sans avoir à envoyer la requête au serveur de base de données. Cela permet une requête en temps réel où un deuxième client peut accéder à la même information 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 de réutiliser les informations tirées dans le premier scénario, puisque 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 à nouveau demander l'info et recevoir une autre page HTML incorporée avec l'information demandée - très inefficace. Sans oublier que ce type de serveur est très flexible en raison de sa capacité à gérer ses propres ressources, y compris la sécurité, le traitement des transactions, la messagerie et la mise en commun des ressources.

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

J'espère que cela t'aides.


99
2018-06-07 13:17



Comme Rutesh et jmservera l'ont souligné, la distinction est floue. Historiquement, ils étaient différents, mais à travers les années 90, ces deux catégories auparavant distinctes ont fusionné des fonctionnalités et fusionné efficacement. À ce stade, il est probablement préférable d'imaginer que la catégorie de produits «App Server» est un surensemble strict de la catégorie «serveur Web».

Un peu d'histoire. Au tout début du navigateur et du contenu hypertexte de Mosaic, il y a eu ce qu'on appelle un «serveur Web» qui servait le contenu des pages Web et les images sur HTTP. La plupart du contenu était statique et le protocole HTTP 1.0 était juste un moyen d'expédier des fichiers. Rapidement, la catégorie «serveur Web» a évolué pour inclure la fonctionnalité CGI - en lançant efficacement un processus sur chaque requête Web pour générer du contenu dynamique. HTTP a également mûri et les produits sont devenus plus sophistiqués, avec des fonctions de mise en cache, de sécurité et de gestion. Au fur et à mesure de l'évolution de la technologie, Kiva et NetDynamics ont intégré la technologie côté serveur spécifique à Java, qui a finalement été fusionnée avec JSP. Microsoft a ajouté ASP, je pense en 1996, à Windows NT 4.0. Le serveur Web statique avait appris quelques nouvelles astuces, de sorte que c'était un "serveur d'applications" efficace pour de nombreux scénarios.

Dans une catégorie parallèle, le serveur d'applications avait évolué et existait depuis longtemps. Les entreprises 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 a ensuite évolué vers COM +. La plupart de ces produits spécifiaient des protocoles de communication «fermés» spécifiques au produit pour interconnecter les clients «gros» 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é à se brouiller.

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

À ce stade, la ligne entre "serveur d'application" et "serveur Web" est floue. Mais les gens continuent à utiliser les termes différemment, comme une question d'emphase. Quand quelqu'un dit "serveur web", vous pensez souvent à des applications orientées HTTP, centrées sur l'interface utilisateur. Quand quelqu'un dit «App server», vous pouvez penser à des charges plus lourdes, des fonctionnalités d'entreprise, des transactions et des files d'attente, des communications multicanaux (HTTP + more), mais souvent le même produit répond aux deux exigences de charge de travail.

  • WebSphere, le «serveur d'applications» d'IBM possède son propre serveur Web.
  • WebLogic, un autre serveur d'application traditionnel, de même.
  • Windows, qui est le serveur d'applications de Microsoft (en plus d'être son serveur de fichiers et d'impression, le serveur de médias, etc.), regroupe les services Internet (IIS).

52
2018-06-01 19:54



serveur Web

Courir python -m 'SimpleHTTPServer' et allez à http: // localhost: 8080. Ce que vous voyez 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 ceci est 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 Ballon).

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

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

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

Pour exécuter ce code, nous avons besoin d'un serveur d'application - un programme ou un module capable d'écouter les requêtes d'un client et d'utiliser notre code, de retourner quelque chose dynamiquement. Dans l'exemple, nous retournons simplement du HTML très mauvais.

Quelle est la logique métier dont parlent tous les autres? Eh bien, comme une URL correspond à quelque chose de spécifique dans notre base de code, nous montrons une certaine logique sur le fonctionnement de notre programme.


Récapitulation

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

serveur d'application - 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'application stricts tels que 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. Ceci est fait dans certains cas pendant le développement où vous ne voulez pas avoir un gazillion de différents serveurs fonctionnant sur votre ordinateur.


34
2018-02-12 10:56



Comme beaucoup l'ont déjà dit, les serveurs Web gèrent les requêtes HTTP, tandis que les serveurs d'applications gèrent les requêtes pour les composants distribués. Donc, peut-être la meilleure façon de comprendre la différence est de comparer les deux produits en ce qui concerne l'environnement de programmation qu'ils offrent.

Serveur Web -> Environnement de programmation

IIS: ASP (.NET)

Tomcat: Servlet

Jetée: Servlet

Apache: Php, CGI

Serveurs d'applications -> Environnement de programmation

MTS: COM +

WAS: EJB

JBoss: EJB

WebLogic Application Server: EJB

La différence cruciale est que les serveurs d’applications supportent composant distribué la technologie, en fournissant des fonctionnalités telles que l'invocation à distance et les transactions distribuées, comme EJB dans le monde de Java ou COM + sur la plate-forme Microsoft. Les serveurs Http supportent souvent des environnements de programmation plus simples, souvent script, comme ASP (.NET) dans le cas de Microsoft ou Servlet, y compris JSP et bien d'autres dans le cas de Java ou PHP et CGI dans le cas d'Apache.

D'autres fonctionnalités telles que l'équilibrage de charge, le clustering, le basculement de session, le regroupement de connexions, etc., qui étaient auparavant des serveurs d'applications, sont également disponibles sur les serveurs Web directement ou via certains produits tiers.

Enfin, il convient de noter que l'image est encore 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 d'un composant distribué à un paradigme de service et à une architecture SOA, il reste de moins en moins de place pour les serveurs d'applications traditionnels.


33
2017-11-01 14:26



Un serveur Web traite exclusivement les requêtes HTTP / HTTPS. Il sert du contenu sur le Web en utilisant le protocole HTTP / HTTPS.

Un serveur d'applications sert la logique métier aux programmes d'application via un nombre quelconque de protocoles, incluant éventuellement le protocole 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) des serveurs d'applications Java EE (Java Platform, Enterprise Edition). L'essentiel est que le serveur Web expose tout via le protocole http, alors que le serveur d'applications ne lui est pas limité. Un serveur d'application offre donc beaucoup plus de services qu'un serveur web qui inclut typiquement:

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

La plupart des serveurs d'applications font partie intégrante du serveur Web, ce qui signifie que App Server peut faire tout ce que le serveur Web est capable de faire. En outre, App Server dispose de composants et de fonctionnalités pour prendre en charge les services de niveau Application tels que le regroupement de connexions, la mise en pool d'objets, la prise en charge de transactions, les services de messagerie, etc.

Un serveur d'application peut (mais pas toujours) s'exécuter sur un serveur Web pour exécuter une logique de programme dont les résultats peuvent être transmis par le serveur Web. C'est un exemple de scénario de serveur web / serveur d'application. 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 sommet" d'IIS, exécute une logique spécifique et fournit les résultats via IIS. Dans le monde Java, il existe un scénario similaire avec Apache et Tomcat, par exemple.

Comme les serveurs Web sont bien adaptés aux contenus statiques et aux serveurs d'applications pour le contenu dynamique, la plupart des environnements de production ont un serveur Web agissant en tant que proxy inverse du serveur d'applications. Cela signifie que lors du traitement d'une demande de page, des contenus statiques tels que des images / Static html sont servis par le serveur Web qui interprète la requête. 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'applications.

Apache HTTP Server et BEA WebLogic Server sont des exemples de cette configuration. 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é d'un 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+

17
2017-12-19 14:02