Crítica escrachada ao Java

27 respostas
A

Segue abaixo uma crítica ao Java feita por uma colega meu de faculdade. Detalhe: Pra ele a única linguagem que presta é C/C++.

Enterprise JavaBean - uma profissão de fé
É visível a insatisfação que se generalizou neste semestre quanto ao “Java way” de se programar, graças à tomada do cenário por um elemento bastante digno de nota: o nosso agora conhecido e trabalhado à exaustão Enterprise JavaBean.

A idéia por trás do Enterprise JavaBean é bastante louvável. Ele se propõe a facilitar a vida do programador, oferecendo todo o suporte a uma infinidade de serviços, aliás, a maioria dos quais você não sabe pra quê serve, acabou de descobrir que existe e provavelmente nunca vai usar. E, de fato, a redução de código-fonte escrito é notável. É possível escrever uma aplicação com meia dúzia de métodos de quatro linhas cada, é claro, desde que você antes instale a máquina virtual Java, configure as variáveis de ambiente, instale um container de Enterprise JavaBeans tipo JBoss, configure-o, use uma ferramenta tipo Lomboz para gerar o esqueleto das interfaces e classes, use o XDoclet para documentá-las, faça um deployment da sua aplicação, empacote-a com alguma ferramenta, desempacote-a novamente para instalá-la no container e configure a aplicação para rodar de forma que as classes se comuniquem… Há quem acredite que isso veio para facilitar sua vida.

Pois muito bem. Após percorrida a via-crucis (ou seria via-JCrucis?) chega finalmente a hora de ver seu Enterprise JavaBean rodar! Bem, “ver” é um termo um tanto quanto forçoso, já que ninguém jamais conseguiu ver algo dessa natureza. Há lendas de que os EJBs realmente funcionam (talvez em Hoggwarts ou na Terra-Média?), mas essas lendas são de origem bastante duvidosa, sempre se sabe de alguém que “tem um amigo que uma vez viu numa revistinha”, nada nunca mais próximo do que um contato imediato de quinto grau. É daí que vem a nossa premissa, a de que para continuar a tentar usar um EJB, é preciso fé. Muita fé. Você precisa acreditar em algo que nunca viu, algo sem quaisquer provas concretas ou materiais que possam aparecer diante de seus olhos. Enfim, é preciso ter fé.

E foi vislumbrando um framework mais amigável e, principalmente, mais facilmente compreensível, que meu colega Renato e eu lançamos as bases de um futuro conjunto de interfaces que, se implementadas, iriam determinar a derrocada derradeira da confusa avalanche de interfaces em voga atualmente. Este framework seria composto simplesmente de duas interfaces: a interface Enterprise JPenis e a interface Enterprise JXoxota, ou simplesmente JXota (lê-se: jota-ksota). Dotadas de um encaixe perfeito, essas duas interfaces iriam sempre trabalhar em conjunto, tendo as seguintes assinaturas:

(private | public) interface JPenis extends QuandoAlisa { }
(private | public) interface JXota extends QuandoEnfia { }

Note que ambas são private na maior parte do tempo, se tornando public na exata hora de serem usadas.

Entretanto, elas não passam de um sonho distante e enevoado. Por hora, só podemos contar com as facilidades das nossas cerca de quatro bilhões de interfaces e classes diferentes. Cabe aqui um questionamento: por que continuar tendo que instalar oitenta programas e tendo que comprar dois pentes de memória de 512, só pra rodar um maldito programa numa tela preta na qual vai se ler “Hello world” e que, se não bastasse isso, nunca funciona? Porque facilita a nossa vida! E os Enterprise JavaBeans funcionam, sim! Tu é que não tens fé suficiente, ó herege!

Rodrigo César Dias,
Julho de 2004.

27 Respostas

P

Olá,

Primeiro de tudo, seu amigo escreve muito bem.

Depois, ele está criticando EJBs, não java em si, apesar de eu apostar que ele também não nutre muito gosto por qualquer cosia que envolva Java.

As pessoas têm od ireito de criticar o que quiser, e quando têm argumentos, a cosia é mais válida ainda.

EJBs realmente são complicados, mas isso porque eles não são usados onde deviam. Eu apsoto que de todas as pessoas que usam EJBs e frequentam este fórum, apenas 2% ou menos realmente um dia precisaram usar EJBs, o resto of ez por hype, imposição dos outros, acreditar cegamente na especificação de J2EE (acreditar no que dizem, não no que está escrito, aliás)…

Trabalho num lugar onde 90% dos programadores são C/C++ UNIX, e me dou muito bem com o pessoal. Piadinha de cá, piadinha de lá, a gente leva tudo na boa, e são pessoas muito competentes, mesmo um grande amigo meu que vive para me mostrar que Java é uma merda sabe que tudo tem o seu lugar.

Meu grande argumento nas discussões é: " O dia em que <coloque o nome da sua linguagem de baixo nível predileta aqui> tiver reflection, garbage collection ou serialização descente, você fala comigo!", mas isso geralemnte desencana em outras disucssões.

Eu sicneramente gostei muito do texto (ele está em algum lugar além daqui?) e acho que seu amigo está certo. EJBs são extremamente compelxos para fazer uma cosia simples (como citado), mas o ponto é que EJBs não deveriam ser usados para coisas simples.

EJBs deveriam viver em poucas aplicações onde escalabilidade absurda (i.e. =~300 nós em um cluster), transacionamento absurdo, quantidade absurda de clietnes Java diferentes (via RMI) e demais absurdos sejam verdades. Esse ambiente não é fácil de achar.

[]s

D

:lol: :lol: :lol: :lol: :lol:
hahahahahahhaha
essa critica escrachada é no minimo muito cômica,
Só rindo mesmo! a visão dele é bem de iniciante no java mas de um conhecimento bem aprofundando em outras!
Fazer o que né … cade um com seu C#

A

Aguarde o EJB 3.0 hehehe :lol:

Mas como o Phillip falou, EJB’s devem ser corretamente usados, em ambientes que realmente necessitam dessa arquitetura, por isso é muito importante a análise do projeto para verificar a viabilidade de utilizar EJB’s.

Eu partitularmente nunca utilizei EJB, e aki na empresa onde trabalho, não vejo nenhuma possibilidade de utiliza-lo, ao menos no médio prazo.

[]'s

F

qual curso que esse teu colega ta fazendo na tua faculdade? pelo visto eh portugues, pq ele realmente escreve muito bem, mas algo relacionado a computacao nao eh…

vc tem que esplicar pro teu amigo que Java nao eh EJB… o Java em si esta no J2SE, pra rodar um prog em java basta instalar o JRE, nao precisa configurar nada, eh soh baixar o arquivo de instalacao, dar dois clicks e ir apertando em “next” (isso ateh qm faz faculdade de portugues consegue fazer :grin: )

o EJB foi feito pra rodar em servidores, em aplicativos de missao critica… o objetivo do EJB nao eh ser facil de instalar/configurar, pois nao eh voltado para desktops…

S

Teu amigo mandou muito bem !!! Provavelmente ficou sabendo de Java através da onda EJB, que só serviu para entendermos como as coisas não devem ser feitas em Java.

Pede para ele dar um olhada em Hibernate, Spring e outras coisas mais legais do Java.

Eu teria trancado essa matéria e espero só ter que programar em EJB em troca de muito dinheiro.

EJB, na minha opinião, é um castigo pra quem gosta de programar!

R

:grin:

C++ tem isso? :?:

P

Não até onde eu sei.

Você pdoe até serializar algo, ams seus ponteiros vão pra casa do cacete. Garbage collection dá pra implementar, ams ai não dá nem rpa dizer que vc tá programando em c/c++ de tanta macumba…

J

Parabens para o bom texto do seu amigo e tambem para a boa resposta do Phillip. Nunca cheguei a programar EJBs, mas só de ler parte da spec e alguns artigos decidi que não precisaria usar, talvez algum dia, nos projetos atuais não. No fim das contas, a historia se resume a usar quando é necessario e não quando parece estranho o suficiente para contar aos colegas. Acho que pouquissima gente usaria um EJB para fazer um HelloWorld, se bem que se deve começar por algum lugar, mas exemplos assim não demonstram o verdadeiro proposito da tecnologia.

ps.: Quando disse para um amigo que ia dar um tempo em C++ para estudar Java ele respondeu de cara: “Pra que? Java é apenas um C++ facinho!”. Ele só não conseguiu explicar depois qual o problema nisso.

valeuz…

J

Oi

alex, seu amigo parece até saber um pouco de EJBs…

Mas bom, é óbvio que EJBs devem ser bem usados, mas, mesmo sendo mal usados, deve ser feito por quem saiba o que está fazendo e não por quem conhece a teoria…

Mas bom, essa conversa vai dar pano pra manga, eu só posso dizer uma coisa, pra quem achah dificil instalar uma IDE, fazer um deploy, etc, não tem jeito, só mesmo com o BesteirolStudio pro cara se enganar, pensando que programa… Ops, será ele acha que arrastar componentes é programar??? :lambededo: :lambededo: :lambededo:

T+

D

Legal o texto, EBJ é complicado mesmo, tem q valer a pena usar mas ele falou ali de 512mb de memoria achei logo q fosse o eclipse q acho q é mais pesado do q qualquer coisa q eu ja rodei aqui.
:lol: 8O

M

ta… ta… manda teu amigo fazer uma aplicação distribuída com interface web q seja independente de OS em C++… vai… vai coda comunicação de protocolos vai… me poupem com uma história dessas… :???:

A

ehehehe, eu sabia que esse tetxo ia fazer “sucesso” aqui no Fórum. :grin:
Bem, realmente eu me expressei mal, no texto o Rodrigo faz uma crítica aos EJB e não ao Java em si, mas ele também não é fã de Java não.
Respondendo a pergunta, o curso que nós fazemos é de Tecnólogo em desenvolvimento de software no CEFET/RN e ele antes cursava Eng. Civil.
Phillip, tem um cópia do texto em http://www.myjavaserver.com/~tds2002

Agora vou explicar um pouco a situação, nós pagamos uma cadeira em que o objetivo era aprender J2EE. Só que o professor não tinha experiência, ele estava aprendendo junto conosco (mas ele corria atrás para aprender) a parte prática, pois sacava da teoria. Assim, realmente até que alguém conseguisse fazer um Hello World com um session bean demorou bastante. Como o Rodrigo já não simpatiza com o Java ele aproveitou para baixar o cacete da forma dele.

A minha opnião é que realmente a especificação EJB é bastate complicada. Imagine só alguém desenvolver EJB sem um framework ou IDE. Acho impossível ficar atualizando aqueles descitores de implantação na mão sempre que houver uma mudança. Apesar disso, os EJB tem seus pontos fortes, como a abstração da camada de persistência. Infelizmente não é algo fácil e rápido de se aprender. Pelo que tenho lido a especificação 3.0 aponta para ser muito mais simples. A edição de Janeiro da Mundo Java tem um artigo que fala sobre. Vamos aguardar para ver se realmente vai facilitar a vida dos desenvolvedores.

S

Apenas uma opinião: Use Hibernate, JDO, ou faça o seu próprio mecanismos de persistencia, que alguns chamam de motor SQL. Entity Beans não são legais. Talvez sejam em EJB 3.0, mas eu não pagaria pra ver.

Eu não manjo muito de EJB na prática, mas acho que a única coisa útil ali é a clusterização/distribuição dos beans. Me corrijam se eu estiver errado…

E

Caros,

EJB é imprescindível em aplicações com um alto número acessos concorrentes onde a escalabilidade é crucial.

Eu trabalho com EJB ha dois anos em um cliente, onde a aplicação é acessada por milhares de usuários no decorrer do mês/dia. Nestes casos, EJB é OBRIGATÓRIO e não uma opção!

Já foi a época onde tínhamos que escrever trocentas classes e interfaces manualmente, hoje com XDoclets a vida ficou mais simples, mesmo para EJBs.

Entity Beans são interessantes para mapear a camada de persistência. Alguns cuidados devem ser tomados ao usar os finders - em alguns casos é melhor criar um DAO para ter mais performance, mas nem isso descarta o uso dos Entity beans.

É possível tb usar SessionBeans em conjunto com DAOs ou com outros frameworks de persistência. A vantagem ? Session beans utilizam o conceito de instance pooling dando mais performance para a aplicação, além de facilitar o controle transacional.

Quando usado adequadamente, EJB trazem um retorno muito bom.

Se a aplicação for acessada por um número pequeno de users, é melhor usar outro framework, pois EJb não trará tantos benefícios.

Falar mal é fácil. As pessoas deveriam enxergar e entender melhor as tecnologias (vantagens e desvantagens) antes de fazerem qualquer crítica. Cada tecnologia tem sua razão de existência e o cenário correto onde vale a pena ser usada.

Essa é a visão de um arquiteto de software.

abs,

Eduardo Murai
Sun certified enterprise architect

P

Olá,

Em sistemas com requisitos de escalabilidade monstruosa, onde hoje eu tenho um nó e amanha preciso de cinquenta, eu acharia EJB uma boa pedida.

99% dos sistemas altamente escaláveis que eu conheço não precisam de EJB. Trabalho com aplicações com milhões de acessos e não vejo obrigação nenhuma no uso de um framework X ou Y, a OBRIGAÇÃO é obedecer aos requisitos, não obedecer o hype.

Ficou menos complicado, mas mesmo assim a arquitetura ainda é extremamente acoplada ao AS utilizado.

Entity beans são tão ruins que são substituídos por uma opção POJO-based no EJB 3.0.

Você não precisa de um EJB para ter transações ou pools, mas sim, Session Beans são as coisas mais usáveis na especificação de EJB.

VB também :slight_smile:

Bom, já falei o que eu chamo de arquitetura itneressante para EJB.

Exato, a opinião do amigo em questão é baseada em muitos achismos, mas eu trabalho diariamente com a tecnologia e não discordo de muitas cosias no ponto dele.

Aliás, você deu uma olhada no EJB 3.0? A revolução que fizeram mostra que mesmo o JCP não acredita muito no EJB como estava.

“emurai”:

Essa é a visão de um arquiteto de software.

E esta de outro :slight_smile:

[]s

S

Realmente tenho muitos preconceitos em relação a EJB, logo minha opinião não é isenta, mas não deixa de ser a minha opinião.

Tenho um site com 5000 acessos simultâneos, 12 máquinas web em load balance, banco Oracle por trás, buscas simultâneas numa tabela de 5 milhões de linhas, etc e tal.

Enquanto puder, evitarei EJB, por ser uma tecnologia totalmente intrusiva, chata de implementar, toda amarrada em XMLs, pesada, etc e tal.

O que temos em EJB que não conseguimos ter sem ele ??? Isso é uma pergunta séria, e não uma afirmação irônica, logo quem tem mais experiência com EJB por favor dê a sua opinião.

Na minha cabeça é a APENAS clusterização/distribuição dos beans. Isso é legal e útil para um sistema que não pode parar de maneira nenhuma e não é muito fácil de se obter por fora de EJB.

Se eu falei besteira ou alguém não concorda, por favor dêem a sua opinião. Quero aprender tb !!!

E

Caro pcalcado,

Primeiramente, muita calma nessa hora!

Tá na cara que vc é contra EJBs, alias como todo mundo inicialmente fica, incluindo eu.

Não vou rebater item a item pq isto não é um “Ringue”, e apenas um forum mas algumas questões são interessantes.

pcalcado wrote:
[color=“blue”] 99% dos sistemas altamente escaláveis que eu conheço não precisam de EJB. Trabalho com aplicações com milhões de acessos e não vejo obrigação nenhuma no uso de um framework X ou Y, a OBRIGAÇÃO é obedecer aos requisitos, não obedecer o hype. [/color]

[color="#444444"]Frameworks não são obrigatórios mas com certeza trazem mais produtividade ao desenvolvimento pois é para isso que eles servem.

Como vc sabe que os seus “sistemas altamente escaláveis” não precisam de EJB ?
Talvez vc devesse reconsiderar essa opção, talvez com EJB eles rodassem de uma forma muito mais eficiente.

Se o tempo de resposta atual é suficiente para o cliente, ou seja, atendeu aos requisitos, blz… por ora o EJB não faz falta.
Mas e se daqui a algum tempo aumentarem muito o número de acessos ? Tudo isso deve ser analisado.[/color]

pcalcado wrote:
[color=“blue”]Ficou menos complicado, mas mesmo assim a arquitetura ainda é extremamente acoplada ao AS utilizado. [/color]

[color="#444444"]Realmente parte do codigo do EJB é especifico de cada app server. Além disso existem configs específicas de cada app server.
O objetivo disso é permitir que o Tunning seja feito no app server e não na aplicação.

Um ponto importante: a maioria do pessoal esquece de fazer o tunning dos EJbs no app server, referente ao controle transacional,locks, etc
que causam impacto na performance.[/color]

pcalcado wrote:
[color=“blue”]Exato, a opinião do amigo em questão é baseada em muitos achismos, mas eu trabalho diariamente com a tecnologia e não discordo de muitas cosias no ponto dele. [/color]

[color="#444444"]Vc vai me desculpar, mas sou developer além de ser arquiteto e trabalho com Java desde 1997 e J2EE desde 2000.
Tudo o que eu disse é baseado em EXPERIÊNCIAS reais em projetos e contabilizando o fato que eu tb já programei em outras linguagens como C e Pascal, entre outras.

Agora e vc ?Você já usou EJB em algum projeto para poder comparar ? E se sim, fez o tunning adequado ?

Se você não usa EJB, vc terá que se preocupar em implementar um monte de mecanismos que o container fornece como controle de transação, instance pooling, concorrência de threads, entre outros.

Se vc não precisa de nada disso, então EJB não é caso mesmo. [/color]

Não quero convencer ninguem que EJB é a melhor coisa do mundo, só quis citar algumas vantagens. Vai de cada um absorver isso como uma coisa positiva ou simplesmente continuar rejeitando o EJB. LIVRE ARBITRIO !

S

Controle da transação pode ser feito na grande maioria dos casos com JDBC mesmo. Nos casos mais complicados (1%), onde vc precise por exemplo de um two-phase commit, vc pode usar JTA.

Se vc estiver utilizando algum framework de persistencia como Hibernate, JDO ou o seu próprio (meu caso) haverá necessariamente um mecanismo para controlar transações, algo assim:

Transaction t = null;
try {
    t = Transaction.begin("seu pool aqui");
    t.save(profile);
    // faz um monte de coisa aqui.
    t.save(customer);
    t.commit();
} catch(Exception e) {
    t.rollback();
} finally {
    t.end();
}

Instance pooling é algo muito, mas muito fácil de implementar na mão, ou vc pode usar um dos milhões de produtos free que fazem isso muito bem.

Concorrência de threads será sempre complicado, usando EJB ou synchronizando o seu código na mão com synchronized/wait/notify.

O problema que eu imagino aqui, é que muitos gerentes/diretores de informática nunca programaram com Java, não tem experiência prática com a coisa. Não tem a mínima condição de chegar e falar: “Vamos usar isso por causa disso, disso, disso. Ou isso aqui será melhor devido a isso, isso e isso.” Isso é um problema gravíssimo causado pela velocidade absurda de evolução das coisas. Então o que um chefe desse fala !!!??? Não!!! Vamos usar EJB, ejb é o padrão da Sun para projetos distribuídos e altamente escaláveis, etc e tal. O cara não tem idéia da furada em que está se metendo.

Senhores diretores/gerentes que nunca programaram seriamente com Java/EJB. Fujam de EJB sempre que possível !!! Ou o seu projeto consumirá muito dinheiro, muitíssimo tempo, e no final corre o risco de fracassar, e aí lógico que é culpa do programador que fez a coisa. Não é porque EJB é um lixo, que Entity Beans é um lixo que nunca funcionou e vai ser mudado no EJB3.0, e não é porque o Application Server que custa 30 mil dólares está cheio de bugs e problemas, etc e tal.

M

so para fins de exemplo disso q o saoj falou… a minha empresa tem um cliente q comprou um Oracle AS e tem uns 200 entity deployados, sendo q 'e uma maquina s’o… eles nao tem nocao pra q serve… tem entity pra todo lado, cada um 'e uma tabela… tudo relacional… terrivel…

P

Olá,

Não me considero ‘nervoso’, só não concordo com você.

Inicialmente? Ora, eu posso te citar pessoas que, como eu, trabalham com J2EE (incluindo EJB) há muito tempo e continuam odiando.

Exato. É meio complicado você dizer que EJB não faz falta ‘por enquanto’ (assim como você presumir coisas sobre minha experiência com EJB, como fez no ‘inicialmente’), porque você não tem amenor noção do tipo de sistema que eu estou falando, nem do quanto ele vai/pode crescer.

Sim, e o aumento não indica necessidade de uso de EJB. Isso não é ortogonal.

Uma aplicação bem projetada vai poder se expandir sem muitos problemas, e eu conheço inúmeros casos de aplicações que usam boa parte das tecnologias e padrões ligados ao EJB e simplesmente não escalam.

Além do mais, um sistema deve se preocupar com sua realdiade atual. Se, como falei, seu projeto for bom, ele escalará, mas não posso ficar gastando tempo e esforço pensando em situações que talvez nunca ocorram, e não adianta dizer que EJB me tira esta preocupação, proque não é verdade, e ainda que fosse eu vou ter um sistema de um tamanho muito pequeno cheio de limitações impostas pelo modelo EJB que, novamente, talvez nunca sejam usadas.

E tornar sua aplicação praticamente parte do Application Server. Isso é bom?

Tuning é uma cosia. Eu quero uma aplicação utilizável em qualquer AS, e a partir dela fazer o tuning em cada AS que for fazer a isntalação. EJB me oferece isso? No way. Você pode até se ater as especificações apenas, mas vai ter algo muito limitado.

Um caso real sobre o tema é um sitema que dou manutenção onde tudo está fortemente otimizado…e acoplado ao JBoss 3.2.3. Nada funciona fora desta versão (nem mesmo na 3.2.4!).

Developer e Architect… distinções? Acho que você está falando de certificação então, porque na minha opnião um arquiteto que não programa não produz muita cosia útil, logo eu semrpe presumi que fosse fosse um programador, além de arquiteto.

Enfim você pergutna e não presume.

Bom, eu tenho atualmente 5 projetos com EJB. Em nenhum deles eu escolhia tecnologia utilizada e em 4 estamos fazendo refactoring para eliminar o EJB. A área é telecomunicações, o volume de transações diárias você pode imaginar pensando em quantas ligações coorporativas são realizadas numa operadora de tamanho nacional.

Sou digno de opinar? Se você precisar do meu curriculum para ter uma opinião, avise.

Acho que você se enganou aqui. J2EE é composto por um conuunto de especificações, um AS implementa estas especificações. EJB é uma delas, e nada impede que você use outras. Você nunca viu uma aplicação web usando JAAS, JTA e até mesmo JCA sem EJB? Pois é, existem.

No mais, um container lightweigth como o Spring te oferece os mesmos benefícios na maioria das vezes. Comof alei, em alguns casos odne existe uma necessidade muito real e específica, EJBs e toda a sua aprafernalha pdoe ser interessante.

“emurai”:

Não quero convencer ninguem que EJB é a melhor coisa do mundo, só quis citar algumas vantagens. Vai de cada um absorver isso como uma coisa positiva ou simplesmente continuar rejeitando o EJB. LIVRE ARBITRIO !

Não, você citou termos como OBRIGAÇÃO

“emurai”:

Nestes casos, EJB é OBRIGATÓRIO e não uma opção!

Mas eu entendo que é a sua visão, e não estou falando que você nãod eve usar EJB. Na verdade, eu estou até falando isso, mas vai de cada um ouvir ou não.

Não me leve a mal, isso é uma discussão técnica.

E

Olá,

pcalcado wrote:
[color=“blue”]Não, você citou termos como OBRIGAÇÃO [/color]

pcalcado wrote:
[color=“blue”]Acho que você se enganou aqui. J2EE é composto por um conuunto de especificações, um AS implementa estas especificações. EJB é uma delas, e nada impede que você use outras. Você nunca viu uma aplicação web usando JAAS, JTA e até mesmo JCA sem EJB? Pois é, existem. [/color]

Realmente OBRIGATÓRIO não foi uma palavra adequada, deveria ser RECOMENDADO.

EJB é uma OPÇÃO entre outros frameworks, queria deixar isto claro, .

pcalcado wrote:
[color=“blue”] Exato, a opinião do amigo em questão é baseada em muitos achismos, …[/color]

O fato de eu colocar a minha experiência e aquelas perguntas a seu respeito foi para rebater isto, que eu considerei uma falta de respeito.

pcalcado wrote:
[color=“blue”] Sou digno de opinar? Se você precisar do meu curriculum para ter uma opinião, avise. [/color]

Explicado anteriormente e caso tenha se ofendido, aqui ficam as minhas desculpas.

Vamos manter o foco na tech, repeitando a opinião dos outros e fazer deste um forum construtivo ao invés de ser destrutivo.

pcalcado wrote:
[color=“blue”]Tuning é uma cosia. Eu quero uma aplicação utilizável em qualquer AS, e a partir dela fazer o tuning em cada AS que for fazer a isntalação. EJB me oferece isso? No way. Você pode até se ater as especificações apenas, mas vai ter algo muito limitado. [/color]

Concordo com você que eles deveriam isolar MELHOR a parte especifica dentro do app server. Mas na prática, é dificil encontrar empresas com app servers diferentes, então na maior parte das vezes vc estará lidando com uma única “marca”. Mais de um app server pode implicar em pagar licensas extras, aumentando o custo.

Aqui onde trabalho eles tinham o app server ATG Dynamo e o JBOSS em outro departamento rodando aplicações distintas. Eles optaram por migrar todas as aplicações do ATG para o JBOSS para cortar o custo da licença anual que era absurda.

pcalcado wrote:
[color=“blue”] Sim, e o aumento não indica necessidade de uso de EJB. Isso não é ortogonal. [/color]

Isto não é regra, mas o EJB foi projetado para ter escalabilidade.

pcalcado wrote:
[color=“blue”] Uma aplicação bem projetada vai poder se expandir sem muitos problemas, e eu conheço inúmeros casos de aplicações que usam boa parte das tecnologias e padrões ligados ao EJB e simplesmente não escalam.

Além do mais, um sistema deve se preocupar com sua realdiade atual. Se, como falei, seu projeto for bom, ele escalará, mas não posso ficar gastando tempo e esforço pensando em situações que talvez nunca ocorram, e não adianta dizer que EJB me tira esta preocupação, proque não é verdade, e ainda que fosse eu vou ter um sistema de um tamanho muito pequeno cheio de limitações impostas pelo modelo EJB que, novamente, talvez nunca sejam usadas.
[/color]

Concordo que uma aplicação bem projetada pode se expandir sem muitos problemas, mas o EJB pode aumentar essa escalabilidade.

O fato de existirem algumas aplicações EJB que não escalam não implica em dizer que a tecnologia não funciona mas com certeza isso já põe um certo sentimento negativo sobre ela - como eu disse anteriormente, pode até ser um problema de tunning.

Na aplicação onde usamos EJB, o volume de acessos é enorme e o número de acessos aumenta de tempos em tempos (não conseguimos prever o qto), é transacional e tb usamos load-balance e fail-over. Para este cenário, temos tido um bom desempenho.

Isto é um exemplo de experiência POSITIVA do EJB.

P

Opa, mau-entendido detected:

“pcalcado”:

Exato, a opinião do amigo em questão é baseada em muitos achismos, mas eu trabalho diariamente com a tecnologia e não discordo de muitas cosias no ponto dele.

O “amigo em questão” é o que escreveu o texto que iniciou essa thread, se estivesse me referindo à você, citaria seu nome ou nick :wink:

[]s

S

Só não comentaram minhas perguntas… :cry: :cry: :cry:

E

Ola Saoj,

Alguns pontos em relacao aos seus comentarios:

1- Transação

Com EJB a transação pode ser demarcada manualmente (similar ao exemplo que vc deu) ou declarativamente como no exemplo abaixo (Xdoclet) para um metodo de um SessionBean local :

/**

  • @ejb.interface-method
  • @ejb.transaction type = “Required”
    */
    public void gravarDados()
    {
    // codigo de gravacao sem utilizar commit ou rollback
    }

Pode haver chamadas aninhadas entre metodos de EJB - para ele mesmo ou para outro EJB, e vc consegue especificar um atributo transacional diferente para cada método, caso precise, fornecendo uma granularidade fina. O EJB tb cuida da propagação do contexto transacional nesse exemplo “aninhado”.

Perceba que a opção de demarcação declarativa reduz o código necessário.

2- Instance Pooling

Esta config. fica no app server. vc não precisa escrever uma linha de código mas pode customizar o tamanho do pool e a estratégia do processo, por exemplo.

3- Concorrência de Threads

Este item realmente é complexo, como vc comentou.

O JBOSS fornece algumas pre-configurações interessantes de estratégias para lidar com isso.

Para os entity beans, por exemplo, o default é ter uma única instância de um entity para todas as transações. Isso gera um lock violento.

A boa nova é que existe uma pré-config que pode ser setada para os entity beans para usar uma instância por transação, diminuindo drasticamente o lock, se aplicável.

4- Gerentes de TI

Concordo com vc… as vezes as decisões não são nossas, sendo o gerente de TI o responsável.

As vezes tb o prazo do projeto é curto e não dá para arriscar com uma nova tech, como EJB…

Já convenci gerentes a usar uma determinada tech, mas sei que é complicado. Depende muito da flexibilidade do mesmo e das restrições/burocracias das empresas.

Bom, espero ter contribuído com algo.

abs,

Emurai

S

Contribuiu sim !!! Obrigado rapaz e quando eu tiver alguma dúvida de EJB eu já sei pra quem perguntar. :wink:

B

Meus Parabens , estava acompanhando a “discussão” e sem duvida foi um dos topícos mais alto nivel aqui do PJ .
Os 2 dominam bem o assunto …apenas tem pontos de vista diferentes … e felizmente esse é o barato da coisa !

D

Eu não sou um ávido utilizador de EJB e muito menos um amante da tecnologia. Eu também tenho muito preconceito quantos aos EJBs, mas numa aplicação que eu mesmo definí preferí escolher usar EJB (Session e MDB), pois me tiraria muito trabalho que já era fornecido pelo AS. Ganhei em tempo, além do que o XDoclet também facilitou.

Mas optei usar os meus DAOs a usar Entity Beans, o que acho complicado, chato e só ouço falar mal (por pessoas que realmente o usam).

Acho que EJB não chega a determinante ao sucesso ou falha, mas uma escolha a ser feita, levando em conta as características do projeto.

É isso aí.

Criado 2 de fevereiro de 2005
Ultima resposta 16 de fev. de 2005
Respostas 27
Participantes 14