EJB é uma EXCELENTE idéia, mas seu uso vai depender de n-fatores.

então, é melhor estudar bastante, antes de escolher usar os EJBs.

Aqui um artigo dizendo 101 razoes para nao utilizar ejbs:

http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf

Abraço,

Achar EJB excelente ou pessimo varia muito de pessoa para pessoa. Eu pessoalmente acho overhead demais para coisas de menos… Ele pode ate facilitar certas coisas, mas o custo disso eh caro demais para considerar o uso.

Mas eh aquela historia: nunca usei, e o pouco que conheco, nao gosto.

Rafael

Rafael, acho que você não entendeu o meu “Excelente Idéia”.

Deixa eu explicar. OS EJBs, por estarem dentro de um ApplicationServer que implementa RequestManagement, ResourceManagement, TransactionManagement, PersistenceManagement, SecutiryManagement, “Clustering”, FailOver, etc.

Diminui drásticamente a quantidade de esforço para se construir aplicações corporativas, distribuidas e vão garantir a escalabilidade dos serviços da aplicação, e ainda existem várias preocupações com performance, concorrência, segurança, e justamente por fazer parte de um MiddleWare, permite que múltiplos tipos de clientes acessem-nos.

Por isso, hoje em dia, o seu uso é muito indicado sim, em todos os tipos de projetos, desde WebMails, e-Commerce, EDI, BI, Billing, etc.

O que vai valer a pena estudar, são os tipos de EJBs que serão usados numa aplicação, e os tipos de associações deles.

Assim, um sistema que hoje roda com 10 usuários, da noite pro dia, sem alterar uma linha de código, pode-se escalar para 1000 usuários, somente substituindo o hardware.

E isso, é o que toda empresa procura quando se fala de sistemas corporativos, pois o uso da J2EE, garante a manutenção da taxa da ROI (Return of Investment).

[]´s

Bom estudo.

Sim, concordo com o ponto de vista da ideia/intencao ser boa, mas nao ha de negar que a forma que foi implementado ate agora nao eh das melhores. Como voce disse, facilita enormemente muitas coisas, escalabilidade/clustering eh “nativo” de EJB e todos os outros pontos que voce citou.

Se os EJBs melhorarem em muitas coisas, com certeza seria algo que todo mundo iria querer sair usando, mas parece que esta meio longe de chegar num ponto tao “bom” ainda.
Logicamente, se nao tivesse vantagem alguma, ninguem usaria, mas acompanhando as listas de discussao mundo afora e documentos pela net, fica claro que muita gente usa pelo simples fato de ser EJB ( e nao pelos beneficios em si ), ou seja, “modismo” puro, tem os que estao em um dilema de usar-nao usa, ha quem defenda e consegue fazer um otimo uso da tecnologia ( ou seja, alguem que usa EJB e conhece/sabe o que esta fazendo ), e ha os que odeiam.

Rafael

A especificacao 2.0 melhorou e muito os EJB’s , algumas pessoas que nao sabem como utilizar os EJB’s falam mal, porque desconhecem o proprio, procure utilizar todo os recursos da Plataforma J2EE e vera como ela é poderosa (EJB, Servlets e JSP’s ) e tb vera como os EJB’s sao uma mao na Roda

Meu amigo, eu uso, e indico pra todo mundo, pois é do CARALHO… facilita muita coisa… E quem ainda não usa, está gastando muito dinheiro para escrever coisas que já estão prontas e testadas.

[]´s

…e quem usa, mas não tem profissionais e ferramentas competentes, está gastando um dinheiro mais violento ainda com tecnologia que não vai ser tão escalável quanto promete… então, aqui vai, de novo, a máxima: People + Tools + Time + QA = Code.

Isso pode ser no seu mundo meu amigo, pois já participei e tenho notícias concretas de vários projetos de muito sucesso que usam EJBs, inclusive EntityBeans.

Hoje em dia, as ferramentas de desenvolvimento estão muito boas e com uma excelente qualidade (Eclipse, SunOneStudio, JBuilder, JDeveloper, WSAD, etc.) e agilizam muito o tempo de construção dos EJBs. E mesmo assim, o tempo ainda é menor usando os EJBs pela quantidade de serviços já prontos.

Quanto ao PeopleWare, vai variar de caso a caso. Na Procwork, temos uma excelente equipe (> 70% Certificada) que manda muito bem de J2EE.

E quanto ao QA, acho que indedepente da tecnologia, o esforço é o mesmo.

Então, só não usa EJB quem não sabe como usar.

OK, eu nao conheco nada de EJB, mas me fale sobre o maravilhoso overheade dele ( EJB QL, isso? ).
O EJB 1.0 soh vi falarem mal, e a desculpa pro 2.0 eh “ja esta melhor, esta melhorando” etc etc…

Ja li noticias onde dizia que a Sun admitia que EJB tinha sido muito mal planejado.

Rafael

Rafael… Não vamos mais discutir isso…

Estude mais sobre os EJBs, e verá que eles não foram mal planejados assim, é que as pessoas usam eles de forma errada.

Usando do jeito certo a J2EE é sucesso com certeza…

Assim…, sem querer entrar na Treta, a EJB-Ql eh convertida em sql padrao no deploy, entao amigo

“É preciso conhecer para falar mal”

No artigo que coloquei o link no comeco da Treta o autor sabe do que esta falando, e os pontos dele fazem sentido, e ele termina assim:
“Se arrumarem esses problemas, sai de baixo”

Agora se nao usar j2ee, vc vai usar o que?

1)fazer na mao
2)usar um framework de uns nerdzinhos por ai
3)apostar em um framework de peso, encabecado por gente grande.

O EJB tem problemas, claro que tem, mas se ninguem usa-lo jamais iremos encotra-los e corrigi-los.

E o interessante de Java eh que a cada versao as coisas vao se arrumando, as pessoas que definem esses frameworks sao extremamente acessiveis, diferente de um Microsft ou uma Oracle que te enfia tudo goela a baixo com a filosofia: “Aprenda se quiser, vai ser assim e pronto”

Eu fico irritado como algumas pessoas cobram a perfeicao de uma tecnologia tao nova e mesmo assim ja tao madura.

Abraco,

[obs]
nao me pronuncio mais nesse topico

Jakarta eh soh nerdezinho??

Rafael

Tem um monte de coisa legal na 2.1 e até melhoras na EJB QL (hehehe coitadinha tão criticada).

O suporte aos webservices será total, com as novas APIS(JAX-RPC e JAXM) , poderemos exportar os Stateless Session Beans e Message-Driven Beans como webservices baseados em SOAP, fazendo com que fique disponível para qualquer cliente compativel com SOAP.

Também teremos inovações nos Message-Driven Beans com suporte a J2EE Connector Architecture , os MDBs podem ser extendidos atravez de conectores para trabalhar com qualquer protocolo de mensagens e não só JMS.

Tambem será possível modelar um fluxo de mensagens com o destination linking.

A API Timer Service , que vai funcionar como um Cron do UNIX para agendar tarefas nos servidores EJB. Com essa API será possível escrever eventos-temporizados ligados a Beans para realizar tarefas com datas, períodos de tempo e intervalos específicos.

=== OBS ====
Eu tinha escrito isso em outro tópico e achei que entrava aqui.

EJB, como qualquer outra tecnologia, se usada indevidamente não trará bons resultados. Tem muita gente criando Session Bean a torta e a direita, acessando os Entity Bean remotamente e não utilizando as práticas aconselhadas.
E geralmente quem fala mal nunca trabalhou com EJB!

Lógico vc tem o direito de criticar o que quiser e usar o que bem entender, mais só pq eu prefiro o Struts, não vou sair falando que o WebWork é uma porcaria e pedir a “morte do WebWork” se eu nunca nem usei. É o mesmo com EJB, se precisp distribuir os objetos eu até posso fazer tudo com RMI direto, mais prefiro trabalhar com SessionBean, para trabalhar com um sistema de mensagens, posso trabalhar direto com JMS ou usar um Message-Driven Bean. E é lógico que se eu preferir a segunta opção é pq encontro vantagens nisso, porém outras pessoas podem e tem o diretito de não concordarem.

calmaaaaaa pessoal. cada um defenda seu topico, nao tem problema ALGUM em falar que um acha uma coisa uma droga, outro acha muito bom.

eu nao conheco EJB. nao posso falar anda. Mas ja fiz projetos bem rapidos, e nunca senti a necessidade. Mas poderei vir a sentir.

Alguns comentarios importantes:

O Oziel esta coberto de razao nesse ponto nao? Mas vamos lebrar que as pessoas usam de forma errada por causa do “hype” que existe em torno do ejb.

O Claudio tambem fala algo interessante aqui:

Voce fala mais exatamente de EJB neh? Porque servlets rules e ninguem fala o cotnrario.

Esta ai uma ideia interessante, se for uma empresa e tiver um produto e metodologia. Caso contrario, suicidio.

Poxa. Tem o Hibernate e OJB que fazm persistencia de banco de dados e tem uma LEGIAO de fas. Struts e WebWork nem se fala. E tem mais dois, que nao sei se todo mundo conhece: O AltRMI (versao apacheana do RMI) e o Entreprise Object Broker, baseado no OJB e AltRMI, para confrontar DIRETO o EJB. Apache tambem. Eu amo os nerdzinhos do apache/jakarta!

Jakarta!

Senti que todos acham que, se uma empresa utiliza EJB apra os projetos mais simples, vai acabar se queimando nao? Mas que em um projeto grande, que precisa ser muito bem componentizado, e especialmente distribuido, eh muito interessante, apesar de eu nao saber do que estou falando :).

Outra coisa, quando falei no topcio sobre java3, que queria morte ao EJB, foi CLARAMENTE uma brincadeira.

Mais uma vez, eu concordo que para sistemas distribuidos, escalabilidade, load-balance, controle de sessao, controle de crash etc etc EJB pode ser uma otima saida, pois sao coisas complexas de realizar “no braco”.

Para tudo ha uma solucao, mas fica claro que a maior parte quer EJB para tudo ou para nada. O ponto que eu mais nao concordo eh sair dizendo que EJB eh A solucao para algum problema. Ele poder ser para DETERMINADO problema, e esse problema geralmente sao os maiores, onde os fatores do primeiro paragrafo se aplicam.

Assim como o Paulo comentou, desejar a morte ao EJB eh brincaderia, modo de expressao. Eu ficaria super feliz se EJB perdesse as dezenas de problemas atuais, pois assim o Java ficaria ainda mais forte do que ja eh. Afinal, todos queremos Java.
Porem, mais uma vez, eu sou do time que defende a melhor solucao, seja ela qual for. Se provarem que EJB de fato eh melhor para o meu problema, otimo, usarei ele pois caso contrario eu estaria perdendo, mas se nao for, nao vou usar por simplesmente ser EJB.

Documentos e documentos pela net falam muito mal de EJB, outros milhares falem muito bem, cada um tem seu ponto de vista. Mas a maior parte nao sustenta o ponto de vista, querem 1) ou enviar goela abaixo; 2) ou chutar tudo.
Assim como comparacoes de Java x .NET somente levam em consideracoes “.NET tem isso, Java nao tem aquilo” ( e vice-versa ), a discussao em torno de EJB eh “EJB te permite escalar de maneira muito simples, permite recover de sessao se der crash, permite isso e aquilo…”, porem parece que o pessoal esquece de analisar um fator MUITO importante: “Preciso disso para o meu sistema? ganhar 1 mes no prazo por usar EJB vai compensar realmente?”

Eu defendo a melhor solucao, e nao me importaria de usar EJB de visse que ele poderia me ajudar.

Pagando bem, programo ate em .NET.

Rafael

ahhhh. pera la. xingar tudo bem. mas agora isso? morte ao rafael!!!
uhauhauhauh

Pois é, tá cheio de projetos tentando “reinventar melhor” a roda dos EJBs. O Hibernate, por exemplo, resolve muito bem a questão da persistência, aliás, e eu sou fã de carteirinha dele pra usar naqueles casos onde vai ter mais leitura do que escrita no DB. É rápido, e o desenvolvimento, aliado ao XDoclet, WebWork e Velocity, fica uma baba total. Sai mais rápido que muita gente programando em PHP por aí, até.

Agora, que empresa te deixaria começar um projeto usando essas ferramentas? O difícil, em muitos casos, é “vender” alternativas mais simples aos EJBs e JSPs. Tenho experimentado bastante isso tentando vender o peixe do WebWork em empresas que estão pensando em usar o Struts. Impressionante a trabalheira que dá convencer os caras, e olha que o Struts também é free, e também é considerado “alternativo”!

No fim das contas, o pessoal acaba usando a J2EE “bare metal” pq tem medo de bibliotecas e frameworks opensource…tsc tsc…

há algumas coisas que o dinheiro não compra, pro resto tem mastercard, não? :lol:

mas, falando sério… acompanhei meio de longe este tópico, mas, resumidamente (ou nem tanto), minha opinião sobre o mundo do EJB é esta:

1. a spec. é muito boa (há problema, claro, nada é perfeito, mas como disseram, os problemas vão se resolvendo à medida que vamos usando a tecnologia), resolve quase todos os problemas que as soluções corporativas normalmente têm (fail over, controle de concorrência, etc etc…); mas vale ressaltar: soluções corporativas; no “site do zé”, usar EJB é um exagero (podem dizer que o tal “site do zé” pode, do dia para a noite, virar uma sensação da internet e precisar escalar rapidamente; se isso ocorrer, então o erro não foi não ter usado EJB no início, mas foi não prever - ou seja, erro de análise pré-projeto - a possibilidade do “site do zé” de virar este imenso sucesso);
2. há muita gente que fica excitado em experimentar tecnologia; isso não é errado, muito pelo contrário; porém, uma coisa é experimentar, testar, aprender esta nova tecnologia, outra é aplicar isso num projeto real sem analisar aquela velha dupla “custo-benefício” e sair de cara considerando EJB como A SAÍDA. E, por mais que digam que não, isso é muito freqüente.
3. há os movidos pelo modismo do EJB, que acham que EJB é tudo. Para estes, vale lembrar que calça boca-de-sino não é mais moda desde a década de 70 :lol: .

Em suma, acho que “morte aos EJBs” (como eu já defendi) é um radicalismo. O ideal seria “morte ao modismo do EJB”.

e isso é tudo, p-pessoal… 8) [/quote]

abrindo um parênteses:

acho que algumas coisas como Velocity e o Webwork sào uns exageros. JSP+JSTL (ou, o JSP 2) geralmente dão conta do recado

Não me referi a ninguem falando do morte ao EJB especificamente, na realidade esse é o título do tópico.

Acho legal que se chegue a um entendimento que o mau uso de uma tecnologia, não faz dela uma tecnologia ruim, o ruim é quem não sabe usar.

Não existe tecnologia que seja a única alternativa para determinado problema, sempre tem uma outra maneira de se fazer as coisas.

Acho muito válido questionar sobre a qualidade disso ou da quilo, a utilidade etc. Não devemos ir aceitando tudo por modismo ou qualquer outro motivo. E o questionamento ajuda a resolver problemas e criar novas soluções e alternativas.

Também acho válido em muitas vezes “reiventar a roda” sim, pois se vc achar que determinadas soluções não são as melhores e vc pode fazer melhor, todos podem ganhar com isso. De outra maneira não teriamos projetos concorrentes na Jakarta por exemplo.

Quanto a Jakarta, cara eu adoro os projetos da Jakarta o pessoal é 10, e se a alternativa deles ao EJB for melhor, serei mais um a usar.

E Daniel Quirino, quanto ao receio de algumas empresas estarem usando projetos OpenSource, isso vem diminuindo, pois empresas como IBM, SUN, BORLAND entre outras estão apoiando e usando iniciativas OpenSource.
O que as empresas estão procurando hoje em dia é usar “padrão de mercado”, muitos dos projetos OpenSource de sucesso, são praticamente padrões de mercado ou estão se tornando. Por isso muitas vezes existe um receio de trocar um framework por outro.

Aham. JSF é praticamente uma fusão de JSTL + Struts.
Eu não tenho receio algum de usar qualquer framework OS nos meus projetos, desde que eles sejam perfeitos no quesito “faça tudo o que eu quero fazer de maneira mais fácil e produtiva”. Tanto é que alguns deles eu acho imprescindível, como Hibernate/TJDO, AspectJ (estou vendo o Aspectwerks, que o Carlos tanto adora), log4j. O que eu quis dizer com

acho que algumas coisas como Velocity e o Webwork sào uns exageros. JSP+JSTL (ou, o JSP 2) geralmente dão conta do recado

Voce disse TUDO aqui. Serio mesmo.
Eu tenho essa mesma ideia. Soh que muita gente mostra que a Microsoft sobrevive fazendo exatamente o cotnrario. Nunca tem 2 apis pra mesma coisa, nunca…

Pois é…será que dá pra contar nos dedos quantas APIs tem pra fazer uma toolbar? Ou quantas APIs diferentes dá pra usar pra desenhar dentro de uma janela?