Quelle est la différence entre serveur d'applications et serveur Web?
Quelle est la différence entre serveur d'applications et serveur Web?
La plupart du temps, ces termes Serveur Web et Serveur d'applications sont utilisés de manière interchangeable.
Voici certaines des principales différences entre les fonctionnalités de Web Server et Application Server:
- Web Server est conçu pour servir le 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 serveurs Web disposent de plug-ins prenant en charge des langages de script tels que Perl, PHP, ASP, JSP, etc. via 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 qu'App Server peut faire tout ce que Web Server est capable de faire. De plus, App Server possède des composants et des fonctionnalités pour prendre en charge des services de niveau application tels que le regroupement de connexions, le regroupement d'objets, la prise en charge de 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 disposent d'un serveur Web faisant office de proxy inverse pour le serveur d'applications. Cela signifie que lors du traitement d'une requête de page, les contenus statiques (tels que images/HTML statique) sont servis par un serveur Web qui interprète la requête. En utilisant une technique de filtrage (principalement l'extension de la ressource demandée), le serveur Web identifie la demande de contenu dynamique et le transmet de manière transparente au serveur d'applications.
Un exemple de cette configuration est le serveur HTTP Apache Tomcat et le serveur WebLogic Oracle (anciennement BEA). 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é d'un environnement d'exécution .NET, IIS est capable de fournir des services d'application.
C’est une réponse détaillée avec quelques scénarios pour bien comprendre la différence, la similitude et la manière dont les deux peuvent fonctionner ensemble et tous.
Serveur d'applications est un terme parfois associé à un serveur Web . Alors qu'un serveur Web gère principalement les protocoles HTTP , le serveur d'applications traite plusieurs protocoles différents, notamment, mais n'est pas limité. , en HTTP .
La tâche principale du serveur Web consiste à afficher le contenu du site et le serveur d'applications est en charge de la logique , l'interaction entre l'utilisateur et le contenu affiché. Le serveur d'applications travaille en conjonction avec le serveur Web, l'un affiché et l'autre interagissant.
Les informations échangées entre le serveur et son client ne se limitent pas à un simple marquage d'affichage, mais à une interaction entre les deux.
Dans la plupart des cas, le serveur crée cette interaction via une API de composant , telle que J2EE ( Plateforme Java 2) , EJB (Enterprise JavaBean) et d'autres modèles de logiciels d'application.
Un exemple:
La meilleure façon de comprendre la différence entre les scénarios dans lesquels un serveur d'applications fonctionne avec le serveur Web et ceux qui ne le sont pas 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 expliquer celle-ci 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 en aller-retour entre le serveur et le serveur de base de données a lieu chaque fois qu'une requête est exécutée.
Scénario 2: serveur Web avec un serveur d'application
si la requête que vous souhaitez exécuter a déjà été effectuée 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 lorsqu'un second 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. Comme ces informations sont incorporées dans une page HTML particulière et "personnalisée", il ne s'agit pas d'un processus réutilisable. Un deuxième client devra demander à nouveau les informations et recevoir une autre page HTML incorporée avec les informations demandées - très inefficaces. 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 le pooling de 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 traiter 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 inversement dans certains cas.
serveur Web: sert le contenu sur le Web en utilisant le protocole http.
serveur d'applications: héberge et expose la logique et les processus métier.
Je pense que l’essentiel est que le serveur Web expose tout via le protocole http, alors que le serveur d’applications n’est pas limité à cela.
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 permettant à l’utilisateur d’interagir avec les règles de gestion trouvées dans le serveur. serveur d'application.
Comme l'ont souligné Rutesh et Jmservera, la distinction est floue. Historiquement, elles étaient différentes, mais au cours des années 90, ces deux catégories auparavant distinctes ont fusionné des caractéristiques et ont fusionné. À ce stade, il est probablement préférable d’imaginer que la catégorie de produit "Serveur d’application" est un sur-ensemble strict de la catégorie "Serveur Web".
Un peu d'histoire. Dans les débuts du navigateur Mosaic et du contenu hypertexte, il a évolué, ce qui s'appelle un "serveur Web" qui sert le contenu de pages Web et les images via HTTP. La plupart du contenu était statique et le protocole HTTP 1.0 n'était qu'un moyen de transférer des fichiers. Rapidement, la catégorie "serveur Web" a évolué pour inclure la fonctionnalité CGI - lancement effectif d'un processus sur chaque demande Web pour générer un contenu dynamique. HTTP a également mûri et les produits sont devenus plus sophistiqués, avec des fonctionnalités de mise en cache, de sécurité et de gestion. À mesure que la technologie évoluait, nous avons obtenu de Kiva et de NetDynamics une technologie côté serveur basée sur Java et propre à la société, qui ont finalement toutes été fusionnées dans JSP. Microsoft a ajouté ASP, je pense en 1996, à Windows NT 4.0. Le serveur Web statique avait appris de nouvelles astuces, ce qui en faisait un "serveur d'applications" efficace dans de nombreux scénarios.
Dans une catégorie parallèle, le serveur d'applications avait évolué et existait depuis longtemps. Les sociétés ont livré des produits pour Unix tels que Tuxedo, TopEnd et Encina, qui étaient philosophiquement dérivés des environnements de gestion et de surveillance des applications Mainframe tels que IMS et CICS. L'offre de Microsoft était Microsoft Transaction Server (MTS), qui a ensuite évolué pour devenir COM +. La plupart de ces produits ont spécifié des protocoles de communication "fermés" spécifiques au produit pour interconnecter les "gros" clients aux serveurs. (Pour Encina, le protocole de communication était DCE RPC; pour MTS, DCOM; etc.) En 1995/96, ces produits de serveur 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 de plus en plus matures en ce qui concerne la gestion de charges plus élevées, de plus de simultanéité et de meilleures fonctionnalités. Les serveurs d'applications offraient de plus en plus de capacités de communication basées sur HTTP.
À ce stade, la ligne entre "serveur d'applications" et "serveur Web" est floue. Mais les gens continuent à utiliser les termes différemment, par souci d'emphase. Lorsque quelqu'un dit "serveur Web", vous pensez souvent à des applications orientées HTTP, à une interface utilisateur Web ou à une interface HTTP. Quand quelqu'un dit "Serveur d'application", vous pouvez penser "des charges plus lourdes, des fonctionnalités d'entreprise, des transactions et des files d'attente, une communication multicanal (HTTP + plus). Mais souvent, c'est le même produit qui répond aux deux exigences de charge de travail.
- WebSphere, le "serveur d'applications" d'IBM, possède son propre serveur Web intégré.
- De même, WebLogic, un autre serveur d'applications traditionnel.
- Windows, qui est le serveur d'applications de Microsoft (en plus d'être son serveur de fichiers et d'impression, son serveur de supports, etc.), regroupe IIS.
serveur Web
Exécutez python -m 'SimpleHTTPServer' et accédez à http: // localhost: 808 . Qu'est-ce que vous voyez est un serveur Web à ses travaux. 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 sur un protocole différent.
Serveur d'application
Disons que nous avons une application minuscule 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 exemple de programme mappe l'URL / sur la fonction homepage() et le /about sur la fonction about().
Pour exécuter ce code, nous avons besoin d’un serveur d’application (par exemple, Gunicorn) - un programme ou un module capable d’écouter les demandes d’un client et d’utiliser notre code pour renvoyer quelque chose de manière dynamique. Dans l'exemple, nous renvoyons simplement un très mauvais HTML.
Quelle est la logique métier que toutes les autres personnes parlent? Dans la mesure où une adresse URL correspond à un emplacement spécifique de notre base de code, nous montrons de manière hypothétique une certaine logique concernant le fonctionnement de notre programme.
Recapsulation
serveur Web - sert les 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 plug-in ou viennent même avec une fonctionnalité intégrée 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. Cela se fait dans certains cas, au cours du développement, lorsque vous ne voulez pas utiliser un nombre de milliards de serveurs différents sur votre ordinateur.
Comme beaucoup l'ont déjà dit, les serveurs Web traitent les requêtes HTTP, tandis que les serveurs d'applications traitent les requêtes de composants distribués. La meilleure façon de comprendre la différence est donc peut-être 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 réside dans le fait que les serveurs d’applications prennent en charge certaines technologies composant distribué, offrant des fonctionnalités telles que l’appel à distance et les transactions distribuées, telles que EJB dans Java monde ou COM + sur la plate-forme Microsoft. Le serveur HTTP prend souvent en charge des environnements de programmation plus simples, utilisant souvent des scripts, tels que 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 la charge, la mise en cluster, le basculement de session, le regroupement de connexions, etc., qui appartenaient auparavant aux serveurs d'applications, sont désormais disponibles sur les serveurs Web, directement ou via des produits tiers.
Enfin, il convient de noter que l'image est encore plus déformée avec des "conteneurs légers" tels que 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 comme la distribution dans les applications évolue de composant distribué vers le paradigme de service et l'architecture SOA, il y a de moins en moins d'espace disponible pour les serveurs d'applications traditionnels.
Un serveur Web gère exclusivement les requêtes HTTP/HTTPS. Il sert le contenu sur le Web en utilisant le protocole HTTP/HTTPS.
Un serveur d'applications sert la logique métier aux programmes d'applications via un nombre quelconque de protocoles, y compris éventuellement HTTP. Le programme d'application peut utiliser cette logique de la même manière qu'il appelle 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 n'est pas limité à cela. 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)
- Equilibrage de charge, basculement ...
- Gestion du cycle de vie des objets
- Gestion d'état (session)
- Gestion des ressources (par exemple, des pools de connexion à la base de données)
La plupart des serveurs d'applications ont Web Server comme partie intégrante, ce qui signifie qu'App Server peut faire tout ce que Web Server est capable de faire. De plus, App Server possède des composants et des fonctionnalités pour prendre en charge des services de niveau application tels que le regroupement de connexions, le regroupement d'objets, la prise en charge de transactions, les services de messagerie, etc.
Un serveur d'applications peut (mais pas toujours) s'exécuter sur un serveur Web pour exécuter une logique de programme, dont les résultats peuvent ensuite être transmis par le serveur Web. C'est un exemple de scénario serveur Web/serveur d'applications. La relation Internet Information Server/SharePoint Server est un bon exemple dans le monde Microsoft. 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 diffuse 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 disposent d'un serveur Web faisant office de proxy inverse pour le serveur d'applications. Cela signifie que lors du traitement d'une demande de page, des contenus statiques tels que images/Static html sont fournis par un serveur Web qui interprète la demande. En utilisant une technique de filtrage (principalement l'extension de la ressource demandée), le serveur Web identifie la demande de contenu dynamique et le 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é 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 principale différence entre serveur Web et serveur d'applications est que le serveur Web est destiné à servir des pages statiques, par exemple. HTML et CSS, tandis qu'Application Server est chargé de générer du contenu dynamique en exécutant un code côté serveur, par exemple. JSP, Servlet ou EJB.
Lequel dois-je utiliser?
Une fois que vous connaissez la différence entre Web et serveur d'applications et conteneurs Web, il est facile de savoir quand les utiliser. Si vous utilisez des pages Web statiques, vous avez besoin d'un web server comme Apache HTTPD. Si vous avez une application Java avec uniquement JSP et Servlet pour générer du contenu dynamique, vous avez besoin de web containers comme Tomcat ou Jetty. Alors que si vous avez Java application EE utilisant EJB, transaction distribuée, messagerie et autres fonctionnalités sophistiquées , vous avez besoin d'un application server complet comme JBoss, WebSphere ou WebLogic d’Oracle.
Le conteneur Web fait partie de Web Server et le serveur Web fait partie d'Application Server.
Web Server est composé d'un conteneur Web, tandis qu'Application Server est composé d'un conteneur Web et d'un conteneur EJB.
En bref, un serveur Web est un serveur qui sert des pages Web aux utilisateurs via http. Un serveur d'application est un serveur qui héberge la logique métier d'un système. Il héberge souvent des processus longs/par lots et/ou des services d'interopérabilité non destinés à la consommation humaine (services REST/JSON, SOAP, RPC, etc.).
En Java, il y en a un autre: conteneur Web (ou plus strictement, conteneur de servlet). C'est, disons, entre le serveur Web et le serveur d'applications. Un conteneur Web dans Java terms est un serveur d'applications qui uniquement implémente la partie JSP/Servlet de Java EE et manque de plusieurs parties Java EE, tel que le support EJB. Apache Tomcat en est un exemple.
Un serveur d'applications est généralement conçu et déployé pour faciliter l'exécution de processus plus longs qui nécessiteront également davantage de ressources.
Un serveur Web est généralement utilisé pour les courtes rafales ne nécessitant pas beaucoup de ressources. Ceci est principalement pour faciliter le service du trafic Web.
Un serveur Web exécute le protocole HTTP pour servir les pages Web. Un serveur d'applications peut (mais pas toujours) s'exécuter sur un serveur Web pour exécuter une logique de programme, dont les résultats peuvent ensuite être transmis par le serveur Web. C'est un exemple de scénario serveur Web/serveur d'applications.
La relation Internet Information Server/SharePoint Server est un bon exemple dans le monde Microsoft. 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 diffuse les résultats via IIS.
Dans le monde Java, il existe un scénario similaire avec Apache et Tomcat, par exemple.
Tout d’abord, un serveur Web sert du contenu Web (HTML et contenu statique) via le protocole HTTP. D'autre part, 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 différents protocoles, y compris HTTP dans une architecture à plusieurs 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 d'état (session),
- Gestion des ressources (par exemple, des pools de connexion à la base de données),
- Equilibrage de charge, basculement ...
Autant que je sache, ATG Dynamo a été l’un des tout premiers serveurs d’applications à la fin des années 90 (selon la définition ci-dessus). Au début des années 2000, certains serveurs d’applications propriétaires, tels que ColdFusion (CFML AS), BroadVision (JavaScript AS côté serveur), étaient sous le règne de ce dernier, etc. Java époque du serveur d'applications.
La frontière entre les deux devient de plus en plus mince.
Les serveurs d'applications exposent la logique métier à un client. Ainsi, son serveur d’applications d’application comprend un ensemble de méthodes (pas nécessairement, il peut même s'agir d’un ordinateur en réseau permettant à de nombreuses personnes d’exécuter des logiciels) afin d’exécuter une logique d’entreprise. Donc, il va simplement sortir les résultats souhaités, pas le contenu HTML. (similaire à un appel de méthode). Donc, ce n'est 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 des scripts côté serveur aidait également les serveurs Web à gérer le contenu dynamique. Où le serveur Web prend la demande et la dirige vers le script (PHP, JSP, scripts CGI, etc.) pour CRÉER le contenu HTML à envoyer au client. Ensuite, le serveur Web sait comment les renvoyer au client. PARCE QUE c'est ce qu'un serveur Web sait vraiment.
Cela dit, les développeurs utilisent actuellement ces deux technologies ensemble. Lorsque le serveur Web accepte la demande, puis appelle un script pour créer le code HTML, le script BUT appelle à nouveau un serveur d'application LOGIC (par exemple, récupérer les détails de la transaction) pour remplir le contenu HTML.
Donc, dans ce cas, les deux serveurs ont été utilisés efficacement.
Par conséquent ... Nous pouvons dire en toute sécurité que de nos jours, dans la plupart des cas, les serveurs Web sont utilisés en tant que 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 trouvé this article assez pratique.
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, quel que soit le protocole utilisé) les demandes des clients pour le service fourni, puis effectue quelque chose en fonction de ces demandes. (peut impliquer ou non 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 à partir d'un fichier HTML statique sur le serveur, soit construite de manière dynamique en fonction des paramètres de la demande client entrante.
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 prenez TomEE à titre d'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 techniciens sur le serveur Web si vous le souhaitez, mais les serveurs d'applications ne font que regrouper toutes ces choses pour votre commodité. Pour être entièrement classé en tant que serveur d'applications, vous devez essentiellement vous conformer à la liste des outils définis par certaines normes.
En réalité, Apache est un serveur Web et Tomcat est un serveur d'applications. Lorsque la requête HTTP arrive sur le serveur Web. Ensuite, les contenus statiques sont renvoyés au navigateur par serveur Web. Y a-t-il une logique à faire, puis cette demande est envoyée au serveur d'applications. après traitement de la logique, la réponse est envoyée au serveur Web et envoyée au client.
La plus grande différence est qu'un serveur Web gère les demandes HTTP, tandis qu'un serveur d'applications exécute la logique métier sur un nombre quelconque de protocoles.
Le serveur d'applications et le serveur Web sont tous deux utilisés pour héberger une application Web. Web Server est traité avec le conteneur Web, d'autre part. Application Server est traité avec le conteneur Web, ainsi que le conteneur EJB (Enterprise JavaBean) ou COM + pour Microsoft dot Net.
Web Server est conçu pour servir du contenu statique HTTP tel que HTML, des images, etc. Il comporte des plugins prenant en charge les langages de script tels que Perl, PHP, ASP, JSP, etc. Il est limité au protocole HTTP. Les serveurs ci-dessous peuvent générer un contenu HTTP dynamique.
Environnement de programmation du serveur Web:
IIS: ASP (.NET)
Apache Tomcat: Servlet
Jetée: Servlet
Apache: Php, CGI
Application Server peut faire tout ce que Web Server est capable et écoute en utilisant n'importe quel protocole, et App Server dispose de composants et de fonctionnalités pour prendre en charge des services de niveau application tels que le regroupement de connexions, le regroupement d'objets, la prise en charge de transactions, les services de messagerie, etc.
Environnement de programmation du serveur d'applications:
MTS: COM +
WAS: EJB
JBoss: EJB
WebLogic Application Server: EJB
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'applications).
De https://en.wikipedia.org/wiki/Web_server
Un serveur Web est un système informatique qui traite les demandes via HTTP, protocole réseau de base utilisé pour distribuer 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 .
De 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 et composants d'exécution ( serveur d'applications offre .
Compréhension de base :
Dans l'architecture client/serveur
Serveur:> Qui sert les requêtes.
Client:> Qui consomme le service.
Serveur Web et serveur d'applications sont deux applications logicielles qui agissent en tant que serveurs pour 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.
Usage -
we require low processing rates, regular processing practices involves.Ex.: Tous les serveurs plats généralement disponibles prêts à l'emploi qui servent uniquement 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.
Usage -
we require multi point processing, specialized processing techniques involves like for AI.Ex: serveurs de cartes Google, serveurs de recherche Google, serveurs Google Documents, serveurs Microsoft 365, serveurs de vision d'ordinateur Microsoft pour AI.
Nous pouvons les assumer en tant que 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.
Suivez ce lien pour les analogies d’architecture standard:
https://docs.Microsoft.com/en-us/previous-versions/msp-n-p/ee658120 (v% 3dpandp.10)
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, réside 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 d'état entre le client et le serveur (donc REST) et/ou en la sérialisant sur un stockage persistant externe (SQL Server, Memcached, etc.).
Sur le serveur d'applications, la session est généralement plus explicite et prend souvent la forme d'un objet résidant 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 des protocoles Web de manière native (XML/RPC/SOAP sur HTTP), de sorte qu'il y a peu de différence technique. En règle générale, un serveur Web est orienté utilisateur, fournissant une variété de contenu via HTTP/HTTPS, tandis qu'un serveur d'applications n'est pas orienté utilisateur et peut utiliser des protocoles non standard ou non routables. Bien sûr, avec RIA/AJAX, la différence pourrait encore être atténuée, ne fournissant que du contenu non HTML (JSON/XML) aux clients exploitant 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 incorporées dans le contenu HTML demandé. Quel serait l'impact?
Par exemple, imaginez que vous ayez deux applications différentes qui rendent le contenu HTML entièrement différent du navigateur. Si vous sépariez la logique métier en un serveur d'applications, vous pourriez fournir différents serveurs Web recherchant les mêmes données dans le serveur d'applications via des scripts. Toutefois, si vous ne sépariez pas la logique et la conserviez sur le serveur Web, chaque fois que vous modifiez votre modèle commercial, vous finissez par la modifier sur chaque serveur Web dont vous disposez, ce qui prendrait plus de temps, serait moins fiable et plus économique. sujet aux erreurs.