Bom dia para todos!
Bem garela, estou utilizando XDoclet e minha duvida é: como faço para implementar Herança nos EJB’s?
É simplesmente “extender” a minha superclasse?
E a PK?
Bem galera,
Me disseram que o xdoclet / ejbs não gera o mapeamento para bd relacional diretamente. E que o melhor que tenho a fazer é criar um relacionamento 0…1 para 1 e fazer uma interface simulando a minha super classe e as sub classes implementarem ela. E no meu entity, session, setar os atributos de super no VO.
Simulando a Herança.
Fala, egcoelho!
Eu estou implementando um projetinho usando jboss e xdoclet… Também recaí na mesma dúvida que vc, a um tempo atrás. A resposta é:
A especificação EJB 2.0 não comporta herança de Entity Beans, o que, convenhamos, é pelo menos uma pena, p/ não dizer um absurdo. Acho que a Sun não quis pisar no terreno frágil de como modelar a herança no BD, escolher um ou outra solução em detrimento de outra, etc…
Como consequência, o xdoclet também não lida com isso, e como vc já deve ter percebido, quando vc tenta fazer herança, as classes geradas contém muitos erros, como métodos sobrescritos que só mudam o tipo de retorno, etc…
A solução que adotei: utilizei composição ao invés de herança. Ou seja:
Se tenho uma classe Party, e uma classe Person que herdaria de Party, na verdade Person contém um relacionamento 1…1 com Party. Os métodos herdados, na verdade, delegam a tarefa p/ Party.
Desculpa se chovi no molhado, espero ter ajudado!
Falou!
Põ cara,
ajudou sim.
Confirmou o que eu havia feito.
Herança em EJB é um crime em dois pontos de vistas:
1 (OO View) - EJB é uma camada de Serviços para Aplicações.
2 (Tech View) - Vai ficar uma carroça.
[]´s
[quote=“ozielneto”]Herança em EJB é um crime em dois pontos de vistas:
1 (OO View) - EJB é uma camada de Serviços para Aplicações.[/quote]
Não entendi o que vc quer dizer com isso, Oziel - se EJB é uma camada de serviços, então pq a gente tem o nosso modelo (entity beans) enfiado nela? Soa contraditório, no mínimo.
Se isso não fala mal sobre a forma como a especificação foi (mal-) feita, eu não sei o que fala, então 
também não entendi, achei que tinha que funcionar perfeitamente.
se é OO, por que não posso utilizar herança??
Querido Carlos,
Não vamos polemizar ainda mais esse assunto… EJB é um framework como qualquer outro que tem prós e contras.
Particularmente, eu acho muito interessante e eficiente o uso de EJBs, pois as qualidades de serviço das aplicações corporativas e distribuidas são facilmente contempladas usandos os EJBs.
E para se alcançar essas qualidades sistêmicas, existem algumas restrições, como a herança. Ou seja, em detrimento a uma visão OO mais purista, evitamos a herança em EJBs para se ter uma melhor performance e maior robustes. (É para isso que existem os Arquitetos, para dar a melhor solução de um problema que impacta nas qualidades sitêmicas de uma aplicação e garantir a sua saúde).
A especificação dos EJBs não foi mal feita como você concluiu. Justamente contrário a esta idéia existem 6 tipos de EJBs, um para cada situação da aplicação ( serviços conversacionais, não-conversacionais, persistência e trocas de mensagens ).
Sugiro você estudar um pouco mais afundo os casos de sucesso no mercado usando EJB, e você verá que eles falam por si só.
[]´s
uma duida só agora,
herança não funciona legal nem com os EntityBeans??
Sim, a diferença para os outros frameworks é que ele tem mais contras do que prós 
Voce poderia listar as tais “qualidades de serviço das aplicações corporativas e distribuídas”? De todas as que eu consegui pensar, EJBs não são a melhor solução existente para nenhuma delas.
Isso mostra como a Lei das Abstrações Falhas não erra: toda abstração falha de alguma forma, e esse caso não é diferente: ao tentar construir uma camada OO para um banco de dados relacional, falhou-se ao tentar conseguir performance.
A solução? Enfiar uma restrição nos sistemas que usam a ferramenta. Definitivamente, foi uma saída, mas não foi a melhor delas - existem muitas outras ferramentas de mapeamento O/R aí pra mostrar que é perfeitamente possível ter persistência em bancos de dados relacionais com performance muito boa, sem sacrificar os princípios da OO.
Ah, e sem querer ser muito chato, robustez é com “z”. Se vai fingir que sabe do que tá falando, pelo menos acerte no português.
De fato, os dois ou três casos de sucesso de EJBs existentes devem falar alguma coisa perto dos zilhões de casos de insucesso que essa tecnologia trouxe pro mundo Java. O pessoal tentando manter código J2EE também deve ter muito a dizer - e sei que incusive vc, Oziel, já teve de dar manutenção em alguns sistemas, e sei que vc não se deu muito bem, ou, colocando de outra forma, poderia ter se dado melhor. Só não entendo como vc não percebeu até agora que EJB é um freio de produtividade em forma de especificação.
Usar a Herança em EJBs é tecninca possível. Entretanto não é tecnicológicamente indicado.
Realmente, eu corrigi alguns sistemas que usam EJB pois programadores inexperientes ou desavisados implementaram coisas erradas. Quanto ás “qualidades sistêmicas” que falei, sugiro você fazer o SL425 da Sun.
[]'s
Bom trabalho.
Tá, a questão toda aqui é: POR QUÊ não é tecnologicamente indicado?
…e pagar 4 mil reais ou mais pra “aprender” a trabalhar com uma tecnologia que eu não quero usar? Não, obrigado, Oziel, eu só queria que vc listasse as tais qualidades, mas vejo que vc não quer basear suas afirmações em fatos, e prefere fugir mandando o pessoal fazer curso. Tudo bem, eu entendo, afinal, vc eh instrutor 
No post anterior… …em detrimento a uma visão OO mais purista, evitamos a herança em EJBs para se ter uma melhor performance e maior robustes…
Systemic Quality Categories
• Manifest qualities:
• Performance
• Reliability
• Availability
• Operational qualities:
• Throughput
• Manageability
• Security
• Serviceability
• Testability
•Developmental qualities:
• Realizability
• Planability
• Evolutionary qualities:
• Scalability
• Maintainability
• Extensibility
• Flexibility
• Reusability
• Portability
Impact of Dimensions on Systemic Qualities
• Capacity
• Redundancy
• Modularity
• Tolerance
• Workload
• Heterogeneity
[]'s
EBA! :twisted:
• Performance
Piada, né? Olha o peso e overhead que um application server J2EE tem quando vc comeca a lidar com EJBs…
• Reliability
De fato, não cai, foda é botar em pé
• Availability
Razoável… se acontece algum problema de rede, por exemplo, os appservers geralmente não são inteligentes o suficiente pra se virar, ao contrário de soluções distribuídas de verdade, como Jini ou JXTA.
• Throughput
Vide comentário sobre overhead acima.
• Manageability
Boa, em projetos pequenos, em projetos grandes, não funciona de acordo.
• Security
Boa.
• Serviceability
Vide comentário sobre gerenciabilidade acima.
• Testability
Horrenda. Se voce duvida, tente fazer TDD (Test-Driven Development) com EJBs e, se vc continuar em perfeitas condições mentais, volte pra contar a história.
• Realizability
Ruim. É difícil desenvolver soluções baseadas em EJBs é complicado demais pro que deveria ser, mesmo usando as melhores ferramentas disponíveis. Vide comentário acima.
• Planability
Pouca, a menos que vc contrate meia dúzia de arquitetos caríssimos e pomposos que andam com o Core J2EE Patterns enfiado no sovaco o dia inteiro.
• Scalability
Boa, mas vide comentários sobre gerenciabilidade.
• Maintainability
Ridídcula. Vide comentário sobre testabilidade acima.
• Extensibility
Ruim. Se eu quiser adicionar novos tipos de serviços (system-wide logging, ou caching otimista, por exemplo), eu tenho que modificar o application server, ou usar uma extensão proprietária.
• Flexibility
Vide comentário acima.
• Reusability
Fraca, tanto pelos usuários da tecnologia que não estão acostumados a reusar EJBs quanto pela tecnologia em si, que não encoraja isso.
• Portability
Boa, em termos - deployment descriptors proprietários ainda são a solução em muitos casos.
• Redundancy
Se isso quer dizer redundância de código, tem sim - e muita. Duvida? Pegue um sistema, desses bem arquitetados, e procure ver quantas vezes um mesmo dado é copiado durante o fluxo de execução.
(as outras características não considerei relevantes na conversa, então não vou comentar)
Oba oba!!! A discussão tá começando a ficar boa e construtiva!!!
Deveria rolar um artigo sobre EJB´s , prós e contras pra galera do GUJ !!!
Abraços
É isso aí, bota p/ quebrar!
Minhas opiniões:
-
Como disse anteriormente, acabei usando composição no lugar de herança, para burlar o limite da falta de herança com CMP + EntityBeans… Acredito que a solução ficou muito boa, seria o que se faria ao se normalizar o banco, reduzindo muito campo duplicado no BD. Perdi performance com isso??? Talvez, mas vivo com isso. Como já disse Knuth, cuidar da otimização prematuramente é a semente de todo mal.
-
Concordo que esta não foi a melhor solução, seria muuiiiittooo melhor se pudesse utilizar príncipios OO puros. Mas por outro lado, não ter que cuidar de uma série de detalhes (como cache das entidades, segurança, persistência…) acaba me tornando mais produtivo sim. Utilizando alguns recursos do JBoss, nem mesmo tive o trabalho de construir as tabelas no BD. Acho que neste sentido, ponto positivo.
-
Faço testes usando JUnit e estou são e vivo p/ contar… não é tão ruim assim… nem tive que apelar p/ o Cactus…
Enfim, sou um defensor do J2EE. Claro que respeitados seus limites. Não vamos tentar construir uma aplicaçãozinha cliente utilizando J2EE, que é um absurdo. J2EE é munição pesada p/ problemas sérios, onde o preço e tamanho do servidor não importam…hehehehe!!!
Devo discordar do ozielneto numa coisa. Dá p/ fazer muita coisa, e ter opinião, sem se fazer os cursos da Sun. Eu não fiz…
Falou!!!
Será que eu sou o único anti-cristo aqui?
Ponto positivo, até vc precisar de algum serviço que não está incluído no pacote. A gente é muito panaca mesmo, e se contenta com pouco. Já pensou se, além de segurança, controle transacional, caching e persistência, vc precisasse de FTS (full-text searching)? E aí, fodeu né? O container não vai te ajudar em nada aqui, e extender os mecanismos dele torna sua aplicação não-portável. Ponto negativo, e um bem grande nesse quesito.
E quanto tempo demora pra montar cada test run? 5 minutos? 10 minutos? 20? 30? Enquanto vc espera seu application server subir, eu já rodei meus testes nas Actions do WebWork e entidades AOP umas 20 vezes. Mas, se vc tem paciência pra essas coisas, tudo bem, vc deve estar tentando entrar na fila pra ser canonizado ou algo assim
Eu também gosto da J2EE, não me levem a mal - tirando as partes mal-feitas dela, como, por exemplo, EJBs, é uma ótima tecnologia, e muito melhor do que as disponíveis em outras plataformas, como .NET, IMHO.
Tem um problema sério na sua atitude aqui, cara. Se voce quer continuar elitizando a tecnologia (Java é para poucos!), tudo bem, mas eu gosto de ver gente que antes trabalhava com VB chegando pra mim e dizendo “nossa, como Java é facil!” algumas semanas depois de começar. Aí esses caras pegam EJB pra aprender, e curiosamente, mudam de idéia assim que começam a se aprofundar.
De repente, toda essa história de “J2EE é um canhão e não serve pra mosca pequena” deixa de ser uma coisa pra se orgulhar. Um container não deveria ser munição pesada - se a J2EE é a única spec para server-side que a gente tem, então deveríamos tratá-la como pau pra toda obra. E você há de concordar comigo, EJBs não são pau pra toda obra de jeito nenhum e, infelizmente, não temos uma tecnologia padronizada e amplamente disponível que sirva para todos os casos, dos pequenos aos monstruosos.
Muito bem dito, fbdo…
Bom, posso ser, aqui no GUJ, mas está na hora de dar uma olhadinha lá fora:
http://freeroller.net/page/ceperez/20030719#have_ejb_vendors_just_discovered
Me impressionou bastante o link para a comparacao de features entre o TopLink (da Oracle) e EJBs, versão 1.1 e 2.0. Não fiz muita coisa com o TopLink, mas isso aqui é de convencer qualquer um de que 1) TopLink é foda, e 2) EJB é uma merda mesmo:
http://otn.oracle.com/products/ias/toplink/addvalueover_ejb2.html
É esse TopLink é bem interessante mesmo… Gosto muito dos produtos da oracle (por isso minha proxima certificacção será OCA!) e acho o pessoal de lá extremamente competente…
Quanto à dizer q EJB é uma bosta, acho radical demais… Simplesmente EJB é uma tecnologia que têm MUITO a se desenvolver… Só isso… Para alguns problemas ela se encaixa mas para outros realmente faltam alguns recursos importantes…
É isso…
Ps: cv vc já viu algum exemplo de implementação desse TopLink??? Se sim onde eu posso vê-lo? Esse negócio me interessou!!!
Abraços
Cara, tem exemplo pra caramba de uso do TopLink na OTN (http://otn.oracle.com), mas infelizmente eu tou sem tempo de procurar um link mais direto pra vc. Qualquer coisa, entre em contato com o pessoal da Oracle aqui no Brasil, e eles podem te dar uma força com exemplos, documentação, demos, etc.