EJB 3: Dead Or Alive?

chun wrote:
1) EJB sem JavaEE não tem muito sentido... perde-se muito... quanto ao JSF como te disse SUBSTITUI... agora se vc quer ou não eh opção sua.

Vamos focar em EJB e esquecer o resto.

chun wrote:
2) Aprender JPA != Aprender Hibernate... Hibernate faz muita coisa da maneira dele... e mais mais que JPA... não é igual... JPA por exemplo nao tem criteria... a complexidade é maior. Voce poderia me citar qual a diferenca entre uma implesmentacao de JPA e outra ? se implementa JPA tem que seguir diversos padroes... voce tem um exemplo concreto disso ?

http://lists.jboss.org/pipermail/hibernate-issues/2007-August/006677.html
Apenas um exemplo.

chun wrote:
3) Spring com annotations ? só se for na super mega versao nova... ou com mais um framework do urubatan... mais um hein ? hehehe

Não mesmo. Não lembro exatamente em qual versão do Spring veio isso. Acredito que na versão 2. Não estou lembrado, mas faz um tempinho que já tem isso.

chun wrote:
4) Brinque com o Glassfish e vai perceber o que load balance na web tem a ver com EJB As vezes voce precisa balancear a carga da regra de negocio e com glassfish isso é simples.

Ta, você configura os dois juntos com o mesmo clique, isso não significa que funcionam da mesma forma ou que sem usar EJB\glassfish seja uma coisa do outro mundo.

Alias, estamos discutindo o que aqui, EJB ou Glassfish?

1) Dificil... um exemplo seria o controle de transacoes é por parte do JTA que é JEE e nao EJB... entre outros...

2) É um bug cerebral do pessoal do Hibernate, é só seguir JPA e deixar essa "feature" de lado

Não entendi sua colocação... ainda se eu seguir JPA posso usar hibernate... do contrario tenho este problema que voce citou.

3) Tempinho ? Fale com o urubatan... ele sabe bem quanto TEMPINHO a Interface21 levou para "lembrar" que existe annotations...

4) Nao funcionam da mesma forma... eles "apenas funcionam" , e ae voce configura detalhes do balanceamento mas eh bem DRY e CPE

Glassfish Implementa Jave EE 5 e atualmente é o container mais "amigavel" do mercado OpenSource

This message was edited 3 times. Last update was at 26/08/2008 15:49:05

chun wrote:1) Dificil... um exemplo seria o controle de transacoes é por parte do JTA que é JEE e nao EJB... entre outros...

Desisto...

chun wrote:
2) É um bug cerebral do pessoal do Hibernate, é só seguir JPA e deixar essa "feature" de lado Não entendi sua colocação... ainda se eu seguir JPA posso usar hibernate... do contrario tenho este problema que voce citou.

Antes de mais nada eu teria muito cuidado antes de falar que o pessoal do Hibernate tem um bug cerebral

Acho que você não leu o meu link, é um bug report que eu fiz de uma funcionalidade: o uso de Date e Calendar. A JPA do Hibernate não obriga o uso de @Temporal, o Toplink obriga. O ponto é: esse é apenas um exemplo de uma funcionalidade que funciona diferente em duas implementações de JPA, e, sim, existem mais exemplos de incompatibilidades entre as implementações.

chun wrote:
3) Tempinho ? Fale com o urubatan... ele sabe bem quanto TEMPINHO a Interface21 levou para "lembrar" que existe annotations...

Cara, o Spring 2 saiu no final de 2006, vai fazer dois anos

chun wrote:
4) Nao funcionam da mesma forma... eles "apenas funcionam" , e ae voce configura detalhes do balanceamento mas eh bem DRY e CPE

Desisto de novo. Fazer cluster não é só dar uns cliques no console do glassfish e você tem um cluster com load balance e tudo mais. Há muito mais envolvido. Além disso, configurar cluster em outros AS e cluster da camada web sem AS não é complicado também.

Vamos lá denovo hehehe:

1) Não desista... admita... EJB esta contido em Java EE e não teria nem logica em usar um sem o outro... voce pode até não usar os recursos do container... mesmo assim vai estar usando JavaEE

2) Segundo a SPEC quem está certo ?

3) JavaEE 5 é bem mais velho

fora que é uma spec e não um framework.

4) Não acho... eh isso que voce não entende... eu compreendi a sua parte... mas em glassfish fazer um setup INICIAL para isso é SIMPLES... fazer tunning em cima disso é outros 500 , separar quais nós vão cuidar de quais servicços é outros 500... agora, se voce precisar fazer isso, vai perceber que tmb não é um bicho de 7 cabeças...

chun wrote:
2) Segundo a SPEC quem está certo ?

A questão não é quem esta certo ou quem esta errado, a questão é que não basta adicionar JPA.JAR no lib do projeto e sair usando JPA a torto e a direito sem entender as particularidades implementação. Então essa de que é usar JPA é um framework a menos para entender cai por agua abaixo.
Isso por que eu nem mencionei a questão do second-level cache que não é coberta pela especificação!

chun wrote:
3) JavaEE 5 é bem mais velho fora que é uma spec e não um framework.

Java EE 5 é 'bem' mais velho, ok. O ponto não é esse

O ponto é que eu não preciso de um AS que leva pelo menos 10 vezes mais para carregar para controlar transação com anotação

chun wrote:
4) Não acho... eh isso que voce não entende... eu compreendi a sua parte... mas em glassfish fazer um setup INICIAL para isso é SIMPLES... fazer tunning em cima disso é outros 500 , separar quais nós vão cuidar de quais servicços é outros 500... agora, se voce precisar fazer isso, vai perceber que tmb não é um bicho de 7 cabeças...

Caramba, a discussão era sobre uso de N frameworks X EJB, pare de ficar falando que o glassfish é isso ou aquilo. Ta parecendo eu falando do Mentawai po

EJB3 ++

O legal é que os dois brigam, não chegam a lugar nenhum e todo mundo se beneficia da diversidade que temos.

Embora eu, pessoalmente, prefiro usar um mínimo de frameworks e aderir à especificação.

danieldestro wrote:O legal é que os dois brigam, não chegam a lugar nenhum e todo mundo se beneficia da diversidade que temos.

Embora eu, pessoalmente, prefiro usar um mínimo de frameworks e aderir à especificação.

Eu já prefiro os frameworks hehehe

E os dois não estão brigando, só discutindo. O chun é evangelista de carteirinha mesmo, então é facinho de rolar uma discussão longa com ele defendendo o glassfish, ejb e o netbeans como se fossem as últimas ferramentas/frameworks/specs do mundo

Olá

leandrokjava wrote:mas pq muita gente vai preferir não usar JSF?
depois que conheci JSF, nunca mais quis voltar para Struts.

Quando conheci JSF (na versão 1.0), fiquei com a impressão que da Sun dificilmente sairá algo que preste em termos de desenvolvimento web. Será que um dos motivos é que o criador do Struts 1.x trabalha lá?

[]s
Luca

This message was edited 1 time. Last update was at 26/08/2008 22:02:18

Eu uso EJB 3 e to achando bom, bem facim

JavaGuru Membro desde: 27/01/2005 11:41:47 Mensagens: 294 Offline

Facelets + JSF > Struts. Definitivamente.

JSF > Struts? Eu acho. Mas, your mileage may vary...

Respondendo ao Rubem:

1) Ae que está a questão... hibernate botou um plus na SPEC... e eu vou trabalhar com a SPEC e nao com o hibernate... entao não me beneficio desta "feature" logo... se estou dentro da SPEC não preciso nem saber o que é hibernate... e vc pode falar que não... em 1% dos casos você até pole puxar o HibernateSession diretamente do EntityManager para fazer algo que "só ele faz" , mas isso é 1% do seu software... e uma equipe tem os outros 99% para se preocupar...

2)10 Vezes ? Acho que voce REALMENTE precisa fazer novos testes... use apenas o WebContainer do Glassfish ( que nem voce usa o tomcat ) e vai ver algo BEEEEEEMM diferente que 10 vezes... um numero BEEEM menor... com um plus de algumas toneladas de servicos que podem ser utilizados e sem nenhum "guru da programacao" reinventando a roda.

3)Que culpa eu tenho se voce vem com essa de 10x mais lento sem testar ? Se é para falar besteira... quero falar tmb

Leozin,

Não estou defendendo nem o glassfish e nem o NetBeans, apenas respondendo ao rubem que simplesmente acha EJB3 a coisa mais dificil e inutil do universo... só que provavelmente ele parou no EJB 2 e agora prega isso ae...

Disseminar informacao incompleta não dá...

This message was edited 4 times. Last update was at 27/08/2008 07:57:41

Bom, Chun posso dar minhas considerações ?

1) O Spring é muito mais que um container para IoC e sabes disso, mas me pautando somente nessa feature, EJB não faz IoC de Pojos. Isso já é motivo suficiente para algumas arquiteturas fazerem uso do IoC do Spring, como o Grails, que faz uso dessa característica para injetar recursos sem serem EJB.

Vou dar uma rápida passadinha no Spring, somente para lembrar algumas coisas :

- Framework MVC - ActionBased, pois em muitos cenários de negócio ainda pela especificação JSF 1.0 , ponto até que o Gavin King quer que mude é o clico de vida statless - Alternative stateless UI component lifecycle - http://in.relation.to/Bloggers/GavinsBlog/Tag/EE6+Wishlist.

Só esse monto para usários simultâneos, dependendo do perfil da aplicação já faz a solução Component Based não ser viável por questões de ROI, já que MVC custaria infinitamente mais barato.

Lembrando que o cliclo de desenvolvimento MVC do Spring já é coberto por annotations.

- Spring AOP, para retirada de todo interesse ortogonal, uma das novas funcionalidades do Weblogic 10 foi a inclusão de AOP para instrumentação de excessões, só para citar um exemplo de utilização.

Cara, poderia falar de OSGI, outros projetos Spring como Batch, WebServices, Integration mas acho que já sacou o que eu queria passar, o EJB3 não vai descartar o uso do mesmo, à não ser pelas pessoas que só faziam uso mínimo da funcionalidade de IoC.

2- JPA e Hibernate - Bom , quem nasceu primeiro ? Nesse caso simples, hibernate, então ele não foge à especificação e sim a especificação que não implementa recursos interessantíssimos como Criteria, Projections, Statistics e por aí vai. Vai demorar muito à eu usar "JPA" como vem de caixa e falando em provider, qual é o seu provider JPA ? Hibernate ? Se for, porque não fazer uso intensamente ? Compliance ? Sinceramente as especificações até só deixando a desejar. Quem apostou em especificação Entitys BMP está com um grande problema, sem falar de outras tantas, como Portlets 168 e por aí vai ...

3 - Acegi ? - Amigo acho que você não tem a mínima noção do que acabou de dizer. ACEGI é um Sr. Framework, tirando que ele implementa a JSR 250 , dos EJBs , o mecanismo de votação (http://www.acegisecurity.org/guide/springsecurity.html#authorization) para provisionamento de permissões é fantástico. Acho que vale à pena ler a ocumentação e entender que ele não é somente um autenticadorzinho de plantão - http://www.acegisecurity.org/guide/springsecurity.html leia e depois comente algo.

4- Struts - Realmente esse pode morrer !! Ninguém vai sentir falta

Sem duvidas Kenobi !

1) Minha questão não é o que o Spring faz ou não faz... a questão é querer usar Spring para fazer o que EJB faz... e é nisso que estou comentando... mais um framework para fazer a mesma coisa ? Então usa o que já esta disponivel pelo container... Agora se você quer recursos exclusivos... otimo.. são outros 500... agora... enfiar mais um framework dentro da aplicação apenas para "fazer de outra forma a mesma coisa" eh que não acho vantagem...

2) Mais uma vez... o meu foco na discussao não é o que o hibernate faz ou não faz... a questão levantada foi "padronizar o desenvolvimento para que a curva de aprendizagem fosse menor" e nisso JPA ganha... todos da equipe trabalham sempre da mesma forma... e em 1%-10% dos casos fogem a regra

Quem veio antes ou não não vem ao caso, pelo menos não no ambito do inicio da discussao..

3) é um sr. framework, mas será que todas aplicações precisam realmente desse sr. framework... MAIS UMA VEZ... não venho aqui comentar se ele cozinha e faz café... e sim dentro de um desenvolvimento se o mesmo é realmente imprecindivel em todos projetos que fazem uso de autenticação enterprise... mais um framework... mais um aprendizado...

Kenobi... não estou aqui discutindo qual framework faz mais... apenas comentando que algo "all in one" em 80% dos casos é uma coisa boa... fazer sempre da mesma forma e de uma maneira em que o cara não precise se matar em 505 maneiras diferentes de fazer algo igula (ou muito proximo)...

Frameworks estão ai e tem seu valor... mais algo que sinto falta no java ( que existe a decadas em .net) é que eu não tenha que sair contratando "mini-gurus" de frameworks... que pelo menos eu consiga exigir algo padrao... quero ver no mercado voce achar facil facil quem junte esses 4 framewoks de maneira tranquila e "transparente" no desenvolvimento, é uma tarefa bem interessante...

Não adianta discutir funcionalidade... já disse... o negocio é "por que EJB3?" então ae está a resposta

Notícias, artigos e o maior fórum brasileiro sobre Java