Você, na presente data, use JBoss ou Glassfish (ou outro) como servidor Java EE para um novo projeto? [fechadas]

Question

Se você iniciou um novo projeto Java EE hoje que deve ser concluído em cerca de um ano, que servidor de aplicativos que você escolheria e por quê?

A parte de sua resposta deve incluir seus argumentos para a sua decisão. E também como você tem muita experiência com o servidor Java EE que você escolher e com os outros servidores disponíveis no mercado. Estes são interessantes como todos nós ter uma noção da investigação e do pensamento que foi colocado em sua resposta.

Answer 1

Eu tenho usado WebLogic, WebSphere, JBoss, GlassFish, resina, Jetty, Tomcat, e alguns outros ao longo dos últimos 10 + anos. Então, se eu estava considerando um novo projeto, eu iria me fazer algumas perguntas primeiro. Uma coisa que eu não iria questionar mais é que eu me recusaria plana para JSPs uso a menos que eu foi torturado até que eu chorei por minha mãe.

Eu tenho que ser compatível / deploy para um produto específico por causa do mandato de alguém? Não há nenhuma maneira de ignorá-los ou convencê-los de outra forma? Se assim for, não é a sua resposta.

Eu tenho que usar EJBs? Realmente? Evitá-los, se possível - eles são realmente necessários apenas para sistemas muito grandes, de classe empresarial. Lembre-se que eles são apenas ferramentas, e grandes em que (alguém pode dizer "Golden Sledgehammer"?). Eles são fortemente usado em demasia, então realmente, realmente questionar se você precisar deles. Se você precisar deles, então que remove várias das suas opções, incluindo o meu favorito, Pontão.

Você tem que usar qualquer uma das outras tecnologias J2EE grandes como JMS, ESB, etc? Se assim for, e você realmente não pode fazer sem, então você está novamente restrito a um recipiente J2EE full-blown. Cuidadosamente pensar e investigar antes de se comprometer com BPM, por exemplo, e evitar AquaLogic BPM em (quase) todos os custos -. É feio no extremo

Se você realmente deve usar um recipiente J2EE full-blown, considere-fonte aberto em primeiro lugar porque é mais robusto, melhor suporte e mais rentável. Eles têm bases de clientes maiores e interação apoio mais aberto, então eles tendem a obter melhores correções mais rápido. No entanto, Resin é imaturo e eu gostaria de evitá-lo em relação ao GlassFish ou JBoss - Eu achei problemático para implantar e apoio. Eu preferiria JBoss por causa de sua ampla base de clientes, maturidade, etc. GlassFish é mais difícil de incorporar em um processo de criação / implantação automatizada, mas pode ser mais agradável para algumas das suas características específicas (se você precisar deles).

Eu tenho um motivo especial para necessidade Apache? Em seguida, inclinar-se para Tomcat, talvez mais alguma coisa.

Posso fazer com apenas servlets? Então eu usaria Jetty - é a, mais rápida e fácil solução mais leve, mais flexível. Se estou encostado poder usar Jetty, gostaria de questionar todas as minhas hipóteses do porquê. aplica YAGNI.

Melhor é usar StringTemplate / WebStringTemplate no molhe:. Um jejum, solução limpa, robusta, de fácil manutenção, sem taxas de licenciamento, sólida reputação e apoio, etc., que é onde eu começar hoje

A maioria dos aplicativos / sistemas escolher lotes de fantasia J2EE apresenta quando tudo o que realmente precisamos é de servlets e JDBC com alguma decente arquitetura / design. Pergunta por que você acha que precisa de mais.

Entre os recipientes full-blown, gostaria de evitar WebLogic e WebSphere, a menos que você está apoiando um site público MAJOR (website meu atual empregador é implantado em WebLogic e torna-se onze + milhões de acessos por mês, outros foram comparáveis). do WebLogic verdadeira alegação-se a fama é o seu agrupamento relativamente fácil, mas evitar a sua proprietária fornecedor-lock-in características em (quase) todo o custo. WebSphere é simplesmente um pesadelo que eu evitaria literalmente a todo o custo - Eu me recuso a fazer projetos envolvendo WebSphere depois de ter feito um casal no passado. Nem produto vale a pena as taxas de licenciamento em massa, a menos que você realmente tem uma necessidade especial que impulsiona o uso de um recurso proprietário. Em uma década como um arquiteto / engenheiro sênior para muitas empresas da Fortune 500, tenho ainda de ver essa necessidade. Por outro lado, tenho visto muita dor devido a escolher tais produtos proprietários.

Mesmo para o muito grande de alto tráfego, sites públicos, os produtos proprietários ainda são questionáveis. Eu prefiro gastar esse vários milhões de dólares por ano de taxas de licenciamento em algum hardware bom e algum tempo de qualidade a partir de um punhado de realmente bons consultores para abordar uma solução escalabilidade simples. Os milhões extras por ano poderia, então, ser usado para produziralgo digno de venda naquele belo site ...

EDIT: outra peça para considerar ...

Eu encontrei recentemente Terracotta . Estou repensando tudo, e olhando para implantá-lo em um sistema significativo em breve. Em particular, Terracotta se aglomerando melhor do que qualquer outra coisa, então eu não seria mais recomendável WebLogic para seu agrupamento.

Answer 2

O termo "servidor de aplicação" é ambíguo. Com GlassFish v3, você pode começar pequeno com, digamos, um recipiente web tradicional e evoluir (usando OSGi e simples "contentor add" funcionalidade) para adicionar qualquer coisa que você gostaria: JPA, JAX-RS, EJB, JTA, JMS, ESB , etc ... no entanto, é o mesmo produto, mesma interface de administração, etc. Será que isso se qualifica como um servidor de aplicativos para você? -Alexis (Sun)

Answer 3

A primeira pergunta que eu geralmente me pergunto é "Posso fazer isso com o Tomcat?". Se a resposta é não, porque eu preciso de JMS ou JTA então eu recorrer a um servidor de aplicativos.

Eu costumava WebLogic 8 cerca de 3 anos feliz com facilidade do WebLogic de uso e o modelo de licenciamento / custo. Que usamos para dois projetos foi um serviço web e o outro era um portal. Nós não encontrar qualquer problema com WebLogic ou WebLogic Portal em qualquer desses projectos.

Nos últimos dois anos eu estava trabalhando com o WebSphere. Toda vez que eu negociado com a IBM era sempre acabou custando o dobro do que uma política equivalente, mas corporativo WebLogic ditada WebSphere teve que ser usado. Eu encontrei a curva de aprendizagem no WebSphere a ser consideravelmente mais acentuada do que WebLogic e nosso ciclo de vida / deploy / ensaio de aumento foi tão demorado que usamos Tomcat no ambiente de desenvolvimento. Mas o maior problema que tive com o WebSphere foi quando encontrou um bug que nos obrigou a atualizar para a versão do patch próxima apenas para correr em novo web.xml problema de análise. Demorou um turno de 48 horas de trabalho por tudo isso.

No momento que eu estou usando JBoss. Cerca de 3 meses atrás, eu estava prestes a embarcar em meu novo projeto com Tomcat e Jetspeed 2, Mas notei que Jetspeed 2 parece um pouco estagnada agora e JBoss Portal 2.7.0 foi liberado apenas com JSR apoio 286 / Portlet 2.0. Eu dei JBoss um giro e achei muito fácil de set-up e administrar. O ciclo de build / deploy / teste é muito rápido e eu raramente é necessário reiniciar o servidor a menos que eu mudei a algum lugar do arquivo XML da Primavera.

Answer 4

Estou usando o JBoss por 3-4 anos.

Argumentos para JBoss:

1. Open source.
2. Suporte comercial disponível.
3. Grande, comunidade de usuários ativos.

Argumentos contra JBoss:

1. No-acesso geral, apoiado Java EE versão 5 recipiente.
2. Muita documentação, mas detalhado; Pode ser difícil encontrar as respostas a "Como eu faço x?"
3. ferramentas administrativas para 4.x baixa comparado com outras ofertas comerciais.

Answer 5

Checkout GlassFish 3.1! Construído no topo da modular, Java EE 6 com base GlassFish v3 kernel, a versão 3.1 oferece clustering, administração centralizada e alta disponibilidade.

Consulte http://blogs.oracle.com/nazrul/entry/glassfish_3_1 para mais detalhes.

Answer 6

Outro ponto que não foi discutido aqui é o desempenho. Se esta é uma preocupação por causa do tipo de serviço ou por causa do número de usuários, em seguida, o seguinte será aplicável:

• Tomcat parece ser mais lento do que Glassfish
• Glassfish parece ser mais lento do que a resina
• A resina é muito mais lento do G-WAN + Java

Note que G-WAN depende da JVM sozinho:. Ele não usa quaisquer recipientes (a menos que especificado explicitamente), de modo que você pode reservá-lo a partes de suas aplicações web de desempenho crítico

Como G-WAN suporta outras linguagens (C, C ++, C #, D, Objective-C), você pode até processar algumas partes das aplicações em matéria-C, mantendo Java para outras tarefas.

Answer 7

Eu poderia incluir o seu sistema operacional preferido como um critério de decisão. Ele deve tornar mais fácil para apoiar se você estiver usando o mesmo fornecedor para OS e servidor de aplicações. Se você já tem um relacionamento com um ou ambos os vendedores considerar se eles são bons para lidar com eles.

De uma perspectiva técnica eu escolheria GlassFish porque tem suporte para as inovações mais recentes. Eu não acho que JBoss é ruim de qualquer maneira ele simplesmente não é tão up-to-date.

A maioria da minha experiência é em WebLogic mas eu usei JBoss e GlassFish. Eu só lançou um novo site em uma pilha completa Sun open source (OpenSolaris, GlassFish, MySQL) e foi uma grande experiência com apenas pequenas frustrações.

Answer 8

Eu ainda acho que WebLogic é o melhor servidor de aplicações Java EE no mercado. Eu acho que vale a pena do que se você pode pagar essas taxas de licença.

Eu fui surpreendido ao ver o quão longe você pode ir combinando Tomcat, OpenEJB e ActiveMQ. Isso parece-me ser uma alternativa de baixo custo.

Eu também olhar para o dm Primavera Server. É baseado em Tomcat, mas acho que a peça OSGi eles adicionaram no poderia estar em toda parte na ordem curta. Se for feito com a mesma qualidade que o framework Spring, vai ser realmente muito bom.

Answer 9

Uma alternativa:. Uso não appserver em tudo

Confira http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

Para projetos Web, manter um container web luz, se você tem que, combinado com algo como Wicket para evitar a complexidade da JSP / JSF ou suportes.

HTH Guy