Vocês usam ou não EJBs?

Programação Java
#21

:smiley:

Para eu ser Evangelist, teria que entender muito bem do assunto, como não é o meu caso! :wink:

Apenas não sou fundamentalista como um monte de gente que vejo por aí, que não gosta de EJB (ou qualquer outra tecnologia que esteja na moda ser malhada) simplesmente porque não gosta! :slight_smile:

Meu objetivo aqui é aprender e é por isso que eu questiono certas coisas.

Respostas como “Existem várias tecnologias que fazem o mesmo que EJB faz” não me dizem muita coisa, pois eu quero entender porque são melhores ou piores e não apenas saber que existem.

Abraços,
Marco Campêlo

#22

Olá

Eu deveria ter me dado ao trabalho de distribuir 5 estrelas para todos que escreveram neste tópico. Acho que as respostas até aqui foram de nível altíssimo e bem aquilo que eu estava precisando ler. Ainda espero aprender mais.

[quote=saoj]Rolou uma discussão semelhante em:
http://www.portaljava.com.br/home/modules.php?name=Forums&file=viewtopic&t=14198&sid=4c6967e2e9bfc6e842292f28a4685b62[/quote]

Dei 5 estrelas para o Sérgio pelo favor de incluir este fantástico link com a brilhante disputa Shoes x Murai. Muito bom mesmo!

Detalhe: A discussão do Portal Java começou na véspera do Carnaval e e passou do desfile das campeãs. Carnaval de nerd é discutir EJBs!

[]s
Luca

#23

O Murai trabalha comigo, mas em outros projetos! Ele tem experiência como Java. Foi o primeiro no estado a tirar SCJP e tbm tem SCEA. Ele acabou de implantar um sistemas usando muitos EJBs e muito requisitado (users/dia).

Eu que acabei indicando aquele post e outros links do GUJ sobre discussão de EJB e Struts, principalmente, já que ele adora estas duas tecnologias.

#24

De forma resumida, o que tenho a dizer sobre EJBs é: MDBs são muito úteis e Session Beans também. Uma das arquiteturas do genesis inclusive usa um Session Bean de forma invisível ajudando a tirar proveito das características de seu servidor de aplicação.

#25

Atualmente estou num projeto que usa Hibernate para persistência, com uma camada de Stateless Session Beans com Container-Managed Transactions acima disso. Funciona bem, e, com XDoclet fica relativamente fácil de trabalhar. Mas isso seria facilmente resolvido pelo Spring.

Além disso, a gente usa MDBs pra fazer processamento paralelo dentro do Container. E também funciona bem. Não sei como seria a solução pra esse tipo de problema sem usar MDBs. Alguém?

Enfim, acho que EJB tem seus usos. Mas como todo mundo já disse, 99% dos casos, hoje em dia, não precisam.

[]'s

#26

As IDEs resolvem mas mesmo assim vc programa sem entender nada, pois quem está programando é IDE. :stuck_out_tongue:

Bom, eu nunca fiz um projeto prático usando EJB, pois sempre fujo deles, mas eu realmente acho chato demais ficar configurando um milhão de xmls e escrevendo um milhão de classes e interfaces para modelar uma entidade. Contraste isso com a simplicidade do Hibernate, onde um objeto persistente é como um JavaBean puro.

A complexidade de EJB, a quantidade massiva de configurações XML, a complexidade dos Applications Servers, me fazem continuar com o bom e velho Servlet Engine.

Tá certo que com servlet vc vai ter que implementar algumas coisas na mão, ou ser safo para achar essas coisas já implementadas por aí (Hibernate, Taglibs, JTA, etc.), mas será bem mais divertido e no final vc terá a sensação de que vc está no controle e não um application server maluco.

#27

Olá…

Achei este material no TheServerSide:
É uma crítica quanto ao EJB 3.0!

Abraços!

#28

Estou com preguiça de ler as postagens anteriores, mas me interessei pelo assunto.
Gostaria de saber quem já utilizou o padrão EJB Session Façade em um projeto para distribuição de módulos, persistindo os dados com Entity’s Bean na versão 2.1, utilizando JDeveloper, BD Oracle 10g e Oracle 10g AS?!?

#29

A ressureição… :slight_smile:

Não sou defensor do uso de EJB em todas as soluções, mas essa é pra quem gosta de malhar sem conhecer… :wink:

[quote=Kameron McKenzie at JavaRanch]

Let us establish one undeniable fact: enterprise programming is hard.

Sure, Servlets are superb at handling client requests, and Java Server Pages are fabulous at generating markup for a client, but request-response programming is not where Java developers earn their salt.

Java developers earn their salt by implementing some seriously complicated business logic. Fiddling with a Servlet’s request and response objects all day long won’t impress anybody.

Enterprise programming is hard, but EJBs make some of the toughest parts of enterprise programming just a little bit easier.

What are the common challenges enterprise developers encounter?

Enterprise programming is hard. In an enterprise environment, there are a number of mission critical challenges that must be addressed and implemented properly, otherwise applications will fail.

Some of the typical challenges that enterprise developers encounter include:
Database Access:

How do we ensure that that data in our application is completely, totally, 100% in sync with what is in the database? This is a requirement of almost every enterprise application, but without an intimate knowledge of how a database works, implementing database synchronization properly is a significant challenge.
Transactional Updates:

If I’m updating three different databases in an ‘all or nothing’ type of scenario, and one of those database writes fails, how do I roll back writes to the other two databases?

What if one of those databases is in Kalamazoo and two of them are in Tuktoyaktuk? How do you maintain the transactional integrity of your updates?
Distributed Programming:

I’m in Gun Barrel, Texas, but I want users in Antigonish, Nova Scotia to remotely invoke the methods in my Java components. How do I make a local component accessible to remote applications?
Multithreading:

Multithreading remotely accessible components that must handle a gargantuan load is a difficult and onerous task. How are you going to do it?
Secure Access:

You only want Double Agents to call one method of your JavaBean, and only Secret Agents can call the other method. How ya gonna do it? With a typical Java application, it’s almost impossible.

How do EJBs Make Life Easier?

Database concurrency, distributed transactions, multithreading, distributed programming and secure accesses are all issues our enterprise applications must deal with.

If we have to deal with these issues alone, we’re going to be in an ugly world of hurt. The good news is that EJBs deal with these issues, and by dealing with them, they make enterprise programming much, much easier.

I hope that sheds some light on ejbs. More here:

http://www.technicalfacilitation.com/get.php?link=usingejbs[/quote]

O conteúdo original está aqui…

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t=012333

#30

Bom senhores, vou contribuir com a experiência que possuo sobre o assunto:

Como muitos disseram, um dos principais motivos da adoção EJB é quando sua aplicação possui necessidade de estar 99,9999% no ar. Logo se projeta uma arquitetura de Cluster com diversos nós.

Alguns applications servers como Websphere, adotam a estratégia de cluster da sessão, ligados a um banco de dados.

Um dos motivos de eu gostar do GlassFlish é o HADB- High Avaible Data Base, uma tecnologia da Clustra - empresa que a Sun adquiriu no passado e integrou ao seu produto na versão 7.1.

Com tal tecnologia, você serializa os objetos e compartilha por uma estratégia Round-Robin de escalonamento.

Nesse cenário utilizar um Session Bean Stateful, para armaezenar algumas informações que você não pode correr o risco de perder pode ser uma grande vantagem.

A especificação te dá essa opção e um bom produto que faça bom proveito da mesma, pode reduzir bastante seu TCO com hardwares de cluster, utilizando somente Application Server para a questão.

Vivi esse cenário num projeto da OESP, cliente da Sun Microsystems (empresa que representei como consultor).

JMS todos aqui mencionaram como se ganha poder ao utilizar MDB´s e simplicidade. Existem muitos patterns de desacoplar todo o tratamento de excessões usando JMS de forma assíncrona, principalmente quando se precisa dar continuidade ao processo e logar a informação ou dar seu devido tratamento de forma isolada.

Também estou acompanhando alguns Patterns mais novos sobre Ajax + JMS - http://www.trajano.net/2006/04/ajax-queue.html

Claro que você pode utilizar o Spring para controlar desde o MVC ao JMS, sei que muitos vão falar disso e tb prefiro a solução.

Mas em projetos de integração, quando você opta por utilizar uma estratégia baseada em JMS, ter um monitor ( serviço do application Server) entre outras features de controle, te faz olhar EJB com outros olhos.

Realmente a parte de persistência (Entity Beans) não me agrada. Para cenários complexos você pode ter muita dor de cabeça e hoje você tem muitas alternativas, como várias implementações JDO, Hibernate - que agora está seguindo EJB3.

Mas para findar, acredito que deve-se estar ciente do que sua aplicação necessita de infra-esturutra, quais são as premissas do negócio.

EJB na minha ótica provisiona uma ótima relação custo x benefício para ambientes clusterizados, vide hardwares para tal operação são muitas vezes ineficientes e bastante custosos.

#31

Aproveitando o tópico, clientes swing acessando as regras de negócio no app. server teria outra opção além de uma camada de Session Beans fazendo a ligação entre eles? Não sou simpático em utilizar chamadas http no cliente swing e estou começando um sistema com a abordagem que citei acima…

#32

Olá

Então empatamos pois eu sou favorável a utilizar chamadas Http síncronas ou assíncronas no cliente Swing.

Mas em alguns raros casos concordo que se pode fazer do modo como você falou.

Se quer uma outra opção sem usar Http seria necessário que você desse mais dados da sua aplicação dizendo se ela está confinada em uma rede local que aceita RMI, se está na Internet por trás de firewalls, se será baseada em serviços ou eventos, etc…

[]s
Luca

#33

Em principio está na intranet, mas no futuro deverá ter acesso via internet atrás de um firewall. Será baseado em serviços.

#34

[quote=mutano]Aproveitando o tópico, clientes swing acessando as regras de negócio no app. server teria outra opção além de uma camada de Session Beans fazendo a ligação entre eles? Não sou simpático em utilizar chamadas http no cliente swing e estou começando um sistema com a abordagem que citei acima…
[/quote]

Existem algumas opcoes de remoting para essa situacao, mas nao importa o que voce escolha, nao faca chamadas “na unha”. Diversos frameworks sao capazes de invocar interfaces remotas via HTTP e existe tambem RMI/HTTP(S), o que permite acessar EJBs atraves da porta 80.

Com o genesis, costumamos usar Session Beans mesmo e jah usei RMI/HTTPS algumas vezes.

#35

Pessoal,
Acompanhei as dicussões sobre utilizar ou não EJB. Eu não preciso, afinal não é um sistema distribuído e tal… mas estou precisando utilizar MDB, já que não é adequado utilizar thread em aplicação J2EE.
E agora?
Existe alguma solução que não seja MDB para processamento paralelo nesta situação?
Caso não exista, como fica a arquitetura de um projeto que utiliza somente “parte” de EJB, no caso, somente MDB (Eu não conheço muito de EJB)?

#36

Resolvi me dar ao trabalho de olhar as mensagens todas, e apesar do bom nível técnico das discussão, parece-me que a maioria dos posts abordou a questão do ponto de vista do mérito/demérito dos EJBs para o código, ou seja, uma visão do que é bom/ruim para o desenvolvedor.

Convenhamos, uma vez a aplicação feita (e funcionando), ela vai ser entregue para uma área de produção que não está nem aí se vc. usou Struts ou Mentaway ou Spring para implementar MVC - ou mesmo se vc. usou ou não MVC.

Esta área quer é um conjunto de artefatos para fazer deploy, junto com a especificação dos requisitos estáticos (datasources) e dinâmicos (tamanho dos pools, pex) a sereme configurados.

Uma vez no ar, a produção tem que responder perguntas do tipo: Quantos acessos a página tal tem por dia ? Qual o tempo de resposta ? Qual a evolução no número de usuários nos últimos 6 meses ?

Para responder a estas questões, a aplicação precisa ser constantemente monitorada. Neste momento, o que a produção precisa é uma visão clara dos módulos do sistema e, em caso de problemas, ser capaz de alterar parâmetros em tempo de execução, preferencialmente sem afetar outras aplicações.

Nesta hora, os EJBs (Session, ok ? Acho que todos concordam que Entity Beans foram uma bola fora) apresentam algumas vantagens:

  • Um EJB pode ser utilizado como ponto de controle de fluxo, manipulando-de o tamanho do pool de instâncias.

  • EJBs podem ser atualizados de forma independente uns dos outros e dos clientes (wars e clientes RMI). Em um ambiente de produção esta flexibilidade pode ser interessante, uma vez que o maior motivo de parada de um aplicativo é para atualização de versões.

  • Os containers instrumentam os EJBs (e servlets) de forma a ser possível monitorar os tempos gastos nas sua execução.

Vc. pode fazer isto tudo sem EJBs ? É claro que sim ! Mas será código da aplicação. Mesmo que todas as aplicações usassem o mesmo framework, mesmas versões de bibliotecas - o que não acontece na prática - ainda assim, do ponto de vista da produção, tal solução seria inadequada, e provavelmente criaria problemas operacionais relacionados à dificuldade em operar aplicações com formas distintas de operar.

Com EJBs, ao menos a separação das camadas principais fica exposta de uma forma padronizada, permitindo um ponto de observação/controle/diagnóstico que é independente das bibliotecas utilizadas.

#37

Olá

Beleza, sevestre. Levou 5 estrelas com louvor.

[quote=ferstring]
Existe alguma solução que não seja MDB para processamento paralelo nesta situação?
Caso não exista, como fica a arquitetura de um projeto que utiliza somente “parte” de EJB, no caso, somente MDB (Eu não conheço muito de EJB)?[/quote]

MDBs são ótimos. Como também você poderia fazer tudo sem MDBs usando JMS na raça que nãoé tão difícil assim.

O maior problema que eu vejo não é na tecnologia e sim no fato de você ter dito que não conhece bem. Acho que o conselho mais honesto seria para você procurar aprender o máximo sobre arquiteturas baseadas em mensagens, os conceitos de tópicos e filas, porque a arquitetura de mensagens baseada em MDBs/JMS é boa dentro da empresa e manca na Internet, etc. Um bom livro é o Java Messaging do Eric Bruno.

Desenvolver um software baseado em mensagens assíncronas é o modo mais fácil de ter escalabilidade sem precisar gastar rios de dinheiro com soluções de hardware e rede.

[]s
Luca

#38

gente hoje eu não vou fazer grandes debates, vou apenas fazer perguntas e dar infos…

o que acham de spring em cluster?
www.terracottatech.com/pdf/Spring.pdf

HTTP Invoker para acesso remoto?
vcs sabiam que esta solução esta disponivel? (beta ainda).
se sabiam o que muda? alguma consideração?

acho que EJB e complicado mesmo… não uso mais…

#39