JBoss vs Tomcat novamente [fechado]


138

Essa será a pergunta antiga (qual é :)), qual servidor é melhor entre o Tomcat e o JBoss, mas ainda não encontrei uma resposta boa o suficiente para resolver o meu problema.

Eu sei que o Tomcat é apenas um mecanismo de servlet e o JBoss oferece muito mais funcionalidades prontas para uso, mas o que eu não entendo é por que o Tomcat é melhor usar em algumas situações do que o jboss. Li em algum lugar que o JBoss tem uma arquitetura conectável e, se necessário, você pode desconectar os recursos do JBoss para torná-lo essencialmente um contêiner de servlet do tomcat. Se for esse o caso, não é melhor fazê-lo em vez de usar o Tomcat, a fim de deixar espaço para conectar as coisas de volta.

Outra explicação que acho a favor do Tomcat é que ele é leve, significa menos necessidade de memória ou permite uma resposta mais rápida. Novamente, eu preciso saber que o jboss não carregará componentes conforme o requisito, ou seja, se eu estiver usando apenas servlets, o jboss não ignorará o restante dos recursos e se tornará leve automaticamente.

Essencialmente, meu aplicativo não possui nenhum recurso Java EE, mas os argumentos 'leves' a favor do Tomcat não parecem convincentes o suficiente por causa dos motivos mencionados acima.

Por favor ajude.

Edit: Decidimos finalmente usar o tomcat na época e o usamos há mais de 6 meses com grande facilidade de uso. De fato, encontramos um uso prático em que poderíamos facilmente executar várias instâncias do tomcat na mesma máquina servidor para desenvolvedores diferentes; o mesmo poderia ter sido muito difícil com o jboss.

Eu achei o tomcat livre de problemas para o nosso trabalho e, portanto, pode ser a escolha certa quando você não estiver usando muitos recursos do Java EE. PS: Observe que ainda usamos o Spring e o Hibernate com o Tomcat


1
O JBoss não se integra ao Tomcat?
Navi

4
@ Navi: Na verdade não. Ele contém a versão bifurcada da base de código do Tomcat, mas divergiu bastante.
skaffman

1
Um aplicativo da web simples, sem recursos do j2ee, deve ser implementado facilmente em qualquer contêiner de servlet compatível. Dado isso, não deve importar muito qual deles você usa antecipadamente. Eu começaria com a mais simples de implantar (o Tomcat e o Jetty me serviram bem no passado).
Joel

3
Para sua informação, no final de 2011, o Tomcat recebeu o certificado JavaEE 6 como TomEE para responder a essa pergunta antiga.
David Blevins

1
um ques fechado com cerca de 150 mil visualizações, 125 upvotes e 0 downvotes? !! Eu sei que essas são as regras, mas devo dizer que essas regras devem ser um pouco alteradas.
Muhammed Refaat

Respostas:


132

Primeiro os fatos, nem é melhor . Como você já mencionou, o Tomcat fornece um contêiner de servlet que suporta a especificação de Servlet (o Tomcat 7 suporta o Servlet 3.0). O JBoss AS, um servidor de aplicativos 'completo' suporta Java EE 6 (incluindo o Servlet 3.0) em sua versão atual.

O Tomcat é bastante leve e, se você precisar de certos recursos Java EE além da API do Servlet, poderá aprimorar facilmente o Tomcat fornecendo as bibliotecas necessárias como parte do seu aplicativo. Por exemplo, se você precisar de recursos JPA, poderá incluir o Hibernate ou OpenEJB e o JPA funcionará quase que imediatamente .

Como decidir se deve usar o Tomcat ou um Java EEservidor de aplicativos de pilha cheia :

Ao iniciar seu projeto, você deve ter uma idéia do que ele requer. Se você estiver em um grande ambiente corporativo, o JBoss (ou qualquer outro servidor Java EE) pode ser a escolha certa, pois fornece suporte interno para, por exemplo:

  1. Sistema de mensagens JMS para integração assíncrona
  2. Mecanismo de Serviços da Web (JAX-WS e / ou JAX-RS)
  3. Recursos de gerenciamento como JMX e uma interface de administração com script
  4. Segurança avançada, por exemplo, integração imediata com diretórios de terceiros
  5. Arquivo EAR em vez de suporte apenas a arquivos WAR
  6. todos os outros "ótimos" recursos Java EE que não me lembro :-)

Na minha opinião, o Tomcat se encaixa muito bem em aplicativos voltados para o usuário, centrados na Web. Se a integração de back-end entrar em ação, um servidor de aplicativos Java EE deve ser (pelo menos) considerado. Por último, mas não menos importante, a migração de um WAR desenvolvido para o Tomcat para o JBoss deve ser um exercício de 1 dia.

Segundo, você também deve levar em consideração o uso dentro do seu ambiente. Caso sua organização já execute, digamos, 1.000 instâncias do JBoss, você pode sempre segui-lo, independentemente de seus requisitos concretos (considere aspectos como custo de operações ou aprimoramento). Obviamente, isso se aplica vice-versa.

meus 2 centavos


13

Dê uma olhada no TOMEE

Possui todos os recursos necessários para criar um aplicativo Java EE completo.


7

Eu certamente procuraria o TomEE, já que a idéia por trás disso é manter o Tomcat trazendo toda a integração do JavaEE 6 ausente por padrão. Esse é um tipo de compromisso muito bom


6

Estritamente falando; Sem os recursos Java EE, seu aplicativo quase não precisa de um servidor de aplicativos ;-)

Como outros já apontaram, o JBoss possui uma pilha Java EE (mais ou menos) completa, enquanto o Tomcat é apenas um contêiner da web. O JBoss pode ser configurado para servir apenas como um contêiner da web, seria apenas um invólucro fino ao redor do contêiner da web tomcat incluído. Dessa forma, você poderia ter um JBoss quase tão leve, que na verdade seria apenas um "invólucro" fino em torno do Tomcat. Isso seria quase tão leve.

Se você não precisa de nenhum dos extras que o JBoss tem a oferecer, escolha o que mais lhe agrada. Qual é mais fácil de configurar e manter para você?


1
Quão difícil é para usar os serviços da web e JMX com tomcat, você pode fornecer algumas boas referências / links
Ashish

2

Também li que, para alguns servidores, por exemplo, é necessário apenas anotar contextos de persistência, mas em alguns servidores, a injeção deve ser feita manualmente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.