EJB 3: Dead Or Alive?

Acho que a nossa porcentagem de usuários EJB2 é violentamente maior!

Pois é,

Também estou na turma do EJB2

Fabio Nascimento

EJB2++

Eu estou com o EJB3 mas de vez em quando me deparo com alguns projetos em EJB2, fazer o que…

pode multiplicar o valor de uso de ejb2 pela quantidade de componentes que tenho aqui? porque se puder…multiplique por 832.

ejb2 * 832

EJB3++

EJB2

acho que aqui está na metade da média de lá.
meu caso EJB3, mas estou me envolvendo em um projeto pesquisa meu e não profissional no momento.

interessante pesquisa!

Eu uso EJB 3.

Eu também uso EJB 3.

Acho que ainda é cedo p/ avaliar.
Tem muito legado de projetos com EJB2 . Essa tecnologia pegou uma epoca de boom do java, e nos ainda não sabiamos direito com o que estavamos lidando. Por isso aqui no Brasil acho que ainda existem mais projetos com EJB2.
O numero de projetos com EJB3 vai crescer, mas vai demorar um pouco ainda.
Principalmente pelo trauma causado pela verao anterior.

[]´s

EJB 2++…

Aproveitando, alguém já fez a migração do 2.X para o 3???

Estou querendo alavancar esse projeto…

Abraço

Eu sai a pouco de um projeto de grande porte com EJB3 e
atualmente estou iniciando outro projeto tb com EJB3.

EJB3+=2;

Acho que a resposta para a questão é “Alive”.

felipeguerra:

EJB 2++…

Aproveitando, alguém já fez a migração do 2.X para o 3???

Estou querendo alavancar esse projeto…

Abraço

[]'s

EJB 3

pelo bem dos deuses EJB 3

Graças ao bom deus eu nao uso EJB.

EJB is dead for me

EJB3. Softwares em produção, “comerciais”.

EJB3. Softwares em produção, “comerciais” ++

Where do you live man?

EJB3…

Frentic:

Graças ao bom deus eu nao uso EJB.

EJB is dead for me :)

Uma pena você encarar EJB3 com a mesma raiva que encara as outras versões…
vai descobrir que uma porrada de frameworks que vc usa poderia estar deixando de lado se adotasse a versão 3.0…

All in one

Se ele usasse EJB ele também poderia continuar perdendo um tempão esperando o Glassfish subir todos os EJBs

Rubem Azenha:

chun:

Uma pena você encarar EJB3 com a mesma raiva que encara as outras versões…
vai descobrir que uma porrada de frameworks que vc usa poderia estar deixando de lado se adotasse a versão 3.0…

All in one

Se ele usasse EJB ele também poderia continuar perdendo um tempão esperando o Glassfish subir todos os EJBs :P

e o tempo de carga de um EJB ( que sinceramente eh bem rapido , aqui eh ms…) é fator para trocar all in one por um milhao de frameworks adicionais ? com 300 configuracoes a toa ? me desculpe… mas desculpinha mais boba hein ?

Tá, quantos frameworks você jogou no lixo por usar EJB3?

Não é jogar no lixo , é abstratir por interfaces padrão de trabalho…

Vamos começar a enumerar…

1. Spring
2. Hibernate
3. ACEGI
4. Struts

Acho que isso já dá uma boa curva de aprendizado…

Fora os beneficios que o container tem como JMS, Controle de transacoes unificado , load balance , entre outros

Para uma equipe grande isso é MUITO legal… todos trabalharem da mesma forma sem “piracoes a parte”

Vamos lá:

Desde quando EJB substitui Struts?

E quanto ao Hiberante, usa JPA, que é basicamente um clone do Hibernate, a complexidade é a mesma.

Quanto ao ACEGI eu até entendo que é um framework a menos, mas o que eu mais vejo é o pessoal fazendo a segurança na camada web. Não acho que o ACEGI requer tanta configuração assim, é quase como configurar junto com o Spring mesmo.

“Controle de transacoes unificado” -> O Spring tem isso tão simples quanto EJB.

“load balance” -> Com EJB você tem load-balance da camada de negócios mas na imensa maioria dos casos basta fazer um load balance da camada web. Acho que fazer load balance da camada de negócios é essencial em alguns casos, como processamentos assincronos pesados, batches, etc. Fazer load balance da camada de negócio para coisas simples como uma página de busca simples não vale a pena ao meu ver.

Rubem Azenha:

Vamos lá:

Desde quando EJB substitui Struts?

E quanto ao Hiberante, usa JPA, que é basicamente um clone do Hibernate, a complexidade é a mesma.

Quanto ao ACEGI eu até entendo que é um framework a menos, mas o que eu mais vejo é o pessoal fazendo a segurança na camada web. Não acho que o ACEGI requer tanta configuração assim, é quase como configurar junto com o Spring mesmo.

“Controle de transacoes unificado” -> O Spring tem isso tão simples quanto EJB.

“load balance” -> Com EJB você tem load-balance da camada de negócios mas na imensa maioria dos casos basta fazer um load balance da camada web. Acho que fazer load balance da camada de negócios é essencial em alguns casos, como processamentos assincronos pesados, batches, etc. Fazer load balance da camada de negócio para coisas simples como uma página de busca simples não vale a pena ao meu ver.

Vamos lá por topico… EJB dentro de java EE substitui o strus com JSF…

Ninguem usa EJB sem se benificiar do Java EE… seria besteira…

JPA asbtrai hibernate… nao importa o que uso para persistencia… importa aprender JPA… menos uns 415 frameworks ORM… quem trabalha com JPA trabalha com qualquer ORM que o implemente… ( e isso quer dizer muita coisa )

512312314 XMl’s ? Por favor… EJB eh um @transaction no metodo… ou no bean… admita… pegar um IDE que suporte isso é bem mais facil que sair corrende procurando plugins atualizados…

Quanto ao load balance , voce falou falou e falou… em EJB isso é transparente … tanto na web quanto na camada de negocios… convido voce a testar o clustering support do Glassfish. Valer a pena depende de “quantos clicks” voce demora para balancear sua regra de negocio… quando se trata de mensagens assincronas isso é bastante util…

Opa, pera lá. A discussão é sobre EJB e não sobre Java EE. (EJB 3: Dead or Alive? e não Java EE puro e simples dead or alive).
E, sinceramente, muita gente (eu incluso) vai preferir não usar JSF.

Aprender JPA = Aprender Hibernate. Quem conhece um mínimo de Hibernate sabe que JPA é uma cópia de um subset do Hibernate. As APIs são muito parecidas. Logo a complexidade é a mesma.
E não me venha com essa de que basta aprender JPA que você trabalha com qualquer ORM, basta ver que existem diferenças significativas entre as implementações de JPA.

No Spring também

Cara, que que load balance na web tem haver com EJB? Load balance pra web é transparente com Spring.
Sinceramente, cluster, load-balance, fail-on-over, escalabilidade, etc são coisas tão sérias e complexas que a coisa que eu menos me preocupo é quantos cliques eu vou demorar para balancear a minha regra de negócio.

Concordo que no quesito de processamento assincrono EJB é imbatível. JMS+MDB rules

Respondendo:

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.

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 ?

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

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.

Vou entrar nesta discussão tb.

Rubem Azenha:

chun:

Vamos lá por topico… EJB dentro de java EE substitui o strus com JSF…

Ninguem usa EJB sem se benificiar do Java EE… seria besteira…

Opa, pera lá. A discussão é sobre EJB e não sobre Java EE. (EJB 3: Dead or Alive? e não Java EE puro e simples dead or alive).
E, sinceramente, muita gente (eu incluso) vai preferir não usar JSF.

concordo com chun, apesar de ter se desviado um pouco do foco de EJB3.

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

Vamos focar em EJB e esquecer o resto.

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

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.

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

chun:

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

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.

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

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…

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!

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

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:

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:

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

Eu uso EJB 3 e to achando bom, bem facim

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á…

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 8)

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

chun:

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

Chun, acho que esta é uma visão estreita. Se você olhar para o cenário Enterprise HighEnd e não Mind-ranges, vai encontrar muito mais necessidades que imaginas. Quando começar a trabalhar com containers de processamento Mainframew como Tuxedo, precisar escalar soluções à 50k minuto entre outras, algumas coisas serão necessárias.

A arquitetura com Spring pode prover flexibilidade, para injetar um sistema de grid como GigaSpaces ou o Hibernate pode ser utilizado junto com o Coherence.

Particularmente preifro ter “opções” e alternativas ao mundo fechado .net. Aliás vai ver muita solução até mesmo de hardware, para contonar deficiências de desenvolvimento, como o parser de XML da IBM por exemplo.

Não estou excluindo o uso de EJB3, pelo contrário, gosto da tecnologia, entretanto os outros frameworks que estão aí também possuem o seu valor, isso que eu quis dizer e o mundo não gira exatamente igual em todas as companhias.

Neste exato momento estou num projeto SOA que possui uma arquitetura muito atípica e necessidades de integração distintas, mas isso é outro tópico.

Kenobi, continuando:

1. Certo… como você mesmo acabou de falar… “visão estreita” eu diria que é mais “pequenas/medias aplicações”… vejo muito nego por ae socando de frameworks tornando projetos simples em verdadeiras torres de babel… e é para estes casos que digo o que disse… e não para casos extremos.

2. Sim spring possibilita tudo isso… mas quem realmente que esta usando Spring que “sabe” OU pior… utiliza realmente isso ? Posso contar nos dedos… é que nem um povo a um tempo que criticava o MySQL por nao ter stored procedures e nem integridade referencial faziam em suas tabelas no Pg… meu ponto é “Use quando realmente for necessario” e não ficar enchendo de bagulhada para tornar o desenvolvimento na plataforma java um mundo de DOR… é para isso que tem um arquiteto… para dizer o que usar e não deixar isso simples e puramente na mão de quem programa…
   As vezes a decisão deve visar um conjunto total e não apenas um.

3. Eu ADORO ter opções (http://www.go-java.com/blog/2008/08/01/1217590877657.html) e este não é o caso , o caso é produção e renovação… e nisso ter milhares de frameworks é como ter milhares de componentes no velho delphi… um inferno para gerenciar a equipe…

4. Quanto a existirem outros framewoks que possuem o seu valor… eu já afirmei nas minhas outras mensagens… eu apenas tento matar uma girafa usando um rifle e não uma bazuca… deixo a bazuca para bombardear os EUA… hehe

5. Em seu projeto atipico , necessita de abordagens atipicas… então bora usar todo o potencial… voce acabou de chegar no ponto… ATIPICO… e os tipicos… voce teria a mesma abordagem ?

chun:

Kenobi, continuando:

1. Certo… como você mesmo acabou de falar… “visão estreita” eu diria que é mais “pequenas/medias aplicações”… vejo muito nego por ae socando de frameworks tornando projetos simples em verdadeiras torres de babel… e é para estes casos que digo o que disse… e não para casos extremos.

2. Sim spring possibilita tudo isso… mas quem realmente que esta usando Spring que “sabe” OU pior… utiliza realmente isso ? Posso contar nos dedos… é que nem um povo a um tempo que criticava o MySQL por nao ter stored procedures e nem integridade referencial faziam em suas tabelas no Pg… meu ponto é “Use quando realmente for necessario” e não ficar enchendo de bagulhada para tornar o desenvolvimento na plataforma java um mundo de DOR… é para isso que tem um arquiteto… para dizer o que usar e não deixar isso simples e puramente na mão de quem programa…
   As vezes a decisão deve visar um conjunto total e não apenas um.

3. Eu ADORO ter opções (http://www.go-java.com/blog/2008/08/01/1217590877657.html) e este não é o caso , o caso é produção e renovação… e nisso ter milhares de frameworks é como ter milhares de componentes no velho delphi… um inferno para gerenciar a equipe…

4. Quanto a existirem outros framewoks que possuem o seu valor… eu já afirmei nas minhas outras mensagens… eu apenas tento matar uma girafa usando um rifle e não uma bazuca… deixo a bazuca para bombardear os EUA… hehe

5. Em seu projeto atipico , necessita de abordagens atipicas… então bora usar todo o potencial… voce acabou de chegar no ponto… ATIPICO… e os tipicos… voce teria a mesma abordagem ?
   

Bom na minha ótica você generalizou o uso do Spring. Não sei se está baseado em alguma pesquisa ou apenas vivência no cenário que atua. Particularmente enxergo muito mais no framework citado e se fosse utilizá-lo seria como citei. Talvez “as pessoas” como você mencinou o conhecem superficialmente, particularmente acho esse o mal de muitos que se dizem “Arquitetos” na nossa área. O cara conhece meia dúzia de tecnologias e fala que conhece arquitetura de software…complicado.

Quanto ao “comum”, pode se estabelecer um modelo como a proposta WebBeans - Seam, acho válida.

Olá

Este tópico virou uma discussão entre EJB3 e Spring.

Acho que o foco inicial era ver quantos ainda usam os EJB 2.x, que na minha opinião foram a maior tolice já inventada na área de TI. Ou ver quem já usa os EJB 3.x que quase não tem nada a ver com os EJB 2.x.

Acredito que ainda existam muitas aplicações usando a porcaria dos EJB 2.x. Sorte dos que podem trabalhar com EJB 3.x que são muito mais interessantes. Os que sofrem com EJB 2.x se consolam porque talvez possam ganhar mais ou trabalhar mais horas para obter o mesmo resultado.

O Spring, exceto o Spring-MVC, tem enorme valor. Quem teve a sapiência de usá-lo ao invés dos EJB 2.x, talvez hoje se arrependa porque perdeu a galinha dos ovos de ouro na manutenção ou redesenvolvimento dos sistemas feitos com eles.

Acho mesmo com EJB 3.x, o Spring ainda tem muita coisa boa e não acredito na história de quem usa Spring não usa JEE. O mesmo raciocínio para quem usa Hibernate ou JPA.

Porque a gente não volta a discutir EJB 2.x versus EJB 3.x?

[]s
Luca

Luca:

Olá

Este tópico virou uma discussão entre EJB3 e Spring.

Acho que o foco inicial era ver quantos ainda usam os EJB 2.x, que na minha opinião foram a maior tolice já inventada na área de TI. Ou ver quem já usa os EJB 3.x que quase não tem nada a ver com os EJB 2.x.

Acredito que ainda existam muitas aplicações usando a porcaria dos EJB 2.x. Sorte dos que podem trabalhar com EJB 3.x que são muito mais interessantes. Os que sofrem com EJB 2.x se consolam porque talvez possam ganhar mais ou trabalhar mais horas para obter o mesmo resultado.

O Spring, exceto o Spring-MVC, tem enorme valor. Quem teve a sapiência de usá-lo ao invés dos EJB 2.x, talvez hoje se arrependa porque perdeu a galinha dos ovos de ouro na manutenção ou redesenvolvimento dos sistemas feitos com eles.

Acho mesmo com EJB 3.x, o Spring ainda tem muita coisa boa e não acredito na história de quem usa Spring não usa JEE. O mesmo raciocínio para quem usa Hibernate ou JPA.

Porque a gente não volta a discutir EJB 2.x versus EJB 3.x?

[]s
Luca

Legal, particularmente já coloquei meu ponto de vista sobre o EJB, começo da idéia e alternativas à época com o Corba. Ele teve falhas como os Entitys e são bastante condenados por isso. Mas se olhar SessionBeans, MDB´s, JTA - Controle transacional, são pontos à favor.

Kenobi:

WebBeans seria uma boa resposta a tudo isso junto… em 80% dos casos de aplicações pequenas/medias…

Eu não generalizo o uso do Spring, muito pelo contrário, reconheco o tamanho deste framework… mas não é por isso que vou colocar ele em tudo quanto é buraco… é só isso…

Quanto as pessoas que mencionei conhecer, será que elas conhecem superficialmente ou só conhecem essa resposta ? tanto que só enchergao a “solução spring” em tudo quanto é lado… mesmo que isso seja condenar todo um densenvolvimento a bilhares de XML’s como era antigamente ( quanto as annotations eu uso o spring annotations faz um bom tempo… e nao me preocupava muito com os XML’s do spring )

E finalizo por aqui essa discussão que admito já perdeu o foco

Luca:

Olá

leandrokjava:

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

Bom acredito que sim, de acordo com este este topico http://www.guj.com.br/posts/list/3804.java é oque parece.

mas em nenhum momento falei que Não gosto de Struts só prefiro JSF.

e um viva para Craig McClanahan’s. \o/

Não gosto muito de bater em cachorro morto não …

EJB3 Alive, EJB2.x Dead

Creio que ainda há muitos projetos que usam EJB2.x.
Mas se a idéia for migrar de um pra outro dá pra matar uns 80% só de código inútil :shock:, só aproveitando as regras mesmo.
Na minha opinião navegar em código feito com EJB2.x é um trabalho muito chato, portanto EJB3 Alive (pelo menos em projetos onde é necessário).

Infelizmente ainda tenho que usar EJB2 em muitos projetos legados… mas tenho usado sempre EJB3 quando temos a oportunidade de definir a arquitetura da aplicação.

Luca, Kenobi, chun e demais!

Estou precisando de uma ajuda e creio que vcs podem me ajudar.
Gostaria de informações (benchmark) de cases onde o EJB 3 foi utilizado e esteja atualmente em produção. Trata-se uma pesquisa para corroborar junto à gerência a probabilidade de sucesso da implementação da tecnologia.
Os mesmos se propõem (se for possível) entrar em contato com as empresas que tenham esses cases de sucesso.

Obrigado!

Creio que exista maior utilização de EJB2x, pois o há um considerável custo ($$) para migrar e aderir ao EJB3. Os projetos mais recentes estão aderindo melhor a versão 3.x.

Já usei EJB 3, mas acabei de voltar para o 2.1

Vc voltou por que não gostou ou por que foi obrigado?

[]'s

Tava trabalhando em uma empresa que fez migração do 2.1 para o 3 e agora estou numa empresa que usa 2.1.

Mas pelo menos o pessoal demonstrou um interesse numa migração.