Cluster x EJB ? Algo mais que justifique o uso de EJB?

Programação Java
#21

[quote=saoj]
Me dá um exemplo, tirando cluster, de algo que exija uma curva de aprendizado grande ?[/quote]

Voce não esta entendo… nao estou dizendo que UMA coisa vai ser grande… mas junta dezenas de frameworks em um local só é pedir para fazer uma salada… e com certeza para um membro novo na equipe vai ser uma zona… nunca achei interesasnte dependenr de muitos fornecedores unicos para uma coisa…

Por isso que Java EE 5 se encaixa perfeitamente na minha opiniao… é um “All in one” que tem vários “sabores” e de forma toda integrada.

#22

Discordo.

Vc não precisará de diversos frameworks, muito pelo contrário.

Usando apenas um framework web, vc pode fazer tudo isso.

E se usar o Mentawai ainda poderá fazer CLUSTER. :shock:

Vc não respondeu a pergunta:

Me diz apenas uma coisa, que vc faz com EJB, que vc acredita não ser fácil fazer na mão.

Não estou falando de usar outros frameworks. Estou falando de fazer na mão sem qualquer dificuldade, para qualquer programador mediano-bom.

#23

[quote=saoj]
Discordo.

Vc não precisará de diversos frameworks, muito pelo contrário.

Usando apenas um framework web, vc pode fazer tudo isso.

E se usar o Mentawai ainda poderá fazer CLUSTER. :shock:

Vc não respondeu a pergunta:

Me diz apenas uma coisa, que vc faz com EJB, que vc acredita não ser fácil fazer na mão.

Não estou falando de usar outros frameworks. Estou falando de fazer na mão sem qualquer dificuldade, para qualquer programador mediano-bom.[/quote]

Controle de Transacoes é um saco
JMS é chato…
Controlar o JPA é algo mala… (transacoes , fabricas etc…etc…)
controle de seguranca é complexo…

Mentawai é um produto unico… nao tem como comparar com EJB que tem vários fornecedores… o dia que o mentaway nao fizer algo “como eu espero” eu só lamento… ou altero ou reescrevo tudo… diferente de EJB… que até na epoca dos malditos Entiutys 2.x voce conseguia sair pela tangente …

sem ter que reprogramar tudo :slight_smile:

ps: essa eh a minha opiniao… pode nao ser a verdade suprema.

#24

Esse tema é polêmico, logo não estou dizendo que estou com a razão.

Controle de transações não tem mistério nenhum. São raros os casos onde vc vai precisar de um Two-phase commit, ou se uma transaçao em dois bancos de dados diferentes. Já fiz sistemas de billing que nunca precisaram disso. Em 99% dos casos, transação é algo bem simples como: preciso inserir na tabela A, B e C atomicamente. Qual a dificuldade em demarcar essa transaçao na mão. Geralmente o seu modelo delimita a transaçao em volta dos DAOs que ele for usar, e que precisam ser executados atomicamente.

Se houver um caso recorrente, diferente desse que eu descrevi aí em cima, então explica, pois não vejo necessidade de complicar isso.

JMS é chato e complicado, e não precisa ser usado com EJB, acredito eu. JMS é uma soluçao desesperadamente procurando por problemas, e esses são escassos. Qual a situaçao em que vc vai precisar de mensagens assincronas em tempo real? Por que vc não pode de tempos em tempos fazer uma requisição ao servidor para saber se existe alguma mensagem pra vc?

JPA? Vc está falando de persistencia em banco?

Segurançá ??? Aonde isso é complicado ? Vc está falando de autenticaçao e autorizaçao ou de SSL ?

Ou seja, alguém precisa realmente chegar e dizer: “Nesses casos aqui, que não são tão raros assim, EJB te dá um ganho X que justifica e muito o custo Y que vc paga pela complexidade, peso e chateaçao de mexer com ele”

[quote]o dia que o mentaway nao fizer algo “como eu espero” eu só lamento…
[/quote]

O dia que o Mentawai não fizer alguma coisa que vc espera, basta vc extender as interfaces e resolver o seu problema. E isso é bem fácil, pois qualquer programador Java vai saber implementar uma interface de acordo com a especificaçao da API. Isso é básico do básico.

Taí a diferença:

EJB tenta resolver tudo, de forma que vc não se preocupe com nada e acaba criando uma soluçao gigante, pesado, chata e complexa. E cria tb um monte de gente que programa como robo sem nem saber o que está fazendo.

Um frameweork web bom, vai te dar a fundaçao e as soluçoes para as coisas chatas e reocrrentes de todo o projeto, e o resto é contigo. Por que vc gosta de solucionar problemas e não seguir receitas de bolo furadas!

#25

  • JMS em EJB é extremamente simples… e se usar Message Driven Bean entao… fica baba…

  • EJB Pesado ? EJB Complexo ? acho que voce precisa ver java EE 5.

  • Prefiro deixar o framework web fazer o que ele foi feito… controlar a parte web… o backend deixo para frameworks mais parrudos e com propositos especificos.

  • JPA esta contido em EJB… estou sim falando de persistencia

  • Seguranca em nivel de componente… nao de “acesso de sistema” , sistemas acessando sistemas com nivel de permissao definido… e Single Sign On

  • Definir transacoes na mão é algo alem de chato sugeito a falhas em grandes projetos onde “não existe EUquipe” , qualquer coisa maior que 2 programadores torna-se chato e abre brecha para bugs pesados.

  • Já disse… numa empresa nem sempre “extender as coisas” é a melhor forma… ainda amis quando voce esta lidando com muito critica… voce espera garantias… e EJB te dá isso… garantias de fornecedor.

  • Solucionar problemas pode ser algo simples… nao necessita de “grandes solucoes magicas”

para voce ter chamado EJB 3 de complexo acho que realmente OU voce nao trabalhou com Java EE 5 OU voce criou este topico apenas para malhar EJB sem se importar com o atual estagio de maturidade da plataforma.

Antigamente tudo que voce falou era justificado… mas agora com Java EE 5 viraram algumentos sem peso algum… pra que usar dezenas se posso fazer com um ?

#26

Aprendi muito sobre EJB3 na faculdade, trabalhos e trabalhos utilizando essa tecnologia.

Iniciamos o ano de 2006 apenas utilizando conceitos sobre classes entidade, classes de controle e classes limitrofes.

No segundo semestre já começamos a adquirir idéias mais maduras sobre engenharia de software, em que tinhamos que ter a idéia de que o desafio do software não deve ser somente evoluir da versão 1 para a 2, mais da 1, 2 3… versão 10, sem que tenhamos de jogar tudo fora e refazer tudo novamente.

Acredito então que o EJB3 venha oferecer suporte a criação de um software robusto e com qualidade não apenas em pequenas rotinas no código, mas no geral, venha a manter a qualidade em todo o código desenvolvido.

E também, hoje a linguagem que está na moda com certeza é o Java, queremos fazer tudo em Java. Como você fará, no futuro, para incorporar um novo sistema na sua empresa que terá que ser desenvolvido em uma outra linguagem. Basta usar seu servidor de aplicação em EJB3 com JNDI e mostrar o caminho do serviço compartilhado que será acessado.

Concluindo, aprender EJB3 e todas as demais tecnologias que o envolvem com certeza é algo muito desgastante, mas se você quer qualidade, robustez, escalabilidade, baixo custo de manutenção, e um software para toda a vida, estude EJB3 e tecnologias que o envolvem.

#27

Isso é sintoma clássico de um Anemic Domain Model ou até mesmo um design altamente procedural. Quando você possui objetos de negócio bem definidos o Repository/DAO é apenas mais um objeto envolvido numa transação, não seu gerente.

#28

E não foi isso que eu falei acima?

“Geralmente o seu modelo delimita a transaçao em volta dos DAOs que ele for usar, e que precisam ser executados atomicamente.”

Continuo no aguardo de exemplos concretos onde teríamos uma transaçao complexa o suficiente que não poderíamos fazer na mão, delimitando no próprio modelo de negócios onde ela começa e onde ela acaba. Sem contar que em 90% dos casos, uma requisiçao será uma transaçao. A coisa pega quando vc tem que executar um batch de transações assincronamente, mas aí basta tb subdividir esse batch em pequenos batchs transacionais…

Segurançá a nível de componente? Em que situações isso é necessário? Apenas quando vc usa EJB!

Não! Definir transaçoes na mão é muito fácil.


// begin

faz o que tem que fazer

// commit

// deu erro rollback..

A coisa só vai ficar complicada, se vc quiser que fique. Necessidade não há… A não ser que vc mostre uma situaçao recorrente onde o esquema acima não é suficiente…

#29

Sergio, EJB 3.0 é muito útil quando você quer desenvolver um middleware que vai ser usado por muitas aplicações. Ele facilita muito quando você precisa usar 2PC, que é mais comum do que você imagina em middlewares de integração.

O cenário mais comum que eu vejo é JDBC + JMS, no qual o commit no banco e na fila tem que ser atômico. Isso ocorre principalmente quando algum consumidor da fila não consegue identificar mensagens duplicadas.

JMS é facil de usar e situa como elemento chave de qualquer arquitetura que tem altíssimos volumes transacionais. Mainframes, em sua maioria, operando com troca de mensagens assíncronas. Pooling não escala e não permite desacoplamento entre produtores e consumidores, além de uma tonelada de outros problemas associados.

Qual a utilidade de um framework web quanto tudo que você quer é exportar vários webservices para consumo de várias aplicações internas? Nesse caso compensa mais usar EJB 3.0, que é uma versão simplificada do Hibernate para persistencia e um modelo de componentes muito mais facil de usar que os da versão anterior.

Quanto a autenticação/autorização, concordo com você que EJB não alivia nada nesse sentido, apesar que com o suporte a interceptors você pode contruir uma solução tão simples quanto a equivalente do Mentawai.

O custo de você usar EJB 3.0 hoje é o mesmo de usar hibernate e qualquer solução de remoting, caso precise. Ou seja, não precisa de 1 tonelada de motivos para se justificar.

Sergio, olha que ano estamos, 2007, não 2001, com EJB 1.x. Então não tenta justificar a necessidade de um action-oriented framework quando a questão não é nem essa. Ainda mais quando a comparação não é nem cabivel, já que existem muitos cenários nos quais ele é completamente dispensável.

#30

[quote=saoj][quote=pcalcado]
Isso é sintoma clássico de um Anemic Domain Model ou até mesmo um design altamente procedural. Quando você possui objetos de negócio bem definidos o Repository/DAO é apenas mais um objeto envolvido numa transação, não seu gerente.
[/quote]

E não foi isso que eu falei acima?
[/quote]

Não.

Se a transação está em volta do DAo significa que eu não posso utilizar o mesmo DAo ou mesmo o mesmo método dele em outro fluxo com outras requisições de transação.

Não precisa ser complexo, Sérgio, basta ser OO e talvez por isso você não esteja entendendo a necessidade de transações declarativas. Um mesmo modelo de objetos pode (e deve!) ser reutilizado de dezenas de maneiras possíveis, cada uma com um critério de transações provavelmente bem diferente.

Transações são demarcadas no modelo de negócios, não no de persistência.

#31

Acho que vc teve um problema de interpretação de texto aqui, Shoes.

Em volta é muito diferente do que d entro.

E eu falei diversas vezes que o modelo de negócios que define a transação em volta dos DAOs.

“Continuo no aguardo de exemplos concretos onde teríamos uma transaçao complexa o suficiente que não poderíamos fazer na mão, delimitando no próprio modelo de negócios onde ela começa e onde ela acaba.”

#32

Qualquer coisa mais bem boladinha vai precisar… quando seu sistema depende de outros sistemas…ex: seu sistema de cliente integrando ao seu sistema de caixa unico… pronto… esse nivel de hierarquico é util e necessário, e sinceramente não deixaria isso por conta de um servletfilter.

Por favor… quando o sistema faz interacao com varios componentes de si proprio voce precisa de um nivel de isolamento entre os componentes… nem sempre a “falha” de um vai implicar em rollback… voce esta exemplçificando o caso mais simples dos simples… uma fachada que faz tudo… mas nem sempre fachadas são usadas… quando voce tem um problema desde nivel… marcar transacao entre componentes é algo simplesmente impraticavel…

  • SessionA chama metodo b
  • metodo b chama SessionB

Voce pode demarcar a transacao para comportamente diferente neste caso… não tem bem uma fachada… mas o mesmo contrala transacao em nivel de componente.

Olha… vou dizer o que o louds disse… acorda … é 2007… complicado EJB ? acho que realmente voce não leu nada sobre Java EE 5 para repetir que ele é complexo.

Para mim… nao justifica usar um framework web para fazer clusterizacao… e nem para controlar transacao… acho isso o fim da picada… prefiro deixar isso para o JTA ( nao soh eu… até o hibernate deixa isso para JTA)

é questão de opiniao… vc pode construir um predio com cinemnto por tudo… ou usar tijolos quando precisar mais forca.

#33

Ok, me dê um exemplo de método de negócios com código de transação. Vamos supor que eu tenha:

void novoUsuario(Usuario administrador, String login, String senha){
 Usuario u = new Usuario(login);
 u.setSenha(senha);
 u.setAdministrador(administrador);


 repositoriousuarios.adiciona(usuario);
}
#34

Sérgio, você quer 1 exemplo trivial de como demarcar transações em volta dos DAOs é ruim.

Ok, que tal o sistema da lojinha, que tem no mesmo sistema controle do caixa e do estoque. Nele você tem 2 Daos: CaixaDao e EstoqueDao.

Quando um produto é entregue, você chama: “estoqueDao.aumentaEstoque(produto, quantidade)”. O dao demarca a transação, legal, funcinou!

Quando uma compra é feita, você chama primeiro: “caixaDao.registraVenda(produto, quantidade)” e depois “estoqueDao.fazBaixaNoEstoque(produto, quantidade)”. Se a transação for demarcada pelos daos, vamos ter casos de produtos vendidos que não sofreram baixa no estoque e casos de estoque vazio apesar das prateleiras estarem cheias.

Demarcação explicita e exteriorizada de transações é importante e comum para todo sistema.

#35

Vcs apresentaram argumentos válidos.

Para middleware pode ser uma boa.

Agora essa discussao não vai ter fim, se vcs não apresentarem um especificaçao de projeto que necessita de EJB.

O Mentawai suporta cluster de objetos via JGroups. Mesma tecnologia que o JBoss usa para cluster. Não to falando que vc vai usar mentawai para cluster, mas se tiver num projeto web e precisar fazer um cluster de sessão ou um cache distribuído vc pode.

Sim, por isso que vc vai delimitar duas transações e não uma. Na mão mesmo…

#36

[quote=louds]Sérgio, você quer 1 exemplo trivial de como demarcar transações em volta dos DAOs é ruim.

Ok, que tal o sistema da lojinha, que tem no mesmo sistema controle do caixa e do estoque. Nele você tem 2 Daos: CaixaDao e EstoqueDao.

Quando um produto é entregue, você chama: “estoqueDao.aumentaEstoque(produto, quantidade)”. O dao demarca a transação, legal, funcinou!

Quando uma compra é feita, você chama primeiro: “caixaDao.registraVenda(produto, quantidade)” e depois “estoqueDao.fazBaixaNoEstoque(produto, quantidade)”. Se a transação for demarcada pelos daos, vamos ter casos de produtos vendidos que não sofreram baixa no estoque e casos de estoque vazio apesar das prateleiras estarem cheias.

Demarcação explicita e exteriorizada de transações é importante e comum para todo sistema.[/quote]

Acho que vc e o Shoes estão com sérios problemas de interpretaçao de texto:

Vou repetir de novo, se não entender a frase pode entrar em contato em private que eu tento explicar melhor:

“O modelo de negócio vai delimitar a transaçao em volta do DAO. A transação não está dentro do DAO. Especificar a transaçao dentro do DAO não faz o menor sentido.”

E aí, podemos seguir em frente?

#37

pra que fazer na mão ? o que voce ganha com isso ? que beneficios eu ganho me preocupando com transacoes na mão ?

#38

A questão que estou tentando apresentar não é “por que usar ?” e sim… “por que não ?”

#39

Chun,

Não tenho dúvida em que haverá situaçoes que ele se justifica, e se ele agora na versão 3 (depois de duas tentativas frustradas) está mais smples e maduro, então melhor ainda.

O que me falta é um exemplo de uma situaçao clássica onde EJB é bastante recomendável. Algo mais do que: “sistemas de middleware”.

Vou comprar um livro sobre EJB e dar uma lida aqui. Qualquer coisa eu devolvo na livraria depois… :stuck_out_tongue:

#40

Sérgio, você pediu um exemplo de sistema que seria bom usar EJB 3.0, eu dei, agora só porque esse é um exemplo ruim para você malhar não vale?

Sinceramente, EJB hoje é útil e recomendável em qualquer sistema que use hibernate. Simples assim. Ou seja, se você vai ter muita manipulação de dados ou precisa de independencia de banco, é uma boa escolha.