Devo usar EJB3 ou Spring para minha camada de negócios?

Question

Minha equipe está desenvolvendo um novo produto orientado a serviços com front-end web.Nas discussões sobre quais tecnologias usaremos, decidimos executar um servidor de aplicativos JBoss e frontend Flex (com possível implantação de desktop usando Adobe AIR) e serviços web para fazer interface entre o cliente e o servidor.

Chegamos a um impasse quando se trata de qual tecnologia de servidor usar em nossa lógica de negócios.A grande discussão é entre EJB3 e Spring, sendo que nossas maiores preocupações são escalabilidade e desempenho, e também manutenibilidade da base de código.

Aqui estão minhas perguntas:

1. Quais são os argumentos a favor ou contra EJB3 vs Spring?
   • Que armadilhas posso esperar de cada um?
   • Onde posso encontrar boas informações de benchmark?

Answer 1

Não haverá muita diferença entre EJB3 e Spring com base no desempenho.Escolhemos o Spring pelos seguintes motivos (não mencionados na pergunta):

• O Spring conduz a arquitetura em uma direção que oferece suporte mais imediato aos testes unitários.Por exemplo, injete um objeto DAO simulado para testar a unidade de sua camada de negócios ou utilize o objeto MockHttpRequest do Spring para testar a unidade de um servlet.Mantemos uma configuração Spring separada para testes unitários que nos permite isolar os testes em camadas específicas.
• Um driver predominante era a compatibilidade.Se você precisar suportar mais de um App Server (ou eventualmente quiser a opção de migrar do JBoss para o Glassfish, etc.), você estará essencialmente carregando seu contêiner (Spring) com você, em vez de depender da compatibilidade entre diferentes implementações do Especificação EJB3.
• Spring permite escolhas de tecnologia para persistência, comunicação remota de objetos, etc.Por exemplo, também estamos usando um front-end Flex e o protocolo Hessian para comunicações entre Flex e Spring.

Answer 2

A diferença entre o EJB3 e o Spring é muito menor do que era, claramente.Dito isto, uma das desvantagens do EJB3 agora é que você só pode injetar em um bean, então você pode acabar transformando componentes em beans que não precisam ser assim.

O argumento sobre testes unitários é bastante irrelevante agora - o EJB3 foi claramente projetado para ser mais facilmente testável em unidades.

O argumento de compatibilidade acima também é irrelevante:quer você use EJB3 ou Spring, você ainda depende de implementações de gerenciadores de transações, JMS, etc. fornecidas por terceiros.

O que seria importante para mim, no entanto, é o apoio da comunidade.Trabalhando em um projeto EJB3 no ano passado, simplesmente não havia muitas pessoas usando-o e falando sobre seus problemas.A primavera, com ou sem razão, é extremamente difundida, principalmente nas empresas, e isso torna mais fácil encontrar alguém que tenha o mesmo problema que você está tentando resolver.

Answer 3

Quais são os argumentos a favor ou contra EJB3 vs Spring?A Spring está sempre inovando e reconhece as restrições do mundo real.Spring ofereceu simplicidade e elegância para os servidores de aplicativos Java 1.4 e não exigiu uma versão da especificação J2EE à qual ninguém tinha acesso em 2004-2006.Neste ponto, é quase um debate religioso no qual você pode ser sugado - Spring + abstração + código aberto versus especificações Java Enterprise Edition (Java EE) 5.0.

Eu acho que a primavera complementa mais do que compete com as especificações Java EE.À medida que os recursos que antes eram exclusivos do Spring continuam a ser incluídos na especificação, muitos argumentarão que o EJB 3 oferece um conjunto de recursos “bom o suficiente” para a maioria dos aplicativos de negócios internos.

Que armadilhas posso esperar de cada um?Se você está tratando isso como um problema de persistência (Spring + JPA) versus EJB3, você realmente não está fazendo uma escolha tão grande.

Onde posso encontrar boas informações de benchmark?Eu não segui o resultados de benchmark specj por algum tempo, mas eles foram populares por um tempo.Parece que cada fornecedor (IBM, JBOSS, Oracle e Sun) está cada vez menos interessado em ter um servidor compatível.As listas de fornecedores certificados ficam cada vez mais curtas à medida que você passa de 1.3, 1.4.1.5 Edição Java Enterprise.Acho que os dias de um servidor gigante totalmente compatível com todas as especificações acabaram.

Answer 4

Eu definitivamente recomendaria o EJB3 na primavera.Descobrimos que ele é mais simplificado, mais agradável de codificar e com melhor suporte.No passado, usei o Spring e achei muito confuso e não tão bem documentado quanto o EJB3 (ou JPA, acho, no final do dia)

1. A partir do EJB3 você não precisa mais lidar com arquivos de configuração externos e há apenas um POJO que você anota por tabela do banco de dados.Este POJO pode ser passado para sua camada web sem problemas.IDEs como o Netbeans podem até gerar automaticamente esses POJOs para você.Usamos o EJB3 agora como back-end para alguns aplicativos de grande escala e não notamos nenhum problema de desempenho.Seus Session Beans podem ser facilmente expostos como serviços da web que você pode expor ao seu frontend Flex.Os beans de sessão são fáceis de bloquear em nível de método ou classe para atribuir funções e coisas assim, se necessário.

Não posso falar muito sobre a primavera, pois só experimentei por algumas semanas.Mas minha impressão geral foi muito ruim.Isso não significa que seja uma estrutura ruim, mas nossa equipe aqui descobriu que o EJB3 é o melhor para a camada de persistência/negócios.

Answer 5

Eu tendo a preferir Spring em vez de EJB3, mas minha recomendação seria qualquer abordagem que você adotar, tente escrever POJOs e usar as anotações padrão sempre que possível, como as anotações JSR como @PostConstruct, @PreDestroy e @Resource que funcionam com EJB3 ou Spring para que você possa escolher a estrutura de sua preferência.

por exemplo.você pode decidir sobre algum projeto para usar o Guice para IoC.

Se você quiser usar injeção de pré-solicitação, como em um aplicativo da web, poderá descobrir que o Guice é um pouco mais rápido para injeção de dependência do que o Spring.

Os beans de sessão se resumem principalmente a injeção de dependência e transações;então EJB3 e Spring são meio parecidos nisso.Onde o Spring tem vantagem é na melhor injeção de dependência e abstrações melhores para coisas como JMS

Answer 6

eu usei uma arquitetura muito semelhante no passado.Spring + Java 1.5 + Actionscript 2/3 quando combinados com Flex Data Services tornaram tudo muito fácil (e divertido!) de codificar.porém, um front-end Flex significa que você precisa de máquinas clientes adequadamente poderosas.

Answer 7

Quanto à sua pergunta:

Quais são os argumentos a favor ou contra EJB3 vs Spring?

Sugiro a leitura da resposta dos especialistas: UMA RESPOSTA PARA:ANÁLISE COMPARATIVA DE EJB 3 E SPRING por Mark Fisher.Leia os comentários para encontrar as observações de Reza Rahman (EJB 3.0).

Answer 8

Outra coisa a favor do Spring é que a maioria das outras ferramentas/frameworks por aí têm melhor suporte para integração com o Spring, a maioria deles também usa o Spring internamente (por exemplo,activemq, camelo, CXF etc.).

Também é mais maduro e há muito mais recursos (livros, artigos, melhores práticas, etc.) e desenvolvedores experientes disponíveis do que para EJB3.

Answer 9

Acho que EJB é uma boa tecnologia de componentes, mas não um bom framework.Spring é o melhor framework disponível atualmente.Portanto, devo considerar o Spring como a melhor implementação de JEE no sentido de um framework e minha recomendação é usar o spring em todos projeto que nos dá a flexibilidade de integração fácil com qualquer tecnologia de componente.