Arquivo Discussoes de Programacao e Tecnologia 
Quando eu estava iniciando em Java eu nem sabia o que era EJB mas sempre a frase nas vagas “ejb - com experiencia” mas eu, um simples mortal não ganhei experiência em ejb no útero e gostaria de saber o pq da complicação de iniciar em uma empresa que tenha EJB
Todos tem que vir do berço com experiência em ejb 2.1 pq hj o ejb 3 esta fraco no mercado
Não concordo que EJB3 esteja fraco no mercado.
Talvez vc tenha pego os anuncios num dia onde estejam contratando mais gente pra lidar com legado do que novos desenvolvimentos.
Ao menos até onde sei, não há ninguém começando projetos com EJB 2.1 (ao menos ninguém que conheça java, talvez um ‘gerente’ sem conhecimento técnico algum)
Quanto ao ponto da experiência isso é normal, quem entra pra aprender é Trainee, o resto tem que chegar sabendo (sim, sou recrutador tb)
Abs
Provavelmente é aplicação antiga, ninguém é louco de iniciar hoje algo com EJB 2.1, sem contar que a maioria que usaram EJB 2, utilizou totalmente equivocado, acabaram por ter que implementar vários padrões e acrescentar complexidade para consertar o fato do mal uso do EJB, usavam num contexto que não era apropriado.
O EJB 3 não é uma evolução do EJB 2, pra quem conhece, sabe que EJB 3 é um novo produto que apenas herdou o nome do anterior. Hoje não vejo muito sentido de usar EJB 3 se não for local. Atualmente num projeto distribuído temos trabalho com excelência utilizando o Spring.
[]'s Hewerton Crisóstomo
Acredito quando se trata de uma vaga para um novo desenvolvimento em EJB, a necessidade de alguém com experiência seja fundamental, mas quando se trata de alguma manutenção não, alguém com experiência de uns 3 anos em java resolve, talvez pedir conhecimento teórico já basta
Eu pelo menos nunca ví um tramplo de verdade aqui em SP que esteja utilizando EJB3. Mesmo!
Agora, EJB2 eu já ví a rodo e já trabalhei em sistemas assim.
Acredito que existam empresas utilizando EJB3, apesar de desconhecer hehe.
Tu utiliza no teu trampo?! Se sim, como está sendo a experiência?
nos trabalhamos com ejb 3.0 aqui, eu nao uso para fazer chamadas remotas ou coisa do tipo, mas sim para controle de transacao, webservices e etc.
Chamadas remotas mesmo, acho que tem 2 pessoas que utilizam em algum lado mto obscuro do sistema ehehheheh
abrasssss
Provavelmente é aplicação antiga, ninguém é louco de iniciar hoje algo com EJB 2.1, sem contar que a maioria que usaram EJB 2, utilizou totalmente equivocado, acabaram por ter que implementar vários padrões e acrescentar complexidade para consertar o fato do mal uso do EJB, usavam num contexto que não era apropriado.O EJB 3 não é uma evolução do EJB 2, pra quem conhece, sabe que EJB 3 é um novo produto que apenas herdou o nome do anterior. Hoje não vejo muito sentido de usar EJB 3 se não for local. Atualmente num projeto distribuído temos trabalho com excelência utilizando o Spring.
[]'s Hewerton Crisóstomo
Depende,
Ano passado começamos um novo projeto aqui e tivemos que utilizar o EJB 2.1 porque o WebSphere (versao 6.1) nao suportava EJB 3 ainda.
Trabalhei em um projeto ate abril deste ano que usa EJB3 e não tive do que reclamar.
Realmente, hoje ainda vejo diversos projetos que utilizam EJB2 e que não pretendem migrar para EJB3 tão cedo.
Provavelmente é aplicação antiga, ninguém é louco de iniciar hoje algo com EJB 2.1, sem contar que a maioria que usaram EJB 2, utilizou totalmente equivocado, acabaram por ter que implementar vários padrões e acrescentar complexidade para consertar o fato do mal uso do EJB, usavam num contexto que não era apropriado.O EJB 3 não é uma evolução do EJB 2, pra quem conhece, sabe que EJB 3 é um novo produto que apenas herdou o nome do anterior. Hoje não vejo muito sentido de usar EJB 3 se não for local. Atualmente num projeto distribuído temos trabalho com excelência utilizando o Spring.
[]'s Hewerton Crisóstomo
Depende,
Ano passado começamos um novo projeto aqui e tivemos que utilizar o EJB 2.1 porque o WebSphere (versao 6.1) nao suportava EJB 3 ainda.
Funciona EJB 3 no Websphere sim senhor. Procure pelos Feature Packs desta versão, que elas habilitam o websphere para o uso desta versão de EJB
Provavelmente é aplicação antiga, ninguém é louco de iniciar hoje algo com EJB 2.1, sem contar que a maioria que usaram EJB 2, utilizou totalmente equivocado, acabaram por ter que implementar vários padrões e acrescentar complexidade para consertar o fato do mal uso do EJB, usavam num contexto que não era apropriado.O EJB 3 não é uma evolução do EJB 2, pra quem conhece, sabe que EJB 3 é um novo produto que apenas herdou o nome do anterior. Hoje não vejo muito sentido de usar EJB 3 se não for local. Atualmente num projeto distribuído temos trabalho com excelência utilizando o Spring.
[]'s Hewerton Crisóstomo
Depende,
Ano passado começamos um novo projeto aqui e tivemos que utilizar o EJB 2.1 porque o WebSphere (versao 6.1) nao suportava EJB 3 ainda.
Entre usar EJB 2.1 e não usar nada e fazer tudo na unha eu fico com a segunda opção. NÃO EXISTE NEM NUNCA EXISTIU RAZÃO NENHUMA PARA SE USAR EJB 2.1. Os imbecis que inventaram o EJB 1.0 ao 2.1 deveriam ser fuzilados pelo grande dano que causaram a plataforma java.
Sem falar que com tantos servidores bons (e open source) por aí, foram pegar logo o Websphere que é fechado, caro e ruim?
Entre usar EJB 2.1 e não usar nada e fazer tudo na unha eu fico com a segunda opção. NÃO EXISTE NEM NUNCA EXISTIU RAZÃO NENHUMA PARA SE USAR EJB 2.1. Os imbecis que inventaram o EJB 1.0 ao 2.1 deveriam ser fuzilados pelo grande dano que causaram a plataforma java.
Por que tu diz isso? Quer dizer que razão pra EJB 3 existe e não pra EJB 2?
Eu vj uma que continua em Java, desde junho cada vez maior… apinfo no dia 01/09/2009, mandei 3 e no dia 02 mandei 2 curriculos e a um ano em dias fracos eu mandava 8, 9 cv.
Nos retornos sempre é algo sobre manutenção e desenvolvimento, acho que por esse motivo o 2.1
Entre usar EJB 2.1 e não usar nada e fazer tudo na unha eu fico com a segunda opção. NÃO EXISTE NEM NUNCA EXISTIU RAZÃO NENHUMA PARA SE USAR EJB 2.1. Os imbecis que inventaram o EJB 1.0 ao 2.1 deveriam ser fuzilados pelo grande dano que causaram a plataforma java.
Por que tu diz isso? Quer dizer que razão pra EJB 3 existe e não pra EJB 2?
O EJB 3 é algo significativamente diferente do EJB 2. O uso de JPA em lugar de CMP e BMP é ótimo, afinal de contas CMP não serve para nada mesmo (é preferível fazer DAOs na mão, ou seja BMP) e BMP é um dinossauro perto do JPA. Mas mesmo assim, o EJB 3 também tem algumas coisas meio sem sentido.
Na minha opinião, regras de negócio bem codificadas não precisam utilizar dados armazenados em atributos de SLSB ou MDBs que tornam-se inválidos após o fim da invocação dos métodos pertinentes. Tais atributos ao meu ver só deveriam ser usados para DI, o resto deveria estar em passagem de parâmetros ou em outros tipos de classes comuns que não sabem nada sobre EJB. Retirando o caso específico da DI, se você não precisa utilizar os atributos de um objeto, então este objeto não precisa ser mantido em um pool de instâncias e nem ter um ciclo de vida maluco. A injeção de dependências poderia ser feita de outra forma, uma destas formas é que todos os atributos fossem do tipo ThreadLocal ao invés do tipo XXX, então você sempre precisaria só de uma única instância de cada classe daquilo que hoje são SLSBs e MDBs. Seria algo um tanto semelhante aos Servlets (o container os trata como se fossem singletons), e pelo que andei vendo por aí, o singleton session bean do EJB 3.1 vai ser algo mais ou menos parecido com isso. Aliás, o Spring prova que DI poderia ser feito em qualquer classe, logo não há muito sentido em se criar um tipo de classe de ouro em um pedestal e chamá-la de stateless session bean só para isso (talvez para chamadas remotas até faça sentido, mas acho que isso também poderia ser trabalhado de outra forma).
Quanto a anotações de transações e interceptors, estes seriam bem melhores se pudessem ser usados em qualquer classe e não apenas em EJBs. O Spring tá aí para provar que isso é possível. Basta que o classloader altere o bytecode carregado instrumentando ele de acordo com o que há nas annotations. Aliás, DI é implementado desta forma.
Quanto ao SFSB, confesso que este pode ser bem útil, inclusive no EJB 2.1, apesar de que no EJB 2.1 o preço a pagar era bem doloroso.
Bem, esta é a minha opinião, e sei que muita gente não concorda com ela. Talvez eu esteja errado, mas é essa a visão que eu tenho.
Provavelmente é aplicação antiga, ninguém é louco de iniciar hoje algo com EJB 2.1, sem contar que a maioria que usaram EJB 2, utilizou totalmente equivocado, acabaram por ter que implementar vários padrões e acrescentar complexidade para consertar o fato do mal uso do EJB, usavam num contexto que não era apropriado.O EJB 3 não é uma evolução do EJB 2, pra quem conhece, sabe que EJB 3 é um novo produto que apenas herdou o nome do anterior. Hoje não vejo muito sentido de usar EJB 3 se não for local. Atualmente num projeto distribuído temos trabalho com excelência utilizando o Spring.
[]'s Hewerton Crisóstomo
Depende,
Ano passado começamos um novo projeto aqui e tivemos que utilizar o EJB 2.1 porque o WebSphere (versao 6.1) nao suportava EJB 3 ainda.
Funciona EJB 3 no Websphere sim senhor. Procure pelos Feature Packs desta versão, que elas habilitam o websphere para o uso desta versão de EJB
Calma cara, ta nervoso? Eu disse “nao suportava”. Com todos esses “Feature Packs” que voce diz funciona mas com o WAS puro creio que não, mas no ano passado tinha vários papos em corredores aqui entre funcionarios mais antigos que tinham a “lenda” de que nao funcionava, e por isso usaram EJB 2.1
So dei um exemplo de pq alguem usaria (mesmo errado eeheh) EJB 2 ainda.
Quanto ao outro post, em fazer tudo na unha, nao concordo muito nao… masss…cada um com sua opinião.
E quem acha que vai só trabalhar com EJB 3 daqui pra frente se engana… é muito dificil uma empresa migrar pra de EJB2 pra EJB3 por uma serie de razoes…
é uma merda EJB 2? é… mas fazer o que…
Já trabalhei em vários projetos legados com EJB 2.1 e apenas um projeto do zero com EJB3.
Posso dizer que no projeto de EJB3 foi complicação demais apenas pela premissa de que “futuramente a aplicação pode ser distribuída”. Tudo que foi feito com EJB3 no projeto poderia ter sido resolvido de outras maneiras (alguem falou Spring?) e a injeção de dependências dele é patética.
Eu sinceramente não vejo um caso em que valha a pena usar EJB3, mesmo sendo muito superior ao EJB 2.1. Distribuir os objetos da aplicação é uma fábula que fez muita gente gastar muito dinheiro na mão de vendors de EJB.
ejb3 é tão fácil que a gente tem q se perguntar muito por que não usá-lo (principalmente pra quem usa seam). No meu caso foi por causa do application server. prefiro continuar usando só jpa pq desenvolver só com tomcat é muito mais rápido.
Porque sua aplicação precisa escalar e/ou não dispõe (nem quer dispor) de um servidor de aplicação.
Não manjo quase nada de EJB, mas vejam meu caso, quero desenvolver uma app onde toda a regra de negocios fique em um unico lugar e entao eu quero ter clientes Web e Desktop, quais seriam as soluções? Pelo que vi EJB serve pra isto correto?
A solução é separar a lógica de negócios da apresentação. Você não precisa de framework nenhum pra fazer isso.
eu criaria uma camada de negócio, jogaria tudo que é de negócio nessa camada…
Sim e onde ficaria esta camada?? Apenas mais um JAR? Tanto na lib da app web, como na lib da app desktop? Humm não sei se era isto que eu estava querendo.
E neste caso eu teria que ir atualizando cada cliente, caso mude alguma regra de negocio que nao afete a visão!!!??
Afinal qual o proposito geral do EJB? Não é fazer aplicações distribuidas?
Eu esta imaginando nos clientes fazerem chamadas remotas as regras de negocios que estao no EJB.
Pois terei tanto cliente dentro de uma LAN, como tambem vendedores de rua, tanto web quanto desktop, e quem sabe ate com smartphones/palm’s.
Sim e onde ficaria esta camada?? Apenas mais um JAR? Tanto na lib da app web, como na lib da app desktop? Humm não sei se era isto que eu estava querendo.
E neste caso eu teria que ir atualizando cada cliente, caso mude alguma regra de negocio que nao afete a visão!!!??Afinal qual o proposito geral do EJB? Não é fazer aplicações distribuidas?
Eu esta imaginando nos clientes fazerem chamadas remotas as regras de negocios que estao no EJB.
Pois terei tanto cliente dentro de uma LAN, como tambem vendedores de rua, tanto web quanto desktop, e quem sabe ate com smartphones/palm’s.
que tal usar http? Qualquer faz chamadas via http em 3 linhas de código.
Sim e onde ficaria esta camada?? Apenas mais um JAR? Tanto na lib da app web, como na lib da app desktop? Humm não sei se era isto que eu estava querendo.
E neste caso eu teria que ir atualizando cada cliente, caso mude alguma regra de negocio que nao afete a visão!!!??Afinal qual o proposito geral do EJB? Não é fazer aplicações distribuidas?
Eu esta imaginando nos clientes fazerem chamadas remotas as regras de negocios que estao no EJB.
Pois terei tanto cliente dentro de uma LAN, como tambem vendedores de rua, tanto web quanto desktop, e quem sabe ate com smartphones/palm’s.
Posso listar aqui um mooonte de soluções melhores do que EJB pro seu caso.
Tome muito cuidado antes de tomar uma decisão dessas. Muita gente na década passada tomou a decisão de utilizar EJB e se arrependeu amargamente. Hoje em dia é menos traumático, devido ao EJB3 ser melhor que o EJB 2.1, mas ainda assim adiciona muita complexidade desnecessária, além do fato de ser necessário utilizar um servidor de aplicações.
Eu vejo muito trauma do pessoal com relação a EJB, não são os traumas do 2.1 não?
EJB 3, nao me parece esse monstro do lago ness não! Posso estar enganado mas essa foi a primeira visão que tive do mesmo!
Sim e onde ficaria esta camada?? Apenas mais um JAR? Tanto na lib da app web, como na lib da app desktop? Humm não sei se era isto que eu estava querendo.
E neste caso eu teria que ir atualizando cada cliente, caso mude alguma regra de negocio que nao afete a visão!!!??Afinal qual o proposito geral do EJB? Não é fazer aplicações distribuidas?
Eu esta imaginando nos clientes fazerem chamadas remotas as regras de negocios que estao no EJB.
Pois terei tanto cliente dentro de uma LAN, como tambem vendedores de rua, tanto web quanto desktop, e quem sabe ate com smartphones/palm’s.
Vc pode disponibilizar os serviços utilizando o spring debaixo de web server de sua preferencia, assim vc terá tanto acesso via TPC como HTTP sem problemas.
Eu vejo muito trauma do pessoal com relação a EJB, não são os traumas do 2.1 não?EJB 3, nao me parece esse monstro do lago ness não! Posso estar enganado mas essa foi a primeira visão que tive do mesmo!
Eu acho que vc está certo…o problema é que quando vc pensa sobre o que vc realmente precisa vc conclui que existe soluções bem mais leves, simples e potencialmente bem mais rápidsa (desenvolvimento e uso de recursos).
Outro ponto que também percebo é que muita gente aplica EJB 3 sem concluir se os recursos disponibilizados pela tecnologia serão realmente utilizados.
Se a idéia for apenas oferecer oportunidade diferenciada de acesso (TPC, HTTP), ORM e transações acredito que o projeto fique um pouco superdimencionado, porque EJBs é bem mais que isso.
flws
Eu vejo muito trauma do pessoal com relação a EJB, não são os traumas do 2.1 não?EJB 3, nao me parece esse monstro do lago ness não! Posso estar enganado mas essa foi a primeira visão que tive do mesmo!
Algumas melhorias ocorreram mas o monstro continua la, debaixo de muitas camadas de água.
De uma olhada no VRapor 3, eles parecem tem um suporte legal pra web, http.
hahahah…boa essa heim!!!
flws
Eu vou começar a fazer um ERPzinho, posso chamar assim quem sabe vire um ERPzao, vou começar pela automação comercial com NF-e, SPED, PDV, e vou adicionando modulos, produção, crm e etc., o que da pra ter visao em Web blz, o que nao ficar viavel vai pra Swing, e ainda temos os mobiles.
Então vejam que podemos ter varios tipos de clientes, Web, Desktop J2SE, e os mobiles J2ME.
WebServices seriam uma opção, mas ws pros clientes da lan??? Nao sei!
Entao temos um core de negocios, e varios tipos de clientes acessando o mesmo. Na minha visao essa era justamente um caso para EJB, pelo que conheco.
Mas pra nao fugir muito do tópico vamos la, uma pergunta que sempre fazem, qual o proposito do EJB afinal de contas?? Para quais casos ele é indicado? E quais ferramentas/features ele oferece para tal?
Se a galera poder dar uma contribuida legal com essas questoes, por que com elas respondidas sim, poderiamos entao realmente dizer que estamos querendo matar formiga com AK-47, ou que EJB é muito complexo para tal.
fred, a ideia basica do EJB eh distribuir seus objetos.
por exemplo, imagine que sua aplicacao fornece tres beans diferentes (A, B e C). voce percebe que as requisicoes para o bean A sao muito mais numerosas que pros beans B e C e resolve, ao inves de fazer um cluster para otimizar sua aplicacao como um todo, distribuir seus objetos e colocar o bean A em um servidor separado dos beans B e C. acontece que esta solucao ao meu ver (e de fontes importantes na comunidade OO, como Martin Fowler) nao vale a pena. no caso, seria melhor colocar sua aplicacao em cluster.
para simplesmente deixar sua logica de negocios separada das outras camadas voce tem opcoes bem mais leves que EJB, como ja citamos. o EJB provem outras coisas como injecao de dependencia (bem primaria), transacoes, etc, mas para isto existem opcoes mais simples e completas, como o Spring (que nao precisa rodar num servidor de aplicacoes).
recomendo estudar melhor EJB antes de optar utilizar em qualquer aplicacao que seja.
ja trabalhei em projetos SAP/Netweaver que envolviam EJB2 e EJB3, é verdade que para essa plataforma tem mta coisa em EJB2, os caras da sap ja tao trampando no java frankstein deles para migrar para ejb3…mas basicamente mta, mas mta coisa msm que envolve logica de negocios para vc fazer uma app java/netweaver envolve EJB…
graças a deus que me livrei de sap…e no momento estou começando um projeto ejb3…e como falaram ai, é mto facil usar ejb3, não vejo motivo para deixar de usar ou de reclamar dele…a não ser claro por questões de performance em alguns casos…
mas no geral, acredito que ejb3 esta sendo bem usado por ai e os principais motivos sao a facilidade de aprendizado e sua robustez…
mas é claro…isso é só minha opinião… 
abraços
E cada vez complica mais :lol:
Vem um e diz pra fugir igual diabo da cruz, ja outros dizem que “não tem porque nao usar, EJB3 é muito easy” :?: :?:
É vou ter que dar uma estuda mais a fundo no bixo.
Sobre o que alguns disseram de “vai ter que ter um app server”, acho que nao é problema, pois de qualquer forma vai ter que ter por causa da parte web.
Salvo engano o ERP compiere que é desktop usa EJB!
E cada vez complica mais :lol:Vem um e diz pra fugir igual diabo da cruz, ja outros dizem que “não tem porque nao usar, EJB3 é muito easy” :?: :?:
É vou ter que dar uma estuda mais a fundo no bixo.
Sobre o que alguns disseram de “vai ter que ter um app server”, acho que nao é problema, pois de qualquer forma vai ter que ter por causa da parte web.
Salvo engano o ERP compiere que é desktop usa EJB!
sim o compiere e o adempiere usam ejb dentro do jboss…la empresa que eu trampava…eu implantei esse erp pra eles…demorava um pouquinho pra subir a app…mas depois funcionava de buenas…
como relação ao que falamos ai…a melhor maneira e vc fazer um teste…instala um glassfish na sua maquina, brinca com uns ejbs e depois vc ja vai ter uma opiniao sobre eles…
E cada vez complica mais :lol:Vem um e diz pra fugir igual diabo da cruz, ja outros dizem que “não tem porque nao usar, EJB3 é muito easy” :?: :?:
É vou ter que dar uma estuda mais a fundo no bixo.
Sobre o que alguns disseram de “vai ter que ter um app server”, acho que nao é problema, pois de qualquer forma vai ter que ter por causa da parte web.
Salvo engano o ERP compiere que é desktop usa EJB!
Sobre o servidor, na verdade voce nao precisa de um app server pra parte web. Se nao utilizar EJB vc pode usar Tomcat, Jetty, etc. Se for utilizar vai precisar de um servidor que possua um container EJB (glassfish, weblogic, jboss, etc).
App Server não é feito pra rodar aplicações web.
Sim, sim, container que seja. Falo isto porque sempre usei o Glassfish pra tudo, entao quer seja somente web ou com EJB junto, vai ser o glassfish mesmo.
É acho que é o melhor jeito de conhecer e mensurar o bixo, vou fazer isto.