ola pessoal!
durantes minhas leituras, percebi que existe uma diferença notavel entre aplicação web e aplicação corporativa. Percebi tbm que o EJB é usado como um padrão especifico e por conta disso abafa as demais tecnologias que poderiam ser apresentadas no mesmo contexto.
mas i agora…
uma aplicação corporativa precisa ter mesmo EJB?
gostaria que vcs deixasem as alternativas e esclarecimentos sobre está minha dúvida.
Olá
Não!
Você em raros casos pode precisar de EJBs. Mas só use se for EJB 3.0 porque os antigos nem vale a pena aprender. Sorte de quem escapou desta droga.
Mas muitas aplicações corporativas vão muito bem sem EJBs, com hibernate e spring.
Aliás, em muitos casos poderiam também ser feitas usando Grails+groovy+Java+etc. ou com Rails+Ruby
[]s
Luca
[quote=Zakim]ola pessoal!
durantes minhas leituras, percebi que existe uma diferença notavel entre aplicação web e aplicação corporativa. Percebi tbm que o EJB é usado como um padrão especifico e por conta disso abafa as demais tecnologias que poderiam ser apresentadas no mesmo contexto.
mas i agora…
uma aplicação corporativa precisa ter mesmo EJB?
gostaria que vcs deixasem as alternativas e esclarecimentos sobre está minha dúvida.
[/quote]
Bom, calma ai.
Primeiro, quando você diz “aplicação corporativa” o que significa especificamente?
Segundo, nenhum aplicação seja ela “corporativa”(que não sei qual sua definição disso) ou não, precisa de EJB’s.
EJB’s são uma solução específica(muito boa por sinal) para incorporarmos componentes distribuídos a nossa aplicação.(Componentes Distribuidos = objeto que rode em sistemas Heterogêneos)
O ponto forte dela é que ao utilizarmos, teremos em mãos também um facilidade de adicionar-mos ao nosso ambiente conceitos como Load Balance, Threading, Transações, Fail-over, Clustering, e etc e tal.
Muitas pessoas utilizam tecnologias assim para colocar apenas mais peso na aplicação e incorporar mais algumas siglas no produto. Porém temos que entender EJB’s como uma alternativa para a resolução de certos problemas.
Como dizem por aí, estaremos matando passarinhos com um canhão.
[quote=nbluis][quote=Zakim]ola pessoal!
durantes minhas leituras, percebi que existe uma diferença notavel entre aplicação web e aplicação corporativa. Percebi tbm que o EJB é usado como um padrão especifico e por conta disso abafa as demais tecnologias que poderiam ser apresentadas no mesmo contexto.
mas i agora…
uma aplicação corporativa precisa ter mesmo EJB?
gostaria que vcs deixasem as alternativas e esclarecimentos sobre está minha dúvida.
[/quote]
Bom, calma ai.
Primeiro, quando você diz “aplicação corporativa” o que significa especificamente?
Segundo, nenhum aplicação seja ela “corporativa”(que não sei qual sua definição disso) ou não, precisa de EJB’s.
EJB’s são uma solução específica(muito boa por sinal) para incorporarmos componentes distribuídos a nossa aplicação.(Componentes Distribuidos = objeto que rode em sistemas Heterogêneos)
O ponto forte dela é que ao utilizarmos, teremos em mãos também um facilidade de adicionar-mos ao nosso ambiente conceitos como Load Balance, Threading, Transações, Fail-over, Clustering, e etc e tal.
Muitas pessoas utilizam tecnologias assim para colocar apenas mais peso na aplicação e incorporar mais algumas siglas no produto. Porém temos que entender EJB’s como uma alternativa para a resolução de certos problemas.
Como dizem
por aí, estaremos matando passarinhos com um canhão.
[/quote]
Boa, realmente vale à pena conhecer profundamente a infra-estrutura desse framework, saber o que ele te provê , até mesmo para aplicar parte dele em algumas situações.
Luca, no meu ponto de vista, soluções como Grails, que ainda estão em fase lab, pode te tirar o convívio social e trazer até mesmo dano ao seu cliente.
Imagina a quantidade de bugs que uma aplicação iniciante dessas pode ter.
Eu não poria num cliente Enterprise, como Banco por exemplo, ainda mais se eu não fizer parte da equipe , for um consultor pontual.
Prefiro pecar pelo conservadorismo, mas garantir meus finais de semana curtindo som eletrônico de boa com os amigos 
Olá
[quote=Kenobi]
Luca, no meu ponto de vista, soluções como Grails, que ainda estão em fase lab, pode te tirar o convívio social e trazer até mesmo dano ao seu cliente.
Imagina a quantidade de bugs que uma aplicação iniciante dessas pode ter.
Eu não poria num cliente Enterprise, como Banco por exemplo, ainda mais se eu não fizer parte da equipe , for um consultor pontual.
Prefiro pecar pelo conservadorismo, mas garantir meus finais de semana curtindo som eletrônico de boa com os amigos [/quote]
Eu também não colocaria Rails nem Grails porque não domino nenhum dos dois.
Mas sei que em grandes empresas se usa de tudo. Há aplicações CRUD em grandes corporações até em maior número do que na quitanda da esquina. Então, se eu fosse gerente de projetos e alguém aparecesse com uma solução pronta e funcionando usando Ruby ou Groovy, eu não teria nada contra. Aliás, pelo pouco que sei, o Grails pode ser muito bom para uma equipe que não sabe Ruby e domina Java.
Posso afirmar isto com certeza por que há muitos anos atrás aprovei um CRUD usando Struts para um Help Desk que foi feito em poucos dias e na época eu não sabia nada de Struts. Melhor do que o Struts 1, com certeza Grails e Rails são.
[]s
Luca
[quote=Luca]Olá
[quote=Kenobi]
Luca, no meu ponto de vista, soluções como Grails, que ainda estão em fase lab, pode te tirar o convívio social e trazer até mesmo dano ao seu cliente.
Imagina a quantidade de bugs que uma aplicação iniciante dessas pode ter.
Eu não poria num cliente Enterprise, como Banco por exemplo, ainda mais se eu não fizer parte da equipe , for um consultor pontual.
Prefiro pecar pelo conservadorismo, mas garantir meus finais de semana curtindo som eletrônico de boa com os amigos [/quote]
Eu também não colocaria Rails nem Grails porque não domino nenhum dos dois.
Mas sei que em grandes empresas se usa de tudo. Há aplicações CRUD em grandes corporações até em maior número do que na quitanda da esquina. Então, se eu fosse gerente de projetos e alguém aparecesse com uma solução pronta e funcionando usando Ruby ou Groovy, eu não teria nada contra. Aliás, pelo pouco que sei, o Grails pode ser muito bom para uma equipe que não sabe Ruby e domina Java.
Posso afirmar isto com certeza por que há muitos anos atrás aprovei um CRUD usando Struts para um Help Desk que foi feito em poucos dias e na época eu não sabia nada de Struts. Melhor do que o Struts 1, com certeza Grails e Rails são.
[]s
Luca[/quote]
Isso depende de tantos fatores… um por exemplo é regras da instituição, se tem uma GEMUD - Gestão de Mudança, fechada e sua aplicação apresenta diversos problemas ainda não previstos, vai ter sérios problemas com a equipe de Infra.
Você foi corajoso, talvez pudesse fazer essa escolha pois tinha flexibilidade em alterar o ambiente em produção.
Quando não temos tal, e Standards, aí o bicho pega …
Anyway, voltando ao tópico, entenda as reais necessidades do seu projeto, o que é o EJB em termos de infra e depois decida oq utilizar do framework e como !!
Esse é um caminho longo, que pode ser percorrido com livros, cursos e muita muita persistência
Olá
[quote=Kenobi] voltando ao tópico, entenda as reais necessidades do seu projeto, o que é o EJB em termos de infra e depois decida oq utilizar do framework e como !!
Esse é um caminho longo, que pode ser percorrido com livros, cursos e muita muita persistência [/quote]
Uma sugestão para todos. Sempre que recomendarem o uso de EJB 3.0, coloquem por extenso EJB 3.0 para que ninguém pense que a recomendação é para usar aqueles EJBs anteriores ao 3.0, que na minha opinião foram uma completa porcaria. E olha que eu estou sendo bonzinho, porque na opinião de gente como o Rod Johnson, eles foram muito piores do que isto.
[]s
Luca
[quote=Luca]Olá
[quote=Kenobi] voltando ao tópico, entenda as reais necessidades do seu projeto, o que é o EJB em termos de infra e depois decida oq utilizar do framework e como !!
Esse é um caminho longo, que pode ser percorrido com livros, cursos e muita muita persistência [/quote]
Uma sugestão para todos. Sempre que recomendarem o uso de EJB 3.0, coloquem por extenso EJB 3.0 para que ninguém pense que a recomendação é para usar aqueles EJBs anteriores ao 3.0, que na minha opinião foram uma completa porcaria. E olha que eu estou sendo bonzinho, porque na opinião de gente como o Rod Johnson, eles foram muito piores do que isto.
[]s
Luca[/quote]
Apoiado;
Antes da versão 3.0 esse troço era uma vida de aprendizado(e ainda sim apareciam problemas).
Para aqueles que pensam em desenvolvimento ágil e fácil suporte, eles eram um bicho de sete ou até mais cabeças.
hehehe…
gostei da discussão!
Não posso dar muitas opniões porque sou um novato com muita vontade de aprender.
Partindo do conceito de que “aplicações corporativas” são aplicações de grande porte e que precisam ser muito bem elaboradas, acredito que devo sim usar o EJB, haja visto que ele possui mais documentações e é mais acessivel para o aprendizado.
Agradeço pela discussão de vocês, que de certa forma contribuiu muito para a respostas de alguns dos meus inumeros questionamentos sobre frameworks.
valeu!
Acredito que para uma aplicação de PESO é uma alternativa a ser considerada em detrimento do Spring e Hibernate. A simplicidade do EJB 3 no desenvolvimento dessas aplicações mais “parrudas” se apresentam, no meu ver, a melhor alternativa. O controle trasparente desses aspectos citados acima me agradam e muito.
Haja visto os benefícios do controle de vários aspectos do sistema pelo Container, somado ao controle pontual destes através da configuração do próprio AS (portabilidade, segurança etc)
Ou seja, o controle dos aspectos gerais do sistema é muito máis forte quando usa EJB. Acho o Spring mais complexo que EJB 3, por exemplo (sem querer incitar flamewar ou aquiescer minhas preferências)
É aquele papo já clichê: Cada caso deve ser analisado.
Alguns você resolve com Grails, outros com SOA(Webservices ou RESTlets - para agrado do Luca -) e outros com EJB 3.
[]s