Teoricamente métodos ejbSelect retornam qualquer coisa ejb objects, ejb local objects, Integers, Double, Collections de qualquer coisa e etc… Na especificação EJB 2.1, nós temos a possibilidade de utilizar as funções max, min e blablabla.
Mas para executarmos um ejbSelect, o melhor a fazer é criar um ejbHome que delega a sua chamada para o ejbSelect. Isso é chato de fazer, aliás, muito chato. Além disso você não tem criterios como GROUP BY, etc…
Isso é muito complicado. Em SAs open sources como o JBoss, você pode re-escrever a infra-estrutura. No caso do JBoss você pode escrever um MBean que faça isso para você ou que encapsule alguém que possa fazer isso para você. Mas e se você estiver em um SA proprietário? E ai? Como é que fica ? Se eu não me engano, o jrun e o websphere 5.0 possuem alguma solução para isso… O JRun também usa JMX, então a solução é a mesma do JBoss…
Esconder pesquisas SQL em Session Beans é horrível…
Eu me faço esta pergunta com uma freqüência muito alta.
Ok, alguém vai vir aqui dizer que EJBs são muito importantes porque deixam muito trabalho sujo transparente, que poderia ser muito pior, que EJBs permitem (com uma certa transparência) clusterização, fail-over, controle de transações, etc etc… Eu não estou questionando o que EJB permite ou não ser feito nem com qual grau de facilidade. A questão é: nos inúmeros projetos em que a tecnologia Java pode ser aplicada, qual a porcentagem de uso que cabe aos EJBs e qual a porcentagem de importância dada a eles? Em outras palavras, será que o marketing feito sobre eles não é superior ao seu real ganho/uso?
Oziel, já tinham me falado que você não gostava do JBoss :D. Mas a questão não é essa. A questão é que a EJB-QL não é realista para pesquisas em grandes sistemas. O problema é a especificação, não a implementação.
bom, no EJB2.1 vai melhorar bastante, mas por enquanto, você pode utilizar JCA (Java Conector Architecture) para resolver parte do problema, se não me engano a JCA ja é obrigatoria para o J2EE 1.3, mas não tenho certeza, pelo menos o WebSphere, Sun One e JBOss eu tenho certeza que suportam JCA
Pessoal,
essa discussao nao leva a lugar nenhum , pois que pode ser bom pra mim, pode nao ser bom pra vc e vice-versa, eu acho valido sim discutir a tecnologia e tentar buscar solucoes melhores para a implementacao, no caso do EJB-QL eu o uso e quando ele nao me atende eu uso o JBOSS-QL e quando ele nao me atende eu uso DECLARED-QL e por ultimo JDBC, e te digo que raramente preciso chegar na ultima opcao!!
Em geral , quando se comeca a fazer comparacao entre AppServers / EJB e outras tecnicas (hibernate, jdo), o pessoal fica sempre batendo na mesma tecla: EJB-QL eh um lixo, precisa de um appserver, blablabla.
O mais importante, o que realmente os appserver/ejb revolucionaram eh a criacao da Programacao Declarativa. Uma penca de funcionalidades, que deveriam ser implementada pelo programador passaram a fazer parte do ambiente de deploy e descritos em arquivos XML.
Assim, hoje em dia, voce cria seu EJB, e separadamente diz que metodos vao ter que tipos de comportamento transacional. Voce tambem chega, ainda em granularidade de metodo dizer que perfil de usuario vai poder fazer uso de metodo (administrador ou usuario). Isso tudo sem precisar mexer em uma linha de codigo, somente no descritor.
Nas outras tecnologias isso tudo precisa ser explicitada pelo programador, na forma: aqui comeca minha transacao , comando1, comando2 , commit. Ou no caso de seguranca usando um if (!admin) return.
O EJB QL ta evoluindo. Logo ele sera o suficiente para a maior parte das aplicacoes (se ja nao eh).
Agora, se realmente, seguranca, transacoes, filas de mensagens, nada disso for interessante no seu sistema, uma abordagem totalmente web, com um hibernate ou jdo talvez seja uma melhor abordagem.
Mas nao va reeinventar a roda. Deixe o servidor de aplicacao fazer o trabalho sujo por voce. Deixe ele fazer os if (!admin) return, fazer os begin() commit() rollback().
é verdade, mas também pode ser esforço inutil se o sistema não precisar disto
gosto muito do J2EE, de EJBs e tudo o que vem junto, mas é preciso ver se o software realmente necessita de todos estes recursos
