EJB 3.0 - Grupo de estudos

Pô Dark… não manjo nada ainda. Mas tem como a gente trocar uma idéia sobre o assunto ?

Valeu!

Opa Guilherme, tem sim! Eu ainda to engantinhando, fiz apenas um hello world heheh, mas digo q foi beeeeeeem mais simples q o meu hello world em EJB 2.1 ehehehe

Como disse eu to usando o Glassfish e em ambiente Linux (ubuntu) e nao teve segredo nenhum pra instalar, foi bem tranquilo.

Opa… então, vou instalar esse ambiente aqui para começar a brincar.

Salve Dark,

Bem em junho ainda, quando começou a falar em EJB 3, lançou aquela versão beta e tudo mais eu andei fazendo um session e não foi tão difícil não, tipo tinha muito mais dificuldade para trabalhar com 2.x do que o 3. Só que até agora ainda não arrumei um tempinho para fazer isto aí com o glassfish, vou testar aqui, aí vou estudar a possibilidade de criar também um tutorial para galerinha a respeito. O que acham?

:okok:

Boa marcos! Será muito bem vindo !!!

Trabalho com ejb 2 ha pelo menos 2 anos e gosto muito. no entanto, utilizo o jbuilder que simplesmente faz tudo. depois que se aprende os patterns e pra que servem, o melhor é utilizar os wizrds mesmo, ao invés de ficar criando VO’s e outras classes na mão e tendo trabalho a toa. o EJB utlizando o Jbuilder e uma mao na roda. fiz a analise de um sistema inteiro com +/- 70 tabelas todas interrelacionadas e consegui dar deploy no jboss 3 horas depois de inicado o trabalho no jbuidler. isso com todos os facades, assemblers, dtos e delegtes (~350 classes, fora interfaces) . so usando os wizards do jbuilder. repito: não vou ficar perdendo tempo em fazer tudo na mão se já aprendi. ok, mas tinha o problema do jbuilder ser software proprietário e isso me incomodava mesmo, pois a licença que eu tinha era 9 e ja tava usando jbuilder 2006… eis que surge o ejb 3 baseado no hibernate… achei muito bom e simples. comecei a estudar com um amigo e realmente era mais simples, apesar de não ter ferramenta gráfica. pelos tutorias que estudamos, o vo não existia mais. o delegate tb não, apesar de ser necessário utilizar service locator no cliente, o que não gosto, etc. bem, até ai tudo bem, as tags super simlples, belezinha mesmo. ai veio o grande problema. fazer relacionamento de beans em bancos diferentes. já tentamos de tudo, mexendo no persistent.xml colocando + de um context etc. e nada. nos foruns internacionais tb nada! os caras dizem que não dá e que isso é um erro de análise, o que é simplesmente ridículo. se eu tenho um projeto e quero utilizar uma classe já pronta obviamente deveria aproveitá-la de outro projeto… antes que isso chegue a uma discussão já martelada, pq isso é um fórum e todo mundo quer ajudar, eu adianto logo: com o jbuilder (ou qq outro como eclipse) isso é totalmente possível do EJB 2. no jbuilder e tão ridiculo de fazer que da ate pena. basta criar dois datasources, apontar cada bean pro seu datasource referente (nem o banco precisa ser o mesmo, pode ser qq um, oracle com mssql, etc.), depois esticar um relacionamento (1-n, n-1, n-n) pro outro bean. criar os facades, tudo nos wizards e blz. funciona que e uma beleza, ja testato e tudo. estamos quase voltando pro ejb 2 e suas zilhares de xml’s… não sei se é uma deficiência ou uma opção do ejb 3 mas ta atrapalhando meu pessoal supervisionado. e eu tb que prometi uma ferrari e dei pra eles um fusca… hehehe. me ajudem a tranformar o fusca em ferrari, pq nos foruns internacionais não deu nada…

Vou ser sincero com vc, acho meio estranho utilizar tableas de bancos diferentes… digo estranho pq é algo q nunca vi. Na empresa onde trampo, temos um sistema gigantesco (grande mesmo) com muitas tabelas, mas eh tudo no mesmo banco (oracle), mesmo usuario (tablespace ou sei la como chama isso.). O q vc poderia fazer, ja q o hibernate 3 nao da suporte pra isso, é criar um scriptizinho para pegar os seus dados do banco A, criar as tabelas no Banco B e jogar os dados para lá. Caso isso nao seja possivel, vc pode tbm criar uma interoperabilidade com webservices, bom, o q quero dizer eh q sempre há um jeito de contornarmos o nosso problema.

Ah, soh uma correção no que vc disse: não é necessário utilizar service locator no cliente, você pode injetar o Bean que vc quer, mesmo sendo um cliente não web, utilizando appclient (pelo menos no glassfish tem isso).

Cara,

Sei muito bem o que é isso. Isto é muito comum, pelo menos até hoje a maioria das aplicações que eu já fiz compatilhavam informações com outros bancos, bem se os bancos de dados devem compartilhar dados, isto é tarefa do banco de dados. Dê uma pesquisa sobre views.

:okok:

darkseid, é muito comum mesmo aplicações compartilharem dados. Nós não temos um sistema gigantesco. nós temos um sistema grande (400 estações simultâneas) e pelo menos 7 sistemas médios. vou te dar um exemplo simples. se vc tem um controle de processos que utiliza acesso via autenticação, o usuário daquele sistema pode muito bem ficar em uma tabela usuario com id, nome, tudo local… mas o mais seguro seria utilizar os dados provenientes do sistema de rh para pegar os dados referentes ao funcionário que seria então um usuário do sistema de processos. fomos além ainda e criamos um sistema de segurança que faz a integração de todos os sistemas. enfim, como disse o marcos isso é muito comum.
Com relação a view vc está certo marcos, em parte. lembre que uma das regras da programação em camadas é tirar a inteligência da camada de persistência. sei q muita gente não concorda (principalmente os DBA’s hehehehe) mas é assim que preferimos. os bancos na verdade tem que ser rápidos e seguros… O principal trabalho do DBA em 4 camadas é tunning, pelo menos pra gente que utiliza essa metodologia.
Eu tenho uma solução utilizando o pattern VO mas fica mais complexo. como o VO nao tem dependência com o banco, cria-se os beans apenas com seus respectivos IDs estrangeiros em sua própria classe e próprio pacote. o facade fica encarregado, via entity-manager de achar os beans das outras aplicações e monta-los em VO’s. O VO então será o objeto fornecido ao cliente, com todos os dados necessários (VO’s de VO’s). ai eu ja coloquei mais dois patterns que nao tinham, VO e assembler, utilizado para a montagem dos VOs no facade. Essa solução pelo menos mantém a segurança do isolamento dos beans (clientes não olham beans…) mas tb complicam a vida do povo.

Ah tah, entendi o esquema… é que geralmente eu via essas relações entre sistemas ou feitas em XML (webservices) ou no mesmo banco de dados, como na empresa q eu trabalho, mas é pq nós estamos fazendo o sistema todo.

Vc ja pensou na possibilidade de usar webservices?

não. nunca usei webservice. é um framework pra web? bem, se for, meu problema não é exatamente no cliente, e sim no server. para clientes web utilizo o tapestry 3 da jakarta e tou muito feliz com ele, muito bom e produtivo…
quanto ao comentário do marcos em relação ao view, tou até ponderando. mas lembre-se que ao dar deploy com campos de chave estrangeira ele cria contraints de foreign-key. acho que não vai ser possivel pq como ele vai criar constraints pra uma view. será que faz isso? outra coisa. não sei se da pra criar view em bancos diferentes (oracle x sql-server) e aqui nós temos esse problema… se me perguntarem pq vou ter que explicar um monte de questão política, então não perguntem. hehehehehehe

Não, na verdade webservices eh uma forma padrozinada de prover serviços pela web. Com isso, ao inves de vc ver no banco do RH alguma informação, você solicita essa informação ao sistema de rh q via webservice te envia… geralmente isso eh feito com xml… eh bem interessante para este tipo de problemas, pois garante a interoperabilidade de sistemas diferentes em ambientes diferentes. O unico problema eh q vc vai ter q mexer no sistema de rh para adicionar essa funcionalidade.