EJB / Herança

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

“ozielneto”:

Herança em EJB é um crime em dois pontos de vistas:
1 (OO View) - EJB é uma camada de Serviços para Aplicações.

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:

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

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

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

Site do TopLink na OTN:
http://otn.oracle.com/products/ias/toplink/content.html

Starting Guide:
http://otn.oracle.com/docs/products/ias/doc_library/903doc_otn/toplink.903/b10061/toc.htm

Tutoriais:
http://otn.oracle.com/docs/products/ias/doc_library/903doc_otn/toplink.903/b10062/toc.htm

QuickTour:
http://otn.oracle.com/products/ias/toplink/quicktour/index.htm

Demonstrações:
http://otn.oracle.com/products/ias/toplink/mwdemos/content.html

Vale ressaltar que o TOPLINK é uma camada de persistência que trabalha com qualquer banco de dados em qualquer servidor de aplicacoes J2EE.
[ ] ´s

Valeu, Adriano

Bom.

O foco dessas qualidades sistêmicas é avaliar a saude de um sistema. A J2EE foca disponibilizar serviços amigavelmente para suportar os niveis de qualidade exigidos para que um sistêma esteja saudável e aceitável para os “stakeholders”.

Portanto, sem fugir do tópico de Herança, o uso de EJBs se faz necessário em alguns sistemas e em outros não seriam indicados ( depende do tamano e capacidade desejados ). É por isso que hoje existem 6 tipos de EJBs.

Como todo framework, tem seus benefícios, custos e limitações. A Herança em EJBs é uma dessas limitações. O maiores benefícios são, segurança, diminuição da complexiade transacional e failover. Acho que para se ter esses benefícios, vale a pena ter um desenvolvimento mais complexo, e até para pagar melhor o desenvolvedores. O mercado paga bem melhor quem conhece EJB ao invés de quem conhece Hibernate, Struts e Prevlayer. Que coisa???

Entretanto, todo sistema distribuido, relacionado a BI (B2B, B2C, C2C, EDI, e etc) pode usar EJBs para implementar a solução com uma qualidade desses serviços em nível ótimo, sem esquecer de todo o suporte dos J2EE Containers (WEB e EJB). Até porque essas aplicações vão ser suportadas pelos robustos AppServers (SunOne, WebSphere, Oracle, WebLogics, etc). Quem investiu nessas ferramentas, espera obter o melhor delas, e para isso o uso do EJBs se faz necessário. Sem herança, é claro.

E a discussão não é se EJB é bom… Mas se herança é indicado? A respota é não. Pode ser feita, com alguma restrições, mas não é bom. Vários autores pregam o uso da Agregação ou Composição ao invés de se usar herança, e assim ter modelos menos complexo, mais flexiveis e mais orientados a serviços. Outra ironia… EJBs foram desenhados para prover serviços de negócios e não ser o negócio. Mais um ponto pelo qual a herança não é indicada.

Para finalizar, eu sempre indico que os técnicos façam treinamentos específicos antes de lidar com tecnologia. Basta ver a quantidade de posts com dúvidas tão básicas que são feitas no nosso forum todos os dias. Isso porque as pessoas insistem em começar a usar sem antes conhecer. Sabe qual o maior mal do brasileiro? Usar a TV sem antes ler o manual. Isso é ruim, cria gaps de conhecimento e durante o processo de construção de um sistema pode ser desastrozo.

[Propaganda sobre os cursos da Sun cortada pelo moderador]

Um bom trabalho a todos.

Acho injusto a censura sobre o meu topico… Toda opnião aqui deveria ser respeitada garantindo nosso direito de expressão…

Não estava fazendo propaganda, até porque não ganho comissão.

Essa atitude por parte do moderador vai no mínimo contra aos propósitos do forum, que é criar um debate construtivo e compartilhado de conhecimento.

Que fique registrado meu voto de descontentamento.

Um bom artigo sobre o tema,

o interessante desse artigo eh que o cara eh claro, sem deixar o EGO dele atrapalhar na resposta! :x

http://www.onjava.com/pub/a/onjava/2002/09/04/ejbinherit.html

Pra bom entendedor…

Abraco a todos.

Pessoal,

Desculpe se escrevi no local errado ou com a formatação errada. Esta é minha primeira mensagem para este grupo.
Eu nunca fiz curso algum na Sun, portanto acho que estou na categoria dos despreparados, segundo o Oziel. Mas como tenho 18 anos de experiência em Informática, 5 anos de experiência em Java e mais de 60 artigos publicados em revistas sobre o tema, acho que vou dar meu palpite mesmo assim.

Herança nada têm a ver com a velocidade de um sistema. O Websphere implementa herança em EJBs (inclusive com polimorfismo), sem queda de performance perceptível. Eu testei. Não estou falando o que ouví.

Também não vejo o que têm a ver a falta de herança com qual a camada em que os EJBs estão situados. Existe alguma regra para adotar herança ou não em cada uma das camadas ?

Se discutir a falta de herança nos EJBs for falta de preparo para a tecnologia EJBs, acho que existe um mundo de pessoas por aí que não conhecem nada (inclusive eu). Existem pelo menos umas 10 listas de discussão espalhadas pelo mundo falando sobre o tema, em sites respeitáveis. Aceitar cegamente as palavras que um fabricante prega faz com que não vejamos com clareza a verdade.
A função dos consultores e especialistas deveria ser não vender a posição de um fabricante, mas sim mostrar os prós e contras para o cliente

Meu palpite é que a opção por não implementar herança foi simplesmente para facilitar o mecanismo de distribuição. Se um EJB não têm filho, não corremos o risco de colocar o EJB pai em uma máquina e o EJB filho em outra. Adotar algo mais próximo dos componentes faz com que os componentes fiquem mais soltos (minha opinião).

Realmente a maioria dos especialistas sugere a adoção de composição (e não agregação) ao invés de herança. Mas isto não é unanimidade.
O que se prega é que a herança pode quebrar o princípio do encapsulamento. Se você está utilizando uma classe filha em um sistema, e por alguma razão altera a classe pai, você pode arrebentar com o comportamento da filha, decorrente desta alteração. Isto fere o princípio do encapsulamento. O que se sugere é instanciar o pai, e colocá-lo como composto dentro do filho (sim, porque cada filho terá sua instância de pai, e portanto não pode ser uma agregação). Cada vez que você precisar chamar um código do pai, o faz através de delegação. Supondo que os códigos do filho estejam criados de uma forma apropriada, o código fica mais robusto. Feiérrimo, mas é o recomendado.

Por último, os JDOs foram criados como resposta para uma infinidade de empresas que não necessitam dos mecanismos de distribuição e nem segurança dos EJBs, mas eram obrigados a ter o overhead por falta de um outro padrão.
Existe uma grande quantidade de empresas que estão adotando EJBs, quando este não deveria ser o caso. Leiam o artigo do Martin Fowler (que deve estar também na categoria dos despreparados), que fala exatamente sobre este problema http://www.sdmagazine.com/documents/sdm0304a/

Gostaria de deixar claro que não sou contra os EJBs
Um abraço a todos desta lista.

Somente para responder a pergunta original, existe um artigo sobre herança em EJBs no endereço http://www.onjava.com/pub/a/onjava/2002/09/04/ejbinherit.html
No final do artigo o autor diz que pode funcionar em um servidor e não funcionar em outros. Se você quizer fazer códigos portáveis, acho que deve evitar utilizar esta idéia.