Sem querer ser chato, mas já sendo, você já trabalhou com um sistema realmente distribuído com EJB? Foi feliz com isso?
Se você foi, precisa, urgentemente dar uma olhada na API de remoting do Spring e ver como se faz uma camada de chamadas remotas realmente separada de todo o resto.
Pois é, nestes casos admito que são ótimos e vale a pena pagar seu preço (*). Mas todo mundo sabe de casos que em se usou EJBs apenas para aprender ou para justificar a compra de um Websphere da vida e que o sistema ficou pesado demais desnecessariamente. A imagem do Java vai lá para baixo. Um dia, há uns 2 anos atrás em um almoço de negócios, um diretor de uma empresa grande deu risada na minha cara dizendo que Java não prestava porque uma empresa que ele conhecia tinha gasto mais de 20 milhões com Java, Websphere, máquinas IBM, etc. e tal e depois de um ano não tinha resultado nenhum.
(*) Digo por ouvir dizer porque nunca passei por isto
Isto tenho lido e ouvido por aí. E também que Java precisa se livrar de vez dos EJBs. Tem gente simpática ao EJB 3.0 só porque cortou muita coisa de ruim. Eu ainda estou cético e depois que li que a especificação do EJB 3.0 tem 700 páginas fiquei horrorizado. Se isto for verdade acho que trocar Spring + POJOs + algo que pode ser mentawai por qualquer coisa que contenha em sua formulação química a sigla EJB, continuará sendo matar pombo com bazuka (antes era com canhão).
[]s
Luca[/quote]
não fale assimm … EJB tem seu uso em ambientes distribuídos.[/quote]
Jini tem uso em ambientes de objetos realmente distribuídos (distribuídos de verdade, não este paradigma estúpido “distribuídos-mas-centralizado-no-appserver” dos EJBs) com uma simplicidade e performance bem satisfatórias. Web services são mais efetivos para ambientes distribuídos pois são independentes de tecnologia do ponto de vista de quem os consome. EJBs nem tanto. Normalmente (70% dos projetos em que eu já participei), ninguém usa EJB remotamente porque a performance cai drasticamente (http://jboss.org/jbossBlog/blog/acoliver/2006/03/21/If_you_dont_do_this_JBoss_will_run_really_slowly.txt) e fazer tuning em AS para conseguir recuperar o prejuízo não é algo tão simples e bem documentado como fazer tuning em um banco de dados (pelo menos dizem por aí que é bem documentado).
Então, nem para ambientes distribuídos EJBs são a melhor escolha. Não estou querendo dizer que EJBs de nada valem, mas eles não costumam ser a melhor alternativa para a maioria dos projetos que os utiliza.
Mas, bla bla bla à parte, e voltando ao novo tópico desta semana sobre o debate “Java vs. Ruby”, concordo quando dizem que Ruby talvez não vá vingar como Java vingou, mas Ruby ajudou a dizer ao javaneses que o “Rei Java está nu”, mostrando quão complexo está se tornando nosso ambiente para resolver problemas simples. E acho que esta é a lição mais importante que a comunidade Java deveria tirar destes debates.
hibernate complicado? po pessoal… hibernate com criteria e anotacoes do JPA é mais facil que o active record… sem contar q vc pode controlar um BOLO de coisas… soh se quiser
luca… nao entendo o pessoal que fala do Spring. o manual do Spring deve ser umas TRES vezes maior que a spec de EJB3. Sem contar que o Spring hoje em dia eh um framework-faz-tudo… enquanto ta todo mundo no “less is more” o Spring vai enfiando mais e mais “suporte” a apis
é RIDICULo quando o Spring vfala que tem suporte a api de email e o que ele faz é simpelsmente injetar um bean idiota que encapsula o mail…
Session beans ainda são uma porcaria, mas os entities, que são o “Hibernate com MUITO MENOS configuração” não tem nem comparação. Não dá pra dizer que é “tão simples quanto” o ActiveRecord, mas que já a coisa já melhorou muito, melhorou sim.[/quote]
porque uma porcaria? nao tem mais home, voce nao precisa implementar metodos de lifecycle se nao quiser, é um POJO e encapsula uma logica de negocios…
EJB3 vai estourar se BEA e IBM nao demoraram 3 anos para seguirem a spec e atualizarem os servers…
Só se o Hibernate mudou muito, pois o quick-start dele não era nem um pouco quick. Por isso que até hoje eu uso JDBC.
Ter um monte de coisa no framework não é ruim, desde que essas coisas possam ser facilmente ignoradas por quem não quiser elas. Veja o java, tem um milhão de coisas e nem por isso é complicada…
Alguém aqui manja de ActiveRecord ???
O quão difícil seria fazer um em Java ???
No passado eu sei muito um DBBean que fazia CRUD automático sem uma linha de SQL.
Funcionava direitinho e ainda era otimizado para só dar update nos campos que foram alterados e não em tudo.
Sem querer ser chato, mas já sendo, você já trabalhou com um sistema realmente distribuído com EJB? Foi feliz com isso?
Se você foi, precisa, urgentemente dar uma olhada na API de remoting do Spring e ver como se faz uma camada de chamadas remotas realmente separada de todo o resto.[/quote]
Sabemos o quanto ainda é difícil trabalhar com ambiente distribuído, o principal pra mim é a rede, alguns culpam o Java por ser lento em ambiente distribuído, mas será que eles ja pararam pra ver se não é o tráfego da rede que está tornando lento o sistema ? Ao invés de sair por aí dizendo que EJB é lento, que não presta , que isso que aquilo … A única dificuldade que se tem quando vc está num ambiente desses é fazer com que fabricantes de appServers se comuniquem eficientemente, que não acontece muito bem hoje em dia, o Spring apresenta um conceito interessante sobre invocações remotas que com EJB utiliza-se alguns patterns auxiliares como BD, SL, etc… para isso. Acredito no EJB3, está mais simples do que a porcaria da #$$%&$ da esp. 2.1
[quote=Paulo Silveira]
porque uma porcaria? nao tem mais home, voce nao precisa implementar metodos de lifecycle se nao quiser, é um POJO e encapsula uma logica de negocios…[/quote]
At’eu que sou turrão gostei do EJB3, não sei onde estão vendo tanta complicação nele, pelo contrário, está muito simples e fácil.
[quote=saoj]Outra coisa: Java precisa urgentemente de um ActiveRecord. Hibernate é muito poderoso e robusto, mas não é simples nem fácil !!![/quote]Que é isso, cara… Eu acho Hibernate fácil. E usando Hibernate-Annotations então? Tô trabalhando em um projeto em que uma parte do sistema (legado) é feita usando JDBC e outra em Hibernate e a diferença entre os dois é assustadora! Fazer a manutenção do projeto com JDBC é um pesadelo!
Session Beans como remote façades são bem razoáveis, o ponto é que muito raramente você rpecisa de remote façades. Mesmo quando precisa, é preciso que o EJB seja apenas isso: uma façade. Nada de lógica dentro dele.
Não acho que o Hibernate em si seja simples, mas é muito mais fácil desenvolver com Hibernate do que com JDBC puro, em minha opinião.
Mapeamento Objeto-Relacional não é trivial de se implementar corretamente, principalmente com os diversos recursos do Hibernate.
O que é chato é algumas particularidades que você as vezes quebra a cabeça para resolver, principalmente quando se tem relacionamentos entre entidades.
Mas é algo que se você teve problema uma vez, aprende e nunca mais comete o mesmo erro. É um projeto muito bem documentado.
Demora um pouco para se aprender a usar, mas vale cada segundo gasto.
Um dos problemas com sistemas em ambiente distribuídos também é que o pessoal não consegue estabelecer corretamente os requisitos, não sabe ao certo o que acontecerá, só dizem … é possível que nós poderemos crescer e ser necessário colocar componentes de forma distribuída, é possível que existam clientes solicitando serviço sob demanda e com isso será mais eficiente se tivermos uma máquina mais perto dele geograficamente provendo esse serviço, ou seja, tudo gira em torno das possibilidades e não das factibilidades.
Concordo com vc, mas um problema que vejo é: como tirar isso da cabeça das pessoas se ao procurar exemplos na Internet, a grande maioria destes usam DTOs/VOs/TOs. Aposto que vc já parou para pensar: “Poxa! as vezes tenho impressão que estou dando murro em ponta de faca, pois eu falo e o pessoal não me entende ou não aceitam!”, mas não é fácil mudar essa cultura se ao começar a programar em Java, os exemplos que vc vai encontrar são destes tipos!
[quote=louds][quote=Thiagosc]Só na cabeça de fanáticos Ruby tem condições de substituir qualquer coisa, e não é só isso, se alguém discorda é atacado verbalmente! Ou seja, é o marketing estilo “bully”, aquele que te pega de porrada se você discordar. Eu não sou fã de marketing de Java, mas nunca vi uma empresa ou um vendedor chamando seus possíveis clientes de “burros”, e daí para baixo, por não desejarem usar Java. hahahah
Mas o pior de tudo é contarem vantagem de “somos superiores”. Meu Deus do céu, sequer têm noção de que isso faz mais mal a própria causa do que bem. Parece que todos que usam Ruby ganham automaticamente um título de “Leonardo da Vinci da área de TI”.
[/quote]
Verdade, você tem toda razão. Ruby é a maior besteira e só cretino usa.[/quote]
Olha, acho que o amigo foi infeliz na frase onde se refere que só cretino usa Ruby. Programo em Java, C/C++, PHP e como também programo em Ruby, essa afirmação me ofendeu. Acho isso muita falta de respeito com profissionais sérios que utilizam outras linguagens ALÉM DO JAVA, seja para trabalhar, por hobby ou simplesmente curiosidade. Aliás, acredito que se alguém deseja ter uma boa colocação no mercado e ser competitivo, precisa conhecer novos horizontes, além daquele mostrado pela TV. Isso é fundamental em qualquer área que se atue, em qualquer profissão. Agora, porque você não concorda com o que é dito sobre Ruby ou não aprova a forma de agir de alguns profissionais, isso também não te dá o direito de ofender/diminuir os demais. Você condenou a atitude de alguns profissionais mas fez algo bem pior. E as atitudes de “Leonardo da Vinci de TI” não se aplica somente aos Rubystas. Tem muito profissional de Java, C#, PHP agindo da mesma maneira. Defendendo sua tecnologia com unhas e dentes e se esquecendo que, quem dita as regras é o mercado. Quando o Java saiu, tinha muita empresa e profissional acreditando que não ia dar em nada, que Java não prestava. Imagina se Ruby acaba dando “em nada” como o Java.
Como você pôde perceber existe um grupo de extremistas aqui no fórum preparados para ofender a todos que discordem de seus pontos de vista míopes.
Você se esquece de um detalhe importante, Ruby é mais velho que Java. Ou seja, o Java evoluiu mais rápido do que ele, por que? Não apenas Ruby, mas Python e várias outras linguagens, por que será?
Não há uma demanda do mercado para isso, apenas meia dúzia de fanáticos fazendo barulho. E Ruby sequer conta com coisas básicas necessárias a qualquer negócio na era da internet como suporte a unicode, internacionalização, etc.
É até engraçado ver os “Leonardos da Vinci de TI” se descabelarem para provar que alguma coisa presta nesse negócio. Em contrapartida eu jamais ouvi um profissional Java xingar outros de burros ou coisa parecida por pensar diferente.