:arrow: estudou EJBs 1.1 pelo livro do Monson-Haefel e achou que aquele troço complicado não ia dar certo.
:arrow: achou que o EJB 2.0 melhorou muito a possibilidade de aproveitar os serviços de transação, segurança e persistência do conteiner usando tudo local e ainda podendo usar MDBs, mas que mesmo assim ainda estava muito complicado.
Eu ainda vou depender de um “fornecedor” pra usar EJB, ou eu posso chegar num WebLogic da vida com uma implementacao nao-BEA e ainda assim ser feliz, do mesmo jeito que a gente faz com Hibernate hoje em dia?
CV, a comparação não é muito justa porque o Hibernate não tem suporte a transações e não pretende substituir completamente um container EJB. E assim como ocorre com o uso de SGBDs, se você escrever sua aplicação EJBtizada priorizando a portabilidade, é capaz dela apresentar mau desempenho em todos os servidores
PS: Melhor livro que conheço livro sobre transações, JTA, JTS, etc: Java Transaction Processing (estou lendo, por enquanto na página 60)
Na palestra da Oracle no 2o. dia do Sun Tech Days o sr. Peter Zadrozny referiu-se à burocracia necessária para o EJB 2.X funcionar como “meleca”. (Isso para promover o EJB 3.0, mas é claro que era para fazer alguma graça e acordar o público). É engraçado ouvir “meleca” pronunciada com tanta ênfase por um gringo…
De fato é preciso realmente precisar dos recursos transacionais do EJB 2.X para se atrever a usá-lo.
Hoje em dia eu ainda tou para conhecer quem trocou de fornecedor de Hibernate…
Eu acho que a spec ainda não tá clara quanto a isso, mas provavelmente não vai ser possivel escolher a implementação de EJB pro seu container. Oque vai ser possivel é fazer igual ao Hibernate e usar um container EJB3 para ORM.
Ate onde eu ví, a API do EJB3 não preve suporte a SPIs