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

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

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

A seguir, estão algumas das principais diferenças nos recursos do servidor da Web e do servidor de aplicativos:

• O servidor Web foi projetado para servir conteúdo HTTP. O App Server também pode servir Conteúdo HTTP, mas não se limita apenas a HTTP. Pode ser fornecido outro suporte de protocolo, como RMI / RPC
• O servidor da Web foi projetado principalmente para veicular conteúdo estático, embora a maioria dos servidores da Web possua plugins para suportar linguagens de script como Perl, PHP, ASP, JSP etc., através dos quais esses servidores podem gerar conteúdo HTTP dinâmico.
• A maioria dos servidores de aplicativos tem o Web Server como parte integrante deles, o que significa que o App Server pode fazer o que for possível. Além disso, o App Server possui componentes e recursos 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 os servidores de aplicativos para conteúdo dinâmico, a maioria dos ambientes de produção possui um servidor da Web que atua como proxy reverso para o servidor de aplicativos. Isso significa que, ao atender a 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 dinâmico e encaminha de forma transparente para o servidor de aplicativos

Exemplo dessa configuração é o Servidor HTTP Apache Tomcat e o Servidor WebLogic Oracle (anteriormente BEA). O servidor HTTP Apache Tomcat é um servidor Web e o Oracle WebLogic é um servidor de aplicativos.

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

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

Servidor de aplicativos é um termo que às vezes é misturado 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 limitado a, HTTP .

A principal tarefa 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 circulam entre o servidor e o cliente não se restringem à 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.

Um exemplo:

A melhor maneira de entender a diferença entre os cenários em que um servidor de aplicativos trabalha com o servidor da Web versus um cenário em que não há um servidor de aplicativos é através 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 cliente. O servidor da Web envia sua consulta diretamente para o servidor de banco de dados (seja paciente, explicarei esta em nossa próxima pepita) e aguarda uma resposta. Uma vez recebido, o servidor da web formula a resposta em um arquivo HTML e a envia para o seu navegador. Essa comunicação entre o servidor e o banco de dados ocorre sempre 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 feita anteriormente e nenhum dado tiver sido alterado desde então, o servidor gerará os resultados sem precisar enviar a solicitação ao servidor de banco de dados. Isso permite uma consulta em tempo real, onde 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 banco de dados. O servidor basicamente atua como um intermediário entre o servidor de banco de dados e o servidor web. Isso permite que as informações extraídas sejam reutilizáveis ​​enquanto estiver no primeiro cenário, uma vez que essas informações são incorporadas a uma página HTML específica e "personalizada", não sendo um processo reutilizável. Um segundo cliente precisará solicitar as informações novamente e receber outra página incorporada em HTML com as informações solicitadas - altamente ineficientes.

Para oferecer suporte a uma variedade de tarefas complexas, esse servidor deve ter redundância integrada, grande poder de processamento e grande quantidade de RAM para lidar com todos os dados que está sendo extraído em tempo real.

Espero que isto ajude.

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

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

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

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

Dito isto, 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 de aplicação.

servidor web

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

Servidor de aplicação

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

@app.route('/')
def homepage():
    return '<html>My homepage</html>'

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

O pequeno programa de exemplo mapeia o URL /para a função homepage()e /aboutpara a função about().

Para executar esse código, precisamos de um servidor de aplicativos (por exemplo, Gunicorn) - um programa ou módulo que possa atender a solicitações de um cliente e, usando nosso código, retornar algo dinamicamente. No exemplo, simplesmente retornamos um código HTML muito ruim.

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

Recapitulando

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

servidor de aplicativos - serve arquivos gerados em tempo real Essencialmente, a maioria dos servidores da Web possui algum tipo de plug-in ou até vem com funcionalidade integrada para fazer isso. Também existem servidores de aplicativos estritos 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 deseja ter um zilhão de servidores diferentes em execução no seu computador.

Como Rutesh e jmservera apontaram, a distinção é nebulosa. Historicamente, eles eram diferentes, mas, nos anos 90, essas duas categorias anteriormente distintas combinaram características e efetivamente se fundiram. Nesse ponto, provavelmente é melhor imaginar que a categoria de produto "App Server" é um superconjunto estrito da categoria "servidor web".

Alguma história. Nos primeiros dias do navegador Mosaic e do conteúdo com hiperlink, evoluiu essa coisa chamada "servidor da web" que exibia imagens e conteúdo de páginas da web por HTTP. A maior parte do conteúdo era estática, e o protocolo HTTP 1.0 era apenas uma maneira de enviar arquivos. Rapidamente a categoria "servidor da web" evoluiu para incluir a capacidade de CGI - iniciando efetivamente um processo em cada solicitação da web para gerar conteúdo dinâmico. O HTTP também amadureceu e os produtos se tornaram mais sofisticados, com recursos de cache, segurança e gerenciamento. À medida que a tecnologia amadureceu, obtivemos a tecnologia do servidor baseada em Java específica da empresa da Kiva e NetDynamics, que eventualmente se fundiram no JSP. A Microsoft adicionou o ASP, penso em 1996, ao Windows NT 4.0. O servidor da Web estático aprendeu alguns novos truques, de modo que era um "

Em uma categoria paralela, o servidor de aplicativos evoluiu e existia por um longo tempo. as empresas entregaram produtos para Unix, como Tuxedo, TopEnd, Encina, que foram filosoficamente derivados do gerenciamento de aplicativos de mainframe e ambientes de monitoramento, 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 especificou protocolos de comunicação específicos ao produto "fechados" para interconectar clientes "gordos" aos servidores. (Para Encina, o protocolo de comunicação era DCE RPC; para MTS, era DCOM; etc.) Em 1995/96, esses produtos tradicionais de servidor de aplicativos começaram a incorporar recursos básicos 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 com relação ao manuseio de cargas mais altas, mais simultaneidade e melhores recursos. Os servidores de aplicativos oferecem cada vez mais capacidade de comunicação baseada em HTTP.

Nesse ponto, a linha entre "servidor de aplicativos" e "servidor da web" é muito difusa. Mas as pessoas continuam a usar os termos de maneira diferente, como uma questão de ênfase. Quando alguém diz "servidor da web", você costuma pensar em aplicativos orientados para a interface do usuário da web, centrados no HTTP. Quando alguém diz "servidor de aplicativos", você pode pensar em "cargas mais pesadas, recursos corporativos, transações e filas, comunicação multicanal (HTTP + mais). Mas, geralmente, é o mesmo produto que atende aos dois conjuntos de requisitos de carga de trabalho.

• O WebSphere, "servidor de aplicativos" da IBM possui seu próprio servidor da Web em pacote.
• O WebLogic, outro servidor de aplicativos tradicional, da mesma forma.
• O Windows, que é o App Server da Microsoft (além de ser o servidor de arquivos e impressão, servidor de mídia etc.), inclui o IIS.

Como muitos disseram antes, os servidores da Web tratam petições HTTP, enquanto os servidores de aplicativos tratam petições de componentes distribuídos. Portanto, 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

Jetty: Servlet

Apache: Php, CGI

Servidores de Aplicativos -> Ambiente de Programação

MTS: COM +

WAS: 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 recursos como invocação remota e transações 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 baseado em Servlet, incluindo JSP e muitos outros no caso de Java ou PHP e CGI no caso do Apache.

Outros recursos, como balanceamento de carga, clustering, failover de sessão, pool de conexão, etc., que costumavam ser usados ​​nos servidores de aplicativos, estão se tornando disponíveis nos servidores Web, diretamente ou através de produtos de terceiros.

Por fim, vale ressaltar que a imagem é distorcida ainda mais com "contêineres leves" como o Spring Framework, que geralmente complementam o objetivo 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á migrando do componente distribuído para o paradigma de serviço e a arquitetura SOA, resta cada vez menos espaço para os servidores de aplicativos tradicionais.

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

Qual devo usar?
Depois de saber a diferença entre o servidor da web e de aplicativos e os contêineres da web, é fácil descobrir quando usá-los. Você precisa de um web serverApache HTTPD se estiver servindo páginas da Web estáticas. Se você tiver um aplicativo Java apenas com JSP e Servlet para gerar conteúdo dinâmico, precisará do web containersTomcat ou Jetty. Entretanto, se você tiver o aplicativo Java EE usando EJB, transações distribuídas, mensagens e outros recursos sofisticados serão necessários, application servercomo JBoss, WebSphere ou WebLogic da Oracle.

O contêiner da Web faz parte do Servidor da Web e o Servidor da Web faz parte do Servidor de Aplicativos.

O Servidor da Web é composto por um contêiner da Web, enquanto o Application Server é composto por um contêiner da Web e também pelo contêiner EJB.

Em resumo, 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. Ele 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.).

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 serve a lógica de negócios para programas de aplicativos através de qualquer número de protocolos, possivelmente incluindo HTTP. O programa aplicativo pode usar essa lógica da mesma maneira que chamaria um método em um objeto. 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 nos servidores de aplicativos Java EE (Java Platform, Enterprise Edition). O ponto principal é que o servidor da Web expõe tudo através do protocolo http, enquanto o servidor de aplicativos não está restrito a ele. Um servidor de aplicativos oferece, portanto, muito mais serviços do que um servidor Web, que normalmente inclui:

• Uma API (proprietária ou não)
• Balanceamento de carga, failover ...
• Gerenciamento do ciclo de vida do objeto
• Gerenciamento de estado (sessão)
• Gerenciamento de recursos (por exemplo, conjuntos de conexões com o banco de dados)

A maioria dos servidores de aplicativos tem o Web Server como parte integrante deles, o que significa que o App Server pode fazer o que for possível. Além disso, o App Server possui componentes e recursos 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) é 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 cenário de servidor da Web / servidor de aplicativos. Um bom exemplo no mundo da Microsoft é o relacionamento do Internet Information Server / SharePoint Server. IIS é um servidor web; O SharePoint é um servidor de aplicativos. O SharePoint fica "em cima" do IIS, executa lógica específica e exibe os resultados via 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 os servidores de aplicativos para conteúdo dinâmico, a maioria dos ambientes de produção possui um servidor da Web que atua como proxy reverso para o servidor de aplicativos. Isso significa que, ao atender uma solicitação de página, o conteúdo estático, como images / Static html, é servido pelo servidor da Web que interpreta a solicitação. O uso de algum tipo de técnica de filtragem (principalmente extensão do recurso solicitado) identifica a solicitação de conteúdo dinâmico e encaminha de forma transparente para o servidor de aplicativos.

Exemplo dessa configuração é o Apache HTTP Server e o BEA WebLogic Server. O Apache HTTP Server é um servidor Web e o BEA WebLogic é um servidor de aplicativos. Em alguns casos, os servidores estão totalmente integrados, como IIS e .NET Runtime. O IIS é um servidor web. quando equipado com o ambiente de tempo de execução .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+

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

Os servidores de aplicativos expõem a lógica de negócios aos clientes. Isso significa que os servidores de aplicativos são compostos por um conjunto de métodos (embora não exclusivamente, pode até ser um computador em rede, permitindo que muitos executem software nele) para executar a lógica de negócios. Portanto, ele 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 o conteúdo HTML para os navegadores (estritamente baseado em HTTP). Os servidores da Web eram capazes de lidar apenas com os recursos estáticos da Web, mas o surgimento de scripts no lado do servidor permitiu que os servidores da Web também manipulassem conteúdo dinâmico. Onde um servidor da Web recebe a solicitação e a direciona para scripts relevantes (scripts PHP, JSP, CGI etc.) para criar o conteúdo HTML a ser enviado ao cliente. Depois que o conteúdo é recebido, o servidor web envia a página HTML para o cliente.

No entanto, hoje em dia esses dois servidores são usados ​​juntos. Onde o servidor da Web recebe a solicitação e chama um script para criar o conteúdo HTML. Em seguida, o script chamará novamente um servidor de aplicativos LOGIC (por exemplo, recuperar detalhes da transação) para preencher o conteúdo HTML.

Portanto, os dois servidores são usados ​​efetivamente.

Portanto ... Podemos dizer com segurança que hoje em dia, na maioria dos casos, 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 geralmente é projetado e implementado para facilitar processos em execução mais longos que também exigirão mais recursos.

Um servidor da web é usado para rajadas curtas que não consomem muitos recursos, geralmente. Isso é principalmente para facilitar a veiculação de tráfego baseado na Web.

Em termos de 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 de 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 suporte a EJB. Um exemplo é o Apache Tomcat.

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), solicitações de clientes para qualquer serviço que forneça e, em seguida, executa algo com base nessas solicitações. (pode ou não envolver uma resposta ao cliente)

Um servidor 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 faz com base nas solicitações recebidas. Geralmente, (como definido originalmente), ele buscava / gerava e retornava uma página da web html ao cliente, obtida de um arquivo html estático no servidor ou construída dinamicamente com base em parâmetros na solicitação de entrada do cliente.

Um servidor web executa o protocolo HTTP para servir páginas da web. Um servidor de aplicativos pode (mas nem sempre) é 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 cenário de servidor da Web / servidor de aplicativos.

Um bom exemplo no mundo da Microsoft é o relacionamento do Internet Information Server / SharePoint Server. IIS é um servidor web; O SharePoint é um servidor de aplicativos. O SharePoint fica "em cima" do IIS, executa uma lógica específica e exibe os resultados via IIS.

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

Em primeira mão, um servidor da web exibe 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 criar e expor processos e lógica de negócios para aplicativos clientes através de vários protocolos, incluindo HTTP em uma arquitetura de n camadas.

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

• Uma API (proprietária ou não)
• Gerenciamento de ciclo de vida de objetos,
• Administração estadual (sessão),
• Gerenciamento de recursos (por exemplo, conjuntos de conexões com o banco de dados),
• 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, foi o reinado de alguns servidores de aplicativos proprietários, como ColdFusion (CFML AS), BroadVision (JavaScript do lado do servidor AS) etc. Mas nenhum deles realmente sobreviveu à era do servidor de aplicativos Java.

Compreensão básica :

Na arquitetura do servidor cliente

Servidor:> Que atende as solicitações.

Cliente:> Que consome serviço.

Servidor Web e servidor de aplicativos são aplicativos de software que atuam como servidores para seus clientes.

Eles receberam seus nomes com base no local de utilização.

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 exemplo: Todos os servidores planos geralmente estão prontos, que servem apenas conteúdo baseado na 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 exemplo: servidores de mapas do Google, servidores de pesquisa do Google, servidores do Google Docs, servidores do Microsoft 365, servidores de visão computacional da Microsoft para IA.

Podemos assumi-los como camadas / hierarquias na arquitetura de 4 camadas / n camadas.

 So they can provide 
                    load balancing,
                    multiple security levels,
                    multiple active points,
                    even they can provide different request processing environments.

Por favor, siga este link para analogias de arquitetura padrão:

https://docs.microsoft.com/pt-br/previous-versions/msp-np/ee658120(v%3dpandp.10)

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

Na verdade, o Apache é um servidor da web e o Tomcat é um servidor de aplicativos. Quando o pedido HTTP chega ao servidor web. Em seguida, o conteúdo estático é enviado de volta ao navegador pelo servidor da web. Existe uma lógica para fazer, então essa solicitação é enviada ao servidor de aplicativos. depois de processar a lógica, a resposta é enviada ao servidor da web e enviada ao cliente.

Todas as opções acima são apenas complicadas demais, algo muito simples. Um servidor de aplicativos contém um servidor da Web, um servidor de aplicativos apenas possui mais algumas adições / extensões do que os servidores da Web padrão. Se você olhar 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 empacotam todas essas coisas para sua conveniência. Para ser totalmente classificado como servidor de aplicativos, você precisa essencialmente cumprir uma lista de ferramentas estabelecidas 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 manipular lógica de negócios (servidor de aplicativos)

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

Um servidor 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 atrás de um servidor web (por exemplo, Apache ou Microsoft Internet Information Services (IIS)) e (quase sempre) na frente de um banco de dados SQL (por exemplo, PostgreSQL, MySQL ou Oracle).

Aplicativos da Web são códigos de computador que são executados no topo de servidores de aplicativos e são escritos no (s) idioma (s) que o servidor de aplicativos suporta e chama as bibliotecas e componentes de tempo de execução que o servidor de aplicativos oferece .

Servidor de aplicativos e servidor da web são usados ​​para hospedar aplicativos da web. O Servidor Web trata do contêiner da Web, por outro lado, o Application Server trata do contêiner da Web, além do contêiner EJB (Enterprise JavaBean) ou COM + para o Microsoft dot Net.

O servidor Web foi projetado para fornecer conteúdo estático HTTP, como HTML, imagens etc., e para o conteúdo dinâmico, existem plugins para suportar linguagens de script como Perl, PHP, ASP, JSP etc. Os servidores abaixo podem gerar conteúdo HTTP dinâmico.

Ambiente de programação do servidor Web:

IIS: ASP (.NET)

Apache Tomcat: Servlet

Jetty: Servlet

Apache: Php, CGI

O Application Server pode fazer o que o servidor Web for capaz e escutar usando qualquer protocolo, bem como o App Server, ter componentes e recursos para oferecer suporte a serviços no nível do 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 +

WAS: EJB

JBoss: EJB

Servidor de aplicativos WebLogic: EJB

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 o IMHO está no modelo de processamento e no gerenciamento de sessões:

No modelo de processamento do servidor Web, o foco está no tratamento de solicitações; a noção de "sessão" é praticamente virtual. Ou seja, a "sessão" é simulada transferindo a representação do estado entre cliente e servidor (daí o REST) ​​e / ou serializando-o para um armazenamento persistente externo (SQL Server, Memcached etc).

No servidor de aplicativos, a sessão geralmente é mais explícita e geralmente assume a forma de um objeto que fica na memória do servidor de aplicativos durante toda a duração da "sessão".

Depende da arquitetura específica. Alguns servidores de aplicativos podem usar protocolos da web nativamente (XML / RPC / SOAP sobre HTTP), portanto, há pouca diferença técnica. Normalmente, um servidor da Web é voltado para o usuário, servindo uma variedade de conteúdo por 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. Obviamente, com o RIA / AJAX, a diferença poderia ser ainda mais nebulosa, servindo apenas conteúdo não HTML (JSON / XML) para clientes que prestam serviços de acesso remoto específicos.

Na OMI, trata-se principalmente de separar preocupações.

Do ponto de vista puramente técnico, você pode fazer tudo (conteúdo da Web + lógica de negócios) em um único servidor da Web. Se você fizer isso, as informações serão incorporadas no interior e solicitarão o conteúdo HTML. Qual seria o impacto?

Por exemplo, imagine que você tenha 2 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 servidores da Web diferentes procurando os mesmos dados no servidor de aplicativos por meio de scripts. No entanto, se você não separar a lógica e mantê-la no servidor da Web, sempre que alterar seu modelo de negócios, você a alterará em todos os servidores da Web que tiverem mais tempo, menos confiáveis ​​e confiáveis. propenso a erros.