CHAT - EJB ou não

com Glauco Reis

Glauco > Boa tarde
Guapo > Boa tarde a todos
Guapo > o Glauco já está no chat
Guapo > podemos iniciar as perguntas, trocas de idéias, etc...
Glauco > Claro, sem problemas
Guapo > Alguém tem uma primeira pergunta?
Guapo > bom, eu tenho algumas perguntas, então vou começar
Guapo > Glauco, você acha que a versão 3.0 os problemas de incompatibilidade vão continuar?
Glauco > Olá Guapo. Acredito que os mesmos problemas, de compaibilidade entre servidores irão continuar
Glauco > Não me parece que haja um concenso para fazer com que todos os servidores tenham descritores compatíveis entre si
Guapo > então parece que o problema está na especificação não ser mais específica?
Glauco > Eu acredito que os fabricantes não desejam fazer com que componentes EJB sejam totalmene interoperáveis
Glauco > Se isto acontecesse, poderia se trocar facilmente de servidores, e haveria uma guerra por preço
Glauco > Mas eu acredito que este é o desejo de todos que utilizam EJBs
Glauco > Que as informações de qual banco, coluna, transações,etc fossem padrão entre os vários servidores
Aprendiz > glauco vc acredita q EJB vai acabar com o surgimento de novas tecnologias?
Glauco > Aprendiz, é que novas tecnologias irão surgir. Isto já aconteceu. A própria Sun criou e está tentando sepultar o JDO, pois de alguma forma ele ofusca a tecnologia EJB
daltondecamargo > Glauco, você indicaria EJB 2.0 para o aprendizado de pessoa iniciando com a tecnologia Java, ou indicaria para os mesmos esperarem até que haja uma implementação do 3.0, que teoricamente será muito mais 'digestivo'?
Glauco > Olá Dalton, eu não acho que será tão mais fácil a codificação utilizando EJB 3.0
Glauco > Hoje, por exemplo, o programador que utiliza xDoclet têm que utilizar toda uma sequência de tags, que não é mais fácil do que criar duas interfaces e uma classe abstrata
Glauco > Para mim, a especificação 3.0 é um xDoclet padronizado pela Sun
Glauco > Acho por outro lado que ainda leva um longo tempo até as impementações EJB 3.0. Mesmo que o JBOSS a implemente, muitas empresas utilizam proutos comerciais como o Websphere e Oracle
Guapo > mas esses problemas que vemos acontecer quando se quer portar de um App server para outro
Guapo > tende a acontecer com todos os tipos de EJBs?
Glauco > Os EJBs mais críticos são os do tipo CMP
Glauco > Eu diria para uma empresa que deseja portar para vários servidores de aplicação, evitar este tipo de EJB
Glauco > Os de tipo Session são menos "danosos"
daltondecamargo > O Gavin em entrevista ao JF, declarou que a maior novidade da junção do Hibernate ao EJB3, será o suporte a filtros. No seu ponto de vista, como você enxerga essa união do Hibernate ao EJB3?
Glauco > Acho que dificilmente será uma padronização entre empresas como IBM ou Sun. Somente o JBOSS (que eu saiba) está indo para este caminho.
Glauco > Trocar o engine de persistencia do JBOSS para o hibernate acho muito bom. Hibernate é estável e padrão de mercado
Glauco > Mas não acho que a IBM irá fazê-lo, por exemplo
Glauco > Nós voltamos ao problema original, que é termos uma camada de negócios mais leve que EJBs, e que suporte todo o paradigma da OO
daltondecamargo > Existem tantos O/R's atualmente disponíveis no mercado, OJB, Hibernate, TopLink etc, você acha que a escolha pelo Hiberante foi uma boa? Porque?
ear > boa pergunta dalton
Glauco > Ele não é intrusivo. Eu sou totalmente contra a abordadem do JDO, que modifica o bytecode, por exemplo. Você já parou para pensar como será o mundo quando tivermos por exemplo um JDO e um AOP, ambos modificando o bytecode, sem termos acesso a ele ?
Glauco > Além disto, o hibernate chegou a um ponto onde muita gente utiliza e a massa de pessoas que ajudam a depurar a tecnologia é grande. Os outros players ainda não atingem um mercado tão grande.
Glauco > O TopLink, se não me engano é pago, certo ?
daltondecamargo > Certo.
daltondecamargo > Claro, mas você já reparou o quanto de adoradores o OJB tem por ex? Eu particularmente gosto muito do Hibernate, porém, é só ir no tss e postar algo declarando que Hiberante é o melhor o/r, que milhares de pessoas dessem a lenha em vc.
daltondecamargo > Eu acho que a entrada do Hibernate no grupo Jboss, ajudou um pouco.
daltondecamargo > A questão é, porque Hibernate e não castor? OJB etc, mas acho que a popularidade do hibernate fez a diferença.
Glauco > Os EJBs do tipo session são mais facilmente portados para vários servidores.
Glauco > Eu acredito que o fator popularidade faz com que a feramenta fique mais depurada
daltondecamargo > concordo.
Glauco > Devemos forçar os fabricantes a adotar uma abordagem multiplaforma, e não sermos obrigados a utilizar a ferramenta do fabricante para fazermos deploy para o servidor dele
Glauco > Aliás, se você olhar a premissa #1 da especificação, diz que um dia poderíamos utilizar qualquer ferramenta e fazermos deploy para qualquer servidor
Glauco > Eu não recomendo CMP, se a idéia é fazer um produto que irá vender no mercado.
daltondecamargo > Glauco, na sua opinião, Gerônimo ou JBoss?
Glauco > Eu ainda acho JBOSS, o gerônimo ainda está muito no início e deve passar pelo amadurecimento necessário, até chegar à maioridade
Glauco > Se você esquecer a personalidade do maioral do JBOSS, tudo fica mais fácil
Guapo > Acho que todos concordam que a idéia de EJBs é fenomenal. Acho que o que falta é acertar uns ponteiros. Estou certo?
Glauco > Sem dúvida nenhuma. Acho a tecnologia fantástica.
ear > O problema é quando esses ponteiros serão acertados. As vezes me sinto como se tivesse comprado promessas vazias em TI.
tetsuo > Glauco, a Sun tentou criar um 'mercado de componentes' com EJBs, agora está tentando mais uma vez com JSF.
tetsuo > A meu ver, nas especificações destas APIs sempre foi dado um grande peso à possibilidade dos fornecedores fazerem extensões proprietárias, opcionais ou obrigatórias, muitas vezes às custas de simplicidade e facilidade de uso.
tetsuo > O que você acha disso?
Glauco > Sem dúvida tetsuo. Os maiores problemas são as extensões proprietárias, que acabam por inviabilizar qualquer portagem
guest193223 > o EJB causa discussão desde seu lançamento ou só depois que novas tecnologisa foram introduzidas no mercado?
Glauco > Eu acho que a discussão vêm de uma longa data.
Glauco > Mais uma coisa que eu acabei não escrevendo no artigo
Glauco > Pegue a história dos EJBs. Mudou-se drásticamente da especificação 1.0 para 1.1 adotando arquivo XML ao invés de serializado
Glauco > Novamente, quando foi de 1.1 para 2.0, mudou-se de uma classe concreta para abstrata
Glauco > Agora, para a especificação 3.0, muda-se novamente, trocando a abordagem para anotações
Glauco > Olhe um empresário, que precisa optar por uma tecnologia. Como ele vai acreditar, se muda tudo a todo momento, e não apenas uma simples evolução?
guest193223 > Glauco, por essas e outras, acredito que quando uma tecnologia gera discordância na comunidade, e uma evolução não linear como você acabou de descrever, deveria ser repensada, ou até banida, o que você acha?
Glauco > Concordo. Veja a evolução dos Servlets, JSPs, JNDI, JDBC. Todas foram incrementais
Guapo > Mas eu acho que as coisas estão evoluindo...
Guapo > porém a complexidade de um arquitetura EJB
Guapo > é muito maior que as outras
Guapo > estamos falando de vários fatores
Guapo > persistência, disponibilidade, transações, escalabilidade... ufa
Glauco > A tecnologia Swing, por exemplo, têm um grau de complexidade talvez maior do que a tecnologia EJB, e nem por isto muda tão drasticamente
daltondecamargo > Quando você diz "Eu não recomendo CMP, se a idéia ..", você não concorda que criar toda persistência manualmente é extramamente braçal? Como você encararia o hibernate neste ponto para poder amenizar o trabalho do desenvolvedor?
Glauco > Criar manualmente é realmente complicado. Diversos engines leves têm surgido, e tendem a gradualmente tomar o lugar dos EJBs
Glauco > Isto é uma outra questão. Quem aguenta pagar U$40000,00 por um servidor, para utilizar apenas a camada Web. Não está na hora de o cliente comprar apenas pelo que ele utiliza ?
daltondecamargo > Aí quem sabe entraria o spring :)
Glauco > Acho que o Spring, e outros containers leves, vai forçar uma queda no preço dos servidores
guest193223 > Guapo, você que trabalhou em grandes empresas pode afirmar, então, que vale a pena as corporações continuarem investindo em EJB, aguardando por melhorias?
Guapo > eu acho que sim, mas diversos cuidados tem que ser tomados. Acho que dá pra usar bastante coisa boa dos EJBs
Glauco > Utilizar Session, BMP, MDB são menos danosos e com poucas particlaridades por servidor
guest193223 > isso é muito interessante....
daltondecamargo > Certo, agora me responda. Uma empresa com 10 programadores, com clientes de médio porte, onde nenhum destes programadores tem conhecimentos avançados de EJB. A aplicação é web e terá no máximo 100 usuários simultânos. Vale a pena a curva do aprendizado..
daltondecamargo > desta equipe para implementar o sistema usando ejb? Ou quem sabe, aprender a usar um spring da vida e implementar usando-o?
Glauco > Olha só pessoal. Peguem a quantidade de empresas que geram sistemas WEb. Destas empresas, vejam quais utilizam EJBs. Não há algo errado com os números ? Todo mundo usa a camada WEB Java, mas nem todo mundo utiliza a camada de persistência J2EE
Glauco > Concordo, Dalton. Muitos sistemas não rodam de forma distribuida, e se utilizam EJBs com a expectativa de um dia serem escalados. Muitos nunca o são...
Glauco > Hoje em dia, conhecer EJB é também um fator para o programador conseguir salários melhores
daltondecamargo > Perfeito Glauco, vou sair agora, muito obrigado pelas respostas, e pelos belos artigos que tem nos proporcionado na MJ! Abraço a todos!
Glauco > Obrigado Dalton !!!
Glauco > Mais alguma pergunta ?
Guapo > Glauco, mais alguma consideração?
tetsuo > em um artigo anterior seu, você abordou os padrões do livro Core J2EE Patterns
tetsuo > Você não acha que aqueles padrões eram mais 'remendos' pra deficiências de EJBs do que qualquer coisa?
tetsuo > Na segunda edição do livro, são introduzidos alguns padrões interessantes, como o ApplicationService
Glauco > Completamente. Para mim, a maioria dos patterns EJB são remendos para deficiências da tecnologia.
tetsuo > Mas na primeira edição, a maioria servia para 'diminuir os problemas causados pela latência da rede', por exemplo
tetsuo > Isso é um problema de arquiteturas distribuídas, mas não são todos os casos que necessitam desse tipo de arquitetura, não é?
Glauco > Mas aqui, cabe a seguinte consideração :
Glauco > Os problemas de latência da rede foram grandemente diminuidos com as interfaces locais. O maior problema delas, é que não são transparentes.
Glauco > Muito poucas empresas rodam sistemas escalados e distribuidos.
Glauco > E eu posso também dizer que, aquelas que decidem ir fundo no WLM, acabam encontrando algum problema no servidor. Estas partes são muito pouco depuradas, porque acredito que são pouco utilizadas
tetsuo > E pela minha (não tão grande) experiência, quando há balanceamento de carga, este ocorre na camada web, não a EJB
Glauco > Usar EJB, para um sistema de apenas uma JVM, é o mesmo que vender geladeiras no polo norte.
Glauco > Também é verdade, tetsuo. É mais fácil e existem mais recursos para fazer WLM na camada WEB
Guapo > Bom pessoal, se ninguém tiver mais perguntas ...
Guapo > Eu gostaria então de agradecer a presença de todo e do Glauco!!
Guapo > Na quinta feira tem chat sobre JMS
Guapo > Glauco alguma consideração final?
Glauco > Agradeço novamente a participação de todos.
Glauco > Precisamos nos unir, pois o concorrente vende que tudo é fácil.
Guapo > Mas sabemos que não é bem assim, e diria que o concorrente vai descobrir várias coisas que Java já descobriu
Glauco > Até a próxima, pessoal !!!
Guapo > Então, oficialmente o chat está encerrado, quem quiser continuar por aqui fique a vontade!!
Guapo > Abraço a todos!! E novamente obrigado por participarem!!
Glauco > Obrigado...