¿Cuál es la diferencia entre el servidor de aplicaciones y el servidor web?
Respuestas:
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:
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.
Esta es una respuesta detallada con algunos escenarios para comprender claramente la diferencia, similitud y cómo ambos pueden funcionar 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 maneja varios protocolos diferentes, que incluyen, entre otros, HTTP .
El trabajo principal del servidor web es mostrar el contenido del sitio y el servidor de aplicaciones se encarga de la lógica , la interacción entre el usuario y el contenido mostrado. El servidor de aplicaciones funciona 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 está restringida a un simple marcado, sino a la interacción entre ambos.
En la mayoría de los casos, el servidor crea esta interacción a través de un componente API , como J2EE (Plataforma Java 2) , EJB (Enterprise JavaBean) y otros modelos de software de aplicación diferentes.
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 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 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.
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.
Espero que esto ayude.
the application server deals with several different protocols, including, but not limited, to HTTP<- eso dice que definitivamente maneja solicitudes http - eso no es exacto.
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 la lógica y los procesos empresariales.
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 está utilizando 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 su funcionamiento. El servidor simplemente sirve archivos a través de 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 (sirven archivos almacenados) pero además de 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 pueda escuchar las solicitudes de un cliente y, utilizando nuestro código, devolver algo dinámicamente. En el ejemplo, simplemente devolvemos algunos HTML muy malos.
¿Cuál es la lógica comercial de la que hablan todas las demás personas? Bueno, dado que una URL se asigna a algún lugar específicamente en nuestra base de código, hipotéticamente mostramos 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 el 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 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 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 una gran cantidad 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 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ó 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 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 la 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 compañía de Kiva y NetDynamics, que finalmente 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 fue un "
En una categoría paralela, el servidor de aplicaciones había evolucionado y existido durante mucho tiempo. Las compañías entregaron productos para Unix como Tuxedo, TopEnd, Encina que se derivaron filosóficamente de entornos de gestión y monitoreo de aplicaciones Mainframe como IMS y CICS. La oferta de Microsoft fue Microsoft Transaction Server (MTS), que más tarde se convirtió en COM +. La mayoría de estos productos especifican protocolos de comunicaciones "cerrados" específicos del producto para interconectar clientes "gordos" a los 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 la capacidad básica de comunicación HTTP, al principio a través de puertas de enlace. 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 más y 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 las personas continúan 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 centradas en HTTP. 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 sirve a ambos conjuntos de requisitos de carga de trabajo.
Como muchos han dicho antes, los servidores web manejan peticiones HTTP, mientras que los servidores de aplicaciones manejan peticiones para componentes distribuidos. Entonces, quizás la forma más fácil de entender la diferencia es comparar los dos productos en cuanto al entorno de programación que ofrecen.
IIS: ASP (.NET)
Tomcat: Servlet
Embarcadero: Servlet
Apache: Php, CGI
MTS: COM +
ERA: EJB
JBoss: EJB
Servidor de aplicaciones WebLogic: EJB
La diferencia crucial es que los servidores de aplicaciones admiten cierta tecnología de componentes distribuidos , proporcionando funciones como invocación remota y transacciones distribuidas, como EJB en el mundo 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 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 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 distribución en las aplicaciones se está moviendo desde el componente distribuido hacia el paradigma de servicio y la arquitectura SOA, queda cada vez menos espacio para los servidores de aplicaciones tradicionales.
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 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 serverApache HTTPD similar 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 containerscomo Tomcat o Jetty. Si bien, si tiene una aplicación Java EE que utiliza EJB, transacciones distribuidas, mensajería y otras características sofisticadas , entonces necesita una versión completaapplication server 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, mientras que el servidor de aplicaciones está compuesto por un contenedor web y un contenedor EJB.
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 de negocios para un sistema. A menudo aloja procesos de ejecución larga / por lotes y / o servicios de interoperabilidad no destinados al consumo humano (servicios REST / JSON, SOAP, RPC, etc.).
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 aplicación 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 empresarial a través de una API de componente, como el modelo de componente 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 generalmente incluye:
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.
Un servidor de aplicaciones puede (pero no siempre) ejecutarse 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 escenario de servidor web / servidor de aplicaciones. Un buen ejemplo en el mundo de Microsoft es la relación de Internet Information Server / 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 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 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.
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 .NET Runtime Environment 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+
La frontera entre estos dos se está volviendo cada vez más delgada.
Los servidores de aplicaciones exponen la lógica empresarial a los clientes. Eso significa que los servidores de aplicaciones forman parte de un conjunto de métodos (aunque no exclusivamente, incluso pueden ser una computadora en red que permite que muchos ejecuten software en ella) para realizar la lógica empresarial. Por lo tanto, simplemente generará los resultados deseados, no el contenido HTML. (similar a una llamada al método). Por lo tanto, no está estrictamente basado en HTTP.
Pero los servidores web pasan 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 secuencias de comandos del lado del servidor permitió que los servidores web también manejaran contenidos dinámicos. Donde un servidor web toma la solicitud y la dirige a los scripts relevantes (PHP, JSP, scripts CGI, etc.) para CREAR contenido HTML que se enviará al cliente. Una vez que se recibe el contenido, el servidor web enviará la página HTML al cliente.
Sin embargo, hoy en día ambos servidores se usan juntos. Donde el servidor web toma la solicitud y luego llama a un script para crear el contenido HTML. Luego, el script volverá a llamar a un LOGIC del servidor de aplicaciones (por ejemplo, recuperar detalles de la transacción) para completar el contenido HTML.
Por lo tanto, ambos servidores se utilizan de manera efectiva.
Por lo tanto ... Podemos decir con seguridad que hoy en día, 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 este artículo bastante útil.
Un servidor de aplicaciones generalmente está diseñado e implementado para facilitar procesos de ejecución más largos 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 la web.
En términos de Java, hay uno más: contenedor web (o más estrictamente, contenedor de servlet). 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 de EJB. Un ejemplo es Apache Tomcat.
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), las solicitudes de los clientes para cualquier servicio que brinde, 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 utilizando uno de los protocolos "internet" (http, https, ftp, etc.) y hace lo que hace en función de esas solicitudes entrantes. .. Generalmente, (como se definió originalmente), obtuvo / generó y devolvió una página web html al cliente, ya sea extraído de un archivo html estático en el servidor, o construido dinámicamente según los parámetros en la solicitud entrante del cliente.
Un servidor web ejecuta el protocolo HTTP para servir páginas web. Un servidor de aplicaciones puede (pero no siempre) ejecutarse 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 escenario de servidor web / servidor de aplicaciones.
Un buen ejemplo en el mundo de Microsoft es la relación de Internet Information Server / 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 sirve los resultados a través de IIS.
En el mundo de Java, hay un escenario similar con Apache y Tomcat, por ejemplo.
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 sobre el cual puede construir y exponer procesos y lógica empresarial a las aplicaciones del 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 generalmente incluye:
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 (JavaScript AS del lado del servidor), etc. Pero ninguno realmente sobrevivió a la era del servidor de aplicaciones Java.
Entendimiento básico :
En la arquitectura del servidor del cliente
Servidor:> que atiende las solicitudes.
Cliente:> Que consume servicio.
El servidor web y el servidor de aplicaciones son aplicaciones de software que actúan como servidores para sus clientes.
Obtuvieron sus nombres en función de su lugar de utilización.
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
Uso -
we require low processing rates, regular processing practices involves.Por ejemplo: todos los servidores planos generalmente están listos para usar y solo sirven contenido basado en la web.
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
Uso -
we require multi point processing, specialized processing techniques involves like for AI.Por ejemplo: servidores de mapas de Google, servidores de búsqueda de Google, servidores de documentos de Google, servidores de Microsoft 365, servidores de visión por computadora de Microsoft para IA.
Podemos asumirlos como niveles / jerarquías en la arquitectura de 4 niveles / n niveles.
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
Siga este enlace para obtener analogías de arquitectura estándar:
https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)
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.
En realidad, Apache es un servidor web y Tomcat es un servidor de aplicaciones. Cuando como solicitud HTTP llega al servidor web. Luego, el contenido estático se envía de vuelta al navegador por el servidor web. Hay una lógica que hacer, entonces esa solicitud se envía al servidor de aplicaciones. Después de procesar la lógica, la respuesta se envía al servidor web y se envía al cliente.
Todo lo anterior simplemente complica demasiado 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 en el 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 simplemente empaquetan todas estas cosas para su conveniencia. Para estar completamente clasificado como un servidor de aplicaciones, esencialmente debe cumplir con una lista de herramientas establecidas por algún estándar.
No hay necesariamente una línea divisoria clara. Hoy en día, muchos programas combinan elementos de ambos: atender solicitudes http (servidor web) y manejar la lógica empresarial (servidor de aplicaciones)
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 .
De 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) frente a 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 escritas en los idiomas que admite el servidor de aplicaciones y llaman a las bibliotecas y componentes de tiempo de ejecución que ofrece el servidor de aplicaciones .
El servidor de aplicaciones y el servidor web se utilizan para alojar aplicaciones web. Web Server trata el contenedor web, por otro lado, Application Server trata el contenedor web, así como el contenedor EJB (Enterprise JavaBean) o el contenedor COM + para Microsoft dot Net.
Web Server está diseñado para servir contenido estático HTTP 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. Los siguientes 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 todo lo que Web Server sea capaz y escuche utilizando cualquier protocolo, y App Server tiene componentes y características para admitir servicios de nivel de aplicación, como Pool de conexiones, Pool 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
Si bien puede haber superposiciones entre los dos (algunos servidores web pueden incluso usarse como servidores de aplicaciones), la mayor diferencia en mi humilde opinión está en el modelo de procesamiento y la gestión de la sesión:
En el modelo de procesamiento del servidor web, el foco está en manejar las solicitudes; La noción de "sesión" es prácticamente virtual. Es decir que la "sesión" se simula transfiriendo la representación de estado entre el cliente y el servidor (de ahí 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 "sesión".
Depende de la arquitectura específica. Algunos servidores de aplicaciones pueden usar protocolos web de forma nativa (XML / RPC / SOAP sobre 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 nublarse aún más, sirviendo solo contenido no HTML (JSON / XML) a los clientes que bombean servicios particulares de acceso remoto.
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 solo servidor web. Si lo hiciera, 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 muestran 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 buscando los mismos datos en el servidor de aplicaciones a través de scripts. Sin embargo, si no separa la lógica y la mantiene en el servidor web, cada vez que cambie su modelo de negocio, terminaría cambiándolo en cada servidor web que tenga, lo que llevaría más tiempo, sería menos confiable y propenso a errores.
Casi todas las páginas que visitas usan ambas. El servidor web sirve el contenido estático (p. Ej., Imágenes, videos) y el servidor de aplicaciones genera el resto (las partes que son diferentes entre usted y otros usuarios).