¿Cuál es la diferencia entre servidor de aplicaciones y servidor web?
¿Cuál es la diferencia entre servidor de aplicaciones y servidor web?
La mayoría de las veces, estos términos servidor web y servidor de aplicaciones se utilizan indistintamente.
A continuación se detallan algunas de las diferencias clave en las características del servidor web y el servidor de aplicaciones:
- El servidor web está diseñado para servir contenido HTTP. App Server también puede servir contenido HTTP, pero no se limita solo a HTTP. Se puede proporcionar soporte para otros protocolos como RMI/RPC.
- El servidor web está diseñado principalmente para ofrecer contenido estático, aunque la mayoría de los servidores web tienen complementos para admitir lenguajes de secuencias de comandos 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 todo lo que el servidor web es capaz de hacer. Además, App Server tiene componentes y características para admitir servicios a nivel de aplicación, como agrupación de conexiones, agrupación de objetos, soporte de transacciones, servicios de mensajería, etc.
- Como los servidores web son adecuados para contenido estático y los servidores de aplicaciones para contenido dinámico, la mayoría de los entornos de producción tienen un servidor web que actúa como proxy inverso del servidor de aplicaciones. Eso significa que, al atender una solicitud de página, el servidor web que interpreta la solicitud entrega contenidos estáticos (como imágenes/HTML estático). Utilizando algún tipo de técnica de filtrado (principalmente extensión del recurso solicitado), el servidor web identifica la solicitud de contenido dinámico y la reenvía de forma transparente al servidor de aplicaciones.
Un ejemplo de dicha configuración es el servidor HTTP Apache Tomcat y el servidor WebLogic de Oracle (anteriormente BEA). El servidor HTTP Apache Tomcat es un servidor web y Oracle WebLogic es un 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 un entorno de ejecución .NET, IIS es capaz de proporcionar servicios de aplicaciones.
Esta es una respuesta detallada con algunos escenarios para comprender claramente la diferencia y la similitud, y cómo ambas pueden funcionar en conjunto.
Servidor de aplicaciones es un término que en ocasiones se mezcla con servidor web . Mientras que un servidor web maneja principalmente protocolos HTTP , el servidor de aplicaciones maneja varios protocolos diferentes, incluido, entre otros, HTTP .
El trabajo principal del servidor web es mostrar el contenido del sitio y el servidor de aplicaciones está a cargo de la lógica , la interacción entre el usuario y el contenido mostrado. El servidor de aplicaciones trabaja en conjunto con el servidor web, donde uno muestra y el otro interactúa.
La información que viaja de un lado a otro entre el servidor y su cliente no se limita a un simple marcado de visualización, sino a la interacción entre los dos.
En la mayoría de los casos, el servidor crea esta interacción a través de un componente API , como J2EE (Java 2 Platform) , EJB (Enterprise JavaBean) y otros modelos de software de aplicación diferentes.
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 servidor de aplicaciones
tienes una tienda online con sólo un servidor web y sin servidor de aplicaciones. El sitio proporcionará una pantalla donde podrá 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 el próximo artículo) y espera una respuesta. Una vez recibida, 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 la 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 realizó anteriormente y no se han modificado 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 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 tendrá que solicitar la información nuevamente y recibirá otra página HTML incrustada con la información solicitada, lo cual es altamente ineficiente. Sin mencionar que este tipo de servidor es muy flexible debido a su capacidad para administrar sus propios recursos, incluida la seguridad, el procesamiento de transacciones, la mensajería y la agrupación de recursos.
Para soportar tal variedad de tareas complejas, este servidor debe tener redundancia incorporada, gran potencia de procesamiento y una gran cantidad de RAM para manejar todos los datos que extrae en tiempo real.
Ambos términos son muy genéricos, uno contiene al otro y viceversa en algunos casos.
Servidor web : sirve contenido a la web mediante el protocolo http.
Servidor de aplicaciones : aloja y expone procesos y lógica empresarial.
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 utiliza para crear el front-end del servidor de aplicaciones, es decir, expone un conjunto de páginas web que permiten al usuario interactuar con las reglas comerciales que se encuentran en el servidor de aplicaciones.
Servidor web
Ejecute python -m 'SimpleHTTPServer'y vaya a http://localhost:8080 . Lo que ves es un servidor web en funcionamiento. El servidor simplemente sirve archivos a través de 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 (servir archivos almacenados) pero con un protocolo diferente.
Servidor de aplicaciones
Digamos que tenemos una pequeña aplicación como la siguiente (fragmento de Flask ).
@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 asigna la URL /a la función homepage()y /abouta la función about().
Para ejecutar este código necesitamos un servidor de aplicaciones (por ejemplo, Gunicorn): un programa o módulo que puede escuchar las solicitudes de un cliente y, utilizando nuestro código, devolver algo dinámicamente. En el ejemplo simplemente devolvemos HTML muy malo.
¿Cuál es la lógica empresarial de la que habla toda la gente? Bueno, dado que una URL se asigna a algún lugar específico de nuestro código base, hipotéticamente estamos mostrando cierta lógica sobre cómo funciona nuestro programa.
Recapitulando
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 SimpleHTTPServer 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 una funcionalidad incorporada para hacerlo. También existen servidores de aplicaciones estrictos como Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.
Tenga en cuenta que en realidad puede crear un servidor web con el código del servidor de aplicaciones. Esto se hace en algunos casos durante el desarrollo en los que no desea tener millones de servidores diferentes ejecutándose en su computadora.
Como señalaron Rutesh y jmservera, la distinción es confusa. Históricamente, eran diferentes, pero a lo largo de los años 90 estas dos categorías previamente distintas combinaron características y se fusionaron efectivamente. 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 con hipervínculos, evolucionó algo llamado "servidor web" que servía contenido e imágenes de páginas web a través de HTTP. La mayor parte 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 capacidad CGI, lanzando 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 almacenamiento en caché, seguridad y administración. A medida que la tecnología maduró, obtuvimos tecnología del lado del servidor basada en Java específica de la empresa de Kiva y NetDynamics, que finalmente se fusionaron en JSP. Microsoft añadió 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 ha evolucionado y existe desde hace mucho tiempo. Las empresas entregaron productos para Unix como Tuxedo, TopEnd, Encina que se derivaban filosóficamente de entornos de monitoreo y gestión de aplicaciones Mainframe como IMS y CICS. La oferta de Microsoft fue Microsoft Transaction Server (MTS), que luego evolucionó a COM+. La mayoría de estos productos especificaban protocolos de comunicación "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 de servidor de aplicaciones tradicionales comenzaron a incorporar capacidad de comunicación HTTP básica, al principio a través de puertas de enlace. Y las líneas comenzaron a desdibujarse.
Los servidores web se volvieron cada vez más maduros con respecto al manejo de cargas más altas, más concurrencia y mejores funciones. Los servidores de aplicaciones ofrecieron 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 confusa. Pero la gente sigue usando los términos de manera diferente, como una cuestión de énfasis. Cuando alguien dice "servidor web", a menudo piensa en aplicaciones orientadas a la interfaz de usuario web y centradas en HTTP. Cuando alguien dice "servidor de aplicaciones", puede pensar en "cargas más pesadas, funciones empresariales, transacciones y colas, comunicación multicanal (HTTP y más). Pero a menudo es el mismo producto el que satisface ambos conjuntos de requisitos de carga de trabajo".
- WebSphere, el "servidor de aplicaciones" de IBM, tiene su propio servidor web incluido.
- WebLogic, otro servidor de aplicaciones tradicional, también.
- Windows, que es el servidor de aplicaciones de Microsoft (además de ser su servidor de archivos e impresión, servidor de medios, etc.), incluye IIS.
