Qual é a diferença entre o servidor de aplicativos e o servidor da web?

Qual é a diferença entre o servidor de aplicativos e o servidor da web?

    Na maioria das vezes, esses termos servidor Web e servidor de aplicativos são usados ​​de forma intercambiável.

    A seguir, algumas das principais diferenças em resources do Web Server e do Application Server:

    • Web Server é projetado para servir o conteúdo HTTP. O servidor de aplicativos também pode servir conteúdo HTTP, mas não está limitado apenas a HTTP. Pode ser fornecido outro suporte de protocolo, como RMI / RPC
    • O Web Server é projetado principalmente para fornecer conteúdo estático, embora a maioria dos Servidores Web tenha plug-ins para suportar linguagens de script como Perl, PHP, ASP, JSP etc., através das quais esses servidores podem gerar conteúdo HTTP dynamic.
    • A maioria dos servidores de aplicativos tem o Servidor da Web como parte integrante deles, o que significa que o Servidor de Aplicativos pode fazer o que o Servidor da Web é capaz. Além disso, o App Server tem componentes e resources para oferecer suporte a serviços no nível de Aplicativo, como Pool de Conexões, Pool de Objetos, Suporte a Transações, Serviços de Mensagens, etc.
    • Como os servidores da Web são adequados para conteúdo estático e servidores de aplicativos para conteúdo dynamic, a maioria dos ambientes de produção tem o servidor da web atuando como proxy reverso do servidor de aplicativos. Isso significa que durante a manutenção de uma solicitação de página, o conteúdo estático (como imagens / HTML estático) é servido pelo servidor da Web que interpreta a solicitação. Usando algum tipo de técnica de filtragem (principalmente a extensão do recurso solicitado) o servidor da web identifica a solicitação de conteúdo dynamic e encaminha de forma transparente para o servidor de aplicativos

    Exemplo de tal configuração é o Servidor HTTP Apache Tomcat e o Oracle (antigo BEA) WebLogic Server. O Apache Tomcat HTTP Server é um servidor da Web e o Oracle WebLogic é um servidor de aplicativos.

    Em alguns casos, os servidores são fortemente integrados, como o IIS e o .NET Runtime. O IIS é um servidor da web. Quando equipado com o ambiente de tempo de execução do .NET, o IIS é capaz de fornecer serviços de aplicativos.

    Ambos os termos são muito genéricos, um contendo o outro e vice-versa em alguns casos.

    • Servidor da Web : serve conteúdo para a web usando o protocolo http.

    • Servidor de aplicativos : hospeda e expõe a lógica e os processos de negócios.

    Eu acho que o ponto principal é que o servidor web expõe tudo através do protocolo http, enquanto o servidor de aplicativos não está restrito a ele.

    Dito isso, em muitos cenários, você descobrirá que o servidor da Web está sendo usado para criar o front-end do servidor de aplicativos, ou seja, expõe um conjunto de páginas da Web que permitem ao usuário interagir com as regras de negócios encontradas no servidor. servidor de aplicação.

    Esta é uma resposta detalhada com alguns cenários para entender claramente a diferença, semelhança e como ambos podem trabalhar em conjunto e todos

    Application Server é um termo que às vezes é mesclado com um servidor da web . Enquanto um servidor da Web lida principalmente com protocolos HTTP , o servidor de aplicativos lida com vários protocolos diferentes, incluindo, mas não se limitando, a HTTP .

    A tarefa principal do servidor da Web é exibir o conteúdo do site e o servidor de aplicativos é responsável pela lógica , a interação entre o usuário e o conteúdo exibido. O servidor de aplicativos está trabalhando em conjunto com o servidor da web, onde um é exibido e o outro interage.

    As informações que vão e voltam entre o servidor e seu cliente não estão restritas a simples marcação de exibição, mas à interação entre os dois.

    Na maioria dos casos, o servidor cria essa interação por meio de uma API de componente , como J2EE (Java 2 Platform) , EJB (Enterprise JavaBean) e outros modelos de software de aplicativo diferentes.

    insira a descrição da imagem aqui

    Um exemplo:

    A melhor maneira de entender a diferença entre os cenários em que um servidor de aplicativos funciona com o servidor da Web e um cenário em que não há um servidor de aplicativos é por meio de uma loja online.

    Cenário 1: Servidor da Web sem um servidor de aplicativos

    você tem uma loja online com apenas um servidor web e nenhum servidor de aplicativos. O site fornecerá uma exibição de onde você pode escolher um produto. Quando você envia uma consulta, o site realiza uma pesquisa e retorna um resultado HTML de volta ao seu cliente. O servidor da web envia sua consulta diretamente para o servidor de database (seja paciente, explicarei este em nosso próximo nugget) e aguarda uma resposta. Uma vez recebido, o servidor web formula a resposta em um arquivo HTML e a envia para o seu navegador. Essa comunicação de ida e volta entre o servidor e o servidor de database acontece toda vez que uma consulta é executada.

    Cenário 2: Servidor da Web com um servidor de aplicativos

    se a consulta que você deseja executar já tiver sido executada anteriormente e nenhum dado tiver sido alterado desde então, o servidor gerará os resultados sem precisar enviar a solicitação ao servidor de database. Isso permite uma consulta em tempo real em que um segundo cliente pode acessar as mesmas informações e receber informações confiáveis ​​em tempo real, sem enviar outra consulta duplicada ao servidor de database. O servidor basicamente atua como intermediário entre o servidor de database e o servidor da web. Isso permite que as informações sejam reutilizadas enquanto no primeiro cenário, uma vez que essas informações são incorporadas em uma página HTML particular e “personalizada”, isso não é um processo reutilizável. Um segundo cliente terá que solicitar as informações novamente e receber outra página incorporada em HTML com as informações solicitadas – altamente ineficiente. Sem mencionar que este tipo de servidor é muito flexível devido à sua capacidade de gerenciar seus próprios resources, incluindo segurança, processamento de transactions, mensagens e pool de resources.

    Para suportar tal variedade de tarefas complexas, este servidor deve ter redundância embutida, grande capacidade de processamento e alta quantidade de RAM para lidar com todos os dados que está sendo puxado em tempo real.

    Espero que isto ajude.

    Como Rutesh e jmservera salientaram, a distinção é difusa. Historicamente, eles eram diferentes, mas através dos anos 90 essas duas categorias anteriormente distintas misturavam características e se fundiam efetivamente. Neste ponto, é provavelmente melhor imaginar que a categoria de produto “App Server” é um superconjunto estrito da categoria “servidor da Web”.

    Um pouco de história. Nos primeiros dias do navegador Mosaic e do conteúdo com hiperlinks, desenvolveu-se essa coisa chamada “servidor da Web” que servia o conteúdo da página da Web e imagens por HTTP. A maior parte do conteúdo era estática e o protocolo HTTP 1.0 era apenas uma forma de enviar arquivos. Rapidamente, a categoria “servidor da Web” evoluiu para include o recurso de CGI – lançando efetivamente um processo em cada solicitação da Web para gerar conteúdo dynamic. O HTTP também amadureceu e os produtos se tornaram mais sofisticados, com resources de cache, segurança e gerenciamento. Conforme a tecnologia amadurecia, obtivemos tecnologia de servidor baseada em Java específica da empresa da Kiva e da NetDynamics, que acabaram sendo incorporadas ao JSP. Microsoft adicionou ASP, acho que em 1996, para o Windows NT 4.0. O servidor web estático havia aprendido alguns truques novos, de modo que era um “servidor de aplicativos” eficaz para muitos cenários.

    Em uma categoria paralela, o servidor de aplicativos evoluiu e existiu por um longo tempo. As empresas forneciam produtos para Unix como Tuxedo, TopEnd, Encina, que eram derivados filosoficamente dos ambientes de gerenciamento e monitoramento de aplicativos Mainframe, como IMS e CICS. A oferta da Microsoft foi o Microsoft Transaction Server (MTS), que mais tarde evoluiu para o COM +. A maioria desses produtos especificava protocolos de comunicação específicos de produto “fechados” para interconectar clientes “gordinhos” a servidores. (Para Encina, o protocolo de comunicação era DCE RPC; para MTS era DCOM; etc.) Em 1995/96, esses produtos de servidor de aplicativos tradicionais começaram a incorporar a capacidade básica de comunicação HTTP, inicialmente por meio de gateways. E as linhas começaram a ficar borradas.

    Os servidores da Web ficaram cada vez mais maduros no que diz respeito a lidar com cargas mais altas, mais simultaneidade e melhores resources. Os servidores de aplicativos forneceram cada vez mais resources de comunicação baseados em HTTP.

    Neste ponto, a linha entre “servidor de aplicativos” e “servidor da web” é um fuzzy. Mas as pessoas continuam a usar os termos de maneira diferente, por uma questão de ênfase. Quando alguém diz “servidor da Web”, você geralmente pensa em aplicativos orientados para HTTP, UI da Web e orientados. Quando alguém diz “App server”, você pode pensar “cargas mais pesadas, resources empresariais, transactions e enfileiramento, comunicação multicanal (HTTP + mais). Mas muitas vezes é o mesmo produto que atende aos dois conjuntos de requisitos de carga de trabalho.

    • WebSphere, o “servidor de aplicativos” da IBM possui seu próprio servidor da Web empacotado.
    • WebLogic, outro servidor de aplicativos tradicional, da mesma forma.
    • O Windows, que é o Servidor de Aplicativos da Microsoft (além de ser seu Servidor de Arquivo e Impressão, Servidor de Mídia, etc.), agrupa o IIS.

    servidor web

    Execute python -m 'SimpleHTTPServer' e vá para http: // localhost: 8080 . O que você vê é um servidor web em seu funcionamento. O servidor simplesmente serve arquivos sobre HTTP armazenados em seu computador. O ponto chave é que tudo isso é feito no topo do protocolo HTTP. Existem também servidores FTP, por exemplo, que fazem exatamente a mesma coisa (servindo arquivos armazenados), mas em cima de um protocolo diferente.

    Servidor de aplicação

    Digamos que temos um pequeno aplicativo como abaixo (trecho do Flask ).

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

    O pequeno programa de exemplo mapeia o URL / para a function homepage() e o /about para a function about() .

    Para executar este código, precisamos de um servidor de aplicativos – um programa ou módulo que possa escutar solicitações de um cliente e usar nosso código, retornar algo dinamicamente. No exemplo, simplesmente retornamos um HTML muito ruim.

    Qual é a lógica de negócios que todas as outras pessoas falam? Bem, uma vez que uma URL mapeia para algum lugar especificamente em nossa base de código, estamos, hipoteticamente, mostrando alguma lógica sobre como nosso programa funciona.


    Recapping

    servidor web – serve arquivos armazenados em algum lugar (mais comumente .css, .html, .js). Servidores web comuns são Apache, Nginx ou até mesmo o SimpleHTTPServer do Python.

    servidor de aplicativos – serve arquivos gerados em tempo real. Essencialmente, a maioria dos servidores da web tem algum tipo de plug-in ou até mesmo vem com funcionalidades internas para isso. Existem também servidores de aplicação restritos como Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.

    Observe que você pode realmente construir um servidor da Web com o código do servidor de aplicativos. Isso é feito em alguns casos durante o desenvolvimento, onde você não quer ter um zilhão de servidores diferentes em execução no seu computador.

    Como muitos já disseram antes, os servidores da Web lidam com petições HTTP, enquanto os servidores de aplicativos manipulam petições para componentes distribuídos. Então, talvez a maneira mais fácil de entender a diferença seja comparar os dois produtos em relação ao ambiente de programação que eles oferecem.

    Servidor Web -> Ambiente de Programação

    IIS: ASP (.NET)

    Tomcat: Servlet

    Molhe: Servlet

    Apache: Php, CGI

    Servidores de Aplicação -> Ambiente de Programação

    MTS: COM +

    EAS: EJB

    JBoss: EJB

    Servidor de Aplicativos WebLogic: EJB

    A diferença crucial é que os servidores de aplicativos suportam alguma tecnologia de componentes distribuídos , fornecendo resources como invocação remota e transactions distribuídas, como EJB no mundo Java ou COM + na plataforma Microsoft. O servidor Http geralmente suporta alguns ambientes de programação mais simples, geralmente scripts, como ASP (.NET) no caso de Microsoft ou Servlet – baseado, incluindo JSP e muitos outros no caso de Java ou PHP e CGI no caso do Apache.

    Outros resources, como balanceamento de carga, cluster, failover de session, pool de conexão, etc., que costumavam estar no domínio dos servidores de aplicativos, estão se tornando disponíveis em servidores da Web, bem como diretamente ou por meio de alguns produtos de terceiros.

    Finalmente, vale a pena notar que a imagem é ainda mais distorcida com “contêineres leves”, como o Spring Framework, que muitas vezes complementam a finalidade dos servidores de aplicativos de maneira mais simples e sem a infraestrutura do servidor de aplicativos. E como o aspecto de distribuição nos aplicativos está se movendo do componente distribuído para o paradigma de serviço e a arquitetura SOA, há cada vez menos espaço para os servidores de aplicativos tradicionais.

    Um servidor da Web lida exclusivamente com solicitações HTTP / HTTPS. Ele serve conteúdo para a web usando o protocolo HTTP / HTTPS.

    Um servidor de aplicativos atende a lógica de negócios a programas aplicativos por meio de qualquer número de protocolos, possivelmente incluindo HTTP. O programa aplicativo pode usar essa lógica da mesma forma que chamaria um método em um object. Na maioria dos casos, o servidor expõe essa lógica de negócios por meio de uma API de componente, como o modelo de componente EJB (Enterprise JavaBean) encontrado em servidores de aplicativos Java EE (Java Platform, Enterprise Edition). O ponto principal é que o servidor web expõe tudo através do protocolo http, enquanto o servidor de aplicativos não está restrito a ele. Um servidor de aplicativos, portanto, oferece muito mais serviços do que um servidor da Web, que geralmente inclui:

    • Uma API (proprietária ou não)
    • Balanceamento de carga, failover …
    • Gerenciamento do Ciclo de Vida do Objeto
    • Gerenciamento de estado (session)
    • Gerenciamento de resources (por exemplo, pools de conexão para o database)

    A maioria dos servidores de aplicativos tem o Servidor da Web como parte integrante deles, o que significa que o Servidor de Aplicativos pode fazer o que o Servidor da Web é capaz. Além disso, o App Server tem componentes e resources para oferecer suporte a serviços no nível de Aplicativo, como Pool de Conexões, Pool de Objetos, Suporte a Transações, Serviços de Mensagens, etc.

    Um servidor de aplicativos pode (mas nem sempre) ser executado em um servidor da Web para executar a lógica do programa, cujos resultados podem ser entregues pelo servidor da web. Esse é um exemplo de um cenário de servidor da Web / servidor de aplicativos. Um bom exemplo no mundo da Microsoft é o relacionamento do Internet Information Server / SharePoint Server. O IIS é um servidor da Web; O SharePoint é um servidor de aplicativos. O SharePoint fica “no topo” do IIS, executa lógica específica e exibe os resultados por meio do IIS. No mundo Java, há um cenário semelhante com o Apache e o Tomcat, por exemplo.

    Como os servidores da Web são adequados para conteúdo estático e servidores de aplicativos para conteúdo dynamic, a maioria dos ambientes de produção tem o servidor da web atuando como proxy reverso do servidor de aplicativos. Isso significa que durante o serviço de uma solicitação de página, o conteúdo estático, como imagens / HTML estático, é servido pelo servidor da Web que interpreta a solicitação. Usando algum tipo de técnica de filtragem (principalmente extensão do recurso solicitado), o servidor da web identifica a solicitação de conteúdo dynamic e encaminha-se de forma transparente para o servidor de aplicativos.

    Exemplo de tal configuração é o Apache HTTP Server e o BEA WebLogic Server. O Apache HTTP Server é um servidor da Web e o BEA WebLogic é um servidor de aplicativos. Em alguns casos, os servidores são fortemente integrados, como o IIS e o .NET Runtime. O IIS é um servidor da web. quando equipado com o ambiente de tempo de execução do .NET, o IIS é capaz de fornecer serviços de aplicativos


     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+ 

    Em suma, um servidor web é um servidor que serve páginas da web para usuários via http. Um servidor de aplicativos é um servidor que hospeda a lógica de negócios de um sistema. Geralmente hospeda processos de longa execução / lote e / ou serviços de interoperabilidade não destinados ao consumo humano (serviços REST / JSON, SOAP, RPC, etc).

    A principal diferença entre o servidor Web e o servidor de aplicativos é que o servidor da Web serve para páginas estáticas, por exemplo, HTML e CSS, enquanto o Application Server é responsável por gerar conteúdo dynamic executando código do servidor, por exemplo, JSP, Servlet ou EJB.

    Qual deles devo usar?
    Depois de saber a diferença entre o servidor da Web e o servidor de aplicativos e os contêineres da Web, é fácil descobrir quando usá-los. Você precisa de um web server como o Apache HTTPD, se estiver atendendo a páginas da Web estáticas. Se você tiver um aplicativo Java com apenas JSP e Servlet para gerar conteúdo dynamic, precisará de web containers como o Tomcat ou o Jetty. Enquanto, se você tiver o aplicativo Java EE usando EJB, transação distribuída, sistema de mensagens e outros resources sofisticados, precisará de um application server completo como o JBoss, o WebSphere ou o WebLogic da Oracle.

    O contêiner da Web faz parte do Web Server e o Servidor da Web faz parte do Application Server.

    Servidor de aplicação

    O Web Server é composto de contêiner da web, enquanto o Application Server é composto de contêiner da web e de contêiner EJB.

    Um servidor da web executa o protocolo HTTP para servir páginas da web. Um servidor de aplicativos pode (mas nem sempre) ser executado em um servidor da Web para executar a lógica do programa, cujos resultados podem ser entregues pelo servidor da web. Esse é um exemplo de um cenário de servidor da Web / servidor de aplicativos.

    Um bom exemplo no mundo da Microsoft é o relacionamento do Internet Information Server / SharePoint Server. O IIS é um servidor da Web; O SharePoint é um servidor de aplicativos. O SharePoint fica “no topo” do IIS, executa lógica específica e exibe os resultados por meio do IIS.

    No mundo Java, há um cenário semelhante com o Apache e o Tomcat, por exemplo.

    Um servidor de aplicativos é normalmente projetado e implementado para facilitar processos mais longos que também exigem mais resources.

    Um servidor da Web é usado para rajadas curtas que não consomem muitos resources, geralmente. Isso é principalmente para facilitar o tráfego na web.

    Em um primeiro momento, um servidor da Web serve conteúdo da Web (HTML e conteúdo estático) sobre o protocolo HTTP. Por outro lado, um servidor de aplicativos é um contêiner no qual é possível construir e expor a lógica e os processos de negócios para aplicativos clientes por meio de vários protocolos, incluindo HTTP em uma arquitetura de n camadas.

    Um servidor de aplicativos, portanto, oferece muito mais serviços do que um servidor da Web, que geralmente inclui:

    • Uma API (proprietária ou não)
    • Gerenciamento do ciclo de vida do object,
    • Gerenciamento de estado (session)
    • Gerenciamento de resources (por exemplo, pools de conexão para database),
    • Balanceamento de carga, failover …

    AFAIK, ATG Dynamo foi um dos primeiros servidores de aplicativos no final dos anos 90 (de acordo com a definição acima). No início de 2000, era o reinado de alguns servidores de aplicativos proprietários como ColdFusion (CFML AS), BroadVision (JavaScript do lado do servidor AS), etc. Mas nenhum realmente sobreviveu à era do servidor de aplicativos Java.

    Em termos Java, há mais um: contêiner da web (ou mais estritamente, contêiner de servlet). É, digamos, entre servidor web e servidor de aplicativos. Um contêiner da web é, em termos Java, um servidor de aplicativos que basicamente implementa apenas a parte JSP / Servlet do Java EE e não possui várias partes principais do Java EE, como o suporte a EJB. Um exemplo é o Apache Tomcat.

    A fronteira entre esses dois está ficando cada vez mais fina.

    Servidores de aplicativos expõem a lógica de negócios a um cliente. Portanto, seu servidor de aplicativos é composto por um conjunto de methods (não necessariamente, pode até ser um computador em rede, permitindo que muitos executem software nele) para executar a lógica de negócios. Por isso, simplesmente produzirá os resultados desejados, não o conteúdo HTML. (semelhante a uma chamada de método). Portanto, não é estritamente baseado em HTTP.

    Mas os servidores da web transmitem conteúdo HTML para navegadores da web (estritamente baseado em HTTP). Os servidores da Web eram capazes de manipular apenas os resources da Web estáticos, mas o surgimento do script do lado do servidor ajudou os servidores da Web a manipular o conteúdo dynamic também. Onde o servidor da web recebe a solicitação e a direciona para o script (PHP, JSP, scripts CGI, etc.) para CRIAR o conteúdo HTML a ser enviado ao cliente. Então o servidor web sabe como enviá-los de volta ao cliente. PORQUE isso é o que um servidor web realmente sabe.

    Dito isto, hoje em dia os desenvolvedores usam os dois juntos. Quando o servidor da web recebe a solicitação e, em seguida, chama um script para criar o HTML, o script BUT novamente chama um LOGIC do servidor de aplicativos (por exemplo, Recuperar detalhes da transação) para preencher o conteúdo HTML.

    Portanto, neste caso, ambos os servidores foram usados ​​de forma eficaz.

    Portanto … Podemos afirmar com segurança que, atualmente, na maioria dos casos, os servidores da Web são usados ​​como um subconjunto de servidores de aplicativos. MAS teatralmente não é o caso.

    Eu li muitos artigos sobre este tópico e achei este artigo bastante útil.

    Um servidor de aplicativos é uma máquina (um processo executável em execução em alguma máquina, na verdade) que “escuta” (em qualquer canal, usando qualquer protocolo), para solicitações de clientes para qualquer serviço fornecido e faz algo com base nessas solicitações. (pode ou não envolver uma resposta para o cliente)

    Um servidor da Web é um processo em execução em uma máquina que “escuta” especificamente no Canal TCP / IP usando um dos protocolos “internet” (http, https, ftp, etc.) e faz o que fizer com base nessas solicitações recebidas. .. Geralmente, (como definido originalmente), ele buscou / gerou e retornou uma página da web html para o cliente, seja obtida de um arquivo html estático no servidor, ou construída dinamicamente com base em parâmetros na solicitação de input do cliente.

    A maior diferença é que um servidor da Web manipula solicitações HTTP, enquanto um servidor de aplicativos executará a lógica de negócios em qualquer número de protocolos.

    Todos os itens acima estão complicando demais algo muito simples. Um servidor de aplicativos contém um servidor da Web, um servidor de aplicativos possui mais algumas adições / extensões do que os servidores padrão da Web. Se você olhar para o TomEE como um exemplo:

     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 

    Você verá que o Tomcat (contêiner / servidor da Web) é apenas mais uma ferramenta no arsenal de servidores de aplicativos. Você pode obter o JPA e a outra tecnologia no servidor da Web também, se desejar, mas os servidores de aplicativos apenas empacotam todas essas coisas para sua conveniência. Para ser totalmente classificado como um servidor de aplicativos, você basicamente precisa cumprir uma lista de ferramentas definidas por algum padrão.

    Não há necessariamente uma linha divisória clara. Atualmente, muitos programas combinam elementos de ambos – atender solicitações http (servidor da web) e lidar com a lógica de negócios (servidor de aplicativos)

    Na verdade, o Apache é um servidor da Web e o Tomcat é um servidor de aplicativos. Quando, como solicitação HTTP, chega ao servidor web. Então o conteúdo estático é enviado de volta ao navegador pelo servidor web. Existe e lógico para fazer, então esse pedido enviar para o servidor de aplicativos. Depois de processar a lógica, envie a resposta para o servidor web e envie para o cliente.

    Embora possa haver sobreposições entre os dois (alguns servidores da web podem até ser usados ​​como servidores de aplicativos), a maior diferença que IMHO está no modelo de processamento e no gerenciamento de sessões:

    No modelo de processamento do servidor da Web, o foco está no tratamento de solicitações; a noção de “session” é praticamente virtual. Isso quer dizer que a “session” é simulada transferindo a representação de estado entre cliente e servidor (portanto, REST) ​​e / ou serializando-a para um armazenamento persistente externo (SQL Server, Memcached, etc.).

    No servidor de aplicativos, a session é geralmente mais explícita e geralmente toma a forma de um object que vive na memory do servidor de aplicativos durante toda a duração da “session”.

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

    Um servidor da Web é um sistema de computador que processa solicitações via HTTP, o protocolo de rede básico usado para distribuir informações na World Wide Web. O termo pode se referir a todo o sistema, ou especificamente ao software que aceita e supervisiona as solicitações HTTP .

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

    Um servidor de aplicativos é executado por trás de um servidor da Web (por exemplo, Apache ou IIS (Serviços de Informações da Internet da Microsoft) e (quase sempre) na frente de um database SQL (por exemplo, PostgreSQL, MySQL ou Oracle).

    Aplicativos da Web são códigos de computador que são executados sobre servidores de aplicativos e são gravados no (s) idioma (s) ao qual o servidor de aplicativos suporta e chamam as bibliotecas e componentes de tempo de execução que o servidor de aplicativos oferece .

    O servidor de aplicativos e o servidor da Web são usados ​​para hospedar o aplicativo da web. O servidor da Web é compatível com o contêiner da Web, por outro lado, o Application Server trata do contêiner da Web, bem como do contêiner EJB (Enterprise JavaBean) ou do contêiner COM + para o Microsoft dot Net.

    Web Server é projetado para servir HTTP conteúdo estático, como HTML, imagens, etc e para o conteúdo dynamic tem plugins para suportar linguagens de script como Perl, PHP, ASP, JSP etc e é limitado ao protocolo HTTP. Abaixo dos servidores pode gerar conteúdo HTTP dynamic.

    Ambiente de Programação do Servidor Web:

    IIS: ASP (.NET)

    Apache Tomcat: Servlet

    Molhe: Servlet

    Apache: Php, CGI

    O Application Server pode fazer o que o Servidor Web é capaz e escuta usando qualquer protocolo, bem como o App Server tem componentes e resources para suportar serviços em nível de Aplicativo, como Pool de Conexões, Pool de Objetos, Suporte a Transações, Serviços de Mensagens, etc.

    Ambiente de programação do servidor de aplicativos:

    MTS: COM +

    EAS: EJB

    JBoss: EJB

    Servidor de Aplicativos WebLogic: EJB

    Depende da arquitetura específica. Alguns servidores de aplicativos podem usar protocolos da web de maneira nativa (XML / RPC / SOAP sobre HTTP), portanto, há pouca diferença técnica. Normalmente, um servidor da Web é voltado para o usuário, atendendo a uma variedade de conteúdo em HTTP / HTTPS, enquanto um servidor de aplicativos não é voltado para o usuário e pode usar protocolos não-padrão ou não roteáveis. É claro que com o RIA / AJAX, a diferença pode ficar ainda mais nublada, servindo apenas conteúdo não HTML (JSON / XML) para clientes que utilizam serviços específicos de access remoto.

    Em um primeiro momento, um servidor da Web serve conteúdo da Web (HTML e conteúdo estático) sobre o protocolo HTTP. Por outro lado, um servidor de aplicativos é um contêiner no qual é possível construir e expor a lógica e os processos de negócios para aplicativos clientes por meio de vários protocolos, incluindo HTTP em uma arquitetura de n camadas.

    Um servidor de aplicativos, portanto, oferece muito mais serviços do que um servidor da Web, que geralmente inclui:

    • Uma API (proprietária ou não)
    • Gerenciamento do ciclo de vida do object,
    • Gerenciamento de estado (session)
    • Gerenciamento de resources (por exemplo, pools de conexão para database),
    • Balanceamento de carga, failover

    O servidor de aplicativos e o servidor da web em Java são usados ​​para hospedar o aplicativo da web Java. Na perspectiva do Java J2EE, a principal diferença entre o servidor da web e o servidor de aplicativos é o suporte do EJB. Para executar o EJB ou o arquivo do aplicativo Java corporativo (.ear) você precisa de um servidor de aplicativos como JBoss, WebLogic, WebSphere ou Glassfish, enquanto ainda pode executar seu servlet e JSP ou arquivo de aplicativo web java (.war) dentro de qualquer web servidor como Tomcat ou Jetty. O Application Server suporta transação distribuída e EJB. Enquanto o servidor da Web suporta apenas Servlets e JSP. Em termos de diferença lógica entre o servidor da web e o servidor de aplicativos. Supõe-se que o servidor da Web forneça o serviço de nível de protocolo http, enquanto o servidor de aplicativos fornece suporte ao serviço da Web e expõe o serviço de nível de negócios, por exemplo, EJB.

    O servidor de aplicativos é mais pesado que o servidor da Web em termos de utilização de resources.

    IMO, é principalmente sobre separar as preocupações.

    De um ponto de vista puramente técnico, você pode fazer tudo (conteúdo da web + lógica de negócios) em um único servidor web. Se você fizer isso, as informações serão inseridas dentro do conteúdo HTML solicitado. Qual seria o impacto?

    Por exemplo, imagine que você tenha dois aplicativos diferentes que renderizam conteúdo HTML totalmente diferente no navegador. Se você separasse a lógica de negócios em um servidor de aplicativos, poderia fornecer diferentes servidores da Web procurando os mesmos dados no servidor de aplicativos por meio de scripts. No entanto, se você não separasse a lógica e a mantivesse no servidor web, sempre que mudasse seu modelo de negócios, você acabaria mudando-a em cada servidor web que você tem, o que levaria mais tempo, seria menos confiável e propenso a erros.