usados servidores servidor servers para mas contenedor applications aplicaciones webserver terminology application-server

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



servidores de aplicaciones mas usados (26)

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

Como muchos han dicho antes, los servidores web manejan peticiones HTTP, mientras que los servidores de aplicaciones manejan peticiones para 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 son compatibles con la tecnología de algunos componentes distribuidos , que proporciona características como la invocación remota y las transacciones distribuidas, como EJB en el mundo Java o COM + en la plataforma Microsoft. El servidor HTTP suele admitir algunos entornos de programación más simples, a menudo de 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, agrupación en clústeres, conmutación por error de sesión, agrupación de conexiones, etc. que solían estar en el ámbito de los servidores de aplicaciones, están disponibles en los servidores web también directamente o a través de algunos productos de terceros.

Finalmente, vale la pena señalar que la imagen se distorsiona aún más con "contenedores ligeros" 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 aplicaciones se está moviendo de un componente distribuido a un paradigma de servicio y una arquitectura SOA, cada vez queda menos espacio para los servidores de aplicaciones tradicionales.

Como señalaron Rutesh y jmservera, la distinción es borrosa. Históricamente, fueron diferentes, pero a lo largo de los años 90, estas dos categorías previamente distintas combinaron características y se fusionaron de manera efectiva. En este punto es probablemente 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 del contenido hipervinculado, evolucionó esta cosa llamada "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, lanzando efectivamente un proceso en cada solicitud web para generar contenido dinámico. HTTP también maduró y los productos se hicieron más sofisticados, con funciones de almacenamiento en caché, seguridad y administración. A medida que la tecnología maduraba, obtuvimos la tecnología del lado del servidor basada en Java 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" efectivo para muchos escenarios.

En una categoría paralela, el servidor de aplicaciones había evolucionado y existió durante mucho tiempo. las compañías 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 evolucionó a COM +. La mayoría de estos productos especificaron protocolos de comunicaciones "cerrados" específicos del producto para interconectar clientes "grandes" con servidores. (Para Encina, el protocolo de comunicaciones era DCE RPC; para MTS era DCOM; etc.) En 1995/96, estos productos de servidores de aplicaciones tradicionales comenzaron a integrar la capacidad de comunicación HTTP básica, al principio a través de pasarelas. Y las líneas comenzaron a desdibujarse.

Los servidores web se hicieron cada vez más maduros con respecto al manejo de cargas más altas, más concurrencia y mejores características. Los servidores de aplicaciones entregaron 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 se piensa que las aplicaciones están orientadas a la interfaz de usuario y la interfaz de usuario web. Cuando alguien dice "Servidor de aplicaciones" puede pensar que "cargas más pesadas, características empresariales, transacciones y colas, comunicación multicanal (HTTP + más). Pero a menudo es el mismo producto el que cumple con ambos conjuntos de requisitos de carga de trabajo.

  • WebSphere, el "servidor de aplicaciones" de IBM tiene su propio servidor web integrado.
  • WebLogic, otro servidor de aplicaciones tradicional, igualmente.
  • 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.

Depende de la arquitectura específica. Algunos servidores de aplicaciones pueden usar protocolos web de forma nativa (XML / RPC / SOAP a través de HTTP), por lo que hay poca diferencia técnica. Por lo general, un servidor web está orientado al usuario y sirve una variedad de contenido a través de HTTP / HTTPS, mientras que un servidor de aplicaciones no está orientado al usuario y puede usar protocolos no estándar o no enrutables. Por supuesto, con RIA / AJAX, la diferencia podría estar aún más nublada, ya que solo se ofrece contenido no HTML (JSON / XML) a los clientes que bombean servicios de acceso remoto en particular.

Desde https://en.wikipedia.org/wiki/Web_server

Un servidor web es un sistema informático que procesa solicitudes a través de HTTP, el protocolo de red básico utilizado para distribuir información en la World Wide Web. El término puede referirse a todo el sistema, o específicamente al software que acepta y supervisa las solicitudes HTTP .

Desde https://en.wikipedia.org/wiki/Application_server#Application_Server_definition

Un servidor de aplicaciones se ejecuta detrás de un servidor web (por ejemplo, Apache o Microsoft Internet Information Services (IIS)) y (casi siempre) delante de una base de datos SQL (por ejemplo, PostgreSQL, MySQL u Oracle).

Las aplicaciones web son códigos de computadora que se ejecutan sobre servidores de aplicaciones y están escritos en el (los) idioma (s) que el servidor de aplicaciones admite y llaman a las bibliotecas de tiempo de ejecución y los componentes que ofrece el servidor de aplicaciones .

El servidor de aplicaciones y el servidor web en Java se utilizan para alojar la aplicación web de Java. En la perspectiva Java J2EE, la principal diferencia entre el servidor web y el servidor de aplicaciones es el soporte de EJB. Para ejecutar EJB o alojar el archivo de aplicación Java (.ear) de la empresa, necesita un servidor de aplicaciones como JBoss, WebLogic, WebSphere o Glassfish, mientras que aún puede ejecutar su servlet y JSP o archivo de aplicación web java (.war) dentro de cualquier web Servidor como Tomcat o Jetty. Application Server admite transacciones distribuidas y EJB. Mientras que Web Server solo soporta Servlets y JSP. En términos de diferencia lógica entre el servidor web y el servidor de aplicaciones. Se supone que el servidor web debe proporcionar un servicio de nivel de protocolo http, mientras que el servidor de aplicaciones brinda soporte al servicio web y expone un servicio de nivel empresarial, por ejemplo, EJB.

El servidor de aplicaciones es más pesado que el servidor web en términos de utilización de recursos.

El servidor de aplicaciones y el servidor web se utilizan para alojar aplicaciones web. El servidor web se ocupa del contenedor web, por otro lado, el servidor de aplicaciones se trata del contenedor web y del contenedor EJB (Enterprise JavaBean) o contenedor COM + para Microsoft dot Net.

El servidor web está diseñado para servir contenido HTTP estático como HTML, imágenes, etc. y para el contenido dinámico tiene complementos para admitir lenguajes de script como Perl, PHP, ASP, JSP, etc. y está limitado al protocolo HTTP. A continuación los servidores pueden generar contenido HTTP dinámico.

Entorno de Programación del Servidor Web:

IIS: ASP (.NET)

Apache Tomcat: Servlet

Embarcadero: Servlet

Apache: Php, CGI

Application Server puede hacer lo que Web Server es capaz y escucha utilizando cualquier protocolo, así como App Server tiene componentes y características para admitir servicios de nivel de aplicación, tales como agrupación de conexiones, agrupación de objetos, soporte de transacciones, servicios de mensajería, etc.

Entorno de programación del servidor de aplicaciones:

MTS: COM +

ERA: EJB

JBoss: EJB

Servidor de aplicaciones WebLogic: EJB

En mi opinión, se trata principalmente de separar las preocupaciones.

Desde un punto de vista puramente técnico, puede hacer todo (contenido web + lógica empresarial) en un único servidor web. Si hicieras eso, entonces la información se incrustaría dentro del contenido HTML solicitado. ¿Cuál sería el impacto?

Por ejemplo, imagine que tiene 2 aplicaciones diferentes que representan contenido HTML completamente diferente en el navegador. Si separara la lógica de negocios en un servidor de aplicaciones, podría proporcionar diferentes servidores web que busquen los mismos datos en el servidor de aplicaciones mediante scripts. Sin embargo, si no separara la lógica y la mantuviera en el servidor web, cada vez que cambie su modelo de negocio, terminará cambiándola en cada servidor web que tenga, lo que llevaría más tiempo, sería menos confiable y propenso a errores.

En realidad, Apache es un servidor web y Tomcat es un servidor de aplicaciones. Cuando como solicitud HTTP llega al servidor web. Luego los contenidos estáticos se envían de vuelta al navegador por el servidor web. ¿Hay y hay que hacer la lógica? Entonces, esa solicitud se envía al servidor de aplicaciones. después de procesar la lógica, envíe la respuesta al servidor web y envíela al cliente.

En resumen, un servidor web es un servidor que sirve páginas web a los usuarios a través de http. Un servidor de aplicaciones es un servidor que aloja la lógica empresarial de un sistema. A menudo aloja procesos de larga ejecución / por lotes y / o servicios de interoperabilidad no destinados al consumo humano (servicios REST / JSON, SOAP, RPC, etc.).

En términos de Java hay uno más: contenedor web (o más estrictamente, contenedor de servlets). Es, digamos, entre el servidor web y el servidor de aplicaciones. Un contenedor web en términos de Java es un servidor de aplicaciones que, básicamente, solo implementa la parte JSP / Servlet de Java EE y carece de varias partes centrales de Java EE, como el soporte EJB. Un ejemplo es Apache Tomcat.

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

El 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 maneja varios protocolos diferentes, incluidos, 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 funciona junto con el servidor web, donde se muestra uno y el otro interactúa.

La información que viaja de un lado a otro entre el servidor y su cliente no está restringida al 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 en los que un servidor de aplicaciones funciona con el servidor web en comparación con 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

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 (sea paciente, le explicaré esto en nuestro próximo nugget) y espera una respuesta. Una vez recibido, el servidor web formula la respuesta en un archivo HTML y la 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 realizó anteriormente 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 tener que enviar otra consulta duplicada al servidor de la base de datos. El servidor actúa básicamente como un intermediario entre el servidor de 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", esto no es un proceso reutilizable. Un segundo cliente deberá solicitar la información nuevamente y recibir otra página HTML incrustada con la información solicitada, que es altamente ineficiente. Sin mencionar que este tipo de servidor es muy flexible debido a su capacidad para administrar sus propios recursos, incluidos 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 integrada, 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.

La frontera entre estos dos se está volviendo cada vez más delgada.

Los servidores de aplicaciones exponen la lógica empresarial a un cliente. Así que su servidor de aplicaciones similares se compone de un conjunto de métodos (aunque no necesariamente, incluso puede ser una computadora en red que permite que muchos ejecuten software en él) para realizar la lógica empresarial. Así que simplemente generará los resultados deseados, no el contenido HTML. (similar a una llamada de método). Así que no es estrictamente basado en HTTP.

Pero los servidores web pasan el contenido HTML a los navegadores web (estrictamente basados ​​en HTTP). Los servidores web eran capaces de manejar solo los recursos web estáticos, pero la aparición de scripts del lado del servidor ayudó a los servidores web a manejar contenidos dinámicos también. Donde el servidor web toma la solicitud y la dirige a la secuencia de comandos (PHP, JSP, secuencias de comandos CGI, etc.) a CREAR contenido HTML para enviar al cliente. Entonces el servidor web sabe cómo enviarlos de vuelta al cliente. PORQUE eso es lo que un servidor web realmente sabe.

Dicho esto, hoy en día los desarrolladores usan ambos juntos. Cuando el servidor web toma la solicitud y luego llama a un script para crear el HTML, el script BUT llamará nuevamente a un servidor de aplicaciones LÓGICA (por ejemplo, Recuperar detalles de la transacción) para completar el contenido HTML.

Así que en este caso los dos servidores fueron utilizados efectivamente.

Por lo tanto ... Podemos decir con bastante seguridad que en la actualidad, en la mayoría de los casos, los servidores web se utilizan como un subconjunto de servidores de aplicaciones. PERO teatralmente NO es el caso.

He leído muchos artículos sobre este tema y he encontrado this artículo muy útil.

La mayor diferencia es que un servidor web maneja las solicitudes HTTP, mientras que un servidor de aplicaciones ejecutará la lógica empresarial en cualquier número de protocolos.

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

Las siguientes son algunas de las diferencias clave en las características de Web Server y Application Server:

  • El servidor web está diseñado para servir contenido HTTP. El servidor de aplicaciones también puede servir contenido HTTP, pero no se limita 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. mediante los cuales estos servidores pueden generar contenido HTTP dinámico.
  • La mayoría de los servidores de aplicaciones tienen Web Server como parte integral de ellos, lo que significa que App Server puede hacer lo que Web Server sea capaz de hacer. Además, el servidor de aplicaciones 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 muy 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 de proxy inverso al servidor de aplicaciones. Eso significa que mientras se atiende una solicitud de página, el servidor web que interpreta la solicitud sirve contenidos estáticos (como imágenes / HTML estático). El uso de algún tipo de técnica de filtrado (en su mayoría extensión del recurso solicitado) servidor web identifica la solicitud de contenido dinámico y reenvía de forma transparente al servidor de aplicaciones

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 el entorno de ejecución .NET, IIS es capaz de proporcionar servicios de aplicación.

La principal diferencia entre el servidor web y el servidor de aplicaciones es que el servidor web está destinado a servir páginas estáticas, por ejemplo, HTML y CSS, mientras que el servidor de aplicaciones es responsable de generar contenido dinámico ejecutando el código del lado del servidor, por ejemplo, JSP, Servlet o EJB.

¿Cuál debo usar?
Una vez que sepa la diferencia entre la web y el servidor de aplicaciones y los contenedores web, es fácil darse cuenta de cuándo usarlos. Necesita un web server como Apache HTTPD si está sirviendo páginas web estáticas. Si tiene una aplicación Java con solo JSP y Servlet para generar contenido dinámico, necesita web containers como Tomcat o Jetty. Mientras tanto, si tiene una aplicación Java EE que utiliza EJB, transacciones distribuidas, mensajería y otras características sofisticadas , necesita un application server completo como JBoss, WebSphere u WebLogic de Oracle.

El contenedor web forma parte del servidor web y el servidor web forma parte del servidor de aplicaciones.

El servidor web está compuesto por un contenedor web, mientras que el servidor de aplicaciones está compuesto por un contenedor web y un contenedor EJB.

No hay necesariamente una línea divisoria clara. Hoy en día, muchos programas combinan elementos de ambos: el servicio de solicitudes http (servidor web) y el manejo de la lógica empresarial (servidor de aplicaciones)

Normalmente, un servidor de aplicaciones está diseñado e implementado para facilitar procesos de ejecución más prolongados que también requerirán más recursos.

Un servidor web se usa para ráfagas cortas que generalmente no requieren muchos recursos. Esto es principalmente para facilitar el servicio de tráfico basado en web.

Por un lado, un servidor web sirve contenido web (HTML y contenido estático) a través del protocolo HTTP. Por otro lado, un servidor de aplicaciones es un contenedor en el que puede construir y exponer la lógica y los procesos empresariales a las aplicaciones cliente a través de varios protocolos, incluido HTTP en una arquitectura de n niveles.

Por lo tanto, un servidor de aplicaciones ofrece muchos más servicios que un servidor web que normalmente incluye:

  • Una API (propietaria o no)
  • Gestión del ciclo de vida del objeto,
  • Gestión del Estado (sesión),
  • Gestión de recursos (por ejemplo, grupos de conexión a base de datos),
  • Equilibrio de carga, conmutación por error ...

AFAIK, ATG Dynamo fue uno de los primeros servidores de aplicaciones a finales de los 90 (según la definición anterior). A principios de 2000, fue el reinado de algunos servidores de aplicaciones propietarios como ColdFusion (CFML AS), BroadVision (servidor de JavaScript del lado del servidor), etc. Pero ninguno realmente sobrevivió a la era del servidor de aplicaciones Java.

Por un lado, un servidor web sirve contenido web (HTML y contenido estático) a través del protocolo HTTP. Por otro lado, un servidor de aplicaciones es un contenedor en el que puede construir y exponer la lógica y los procesos empresariales a las aplicaciones cliente a través de varios protocolos, incluido HTTP en una arquitectura de n niveles.

Por lo tanto, un servidor de aplicaciones ofrece muchos más servicios que un servidor web que normalmente incluye:

  • Una API (propietaria o no)
  • Gestión del ciclo de vida del objeto,
  • Gestión del Estado (sesión),
  • Gestión de recursos (por ejemplo, grupos de conexión a base de datos),
  • Equilibrio de carga, conmutación por error

Si bien puede haber superposiciones entre los dos (algunos servidores web pueden incluso utilizarse como servidores de aplicaciones), la mayor diferencia es el modelo de procesamiento y la gestión de la sesión:

En el modelo de procesamiento de servidor web, el enfoque está en el manejo de solicitudes; la noción de "sesión" es prácticamente virtual. Es decir, la "sesión" se simula transfiriendo la representación del estado entre el cliente y el servidor (por lo tanto, REST) ​​y / o serializándola a un almacenamiento externo persistente (SQL Server, Memcached, etc.).

En el servidor de aplicaciones, la sesión suele ser más explícita y, a menudo, toma la forma de un objeto que vive en la memoria del servidor de aplicaciones durante toda la duración de la "sesión".

Todo lo anterior es solo una complicación excesiva de algo muy simple. Un servidor de aplicaciones contiene un servidor web, un servidor de aplicaciones solo tiene un par de adiciones / extensiones más que los servidores web estándar. Si nos fijamos en TomEE como ejemplo:

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

Verá que Tomcat (contenedor / servidor web) es solo otra herramienta del arsenal de servidores de aplicaciones. También puede obtener JPA y la otra tecnología en el servidor web si lo desea, pero los servidores de aplicaciones solo empaquetan todas estas cosas para su conveniencia. Para ser clasificado como un servidor de aplicaciones, esencialmente debe cumplir con una lista de herramientas establecidas por algún estándar.

Un servidor de aplicaciones es una máquina (un proceso ejecutable que se ejecuta en alguna máquina, en realidad) que "escucha" (en cualquier canal, usando cualquier protocolo), para las solicitudes de los clientes para cualquier servicio que proporcione, y luego hace algo basado en esas solicitudes. (puede o no implicar una respuesta al cliente)

Un servidor web es un proceso que se ejecuta en una máquina que "escucha" específicamente en el canal TCP / IP usando uno de los protocolos de "internet" (http, https, ftp, etc.) y hace lo que hace según las solicitudes entrantes. .. En general, (como se definió originalmente), recuperó / generó y devolvió una página web html al cliente, ya sea recuperada de un archivo html estático en el servidor, o se construyó dinámicamente en función de los parámetros en la solicitud del cliente entrante.

Un servidor web ejecuta el protocolo HTTP para servir páginas web. Un servidor de aplicaciones puede ejecutarse (pero no siempre) en un servidor web para ejecutar la lógica del programa, cuyos resultados pueden 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 entre Internet Information Server y SharePoint Server. IIS es un servidor web; SharePoint es un servidor de aplicaciones. SharePoint se encuentra "encima" de IIS, ejecuta una lógica específica y entrega los resultados a través de IIS.

En el mundo Java, hay un escenario similar con Apache y Tomcat, por ejemplo.

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 empresarial a los programas de aplicaciones a través de cualquier número 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 de negocios a través de una API de componentes, como el modelo de componentes EJB (Enterprise JavaBean) que se encuentra en los 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 normalmente incluye:

  • Una API (propietaria o no)
  • Equilibrio de carga, conmutación por error ...
  • Gestión del ciclo de vida del objeto.
  • Gestión del estado (sesión)
  • Gestión de recursos (por ejemplo, grupos de conexión a base de datos)

La mayoría de los servidores de aplicaciones tienen Web Server como parte integral de ellos, lo que significa que App Server puede hacer lo que Web Server sea capaz de hacer. Además, el servidor de aplicaciones 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 ejecutarse (pero no siempre) en un servidor web para ejecutar la lógica del programa, cuyos resultados pueden 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 entre Internet Information Server y SharePoint Server. IIS es un servidor web; SharePoint es un servidor de aplicaciones. SharePoint se encuentra "encima" de IIS, ejecuta una lógica específica y entrega los resultados a través de IIS. En el mundo Java, hay un escenario similar con Apache y Tomcat, por ejemplo.

Como los servidores web son muy 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 de proxy inverso al servidor de aplicaciones. Eso significa que, al atender una solicitud de página, el servidor web que interpreta la solicitud sirve contenidos estáticos como imágenes / html estático. El uso de algún tipo de técnica de filtrado (en su mayoría extensión del recurso solicitado) del servidor web identifica la solicitud de contenido dinámico y la reenvía de forma transparente al servidor de aplicaciones.

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 un entorno de ejecución .NET, IIS es capaz de proporcionar servicios de aplicación

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+

Servidor web

Ejecute python -m ''SimpleHTTPServer'' y vaya a http: // localhost: 8080 . Lo que se ve es un servidor web en su funcionamiento. El servidor simplemente sirve archivos sobre HTTP almacenados en su computadora. El punto clave es que todo esto se realiza sobre el protocolo HTTP. También existen servidores FTP, por ejemplo, que hacen exactamente lo mismo (servir archivos almacenados) pero sobre un protocolo diferente.

Servidor de aplicaciones

Digamos que tenemos una pequeña aplicación como la de abajo (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 homepage() la función homepage() y la /about a 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, utilizando nuestro código, devuelva algo de forma dinámica. En el ejemplo simplemente devolvemos un código HTML muy malo.

¿De qué lógica de negocios hablan todas las demás personas? Bueno, dado que una URL se asigna a algún lugar específicamente en nuestro código base, hipotéticamente estamos mostrando algo de lógica acerca de cómo funciona nuestro programa.

Recapitulación

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. Esencialmente, la mayoría de los servidores web tienen algún tipo de complementos o incluso vienen con una funcionalidad integrada para hacer eso. También existen servidores de aplicaciones estrictos como Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.

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

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

  • Servidor web : sirve contenido a la web utilizando 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 casos, encontrará que el servidor web se está utilizando para crear el extremo frontal 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.