Se você iniciou um novo projeto Java EE hoje, que deve ser concluído em cerca de um ano, qual servidor de aplicativos você escolheria e por quê?
Parte da sua resposta deve incluir seus argumentos para sua decisão. E também quanta experiência você possui com o servidor Java EE que você escolher e com os outros servidores disponíveis no mercado. Isso é interessante, pois todos temos uma noção da investigação e do pensamento que foram colocados em sua resposta.
Respostas:
Eu usei WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat e alguns outros nos últimos 10 anos. Portanto, se eu estivesse pensando em um novo projeto, me perguntaria primeiro algumas perguntas. Uma coisa que eu não questionaria mais é que eu me recusaria a usar JSPs, a menos que eu fosse torturada até chorar pela minha mãe.
Preciso ser compatível / implantar em um produto específico por causa do mandato de alguém? Não há como ignorá-los ou convencê-los do contrário? Se sim, aí está sua resposta.
Eu tenho que usar EJBs? Realmente? Evite-os, se possível - eles são realmente necessários apenas para sistemas corporativos muito grandes. Lembre-se de que eles são apenas ferramentas, e grandes ferramentas (alguém pode dizer "Marreta Dourada"?). Eles são muito usados, de modo que realmente questionam se você precisa deles. Se você precisar deles, isso removerá várias de suas opções, incluindo o meu favorito, Jetty.
Você precisa usar alguma das outras principais tecnologias J2EE, como JMS, ESB, etc? Nesse caso, e você realmente não pode prescindir, estará novamente restrito a um contêiner J2EE completo. Pense e investigue cuidadosamente antes de se comprometer com o BPM, por exemplo, e evite o AquaLogic BPM a (quase) todos os custos - é feio ao extremo.
Se você realmente deve usar um contêiner J2EE completo, considere o código-fonte primeiro porque é mais robusto, melhor suportado e mais econômico. Eles têm uma base maior de clientes e uma interação de suporte mais aberta, portanto, tendem a obter melhores correções mais rapidamente. No entanto, a resina é imatura e eu a evitaria em relação ao GlassFish ou JBoss - achei problemático implantar e dar suporte. Eu preferiria o JBoss por causa de sua ampla base de clientes, maturidade, etc. O GlassFish é mais difícil de incorporar em um processo automatizado de criação / implantação, mas pode ser mais agradável para alguns de seus recursos específicos (se você precisar).
Tenho um motivo especial para precisar do Apache? Então incline-se para o Tomcat, talvez mais alguma coisa.
Posso me contentar com apenas servlets? Então eu usaria o Jetty - é a solução mais leve, rápida, fácil e flexível. Se eu me inclino a não poder usar o Jetty, questionaria todas as minhas suposições sobre o porquê. YAGNI se aplica.
O melhor é usar o StringTemplate / WebStringTemplate no Jetty: uma solução limpa, robusta, rápida e sustentável, sem taxas de licenciamento, reputação e suporte sólidos, etc. É aí que começo hoje.
A maioria dos aplicativos / sistemas escolhe muitos recursos sofisticados do J2EE quando tudo o que eles realmente precisam é de servlets e JDBC com uma arquitetura / design decente. Pergunta por que você acha que precisa de mais.
Dos contêineres completos, eu evitaria o WebLogic e o WebSphere, a menos que você suporte um site público MAJOR (o site do meu empregador atual é implementado no WebLogic e recebe onze milhões de acessos por mês, outros são comparáveis). A verdadeira reivindicação da fama do WebLogic é seu agrupamento relativamente fácil, mas evita os recursos proprietários de bloqueio de fornecedor a (quase) todo o custo. O WebSphere é simplesmente um pesadelo que eu evitaria literalmente a todo custo - eu me recuso a fazer projetos envolvendo o WebSphere depois de ter feito alguns no passado. Nenhum dos produtos vale as enormes taxas de licenciamento, a menos que você realmente tenha uma necessidade especial que incentive o uso de um recurso proprietário. Em uma década como arquiteto / engenheiro sênior de muitas empresas da Fortune 500, ainda não vi essa necessidade. Por outro lado,
Mesmo para sites públicos grandes e de alto tráfego, os produtos proprietários ainda são questionáveis. Prefiro gastar esses milhões de dólares por ano em taxas de licenciamento em um bom hardware e um tempo de qualidade de um punhado de bons consultores para resolver uma solução simples de escalabilidade. Os milhões extras por ano poderiam então ser usados para produzir algo digno de vender naquele belo site ...
EDIT: outra peça a considerar ...
Encontrei recentemente terracota . Estou repensando tudo e pretendo implantá-lo em um sistema significativo em breve. Em particular, a Terracotta faz o cluster melhor do que qualquer outra coisa, então eu não recomendaria mais o WebLogic por seu cluster.
O termo "servidor de aplicativos" é ambíguo. Com o GlassFish v3, você pode começar pequeno com, digamos, um contêiner da Web tradicional e evoluir (usando OSGi e a funcionalidade simples "adicionar contêiner") para adicionar o que quiser: JPA, JAX-RS, EJB, JTA, JMS, ESB , etc ... No entanto, é o mesmo produto, a mesma interface administrativa, etc. Isso se qualifica como servidor de aplicativos para você? -Alexis (Sol)
A primeira pergunta que normalmente me faço é "Posso fazer isso com o Tomcat?". Se a resposta for não, porque preciso do JMS ou JTA, recorro a um servidor de aplicativos.
Eu usei o WebLogic 8 há cerca de 3 anos, satisfeito com a facilidade de uso do WebLogic e o modelo de licenciamento / custo. Nós o usamos em dois projetos, um era um serviço da Web e o outro, um portal. Não encontramos nenhum problema com o WebLogic ou o WebLogic Portal em nenhum desses projetos.
Nos últimos dois anos, eu estava trabalhando com o WebSphere. Sempre que negociava com a IBM, sempre acabava custando o dobro do equivalente a um WebLogic, mas a política corporativa determinava que o WebSphere precisava ser usado. Achei que a curva de aprendizado no WebSphere era consideravelmente mais íngreme que o WebLogic e nosso ciclo de vida de construção / implementação / teste consumia tanto tempo que usamos o Tomcat no ambiente de desenvolvimento. Mas o maior problema que tive com o WebSphere foi quando encontramos um bug que nos forçou a atualizar para o próximo release de patch apenas para encontrar um novo problema ao analisar o web.xml. Foi preciso um turno de 48 horas para resolver tudo isso.
No momento, estou usando o JBoss. Há cerca de três meses, eu estava prestes a embarcar no meu novo projeto com o Tomcat e o Jetspeed 2, mas notei que o Jetspeed 2 parece um pouco estagnado no momento e o JBoss Portal 2.7.0 foi lançado com o suporte ao JSR 286 / Portlet 2.0. Dei uma olhada no JBoss e achei muito fácil configurar e administrar. O ciclo de criação / implantação / teste é muito rápido e raramente preciso reiniciar o servidor, a menos que eu tenha alterado um arquivo XML Spring em algum lugar.
Uso o jBoss há 3-4 anos.
Argumentos para o jBoss:
Argumentos contra o jBoss:
Checkout GlassFish 3.1! Construída sobre o kernel GlassFish v3 modular baseado em Java EE 6, a versão 3.1 oferece armazenamento em cluster, administração centralizada e alta disponibilidade.
Consulte http://blogs.oracle.com/nazrul/entry/glassfish_3_1 para obter mais detalhes.
Outro ponto que não foi discutido aqui é o desempenho. Se essa é uma preocupação devido ao tipo de serviço ou ao número de usuários, o seguinte será aplicável:
Observe que a G-WAN depende apenas da JVM: ela não usa outros contêineres (a menos que seja especificado explicitamente); portanto, você pode reservá-la para partes críticas de desempenho de seus aplicativos da web.
Como a G-WAN suporta outras linguagens (C, C ++, C #, D, Objective-C), você pode até processar algumas partes dos aplicativos em C bruto, mantendo o Java para outras tarefas.
Eu posso incluir o seu sistema operacional preferido como critério de decisão. Deve facilitar o suporte se você estiver usando o mesmo fornecedor para SO e servidor de aplicativos. Se você já tem um relacionamento com um ou ambos os fornecedores, considere se eles são bons para lidar.
Do ponto de vista técnico, eu escolheria o GlassFish porque ele suporta inovações mais recentes. Eu não acho que o JBoss seja ruim de qualquer maneira, simplesmente não é tão atualizado.
A maior parte da minha experiência é no WebLogic, mas usei o JBoss e o GlassFish. Acabei de lançar um novo site em uma pilha completa de código aberto da Sun (OpenSolaris, GlassFish, MySQL) e foi uma ótima experiência com apenas pequenas frustrações.
Ainda acho que o WebLogic é o melhor servidor de aplicativos Java EE do mercado. Acho que vale a pena se você puder pagar essas taxas de licença.
Fiquei surpreso ao ver até onde você pode ir combinando Tomcat, OpenEJB e ActiveMQ. Isso me pareceria uma alternativa de baixo custo.
Eu também procuraria no Spring dm Server. É baseado no Tomcat, mas acho que a parte OSGi que eles adicionaram pode estar em qualquer lugar em pouco tempo. Se for feito com a mesma qualidade que o framework Spring, será realmente muito bom.
Uma alternativa: não use nenhum servidor de aplicativos.
Verificação de saída http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .
Para projetos da Web, mantenha um contêiner da Web leve, se necessário, combinado com algo como o Wicket para evitar a complexidade do JSP / JSF ou struts.
HTH Guy