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

Permítanme comenzar diciendo que he usado servidores web desde 1994 más o menos, y servidores de aplicaciones desde 1998 más o menos.

• Un servidor de aplicaciones suele ser un superconjunto de un servidor web, lo que quiere decir que un servidor de aplicaciones puede hacer lo que hace un servidor web (es decir, responder solicitudes de socket HTTP en el puerto 80 y solicitudes de socket HTTPS en el puerto 443).
• Los servidores web son generalmente muy expansibles, por medio de API como CGI, fast-cgi, ISAPI, NSAPI y miles de variaciones modernas de los mismos. En otras palabras, los servidores web admiten la extensión programática y, como tales, son técnicamente capaces de alojar casi cualquier aplicación.
• Mientras que los servidores web están básicamente centrados en archivos (son servidores de archivos que soportan HTTP en lugar de SMB o CIFS), los servidores de aplicaciones están centrados en aplicaciones . Esto tiende a implicar: administración de aplicaciones (incluyendo ciclo de vida, seguridad, monitoreo, etc.), empaquetado de aplicaciones y soporte de (re) implementación, y servicios de tiempo de ejecución de aplicaciones.
• Los servicios de tiempo de ejecución afectan dramáticamente la forma en que uno construye una aplicación. Por ejemplo, en Java EE, hay formas estándar en que los componentes de la aplicación administran transacciones, acceden a fuentes de datos (incluida la funcionalidad de agrupación de conexiones), envían y reciben mensajes, manejan solicitudes HTTP entrantes, administran sesiones de usuario, autentican y autorizan el acceso a recursos, etc. .
• En Java EE, también hay una definición formal de empaque y despliegue, que permite que los componentes y bibliotecas del lado del servidor construidos de forma independiente y separada se unan en una sola unidad de despliegue. La mayoría de los servidores de aplicaciones admiten la implementación (y la posterior implementación) de dicha aplicación, incluso en un clúster de servidores en ejecución.
• Las organizaciones han invertido mucho en herramientas y automatización en torno a plataformas de servidores de aplicaciones, incluida la integración con sus estándares de seguridad de toda la empresa; auditoría y recopilación automatizada de registros; políticas de actualización, copia de seguridad y retención de datos; esfuerzos de privacidad, internacionalización, localización y accesibilidad; virtualización, aprovisionamiento e infraestructura de escalamiento horizontal; y, por supuesto, la base de conocimiento y las prácticas de desarrollo de aplicaciones en sí mismas, lo que significa que incluso cuando un servidor de aplicaciones puede ser técnicamente “sobre-matado” para una aplicación en particular, aún puede ser más rentable y menor riesgo de uso porque de las otras inversiones “hundidas”.

Al igual que con cualquier estandarización o “servicio de nivel superior”, todo lo que es posible con un servidor de aplicaciones se puede construir sin un servidor de aplicaciones. La verdadera pregunta es si los beneficios de las capacidades integradas de un servidor de aplicaciones (y el efecto de red de otras herramientas e infraestructura en las que las organizaciones han invertido) superan los costos; Para la mayoría de las empresas, la respuesta ha sido “sí”.

En aras de la divulgación total, trabajo en Oracle, incluso en los servidores web iPlanet y OHS, la plataforma Java EE y en los servidores de aplicaciones WebLogic y Glassfish. Las opiniones y opiniones expresadas en esta publicación son mías y no reflejan necesariamente las opiniones u opiniones de mi empleador.

Servidor de aplicaciones y servidor web

• Ambos términos son muy genéricos, uno 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 empresariales.
  En la perspectiva Java J2EE, la principal diferencia entre el servidor web y el servidor de aplicaciones es el soporte de EJB (Enterprise Java Beans). Para ejecutar EJB o hospedar el archivo de aplicación Java empresarial (.ear) 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.

1) Application Server admite transacciones distribuidas y EJB. Mientras que Web Server solo admite Servlets y JSP.
2) Application Server puede contener un servidor web en ellos. La mayoría del servidor de aplicaciones, por ejemplo, JBoss o WAS, tiene servlet y contenedor JSP.
3) Aunque no se limita al servidor de aplicaciones, solía proporcionar servicios como agrupación de conexiones, gestión de transacciones, mensajería, agrupación, equilibrio de carga y persistencia. Ahora Apache tomcat también proporciona agrupación de conexiones.

4) En términos de diferencia lógica entre el servidor web y el servidor de aplicaciones. se supone que el servidor web proporciona un servicio de nivel de protocolo http, mientras que el servidor de aplicaciones brinda soporte al servicio web y expone el servicio de nivel empresarial, por ejemplo, EJB.
5) El servidor de aplicaciones es más pesado que el servidor web en términos de utilización de recursos.

6. El modelo de delegación del servidor web es bastante simple, cuando la solicitud llega al servidor web, simplemente pasa la solicitud al programa que mejor pueda manejarla (programa del lado del servidor). Es posible que no admita transacciones y agrupaciones de conexiones de bases de datos. Los servidores web admiten la implementación de archivos .war solo mientras que los servidores de aplicaciones admiten la implementación de archivos .war y .ear. El servidor de aplicaciones tiene más capacidad de comportamiento dinámico que el servidor web . Se puede configurar un servidor de aplicaciones para que funcione como servidor web.

Se puede decir que un servidor web es un subconjunto de un servidor de aplicaciones. Los servidores de aplicaciones y los servidores web están empezando a difuminarse entre sí con la expansión de los recursos e información de las tecnologías de Internet y tecnología web 2.0. Actualmente, en la mayoría de los casos, el software se aloja en servidores web y luego se descarga en el disco duro local, donde se instala en la computadora local. En el nuevo modelo que fusiona el servidor web y el servidor de aplicaciones, el software se alojaría en línea y el usuario podría acceder a él y usarlo según sea necesario, generalmente, a una tasa menor que si comprara el software nuevo.

Un servidor web (programa) tiene límites de carga definidos, porque puede manejar solo un número limitado de conexiones concurrentes de clientes (generalmente entre 2 y 60,000, por defecto entre 500 y 1,000) por dirección IP (y puerto IP) y solo puede servir un cierto número máximo de solicitudes por segundo. Por otro lado, un servidor de aplicaciones tiene una capacidad mucho mayor.

El servidor web no admite el concepto de subprocesamiento múltiple. En Application Server tenemos características como agrupación de conexiones, agrupación de aislamiento, subprocesamiento múltiple y, principalmente, la característica de transacción que no está presente en el servidor web.
Se supone que los servidores web (programas) atienden solicitudes rápidamente desde más de una conexión TCP / IP a la vez. Considere que Internet Explorer o Firefox Web Browser es un programa local en el disco duro del usuario, mientras que las páginas web no lo son. Las páginas web se almacenan en los discos duros de otras computadoras, y estos se conocen como servidores web. Los productos de servidor de aplicaciones generalmente incluyen middleware para permitir que las aplicaciones se comuniquen con aplicaciones dependientes, como servidores web, sistemas de administración de bases de datos y programas de gráficos.

Un ejemplo:
La mejor manera de comprender la diferencia entre los escenarios en los que un servidor de aplicaciones funciona con el servidor web frente a un escenario en el que 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 sin 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, 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 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 ha realizado anteriormente y no ha cambiado ningún dato 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 un intermediario entre el servidor de la base de datos y el servidor web. Esto permite que la información obtenida 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 incrustada en HTML con la información solicitada, muy 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 admitir una variedad de tareas complejas, este servidor debe tener una redundancia incorporada, una gran potencia de procesamiento y una gran cantidad de RAM para manejar todos los datos que extrae en tiempo real.

(esta respuesta se recopila de varias fuentes)

Esta es una de las preguntas que había estado haciendo desde el principio en mis primeros días de desarrollo web. Obtuve muchas respuestas de muchas fuentes, pero a la mayoría de ellas les faltaba algo o algo malo. Todavía no he leído una distinción estándar concisa entre los dos, pero esto es según mi comprensión de las cosas en los pequeños años de trabajo en los que he estado.

Respuesta técnica

Por lo tanto, un servidor web para comenzar es cualquier fuente que proporcione un servicio en un modelo basado en cliente-servidor, generalmente a través del protocolo HTTP. La única y completa tarea del servidor web es escuchar continuamente las solicitudes entrantes y comprender los detalles de la solicitud según el conocimiento del protocolo (HTTP) y enviar la respuesta nuevamente, nuevamente con los detalles del protocolo.

Cómo y desde dónde se calcula esta respuesta tiene que ser la comprensión de la otra aplicación, que se encarga de abrir y leer archivos, hacer conexiones a la base de datos, ejecutar algoritmos y hacer todo eso para comprender los detalles e implicaciones de la plataforma de programación. Esta parte o módulo o motor calcula la respuesta y hace toda la parte difícil y se comunica con el servidor web para el envío. Esencialmente, esto no necesita ser un servidor, sino un motor computacional solo. Pero más a menudo termina siendo un servidor para coordinar con el servidor web de encabezado frontal.

La respuesta del laico

Imagina que vas a tu tienda favorita. El operador del cliente que toma su pedido, lo registra en el sistema, lo factura y se lo envía cuando el pedido está listo es análogo al servidor web. Continuamente toma las solicitudes de nuevos clientes y sigue enviando los pedidos preparados, opcionalmente envolviéndolos en paquetes decorados o en platos.

Al mismo tiempo, el chico envía estas solicitudes a la cocina principal, donde toda la parte difícil de preparar la pizza se hace con el conocimiento de la receta, los ingredientes, los tiempos de cocción y otros detalles, y envía la pizza preparada.
Por lo tanto, la cocina principal tiene la responsabilidad tanto de solicitar el despacho (aunque con complejidad limitada) como de hacer la parte difícil de preparar la pizza. Entonces, actúa como el servidor de aplicaciones.

Ambos términos a menudo se usan indistintamente y la distinción se ha vuelto borrosa con el tiempo. Pero hay algunas diferencias clave entre ambos

• La mayoría de los servidores de aplicaciones tienen un servidor web en su núcleo. Pero los servidores de aplicaciones también vienen con otras características como agrupación de conexiones, colas de mensajes, etc. Esto no es parte de los servidores web.
• Un servidor web está diseñado para servir contenido HTTP, mientras que un servidor de aplicaciones puede hacer mucho más. También puede servir contenido sobre RPC / RMI.
• Aunque los servidores web se diseñaron inicialmente para servir solo contenido estático, como imágenes y archivos javascript, en la actualidad, la mayoría de los servidores web tienen complementos que les permiten servir contenido dinámico usando PHP, Perl, etc. Los servidores de aplicaciones siempre tuvieron la intención de servir contenido dinámico. La lógica de negocios para las empresas.

Dicho esto, a menudo puedes usar uno u otro para servir tu contenido. Pero, cuando las personas citan servidores web, generalmente piensan en protocolos HTTP y contenido de IU. Cuando citan servidores de aplicaciones, generalmente piensan en una lógica comercial pesada con colas de mensajes, beans, computación distribuida, etc.

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 solo a 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 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 Web Server como parte integral de ellos, lo que significa que App Server puede hacer lo que sea que sea capaz de hacer. Además, el servidor de aplicaciones tiene componentes y características para admitir servicios de 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 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 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). Al usar 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 el entorno de tiempo de ejecución .NET, IIS es capaz de proporcionar servicios de aplicaciones.

Existen algunas diferencias básicas entre el servidor de aplicaciones y el servidor web. Echa un vistazo a los detalles a continuación.

1. El servidor web está destinado a servir contenido de protocolo de comunicaciones (HTTP). El servidor de aplicaciones puede servir contenido de protocolo de comunicaciones (HTTP), sin embargo, no se limita al simple protocolo de comunicaciones. Se puede proporcionar soporte de protocolo alternativo como RMI / RPC
2. El servidor web generalmente está diseñado para servir contenido estático, aunque la mayoría de los servidores de Internet tienen complementos para admitir lenguajes de script como Perl, PHP, ASP, JSP, etc. a través de los cuales estos servidores generarán contenido de protocolo de comunicaciones dinámicas.
3. La mayoría de los servidores de dispositivos tienen un servidor de Internet como parte integral de ellos, lo que significa que App Server hará lo que sea que el servidor de Internet sea capaz de hacer. Además, App Server tiene partes y opciones para admitir servicios de nivel de aplicación como agrupación de asociaciones, agrupación de objetos, soporte de negociación, servicios de mensajería electrónica, etc.
4. Como los servidores de Internet están bien adaptados para el contenido estático y los servidores de aplicaciones para contenido dinámico, la mayoría de los entornos de ensamblaje tienen un servidor de Internet que actúa como proxy inverso al servidor de aplicaciones. lo que significa que, al acoplar una solicitud de página, los contenidos estáticos (como imágenes / HTML estático) son servidos por un servidor de Internet que interpreta la solicitud. la explotación alguna técnica de filtrado bastante (principalmente extensión del recurso solicitado) el servidor de Internet identifica la solicitud de contenido dinámico y la reenvía de forma transparente al servidor de aplicaciones

Servidor web
Un servidor web maneja un protocolo HTTP. Cuando una solicitud HTTP llega al servidor web, responde al cliente o al solicitante con una respuesta HTTP, que puede ser una página HTML que el navegador puede representar o una imagen o una redirección a otra página o puede delegar la solicitud a alguna aplicación interna, obtener respuesta de ella y enviarla de vuelta al cliente y esta aplicación interna puede ser un Servidor de aplicaciones .
El servidor web no proporciona ninguna funcionalidad más allá de simplemente proporcionar un entorno en el que el programa del lado del servidor puede ejecutar y devolver las respuestas generadas. El programa del lado del servidor generalmente proporciona funciones tales como el procesamiento de transacciones, la conectividad de la base de datos y la mensajería.
Si bien un servidor web puede no ser compatible con las transacciones o la agrupación de conexiones de la base de datos, puede emplear varias estrategias para la tolerancia a fallas (como la redirección) y la escalabilidad, como el equilibrio de carga, el almacenamiento en caché y la agrupación, características que a menudo se asignan erróneamente como funciones reservadas solo para la aplicación servidores Ahora pasemos al servidor de aplicaciones.
Pocos de los famosos productos de Web Server son IBM http Server, JBoss, Oracle iPlanet, Apache. Servidor de aplicaciones
En una aplicación J2EE, “Servidor de aplicaciones” es la aplicación de nivel medio que ejecuta la lógica de negocios y admite transacciones distribuidas. El servidor de aplicaciones es el intermediario entre las bases de datos de front-end y back-end basadas en navegador y los sistemas heredados donde el servidor web actúa como delegador del servidor de aplicaciones.
El servidor de aplicaciones expone la lógica empresarial a través de un componente API, como el modelo de componente EJB (Enterprise JavaBean) que se encuentra en los servidores de aplicaciones J2EE (Java 2 Platform, Enterprise Edition). Además, el servidor de aplicaciones gestiona sus propios recursos. Esas tareas de mantenimiento de la puerta incluyen seguridad, procesamiento de transacciones, agrupación de recursos y mensajería. El punto a recordar es que el servidor web por sí solo nunca puede ejecutar un EJB.
Pocos de los sabores de Application Server conocidos son Tomcat, Weblogic e IBM Websphere.
Para leer más sobre esto visite: http://gettingstartedon.com/diff …

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 mediante la ejecución de código lateral del servidor, por ejemplo, JSP, Servlet o EJB.

¿Cuál debería usar?
Una vez que sepa la diferencia entre el servidor web y de aplicaciones y los contenedores web, es fácil determinar 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, entonces necesita web containers como Tomcat o Jetty. Si bien, 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 o WebLogic de Oracle.

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

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

Un servidor web comprende y admite solo el protocolo HTTP, mientras que un servidor de aplicaciones admite HTTP, TCP / IP y muchos más protocolos.

Como su nombre lo indica, un servidor de aplicaciones aloja instancias de una aplicación específica, pero también ofrece una gran cantidad de otras funciones. El servidor de aplicaciones proporciona la mayor parte de la lógica empresarial que puede ser necesaria para procesar solicitudes de la aplicación cliente.

El modelo de delegación del servidor web es bastante simple, cuando la solicitud llega al servidor web, simplemente pasa la solicitud al programa que mejor pueda manejarla (programa del lado del servidor). Es posible que no admita transacciones y agrupaciones de conexiones de bases de datos.

El servidor de aplicaciones tiene más capacidad de comportamiento dinámico que el servidor web. También podemos configurar el servidor de aplicaciones para que funcione como un servidor web. Simplemente, el servidor de aplicaciones es un superconjunto de servidores web.

Referencia: servidor de aplicaciones, servidor web: ¿cuál es la diferencia?

Ok, buena pregunta!
Poniendo esto simplemente en palabras,
Crear un entorno en un servidor web para que pueda ejecutar tipos / tipos específicos de aplicaciones.

1. ¡Todos los servidores de aplicaciones son servidores web pero no al revés!
2. Un servidor web que ejecuta servicios especiales (distintos del ordinario) para alojar un tipo particular de código que en tiempo de ejecución requerirá que el entorno de servicios especiales pueda llamarse servidor de aplicaciones.
3. Los servidores de aplicaciones son tareas específicas, alto ancho de banda (principalmente) y recursos.

Un ejemplo

Considere una tienda en línea que proporcione información de precios y disponibilidad en tiempo real. Lo más probable es que el sitio proporcione un formulario con el que puede elegir un producto. Cuando envía su consulta, el sitio realiza una búsqueda y devuelve los resultados incrustados en una página HTML. El sitio puede implementar esta funcionalidad de muchas maneras.

Escenario 1: servidor web sin un servidor de aplicaciones

En el primer escenario, un servidor web solo proporciona la funcionalidad de la tienda en línea. El servidor web toma su solicitud, luego la pasa a un programa del lado del servidor capaz de manejar la solicitud. El programa del lado del servidor busca la información de precios de una base de datos o un archivo plano. Una vez recuperado, el programa del lado del servidor utiliza la información para formular la respuesta HTML, luego el servidor web la envía de vuelta a su navegador web.

Para resumir, un servidor web simplemente procesa las solicitudes HTTP respondiendo con páginas HTML.

Escenario 2: servidor web con un servidor de aplicaciones

El escenario 2 se parece al escenario 1 en que el servidor web todavía delega la generación de respuesta a un script. Sin embargo, ahora puede poner la lógica de negocios para la búsqueda de precios en un servidor de aplicaciones. Con ese cambio, en lugar de que el script sepa cómo buscar los datos y formular una respuesta, el script simplemente puede llamar al servicio de búsqueda del servidor de aplicaciones. El script puede usar el resultado del servicio cuando el script genera su respuesta HTML.

En este escenario, el servidor de aplicaciones sirve la lógica de negocios para buscar la información de precios de un producto. Esa funcionalidad no dice nada sobre la visualización o cómo el cliente debe usar la información. En cambio, el cliente y el servidor de aplicaciones envían datos de un lado a otro. Cuando un cliente llama al servicio de búsqueda del servidor de aplicaciones, el servicio simplemente busca la información y la devuelve al cliente.

Al separar la lógica de fijación de precios del código generador de respuesta HTML, la lógica de fijación de precios se vuelve mucho más reutilizable entre aplicaciones.

Un segundo cliente, como una caja registradora, también podría llamar al mismo servicio que un empleado le echa un vistazo a un cliente.
Por el contrario, en el Escenario 1, el servicio de búsqueda de precios no es reutilizable porque la información está incrustada en la página HTML.

Para resumir, en el modelo del Escenario 2, el servidor web maneja las solicitudes HTTP respondiendo con una página HTML, mientras que el servidor de aplicaciones sirve la lógica de la aplicación procesando las solicitudes de precios y disponibilidad.

Ejemplo de referencia: Ejemplo tomado del enlace de Prabhakaran Nivanil 🙂

Típicamente, un servidor web es un software que escucha algún puerto TCP (típicamente 80). Puede recibir una solicitud HTTP y es capaz de responder con una respuesta HTTP. La respuesta HTTP podría generarse a partir de un archivo estático, o podría generarse mediante un script o programa.

Dentro del contexto de Java, un servidor web es típicamente un proceso Java que es capaz de delegar el procesamiento de una solicitud a Servlets y JSP. Por otro lado, un servidor de aplicaciones hace todo lo que un servidor web puede hacer y más. Entre otras cosas que hace un servidor de aplicaciones es admitir la especificación JavaEE al ser compatible con EJB, JPA, etc.

Por ejemplo, Tomcat es un servidor web y JBoss es un servidor de aplicaciones.

Resumen
En Java, un servidor web admite un subconjunto de la especificación JavaEE, generalmente Servlets y JSP. Mientras que un servidor de aplicaciones admite toda la especificación JavaEE: Servlet, JSP, EJB, Servicios web, JPA, etc.

Servidor de aplicaciones es un nombre elegante para un servidor web que tiene algunas ‘facilidades’ para exponer servicios web y ‘aplicaciones’ en general. A menos que su servidor web solo sirva archivos estáticos, su servidor web ya es un servidor de aplicaciones.

Creo que el término ‘servidor de aplicaciones’ se devolvió cuando intentaron encontrar un nombre adecuado para lo que es un servidor web que sirve servlets Java. Que es otro nombre elegante para algo que ni siquiera debería molestarse en saber, a menos que realmente lo use. Hasta donde recuerdo, los servlets fueron reemplazados por ‘frijoles’, pero no puedo estar muy seguro ya que tengo una gran intolerancia a los bullsh **.

Ahora, si realmente quiere saber qué es un ‘servidor de aplicaciones’, es una ‘palabra de moda’, algo utilizado por los vendedores para vender soluciones costosas a personas que realmente no los necesitan.

Un servidor web en java también se conoce como contenedor web o contenedor de servlet que tiene un conjunto limitado de características Java EE como Servlets, JSP, etc.
Ej: Apache Tomcat.

Un servidor de aplicaciones tiene un contenedor web, así como funciones completas de Java EE como Java Mail Service, JPA, JSF, etc.
Ej: Glassfish, Apache TomEE, JBoss o Wildfly (nuevo nombre), IBM websphere, etc.

Un servidor de aplicaciones es un producto basado en componentes que reside en el nivel medio de una arquitectura centrada en el servidor. Proporciona servicios de middleware para seguridad y mantenimiento del estado, junto con acceso a datos y persistencia.

Servidor web: un servidor web es un programa que utiliza HTTP (Protocolo de transferencia de hipertexto) para servir los archivos que forman páginas web a los usuarios, en respuesta a sus solicitudes, que son reenviadas por los clientes HTTP de sus computadoras. Las computadoras y dispositivos dedicados también pueden denominarse servidores web.

Visítanos: – Diseño web y desarrollo India

En resumen, el servidor web está diseñado para datos HTTP, mientras que el servidor de aplicaciones no está restringido a datos HTTP.

Ej: Tomcat -> Servidor web
JBoss -> Servidor de aplicaciones

Un servidor web responde básicamente a las solicitudes HTTP, mientras que el servidor de aplicaciones es el anfitrión de una variedad de solicitudes que incluyen HTTP, TCP / IP, SQL, etc.
El servidor de aplicaciones contiene la lógica de negocios, etc.

Tengo un poco de tiempo en este momento, así que no puedo explicarlo en detalle, pero revise la URL y obtendrá la esencia.

Servidor de aplicaciones, servidor web: ¿cuál es la diferencia?

La mayoría del servidor de aplicaciones, por ejemplo, JBoss o WAS, tiene servlet y contenedor JSP. … En términos de diferencia lógica entre el servidor web y el servidor de aplicaciones . Se supone que el servidor web proporciona un servicio de nivel de protocolo http , mientras que el servidor de aplicaciones brinda soporte al servicio web y expone el servicio de nivel empresarial, por ejemplo, EJB.

Un servidor de aplicaciones sirve solo la aplicación, mientras que los servidores de servidores web no solo las aplicaciones sino también el software como Biztalk donde podemos obtener la capacitación a través de la capacitación en línea de Biztalk