Discussion :

[ahmedpa]

Bonjour,

J'aimerais savoir quelles différences existent entre un serveur web et un serveur d'applications ?
J'ai déjà cherché sur le net mais le domaine est très vaste.

J'aimerais bien avoir votre idée à propos de ça et éventuellement des exemples de serveurs.

Merci d'avance.

[Laurent.B]

Bonjour,

En fait, tout ceci est très subtile, c'est sans doute pour cela que tu as du mal à trouver des informations précises.

C'est subtile parce que ça dépend de ce que l'on fait de son serveur web ou de son serveur d'applications.

Par exemple, le serveur Apache est avant tout un serveur Web, c'est-à-dire qu'il renvoie des pages HTML. De base il n'est pas un serveur d'applications. Par contre, si on lui ajoute des scripts PHP par exemple, hé bien on peut très bien considérer que l'on a un serveur d'applications mais encore faut-il que les pages HTML générées par ces scripts PHP forment une sorte d'application en ligne (un site de vente ou un backoffice par exemple). Si les scripts PHP génèrent des pages dont le contenu n'est pas particulièrement dynamique, il sera difficile de considérer cela comme une application.

Bon, plus généralement, on parle de serveur d'applications lorsqu'un serveur exécute des applications qui peuvent être de type Web, WebService, EJB...
Quand on parle d'application ici, généralement on sous-entend "application métier", donc proposant des fonctionnalités spécifiques à l'activité des entreprises.

D'autre part, on peut aussi avoir du mal à considérer Tomcat comme un serveur d'applications, parce que sont rôle se "cantonne" en quelque sorte à exécuter des servlets (et dérivés) mais pourtant ces servlets sont contenues dans des "webapp", donc des applications et le considérer comme un serveur d'applications n'est finalement pas inapproprié.

Voilà, je ne suis pas sûr que ce soit plus clair mais dans cette histoire, on confond souvent, serveur physique/programme serveur, contenu/contenant.

Cela dit, tu ne te tromperas pas en disant que :
WebSphere, WebLogic, JBoss, JOnAS, GlassFish.... sont des serveurs d'applications.
Apache est un serveur Web.
Apache Tomcat, Jetty, ... sont des moteurs de servlets (souvent embarqués dans les serveurs d'applications pour gérer la partie servlet justement).

Il ne faut pas trop se prendre la tête avec ces termes, l'important est de savoir ce qu'est capable de gérer tel ou tel (programme) serveur.

[DevServlet]

Bonjour,
Globalement je suis d'accord avec toi, et d'accord aussi sur le fait que le terme serveur d'application, conteneur de servlets, et conteneur EJB peuvent prêter à confusion.Mais avant de donner ma propre analyse à moi, je tiens à apporter quelques précisions sur tes réponses.

Par contre, si on lui ajoute des scripts PHP par exemple, hé bien on peut très bien considérer que l'on a un serveur d'applications mais encore faut-il que les pages HTML générées par ces scripts PHP forment une sorte d'application en ligne (un site de vente ou un backoffice par exemple). Si les scripts PHP génèrent des pages dont le contenu n'est pas particulièrement dynamique, il sera difficile de considérer cela comme une application.

Nan nan pour moi apache et Php sont 2 serveurs bien différents,ce n'est pas seulement en rajoutant des scripts php qu'il devient serveur d'application, mais c'est bien en le couplant au serveur PHP qu'il devient un serveur en part entière. C'est d'ailleurs la raison pour laquelle WAMP= Windows Apache Mysql PHP, c'est bien un mélange de 3 serveurs en un.

Bon, plus généralement, on parle de serveur d'applications lorsqu'un serveur exécute des applications qui peuvent être de type Web, WebService, EJB...
Quand on parle d'application ici, généralement on sous-entend "application métier", donc proposant des fonctionnalités spécifiques à l'activité des entreprises.

Un serveur application peut aussi peut aussi être utilisé dans un contexte hors web, exemple une base de donnée qui tourne et répond aux requêtes SQL est un serveur d'application, en d'autres termes je peux me tromper mais d'un point purement théorique je dirai qu'un serveur d'application est tout simplement une entité capable de fournir des services en s'appuyant sur un langage qu'il est le seul à comprendre (sa cuisine interne)

D'autre part, on peut aussi avoir du mal à considérer Tomcat comme un serveur d'applications, parce que sont rôle se "cantonne" en quelque sorte à exécuter des servlets (et dérivés) mais pourtant ces servlets sont contenues dans des "webapp", donc des applications et le considérer comme un serveur d'applications n'est finalement pas inapproprié.

Pour moi tomcat est un serveur d'application mais avec la spécificité de gérer les servlets.
Mais bon après ce sont des définitions qui n'engagent que moi et je vois là venir un débat sur ces concepts

[Laurent.B]

PHP n'est pas un serveur, c'est un langage. Il faut un interpréteur pour pouvoir exécuter des scripts dans ce langage mais là n'est pas le sujet.

Je ne cherchais pas à provoquer un débat, j'ai peut-être fait des raccourcis mais je ne crois pas que ce soit gênant pour la compréhension de ahmedpa. D'ailleurs, est-ce plus clair ou pas pour toi ahmedpa ?

[DevServlet]

PHP n'est pas un serveur, c'est un langage. Il faut un interpréteur pour pouvoir exécuter des scripts dans ce langage mais là n'est pas le sujet.

Non je persiste là dessus, PHP est bien sûr un langage serveur, et comme tout langage serveur il faut un serveur pour l'exécuter, d'où un serveur PHP, tu peux executer un script php sans forcément installer Apache, fais une recherche Google à ce propos et tu rejoindras mon analyse. lien ici, ou lis ce tutoriel officiel de php

[Laurent.B]

Nan je persiste là dessus, PHP est bien sûr un langage serveur, et comme tout langage serveur il faut un serveur pour l'éxécuter, d'où un serveur PHP, tu peux executer un script php sans forcément installer Apache, fais une recherche google à ce propos et tu rejoindras mon analyse.lien ici, ou lis ce tutoriel officiel de php

PHP n'est même pas/plus un langage serveur (ce qui au passage ne veut rien dire). Un serveur PHP ça n'existe pas dit comme ça.
Oui ma formulation aurait pu faire croire que je ne dissociais pas Apache et PHP mais dans le cas présent on s'en moque...