saoj:

Sempre que debato com o Rubem Azenha sobre EJB temos conversas bem produtivas sobre as reais vantagens e/ou desvantagens de adotar essa tecnologia.

Então deixo a pergunta para um debate sadio:

O que EJB te oferece que vc não pode fazer sem EJB de uma maneira muito mais leve, simples e pura?

Até outro dia eu achava que era cluster, mas depois de conhecer o JGroups, vi que nem pra isso ele está valendo a pena hoje em dia. Mas posso estar enganado…

Este Terracotta também prove clusterização de aplicações Java sem utilização de EJB.

saoj:

Sempre que debato com o Rubem Azenha sobre EJB temos conversas bem produtivas sobre as reais vantagens e/ou desvantagens de adotar essa tecnologia.

Então deixo a pergunta para um debate sadio:

O que EJB te oferece que vc não pode fazer sem EJB de uma maneira muito mais leve, simples e pura?

Até outro dia eu achava que era cluster, mas depois de conhecer o JGroups, vi que nem pra isso ele está valendo a pena hoje em dia. Mas posso estar enganado…

Acredito que as vantagens de EJB ( em sua versao 3 é claro ) são a integração entre os servicos e o appserver… com ejb voce tem já um controle de transacoes (JTA) , servico de mensagens (JMS) de forma integrada e totalmente transparente… com Java EE 5 ficou muito produtivo… pois até o contexto de persistencia é inserido via IoC.

Acredito que outras alternativas sejam capazes de fazer a mesma coisa… a pergunta seria… a que preço ? EJB oferece uma estrutura padrão e implementada por dezenas de fornecedores… até a parte de persistencia pode ser escolhida agora (JPA)

Clusterização é apenas UMA das vantagens… a separação do codigo fica muito evidente em Java EE 5 , isso torna as coisas mais simples de serem programadas… JAAS ficou muito mais simples e sumiram os milhares de XML (Spring) … acredito que valha a pena hoje…

Com JBoss Seam voce tem uma integracao perfeita entre os EJB’s e o JSF… ( que vai ser padrozinada pela JSR dos WebBeans )…

Quando se fala em desenvolvimento em grupo e curva de aprendizado não tão ingrime… Java EE 5 é a melhor opcao. Antigamente tinha que se saber dezenas de coisas… hoje não.

é claro que tudo isso pode ser oferecido por outros frameworks em conjunto… a pergunta continua… mas a que preço ?

e por que não usar ?

Olá

Quando estudei EJBs 1.x há muitos anos atrás, fiquei com a certeza de que era apenas complicação desnecessária em 99% dos casos. O desenvolvedor Java que não poluiu a cabeça aprendendo EJBs 1.x fez muito mais pelo seu patrão do que muitos que recomendaram seu uso. Há por aí um grande legado de aplicações usando EJBs antigos rodando em servidores caríssimos obsoletos como é o caso da CEF por exemplo.

Mas agora estou estudando EJB 3.0 e acho que já dá para pensar em usar sem levar o custo do projeto para as rodas de piadas na hora do almoço nos outros departamentos. Só que pensar em usar não significa adotar indiscriminadamente como algun$ consultore$ andaram recomendando nos últimos anos (por ignorância ou sabotagem). Há ainda muitos projetos em que EBJs oferecem poucas vantagens.

[]s
Luca

Rapaz, quando pensarmos em solução de escalabilidade, como iremos fazer se não pudermos colocar nossos componentes distribuidos, e como outros colegas falaram, e para resolver, transação de negócio sem ter que extender frameworks para provêr tais funcionalidades.

As realidades fazem com que vc defina o que usar para resolver tais cituações, mais EJB é uma plataforma e padrão de mercado e em situações corporativas não abro mão dos Session para me provêr o que acima citei.

[s]
baiano

Olá

O problema é que isto não é um requisito comum ou padrão. Fazer isto só por fazer é o que ridicularizou o uso de EJBs.

Um dia almocei com vários diretores de empresas da área financeira. Os caras morriam de dar risada metendo o pau no Java. Eles citaram vários exemplos, inclusive o de uma grande instituição que gastou mais de R$ 20 milhões e depois de um ano ainda não tinha NADA funcionando. O dia em que você passar pela experiência que eu passei vai perceber o mal que alguns consultores podem fazer a uma empresa. Com EJBs pré 3.0 a maioria dos casos foi dinheiro jogado fora.

[]s
Luca

Uma dúvida, para usar JMS é preciso usar EJB ou apenas fica mais fácil usando EJB?

Olá

JMS é uma das melhores coisas do Java. É bem fácil usar sem EJBs mas neste caso sou favorável a usar as message beans. Não só porque facilita mas também porque servidores como o JBoss podem ajudar na monitoração.

[]s
Luca

Sim… mas vamos nos reservar a falar da tecnologia no atual estagio de amadurecimento… senao… vamos extender por meses esta “conversa”… que EJB 1.x e 2.x são terriveis já sabemos…

bola pra frente minha gente !

Olá Luca, obrigado pela resposta, pois então, pelo que andei vendo JMS poderia resolver alguns probleminhas meus, mas não estava querendo ter de ver EJB o sistema é pqno, baixo volume de acesso, etc… Fico feliz q um não dependa do outro.

Estava querendo abordar outras tecnologias, já que EJB será mais difícil de eu usar nos meus projetos. (a não ser q tudo mude, rs, mas não dá para prever tudo, rs)

Uma grande dúvida acerca de EJB é q justamente recomendam ele para sistemas maiores, justamente em cluster, e outars situações mais extremas, contudo o que vejo é ele sendo usando de forma geral, mesmo em sistemas pqnos, isso não seria o equivalente a matar uma mosca com um canhão.

E outro problema o que é um sistema grande, com um grande volume de acessos, etc? Claro q temos aqui pessoas que trabalham em bancos, telefonicas, etc, mas volte e meia aparece alguem falando de um sistema q tem muito acesso e tal, mas na verdade não tem, e um upgrade de hardware resolveria melhor q usar EJB, no meu ver de leigo.

Ou seja não existe uma super valorização dessa tecnologia?

Java EE 5 torna o uso de EJB’s uma coisa normal e sadia… se seu sistema é tão grande como fala… EJB pode ajudar voce a expandir o poder de fogo sem muita alteração na estrutura…

Coisa que com qualquer outra “arquitetura” voce precisaria estar se preparando desde agora… com tecnicas mirabolantes… para que lá na frente… nao precise reescrever tudo…

chun:

Java EE 5 torna o uso de EJB’s uma coisa normal e sadia… se seu sistema é tão grande como fala… EJB pode ajudar voce a expandir o poder de fogo sem muita alteração na estrutura…

Coisa que com qualquer outra “arquitetura” voce precisaria estar se preparando desde agora… com tecnicas mirabolantes… para que lá na frente… nao precise reescrever tudo…

Sim chun isso eu entendi, no caso de um sistema grande é uma realidade, mas estava me referindo a sistemas pqnos ( e q pode falta de informações, experiencia ou parametros de comparação) os desenvolvedores acham q é grande e metem o EJB no meio, sendo q poderia ser resolvido com outras tecnologias.

Veja nunca mexi com EJB posso estar falando bobagem.

Agora se desenvolver com EJB é simples e fácil o “problema” residiria apenas no fato de usar um canhão para matar a mosca, mas o resultado final (q muitas vezes é só o q importa) é atingido (a mosca tá morta), risos.

A proposta de JBoss Seam é justamente esta… usar para qualquer tamanho de projetos Java EE 5

Acredito que com a versão 5 da especificação Java EE , a adoção de EJB em projetos tenha sido invertida… em 90% das vezes voce pode colocar eles… para ajudar a separar as coisas… e deixar uma brecha para uma possivel clusterização futura ou até mesmo uma separacao explicita (ex: um servidor fazendo a regra de negocio e outros 15 atendendo requisicao http )

Com Java EE 5 … o que abunda não prejudica

Para segurança, nada te impede de usar qualquer outra esquema de autenticação e autorização.

Para escalabilidade, nada te impede de usar um load balance qualquer.

Para cluster (load balance + failover), nada te impede de usar JGroups ou esse outro que falaram aí.

Para controle de transações, nada te impede de fazer isso na mão sem qualquer problema. 99% dos casos de transações são simples e não precisam de two-phase commit ou essas coisas complexas e muitas vezes sem qualquer benefício.

EJB é uma solução desesperadamente procurando um problema!

Eu trabalhei na Accenture na época que EJB surgia. Vi projetos gigantescos que foram jogados no lixo, porque foi feito um sistema gigante, cheio de bugs e uma carroça.

EJB 1.0 e EJB 2.0 era a receita certa para o desastre e prejuízo (para o cliente é claro!).

EJB 3 melhor. Claro, depois de tentar por 3 vezes fazer a coisa direito, já estava mais do que na hora de fazer uma coisa descente.

Mas EJB continua sendo totalmente desncessário, na minha opinião.

O que vc consegue fazer com EBJ que vc não consegue fazer sem ele? Difícil !

saoj:

Mas EJB continua sendo totalmente desnecessário, na minha opinião.

O que vc consegue fazer com EBJ que vc não consegue fazer sem ele? Difícil !

Sergio acho que o ponto é q EJB oferece todas estas funcionalidades já de fábrica e integradas, mas (chutando) vc consegue fazer tudo sem ele (eu acho, rs).

Onde encontro um bom exemplo, tutorial, etc, de como integrar escalabilidade, transação, cluster, etc sem EJB? Quem já fez uma vez e tem isso bem estruturado, ótimo, mas quem não tem o buraco é mais embaixo e acaba ficando com EJB …

saoj:

Para segurança, nada te impede de usar qualquer outra esquema de autenticação e autorização.

Para escalabilidade, nada te impede de usar um load balance qualquer.

Para cluster (load balance + failover), nada te impede de usar JGroups ou esse outro que falaram aí.

Para controle de transações, nada te impede de fazer isso na mão sem qualquer problema. 99% dos casos de transações são simples e não precisam de two-phase commit ou essas coisas complexas e muitas vezes sem qualquer benefício.

EJB é uma solução desesperadamente procurando um problema!

Como eu disse… esse preço eu não pagaria… 313 frameworks para fazer algo que um faz ? pra que ? pra provar que dá para fazer diferente ? Java EE 5 simplificou ao ponto desses argumentos serem considerados invalidos… não tem motivo… pra que complicar ? pra que complicar a vida da equipe inteira ? aprender 3123123 frameworks ? no way.

Ejb esta simples e facil… ao ponto de ser usado em 90% das aplicacoes.

A única coisa que é complexa é CLUSTER.

O resto não vejo dificuldade para qualquer programdor mediano.

Além do cluster, o que exigiria trabalho ou outros framewoks?

Curva de aprendizado… dezenas de configuracoes diferentes , maneiras de trabalho diferentes… coisas do genero…
por mais q seja “simples” a curva de aprendizado com certeza será bem mais íngrime.

Me dá um exemplo, tirando cluster, de algo que exija uma curva de aprendizado grande ?

saoj:

Me dá um exemplo, tirando cluster, de algo que exija uma curva de aprendizado grande ?

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.

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.

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.

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

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

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”

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

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!

• 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 ?

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.

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.

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…

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.

saoj:

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.

E não foi isso que eu falei acima?

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.

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.”

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.

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);
}

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.

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…

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.

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?

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

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

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…

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.

Ok, Sérgio, eu te conheço e sei que você é turrão mas é inteligente o suficiente para ir direto ao ponto. Se você tivesse respondido minha proposta acima adicionando código de transação ao código que eu escrevi você iria estar misturando conceitos.

Transação dificilmente faŕa parte do domínio de negócios, por isso é muito bom ter alguém, seja um EJB, o Spring ou o que for, delimitando isso de maneira transparente, por configuração, metadados ou o que for.

Sobre o tópico em si: eu já tive alguns casos onde usar EJB fazia sentido mas na maioria deles não. Geralmente chamadas remotas são um belo caso de uso para EJB, muito mais simples que gerenciar tudo via RMI.

Outro casod e uso é uma arquitetura CBD. Acontece que quase ninguém sabe o que é CBD, muito menos saber arquiteturar algo assim.

Quanto ao EJB 3.0 eu acho um ótimo trabalho mas só posso ter certeza após algum trabalho sério. Ah, e a falta de Criteria API é simplesmente ridicula e resultante da pressa.

louds:

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.

Achei o seu exemplo um pouco vago. Se possível mostra um problema e apresenta a soluçao com EJB, para eu ver se consigo sugerir outra sem EJB.

Tem razão, Phillip. Modelo de negócio trabalhando com transação parece ruim mesmo, e eu estava pensando em fazer isso.

Mas digamos que o meu modelo de negócio tem uma função que realiza duas operações que precisam ser atomicas.

Então eu faria essas duas operacoes sem se preocupar com transação e depois daria um jeito de abraçar isso com uma transação, certo?

No caso de um projeto web, acredito que 95% das situações vc vai resolver fazendo a requisicao ficar atomica, com um filtro de transação para abraçar qualquer coisa que ela venha a fazer.

Seria diferente quando por algum motivo, na mesma requisiçao vc estivesse disposto a fazer 2 transações independentes. Se o modelo de negócio não deve se preocupar com as transaçoes, então alguma outra coisa teria que delimitar isso. A action poderia fazer na mão, abrindo as transaçoes e chamando o modelo, ou algum outro esquema de demarcação que eu não conheço.

O que me falta e um exemplo clássico de situação onde EJB vai resolver o teu problema de maneira que justifique o seu uso. Esse tal de controle transacional, parece que as situações que ele resolve são raríssimas, como 2PC.

PS: Phillip, tu sabes que tenho consideração pela sua pessoa e pela sua capacidade técnica, meu amigo. Um dia ainda vamos fazer umas brincadeiras aí no Rio.

Você quer um exemplo que nunca vai existir… nada é insubstituivel… ainda mais em java… voce faz a mesma coisa de 20 formas diferentes… acredito que voce está magoado com EJB 1.x e 2.x e tá querendo procurar pêlo em ovo… se voce quer deixar um filtro servlet cuidar da sua transacao… é uma opcao sua… eu não delegaria essa funcionalidade a um framework web… usaria um EJB ou Spring ou diabo que o parta… acho que cada coisa deve ser usada para um fim especifico… senao… daqui a pouco o webwork vai fazer tela swing tmb… hehe

Sergio, quer um bom exemplo? Uma plataforma de bilhetagem e cobrança.

Os requisitos são bem simples:

:arrow: As regras do negócio devem ser concentradas em um único sistema.

:arrow: Este sistema deve ser acessivel por todos demais sistemas da corporação atraves de uma interface publicada e bem definida.

:arrow: O sistema deve permitir escalabilidade de deployment, isto é, uma alteração nas regras de negocio não deve exigir fazer um deployment de todos sistemas que se utilizam dele.

:arrow: O sistema deve possui ciclo de vida independente dos demais que se utilizam deles.

Ou seja, os requisitos são, a grosso modo, para desenvolver o sistema utilizando SOA e para isto, um framework web é a última coisa no planeta que vc vai querer.

Valeu pelo exemplo. Esse está um pouco mais claro.

Sem necessidade de EJB para isso.

Esse sistema deve prover uma interface de comunicacão para que qualquer sistema possa interagir com ele, certo. Por que não usar HTTP/HTTPS? Qual a necessidade desse sistema que justifique mensagens assíncronas (JMS) ? Por que usar chamadas remotas via EJB, RMI, RPC, SOAP, e essas coisas?

A não ser que vc mude a interface de comunicaçao com o mundo exterior, as regras de negócio poderão ser alteradas sem problemas. Não há necessidade de EJB para obter isso.

Claro, quando o servidor do gmail sai do ar, a sua vida não para.

Tudo depende do protocolo de comunicação que vc quer usar, certo? Há várias opções:

:arrow: HTTP puro

:arrow: XML em cima de HTTP

:arrow: Objeto serializado em cima de HTTP (pode ser binário via post ou hex via get mesmo)

Http só não é muito indicado para um sistema que exiga mensagens assíncronas em real-time, o que não parece ser um requisito desse seu sistema. E mesmo quando precisamos de mensagens assíncronas, na maioria dos casos pooling resolve. E escala sim! Quantas requisiçoes por segundo um tomcat aguenta? Sem contar que vc pode fazer load balance tb para as mensagens assíncronas, sem muita dificuldade.

Sérgio, como nós discutimos.

EJB é um meio de fazer isso

Com EJB 3 você vai na sua classe e coloca:

@Stateless

pronto! Sua classe agora pode ser disponibilizada como serviço, funciona em cluster, tem controle transacional, pode ter acesso a serviços de persistência e segurança e ainda ganha de brinde inversão de controle (e mais coisas ainda)

Ta, não é só isso, tem que ter uma ou outra configuração do AS para certos serviços como cluster. Mas é isso aí, acredito que não seja mais complexo que outras alternativas.

Na verdade HTTP não é muito indicado para qualquer coisa que fuja do seu escopo original: transferir documentos.

Neste momento um dos meus projetos é transformar uma interface HTTP para uma orientada a conexão de modo que seja armazenável em um pool. Abrir e fechar conexões está saindo mais caro do que criar e processar a mensagem.

pcalcado:

Na verdade HTTP não é muito indicado para qualquer coisa que fuja do seu escopo original: transferir documentos.

Neste momento um dos meus projetos é transformar uma interface HTTP para uma orientada a conexão de modo que seja armazenável em um pool. Abrir e fechar conexões está saindo mais caro do que criar e processar a mensagem.

Fazer pooling de conexões, ou usar KeepAlive com HTTP, é uma otimização importante, mas só quando você não tem milhares de clientes simultâneos tentando fazer isso e causar um DDOS no teu sistema.

A conexão é interna de um sistema com outro e já faz literalmente milhares de requisições por segundo, mas este não é o ponto, o ponto é substituir HTTP por algo que já foi criado para ser mantido conectado e que não tenha um milhões de headers para parsear quando na verdade o que se passa é uma string de até 10 letras.

saoj:

Valeu pelo exemplo. Esse está um pouco mais claro.
…

Esse sistema deve prover uma interface de comunicacão para que qualquer sistema possa interagir com ele, certo. Por que não usar HTTP/HTTPS? Qual a necessidade desse sistema que justifique mensagens assíncronas (JMS) ? Por que usar chamadas remotas via EJB, RMI, RPC, SOAP, e essas coisas?

Não falei nada sobre a tecnologia a ser usada, muito menos o wire protocol. Mas sim que a aplicação deve expor sua funcionalidade de forma bem definida. Ou seja, ser acessivel de forma fácil por outros sistemas. Este é um bom caso para usar EJBs ou Web Services, dependendo da possibilidade de existirem clientes não Java.

O ponto aqui é que a solução criada não pode ser uma biblioteca, pois se assim for, quando alterar alguma regra, todas aplicações que usarem ela, vão precisar de um deploy.

Ciclo de vida do projeto! Não falei em uptime! Conhece aquele papo de ciclo de vide de um software? Então, é isso. Este é um requisito muito comum e importante, já que você não quer atrelar manutenções de um sistema com o de outro. Isso é para ter escalabilidade de recursos (desenvolvedores) e gerência.

Qual o ponto de ficar reinventando a roda se você pode usar um negócio já pronto e que funciona? É a mesma coisa que dizer que é melhor usar servlets puro pra um sistema web em vez de usar o framework MVC adequado. Comunicação remota e sistemas distribuídos baseados em RPC são muito mais faceis de fazer com EJB 3.

saoj, entendo seus contra argumentos até ao EJB 2.1. Eu mesmo sempre fui reticente à adoção de EJBs. Mas conhecendo EJB 3.0 estou seguro de adotar esta tecnologia. È tão simples quanto não usar EJB e você ainda ganha um monte de brindes grátis (JTA, JPA, JMS, etc).

Até ontem fiz sistemas sem EJB e só usei quando era requisito do cliente. Hoje eu aconselho usar, simplesmente por dois fatores: a perfumaria gratuita e ser o padrão de mercado.

Aos olhos do cliente o TCO é menor.

Gostaria de saber como usar o JBOSS sem o EJB e não posso usar o Tomcat… Como devo proceder?

Obrigado

Jonasg:

Gostaria de saber como usar o JBOSS sem o EJB e não posso usar o Tomcat… Como devo proceder?

Obrigado

Se sua aplicação não tiver EJBs (ou fizer acesso a eles), o JBoss não irá criá-los do nada. Faça o deploy do seu WAR e vc. não estará “usando EJBs” só pq está rodando no JBoss (isto vale para qq AppServer).

vou ser curto e grosso:

framework é re-invenção da roda.

mano!! nao para mais essa onda filha da #$%! de framework, #$%! merda, daqui a pouco vao criar um framework q programa pra vc…

parem de procurar alternativas, atalhos ou qqr porra que for pra reduzir a quantidade de linhas à ser digitada, pq daqui a pouco vc vai tar digitando:

C:&gtplease do my job today -verbose -xvf
(AHUhAuhAuAHuAHuAHuAHuAhAUhAUhaUhaUhAUhAUAHuAuAH)

um exemplo lindo e perfeito de que isso ja ta acontecendo:

Iterator??? ITERATOR??? q mane iterator, eh FOR INT I = 0; pana nan pana nan e tal…

e ainda digo mais, vou dar exemplo pratico pra vermos que porra de vantagem tem em usar um ITERATOR(hauhau):

===============================================

List list = new ArrayList();

list.add("programador de apis 1 hauahu");

list.add("programador de apis 2 hauahu");

list.add("programador de apis 3 hauahu");

Iterator it = list.iterator();

while(it.hasNext())
{
System.out.println((String)it.next());
}

List list = new ArrayList();

list.add("programador de apis 1 hauahu");

list.add("programador de apis 2 hauahu");

list.add("programador de apis 3 hauahu");

for(int i = 0; i &lt list.size(); i++)
{
System.out.println((String)list.get(i));
}

que coisa…a versão do for, tem menos linhas aHUAHuAHA ridiculo…
OBS: ta eu sei q iterator nao tem nada a ver com framework, mas eh uma reinvencao da roda SIM, e um otimo exemplo disso tbm!

na minha opiniao java é legal, mas emburrece um programador…e cada dia ta emburrecendo mais ainda…daqui a pouco seu chefe cola em vc e fala:

"olha sr. fulano x, aqui nao pode usar essas merdas de iterator e tal pq dificulta o entendimento da logica na hora da manutencao, arrume uma forma alternativa"

"mas sr, eu sou programador frameworkeiro(), e nao sei fazer um loop FOR pra ler um arraylist =("

"bom mas html vc sabe ne? pode me ajudar aqui nesta jsp?"

"é em taglib??? =("

"AHUAHAUhAUhAUhaUhaUahuAHuaHUAH cara, vai pastar vai, c nao sabe nem html pq ja comecou nessas de taglib, aqui eh uma EMPRESA ROOTS, raizes, feita de programadores com base… nao de xucros que acham q tao abafando pq tem sempre uma api q faz tudo por um idiota que nem vc hauhauhauha"

"ai a voz da sabedoria(junto com a do capeta rindo de vc pq vc vai perder o emprego): kakakakakakk mas javeiro é um bicho que nao sabe de nada mesmo, acha q ta abafando com aquele framework porco novo q saiu agora feito no fundo do quintal… vai programar c++ rapá! quero ver vc se fudendo nos malloc() da vida hauHAuAHuAHuAH"

assume sua funcao: VC EH UM PROGRAMADOR E NAO UM USUARIO FINAL, PORTANTO VC TEM Q SABER PROGRAMAR E NAO FICAR USANDO FERRAMENTINHA RALÉ PRA PROGRAMAR SEM DIFICULDADES, PQ O MERITO VAI PRO CARA QUE FEZ O FRAMEWORK E NAO PRA VC, IMBECIL.

agora o que isso tem a ver com ejb?? ejb eh uma reinvencao de RMI…e bem mal feita por sinal hauhauah…

sem mais.

Cara, acho que nunca vi tanta bobagem em um lugar só.

Ex.

framework é re-invenção da roda;

RMI = EJB;

Iterator = “for(int i”;

E outra, tenha mais respeito com os comparsas.
Ou volta pro buraco que tu saiu.

hauhauha beleza…

me fala qual a diferenca entre iterator e for? hahahuah o nome e o jeito de fazer eh diferente…e dai? hauhauha

onde que eu falei q RMI É EJB??? onde??

eu disse q EJB usa principios RMI e eh praticamente baseado nisso…como uma aplicacao distribuida se comunica com seus fragmentos? via RMI…atraves de um lookup no container ejb via jndi…ou seja ejb eh um nome bonitinho pra rmi…com alguns lances de regras de negocios…

[color=red][size=24]Restante do post apagado [/size]

Mensagens com mesmo tom de desreispeito serão deliberadamente apagadas sem mais avisos[/color]

Bom.

Sobre o iterator http://web.cs.wpi.edu/~gpollice/cs509-s04/Patterns/IteratorPattern.html

Você dizer

é bem diferente de

E o motivo de qualquer framework existir é exatamente para não reinventarmos a roda.
Pois aquele código que tínhamos que programar em todos os projetos (o mesmo código), agora é colocado em um framework e reusado em todos(logo não reinventamos a roda);

E outra, não seja mal educado por que ninguém aqui é bixo pra falar dessa maneira.
Exponha suas idéias e diga que são suas, não saia chingando o que não conhece só por que acabou de conhecer uma tecnologia diferente que achou melhor.

e nao quer dizer a mesma coisa??? ahUHAUhAUhAUahuaHuaHuahAUhAUha OMG…
(to falando de rmi e ejb)

voltando aos frameworks:
framework é sinonimo de lazy programmer detected(hauhAUHA), blz agora falando serio. é uma reinvencao da roda sim pq framework eh uma incrementacao tosca pra uma determinada sessao da linguagem java ou seja frameworks vieram depois que java foi lancado…logo o que vc ta me falando LOGICAMENTe nao prossegue…

quer reciclar objetos? velho, ce quer ser lixeiro ou programar java? hAUHAU com essa onda de framework, tá parecendo aquele brinquedo de montar: LEGO…vc pega os tecos do codigo, ctrl + c, ctrl + v, e ja era, ai da pau e o animal nem sabe porque, de tanta camada que tem em cima da aplicacao java dele…virou uma salada de frameworks hauha UAUU que POWER-ADVANCED…pra mim javeiro nao sabe de nada e quer só complicar os codigos com essas palavras bonitas, elegantes e grandes, pra poder valorizar seu trabalho(como o q ocorreu no EJB 1.1 kakakakk q todos viram q era uma grande merda)

ahh! li seu artigo do iterator e nao vi nenhuma vantagem em utiliza-lo ainda hauha, obrigado de qualquer forma(sem ironia), qualquer conhecimento é bem vindo, mas prefiro meu FOR.

pense comigo: o tempo que vc perde aprendendo uma porra de um framework novo, vc pode usar criando sua propria estrutura e dps utiliza-la inumeras vezes…a concepcao do struts por exemplo, é legal, mas vc nao precisa usar o struts pra usar o modelo MVC de aplicacoes web…

sem mais por enqto

void iteraSobreQualquerCoisa(Iterator&lt? extends MinhaInterface&gt it){
 MinhaInterface i = it.next();
 i.fazAlgo();
}

EJBs podem ser locais ou se comunicar via JMS.

Uma aplicação distribuída pode utilizar diversos protocolos, entre eles HTTP, CORBA, XML-RPC e o tal RMI.

O resto do psot foi apagado pela moderação porque ignorância é uma coisa mas desreispeito é inaceitável.

fr3akoutTotal:

framework é sinonimo de lazy programmer detected(hauhAUHA), blz agora falando serio. é uma reinvencao da roda sim pq framework eh uma incrementacao tosca pra uma determinada sessao da linguagem java ou seja frameworks vieram depois que java foi lancado…logo o que vc ta me falando LOGICAMENTe nao prossegue…

Ou seja: não use o framework já que ele reinventa a roda, reinvente a roda você mesmo. :roll:

nossa cara vc eh muito burro, da raiva…hauaha mas blz n vou mais perder meu tempo aki…seja mais um desses merdas programadores de alto nivel(no sentido de abstracao na programacao, ex: assembly = baixo nivel) usando bastante frameworks, q abstraem praticamente tudo de um codigo fonte, pra vcs jagunços utilizarem e se sentirem grandes programadores escrevendo 3 linhas de codigo e o “generator” gerando 200, daqui a pouco nego n vai saber nem escrever html com essas porcarias de taglibs, por exemplo, que ridiculo hauhauah

im out.

(ahh le a piadinha sem graça na minha assinatura antes de fechar a tab hauhaua)

Fazer msuas proprias estruturas? Tipico de programador inciante que acha que poder fazer melhor que 2000, 3000 engenheiros experientes… ou seja, de gente sem noção do que é desenvolver software!

Olá pessoal, desculpem se estiver no tópico errado, mas eu vi alguns falando em “cluster”, eu trabalho com java a pouco tempo e me surgiu a tarefa de pesquisar sobre cluster de aplicações JEE, eu trabalho com weblogic 8.1 e Oracle, gostaria de saber se alguém tem algum material( apostila, link, exemplos, etc…) q me ajude a entender esse lançe de cluster em aplicações java.

Desde já agradeço a ajuda e compreensão de todos.

[]'s

Pessoal surgiu uma duvida lendo esse topico.
Utilizando o Cluster no Jboss o cluster no jms com Ejb é nativo?

louds wrote:

Uma plataforma de bilhetagem e cobrança.
Os requisitos são bem simples:

As regras do negócio devem ser concentradas em um único sistema.

Este sistema deve ser acessivel por todos demais sistemas da corporação atraves de uma interface publicada e bem definida.

O sistema deve permitir escalabilidade de deployment, isto é, uma alteração nas regras de negocio não deve exigir fazer um deployment de todos sistemas que se utilizam dele.

O sistema deve possui ciclo de vida independente dos demais que se utilizam deles.

gostei do exemplo, valeu Louds

Algo para pensar. Pode virar um elefante branco se eu utilizar HTTP/HTTPS, e se os demais sistemas que irão interagir utilizarem outros tipos de interface. Acho complicado.

saoj wrote:
Tudo depende do protocolo de comunicação que vc quer usar, certo? Há várias opções:

HTTP puro
XML em cima de HTTP
Objeto serializado em cima de HTTP (pode ser binário via post ou hex via get mesmo)

Http só não é muito indicado para um sistema que exiga mensagens assíncronas em real-time, o que não parece ser um requisito desse seu sistema.

Saoj, pergunta: se no caso o sistema tivesse mensagens assíncronas em real-time, o que você recomendaria?

Provavelmente usar EJB ou OpenJMS. Embora plenamente possível, vc não vai querer fazer o seu gerenciador central de mensagens na mão. É loucura. A não ser que te paguem pra isso…

Transacao é demarcada pela aplicacao, nao é pelo negocio e nem pela web, portanto…

Esse é um requisito da aplicação e nao do negocio.

use uma camada de aplicação.

Você parece fixado com transacao mas ja foram citados outros motivos, inclusive remoting que IMO ja e um grande argumenbto a favor de ejbs.

Tudo bem. Mas na grande maioria dos casos basta fazer sua action/requisição atômica, ou seja, uma requisção = uma transação. Não há porque complicar isso…

Remoting seria um motivo mais forte do que transação, na minha opinião. Só que para Remoting vc tb pode usar xFire, RMI, Soap, REST e por aí vai…

saoj:

Remoting seria um motivo mais forte do que transação, na minha opinião. Só que para Remoting vc tb pode usar xFire, RMI, Soap, REST e por aí vai…

é por isso que a sun vai lançar os profiles no Java EE6.

Minha regra é a seguinte. Dado o conjunto de requisitos: remotabilidade, transacoes, seguranca, persistencia, cluster, caching, pooling e inversao de controle. Se voce precisa de apenas UM deles, nao use EJB< use uma tecnologia que só faça isso. Se voce precisa mais varios destes, use EJB porque uma so pessoa ja vai te dar tudo isso.

Acho simplista podendo nao ser suficiente em alguns casos, o que te levaria a ter demarcacoes em varios lugares.

E você parte do pressuposto que transacoes em session beans sao complicadas, o que nao é verdade.

Paulo Silveira:

Minha regra é a seguinte. Dado o conjunto de requisitos: remotabilidade, transacoes, seguranca, persistencia, cluster, caching, pooling e inversao de controle. Se voce precisa de apenas UM deles, nao use EJB< use uma tecnologia que só faça isso. Se voce precisa mais varios destes, use EJB porque uma so pessoa ja vai te dar tudo isso.

Não só vai dar as tecnologias mas também as especificações ne, senao seria apenas outro framework.

Lembra Spring?

Aqui.

http://e-docs.bea.com/wls/docs81/cluster/overview.html

o google faz coisas que vc nem imagina!!!