Pregunta ¿Cuál es la diferencia entre el servidor de aplicaciones y el servidor web?


¿Cuál es la diferencia entre el servidor de aplicaciones y el servidor web?


523
2018-06-01 18:57


origen


Respuestas:


La mayoría de las veces estos términos Servidor web y Servidor de aplicaciones se usan indistintamente.

A continuación se detallan algunas de las principales diferencias en las características de Servidor web y Servidor de aplicaciones:

  • El servidor web está diseñado para servir contenido HTTP. App Server también puede servir contenido HTTP pero no está limitado a solo HTTP. Se puede proporcionar otro soporte de protocolo como RMI / RPC
  • El servidor web está diseñado principalmente para servir contenido estático, aunque la mayoría de los servidores web tienen complementos para admitir lenguajes de scripting como Perl, PHP, ASP, JSP, etc. a través de los cuales estos servidores pueden generar contenido HTTP dinámico.
  • La mayoría de los servidores de aplicaciones tienen el Servidor Web como parte integral de ellos, lo que significa que el Servidor de Aplicaciones puede hacer lo que sea que el Servidor Web sea capaz de hacer. Además, App Server tiene componentes y características para admitir servicios de nivel de aplicación como la agrupación de conexiones, la agrupación de objetos, el soporte de transacciones, los servicios de mensajería, etc.
  • Como los servidores web son adecuados para el contenido estático y los servidores de aplicaciones para el contenido dinámico, la mayoría de los entornos de producción tienen un servidor web que actúa como proxy inverso al servidor de la aplicación. Esto significa que al atender una solicitud de página, el servidor web que interpreta la solicitud proporciona contenidos estáticos (como imágenes / HTML estático). Utilizando algún tipo de técnica de filtrado (principalmente la extensión del recurso solicitado), el servidor web identifica la solicitud de contenido dinámico y reenvía transparente al servidor de aplicaciones.

Ejemplo de tal configuración es Apache Tomcat HTTP Server y Oracle (anteriormente BEA) WebLogic Server. El servidor HTTP Apache Tomcat es el servidor web y Oracle WebLogic es el servidor de aplicaciones.

En algunos casos, los servidores están estrechamente integrados, como IIS y .NET Runtime. IIS es un servidor web. Cuando está equipado con el entorno de tiempo de ejecución .NET, IIS es capaz de proporcionar servicios de aplicaciones.


475
2018-06-01 19:10



Ambos términos son muy genéricos, uno que contiene el otro y viceversa en algunos casos.

  • Servidor web: sirve contenido a la web usando el protocolo http.

  • Servidor de aplicaciones: aloja y expone la lógica y los procesos comerciales.

Creo que el punto principal es que el servidor web expone todo a través del protocolo http, mientras que el servidor de aplicaciones no está restringido a él.

Dicho esto, en muchos escenarios encontrará que el servidor web se usa para crear el front-end del servidor de aplicaciones, es decir, expone un conjunto de páginas web que le permiten interactuar con las reglas comerciales encontradas en el servidor. servidor de aplicaciones.


105
2018-06-01 19:30



Esta es una respuesta detallada con algunos escenarios para entender claramente la diferencia, la similitud y cómo ambos pueden trabajar en conjunto y todos

Servidor de aplicaciones es un término que a veces se mezcla con un Servidor web. Mientras que un servidor web maneja principalmente Protocolos HTTP, el servidor de aplicaciones trata con varios protocolos diferentes, incluyendo, pero no limitado a HTTP.

El trabajo principal del servidor web es mostrar el contenido del sitio y el servidor de aplicaciones es a cargo de la lógica, la interacción entre el usuario y el contenido mostrado. El servidor de aplicaciones es trabajando en conjunto con el servidor web, donde uno muestra y el otro interactúa.

La información que viaja de ida y vuelta entre el servidor y su cliente no está restringida al marcado de visualización simple, sino a la interacción entre los dos.

En la mayoría de los casos, el servidor crea esto interacción a través de una API componente, como J2EE (Plataforma Java 2), EJB (Enterprise JavaBean) y otros modelos de software de aplicación diferentes.

enter image description here

Un ejemplo:

La mejor manera de entender la diferencia entre los escenarios donde un servidor de aplicaciones funciona con el servidor web versus un escenario donde no hay un servidor de aplicaciones es a través de una tienda en línea.

Escenario 1: servidor web sin un servidor de aplicaciones 

usted tiene una tienda en línea con solo un servidor web y ningún servidor de aplicaciones. El sitio proporcionará una pantalla donde puede elegir un producto. Cuando envía una consulta, el sitio realiza una búsqueda y devuelve un resultado HTML a su cliente. El servidor web envía su consulta directamente al servidor de la base de datos (tenga paciencia, lo explicaré en nuestro próximo nugget) y espera una respuesta. Una vez recibido, el servidor web formula la respuesta en un archivo HTML y lo envía a su navegador web. Esta comunicación de ida y vuelta entre el servidor y el servidor de base de datos ocurre cada vez que se ejecuta una consulta.

Escenario 2: servidor web con un servidor de aplicaciones

si la consulta que desea ejecutar ya se ha realizado previamente y no se han modificado los datos desde entonces, el servidor generará los resultados sin tener que enviar la solicitud al servidor de la base de datos. Esto permite una consulta en tiempo real donde un segundo cliente puede acceder a la misma información y recibir información confiable en tiempo real sin enviar otra consulta duplicada al servidor de la base de datos. El servidor básicamente actúa como intermediario entre el servidor de la base de datos y el servidor web. Esto permite que la información extraída sea reutilizable mientras que en el primer escenario, ya que esta información está incrustada en una página HTML particular y "personalizada", este no es un proceso reutilizable. Un segundo cliente deberá solicitar nuevamente la información y recibir otra página embebida en HTML con la información solicitada, muy ineficiente. Sin mencionar que este tipo de servidor es muy flexible debido a su capacidad de administrar sus propios recursos, incluida la seguridad, el procesamiento de transacciones, la mensajería y la agrupación de recursos.

Para admitir una variedad de tareas complejas, este servidor debe tener una redundancia incorporada, una gran capacidad de procesamiento y una gran cantidad de RAM para manejar todos los datos que extrae en tiempo real.

Espero que esto ayude.


99
2018-06-07 13:17



Como señalaron Rutesh y jmservera, la distinción es confusa. Históricamente, fueron diferentes, pero a través de los años 90 estas dos categorías previamente distintas combinaron características y se fusionaron de manera efectiva. En este punto, probablemente sea mejor imaginar que la categoría de producto "Servidor de aplicaciones" es un superconjunto estricto de la categoría "servidor web".

Algo de historia. En los primeros días del navegador Mosaic y el contenido hipervinculado, evolucionó este llamado "servidor web" que servía el contenido de la página web y las imágenes a través de HTTP. La mayoría del contenido era estático, y el protocolo HTTP 1.0 era solo una forma de enviar archivos. Rápidamente, la categoría de "servidor web" evolucionó para incluir la capacidad de CGI, iniciando efectivamente un proceso en cada solicitud web para generar contenido dinámico. HTTP también maduró y los productos se volvieron más sofisticados, con funciones de caché, seguridad y administración. A medida que la tecnología maduró, obtuvimos tecnología del lado del servidor basada en Java y específica de la empresa de Kiva y NetDynamics, que eventualmente se fusionaron en JSP. Microsoft agregó ASP, creo que en 1996, a Windows NT 4.0. El servidor web estático había aprendido algunos trucos nuevos, por lo que era un "servidor de aplicaciones" eficaz para muchos escenarios.

En una categoría paralela, el servidor de aplicaciones evolucionó y existió durante mucho tiempo. las empresas entregaron productos para Unix como Tuxedo, TopEnd, Encina que se derivaron filosóficamente de la administración de aplicaciones de Mainframe y entornos de monitoreo como IMS y CICS. La oferta de Microsoft fue Microsoft Transaction Server (MTS), que luego se convirtió en COM +. La mayoría de estos productos especificaron protocolos de comunicaciones "cerrados" específicos del producto para interconectar clientes "gordos" con servidores. (Para Encina, el protocolo de comunicaciones era DCE RPC, para MTS era DCOM, etc.) En 1995/96, estos productos tradicionales de servidores de aplicaciones comenzaron a integrar la capacidad básica de comunicación HTTP, primero a través de gateways. Y las líneas comenzaron a difuminarse.

Los servidores web se volvieron más y más maduros con respecto al manejo de mayores cargas, más concurrencia y mejores características. Los servidores de aplicaciones ofrecen cada vez más capacidad de comunicación basada en HTTP.

En este punto, la línea entre "servidor de aplicaciones" y "servidor web" es difusa. Pero las personas continúan usando los términos de manera diferente, como una cuestión de énfasis. Cuando alguien dice "servidor web", a menudo piensas en aplicaciones orientadas a HTTP, UI web, orientadas. Cuando alguien dice "Servidor de aplicaciones" puede pensar "cargas más pesadas, funciones empresariales, transacciones y colas, comunicación multicanal (HTTP + más). Pero a menudo es el mismo producto que cumple con los dos requisitos de carga de trabajo.

  • WebSphere, el "servidor de aplicaciones" de IBM tiene su propio servidor web integrado.
  • WebLogic, otro servidor de aplicaciones tradicional, del mismo modo.
  • Windows, que es el servidor de aplicaciones de Microsoft (además de ser su servidor de archivos e impresoras, servidor de medios, etc.), agrupa IIS.

52
2018-06-01 19:54



Servidor web

correr python -m 'SimpleHTTPServer' E ir a http: // localhost: 8080. Lo que ves es un servidor web en funcionamiento. El servidor simplemente sirve archivos sobre HTTP almacenados en su computadora. El punto clave es que todo esto se hace sobre el protocolo HTTP. También existen servidores FTP, por ejemplo, que hacen exactamente lo mismo (sirviendo archivos almacenados) pero encima de un protocolo diferente.

Servidor de aplicaciones

Digamos que tenemos una aplicación pequeña como la siguiente (fragmento de Matraz)

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

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

El pequeño programa de ejemplo mapea la URL /a la función homepage() y el /abouta la función about().

Para ejecutar este código, necesitamos un servidor de aplicaciones, un programa o módulo que pueda escuchar las solicitudes de un cliente y, al usar nuestro código, devolver algo dinámicamente. En el ejemplo, simplemente devolvemos un HTML muy malo.

¿Cuál es la lógica comercial de la que todas las demás personas hablan? Bueno, dado que una URL se asigna a un lugar específico de nuestra base de código, estamos hipotéticamente demostrando cierta lógica sobre cómo funciona nuestro programa.


Recapping

Servidor web - sirve archivos almacenados en algún lugar (más comúnmente .css, .html, .js). Los servidores web comunes son Apache, Nginx o incluso el servidor SimpleHTTPS de Python.

servidor de aplicaciones - sirve archivos generados sobre la marcha. Básicamente, la mayoría de los servidores web tienen algún tipo de complemento o incluso vienen con funcionalidad incorporada para hacerlo. También existen servidores de aplicaciones estrictas como Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.

Tenga en cuenta que en realidad puede construir un servidor web con el código del servidor de aplicaciones. Esto se hace en algunos casos durante el desarrollo en el que no desea tener una gran cantidad de servidores diferentes ejecutándose en su computadora.


34
2018-02-12 10:56



Como muchos han dicho antes, los servidores web manejan las peticiones HTTP, mientras que los servidores de aplicaciones manejan las peticiones de los componentes distribuidos. Entonces, tal vez la forma más fácil de entender la diferencia es comparar los dos productos en relación con el entorno de programación que ofrecen.

Servidor web -> Entorno de programación

IIS: ASP (.NET)

Tomcat: Servlet

Embarcadero: Servlet

Apache: Php, CGI

Servidores de aplicaciones -> Entorno de programación

MTS: COM +

ERA: EJB

JBoss: EJB

Servidor de aplicaciones WebLogic: EJB

La diferencia crucial es que los servidores de aplicaciones admiten algunos componente distribuido tecnología, que proporciona funciones como la invocación remota y las transacciones distribuidas, como EJB en el mundo de Java o COM + en la plataforma de Microsoft. El servidor Http a menudo admite algunos entornos de programación más simples, a menudo secuencias de comandos, como ASP (.NET) en el caso de Microsoft o Servlet, incluyendo JSP y muchos otros en el caso de Java o PHP y CGI en el caso de Apache.

Otras capacidades como el equilibrio de carga, la agrupación en clúster, la conmutación por error de sesión, la agrupación de conexiones, etc. que solían estar en el ámbito de los servidores de aplicaciones, están ahora disponibles en los servidores web directamente oa través de algunos productos de terceros.

Finalmente, vale la pena señalar que la imagen se distorsiona aún más con "contenedores livianos" como Spring Framework, que a menudo complementan el propósito de los servidores de aplicaciones de una manera más simple y sin la infraestructura del servidor de aplicaciones. Y dado que el aspecto de la distribución en las aplicaciones se está moviendo desde el componente distribuido hacia el paradigma del servicio y la arquitectura SOA, cada vez queda menos espacio para los servidores de aplicaciones tradicionales.


33
2017-11-01 14:26



Un servidor web maneja exclusivamente las solicitudes HTTP / HTTPS. Sirve contenido a la web utilizando el protocolo HTTP / HTTPS.

Un servidor de aplicaciones sirve la lógica de negocios para los programas de aplicaciones a través de cualquier cantidad de protocolos, posiblemente incluyendo HTTP. El programa de aplicación puede usar esta lógica tal como llamaría a un método en un objeto. En la mayoría de los casos, el servidor expone esta lógica comercial a través de una API componente, como el modelo de componente EJB (Enterprise JavaBean) que se encuentra en servidores de aplicaciones Java EE (Java Platform, Enterprise Edition). El punto principal es que el servidor web expone todo a través del protocolo http, mientras que el servidor de aplicaciones no está restringido a él. Por lo tanto, un servidor de aplicaciones ofrece muchos más servicios que un servidor web que generalmente incluye:

  • Una API (patentada o no)
  • Equilibrio de carga, conmutación por error ...
  • Gestión del ciclo de vida de los objetos
  • Gestión estatal (sesión)
  • Gestión de recursos (por ejemplo, grupos de conexión a la base de datos)

La mayoría de los servidores de aplicaciones tienen el Servidor Web como parte integral de ellos, lo que significa que el Servidor de Aplicaciones puede hacer lo que sea que el Servidor Web sea capaz de hacer. Además, App Server tiene componentes y características para admitir servicios de nivel de aplicación como la agrupación de conexiones, la agrupación de objetos, el soporte de transacciones, los servicios de mensajería, etc.

Un servidor de aplicaciones puede (pero no siempre) ejecutarse en un servidor web para ejecutar la lógica del programa, cuyos resultados pueden luego ser entregados por el servidor web. Ese es un ejemplo de un servidor web / escenario de servidor de aplicaciones. Un buen ejemplo en el mundo de Microsoft es la relación Servidor de información de Internet / Servidor de SharePoint. IIS es un servidor web; SharePoint es un servidor de aplicaciones. SharePoint se encuentra "en la parte superior" de IIS, ejecuta una lógica específica y sirve los resultados a través de IIS. En el mundo de Java, hay un escenario similar con Apache y Tomcat, por ejemplo.

Como los servidores web son adecuados para el contenido estático y los servidores de aplicaciones para el contenido dinámico, la mayoría de los entornos de producción tienen un servidor web que actúa como proxy inverso al servidor de la aplicación. Esto significa que, mientras se realiza el servicio, una solicitud de página, el servidor web que interpreta la solicitud sirve contenido estático como imágenes / HTML estático. Utilizando algún tipo de técnica de filtrado (en su mayoría, extensión del recurso solicitado), el servidor web identifica la solicitud de contenido dinámico y reenvía transparentemente al servidor de la aplicación.

Ejemplo de dicha configuración es Apache HTTP Server y BEA WebLogic Server. Apache HTTP Server es Web Server y BEA WebLogic es Application Server. En algunos casos, los servidores están estrechamente integrados, como IIS y .NET Runtime. IIS es un servidor web. cuando está equipado con el entorno de tiempo de ejecución .NET IIS es capaz de proporcionar servicios de aplicaciones


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