Applilcation Server sem EJB

Jedi_FeniX:

Vale a pena usar um application server sem usar EJB?
Por exemplo usar o app server só para controle de transações e criação de pool de conexões com o banco de dados? Ou seja, gostaria de saber os casos que seriam interessantes usar um application server ao invés de um servlet container.

Sim. Procure por Spring Framework, ele eh sua resposta… Com ele vc possui controle de transacoes e suporte a pool de conexoes de banco de dados independente de container.

Então seria interessante ter jboss + spring + hibernate, mesmo se não for usar ejb?

Qual o ganho que eu tenho escolhendo um application server em vez de um servlet container? Por exemplo passar a desenvolver no jboss ao invés de um tomcat?
Pergunto isso porque estou começando agora nos applications servers e queria entender melhor eles e o porque de usar eles.
Fiz algumas pesquisas no google, mas o conceito ainda não está muito claro.

Olá

Não sei porque você criou o mesmo tópico de novo. Acabou recebendo a mesma resposta que eu dei com a sugestão de usar Spring e/ou Hibernate

Mas se a sua dúvida é sobre o que um servidor do tipo JBoss faz a mais do que o Tomcat (ou o Jetty) então vou dizer algumas coisas para explicar (ou não):

• O JBoss usa um servlet conteiner que pode ser o tomcat —> para servir servlets (e JSPs)

• O tomcat (ou o Jetty) não serve para aplicações que usam EJBs porque como disse antes, são apenas servlet conteiners.

Se você não vai usar EJBs, pode se contentar com o tomcat (ou o Jetty). Para transações tanto o tomcat como o Jetty não ajudam em nada. Quem pode ajudar nisto é o Hibernate e/ou o Spring.

Para complicar sua cabeça vou dizer que se pode usar o JBoss (ou o Glassfish ou outro similar) mesmo quando não se usa EJBs. Porque alguém faria isto? Porque o JBoss ou o Glassfish incluem facilidades de administração e clusterização que podem ser muito úteis.

Um conselho: esqueça o que o servidor de aplicação poderá fazer por você quanto ao controle de transações porque na verdade mesmo o JBoss não faz nada sozinho. Estude Hibernate e JPA antes de pensar em controlar transações seja lá como for. Depois veja como o Spring pode ajudar nisto. E vale a pena estudar EJBs 3.0 (nem passe perto dos antigos EJBs 2.x que foram a maior bobagem que já conheci em 40 anos que vivo na informática)

[]s
Luca

Postei o tópico aqui porque achei que aqui fosse o local certo, só esqueci de postar no antigo que mudei para cá… hehehe… :oops:, peço desculpas por isso…
JPA eu sei tanto que já uso, só que eu crio as minhas DAOs com o EntityManager dentro delas e desta maneira estou “confundido as coisas”, ou seja, o DAO que está responsável por pegar um entitymanager, abrir a transação, dá um commit, fazer a persistencia ou a busca e fechar a transação.
Isso funciona muito bem, usando o tomcat e wicket mas queria aumentar mais o desacoplamento das minhas classes por isso comecei a pesquisar sobre application server, que me falaram que ele faria isso (controle de transações).
E no outro tópico eu coloquei que já usava JPA…

Olá

Então… não faz mas contém as classes que os EJBs usa para fazer. E é você quem escreve os EJBs.

Mesma coisa com o Spring.

[]s
Luca

Existem vários Transaction Managers que você pode colocar no Tomcat/Jetty. No momento lembro dois JOTM e do Bitronix, mas lembro que existem outros. Só dar uma procurada que você acha.

Muito obrigado pelas respostas elas estão ajudando muito.
Pelo que vi vale mais apenas usar EJB se for usar em um sistema distribuído, um dos motivos das minhas dúvidas.
Comecei a ler sobre EJB a um tempo atrás mas vi que se tem muito mais trabalho e muito mais codificação, mas vi que um app server te dá algumas facilidades, como o luca falou em um post anterior, mas só que a minha aplicação não chegaria a usar mais de um pc para reallizar as suas tarefas.
E por isso criei o tópico… para tentar esclarecer estas dúvidas.
Agora gostaria de esclarecer algumas coisas o Spring também é um container?
thiagoks valeu pela dica, mas por enquanto vou focar no Spring…

Olá

EJBs 3.0 não são tão complicados como os anteriores (que se você aprendeu alguma coisa é bom esquecer) e podem ser usados em uma aplicação não distribuída. Aliás, pouquíssimas aplicações necessitam ser distribuídas. É muito raro precisar distribuir uma aplicação mas por aí você encontra um monte de aplicações que foram desenvolvidas de modo distribuído sem nenhuma necessidade.

O Spring é uma espécie de framework. É pouco mais do que uma API. E você nem precisa usar tudo que ele oferece. Pode ir aprendendo aos poucos.

[]s
Luca

Então seu eu quiser fazer uma aplicação de “médio porte” seria interessante usar EJB? Qual conselho você daria de quando usar EJB?
E em relação ao Spring eu vi que ele faz injecção de dependência, se na minha classe DAO eu tenho um atributo do tipo EntityManager o Spring "coloca"uma instância do Entity Manager detro do DAO, mas de qualquer maneira o DAO ainda “fica dependente”, qual o ganho que eu tenho?

Olá

A vantagem de aprender EJBs 3.0 é que não é só de persistência que ele trata. Mas se é só persistência seu problema então JPA (e/ou hibernate) dão conta. E ambos servem para aplicações de pequeno, médio e grande porte.

O Spring dá várias vantagens. Leia a documentação que é melhor do que minha eventual resposta. Se fosse só pela injeção de dependência há outras APIs mais simples. Mas você já falou em transações.

[]s
Luca

É pelo visto tenho que mudar o meu conceito em relação ao EJB… hauhauahua… 8)
Valeu cara pela ajuda!
Vou estudar mais sobre o assunto e por enquanto vou ficar com o Spring para fazer este controle.

Oi Jedi_FeniX, você pode utilizar um transaction manager junto com o Spring sem problemas. Só vai precisar mudar algumas configurações no seu xml. Depois dê uma olhada no capítulo sobre transações na documentação do Spring.

Se você for utilizar mais de um banco de dados ou outros elementos (mensageria) aí você vai ser obrigado a colocar isso no container, senão é mais simples ficar com as transações do hibernate / jdbc mesmo.

O uso de EJB não é restrito somente a sistemas distribuídos.

O uso de EJB torna o sistema mais escalável, pois o servidor de aplicação que controla o processamento dos EJBs.

Abrindo um parênteses, um sistema escalável permite que manipular uma porção crescente de trabalho de forma uniforme. O uso de EJB em um servidor de aplicação, torna esse desenvolvimento transparente.

Não sei se ajudei a entender ou compliquei mais… hehehe

Olá

jeancz:

O uso de EJB torna o sistema mais escalável, pois o servidor de aplicação que controla o processamento dos EJBs.

Abrindo um parênteses, um sistema escalável permite que manipular uma porção crescente de trabalho de forma uniforme. O uso de EJB em um servidor de aplicação, torna esse desenvolvimento transparente.

O uso de certas palavras na área de TI representam verdadeiras armadilhas. Escalabilidade e escalável são algumas delas mais comuns.

Agora você precisa explicar porque o uso de EJB torna o sistema mais escalável. E ainda terá a dura missão de dizer como imagina que seria manipular uma porção crescente de trabalho de forma uniforme e ainda com desenvolvimento transparente.

Nem imagino como possa sair da enrascada em que se colocou. Aconselho a não mais misturar termos perifosos.

[]s
Luca

Luca:

Olá

jeancz:

O uso de EJB torna o sistema mais escalável, pois o servidor de aplicação que controla o processamento dos EJBs.

Abrindo um parênteses, um sistema escalável permite que manipular uma porção crescente de trabalho de forma uniforme. O uso de EJB em um servidor de aplicação, torna esse desenvolvimento transparente.

O uso de certas palavras na área de TI representam verdadeiras armadilhas. Escalabilidade e escalável são algumas delas mais comuns.

Agora você precisa explicar porque o uso de EJB torna o sistema mais escalável. E ainda terá a dura missão de dizer como imagina que seria manipular uma porção crescente de trabalho de forma uniforme e ainda com desenvolvimento transparente.

Nem imagino como possa sair da enrascada em que se colocou. Aconselho a não mais misturar termos perifosos.

[]s
Luca

É sempre bom poder discutir um pouco sobre algum termos com colegas da área.

Sempre nos deparamos com uma sopa de letrinhas, termos, siglas e as vezes é difícil entende-las. Uma maneira bem simples para definir escalabilidade é a capacidade que uma aplicação tem de se adaptar a diferentes cenários de uso. Uma exemplo bem fácil de entender, uma aplicação escalável poderia atender de 10 a 10.000 usuários simultâneos.

A pergunta que nos fazemos é, como o uso EJB contribui para deixar uma aplicação mais escalável??

Umas das maneiras de aumentar a capacidade de processamento e memória do nosso servidor de aplicação é adicionar mais máquinas criando um cluster. Como o servidor de aplicação gerencia a execução dos EJBs, ele passa a executar estes EJBs em qualquer uma dessas máquinas do cluster.

Olá

jeancz:

Uma exemplo bem fácil de entender, uma aplicação escalável poderia atender de 10 a 10.000 usuários simultâneos.

A pergunta que nos fazemos é, como o uso EJB contribui para deixar uma aplicação mais escalável??

Umas das maneiras de aumentar a capacidade de processamento e memória do nosso servidor de aplicação é adicionar mais máquinas criando um cluster. Como o servidor de aplicação gerencia a execução dos EJBs, ele passa a executar estes EJBs em qualquer uma dessas máquinas do cluster.

Conhece algum caso em isto tenha acontecido e onde a opção pelo uso de EJBs tenha contribuído de forma decisiva para se obter tão maravilhoso ambiente? Tem certeza de que o que contribuiu para a escalabilidade não foram outros fatores sem nada a ver com EJBs e principalmente sem nada a ver com o servidor de aplicação? Por exemplo: dizem que o uso de um bom cache faz muito mais efeito.

[]s
Luca

Vários exemplos, mas como estou detectando certa hostilidade paro por aqui.

Olá

Nenhuma hostilidade e se você entendeu assim, peço desculpas. Só tento mostrar que a opção de uso de EJBs não tem nada a ver com escalabilidade. Aliás, muitas vezes tem a ver com dificuldades na escalabilidade.

Os EJBs a partir do 3.0 são ótimos, tem muita serventia, abreviam certos caminhos mas seu uso não representa nenhuma garantia de escalabilidade. Há que ter cuidado ao associar a palavra escalabilidade a alguma ação isolada porque para um site escalar é preciso um conjunto de ações. É claro que não é todo mundo que precisa da escalabilidade do Youtube ou do ebay. Aliás bem poucos sites precisam de escalabilidade. Mas para os que precisam, os exemplos do Youtube, ebay e outros são esclarecedores. Sugiro a leitura de alguns dos links abaixo:

http://kylecordes.com/2007/07/12/youtube-scalability/

http://video.google.com/videoplay?docid=-6304964351441328559

http://gc.blog.br/2007/11/09/qcon-2007-randy-shoup-the-ebay-architecture/ (em português um resumo da palestra abaixo)

http://www.infoq.com/articles/ebay-scalability-best-practices (ver por exemplo um erro muito comum no uso dos EJBs < 3.0: Best Practice #3: Avoid Distributed Transactions)

http://www.google.com/search?q=scalability+site:www.infoq.com

http://highscalability.com/

Mais dois:

E ainda acrescento…

Sobre os EJBs anteriores ao 3.0 já escrevi aqui várias vezes que foram a maior idiotice que já vi em mais de 40 anos que vivo na área de desenvolvimento de sistemas. E o uso deles geralmente acarretava um enorme dispêndio de recursos. Sei de alguns projetos que infelizmente não posso descrevê-los aqui, que gastaram muitos milhões de reais em máquinas, sistemas, servidores e cujo resultado foi absolutamente fraco em relação ao que foi prometido. Na história do uso do Java nas grandes corporações os EJBs < 3.0 estão associados a todos os casos de fracassos. Mas se você perguntar à IBM, Oracle ou gente da antiga BEA, nenhum deles vai admitir que os servidores de aplicações que venderam como panacéia de todos os males fazem parte do fracasso.

Insisto, usar EJBs tem mais a ver com dificuldades do que com facilidades de escalabilidade. É melhor usar alguma coisa que impeça ou desestimule o programador de manter estados do que algo que é muito fácil escrever código difícil de escalar porque mantém estado.

[]s
Luca

Uau Luca, muito informativo esse post, favoritado!
Assim que chegar em casa começo a minha leitura nos tópicos citados.
Luca, aproveitando o assunto seria possível você dizer algo sobre Patterns com EJB3?
Fiz algumas pesquisas e o que encontrei foram testemunos de que mudam muitos conceitos quando se utiliza EJB3, confere?

Muito obrigado!

Olá

Tchello:

… seria possível você dizer algo sobre Patterns com EJB3?
Fiz algumas pesquisas e o que encontrei foram testemunos de que mudam muitos conceitos quando se utiliza EJB3, confere?

Sim, os conceitos mudaram e para melhor. Quanto aos padrões não acho que ninguém deva se preocupar com isto até ter problemas. Adotar um padrão porque leu por aí que alguém diz que são melhores acaba dificultando entendimento do caso de uso do padrão. É melhor sofrer um pouquinho tentando usar para depois refatorar.

Se quiser buscar padrões procure os mesmos de JPA no caso de usar EJBs para persistência e padrões de integração para os MDBs.

E os textos sobre EJB 3.0 já dão dicas de como usá-los.

[]s
Luca